#### I. ISO15118CertificateManagement
-- :x: InstallCertificate
-- :x: DeleteCertificate
+- :white_check_mark: CertificateSigned
+- :white_check_mark: DeleteCertificate
+- :white_check_mark: GetInstalledCertificateIds
+- :white_check_mark: InstallCertificate
+- :white_check_mark: SignCertificate
+
+> **Note**: Certificate management implementation limitations:
+>
+> - **Mock CSR generation**: The `SignCertificate` command generates a mock Certificate Signing Request (CSR) for simulation purposes. In production, this should be replaced with actual cryptographic CSR generation.
+> - **OCSP stub**: Online Certificate Status Protocol (OCSP) validation is stubbed and returns `Failed` status. Full OCSP integration requires external OCSP responder configuration.
#### J. LocalAuthorizationListManagement
--- /dev/null
+
+
+# OCA white paper:
+
+Improved security for OCPP 1.6-J.
+
+Relevant for OCPP 1.6-J (JSON over WebSockets)
+
+Copyright © 2022 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
+
+<table><tr><td>VERSION</td><td>DATE</td><td>AUTHOR</td><td>DESCRIPTION</td></tr><tr><td>1.3 Edition 3</td><td>2022-02-17</td><td>Franc Buve (OCA)Paul Klapwijk (OCA)</td><td>Clarified the description of the certificateHashData fields</td></tr><tr><td>1.2 Edition 2</td><td>2020-03-31</td><td>Paul Klapwijk (OCA)Milan Jansen (OCA)Robert de Leeuw (ihomer)</td><td>Edition 2, based on the security fixes in the OCPP 2.0.1 specification</td></tr><tr><td>1.0</td><td>2018-11-20</td><td>Robert de Leeuw (IHomer)</td><td>Final release after last rework check</td></tr></table>
+
+# 1. Scope
+
+This white paper describes how the security enhancements, introduced in OCPP 2.0, can be used, on top of OCPP 1.6-J, in a standardized way.
+
+The security part of OCPP 2.0 was developed to strengthen and mature the future development and standardization of OCPP. It is based amongst others on the end-to-end security design by LaQuSo [11]. Security requirements are included, on security measures for both Charge Point and Central System, to help developers build a secure OCPP implementation.
+
+This document contains the following security improvements:
+
+- Secure connection setup
+- Security events/logging
+- Secure firmware update
+
+# 1.1. Edition 3
+
+This document is the Edition 3 of "Improved security for OCPP 1.6-J" white paper. The difference between Edition 3 and the previous version is the clarification of the fields of the CertificateHashDataType, see also the changelog edition 3. This clarification was needed since in practice it turned out that the current description was ambiguous and could lead to non-interoperable implementations, because content and representation were not clearly specified.
+
+Edition 3 of this document replaces previous versions. OCA advises implementers of OCPP 1.6-J to no longer implement previous versions of this document and only use edition 3 going forward.
+
+As a rule, existing numbered requirements are only updated or removed, previously used requirements numbers are never reused for a totally different requirement.
+
+# 1.2. Security Objectives
+
+This section is informative.
+
+OCPP security has been designed to meet the following security objectives:
+
+1. To allow the creation of a secure communication channel between the Central System and Charge Point. The integrity and confidentiality of messages on this channel should be protected with strong cryptographic measures.
+2. To provide mutual authentication between the Charge Point and the Central System. Both parties should be able to identify who they are communicating with.
+3. To provide a secure firmware update process by allowing the Charge Point to check the source and the integrity of firmware images, and by allowing non-repudiation of these images.
+4. To allow logging of security events to facilitate monitoring the security of the smart charging system.
+
+# 1.3. Design Considerations
+
+This section is informative.
+
+This document was designed to fit into the approach taken in OCPP. Standard web technologies are used whenever possible to allow cost-effective implementations using available web libraries and software. No application layer security measures are included. Based on these considerations, OCPP security is based on TLS and public key cryptography using X.509 certificates. Because the Central System usually acts as the server, different users or role-based access control on the Charge Point are not implemented in this standard. To mitigate this, it is recommended to implement access control on the Central System. To make sure the mechanisms implemented there cannot be bypassed, OCPP should not be used by qualified personnel performing maintenance to Charge Points locally at the Charge Point, as other protocols may be used for local maintenance purposes.
+
+# 1.4. OCPP-J Only
+
+This section is informative.
+
+This document is for OCPP 1.6-J (JSON over WebSockets) only, OCPP-S (SOAP) is NOT supported. This document was started, as it is seen as a simple step to port OCPP 2.0 security to OCPP 1.6. But as OCPP 2.0/2.0.1 only supports JSON over WebSockets (not SOAP), this document is also written for OCPP 1.6-J only. Adding SOAP to this document would have taken a lot of work and review by security experts.
+
+# 1.5. General documentation remarks
+
+This section is informative.
+
+This document is based on OCPP 2.0.1. To help developers that are implementing both 1.6J security improvement and OCPP 2.0.1, we have kept the Use Case numbering from OCPP 2.0.1. So when implementing for example Use Case N01, it is the same use case in this document as in the 2.0.1 specification.
+
+# 1.6. Conventions
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [13], subject to the following additional clarification clause:
+
+The phrase "valid reasons in particular circumstances" relating to the usage of the terms "SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" is to be taken to mean technically valid reasons, such as the absence of necessary hardware to support a function from a Charge Point design: for the purposes of this specification it specifically excludes decisions made on commercial, or other non-technical grounds, such as cost of implementation, or likelihood of use.
+
+# 1.7.References
+
+Table 1. References
+
+<table><tr><td>REFERENCE</td><td>DESCRIPTION</td></tr><tr><td>[1]</td><td>ENISA European Network and Information Security Agency, Algorithms, key size and parameters report 2014, 2014. (last accessed on 17 January 2016) https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014</td></tr><tr><td>[2]</td><td>Cooper, D., et al., Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Internet Engineering Task Force, Request for Comments 5280, May 2008, http://www.ietf.org/rfc/rfc5280.txt</td></tr><tr><td>[3]</td><td>Dierks, T. and Rescorla, E., The Transport Layer Security (TLS) Protocol Version 1.2, Internet Engineering Task Force, Request for Comments 5246, August 2008, http://www.ietf.org/rfc/rfc5246.txt</td></tr><tr><td>[4]</td><td>Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004. https://www.ietf.org/rfc/rfc3749.txt</td></tr><tr><td>[5]</td><td>Bundesamt für Sicherheit in der Informationstechnik: Anwendungshinweise und Interpretationen zum Schema, AIS 20, Funktionalitätsklassen und Evaluationsmethodologie für deterministische Zufallszahlengenerator, Version 3.0, Bonn, Germany, May 2013. (in German) https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_20(pdf.html</td></tr><tr><td>[6]</td><td>Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005. https://www.ietf.org/rfc/rfc4210.txt</td></tr><tr><td>[7]</td><td>National Institute of Standards and Technology. Special Publication 800-57 Part 1 Rev. 4, Recommendation for Key Management. January 2016. https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-4/final</td></tr><tr><td>[8]</td><td>RFC 2617. HTTP Authentication: Basic and Digest Access Authentication. https://www.ietf.org/rfc/rfc2617.txt</td></tr><tr><td>[9]</td><td>RFC 5280. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. https://www.ietf.org/rfc/rfc5280.txt</td></tr><tr><td>[10]</td><td>OCPP 1.6. Interface description between Charge Point and Central System. October 2015. http://www.openchargealliance.org/downloads/</td></tr><tr><td>[11]</td><td>Eekelen, M. van, Poll, E., Hubbers, E., Vieira, B., Broek, F. van den: An end-to-end security design for smart EV-charging for Enexus and ElaadNL by LaQuSo1. December 2, 2014. https://www.elaad.nl/smart-charging-end2end-security-design/</td></tr><tr><td>[12]</td><td>RFC 2818. HTTP Over TLS. https://tools.ietf.org/html/rfc2818</td></tr><tr><td>[13]</td><td>Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. http://www.ietf.org/rfc/rfc2119.txt</td></tr><tr><td>[14]</td><td>RFC 2986. PKCS #10: Certification Request Syntax Specification, Version 1.7. https://www.ietf.org/rfc/rfc2986.txt</td></tr><tr><td>[15]</td><td>RFC 6960. X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, https://www.ietf.org/rfc/rfc6960.txt</td></tr></table>
+
+# 2. Secure connection setup
+
+# 2.1. Security Profiles
+
+This section defines the different OCPP security profiles and their requirement. This White Paper supports three security profiles:
+
+The table below shows which security measures are used by which profile.
+
+Table 2. Overview of OCPP security profiles
+
+<table><tr><td>PROFILE</td><td>CHARGE POINT
+AUTHENTICATION</td><td>CENTRAL SYSTEM
+AUTHENTICATION</td><td>COMMUNICATION
+SECURITY</td></tr><tr><td>1. Unsecured Transport with Basic Authentication</td><td>HTTP Basic Authentication</td><td>-</td><td>-</td></tr><tr><td>2. TLS with Basic Authentication</td><td>HTTP Basic Authentication</td><td>TLS authentication
+using certificate</td><td>Transport Layer Security
+(TLS)</td></tr><tr><td>3. TLS with Client Side Certificates</td><td>TLS authentication
+using certificate</td><td>TLS authentication
+using certificate</td><td>Transport Layer Security
+(TLS)</td></tr></table>
+
+- The Unsecured Transport with Basic Authentication Profile does not include authentication for the Central System, 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 Central System and the Charge Point. For field operation it is highly recommended to use a security profile with TLS.
+
+# 2.2. Generic Security Profile requirements
+
+Table 3. Generic Security Profile requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A00.FR.001</td><td></td><td>The Charge Point and Central System SHALL only use one security profile at a time</td></tr><tr><td>A00.FR.002</td><td>If the Charge Point tries to connect with a different profile than the Central System is using</td><td>The Central System SHALL reject the connection.</td></tr><tr><td>A00.FR.003</td><td>If the Charge Point detects that the Central System has accepted a connection with a different profile than the Charge Point is using</td><td>The Charge Point SHALL terminate the connection.</td></tr><tr><td>A00.FR.004</td><td></td><td>The security profile SHALL be configured before OCPP communication is enabled.</td></tr><tr><td>A00.FR.005</td><td></td><td>Lowering the security profile that is used to a less secure profile is, for security reasons, not part of the OCPP specification, and MUST be done through another method, not via OCPP. OCPP messages SHALL NOT be used for this (e.g. ChangeConfiguration.req or DataTransfer).</td></tr><tr><td>A00.FR.006</td><td>When a Central System communicates with Charge Points with different security profiles or different versions of OCPP.</td><td>The Central System MAY operate the Charge Points via different addresses or ports of the Central System.
+For instance, the Central System server may have one TCP port for TLS with Basic Authentication, and another port for TLS with Client Side Certificates.
+In this case there is only one security profile in use per port of the Central System, which is allowed.</td></tr></table>
+
+# NOTE
+
+Only securing the OCPP communication is not enough to build a secure Charge Point. All other interfaces to the Charge Point should be equally well secured.
+
+# 2.3. Unsecured Transport with Basic Authentication Profile - 1
+
+Table 4. Security Profile 1 - Unsecured Transport with Basic Authentication
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>Unsecured Transport with Basic Authentication</td></tr><tr><td>2</td><td>Profile No.</td><td>1</td></tr><tr><td>3</td><td>Description</td><td>The Unsecured Transport with Basic Authentication profile provides a low level of security. Charge Point authentication is done through a username and password. No measures are included to secure the communication channel.</td></tr><tr><td>4</td><td>Charge Point Authentication</td><td>For Charge Point authentication HTTP Basic authentication is used.</td></tr><tr><td>5</td><td>Central System Authentication</td><td>In this profile, the Central System does not authenticate itself to the Charge Point. The Charge Point has to trust that the server it connects to is indeed the Central System.</td></tr><tr><td>6</td><td>Communication Security</td><td>No communication security measures are included in the profile.</td></tr></table>
+
+
+Figure 1. Sequence Diagram: HTTP Basic Authentication sequence diagram
+
+<table><tr><td>7</td><td>Remark(s)</td><td>The Charge Point should include the same header as used in Basic Auth RFC 2617, while requesting to upgrade the http connection to a websocket connection as described in RFC 6455. The server first needs to validate the Authorization header before upgrading the connection.
+Example:
+GET /ws HTTP/1.1
+Remote-Addr: 127.0.0.1
+UPGRADE: websocket
+CONNECTION: Upgrade
+HOST: 127.0.0.1:9999
+ORIGIN: http://127.0.0.1:9999
+SEC-WEBSOCKET-KEY: Pb4obWo2214EfaPQuazMjA==SEC-WEBSOCKET-VERSION: 13
+AUTHORIZATION: Basic <Base64 encoded(<ChargePointId>:_<AuthorizationKey>)</td></tr></table>
+
+# 2.3.1. Unsecured Transport with Basic Authentication Profile - Requirements
+
+Table 5. Security Profile 1 - Unsecured Transport with Basic Authentication - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A00.FR.201</td><td></td><td>The Unsecured Transport with Basic Authentication Profile SHOULD only be used in trusted networks.</td></tr><tr><td>A00.FR.202</td><td></td><td>The Charge Point SHALL authenticate itself to the Central System using HTTP Basic authentication [8]</td></tr><tr><td>A00.FR.203</td><td>A00.FR.202</td><td>The client, i.e. the Charge Point, SHALL provide a username and password with every connection request.</td></tr><tr><td>A00.FR.204</td><td>A00.FR.203</td><td>The username SHALL be equal to the Charge Point identity, which is the identifying string of the Charge Point as it uses it in the OCPP-J connection URL.</td></tr><tr><td>A00.FR.205</td><td>A00.FR.203</td><td>The password SHALL be stored in the AuthorizationKey Configuration Key. Minimal 16-bytes long, It is strongly advised to be randomly generated binary to get maximal entropy. Hexadecimal represented (20 bytes maximum, represented as a string of up to 40 hexadecimal digits).</td></tr><tr><td>A00.FR.206</td><td>A00.FR.203</td><td>With HTTP Basic, the username and password are transmitted in clear text, encoded in base64 only. Hence, it is RECOMMENDED that this mechanism will only be used over connections that are already secured with other means, such as VPNs.</td></tr></table>
+
+# 2.4. TLS with Basic Authentication Profile - 2
+
+Table 6. Security Profile 2 - TLS with Basic Authentication
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>TLS with Basic Authentication</td></tr><tr><td>2</td><td>Profile No.</td><td>2</td></tr><tr><td>3</td><td>Description</td><td>In the TLS with Basic Authentication profile, the communication channel is secured using Transport Layer Security (TLS). The Central System authenticates itself using a TLS server certificate. The Charge Points authenticate themselves using HTTP Basic Authentication.</td></tr><tr><td>4</td><td>Charge Point Authentication</td><td>For Charge Point authentication HTTP Basic authentication is used.Because TLS is used in this profile, the password will be sent encrypted, reducing the risks of using this authentication method.</td></tr><tr><td>5</td><td>Central System Authentication</td><td>The Charge Point authenticates the Central System via the TLS server certificate.</td></tr><tr><td>6</td><td>Communication Security</td><td>The communication between Charge Point and Central System is secured using TLS.</td></tr></table>
+
+
+Figure 2. Sequence Diagram: TLS with Basic Authentication sequence diagram
+
+<table><tr><td>7</td><td>Remark(s)</td><td>TLS allows a number of configurations, not all of which provide sufficient security. The requirements below describe the configurations allowed for OCPP.
+It is strongly RECOMMENDED to use TLS v1.2 or above for new Charge Points. This also facilitates a later upgrade to OCPP 2.0.1. To provide an adequate level of security for legacy Charge Points that cannot support TLS v1.2 or above, TLS v1.0 or v1.1 MAY be used with cypher suite TLS_RSA_WITH_AES_128_CBC_SHA.</td></tr></table>
+
+# 2.4.1. TLS with Basic Authentication Profile - Requirements
+
+Table 7. Security Profile 2 - TLS with Basic Authentication - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A00.FR.301</td><td></td><td>The Charge Point SHALL authenticate itself to the Central System using HTTP Basic authentication [8]</td></tr><tr><td>A00.FR.302</td><td>A00.FR.301</td><td>The client, i.e. the Charge Point, SHALL provide a username and password with every connection request.</td></tr><tr><td>A00.FR.303</td><td>A00.FR.302</td><td>The username SHALL be equal to the Charge Point identity, which is the identifying string of the Charge Point as it uses it in the OCPP-J connection URL.</td></tr><tr><td>A00.FR.304</td><td>A00.FR.302</td><td>The password SHALL be stored in the AuthorizationKey Configuration Key. Minimal 16-bytes long, It is strongly advised to be randomly generated binary to get maximal entropy. Hexadecimal represented (20 bytes maximum, represented as a string of up to 40 hexadecimal digits).</td></tr><tr><td>A00.FR.305</td><td></td><td>The Central System SHALL act as the TLS server.</td></tr><tr><td>A00.FR.306</td><td></td><td>The Central System SHALL authenticate itself by using the Central System certificate as server side certificate.</td></tr><tr><td>A00.FR.307</td><td></td><td>The Charge Point SHALL verify the certification path of the Central System's certificate according to the path validation rules established in Section 6 of [2].</td></tr><tr><td>A00.FR.308</td><td></td><td>The Charge Point SHALL verify that the commonName includes the Central System's Fully Qualified Domain Name (FQDN).</td></tr><tr><td>A00.FR.309</td><td>If the Central System does not own a valid certificate, or if the certification path is invalid</td><td>The Charge Point SHALL trigger an InvalidCentralSystemCertificate security event.</td></tr><tr><td>A00.FR.310</td><td>A00.FR.309</td><td>The Charge Point SHALL terminate the connection.</td></tr><tr><td>A00.FR.311</td><td></td><td>The communication channel SHALL be secured using Transport Layer Security (TLS) [3].</td></tr><tr><td>A00.FR.312</td><td></td><td>The Charge Point and Central System SHALL only use TLS v1.2 or above, TLS v1.0/1.1 MAY be used by Charge Points that cannot support TLS v1.2 (NOTE: TLS v1.0/1.1 is not allowed in OCPP 2.0.1).</td></tr><tr><td>A00.FR.313</td><td></td><td>Both of these endpoints SHALL check the version of TLS used.</td></tr><tr><td>A00.FR.314</td><td>A00.FR.313 AND The Central System detects that the Charge Point only allows connections using an older version of TLS, and TLS v1.0/1.1 not expected for this Charge Point, or only allows SSL</td><td>The Central System SHALL terminate the connection.</td></tr><tr><td>A00.FR.315</td><td>A00.FR.313 AND The Charge Point detects that the Central System only allows connections using an older version of TLS, or only allows SSL</td><td>The Charge Point SHALL trigger an InvalidTLSVersion security event AND terminate the connection.</td></tr><tr><td>A00.FR.316</td><td></td><td>TLS SHALL be implemented as in [3] or its successor standards without any modifications.</td></tr><tr><td>A00.FR.317</td><td></td><td>The Central System SHALL support at least the following four cipher suites:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_GCM_SHA384Note: The Central System will have to provide 2 different certificates to support both Digital Signature Algorithms (RSA and ECDSA). Also when using security profile 3, the Central System should be capable of generating client side certificates for both Digital Signature Algorithms.</td></tr><tr><td>A00.FR.318</td><td></td><td>The Charge Point SHALL support at least the cipher suites:(TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256ANDTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384)OR(TLS_RSA_WITH_AES_128_GCM_SHA256ANDTLS_RSA_WITH_AES_256_GCM_SHA384)ORWhen the Charge Point supports only TLS v1.0/1.1:TLS_RSA_WITH_AES_128_CBC_SHANote: TLS_RSA does not support forward secrecy, therefore TLS_ECDHE is RECOMMENDED. Furthermore, if the Charge Point detects an algorithm used that is not secure, it SHOULD trigger an InvalidTLSCipherSuite security event (send to the Central System via a SecurityEventNotification.req).</td></tr><tr><td>A00.FR.319</td><td></td><td>The Charge Point and Central System SHALL NOT use cipher suites that use cryptographic primitives marked as unsuitable for legacy use in [1]. This will mean that when one (or more) of the cipher suites described in this specification becomes marked as unsuitable for legacy use, it SHALL NOT be used anymore.</td></tr><tr><td>A00.FR.320</td><td></td><td>The TLS Server and Client SHALL NOT use TLS compression methods to avoid compression side-channel attacks and to ensure interoperability as described in Section 6 of [4].</td></tr><tr><td>A00.FR.321</td><td>A00.FR.320ANDThe Central System detects that theCharge Point only allows connections using one of these suites</td><td>The Central System SHALL terminate the connection.</td></tr><tr><td>A00.FR.322</td><td>A00.FR.320ANDThe Charge Point detects that theCentral System only allowsconnections using one of these suites</td><td>The Charge Point SHALL trigger an InvalidTLSCipherSuite security event AND terminate the connection.</td></tr><tr><td>A00.FR.323</td><td>When the Central System terminates the connection because of a security reason</td><td>It is RECOMMENDED to log a security event in the Central System.</td></tr><tr><td>A00.FR.324</td><td>When the Central System expects Charge Points with only TLS v1.0/1.1 support</td><td>The Central System SHOULD support the cypher suite: TLS_RSA_WITH_AES_128_CBC_SHA only for TLS v1.0/1.1 connections.</td></tr></table>
+
+# 2.5. TLS with Client Side Certificates Profile - 3
+
+Table 8. Security Profile 3 - TLS with Client Side Certificates
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>TLS with Client Side Certificates</td></tr><tr><td>2</td><td>Profile No.</td><td>3</td></tr><tr><td>3</td><td>Description</td><td>In the TLS with Client Side Certificates profile, the communication channel is secured using Transport Layer Security (TLS). Both the Charge Point and Central System authenticate themselves using certificates.</td></tr><tr><td>4</td><td>Charge Point Authentication</td><td>The Central System authenticates the Charge Point via the TLS client certificate.</td></tr><tr><td>5</td><td>Central System Authentication</td><td>The Charge Point authenticates the Central System via the TLS server certificate.</td></tr><tr><td>6</td><td>Communication Security</td><td>The communication between Charge Point and Central System is secured using TLS.</td></tr></table>
+
+
+Figure 3. Sequence Diagram: TLS with Client Side Certificates
+
+<table><tr><td>7</td><td>Remark(s)</td><td>It is strongly RECOMMENDED to use TLS v1.2 or above for new Charge Points. This also facilitates a later upgrade to OCPP 2.0.1. To provide an adequate level of security for legacy Charge Points that cannot support TLS v1.2 or above, TLS v1.0 or v1.1 MAY be used with cypher suite TLS_RSA_WITH_AES_128_CBC_SHA.</td></tr></table>
+
+# 2.5.1. TLS with Client Side Certificates Profile - Requirements
+
+Table 9. Security Profile 3 - TLS with Client Side Certificates - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A00.FR.401</td><td></td><td>The Charge Point SHALL authenticate itself to the Central System using the Charge Point certificate.</td></tr><tr><td>A00.FR.402</td><td></td><td>The Charge Point certificate SHALL be used as a TLS client side certificate</td></tr><tr><td>A00.FR.403</td><td></td><td>The Central System SHALL verify the certification path of the Charge Point's certificate according to the path validation rules established in Section 6 of [2]</td></tr><tr><td>A00.FR.404</td><td></td><td>The Central System SHALL verify that the certificate is owned by the CPO (or an organization trusted by the CPO) by checking that the O (organizationName) RDN in the subject field of the certificate contains the CPO name.</td></tr><tr><td>A00.FR.405</td><td></td><td>The Central System SHALL verify that the certificate belongs to this Charge Point by checking that the CN (commonName) RDN in the subject field of the certificate contains the unique Serial Number of the Charge Point</td></tr><tr><td>A00.FR.406</td><td>If the Charge Point certificate is not owned by the CPO, for instance immediately after installation</td><td>it is RECOMMENDED to update the certificate before continuing communication with the Charge Point (also see Installation during manufacturing or installation.)</td></tr><tr><td>A00.FR.407</td><td>If the Charge Point does not own a valid certificate, or if the certification path is invalid</td><td>The Central System SHALL terminate the connection.</td></tr><tr><td>A00.FR.408</td><td>A00.FR.407</td><td>It is RECOMMENDED to log a security event in the Central System.</td></tr><tr><td>A00.FR.409</td><td></td><td>The Central System SHALL act as the TLS server.</td></tr><tr><td>A00.FR.410</td><td></td><td>The Central System SHALL authenticate itself by using the Central System certificate as server side certificate.</td></tr><tr><td>A00.FR.411</td><td></td><td>The Charge Point SHALL verify the certification path of the Central System's certificate according to the path validation rules established in Section 6 of [2].</td></tr><tr><td>A00.FR.412</td><td></td><td>The Charge Point SHALL verify that the commonName matches the Central System's Fully Qualified Domain Name (FQDN).</td></tr><tr><td>A00.FR.413</td><td>If the Central System does not own a valid certificate, or if the certification path is invalid</td><td>The Charge Point SHALL trigger an InvalidCentralSystemCertificate security event.</td></tr><tr><td>A00.FR.414</td><td>A00.FR.413</td><td>The Charge Point SHALL terminate the connection.</td></tr><tr><td>A00.FR.415</td><td></td><td>The communication channel SHALL be secured using Transport Layer Security (TLS) [3].</td></tr><tr><td>A00.FR.416</td><td></td><td>The Charge Point and Central System SHALL only use TLS v1.2 or above, TLS v1.0/1.1 MAY be used by Charge Points that cannot support TLS v1.2 (NOTE: TLS v1.0/1.1 is not allowed in OCPP 2.0.1).</td></tr><tr><td>A00.FR.417</td><td></td><td>Both of these endpoints SHALL check the version of TLS used.</td></tr><tr><td>A00.FR.418</td><td>A00.FR.417 AND The Central System detects that the Charge Point only allows connections using an older version of TLS, and TLS v1.0/1.1 not expected for this Charge Point, or only allows SSL</td><td>The Central System SHALL terminate the connection.</td></tr><tr><td>A00.FR.419</td><td>A00.FR.417 AND The Charge Point detects that the Central System only allows connections using an older version of TLS, or only allows SSL</td><td>The Charge Point SHALL trigger an InvalidTLSVersion security event AND terminate the connection.</td></tr><tr><td>A00.FR.420</td><td></td><td>TLS SHALL be implemented as in [3] or its successor standards without any modifications.</td></tr><tr><td>A00.FR.421</td><td></td><td>The Central System SHALL support at least the following four cipher suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384</td></tr><tr><td>A00.FR.422</td><td></td><td>The Charge Point SHALL support at least the cipher suites: (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 AND TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384) OR (TLS_RSA_WITH_AES_128_GCM_SHA256 AND TLS_RSA_WITH_AES_256_GCM_SHA384) OR When the Charge Point supports only TLS v1.0/1.1: TLS_RSA_WITH_AES_128_CBC_SHA Note: TLS_RSA does not support forward secrecy, therefore TLS_ECDHE is preferred. Furthermore, if the Charge Point detects an algorithm used that is not secure, it SHOULD trigger an InvalidTLSCipherSuite security event.</td></tr><tr><td>A00.FR.423</td><td></td><td>The Charge Point and Central System SHALL NOT use cipher suites that use cryptographic primitives marked as unsuitable for legacy use in [1]. This will mean that when one (or more) of the cipher suites described in this specification becomes marked as unsuitable for legacy use, it SHALL NOT be used anymore.</td></tr><tr><td>A00.FR.424</td><td></td><td>The TLS Server and Client SHALL NOT use TLS compression methods to avoid compression side-channel attacks and to ensure interoperability as described in Section 6 of [4].</td></tr><tr><td>A00.FR.425</td><td>A00.FR.424 AND If the Central System detects that the Charge Point only allows connections using one of these suites</td><td>The Central System SHALL terminate the connection.</td></tr><tr><td>A00.FR.426</td><td>A00.FR.424 AND The Charge Point detects that the Central System only allows connections using one of these suites</td><td>The Charge Point SHALL trigger an InvalidTLSCipherSuite security event AND terminate the connection.</td></tr><tr><td>A00.FR.427</td><td></td><td>A unique Charge Point certificate SHALL be used for each Charge Point.</td></tr><tr><td>A00.FR.428</td><td>When the Central System expects Charge Points with only TLS v1.0/1.1 support</td><td>The Central System SHOULD support the cypher suite: TLS_RSA_WITH_AES_128_CBC_SHA only for TLS v1.0/1.1 connections.</td></tr><tr><td>A00.FR.429</td><td>When Charge Point supports Security Profile 3</td><td>The manufacturer is required to give every Charge Point a unique Serial Number.</td></tr></table>
+
+# 2.6. Keys used in OCPP
+
+OCPP uses a number of public private key pairs for its security, see below Table. To manage the keys on the Charge Point, messages have been added to OCPP. Updating keys on the Central System or at the manufacturer is out of scope for OCPP. If TLS with Client Side certificates is used, the Charge Point requires a "Charge Point certificate" for authentication against the Central System.
+
+Table 10. Certificates used in the OCPP security specification
+
+<table><tr><td>CERTIFICATE</td><td>PRIVATE KEY STORED AT</td><td>DESCRIPTION</td></tr><tr><td>Central System Certificate</td><td>Central System</td><td>Key used to authenticate the Central System.</td></tr><tr><td>Central System Root Certificate</td><td>Central System</td><td>Certificate used to authenticate the Central System.</td></tr><tr><td>Charge Point Certificate</td><td>Charge Point</td><td>Key used to authenticate the Charge Point.</td></tr><tr><td>Firmware Signing Certificate</td><td>Manufacturer</td><td>Key used to verify the firmware signature.</td></tr><tr><td>Manufacturer Root Certificate</td><td>Manufacturer</td><td>Root certificate for verification of the Manufacturer certificate.</td></tr></table>
+
+# 2.6.1. Certificate Properties
+
+Table 11. Certificate Properties requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A00.FR.501</td><td></td><td>All certificates SHALL use a private key that provides security equivalent to a symmetric key of at least 112 bits according to Section 5.6.1 of [7]. This is the key size that NIST recommends for the period 2011-2030.</td></tr><tr><td>A00.FR.502</td><td>A00.FR.501ANDRSA or DSA</td><td>This translates into a key that SHALL be at least 2048 bits long.</td></tr><tr><td>A00.FR.503</td><td>A00.FR.501ANDelliptic curve cryptography</td><td>This translates into a key that SHALL be at least 224 bits long.</td></tr><tr><td>A00.FR.504</td><td></td><td>For all cryptographic operations, only the algorithms recommended by BSI in [5], which are suitable for use in future systems, SHALL be used. This restriction includes the signing of certificates in the certificate hierarchy</td></tr><tr><td>A00.FR.505</td><td></td><td>For signing by the certificate authority RSA-PSS, or ECDSA SHOULD be used.</td></tr><tr><td>A00.FR.506</td><td></td><td>For computing hash values the SHA256 algorithm SHOULD be used.</td></tr><tr><td>A00.FR.507</td><td></td><td>The certificates SHALL be stored and transmitted in the X.509 format encoded in Privacy-Enhanced Mail (PEM) format.</td></tr><tr><td>A00.FR.508</td><td></td><td>All certificates SHALL include a serial number.</td></tr><tr><td>A00.FR.509</td><td></td><td>The subject field of the certificate SHALL contain the organization name of the certificate owner in the O (organizationName) RDN.</td></tr><tr><td>A00.FR.510</td><td></td><td>For the Central System certificate, the subject field SHALL contain the Fully Qualified Domain Name (FQDN) of the server in the CN (commonName) RDN</td></tr><tr><td>A00.FR.511</td><td></td><td>For the Charge Point certificate, the subject field SHALL contain a CN (commonName) RDN which consists of the unique serial number of the Charge Point. This serial number SHALL NOT be in the format of a URL or an IP address so that Charge Point certificates can be differentiated from Central System certificates.
+Note: According to RFC 2818 [12], if a subjectAltName extension of type dnsName is present, that must be used as the identity. This would be incompliant with OCPP. Therefore it SHOULD NOT be used in Charge Point and Central System certificates.
+It is allowed to use the subjectAltName extension of type dnsName for a Central System, when the Central System has multiple network paths to reached it. (for example, via a private APN + VPN using its IP address in the VPN and via public Internet using a named URL)</td></tr><tr><td>A00.FR.512</td><td></td><td>For all certificates the X.509 Key Usage extension [9] SHOULD be used to restrict the usage of the certificate to the operations for which it will be used.</td></tr></table>
+
+# 2.6.2. Certificate Hierarchy
+
+This White Paper adds support for the use of two separate certificate hierarchies:
+
+1. The Charge Point Operator hierarchy which contains the Central System, and Charge Point certificates.
+2. The Manufacturer hierarchy which contains the Firmware Signing certificate.
+
+The Central System can update the CPO root certificates stored on the Charge Point using the InstallCertificate.req message.
+
+Table 12. Certificate Hierarchy requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A00.FR.601</td><td></td><td>The Charge Point Operator MAY act as a certificate authority for the Charge Point Operator hierarchy</td></tr><tr><td>A00.FR.602</td><td></td><td>The private keys belonging to the CPO root certificates MUST be well protected.</td></tr><tr><td>A00.FR.603</td><td></td><td>As the Manufacturer is usually a separate organization from the Charge Point Operator, a trusted third party SHOULD be used as a certificate authority. This is essential to have non-repudiation of firmware images.</td></tr></table>
+
+# 2.6.3. Certificate Revocation
+
+In some cases a certificate may become invalid prior to the expiration of the validity period. Such cases include changes of the organization name, or the compromise or suspected compromise of the certificate's private key. In such cases, the certificate needs to be revoked or indicate it is no longer valid. The revocation of the certificate does not mean that the connection needs to be closed as the the connection can stay open longer than 24 hours.
+
+Different methods are recommended for certificate revocation, see below Table.
+
+Table 13. Recommended revocation methods for the different certificates.
+
+<table><tr><td>CERTIFICATE</td><td>REVOCATION</td></tr><tr><td>Central System certificate</td><td>Fast expiration</td></tr><tr><td>Charge Point certificate</td><td>Online verification</td></tr><tr><td>Firmware Signing certificate</td><td>Online verification</td></tr></table>
+
+Table 14. Certificate Revocation requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A00.FR.701</td><td></td><td>Fast expiration SHOULD be used to revoke the Central System certificate. (See Note 1)</td></tr><tr><td>A00.FR.702</td><td></td><td>The Central System SHOULD use online certificate verification to verify the validity of the Charge Point certificates.</td></tr><tr><td>A00.FR.703</td><td></td><td>It is RECOMMENDED that a separate certificate authority server is used to manage the certificates.</td></tr><tr><td>A00.FR.704</td><td></td><td>The Central System SHALL verify the validity of the certificate with the certificate authority server. (See Note 2)</td></tr><tr><td>A00.FR.706</td><td></td><td>Prior to providing the certificate for firmware validation to the Charge Point, the Central System SHOULD validate both, the certificate and the signed firmware update.</td></tr></table>
+
+Note 1: With fast expiration, the certificate is only valid for a short period, less than 24 hours. After that the server needs to request a new certificate from the Certificate Authority, which may be the CPO itself (see section Certificate Hierarchy). This prevents the Charge Points from needing to implement revocation lists or online certificate verification. This simplifies the implementation of certificate management at the Charge Point and reduces communication costs at the Charge Point side. By requiring fast expiration, if the certificate is compromised, the impact is reduced to only a short period.
+
+When the certificate chain should become compromised, attackers could used forged certificates to trick a Charge Point to connect to a "fake" Central System. By using fast expiration, the time a Charge Point is vulnerable is greatly reduced.
+
+The Charge Point always communicates with the Certificate Authority through the Central System, this way, if the Charge Points is compromised, the Charge Point cannot attack the CA directly.
+
+Note 2: This allows for immediate revocation of Charge Point certificates. Revocation of Charge Point certificates will happen for instance when a Charge Point is removed. This is more common than revoking the Central System certificate, which is normally only done when it is compromised.
+
+Note 3: It is best practice for any certificate authority server to keep track of revoked certificates.
+
+# 2.6.4. Installation during manufacturing or installation.
+
+Unique credentials should be used to authenticate each Charge Point to the Central System, whether they are the password used for HTTP Basic Authentication (see Charge Point Authentication) or the Charge Point certificate. These unique credentials have to be put on the Charge Point at some point during manufacturing or installation.
+
+Table 15. Certificate Installation requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A00.FR.801</td><td></td><td>It is RECOMMENDED that the manufacturer initializes the Charge Point with unique credentials during manufacturing.</td></tr><tr><td>A00.FR.802</td><td>A00.FR.801</td><td>The credentials SHOULD be generated using a cryptographic random number generator, and installed in a secure environment.</td></tr><tr><td>A00.FR.803</td><td>A00.FR.801</td><td>The information needed by the CPO to validate the Charge Point credentials SHOULD be sent to the CPO over a secure channel, so that the CPO can import them in the Central System. For example the password. The Certificate Private key is not needed by the CPO and SHOULD NOT be provided to the CPO.</td></tr><tr><td>A00.FR.804</td><td>If Charge Point certificates are used.</td><td>The manufacturer MAY sign these using their own certificate.</td></tr><tr><td>A00.FR.805</td><td>A00.FR.804</td><td>It is RECOMMENDED that the CPO immediately updates the credentials after installation using the methods described in Section A01 - Update Charge Point Password for HTTP Basic Authentication or A02 - Update Charge Point Certificate by request of the Central System.</td></tr><tr><td>A00.FR.806</td><td>Before the 'factory credentials' have been updated</td><td>The Central System MAY restrict the functionality that the Charge Point can use. The Central System can use the BootNotification state: Pending for this. During the Pending state, the Central System can update the credentials.</td></tr></table>
+
+# A01 - Update Charge Point Password for HTTP Basic Authentication
+
+Table 16. A01 - Password Management
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>Update Charge Point Password for HTTP Basic Authentication</td></tr><tr><td>2</td><td>ID</td><td>A01 (OCPP 2.0.1)</td></tr><tr><td>3</td><td>Objective(s)</td><td>This use case defines how to use the authorizationKey, the password used to authenticate Charge Points in the Basic and TLS with Basic Authentication security profiles.</td></tr><tr><td>4</td><td>Description</td><td>To enable the Central System to configure a new password for HTTP Basic Authentication, the Central System can send a new value for the AuthorizationKey Configuration Key.</td></tr><tr><td></td><td>Actors</td><td>Charge Point, Central System</td></tr><tr><td></td><td>Scenario description</td><td>1. The Central System sends a ChangeConfiguration.req(key = AuthorizationKey) to the Charge Point with the AuthorizationKey Configuration Key.
+2. The Charge Point responds with ChangeConfiguration.conf and the status Accepted.
+3. The Charge Point disconnects it current connection. (Storing any queued messages)
+4. The Charge Point connects to the Central System with the new password.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Security Profile: Basic Security Profile or TLS with Basic Authentication in use.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charge Point has reconnected to the Central System with the new password.
+Failure postcondition:
+If the Charge Point responds to the ChangeConfiguration.req with a ChangeConfiguration.req with a status other than Accepted, the Charge Point will keep using the old credentials. The Central System might treat the Charge Point differently, e.g. by not accepting the Charge Point's boot notifications.</td></tr></table>
+
+
+Figure 4. Update Charge Point Password for HTTP Basic Authentication (happy flow)
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# A01 - Update Charge Point Password for HTTP Basic Authentication - Requirements
+
+Table 17. A01 - Update Charge Point Password for HTTP Basic Authentication - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A01.FR.01</td><td></td><td>The Charge Point SHALL store the password in the configuration key AuthorizationKey.</td></tr></table>
+
+Table 18. A02 - Update Charge Point Certificate by request of Central System
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A01.FR.02</td><td></td><td>To set a Charge Point's authorization key via OCPP, the Central System SHALL send the Charge Point a ChangeConfiguration.req message with the AuthorizationKey Configuration Key.</td></tr><tr><td>A01.FR.03</td><td>A01.FR.02 AND The Charge Point responds to this ChangeConfiguration.req with a ChangeConfiguration.conf with status Accepted.</td><td>The Central System SHALL assume that the authorization key change was successful, and no longer accept the credentials previously used by the Charge Point.</td></tr><tr><td>A01.FR.04</td><td>A01.FR.02 AND The Charge Point responds to this ChangeConfiguration.req with a ChangeConfiguration.conf with status Rejected or NotSupported.</td><td>The Central System SHALL assume that the Charge Point has NOT changed the password. Therefore the Central System SHALL keep accepting the old credentials.</td></tr><tr><td>A01.FR.05</td><td>A01.FR.04</td><td>While the Central System SHALL still accepts a connection from the Charge Point, it MAY restrict the functionality that the Charge Point can use. The Central System can use the BootNotification state: Pending for this. During the Pending state, the Central System can for example retry to update the credentials.</td></tr><tr><td>A01.FR.06</td><td></td><td>Different passwords SHOULD be used for different Charge Points.</td></tr><tr><td>A01.FR.07</td><td></td><td>Passwords SHOULD be generated randomly to ensure that the passwords have sufficient entropy.</td></tr><tr><td>A01.FR.08</td><td></td><td>the Central System SHOULD only store salted password hashes, not the passwords themselves.</td></tr><tr><td>A01.FR.09</td><td></td><td>the Central System SHOULD NOT put the passwords in clear-text in log files or debug information. In this way, if the Central System is compromised not all Charge Point password will be immediately compromised.</td></tr><tr><td>A01.FR.10</td><td></td><td>On the Charge Point the password needs to be stored in clear-text. Extra care SHOULD be taken into storing it securely. Definitions of mechanisms how to securely store the credentials are however not in scope of the OCPP Security Profiles.</td></tr><tr><td>A01.FR.11</td><td>A01.FR.02</td><td>The Charge Point SHALL log the change of AuthorizationKey in the Security log.</td></tr><tr><td>A01.FR.12</td><td>A01.FR.11</td><td>The Charge Point SHALL NOT disclose the content of the AuthorizationKey in its logging. This is to prevent exposure of key material to persons that may have access to a diagnostics file.</td></tr></table>
+
+# A02 - Update Charge Point Certificate by request of Central System
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>Update Charge Point Certificate by request of Central System</td></tr><tr><td>2</td><td>ID</td><td>A02 (OCPP 2.0.1)</td></tr><tr><td>3</td><td>Objective(s)</td><td>To facilitate the management of the Charge Point client side certificate, a certificate update procedure is provided.</td></tr><tr><td>4</td><td>Description</td><td>The Central System requests the Charge Point to update its key using ExtendedTriggerMessage.req(SignChargePointCertificate).</td></tr><tr><td></td><td>Actors</td><td>Charge Point, Central System, Certificate Authority Server</td></tr><tr><td></td><td>Scenario description</td><td>1. The Central System requests the Charge Point to update its certificate using the ExtendedTriggerMessage.req(SignChargePointCertificate) message.
+2. The Charge Point responds with ExtendedTriggerMessage.conf
+3. The Charge Point generates a new public / private key pair.
+4. The Charge Point sends a SignCertificate.req to the Central System.
+5. The Central System responds with SignCertificate.conf, with status Accepted.
+6. The Central System 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 Central System.
+9. The Central System sends CertificateSigned.req to the Charge Point.
+10. The Charge Point verifies the Signed Certificate.
+11. The Charge Point responds with h to the Central System with the status Accepted or Rejected.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The configuration variable CpoName MUST be set.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+New Client Side certificate installed in the Charge Point.
+Failure postcondition:
+New Client Side certificate is rejected and discarded.</td></tr></table>
+
+
+Figure 5. Update Charge Point Certificate
+
+<table><tr><td>7</td><td>Error handling</td><td>The Central System accepts the CSR request from the Charge Point, before forwarding it to the CA. But when the CA cannot be reached, or rejects the CSR, the Charge Point will never known. The Central System may do some checks on the CSR, but cannot do all the checks that a CA does, and it does not prevent connection timeout to the CA. When something like this goes wrong, either the CA is offline or the CSR send by the Charge Point is not correct, according to the CA. In both cases this is something an operator at the CPO needs to be notified of. The operator then needs to investigate the issue. When resolved, the operator can re-run A02. It is NOT RECOMMENDED to let the Charge Point retry when the certificate is not send within X minutes or hours. When the CSR is incorrect, that will not be resolved automatically. It is possible that only a new firmware will fix this.</td></tr><tr><td>8</td><td>Remark(s)</td><td>The CPO may act as a Certification Authority, so the CA Server may be a local server.
+The applicable Certification Authority SHALL check the information in the CSR.
+If it is correct, the Certificate Authority SHALL sign the CSR, send it to the CPO, the CPO sends it back to the Charge Point in the CertificateSigned.req message
+The certificate authority SHOULD implement strong measures to keep the certificate signing private keys secure.
+Even though the messages CertificateSigned.req (see use cases A02 and A03) and InstallCertificate.req (use case M05 - Install CA Certificate in a Charge Point) are both used to send certificates, their purposes are different.
+CertificateSigned.req is used to return the the Charge Points own public certificate signed by a Certificate Authority. InstallCertificate.req is used to install Root certificates.
+For (Sub-)CA certificate handling see use cases M03 - Retrieve list of available certificates from a Charge Point, M04 - Delete a specific certificate from a Charge Point, M05 - Install CA certificate in a Charge Point.</td></tr></table>
+
+# A02 - Update Charge Point Certificate by request of Central System - Requirements
+
+Table 19. A02 - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A02.FR.01</td><td></td><td>A key update SHOULD be performed after installation of the Charge Point, to change the key from the one initially provisioned by the manufacturer (possibly a default key).</td></tr><tr><td>A02.FR.02</td><td>After sending a ExtendedTriggerMessage.conf.</td><td>The Charge Point SHALL generate a new public / private key pair using one of the key generation functions described in Section 4.2.1.3 of [6].</td></tr><tr><td>A02.FR.03</td><td>A02.FR.02</td><td>The Charge Point SHALL send the public key in form of a Certificate Signing Request (CSR) as described in RFC 2986 [14] and then PEM encoded, using the SignCertificate.req message.</td></tr><tr><td>A02.FR.04</td><td></td><td>The Central System SHOULD NOT sign the certificate itself, but instead forwards the CSR to a dedicated certificate authority server managing the certificates for the Charge Point infrastructure. The dedicated authority server MAY be operated by the CPO.</td></tr><tr><td>A02.FR.05</td><td></td><td>The private key generated by the Charge Point during the key update process SHALL NOT leave the Charge Point at any time, and SHALL NOT be readable via OCPP or any other (remote) communication connection.</td></tr><tr><td>A02.FR.06</td><td></td><td>The Charge Point SHALL verify the validity of the signed certificate in the CertificateSigned.req message, checking at least the period when the certificate is valid, the properties in Certificate Properties, and that it is part of the Charge Point Operator certificate hierarchy as described in Certificate Hierarchy.</td></tr><tr><td>A02.FR.07</td><td>If the certificate is not valid.</td><td>The Charge Point SHALL discard the certificate, and trigger an InvalidChargePointCertificate security event.</td></tr><tr><td>A02.FR.08</td><td></td><td>The Charge Point SHALL switch to the new certificate as soon as the current date and time is after the 'Not valid before' field in the certificate.</td></tr><tr><td>A02.FR.09</td><td>If the Charge Point contains more than one valid certificate of the same type.</td><td>The Charge Point SHALL use the newest certificate, as measured by the start of the validity period.</td></tr><tr><td>A02.FR.10</td><td>When the Charge Point has validated that the new certificate works</td><td>The Charge Point MAY discard the old certificate. It is RECOMMENDED to store old certificates for one month, as fallback.</td></tr><tr><td>A02.FR.11</td><td>Upon receipt of a SignCertificate.req AND It is able to process the request</td><td>The Central System SHALL set status to Accepted in the SignCertificate.conf.</td></tr><tr><td>A02.FR.12</td><td>Upon receipt of a SignCertificate.req AND It is NOT able to process the request</td><td>The Central System SHALL set status to Rejected in the SignCertificate.conf.</td></tr><tr><td>A02.FR.13</td><td>A02.FR.03</td><td>The Charge Point SHALL put the value of the CpoName configuration key in the organizationName (O) RDN in the CSR subject field.</td></tr></table>
+
+# A03 - Update Charge Point Certificate initiated by the Charge Point
+
+Table 20. A03 - Update Charge Point Certificate initiated by the Charge Point
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>Update Charge Point Certificate initiated by the Charge Point</td></tr><tr><td>2</td><td>ID</td><td>A03 (OCPP 2.0.1)</td></tr><tr><td>3</td><td>Objective(s)</td><td>To facilitate the management of the Charge Point client side certificate, a certificate update procedure is provided.</td></tr><tr><td>4</td><td>Description</td><td>The Charge Point detects that the 'Charge Point Certificate' it is using will expire in one month. The Charge Point initiates the process to update its key using SignCertificate.req.</td></tr><tr><td></td><td>Actors</td><td>Charge Point, Central System, Certificate Authority Server</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charge Point detects that the Charge Point certificate is due to expire.
+2. The Charge Point generates a new public / private key pair.
+3. The Charge Point sends a SignCertificate.req to the Central System.
+4. The Central System responds with a SignCertificate.conf, with status Accepted.
+5. The Central System forwards the CSR to the Certificate Authority Server.
+6. Certificate Authority Server signs the certificate.
+7. The Certificate Authority Server returns the Signed Certificate to the Central System.
+8. The Central System sends a CertificateSigned.req to the Charge Point.
+9. The Charge Point verifies the Signed Certificate.
+10. The Charge Point responds with a CertificateSigned.conf to the Central System with the status Accepted or Rejected.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The configuration variable CpoName MUST be set.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+New Client Side certificate installed in the Charge Point.
+Failure postcondition:
+New Client Side certificate is rejected and discarded.</td></tr></table>
+
+
+Figure 6. Update Charge Point Certificate initiated by Charge Point
+
+<table><tr><td>7</td><td>Error handling</td><td>The Central System accepts the CSR request from the Charge Point, before forwarding it to the CA. But when the CA cannot be reached, or rejects the CSR, the Charge Point will never known. The Central System may do some checks on the CSR, but cannot do all the checks that a CA does, and it does not prevent connection timeout to the CA. When something like this goes wrong, either the CA is offline or the CSR send by the Charge Point is not correct, according to the CA. In both cases this is something an operator at the CPO needs to be notified of. The operator then needs to investigate the issue. When resolved, the operator can re-run A02. It is NOT RECOMMENDED to let the Charge Point retry when the certificate is not send within X minutes or hours. When the CSR is incorrect, that will not be resolved automatically. It is possible that only a new firmware will fix this.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Same remarks as in A02 - Update Charge Point Certificate by request of Central System apply.</td></tr></table>
+
+# A03 - Update Charge Point Certificate initiated by the Charge Point - Requirements
+
+Table 21. A03 - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A03.FR.01</td><td></td><td>A key update MAY be performed after installation of the Charge Point, to change the key from the one initially provisioned by the manufacturer (possibly a default key).</td></tr><tr><td>A03.FR.02</td><td>When the Charge Point detects that the current Charge Point certificate will expire in one month.</td><td>The Charge Point SHALL generate a new public / private key pair using one of the key generation functions described in Section 4.2.1.3 of [6].</td></tr><tr><td>A03.FR.03</td><td>A03.FR.02</td><td>The Charge Point SHALL send the public key in form of a Certificate Signing Request (CSR) as described in RFC 2986 [14] and then PEM encoded, using the SignCertificate.req message.</td></tr><tr><td>A03.FR.04</td><td></td><td>The Central System SHOULD NOT sign the certificate itself, but instead forwards the CSR to a dedicated certificate authority server managing the certificates for the Charge Point infrastructure. The dedicated authority server MAY be operated by the CPO.</td></tr><tr><td>A03.FR.05</td><td></td><td>The private key generated by the Charge Point during the key update process SHALL NOT leave the Charge Point at any time, and SHALL NOT be readable via OCPP or any other (remote) communication connection.</td></tr><tr><td>A03.FR.06</td><td></td><td>The Charge Point SHALL verify the validity of the signed certificate in the CertificateSigned.req message, checking at least the period when the certificate is valid, the properties in Certificate Properties, and that it is part of the Charge Point Operator certificate hierarchy as described in Certificate Hierarchy.</td></tr><tr><td>A03.FR.07</td><td>If the certificate is not valid.</td><td>The Charge Point SHALL discard the certificate, and trigger an InvalidChargePointCertificate security event.</td></tr><tr><td>A03.FR.08</td><td></td><td>The Charge Point SHALL switch to the new certificate as soon as the current date and time is after the 'Not valid before' field in the certificate.</td></tr><tr><td>A03.FR.09</td><td>If the Charge Point contains more than one valid certificate of the same type.</td><td>The Charge Point SHALL use the newest certificate, as measured by the start of the validity period.</td></tr><tr><td>A03.FR.10</td><td>When the Charge Point has validated that the new certificate works</td><td>The Charge Point MAY discard the old certificate. It is RECOMMENDED to store old certificates for one month, as fallback.</td></tr><tr><td>A03.FR.11</td><td>Upon receipt of a SignCertificate.req AND It is able to process the request</td><td>The Central System SHALL set status to Accepted in the SignCertificate.conf.</td></tr><tr><td>A03.FR.12</td><td>Upon receipt of a SignCertificate.req AND It is NOT able to process the request</td><td>The Central System SHALL set status to Rejected in the SignCertificate.conf.</td></tr><tr><td>A03.FR.13</td><td>A03.FR.03</td><td>The Charge Point SHALL put the value of CpoName in the organizationName RDN in the CSR subject field.</td></tr></table>
+
+# A05 - Upgrade Charge Point Security Profile
+
+Table 22. A05 - Upgrade Charge Point Security Profile
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>Upgrade Charge Point Security Profile</td></tr><tr><td>2</td><td>ID</td><td>A05 (OCPP 2.0.1)</td></tr><tr><td>3</td><td>Objective(s)</td><td>Upgrade the security profile used by a Charge Point to a higher profile.</td></tr><tr><td>4</td><td>Description</td><td>The CPO wants to increase the security of the OCPP connection between Central System and a Charge Point. This use case is especially relevant when migrating from OCPP 1.6 without security profiles to OCPP 1.6 with security profiles, before migrating to a security profile the prerequisites, like installed certificates or password need to be configured. The CPO ensures the prerequisite(s) for going to a higher security certificates are met before sending the command to change to a higher security profile. the Charge Point reconnects to the Central System using the higher security profile.</td></tr><tr><td></td><td>Actors</td><td>Charge Point, Central System, CPO</td></tr><tr><td></td><td>Scenario description</td><td>1. CPO command the Central System to upgrade a Charge Point to a higher Security Profile.2. The Central System sends a ChangeConfiguration.req for configuration key: SecurityProfile with a new (higher) value to the Charge Point.3. The Charge Point checks all the prerequisites for the new Security Profile.4. The Charge Point responds with ChangeConfiguration.conf.5. The Charge Point disconnects it's current connection the Central System. 6. The Charge Point connects to the Central System using the new Security Profile.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Configuration Key: SecurityProfile available.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The Charge Point is using the higher security profile.Failure postcondition:The Charge Point is NOT using the higher security profile.</td></tr></table>
+
+
+Figure 7. Upgrade Charge Point Certificate initiated by Charge Point
+
+<table><tr><td>7</td><td>Error handling</td><td>If the Charge Point is unable to connect to the Central System using the configured (higher) security profile, it SHOULD fallback to its previous security profile settings. This is to prevent that the Charge Point will become unable to reconnect to the Central System on its own.</td></tr><tr><td>8</td><td>Remark(s)</td><td>For security reasons it is not allowed to change to a lower Security Profile over OCPP.</td></tr></table>
+
+# A05 - Upgrade Charge Point Security Profile - Requirements
+
+Table 23. A05 - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>A05.FR.01</td><td>Charge Point receives ChangeConfiguration.req for SecurityProfile with a value lower or equal to the current value.</td><td>The Charge Point SHALL respond with ChangeConfiguration.conf(Rejected), and not change the value for SecurityProfile and/or reconnect to the Central System.</td></tr><tr><td>A05.FR.02</td><td>Charge Point receives ChangeConfiguration.req for SecurityProfile with a value higher than the current value AND new value is 1 or 2 AND configuration key: AuthorizationKey does not contain a value (that meets the requirements for AuthorizationKey)</td><td>The Charge Point SHALL respond with ChangeConfiguration.conf(Rejected), and not change the value for SecurityProfile and/or reconnect to the Central System.</td></tr><tr><td>A05.FR.03</td><td>Charge Point receives ChangeConfiguration.req for SecurityProfile with a value higher then the current value AND new value is 2 or 3 AND No valid CentralSystemRootCertificate installed</td><td>The Charge Point SHALL respond with ChangeConfiguration.conf(Rejected), and not change the value for SecurityProfile and/or reconnect to the Central System.</td></tr><tr><td>A05.FR.04</td><td>Charge Point receives ChangeConfiguration.req for SecurityProfile with a value higher then the current value AND new value is 3 AND No valid ChargePointCertificate installed</td><td>The Charge Point SHALL respond with ChangeConfiguration.conf(Rejected), and not change the value for SecurityProfile and/or reconnect to the Central System.</td></tr><tr><td>A05.FR.05</td><td>Charge Point receives ChangeConfiguration.req for SecurityProfile with a value higher then the current value AND all prerequisites are met</td><td>The Charge Point SHALL respond with ChangeConfiguration.conf(Accepted)</td></tr><tr><td>A05.FR.06</td><td>A05.FR.05</td><td>The Charge Point SHALL disconnect from the Central System</td></tr><tr><td>A05.FR.07</td><td>A05.FR.06</td><td>The Charge Point SHALL reconnect the Central System with the new Security Profile</td></tr><tr><td>A05.FR.08</td><td>A05.FR.07 AND The Charge Point was unable to connect to the Central System</td><td>The Charge Point SHOULD fallback to its previous security profile setting.</td></tr><tr><td>A05.FR.09</td><td>A05.FR.07 AND
+The Charge Point was able to successfully connect to the Central System</td><td>The Central System SHALL NOT allow the Charge Point to connect with a lower security profile anymore.</td></tr></table>
+
+# M03 - Retrieve list of available certificates from a Charge Point
+
+Table 24. M03 - Retrieve list of available certificates from a Charge Point
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>Retrieve list of available certificates from a Charge Point</td></tr><tr><td>2</td><td>ID</td><td>M03 (OCPP 2.0.1)</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Central System to retrieve a list of available certificates from a Charge Point.</td></tr><tr><td>4</td><td>Description</td><td>To facilitate the management of the Charge Point's installed certificates, a method of retrieving the installed certificates is provided. The Central System requests the Charge Point to send a list of installed certificates</td></tr><tr><td></td><td>Actors</td><td>Charge Point, Central System</td></tr><tr><td></td><td>Scenario description</td><td>1. The Central System requests the Charge Point to send a list of installed certificates by sending a GetInstalledCertificates.req
+2. The Charge Point responds with a GetInstalledCertificates.conf</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Central System received a list of installed certificates</td></tr></table>
+
+
+Figure 8. Retrieve list of available certificates from a Charge Point
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>For installing the Charge Point Certificate, see use cases A02 - Update Charge Point Certificate by request of Central System and A03 - Update Charge Point Certificate initiated by the Charge Point.</td></tr></table>
+
+# M03 - Retrieve list of available certificates from a Charge Point - Requirements
+
+Table 25. M03 - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>M03.FR.01</td><td>After receiving a GetInstalledCertificates.req</td><td>The Charge Point SHALL respond with a GetInstalledCertificates.conf.</td></tr><tr><td>M03.FR.02</td><td>M03.FR.01 AND No certificate matching certificateType was found</td><td>The Charge Point SHALL indicate this by setting status in the GetInstalledCertificates.conf to NotFound.</td></tr><tr><td>M03.FR.03</td><td>M03.FR.01 AND A certificate matching certificateType was found</td><td>The Charge Point SHALL indicate this by setting status in the GetInstalledCertificates.conf to Accepted.</td></tr><tr><td>M03.FR.04</td><td>M03.FR.03</td><td>The Charge Point SHALL include the hash data for each matching installed certificate in the GetInstalledCertificates.conf.</td></tr></table>
+
+# M04 - Delete a specific certificate from a Charge Point
+
+Table 26. M04 - Delete a specific certificate from a Charge Point
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>Delete a specific certificate from a Charge Point</td></tr><tr><td>2</td><td>ID</td><td>M04 (OCPP 2.0.1)</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Central System to request the Charge Point to delete an installed certificate.</td></tr><tr><td>4</td><td>Description</td><td>To facilitate the management of the Charge Point's installed certificates, a method of deleting an installed certificate is provided. The Central System requests the Charge Point to delete a specific certificate.</td></tr><tr><td></td><td>Actors</td><td>Charge Point, Central System</td></tr><tr><td></td><td>Scenario description</td><td>1. The Central System requests the Charge Point to delete an installed certificate by sending a DeleteCertificate.req.
+2. The Charge Point responds with a DeleteCertificate.conf.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The requested certificate was deleted from the Charge Point.</td></tr></table>
+
+
+
+Figure 9. Delete Installed Certificate
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>For installing the Charge Point Certificate, see use cases A02 - Update Charge Point Certificate by request of Central System and A03 - Update Charge Point Certificate initiated by the Charge Point.
+It is possible to delete the last (every) installed CentralSystemRootCertificates, when all CentralSystemRootCertificates are deleted, the Charge Point cannot validate Central System Certificates, so it will not be able to connect to a Central System.
+Before a Central System would ever send a DeleteCertificate.req that would delete the last/all CentralSystemRootCertificates the Central System is ADVICED to make very sure that this is what is really wanted.
+It is possible to delete the last (every) installed ManufacturerRootCertificates, when all ManufacturerRootCertificates are deleted, no "Signed Firmware" can be installed in the Charge Point.</td></tr></table>
+
+# M04 - Delete a specific certificate from a Charge Point - Requirements
+
+Table 27. M04 - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>M04.FR.01</td><td>After receiving a DeleteCertificate.req</td><td>The Charge Point SHALL respond with a DeleteCertificate.conf.</td></tr><tr><td>M04.FR.02</td><td>M04.FR.01 AND The requested certificate was found</td><td>The Charge Point SHALL delete it, and indicate success by setting 'status' to 'Success' in the DeleteCertificate.conf.</td></tr><tr><td>M04.FR.03</td><td>M04.FR.01 AND The deletion fails</td><td>The Charge Point SHALL indicate failure by setting 'status' to 'Failed' in the DeleteCertificate.conf.</td></tr><tr><td>M04.FR.04</td><td>M04.FR.01 AND The requested certificate was not found</td><td>The Charge Point SHALL indicate failure by setting 'status' to 'NotFound' in the DeleteCertificate.conf.</td></tr><tr><td>M04.FR.05</td><td></td><td>Deletion of the Charge Point Certificate SHALL NOT be possible via a DeleteCertificate.req.</td></tr><tr><td>M04.FR.06</td><td>M04.FR.01 AND Certificate to delete is a CentralSystemRootCertificate AND This CentralSystemRootCertificate is currently in use for validation of the connection the the Central System</td><td>The Charge Point SHALL reject the request by setting 'status' to 'Failed' in the DeleteCertificate.conf.</td></tr><tr><td>M04.FR.07</td><td>When deleting a certificate</td><td>The Central System SHALL use the hashAlgorithm, which was used to install the certificate.</td></tr></table>
+
+# M05 - Install CA certificate in a Charge Point
+
+Table 28. M05 - Install CA certificate in a Charge Point
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>Install CA certificate in a Charge Point</td></tr><tr><td>2</td><td>ID</td><td>M05 (OCPP 2.0.1)</td></tr><tr><td>3</td><td>Objective(s)</td><td>To facilitate the management of the Charge Point's installed certificates, a method to install a new CA certificate.</td></tr><tr><td>4</td><td>Description</td><td>The Central System requests the Charge Point to install a new Central System root certificate or Manufacturer root certificate.</td></tr><tr><td></td><td>Actors</td><td>Charge Point, Central System</td></tr><tr><td></td><td>Scenario description</td><td>1. The Central System requests the Charge Point to install a new certificate by sending an InstallCertificate.req.
+2. The Charge Point responds with an InstallCertificate.conf.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The new certificate was installed in the Charge Point trust store.</td></tr></table>
+
+
+Figure 10. Install CA certificate in a Charge Point
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Even though the messages CertificateSigned.req (see use cases A02 - Update Charge Point Certificate by request of Central System and A03 - Update Charge Point Certificate initiated by the Charge Point) and InstallCertificate.req (use case M05) are both used to send certificates, their purposes are different. CertificateSigned.req is used to return the the Charge Points own public certificate signed by a Certificate Authority. InstallCertificate.req is used to install Root certificates.For installing the Charge Point Certificate, see use cases A02 - Update Charge Point Certificate by request of Central System and A03 - Update Charge Point Certificate initiated by the Charge Point.It is allowed to have multiple certificates of the same type installed.</td></tr></table>
+
+# M05 - Install CA certificate in a Charge Point - Requirements
+
+Table 29. M05 - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td></tr><tr><td>M05.FR.01</td><td>After receiving an InstallCertificate.req</td><td>The Charge Point SHALL attempt to install the certificate and respond with an InstallCertificate.conf.</td></tr><tr><td>M05.FR.02</td><td>M05.FR.01 AND The installation was successful</td><td>The Charge Point SHALL indicate success by setting 'status' to 'Accepted' in the InstallCertificate.conf.</td></tr><tr><td>M05.FR.03</td><td>M05.FR.01 AND Current amount of install certificates >= CertificateStoreMaxLength</td><td>The Charge Point SHALL indicate failure (no more space to install more certificates) by setting 'status' to 'Rejected' in the InstallCertificate.conf</td></tr><tr><td>M05.FR.04</td><td>M05.FR.01 AND The installation failed</td><td>The Charge Point SHALL indicate failure by setting 'status' to 'Failed' in the InstallCertificate.conf.</td></tr><tr><td>M05.FR.06</td><td>M05.FR.01 AND The certificate is invalid and/or incorrect.</td><td>The Charge Point SHALL indicate rejection by setting 'status' to 'Rejected' in the InstallCertificate.conf.</td></tr><tr><td>M05.FR.08</td><td>When AdditionalRootCertificateCheck is true</td><td>Only one certificate (plus a temporarily fallback certificate) of certificateType CentralSystemRootCertificate is allowed to be installed at a time.</td></tr><tr><td>M05.FR.09</td><td>When AdditionalRootCertificateCheck is true AND installing a new certificate of certificateType CentralSystemRootCertificate</td><td>The new Central System Root certificate SHALL replace the old Central System Root certificate AND the new Root Certificate MUST be signed by the old Root Certificate it is replacing</td></tr><tr><td>M05.FR.10</td><td>M05.FR.09 AND the new Central System Root certificate is NOT signed by the old Central System Root certificate</td><td>The Charge Point SHALL NOT install the new Central System Root Certificate and respond with status Rejected.</td></tr><tr><td>M05.FR.11</td><td>M05.FR.09 AND the new Central System Root certificate is signed by the old Central System Root certificate</td><td>The Charge Point SHALL install the new Central System Root Certificate AND temporarily keep the old Central System Root certificate as a fallback certificate AND respond with status Accepted</td></tr><tr><td>M05.FR.12</td><td>M05.FR.11 AND the Charge Point successfully connected to the Central System using the new Central System Root certificate</td><td>The Charge Point SHALL remove the old Central System Root (fallback) certificate.</td></tr><tr><td>M05.FR.13</td><td>M05.FR.11 AND The Charge Point is attempting to reconnect to the Central System, but determines that the server certificate provided by the Central System is invalid when using the new Central System Root certificate to verify it</td><td>The Charge Point SHALL try to use the old Central System Root ( fallback) certificate to verify the server certificate.</td></tr></table>
+
+# 3. Security events/logging
+
+# A04 - Security Event Notification
+
+Table 30. A04 - Security Event Notification
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>Security Event Notification</td></tr><tr><td>2</td><td>ID</td><td>A04 (OCPP 2.0.1)</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the Central System of critical security events.</td></tr><tr><td>4</td><td>Description</td><td>This use case allows the Charge Point to immediately inform the Central System of changes in the system security.</td></tr><tr><td></td><td>Actors</td><td>Central System, Charge Point</td></tr><tr><td></td><td>Scenario description</td><td>1. A critical security event happens.
+2. The Charge Point sends a SecurityEventNotification.req to the Central System.
+3. The Central System responds with SecurityEventNotification.conf to the Charge Point.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charge Point successfully informed the Central System of critical security events by sending a SecurityEventNotification.req to the Central System.</td></tr></table>
+
+
+Figure 11. Security Event Notification
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>A list of security related events and their 'criticality' is provided at Security Events</td></tr></table>
+
+# A04 - Security Event Notification - Requirements
+
+Table 31. A04 - Security Event Notification - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td><td>NOTE</td></tr><tr><td>A04.FR.01</td><td>When a critical security event happens</td><td>The Charge Point SHALL inform the Central System of the security events by sending a SecurityEventNotification.req, to the Central System.</td><td></td></tr><tr><td>A04.FR.02</td><td>A04.FR.01 AND the Charge Point is disconnected.</td><td>Security event notifications MUST be queued with a guaranteed delivery at the Central System.</td><td></td></tr><tr><td>A04.FR.03</td><td>A04.FR.01</td><td>The Central System SHALL confirm the receipt of the notification using the SecurityEventNotification.conf message.</td><td></td></tr><tr><td>A04.FR.04</td><td>When a security event happens (also none-critical)</td><td>The Charge Point SHALL store the security event in a security log.</td><td>It is recommended to implement this in a rolling format.</td></tr></table>
+
+# N01 - Retrieve Log Information
+
+Table 32. N01 - Retrieve Log Information
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>Retrieve Log</td></tr><tr><td>2</td><td>ID</td><td>N01 (OCPP 2.0.1)</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Central System retrieving of log information from a Charge Point.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers the functionality of getting log information from a Charge Point. The Central System can request a Charge Point to upload a file with log information to a given location (URL). The format of this log file is not prescribed. The Charge Point uploads a log file and gives information about the status of the upload by sending status notifications to the Central System.</td></tr><tr><td></td><td>Actors</td><td>Charge Point, Central System</td></tr><tr><td></td><td>Scenario description</td><td>1. The Central System sends a GetLog.req to the Charge Point.
+2. The Charge Point responds with a GetLog.conf.
+3. The Charge Point sends a LogStatusNotification.req with the status Uploading
+4. The Central System responds with a LogStatusNotification.conf acknowledging the status update request.
+5. Uploading of the diagnostics files.
+6. The Charge Point sends LogStatusNotification.req with the status Uploaded.
+7. The Central System responds with LogStatusNotification.conf, acknowledging the status update request.
+8. The Charge Point returns to Idle status.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>- Requested information (either DiagnosticsLog or SecurityLog) is available for upload.
+- URL to upload file to is reachable and exists.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+Log file Successfully uploaded.
+Failure postcondition:
+Log file not Successfully uploaded and Failed.</td></tr></table>
+
+
+Figure 12. Sequence Diagram: Get Security Log
+
+<table><tr><td>7</td><td>Error handling</td><td>When the upload fails, and the transfer protocol supports "resume", it is recommended that the Charge Point tries "resume" before aborting the upload.</td></tr><tr><td>8</td><td>Remark(s)</td><td>When a Charge Point is requested to upload a log file, the Central System supplies in the request an URL where the Charge Point SHALL upload the file. The URL also contains the protocol which must be used to upload the file.
+It is recommended that the log file is uploaded via FTP or FTPS. FTP(S) is better optimized for large binary data than HTTP. Also FTP(S) has the ability to resume uploads. In case an upload is interrupted, the Charge Point can resume uploading after the part it already has uploaded. The FTP URL is of format: ftp://User:password@host:port /path in which the parts User:password@, :password or :port may be excluded.
+The Charge Point has an optional Configuration Key that reports which file transfer protocols it supports:
+SupportedFileTransferProtocols.
+The format of the log file is not prescribed.
+FTP needs to be able to use Passive FTP, to be able to transverse over as much different typologies as possible.</td></tr></table>
+
+# N01 - Retrieve Log Information - Requirements
+
+Table 33. N01 - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td><td>NOTE</td></tr><tr><td>N01.FR.01</td><td>Upon receipt of a GetLog.req AND if the requested log information is available</td><td>The Charge Point SHALL respond with a GetLog.conf stating the name of the file and status Accepted.</td><td></td></tr><tr><td>N01.FR.02</td><td>N01.FR.01</td><td>The Charge Point SHALL start uploading a single log file to the specified location</td><td></td></tr><tr><td>N01.FR.03</td><td>N01.FR.02 AND The GetLog.req contained/logType SecurityLog</td><td>The Charge Point SHALL upload its security log</td><td></td></tr><tr><td>N01.FR.04</td><td>N01.FR.02 AND The GetLog.req contained/logType DiagnosticsLog</td><td>The Charge Point SHALL upload its diagnostics.</td><td></td></tr><tr><td>N01.FR.05</td><td>When a security event happens</td><td>The Charge Point SHALL log this event in its security log. See Section 8. Security Events for a list of security events.</td><td></td></tr><tr><td>N01.FR.07</td><td></td><td>Every LogStatusNotification.req that is sent for the upload of a specific log SHALL contain the same requestid as the GetLog.req that started this log upload.</td><td></td></tr><tr><td>N01.FR.08</td><td>When uploading a log document is started</td><td>The Charge Point SHALL send a LogStatusNotification.req with status Uploading.</td><td></td></tr><tr><td>N01.FR.09</td><td>When a log document is uploaded successfully</td><td>The Charge Point SHALL send a LogStatusNotification.req with status Uploaded.</td><td></td></tr><tr><td>N01.FR.10</td><td>When uploading a log document failed</td><td>The Charge Point SHALL send a LogStatusNotification.req with status UploadFailed, BadMessage, PermissionDenied OR NotSupportedOperation.</td><td>It is RECOMMENDED to send a status that describes the reason of failure as precise as possible.</td></tr><tr><td>N01.FR.11</td><td>When a Charge Point is uploading a log file AND the Charge Point receives a new GetLog.req</td><td>The Charge Point SHOULD cancel the ongoing log file upload AND respond with status AcceptedCanceled.</td><td></td></tr><tr><td>N01.FR.12</td><td></td><td>The field requestId in LogStatusNotification.req is mandatory, unless the message was triggered by an ExtendedTriggerMessage.req AND there is no log upload ongoing.</td><td></td></tr></table>
+
+# 4. Secure firmware update
+
+# L01 - Secure Firmware Update
+
+Table 34. L01 - Secure Firmware Update
+
+<table><tr><td>NO.</td><td>TYPE</td><td>DESCRIPTION</td></tr><tr><td>1</td><td>Name</td><td>Secure Firmware Update</td></tr><tr><td>2</td><td>ID</td><td>L01</td></tr><tr><td>3</td><td>Objective(s)</td><td>Download and install a Secure firmware update.</td></tr><tr><td>4</td><td>Description</td><td>Illustrate how a Charge Point processes a Secure firmware update.</td></tr><tr><td></td><td>Actors</td><td>Central System, Charge Point</td></tr><tr><td></td><td>Scenario description</td><td>1. The Central System sends a SignedUpdateFirmware.req message that contains the location of the firmware, the time after which it should be retrieved, and information on how many times the Charge Point should retry downloading the firmware.
+2. The Charge Point verifies the validity of the certificate against the Manufacturer root certificate.
+3. If the certificate is not valid or could not be verified, the Charge Point aborts the firmware update process and sends a SignedUpdateFirmware.conf with status InvalidCertificate (or status RevokedCertificate when the certificate has been revoked) and a SecurityEventNotification.req with the security event InvalidFirmwareSigningCertificate.
+If the certificate is valid, the Charge Point starts downloading the firmware, and sends a SignedFirmwareStatusNotification.req with status Downloading.
+4. If the Firmware successfully downloaded, the Charge Point sends a SignedFirmwareStatusNotification.req with status Downloaded.
+Otherwise, it sends a SignedFirmwareStatusNotification.req with status DownloadFailed.
+5. If the verification is successful, the Charge Point sends a SignedFirmwareStatusNotification.req with status Installing.
+If the verification of the firmware fails or if a signature is missing entirely, the Charge Point sends a SignedFirmwareStatusNotification.req with status InvalidSignature and a SecurityEventNotification.req with the security event InvalidFirmwareSignature.
+6. If the installation is successful, the Charge Point sends a SignedFirmwareStatusNotification.req with status Installed.
+Otherwise, it sends a SignedFirmwareStatusNotification.req with status InstallationFailed.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charge Point Manufacturer provided a firmware update, signing certificate and signature.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The firmware is updated and the Charge Point is in Installed status.
+Failure postconditions:
+The certificate is not valid or could not be verified and the Charge Point is in InvalidCertificate status.
+Downloading the firmware failed and the Charge Point is in DownloadFailed status.
+The verification of the firmware's digital signature failed and the Charge Point is in InvalidSignature status.
+The installation of the firmware is not successful and the Charge Point is in InstallationFailed status.</td></tr></table>
+
+
+Figure 13. Sequence diagram secure firmware upgrade (happy flow)
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td rowspan="5">8</td><td rowspan="5">Remark(s)</td><td>Measures SHOULD be taken to secure the firmware when it is stored on a server or workstation.</td></tr><tr><td>The Charge Point has a required Configuration Key that reports which file transfer protocols it supports:
+SupportedFileTransferProtocols</td></tr><tr><td>The requirements for the Firmware Signing Certificate are described in the: Certificate Properties section.</td></tr><tr><td>The manufacturer SHALL NOT use intermediate certificates for the firmware signing certificate in the Charge Point.</td></tr><tr><td>FTP needs to be able to use Passive FTP, to be able to transverse over as much different typologies as possible.</td></tr></table>
+
+
+Figure 14. Firmware update process
+
+# L01 - Secure Firmware Update - Requirements
+
+Table 35. L01 - Requirements
+
+<table><tr><td>ID</td><td>PRECONDITION</td><td>REQUIREMENT DEFINITION</td><td>NOTE</td></tr><tr><td>L01.FR.01</td><td>Whenever the Charge Point enters a new state in the firmware update process.</td><td>The Charge Point SHALL send a Signed FirmwareStatusNotification.req message to the Central System with this new status. What reason to use is described in the description of FirmwareStatusEnumType.</td><td></td></tr><tr><td>L01.FR.02</td><td>When the Charge Point enters the Invalid Certificate state in the firmware process.</td><td>The Charge Point SHALL send a SecurityEventNotification.req message to the Central System with the security event InvalidFirmwareSigningCertificate.</td><td></td></tr><tr><td>L01.FR.03</td><td>When the Charge Point enters the Invalid Signature state.</td><td>The Charge Point SHALL send a SecurityEventNotification.req message to the Central System with the security event InvalidFirmwareSignature.</td><td></td></tr><tr><td>L01.FR.04</td><td>When the Charge Point has successfully downloaded the new firmware</td><td>The signature SHALL be validated, by calculating the signature over the entire firmware file using the RSA-PSS or ECSchnorr algorithm for signing, and the SHA256 algorithm for calculating hash values.</td><td></td></tr><tr><td>L01.FR.05</td><td>L01.FR.04 AND installDateTime is not set</td><td>The Charge Point SHALL install the new firmware as soon as it is able to.</td><td></td></tr><tr><td>L01.FR.06</td><td>L01.FR.05 AND The Charge Point has ongoing transactions AND When it is not possible to continue charging during installation of firmware</td><td>The Charge Point SHALL wait until all transactions have ended, before commencing installation.</td><td></td></tr><tr><td>L01.FR.07</td><td>L01.FR.06</td><td>The Charge Point SHALL set all connectors that are not in use to UNAVAILABLE while the Charge Point waits for the ongoing transactions to end. Until the firmware is installed, any connector that becomes available SHALL be set to UNAVAILABLE.</td><td></td></tr><tr><td>L01.FR.08</td><td></td><td>It is RECOMMENDED that the firmware is sent encrypted to the Charge Point. This can either be done by using a secure protocol (such as HTTPS, SFTP, or FTPS) to send the firmware, or by encrypting the firmware itself before sending it.</td><td></td></tr><tr><td>L01.FR.09</td><td></td><td>Firmware updates SHALL be digitally protected to ensure authenticity and to provide proof of origin.</td><td>This protection is achieved by applying a digital signature over the hash value of the firmware image. Ideally, this signature is already computed by the manufacturer. This way proof of origin of the firmware image can be tracked back to the original author of the firmware.</td></tr><tr><td>L01.FR.10</td><td></td><td>Every Signed FirmwareStatusNotification.req that is sent for a specific firmware update SHALL contain the same requestid as the SignedUpdateFirmware.req that started this firmware update.</td><td></td></tr><tr><td>L01.FR.11</td><td></td><td>For security purposes the Central System SHALL include the Firmware Signing certificate (see Keys used in OCPP) in the SignedUpdateFirmware.req.</td><td></td></tr><tr><td>L01.FR.12</td><td></td><td>For verifying the certificate (see Certificate Hierarchy) use the rules for X.509 certificates [9]. The Charge Point MUST verify the file's digital signature using the Firmware Signing certificate.</td><td></td></tr><tr><td>L01.FR.13</td><td>When the Charge Point enters the Download Scheduled state.</td><td>The Charge Point SHALL send a SignedFirmwareStatusNotification.req with status DownloadScheduled.</td><td>For example when it is busy with installing another firmware or it is busy Charging.</td></tr><tr><td>L01.FR.14</td><td>When the Charge Point enters the Download Paused state.</td><td>The Charge Point SHALL send a SignedFirmwareStatusNotification.req with status DownloadPaused.</td><td>For example when the Charge Point has tasks with higher priorities.</td></tr><tr><td>L01.FR.15</td><td>When a Charge Point needs to reboot before installing the downloaded firmware.</td><td>The Charge Point SHALL send a SignedFirmwareStatusNotification.req with status InstallRebooting, before rebooting.</td><td></td></tr><tr><td>L01.FR.16</td><td>L01.FR.04 AND When installDateTime is set to a future date-time</td><td>The Charge Point SHALL send a SignedFirmwareStatusNotification.req with status InstallScheduled and install the firmware at the specified installation time.</td><td></td></tr><tr><td>L01.FR.17</td><td>L01.FR.16 AND current DateTime >= InstallDateTime</td><td>The Charge Point SHALL install the new firmware as soon as it is able to.</td><td></td></tr><tr><td>L01.FR.18</td><td>L01.FR.17 AND The Charge Point has ongoing transactions AND It is not possible to continue charging during installation of firmware</td><td>The Charge Point SHALL wait until all transactions have ended, before commencing installation.</td><td></td></tr><tr><td>L01.FR.19</td><td>L01.FR.18</td><td>The Charge Point SHALL set all connectors that are not in use to UNAVAILABLE while the Charge Point waits for the ongoing transactions to end. Until the firmware is installed, any connector that becomes available SHALL be set to UNAVAILABLE.</td><td></td></tr><tr><td>L01.FR.20</td><td>When the Charge Point receives a UpdateFirmware.req (the original OCPP 1.6 message)</td><td>The Charge Point SHALL respond with a WebSocket RPC CALLERROR NotSupported, and the Charge Point SHALL NOT start the Firmware Update process.</td><td></td></tr><tr><td>L01.FR.21</td><td></td><td>The field requestId in SignedFirmwareStatusNotification.req is mandatory, unless status = Idle.</td><td></td></tr><tr><td>L01.FR.22</td><td>When the Charge Point needs to reboot during a firmware update AND the bootloader is unable to send OCPP messages</td><td>The Charge Point MAY omit the SignedFirmwareStatusNotification.req (status=Installing) message.</td><td></td></tr><tr><td>L01.FR.23</td><td>When the Charge Point receives an SignedUpdateFirmware.req</td><td>The Charge Point SHALL validate the certificate before accepting the message.</td><td></td></tr><tr><td>L01.FR.24</td><td>L01.FR.23 AND the certificate is invalid</td><td>The Charge Point SHALL respond with SignedUpdateFirmware.conf (status=InvalidCertificate).</td><td></td></tr><tr><td>L01.FR.25</td><td>L01.FR.23 AND the certificate is revoked</td><td>The Charge Point SHALL respond with SignedUpdateFirmware.conf (status=RevokedCertificate).</td><td></td></tr><tr><td>L01.FR.26</td><td>When a Charge Point is installing new Firmware OR is going to install new Firmware, but has received an SignedUpdateFirmware.req command to install it at a later time AND the Charge Point receives a new SignedUpdateFirmware.req</td><td>The Charge Point SHOULD cancel the ongoing firmware update AND respond with status AcceptedCanceled.</td><td>The Charge Point SHOULD NOT first check if the new firmware file exists, this way the Central System will be able to cancel an ongoing firmware update without starting a new one.</td></tr><tr><td>L01.FR.27</td><td>L01.FR.26 AND the Charge Point is unable to cancel the installation</td><td>The Charge Point MAY respond with status Rejected.</td><td></td></tr><tr><td>L01.FR.28</td><td>Charge Point receives a ExtendedTriggerMessage.req for FirmwareStatusNotification AND last sent SignedFirmwareStatusNotification.req had status = Installed</td><td>Charge Point SHALL return a SignedFirmwareStatusNotification.req with status = Idle.</td><td></td></tr><tr><td>L01.FR.29</td><td>Charge Point receives a ExtendedTriggerMessage.req for FirmwareStatusNotification AND last sent SignedFirmwareStatusNotification.req had status <> Installed</td><td>Charge Point SHALL return a SignedFirmwareStatusNotification.req with the last sent status.</td><td></td></tr></table>
+
+# 5. Messages
+
+To add the functionality needed for this WhitePaper, a couple of messages have been added from OCPP 2.0.1. Most have their original name from OCPP 2.0.1. Others have a modified name, because they have been modified between 1.6 and 2.0.1. The messages that have been renamed, are marked as such.
+
+# 5.1. CertificateSigned.req
+
+This contains the field definition of the CertificateSigned.req PDU sent by the Central System to the Charge Point.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>certificateChain</td><td>string[0..10000]</td><td>1..1</td><td>Required. The signed PEM encoded X.509 certificates. This can also contain the necessary sub CA certificates. The maximum size of this field is be limited by the configuration key: CertificateSignedMaxSize.</td></tr></table>
+
+# 5.2. CertificateSigned.conf
+
+This contains the field definition of the CertificateSigned.conf PDU sent by the Charge Point to the Central System in response to a CertificateSigned.req.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>CertificateSignedStatusEnumType</td><td>1..1</td><td>Required. Returns whether certificate signing has been accepted, otherwise rejected.</td></tr></table>
+
+# 5.3. DeleteCertificate.req
+
+Used by the Central System to request deletion of an installed certificate on a Charge Point.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>certificateHashData</td><td>CertificateHashDataT ype</td><td>1..1</td><td>Required. Indicates the certificate of which deletion is requested.</td></tr></table>
+
+# 5.4. DeleteCertificate.conf
+
+Response to a DeleteCertificate.req.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>DeleteCertificateStatusEnumType</td><td>1..1</td><td>Required. Charge Point indicates if it can process the request.</td></tr></table>
+
+# 5.5. ExtendedTriggerMessage.req
+
+This contains the field definition of the ExtendedTriggerMessage.req PDU sent by the Central System to the Charge Point.
+
+This message is based on the OCPP 2.0.1 TriggerMessageRequest, it has been renamed to:
+
+ExtendedTriggerMessage.req, because the original name conflicts with the TriggerMessage.req from OCPP 1.6.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>requestedMessage</td><td>MessageTriggerEnum Type</td><td>1..1</td><td>Required. Type of the message to be triggered.</td></tr><tr><td>connectorId</td><td>integer connectorId > 0</td><td>0..1</td><td>Optional. Only filled in when request applies to a specific connector.</td></tr></table>
+
+# 5.6. ExtendedTriggerMessage.conf
+
+This contains the field definition of the ExtendedTriggerMessage.conf PDU sent by the Charge Point to the Central System in response to ExtendedTriggerMessage.req.
+
+This message is based on the OCPP 2.0.1 TriggerMessageResponse, it has been renamed to:
+
+ExtendedTriggerMessage.conf, because the original name conflicts with the TriggerMessage.conf from OCPP 1.6.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td rowspan="2">status</td><td>TriggerMessageStatus</td><td rowspan="2">1..1</td><td rowspan="2">Required. Indicates whether the Charge Point will send the requested notification or not.</td></tr><tr><td>EnumType</td></tr></table>
+
+# 5.7. GetInstalledCertificates.req
+
+Used by the Central System to request an overview of the installed certificates on a Charge Point.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>certificateType</td><td>CertificateUseEnumType</td><td>1..1</td><td>Required. Indicates the type of certificates requested.</td></tr></table>
+
+# 5.8. GetInstalledCertificates.conf
+
+Response to a GetInstalledCertificateIDs.req.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>GetInstalledCertificatesStatusEnumType</td><td>1..1</td><td>Required. Charge Point indicates if it can process the request.</td></tr><tr><td>certificateHashData</td><td>CertificateDataType</td><td>0.*</td><td>Optional. The Charge Point includes the Certificate information for each available certificate.</td></tr></table>
+
+# 5.9. GetLog.req
+
+This contains the field definition of the GetLog.req PDU sent by the Central System to the Charge Point.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>logType</td><td>LogEnumType</td><td>1..1</td><td>Required. This contains the type of log file that the Charge Point should send.</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of this request</td></tr><tr><td>retries</td><td>integer</td><td>0..1</td><td>Optional. This specifies how many times the Charge Point must try to upload the log before giving up. If this field is not present, it is left to Charge Point to decide how many times it wants to retry.</td></tr><tr><td>retryInterval</td><td>integer</td><td>0..1</td><td>Optional. The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charge Point to decide how long to wait between attempts.</td></tr><tr><td>log</td><td>LogParametersType</td><td>1..1</td><td>Required. This field specifies the requested log and the location to which the log should be sent.</td></tr></table>
+
+# 5.10. GetLog.conf
+
+This contains the field definition of the GetLog.conf PDU sent by the Charge Point to the Central System in response to a GetLog.req.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>LogStatusEnumType</td><td>1..1</td><td>Required. This field indicates whether the Charge Point was able to accept the request.</td></tr><tr><td>filename</td><td>string[0..255]</td><td>0..1</td><td>Optional. This contains the name of the log file that will be uploaded. This field is not present when no logging information is available.</td></tr></table>
+
+# 5.11. InstallCertificate.req
+
+Used by the Central System to request installation of a certificate on a Charge Point.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>certificateType</td><td>CertificateUseEnumType</td><td>1..1</td><td>Required. Indicates the certificate type that is sent.</td></tr><tr><td>certificate</td><td>string[0..5500]</td><td>1..1</td><td>Required. An PEM encoded X.509 certificate.</td></tr></table>
+
+# 5.12. InstallCertificate.conf
+
+The response to a InstallCertificate.req, sent by the Charge Point to the Central System.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>CertificateStatusEnu mType</td><td>1..1</td><td>Required. Charge Point indicates if installation was successful.</td></tr></table>
+
+# 5.13. LogStatusNotification.req
+
+This contains the field definition of the LogStatusNotification.req PDU sent by the Charge Point to the Central System.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>UploadLogStatusEnu mType</td><td>1..1</td><td>Required. This contains the status of the log upload.</td></tr><tr><td>requestId</td><td>integer</td><td>0..1</td><td>Optional. The request id that was provided in the GetLog.req that started this log upload.</td></tr></table>
+
+# 5.14. LogStatusNotification.conf
+
+This contains the field definition of the LogStatusNotification.conf PDU sent by the Central System to the Charge Point in response to LogStatusNotification.req.
+
+No fields are defined.
+
+# 5.15. SecurityEventNotification.req
+
+Sent by the Charge Point to the Central System in case of a security event.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>type</td><td>string[50]</td><td>1..1</td><td>Required. Type of the security event (See list of currently known security events)</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. Date and time at which the event occurred.</td></tr><tr><td>techInfo</td><td>string[0..255]</td><td>0..1</td><td>Additional information about the occurred security event.</td></tr></table>
+
+# 5.16. SecurityEventNotification.conf
+
+Sent by the Central System to the Charge Point to confirm the receipt of a SecurityEventNotification.req message.
+
+No fields are defined.
+
+# 5.17. SignCertificate.req
+
+Sent by the Charge Point to the Central System to request that the Certificate Authority signs the public key into a certificate.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>csr</td><td>string[0..5500]</td><td>1..1</td><td>Required. The Charge Point SHALL send the public key in form of a Certificate Signing Request (CSR) as described in RFC 2986 [14] and then PEM encoded, using the SignCertificate.req message.</td></tr></table>
+
+# 5.18. SignCertificate.conf
+
+Sent by the Central System to the Charge Point in response to the SignCertificate.req message.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Specifies whether the Central System can process the request.</td></tr></table>
+
+# 5.19. Signed FirmwareStatusNotification.req
+
+This contains the field definition of the Signed FirmwareStatusNotification.req PDU sent by the Charge Point to the Central System.
+
+This is the OCPP 2.0.1 FirmwareStatusNotificationRequest, it has been renamed to SignedFirmwareStatusNotification.req, because the original name conflicts with the FirmwareStatusNotification.req from OCPP 1.6.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>FirmwareStatusEnum Type</td><td>1..1</td><td>Required. This contains the progress status of the firmware installation.</td></tr><tr><td>requestId</td><td>integer</td><td>0..1</td><td>Optional. The request id that was provided in the SignedUpdateFirmware.req that started this firmware update. This field is mandatory, unless the message was triggered by a TriggerMessage.req or the ExtendedTriggerMessage.req AND there is no firmware update ongoing.</td></tr></table>
+
+# 5.20. Signed FirmwareStatusNotification.conf
+
+This contains the field definition of the Signed FirmwareStatusNotification.conf PDU sent by the Central System to the Charge Point in response to a Signed FirmwareStatusNotification.req.
+
+This is the OCPP 2.0.1 FirmwareStatusNotificationResponse, it is renamed to:
+SignedFirmwareStatusNotification.conf, because the original name conflicts with the FirmwareStatusNotification.conf from OCPP 1.6.
+
+No fields are defined.
+
+# 5.21. SignedUpdateFirmware.req
+
+This contains the field definition of the SignedUpdateFirmware.req PDU sent by the Central System to the Charge Point.
+
+This is the OCPP 2.0.1 UpdateFirmwareRequest, it is renamed to SignedUpdateFirmware.req, it is renamed because the original name conflicts with the UpdateFirmware.req from OCPP 1.6.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>retries</td><td>integer</td><td>0..1</td><td>Optional. This specifies how many times Charge Point must try to download the firmware before giving up. If this field is not present, it is left to Charge Point to decide how many times it wants to retry.</td></tr><tr><td>retrypInterval</td><td>integer</td><td>0..1</td><td>Optional. The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charge Point to decide how long to wait between attempts.</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of this request</td></tr><tr><td>firmware</td><td>FirmwareType</td><td>1..1</td><td>Required. Specifies the firmware to be updated on the Charge Point.</td></tr></table>
+
+# 5.22. SignedUpdateFirmware.conf
+
+This contains the field definition of the SignedUpdateFirmware.conf PDU sent by the Charge Point to the Central System in response to an SignedUpdateFirmware.req.
+
+This is the OCPP 2.0.1 UpdateFirmwareResponse, it is renamed to SignedUpdateFirmware.conf, it is renamed because the original name conflicts with the UpdateFirmware.req from OCPP 1.6.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>UpdateFirmwareStatusEnumType</td><td>1..1</td><td>Required. This field indicates whether the Charge Point was able to accept the request.</td></tr></table>
+
+# 6. Datatypes
+
+# 6.1. CertificateDataType
+
+Class
+
+CertificateHashDataType is used by: DeleteCertificate.req, GetInstalledCertificatesIds.conf
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>hashAlgorithm</td><td>HashAlgorithmEnumType</td><td>1..1</td><td>Required. Used algorithms for the hashes provided.</td></tr><tr><td>issuerNameHash</td><td>CiString128Type</td><td>1..1</td><td>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. The hash is represented in hexbinary format (i.e. each byte is represented by 2 hexadecimal digits).Please refer to the OCSP specification: RFC6960 [15].</td></tr><tr><td>issuerKeyHash</td><td>CiString128Type</td><td>1..1</td><td>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. The hash is represented in hexbinary format (i.e. each byte is represented by 2 hexadecimal digits). Please refer to the OCSP specification: RFC6960 [15].</td></tr><tr><td>serialNumber</td><td>CiString40Type</td><td>1..1</td><td>Required. The serial number as a hexadecimal string without leading zeroes (and without the prefix 0x). For example: the serial number with decimal value 4095 will be represented as "FFF". Please note: The serial number of a certificate is a non-negative integer of at most 20 bytes. Since this is too large to be handled as a number in many system, it is represented as a string that contains the hexadecimal representation of this number. The string shall not have any leading zeroes.</td></tr></table>
+
+# 6.2. CertificateSignedStatusEnumType
+
+Enumeration
+
+CertificateSignedStatusEnumType is used by: CertificateSigned.conf
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Signed certificate is valid.</td></tr><tr><td>Rejected</td><td>Signed certificate is invalid.</td></tr></table>
+
+# 6.3. CertificateStatusEnumType
+
+Enumeration
+
+Status of the certificate.
+
+CertificateStatusEnumType is used by: InstallCertificate.conf
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>The installation of the certificate succeeded.</td></tr><tr><td>Failed</td><td>The certificate is valid and correct, but there is another reason the installation did not succeed.</td></tr><tr><td>Rejected</td><td>The certificate is invalid and/or incorrect OR the CPO tries to install more certificates than allowed.</td></tr></table>
+
+# 6.4. CertificateUseEnumType
+
+Enumeration
+
+CertificateUseEnumType is used by: GetInstalledCertificates.req, InstallCertificate.req
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>CentralSystemRootCertificate</td><td>Root certificate, used by the CA to sign the Central System and Charge Point certificate.</td></tr><tr><td>ManufacturerRootCertificate</td><td>Root certificate for verification of the Manufacturer certificate.</td></tr></table>
+
+# 6.5. CiString40Type
+
+Type
+
+Generic case insensitive string of 40 characters.
+
+<table><tr><td>FIELD TYPE</td><td>DESCRIPTION</td></tr><tr><td>CiString[40]</td><td>String is case insensitive.</td></tr></table>
+
+# 6.6. CiString128Type
+
+Type
+
+Generic case insensitive string of 128 characters.
+
+<table><tr><td>FIELD TYPE</td><td>DESCRIPTION</td></tr><tr><td>CiString[128]</td><td>String is case insensitive.</td></tr></table>
+
+# 6.7. DeleteCertificateStatusEnumType
+
+Enumeration
+
+DeleteCertificateStatusEnumType is used by: DeleteCertificate.conf
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Normal successful completion (no errors).</td></tr><tr><td>Failed</td><td>Processing failure.</td></tr><tr><td>NotFound</td><td>Requested resource not found.</td></tr></table>
+
+# 6.8. FirmwareStatusEnumType
+
+Enumeration
+
+Status of a firmware download.
+
+A value with "Intermediate state" in the description, is an intermediate state, update process is not finished.
+
+A value with "Failure end state" in the description, is an end state, update process has stopped, update failed.
+
+A value with "Successful end state" in the description, is an end state, update process has stopped, update successful.
+
+FirmwareStatusEnumType is used by: SignedFirmwareStatusNotification.req
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Downloaded</td><td>Intermediate state. New firmware has been downloaded by Charge Point.</td></tr><tr><td>DownloadFailed</td><td>Failure end state. Charge Point failed to download firmware.</td></tr><tr><td>Downloading</td><td>Intermediate state. Firmware is being downloaded.</td></tr><tr><td>DownloadScheduled</td><td>Intermediate state. Downloading of new firmware has been scheduled.</td></tr><tr><td>DownloadPaused</td><td>Intermediate state. Downloading has been paused.</td></tr><tr><td>Idle</td><td>Charge Point is not performing firmware update related tasks. Status Idle SHALL only be used as in a Signed Firmware Status Notification req that was triggered by Extended Trigger Message req.</td></tr><tr><td>InstallationFailed</td><td>Failure end state. Installation of new firmware has failed.</td></tr><tr><td>Installing</td><td>Intermediate state. Firmware is being installed.</td></tr><tr><td>Installed</td><td>Successful end state. New firmware has successfully been installed in Charge Point.</td></tr><tr><td>InstallRebooting</td><td>Intermediate state. Charge Point 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.</td></tr><tr><td>InstallScheduled</td><td>Intermediate state. Installation of the downloaded firmware is scheduled to take place on installDateTime given in SignedUpdateFirmware.req.</td></tr><tr><td>InstallVerificationFailed</td><td>Failure end state. Verification of the new firmware (e.g. using a checksum or some other means) has failed and installation will not proceed. (Final failure state)</td></tr><tr><td>InvalidSignature</td><td>Failure end state. The firmware signature is not valid.</td></tr><tr><td>SignatureVerified</td><td>Intermediate state. Provide signature successfully verified.</td></tr></table>
+
+# 6.9. FirmwareType
+
+Class
+
+Represents a copy of the firmware that can be loaded/updated on the Charge Point.
+
+FirmwareType is used by: SignedUpdateFirmware.req
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>location</td><td>string[0..512]</td><td>1..1</td><td>Required. URI defining the origin of the firmware.</td></tr><tr><td>retrieveDateTime</td><td>dateTime</td><td>1..1</td><td>Required. Date and time at which the firmware shall be retrieved.</td></tr><tr><td>installDateTime</td><td>dateTime</td><td>0..1</td><td>Optional. Date and time at which the firmware shall be installed.</td></tr><tr><td>signingCertificate</td><td>string[0..5500]</td><td>1..1</td><td>Required. Certificate with which the firmware was signed. PEM encoded X.509 certificate.</td></tr><tr><td>signature</td><td>string[0..800]</td><td>1..1</td><td>Required. Base64 encoded firmware signature.</td></tr></table>
+
+# 6.10.Generic statusesTypeDef
+
+Enumeration
+
+Generic message response status
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Rejected</td><td>Request has not been accepted and will not be executed.</td></tr></table>
+
+# 6.11. GetInstalledCertificateStatusEnumType
+
+Enumeration
+
+GetInstalledCertificateStatusEnumType is used by: GetInstalledCertificates.conf
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Normal successful completion (no errors).</td></tr><tr><td>NotFound</td><td>Requested certificate not found.</td></tr></table>
+
+# 6.12. HashAlgorithmEnumType
+
+Enumeration
+
+HashAlgorithmEnumType is used by: CertificateHashDataType
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>SHA256</td><td>SHA-256 hash algorithm.</td></tr><tr><td>SHA384</td><td>SHA-384 hash algorithm.</td></tr><tr><td>SHA512</td><td>SHA-512 hash algorithm.</td></tr></table>
+
+# 6.13. LogEnumType
+
+Enumeration
+
+LogEnumType is used by: GetLog.req
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>DiagnosticsLog</td><td>This contains the field definition of a diagnostics log file</td></tr><tr><td>SecurityLog</td><td>Sent by the Central System to the Charge Point to request that the Charge Point uploads the security log.</td></tr></table>
+
+# 6.14. LogParametersType
+
+Class
+
+Class for detailed information the retrieval of logging entries.
+
+LogParametersType is used by: GetLog.req
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>remoteLocation</td><td>string[0..512]</td><td>1..1</td><td>Required. The URL of the location at the remote system where the log should be stored.</td></tr><tr><td>oldestTimestamp</td><td>dateTime</td><td>0..1</td><td>Optional. This contains the date and time of the oldest logging information to include in the diagnostics.</td></tr><tr><td>latestTimestamp</td><td>dateTime</td><td>0..1</td><td>Optional. This contains the date and time of the latest logging information to include in the diagnostics.</td></tr></table>
+
+# 6.15. LogStatusEnumType
+
+Enumeration
+
+LogStatusEnumType is used by: GetLog.conf
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Accepted this log upload. This does not mean the log file is uploaded is successfully, the Charge Point will now start the log file upload.</td></tr><tr><td>Rejected</td><td>Log update request rejected.</td></tr><tr><td>AcceptedCanceled</td><td>Accepted this log upload, but in doing this has canceled an ongoing log file upload.</td></tr></table>
+
+# 6.16. MessageTriggerEnumType
+
+Enumeration
+
+Type of request to be triggered by trigger messages.
+
+MessageTriggerEnumType is used by: ExtendedTriggerMessage.req
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>BootNotification</td><td>To trigger BootNotification.req.</td></tr><tr><td>LogStatusNotifica tion</td><td>To trigger LogStatusNotification.req.</td></tr><tr><td>FirmwareStatusN otification</td><td>To trigger SignedFirmwareStatusNotification.req (So the status of the secure firmware update introduced in this document).</td></tr><tr><td>Heartbeat</td><td>To trigger Heartbeat.req.</td></tr><tr><td>MeterValues</td><td>To trigger MeterValues.req.</td></tr><tr><td>SignChargePointCertificate</td><td>To trigger a SignCertificate.req with certificateType: ChargePointCertificate.</td></tr><tr><td>StatusNotification</td><td>To trigger SatusNotification.req.</td></tr></table>
+
+# 6.17. TriggerMessageStatusEnumType
+
+Enumeration
+
+TriggerMessageStatusEnumType is used by: ExtendedTriggerMessage.conf
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Requested message will be sent.</td></tr><tr><td>Rejected</td><td>Requested message will not be sent.</td></tr><tr><td>NotImplemented</td><td>Requested message cannot be sent because it is either not implemented or unknown.</td></tr></table>
+
+# 6.18. UpdateFirmwareStatusEnumType
+
+Enumeration
+
+Update Firmware StatusEnumType is used by: SignedUpdateFirmware.conf
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Accepted this firmware update request. This does not mean the firmware update is successful, the Charge Point will now start the firmware update process.</td></tr><tr><td>Rejected</td><td>Firmware update request rejected.</td></tr><tr><td>AcceptedCanceled</td><td>Accepted this firmware update request, but in doing this has canceled an ongoing firmware update.</td></tr><tr><td>InvalidCertificate</td><td>The certificate is invalid.</td></tr><tr><td>RevokedCertificate</td><td>Failure end state. The Firmware Signing certificate has been revoked.</td></tr></table>
+
+# 6.19. UploadLogStatusEnumType
+
+Enumeration
+
+UploadLogStatusEnumType is used by: LogStatusNotification.req
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>BadMessage</td><td>A badly formatted packet or other protocol incompatibility was detected.</td></tr><tr><td>Idle</td><td>The Charge Point is not uploading a log file. Idle SHALL only be used when the message was triggered by a ExtendedTriggerMessage.req.</td></tr><tr><td>NotSupportedOperation</td><td>The server does not support the operation</td></tr><tr><td>PermissionDenied</td><td>Insufficient permissions to perform the operation.</td></tr><tr><td>Uploaded</td><td>File has been uploaded successfully.</td></tr><tr><td>UploadFailure</td><td>Failed to upload the requested file.</td></tr><tr><td>Uploading</td><td>File is being uploaded.</td></tr></table>
+
+# 7. Configuration Keys
+
+7.1.AdditionalRootCertificateCheck
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>R</td></tr><tr><td>Type</td><td>boolean</td></tr><tr><td>Description</td><td>When set to true, only one certificate (plus a temporarily fallback certificate) of certificateType CentralSystemRootCertificate is allowed to be installed at a time. When installing a new Central System Root certificate, the new certificate SHALL replace the old one AND the new Central System Root Certificate MUST be signed by the old Central System Root Certificate it is replacing. This configuration key is required unless only "security profile 1 - Unsecured Transport with Basic Authentication" is implemented. Please note that security profile 1 SHOULD only be used in trusted networks.
+Note: When using this additional security mechanism please be aware that the Charge Point needs to perform a full certificate chain verification when the new Central System Root certificate is being installed. However, once the old Central System Root certificate is set as the fallback certificate, the Charge Point needs to perform a partial certificate chain verification when verifying the server certificate during the TLS handshake. Otherwise the verification will fail once the old Central System Root ( fallback) certificate is either expired or removed.</td></tr></table>
+
+# 7.2. AuthorizationKey
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>W</td></tr><tr><td>Type</td><td>String</td></tr><tr><td>Description</td><td>The basic authentication password is used for HTTP Basic Authentication, minimal length: 16 bytes.
+It is strongly advised to be randomly generated binary to get maximal entropy. Hexadecimal represented (20 bytes maximum, represented as a string of up to 40 hexadecimal digits).
+This configuration key is write-only, so that it cannot be accidentally stored in plaintext by the Central System when it reads out all configuration keys.
+This configuration key is required unless only "security profile 3 - TLS with client side certificates" is implemented.</td></tr></table>
+
+# 7.3. CertificateSignedMaxChainSize
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>R</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Description</td><td>This configuration key can be used to limit the size of the 'certificateChain' field from the CertificateSigned.req PDU. The value of this configuration key has a maximum limit of 10.000 characters.</td></tr></table>
+
+# 7.4. CertificateStoreMaxLength
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>R</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Description</td><td>Maximum number of Root/CA certificates that can be installed in the Charge Point.</td></tr></table>
+
+# 7.5. CpoName
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>String</td></tr><tr><td>Description</td><td>This configuration key contains CPO name (or an organization trusted by the CPO) as used in the Charge Point Certificate. This is the CPO name that is to be used in a CSR send via: SignCertificate.req</td></tr><tr><td colspan="2">7.6. SecurityProfile</td></tr><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Description</td><td>This configuration key is used to set the security profile used by the Charge Point.The value of this configuration key can only be increased to a higher level, not decreased to a lower level, if the Charge Point receives a lower value then currently configured,the Charge Point SHALL Rejected the ChangeConfiguration.reqBefore accepting the new value, the Charge Point SHALL check if all the prerequisites for the new Security Profile are met, if not, the Charge Point SHALL Rejected the ChangeConfiguration.req.After the security profile was successfully changed, the Charge Point disconnects from the Central System and SHALL reconnect using the new configured Security Profile.Default, when no security profile is yet configured: 0.</td></tr></table>
+
+# 8. Security Events
+
+The table below provides a list of security events. Security events that are critical should be pushed to the Central System.
+
+<table><tr><td>SECURITY EVENT</td><td>DESCRIPTION</td><td>CRITICAL</td></tr><tr><td>FirmwareUpdated</td><td>The Charge Point firmware is updated</td><td>Yes</td></tr><tr><td>FailedToAuthenticationAtCentralSystem</td><td>The authentication credentials provided by the Charge Point were rejected by the Central System</td><td>No</td></tr><tr><td>CentralSystemFailedToAuthentication</td><td>The authentication credentials provided by the Central System were rejected by the Charge Point</td><td>No</td></tr><tr><td>SettingSystemTime</td><td>The system time on the Charge Point was changed</td><td>Yes</td></tr><tr><td>StartupOfTheDevice</td><td>The Charge Point has booted</td><td>Yes</td></tr><tr><td>ResetOrReboot</td><td>The Charge Point was rebooted or reset</td><td>Yes</td></tr><tr><td>SecurityLogWasCleared</td><td>The security log was cleared</td><td>Yes</td></tr><tr><td>ReconfigurationOfSecurityParameters</td><td>Security parameters, such as keys or the security profile used, were changed</td><td>No</td></tr><tr><td>MemoryExhaustion</td><td>The Flash or RAM memory of the Charge Point is getting full</td><td>Yes</td></tr><tr><td>InvalidMessages</td><td>The Charge Point has received messages that are not valid OCPP messages, if signed messages, signage invalid/incorrect</td><td>No</td></tr><tr><td>AttemptedReplayAttacks</td><td>The Charge Point has received a replayed message (other than the Central System trying to resend a message because it there was for example a network problem)</td><td>No</td></tr><tr><td>TamperDetectionActivated</td><td>The physical tamper detection sensor was triggered</td><td>Yes</td></tr><tr><td>InvalidFirmwareSignature</td><td>The firmware signature is not valid</td><td>No</td></tr><tr><td>InvalidFirmwareSigningCertificate</td><td>The certificate used to verify the firmware signature is not valid</td><td>No</td></tr><tr><td>InvalidCentralSystemCertificate</td><td>The certificate that the Central System uses was not valid or could not be verified</td><td>No</td></tr><tr><td>InvalidChargePointCertificate</td><td>The certificate sent to the Charge Point using the SignCertificate.conf message is not a valid certificate</td><td>No</td></tr><tr><td>InvalidTLSVersion</td><td>The TLS version used by the Central System is lower than 1.2 and is not allowed by the security specification</td><td>No</td></tr><tr><td>InvalidTLSCipherSuite</td><td>The Central System did only allow connections using TLS cipher suites that are not allowed by the security specification</td><td>No</td></tr></table>
+
+# 9. Changelog Edition 2
+
+<table><tr><td>SECTION / USE CASE</td><td>CHANGE</td></tr><tr><td>2.3. Unsecured Transport with Basic Authentication Profile</td><td>Basic auth example added to remarks.</td></tr><tr><td>2.4.1. TLS with Basic Authentication Profile</td><td>A00.FR.308 changed. "URL or IP address" changed to "FQDN".</td></tr><tr><td>2.4.1. TLS with Basic Authentication Profile</td><td>A00.FR.317 changed. Added a note.</td></tr><tr><td>2.5.1. TLS with Client Side Certificates Profile</td><td>A00.FR.405 changed. "unique identifier" changed to "unique serial number".</td></tr><tr><td>2.5.1. TLS with Client Side Certificates Profile</td><td>A00.FR.412 changed. "URL" changed to "FQDN".</td></tr><tr><td>2.5.1. TLS with Client Side Certificates Profile</td><td>A00.FR.429 added.</td></tr><tr><td>2.6.1. Certificate Properties</td><td>A00.FR.507 changed. Encoding changed from DER, followed by Base64 encoding to PEM.</td></tr><tr><td>2.6.1. Certificate Properties</td><td>A00.FR.510 changed. "full URL of the endpoint" changed to "FQDN".</td></tr><tr><td>2.6.2. Certificate Hierarchy</td><td>A00.FR.604, A00.FR.605 removed.</td></tr><tr><td>A02/A03</td><td>Prerequisite added. "The configuration variable CpoName MUST be set."</td></tr><tr><td>A02/A03</td><td>Error handling added.</td></tr><tr><td>A02/A03</td><td>A02.FR.03/A03.FR.03 changed. PEM encoding included.</td></tr><tr><td>A02/A03</td><td>A02.FR.04/A03.FR.04 changed. The dedicated authority server MAY be operated by the CPO.</td></tr><tr><td>A05</td><td>Error handling and requirements; A05.FR.08, A05.FR.09 added.</td></tr><tr><td>L01</td><td>Added requirements; L01.FR.21, L01.FR.22, L01.FR.23, L01.FR.24, L01.FR.25, L01.FR.26, L01.FR.27, L01.FR.28, L01.FR.29.</td></tr><tr><td>M04</td><td>M04.FR.07 added.</td></tr><tr><td>M05</td><td>M05.FR.05, M05.FR.06, M05.FR.07, M05.FR.08, M05.FR.09 added in v1.1.M05.FR.05, M05.FR.07 removed in v1.2M05.FR.08, M05.FR.09 changed in v1.2M05.FR.10, M05.FR.11, M05.FR.12, M05.FR.13 added in v1.2</td></tr><tr><td>N01</td><td>N01.FR.11, N01.FR.12 added.</td></tr><tr><td>5.1. CertificateSigned.req</td><td>Changes in 'cert' field. Field name changed from 'cert' to 'certificateChain'. Field type changed from string[0..5500] to string[0..10000]. Cardinality changed from 1..* to 1..1. Encoding changed from DER, then Hex encoded into a case insensitive string to PEM.</td></tr><tr><td>5.7. GetInstalledCertificateslds.req</td><td>'typeOfCertificate' field renamed to 'certificateType'.</td></tr><tr><td>5.11. InstallCertificate.req</td><td>' certificate' field encoding changed from DER, then Hex encoded into a case insensitive string to PEM.</td></tr><tr><td>5.17. SignCertificate.req</td><td>'csr' field encoding changed from DER to PEM.</td></tr><tr><td>5.13. LogStatusNotification.request</td><td>'requestId' field cardinality changed from 1..1 to 0..1</td></tr><tr><td>5.15. SecurityEventNotification.request</td><td>'techInfo' field added.</td></tr><tr><td>5.19. SignedFirmwareStatusNotification.request</td><td>'requestId' field cardinality changed from 1..1 to 0..1</td></tr><tr><td>6.1. CertificateHashDataType</td><td>'issuerKeyHash' field type changed from string[0..128] to identifierString[0..128].</td></tr><tr><td>6.1. CertificateHashDataType</td><td>'serialNumber' field type changed from string[0..20] to string[0..40].</td></tr><tr><td>6.6. FirmwareStatusEnumType</td><td>Enum values 'InvalidCertificate', 'RevokedCertificate', 'CertificateVerified' removed.</td></tr><tr><td>6.7. FirmwareType</td><td>'signingCertificate' field encoding changed from DER, then Hex encoded into a case insensitive string to PEM.</td></tr><tr><td>6.16. UpdateFirmwareStatusEnumType</td><td>Enum values 'InvalidCertificate', 'RevokedCertificate' added.</td></tr><tr><td>7. Configuration Keys</td><td>Configuration key 'CertificateSignedMaxChain' removed.</td></tr><tr><td>7. Configuration Keys</td><td>Configuration key 'CertificateSignedMaxChainSize' added.</td></tr><tr><td>7. Configuration Keys</td><td>Configuration key 'AdditionalRootCertificateCheck' added.</td></tr><tr><td>8. Security Events</td><td>'FailedToAuthenticationAtCentral System' changed to: 'FailedToAuthenticationAtCentralSystem' removed incorrect whitespace.</td></tr><tr><td>8. Security Events</td><td>'Central SystemFailedToAuthentication' changed to: 'CentralSystemFailedToAuthentication' removed incorrect whitespace.</td></tr></table>
+
+# 10. Changelog Edition 3
+
+<table><tr><td>SECTION / USE CASE</td><td>CHANGE</td></tr><tr><td>6.1. CertificateHashDataType</td><td>Updated descriptions of the fields of this type, clarifying that the contents of these fields must follow the OCSP specification. Corrected the type of the fields to CiStrings.</td></tr></table>
--- /dev/null
+
+
+# Table of Contents
+
+1. Scope. 4
+
+2. Terminology and Conventions 5
+
+2.1. Conventions 5
+2.2. Definitions 5
+2.3. Abbreviations 6
+2.4. References. 7
+
+3. Introduction 8
+
+3.1. Edition 2. 8
+3.2. Document structure. 8
+3.3. Feature Profiles 8
+3.4. General views of operation 10
+3.5. Local Authorization & Offline Behavior 12
+3.6. Transaction in relation to Energy Transfer Period 15
+3.7. Transaction-related messages 17
+3.8. Connector numbering.. 18
+3.9. ID Tokens. 18
+3.10. Parent idTag 19
+3.11. Reservations 19
+3.12. Vendor-specific data transfer 19
+3.13. Smart Charging 20
+3.14. Time zones 29
+3.15. Time notations 29
+3.16. Metering Data. 29
+
+4. Operations Initiated by Charge Point 32
+
+4.1. Authorization 32
+4.2. Boot Notification 32
+4.3. Data Transfer 34
+4.4. Diagnostics Status Notification 34
+4.5. Firmware Status Notification 34
+4.6. Heartbeat 35
+4.7. Meter Values. 35
+4.8. Start Transaction 37
+4.9. Status Notification 38
+4.10. Stop Transaction 43
+
+5. Operations Initiated by Central System 45
+
+5.1. Cancel Reservation 45
+5.2. Change Availability. 45
+5.3. Change Configuration 45
+5.4. Clear Cache 46
+5.5. Clear Charging Profile 47
+5.6. Data Transfer 47
+5.7. Get Composite Schedule. 47
+5.8. Get Configuration 48
+5.9. Get Diagnostics. 48
+5.10. Get Local List Version 49
+5.11. Remote Start Transaction 49
+5.12. Remote Stop Transaction 50
+5.13. Reserve Now. 51
+5.14. Reset 52
+5.15. Send Local List 52
+5.16. Set Charging Profile 53
+5.17. Trigger Message 55
+5.18. Unlock Connector 56
+5.19. Update Firmware 57
+
+6. Messages 60
+
+6.1. Authorization.req 60
+6.2. Authorization.conf 60
+6.3. BootNotification.req 60
+6.4. BootNotification.conf 61
+6.5. CancelReservation.req 61
+6.6. CancelReservation.conf. 61
+6.7. ChangeAvailability.req. 61
+6.8. ChangeAvailability.conf 62
+6.9. ChangeConfiguration.req 62
+6.10. ChangeConfiguration.conf 62
+6.11. ClearCache.req. 62
+6.12. ClearCache.conf 63
+6.13. ClearChargingProfile.req 63
+6.14. ClearChargingProfile.conf. 63
+6.15. DataTransfer.req 63
+6.16. DataTransfer.conf 64
+6.17. DiagnosticsStatusNotification.req 64
+6.18. DiagnosticsStatusNotification.conf 64
+6.19. FirmwareStatusNotification.req. 64
+6.20. FirmwareStatusNotification.conf. 65
+6.21. GetCompositeSchedule.req 65
+6.22. GetCompositeSchedule.conf 65
+6.23. GetConfiguration.req 65
+6.24. GetConfiguration.conf. 66
+6.25. GetDiagnostics.req 66
+6.26. GetDiagnostics.conf. 66
+6.27. GetLocalListVersion.req 66
+6.28. GetLocalListVersion.conf 67
+6.29. Heartbeat.req 67
+6.30. Heartbeat.conf 67
+6.31. MeterValues.req. 67
+6.32. MeterValues.conf 67
+6.33. RemoteStartTransaction.req 68
+6.34. RemoteStartTransaction.conf 68
+6.35. RemoteStopTransaction.reg 68
+6.36. RemoteStopTransaction.conf 68
+6.37. ReserveNow.req. 68
+6.38. ReserveNow.conf 69
+6.39. Reset.req 69
+6.40. Reset.conf 69
+6.41. SendLocalList.req. 69
+6.42. SendLocalList.conf. 70
+6.43. SetChargingProfile.req 70
+6.44. SetChargingProfile.conf 70
+6.45. StartTransaction.req 71
+6.46. StartTransaction.conf 71
+6.47. StatusNotification.req 71
+6.48. StatusNotification.conf 72
+6.49. StopTransaction.req 72
+6.50. StopTransaction.conf 72
+6.51. TriggerMessage.req. 73
+6.52. TriggerMessage.conf 73
+6.53. UnlockConnector.req 73
+6.54. UnlockConnector.conf. 73
+6.55. UpdateFirmware.req. 73
+6.56. UpdateFirmware.conf 74
+
+7. Types. 75
+
+7.1. AuthorizationData 75
+7.2. AuthorizationStatus 75
+7.3. AvailabilityStatus 75
+7.4. AvailabilityType. 76
+7.5. CancelReservationStatus 76
+7.6. ChargePointErrorCode 76
+7.7. ChargePointStatus 77
+7.8. ChargingProfile 78
+7.9. ChargingProfileKindType 79
+7.10. ChargingProfilePurposeType 79
+7.11. ChargingProfileStatus 80
+7.12. ChargingRateUnitType 80
+7.13. ChargingSchedule 80
+7.14. ChargingSchedulePeriod 81
+7.15. CiString20Type 81
+7.16. CiString25Type 81
+7.17. CiString50Type 82
+7.18. CiString255Type 82
+7.19. CiString500Type 82
+7.20. ClearCacheStatus 82
+7.21. ClearChargingProfileStatus 83
+7.22. ConfigurationStatus. 83
+7.23. DataTransferStatus 83
+7.24. DiagnosticsStatus. 84
+7.25. FirmwareStatus 84
+7.26. GetCompositeScheduleStatus 84
+7.27. IdTagInfo 85
+7.28. IdToken 85
+7.29. KeyValue 85
+7.30. Location. 86
+7.31. Measurand 86
+7.32. MessageTrigger 88
+7.33. MeterValue 88
+7.34. Phase 89
+7.35. ReadingContext 89
+7.36. Reason 90
+7.37. RecurrencyKindType 90
+7.38. RegistrationStatus 91
+7.39. RemoteStartStopStatus.. 91
+7.40. ReservationStatus 91
+7.41. ResetStatus 92
+7.42. ResetType 92
+7.43. SampledValue. 92
+7.44. TriggerMessageStatus 93
+7.45. UnitOfMeasure 93
+7.46. UnlockStatus. 94
+7.47. UpdateStatus 94
+7.48. UpdateType 95
+7.49. ValueFormat 95
+
+8. Firmware and Diagnostics File Transfer 96
+
+8.1. Download Firmware 96
+8.2. Upload Diagnostics 96
+
+9. Standard Configuration Key Names & Values 97
+
+9.1. Core Profile 97
+9.2. Local Auth List Management Profile 106
+9.3. Reservation Profile. 106
+9.4. Smart Charging Profile 107
+
+Appendix A: New in OCPP 1.6 109
+
+A.1. Updated/New Messages: 109
+
+<table><tr><td>Document Version</td><td>1.6 edition 2</td></tr><tr><td>Document Status</td><td>FINAL</td></tr><tr><td>Document Release Date</td><td>2017-09-28</td></tr></table>
+
+Copyright © 2010 - 2017 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
+
+<table><tr><td>VERSION</td><td>DATE</td><td>AUTHOR</td><td>DESCRIPTION</td></tr><tr><td>1.6 edition 2</td><td>2017-09-28</td><td>Robert de Leeuw /Homer
+Brendan McMahon ESB eecs
+Klaas van Zuuren EloadNL</td><td>OCPP 1.6 edition 2 Final release.
+Contains all of the known erratas (including v3.0) and improved styling.</td></tr><tr><td>1.6</td><td>2015-10-08</td><td>Robert de Leeuw /Homer
+Reinier Lamers The New Motion
+Brendan McMahon ESB eecs
+Lambert Muhlenberg Alfen
+Patrick Rademakers /Homer
+Sergiu Tcacic smartlab
+Klaas van Zuuren EloadNL</td><td>1.6 Final Release.
+For changes relative to 1.5, see appendix New in OCPP 1.6.</td></tr><tr><td>1.5</td><td>2012-06-01</td><td>Franc Buve</td><td>Specification ready for release. Includes:
+CR-01 Authentication/authorization lists
+CR-02 Interval meter readings
+CR-03 Charge point reservation
+CR-04 Generic data transfer
+CR-05 More detailed status notifications
+CR-06 Query configuration parameters
+CR-07 Timestamp in BootNotification mandatory
+CR-08 Response to StartTransaction.req with status other than Accepted is not clearly defined
+CR-09 Increase size of firmwareVersion in BootNotification</td></tr><tr><td>1.2</td><td>2011-02-21</td><td>Franc Buve</td><td></td></tr><tr><td>1.0</td><td>2010-10-19</td><td>Franc Buve</td><td>Final version approved by e-laad.nl. Identical to version 0.12.</td></tr></table>
+
+# 1. Scope
+
+This document defines the protocol used between a Charge Point and Central System. If the protocol requires a certain action or response from one side or the other, then this will be stated in this document.
+
+The specification does not define the communication technology. Any technology will do, as long as it supports TCP/IP connectivity.
+
+# 2. Terminology and Conventions
+
+# 2.1. Conventions
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], subject to the following additional clarification clause:
+
+The phrase "valid reasons in particular circumstances" relating to the usage of the terms "SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" is to be taken to mean technically valid reasons, such as the absence of necessary hardware to support a function from a charge point design: for the purposes of this specification it specifically excludes decisions made on commercial, or other non-technical grounds, such as cost of implementation, or likelihood of use.
+
+All sections and appendix, except "Scope" and "Terminology and Conventions", are normative, unless they are explicitly indicated to be informative.
+
+# 2.2. Definitions
+
+This section contains the terminology that is used throughout this document.
+
+<table><tr><td>Central System</td><td>Charge Point Management System: the central system that manages Charge Points and has the information for authorizing users for using its Charge Points.</td></tr><tr><td>CiString</td><td>Case Insensitive String. Only printable ASCII allowed.</td></tr><tr><td>Charge Point</td><td>The Charge Point is the physical system where an electric vehicle can be charged. A Charge Point has one or more connectors.</td></tr><tr><td>Charging Profile</td><td>Generic Charging Profile, used for different types of Profiles. Contains information about the Profile and holds the Charging Schedule. In future versions of OCPP it might hold more than 1 Charging Schedule.</td></tr><tr><td>Charging Schedule</td><td>Part of a Charging Profile. Defines a block of charging Power or Current limits. Can contain a start time and length.</td></tr><tr><td>Charging Session</td><td>A Charging Session is started when first interaction with user or EV occurs. This can be a card swipe, remote start of transaction, connection of cable and/or EV, parking bay occupancy detector, etc.</td></tr><tr><td>Composite Charging Schedule</td><td>The charging schedule as calculated by the Charge Point. It is the result of the calculation of all active schedules and possible local limits present in the Charge Point. Local Limits might be taken into account.</td></tr><tr><td>Connector</td><td>The term "Connector", as used in this specification, refers to an independently operated and managed electrical outlet on a Charge Point. This usually corresponds to a single physical connector, but in some cases a single outlet may have multiple physical socket types and/or tethered cable/connector arrangements to facilitate different vehicle types (e.g. four-wheeled EVs and electric scooters).</td></tr><tr><td>Control Pilot signal</td><td>Signal used by a Charge Point to inform EV of maximum Charging power or current limit, as defined by [IEC61851-1].</td></tr><tr><td>Energy Offer Period</td><td>Energy Offer Period starts when the EVSE is ready and willing to supply energy.</td></tr><tr><td>Energy Offer SuspendPeriod</td><td>During a transaction, there may be periods the EnergyOffer to EV is suspended by the EVSE, for instance due to Smart Charging or local balancing.</td></tr><tr><td>Energy Transfer Period</td><td>Time during which an EV chooses to take offered energy, or return it. Multiple Energy Transfer Periods are possible during a Transaction.</td></tr><tr><td>Local Controller</td><td>Optional device in a smart charging infrastructure. Located on the premises with a number of Charge Points connected to it. Sits between the Charge Points and Central System. Understands and speaks OCPP messages. Controls the Power or Current in other Charge Point by using OCPP smart charging messages. Can be a Charge Point itself.</td></tr><tr><td>OCPP-J</td><td>OCPP via JSON over WebSocket</td></tr><tr><td>OCPP-S</td><td>OCPP via SOAP</td></tr><tr><td>Phase Rotation</td><td>Defines the wiring order of the phases between the electrical meter (or if absent, the grid connection), and the Charge Point connector.</td></tr><tr><td>Transaction</td><td>The part of the charging process that starts when all relevant preconditions (e.g. authorization, plug inserted) are met, and ends at the moment when the Charge Point irrevocably leaves this state.</td></tr><tr><td>String</td><td>Case Sensitive String. Only printable ASCII allowed. All strings in messages and enumerations are case sensitive, unless explicitly stated otherwise.</td></tr></table>
+
+# 2.3. Abbreviations
+
+<table><tr><td>CSL</td><td>Comma Separated List</td></tr><tr><td>CPO</td><td>Charge Point Operator</td></tr><tr><td>DNS</td><td>Domain Name System</td></tr><tr><td>DST</td><td>Daylight Saving Time</td></tr><tr><td>EV</td><td>Electrical Vehicle, this can be BEV (battery EV) or PHEV (plug-in hybrid EV)</td></tr><tr><td>EVSE</td><td>Electric Vehicle Supply Equipment [IEC61851-1]</td></tr><tr><td>FTP(S)</td><td>File Transport Protocol (Secure)</td></tr><tr><td>HTTP(S)</td><td>HyperText Transport Protocol (Secure)</td></tr><tr><td>ICCID</td><td>Integrated Circuit Card Identifier</td></tr><tr><td>IMSI</td><td>International Mobile Subscription Identity</td></tr><tr><td>JSON</td><td>JavaScript Object Notation</td></tr><tr><td>NAT</td><td>Native Address Translation</td></tr><tr><td>PDU</td><td>Protocol Data Unit</td></tr><tr><td>SC</td><td>Smart Charging</td></tr><tr><td>SOAP</td><td>Simple Object Access Protocol</td></tr><tr><td>URL</td><td>Uniform Resource Locator</td></tr><tr><td>RST</td><td>3 phase power connection, Standard Reference Phasing</td></tr><tr><td>RTS</td><td>3 phase power connection, Reversed Reference Phasing</td></tr><tr><td>SRT</td><td>3 phase power connection, Reversed 240 degree rotation</td></tr><tr><td>STR</td><td>3 phase power connection, Standard 120 degree rotation</td></tr><tr><td>TRS</td><td>3 phase power connection, Standard 240 degree rotation</td></tr><tr><td>TSR</td><td>3 phase power connection, Reversed 120 degree rotation</td></tr><tr><td>UTC</td><td>Coordinated Universal Time</td></tr></table>
+
+# 2.4. References
+
+<table><tr><td>[IEC61851-1]</td><td>"IEC 61851-1 2010: Electric vehicle conductive charging system - Part 1: General requirements" https://webstore.iec.ch/publication/6029</td></tr><tr><td>[OCPP1.5]</td><td>"OCPP 1.5: Open Charge Proint Protocol 1.5" http://www.openchargealliance.org/downloads/</td></tr><tr><td>[OCPP_1.6CT]</td><td>"OCPP 1.6 Compliance testing" http://www.openchargealliance.org/downloads/</td></tr><tr><td>[OCPP_IMP_J]</td><td>"OCPP JSON Specification" http://www.openchargealliance.org/downloads/</td></tr><tr><td>[OCPP_IMP_S]</td><td>"OCPP SOAP Specification" http://www.openchargealliance.org/downloads/</td></tr><tr><td>[RFC2119]</td><td>"Key words for use in RFCs to Indicate Requirement Levels". S. Bradner. March 1997. http://www.ietf.org/rfc/rfc2119.txt</td></tr></table>
+
+# 3. Introduction
+
+This is the specification for OCPP version 1.6.
+
+OCPP is a standard open protocol for communication between Charge Points and a Central System and is designed to accommodate any type of charging technique.
+
+OCPP 1.6 introduces new features to accommodate the market: Smart Charging, OCPP using JSON over Web sockets, better diagnostics possibilities (Reason), more Charge Point Statuses and TriggerMessage. OCPP 1.6 is based on OCPP 1.5, with some new features and a lot of textual improvements, clarifications and fixes for all known ambiguities. Due to improvements and new features, OCPP 1.6 is not backward compatible with OCPP 1.5.
+
+For a full list of changes, see: New in OCPP 1.6.
+
+Some basic concepts are explained in the sections below in this introductory chapter. The chapters: Operations Initiated by Charge Point and Operations Initiated by Central System describe the operations supported by the protocol. The exact messages and their parameters are detailed in the chapter: Messages and data types are described in chapter: Types. Defined configuration keys are described in the chapter: Standard Configuration Key Names & Values.
+
+# 3.1. Edition 2
+
+This document is OCPP 1.6 edition 2. This document still describes the same protocol: OCPP 1.6, only the documentation is improved. On message level there are no changes compared to the original release of OCPP 1.6 of October 2015. All known errata (previously published in a separate document) have been merged into this document, making it easier for the implementers to work with the specification. When there is doubt about the way OCPP 1.6 should be implemented, this document over rules the original document.
+
+# 3.2. Document structure
+
+With the introduction of OCPP 1.6, there are two different flavours of OCPP; next to the SOAP based implementations, there is the possibility to use the much more compact JSON alternative. To avoid confusion in communication on the type of implementation we recommend using the distinct suffixes -J and -S to indicate JSON or SOAP. In generic terms this would be OCPP-J for JSON and OCPP-S for SOAP.
+
+To support the different flavours, the OCPP standard is divided in multiple documents. The base document (the one you are reading now) contains the technical protocol specification. The technical protocol specification must be used with one of the transport protocol specifications. the OCPP SOAP Specification contains the implementation specification needed to make a OCPP-S implementation. For OCPP-J, the OCPP JSON Specification must be used.
+
+For improved interoperability between the Central Systems and Charge Points, it is advised to meet the requirements stated in the OCPP 1.6 Compliance testing documentation.
+
+# 3.3. Feature Profiles
+
+This section is normative.
+
+In OCPP 1.6 features and associated messages are grouped in profiles. Depending on the required functionality, implementers can choose to implement one or more of the following profiles.
+
+<table><tr><td>PROFILE NAME</td><td>DESCRIPTION</td></tr><tr><td>Core</td><td>Basic Charge Point functionality comparable with OCPP 1.5 [OCPP1.5] without support for firmware updates, local authorization list management and reservations.</td></tr><tr><td>Firmware Management</td><td>Support for firmware update management and diagnostic log file download.</td></tr><tr><td>Local Auth List Management</td><td>Features to manage the local authorization list in Charge Points.</td></tr><tr><td>Reservation</td><td>Support for reservation of a Charge Point.</td></tr><tr><td>Smart Charging</td><td>Support for basic Smart Charging, for instance using control pilot.</td></tr><tr><td>Remote Trigger</td><td>Support for remote triggering of Charge Point initiated messages</td></tr></table>
+
+These profiles can be used by a customer to determine if a OCPP 1.6 product has the required functionality for their business case. Compliance testing will test per profile if a product is compliant with the OCPP 1.6 specification.
+
+Implementation of the Core profile is required. Other profiles are optional.
+
+When the profiles Core, Firmware Management, Local Auth List Management and Reservation are implemented, all functions originating from OCPP 1.5 [OCPP1.5] are covered.
+
+The grouping of all messages in their profiles can be found in the table below.
+
+<table><tr><td>MESSAGE</td><td>CORE</td><td>FIRMWARE
+MANAGEMENT</td><td>LOCAL AUTH
+LIST
+MANAGEMENT</td><td>REMOTE
+TRIGGER</td><td>RESERVATION</td><td>SMART
+CHARGING</td></tr><tr><td>Authorization</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>BootNotification</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>ChangeAvailability</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>ChangeConfiguration</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>ClearCache</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>DataTransfer</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>GetConfiguration</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Heartbeat</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>MeterValues</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>RemoteStartTransaction</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>RemoteStopTransaction</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Reset</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>StartTransaction</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>StatusNotification</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>StopTransaction</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>UnlockConnector</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>GetDiagnostics</td><td></td><td>X</td><td></td><td></td><td></td><td></td></tr><tr><td>DiagnosticsStatusNotification</td><td></td><td>X</td><td></td><td></td><td></td><td></td></tr><tr><td>FirmwareStatusNotification</td><td></td><td>X</td><td></td><td></td><td></td><td></td></tr><tr><td>UpdateFirmware</td><td></td><td>X</td><td></td><td></td><td></td><td></td></tr><tr><td>GetLocalListVersion</td><td></td><td></td><td>X</td><td></td><td></td><td></td></tr><tr><td>SendLocalList</td><td></td><td></td><td>X</td><td></td><td></td><td></td></tr><tr><td>CancelReservation</td><td></td><td></td><td></td><td>X</td><td></td><td></td></tr><tr><td>ReserveNow</td><td></td><td></td><td></td><td>X</td><td></td><td></td></tr><tr><td>ClearChargingProfile</td><td></td><td></td><td></td><td></td><td>X</td><td></td></tr><tr><td>GetCompositeSchedule</td><td></td><td></td><td></td><td></td><td>X</td><td></td></tr><tr><td>SetChargingProfile</td><td></td><td></td><td></td><td></td><td>X</td><td></td></tr><tr><td>TriggerMessage</td><td></td><td></td><td></td><td></td><td></td><td>X</td></tr></table>
+
+The support for the specific feature profiles is reported by the SupportedFeatureProfiles configuration key.
+
+# 3.4. General views of operation
+
+This section is informative.
+
+The following figures describe the general views of the operations between Charge Point and Central System for two cases:
+
+1. a Charge Point requesting authentication of a card and sending charge transaction status,
+2. Central System requesting a Charge Point to update its firmware.
+
+The arrow labels in the following figures indicate the PDUs exchanged during the invocations of the operations. These PDUs are defined in detail in the Messages section.
+
+
+Figure 1. Sequence Diagram: Example of starting and stopping a transaction
+
+When a Charge Point needs to charge an electric vehicle, it needs to authenticate the user first before the charging can be started. If the user is authorized the Charge Point informs the Central System that it has started with charging.
+
+When a user wishes to unplug the electric vehicle from the Charge Point, the Charge Point needs to verify that the user is either the one that initiated the charging or that the user is in the same group and thus allowed to terminate the charging. Once authorized, the Charge Point informs the Central System that the charging has been stopped.
+
+
+
+A Charge Point MUST NOT send an Authorization.req before stopping a transaction if the presented idTag is the same as the idTag presented to start the transaction.
+
+
+Figure 2. Sequence Diagram: Example of a firmware update
+
+When a Charge Point needs to be updated with new firmware, the Central System informs the Charge Point of the time at which the Charge Point can start downloading the new firmware. The Charge Point SHALL notify the Central System after each step as it downloads and installs the new firmware.
+
+# 3.5. Local Authorization & Offline Behavior
+
+This section is normative.
+
+In the event of unavailability of the communications or even of the Central System, the Charge Point is designed to operate stand-alone. In that situation, the Charge Point is said to be offline.
+
+To improve the experience for users, a Charge Point MAY support local authorization of identifiers, using an Authorization Cache and/or a Local Authorization List.
+
+This allows (a) authorization of a user when offline, and (b) faster (apparent) authorization response time when communication between Charge Point and Central System is slow.
+
+The LocalAuthorizationOffline configuration key controls whether a Charge Point will authorize a user when offline using the Authorization Cache and/or the Local Authorization List.
+
+The LocalPreauthorize configuration key controls whether a Charge Point will use the Authorization Cache and/or the Local Authorization List to start a transaction without waiting for an authorization response from the Central System.
+
+A Charge Point MAY support the (automatic) authorization of any presented identifier when offline, to avoid refusal of charging to bona-fide users that cannot be explicitly authorized by Local Authorization List/Authorization Cache entries. This functionality is explained in more detail in Unknown Offline Authorization.
+
+# 3.5.1. Authorization Cache
+
+A Charge Point MAY implement an Authorization Cache that autonomously maintains a record of previously presented identifiers that have been successfully authorized by the Central System. (Successfully meaning: a response received on a message containing an idTag)
+
+If implemented, the Authorization Cache SHOULD conform to the following semantics:
+
+- The Cache contains all the latest received identifiers (i.e. valid and NOT-valid).
+- The Cache is updated using all received IdTagInfo (from Authorization.conf, StartTransaction.conf and StopTransaction.conf)
+- When the validity of a Cache entry expires, it SHALL be changed to expired in the Cache.
+- When an IdTagInfo is received for an identifier in the Cache, it SHALL be updated.
+- If new identifier authorization data is received and the Authorization Cache is full, the Charge Point SHALL remove any NOT-valid entries, and then, if necessary, the oldest valid entries to make space for the new entry.
+- Cache values SHOULD be stored in non-volatile memory, and SHOULD be persisted across reboots and power outages.
+- When an identifier is presented that is stored in the cache as NOT-valid, and the Charge Point is online: an Authorization.req SHOULD be sent to the central System to check the current state of the identifier.
+
+Operation of the Authorization Cache, when present, is reported (and controlled, where possible) by the AuthorizationCacheEnabled configuration key.
+
+# 3.5.2. Local Authorization List
+
+The Local Authorization List is a list of identifiers that can be synchronized with the Central System.
+
+The list contains the authorization status of all (or a selection of) identifiers and the authorization status/expiration date.
+
+Identifiers in the Local Authorization list can be marked as valid, expired, (temporarily) blocked, or blacklisted, corresponding to IdTagInfo status values Accepted/ConcurrentTx, Expired,Blocked, and Invalid, respectively.
+
+These values may be used to provide more fine grained information to users (e.g. by display message) during local authorization.
+
+The Local Authorization List SHOULD be maintained by the Charge Point in non-volatile memory, and SHOULD be persisted across reboots and power outages.
+
+A Charge Point that supports Local Authorization List SHOULD implement the configuration key: LocalAuthListMaxLength This gives the Central System a way to know the the maximum possible number of Local Authorization List elements in a Charge Point
+
+The Charge Point indicates whether the Local Authorization List is supported by the presence or absence of the LocalAuthListManagement element in the value of the SupportedFeatureProfiles configuration key.
+
+Whether the Local Authorization List is enabled is reported and controlled by the LocalAuthListEnabled configuration key.
+
+The Central System can synchronize this list by either (1) sending a complete list of identifiers to replace the Local Authorization List or (2) by sending a list of changes (add, update, delete) to apply to the Local Authorization List. The operations to support this are Get Local List Version and Send Local List.
+
+
+Figure 3. Sequence Diagram: Example of a full local authorization list update
+
+
+Figure 4. Sequence Diagram: Example of a differential local authorization list update
+
+The Charge Point SHALL NOT modify the contents of the Authorization List by any other means than upon a the receipt of a SendLocalList PDU from the Central System.
+
+
+
+Conflicts between the local authorization list and the validity reported in, for instance, a StartTransaction.conf message might occur. When this happens the Charge Point SHALL inform the Central System by sending a StatusNotification with ConnectorId set to 0, andErrorCode set to 'LocalListConflict'.
+
+# 3.5.3. Relation between Authorization Cache and Local Authorization List
+
+The Authorization Cache and Local Authorization List are distinct logical data structures. Identifiers known in the Local Authorization List SHALL NOT be added to the Authorization Cache.
+
+Where both Authorization Cache and Local Authorization List are supported, a Charge Point SHALL treat Local Authorization List entries as having priority over Authorization Cache entries for the same identifiers.
+
+# 3.5.4. Unknown Offline Authorization
+
+When offline, a Charge Point MAY allow automatic authorization of any "unknown" identifiers that cannot be explicitly authorized by Local Authorization List or Authorization Cache entries. Identifiers that are present in a Local Authorization List that have a status other than "Accepted" (Invalid, Restricted, Expired) MUST be rejected. Identifiers that were valid but are apparently expired due to passage of time MUST also be rejected.
+
+Operation of the Unknown Offline Authorization capability, when supported, is reported (and controlled, where possible) by the AllowOfflineTxForUnknownId configuration key.
+
+When connection to the Central Server is restored, the Charge Point SHALL send a Start Transaction request for any transaction that was authorized offline, as required by transaction-related message handling. When the authorization status in the StartTransaction.conf is not Accepted, and the transaction is still ongoing, the Charge Point SHOULD:
+
+- when StopTransactionOnInvalidId is set to true: stop the transaction normally as stated in Stop Transaction. The Reason field in the Stop Transaction request should be set to DeAuthorized. If the Charge Point has the possibility to lock the Charging Cable, it SHOULD keep the Charging Cable locked until the owner presents his identifier.
+- when StopTransactionOnInvalidId is set to false: only stop energy delivery to the vehicle.
+
+
+
+In the case of an invalid identifier, an operator MAY choose to charge the EV with a minimum amount of energy so the EV is able to drive away. This amount is controlled by the optional configuration key: MaxEnergyOnInvalidId.
+
+# 3.6. Transaction in relation to Energy Transfer Period
+
+This section is informative.
+
+The Energy Transfer Period is a period of time during which energy is transferred between the EV and the EVSE. There MAY be multiple Energy Transfer Periods during a Transaction.
+
+Multiple Energy Transfer Periods can be separated by either:
+
+- an EVSE-initiated supense of transfer during which de EVSE does not offer energy transfer
+- an EV-initiated suspense of transfer during which the EV remains electrically connected to the EVSE
+- an EV-initiated suspense of transfer during which the EV is not electrically connected to the EVSE.
+
+A Central System MAY deduce the start and end of an Energy Transfer Period from: the MeterValues that are sent during the Transaction, the status notifications: Charging, SuspendedEV and/or SuspendedEVSE. etc. Central System implementations need to take into account factors such as: Some EVs don't go to state SuspendedEV: they might continue to trickle charge. Some Charge Point don't even have a electrical meter.
+
+
+Figure 5. OCPP Charging Session and transaction definition
+
+# 3.7. Transaction-related messages
+
+This section is normative.
+
+The Charge Point SHOULD deliver transaction-related messages to the Central System in chronological order as soon as possible. Transaction-related messages are StartTransaction.req, StopTransaction.req and periodic or clock-aligned MeterValues.req messages.
+
+When offline, the Charge Point MUST queue any transaction-related messages that it would have sent to the Central System if the Charge Point had been online.
+
+In the event that a Charge Point has transaction-related messages queued to be sent to the Central System, new messages that are not transaction-related MAY be delivered immediately without waiting for the queue to be emptied. It is therefore allowed to send, for example, an Authorization request or a Notifications request before the transaction-related message queue has been emptied, so that customers are not kept waiting and urgent notifications are not delayed.
+
+The delivery of new transaction-related messages SHALL wait until the queue has been emptied. This is to ensure that transaction-related messages are always delivered in chronological order.
+
+When the Central System receives a transaction-related message that was queued on the Charge Point for some time, the Central System will not be aware that this is a historical message, other than by inference given that the various timestamps are significantly in the past. It SHOULD process such a message as any other.
+
+# 3.7.1. Error responses to transaction-related messages
+
+It is permissible for the Charge Point to skip a transaction-related message if and only if the Central System repeatedly reports a `failure to process the message'. Such a stipulation is necessary, because otherwise the requirement to deliver every transaction-related message in chronological order would entail that the Charge Point cannot deliver any transaction-related messages to the Central System after a software bug causes the Central System not to acknowledge one of the Charge Point's transaction-related messages.
+
+What kind of response, or failure to respond, constitutes a `failure to process the message' is defined in the documents OCPP JSON Specification and OCPP SOAP Specification.
+
+The number of times and the interval with which the Charge Point should retry such failed transaction-related messages MAY be configured using the TransactionMessageAttempts and
+
+TransactionMessageRetryInterval configuration keys.
+
+When the Charge Point encounters a first failure to deliver a certain transaction-related message, it SHOULD send this message again as long as it keeps resulting in a failure to process the message and it has not yet encountered as many failures to process the message for this message as specified in its
+
+TransactionMessageAttempts configuration key. Before every retransmission, it SHOULD wait as many seconds as specified in its TransactionMessageRetryInterval key, multiplied by the number of preceding transmissions of this same message.
+
+As an example, consider a Charge Point that has the value "3" for the TransactionMessageAttempts configuration key and the value "60" for the TransactionMessageRetryInterval configuration key. It sends a StopTransaction message and detects a failure to process the message in the Central System. The Charge Point
+
+SHALL wait for 60 seconds, and resend the message. In the case when there is a second failure, the Charge Point SHALL wait for 120 seconds, before resending the message. If this final attempt fails, the Charge Point SHOULD discard the message and continue with the next transaction-related message, if there is any.
+
+# 3.8. Connector numbering
+
+This section is normative.
+
+To enable Central System to be able to address all the connectors of a Charge Point, ConnectorIds MUST always be numbered in the same way.
+
+Connectors numbering (Connectorlds) MUST be as follows:
+
+- ID of the first connector MUST be 1
+ Additional connectors MUST be sequentially numbered (no numbers may be skipped)
+- ConnectorIds MUST never be higher than the total number of connectors of a Charge Point
+- For operations initiated by the Central System, ConnectorId 0 is reserved for addressing the entire Charge Point.
+- For operations initiated by the Charge Point (when reporting), Connectorld 0 is reserved for the Charge Point main controller.
+
+Example: A Charge Point with 3 connectors: All connectors MUST be numbered with the IDs: 1, 2 and 3. It is advisable to number the connectors of a Charge Point in a logical way: from left to right, top to bottom incrementing.
+
+# 3.9. ID Tokens
+
+This section is normative.
+
+In most cases, IdToken data acquired via local token reader hardware is usually a (4 or 7 byte) UID value of a physical RFID card, typically represented as 8/14 hexadecimal digit characters.
+
+However, IdTokens sent to Charge Points by Central Systems for remotely initiated charging sessions may commonly be (single use) virtual transaction authorization codes, or virtual RFID tokens that deliberately use a non-standard UID format to avoid possible conflict with real UID values.
+
+Also, IdToken data used as ParentIds may often use a shared central account identifier for the ParentId, instead of a UID of the first/master RFID card of an account.
+
+Therefore, message data elements of the IdToken class (including ParentId) MAY contain any data, subject to the constraints of the data-type (CiString20Type), that is meaningful to a Central System (e.g. for the purpose of identifying the initiator of charging activity), and Charge Points MUST NOT make any presumptions as to the format or content of such data (e.g. by assuming that it is a UID-like value that must be hex characters only and/or an even number of digits).
+
+To promote interoperability, based on common practice to date in the case of IdToken data representing physical ISO 14443 compatible RFID card UIDs, it is RECOMMENDED that such UIDs be represented as hex representations of the UID bytes. According to ISO14443-3, byte 0 should come first in the hex string.
+
+# 3.10. Parent idTag
+
+This section is normative.
+
+A Central System has the ability to treat a set of identity tokens as a "group", thereby allowing any one token in the group to start a transaction and for the same token, or another token in the same group, to stop the transaction. This supports the common use-cases of families or businesses with multiple drivers using one or more shared electric vehicles on a single recharging contract account.
+
+Tokens (idTags) are grouped for authorization purposes by specifying a common group identifier in the optional ParentId element in IdTagInfo: two idTags are considered to be in the same group if their ParentId Tags match.
+
+
+
+Even though the ParentId has the same nominal data type (IdToken) as an idTag, the value of this element may not be in the common format of IdTokens and/or may not represent an actual valid IdToken (e.g. it may be a common shared "account number"): therefore, the ParentId value SHOULD NOT be used for comparison against a presented Token value (unless it also occurs as an idTag value).
+
+# 3.11. Reservations
+
+This section is informative.
+
+Reservation of a Charge Point is possible using the Reserve Now operation. This operation reserves the Charge Point until a certain expiry time for a specific idTag. A parent idTag may be included in the reservation to support 'group' reservations. It is possible to reserve a specific connector on a Charge Point or to reserve any connector on a Charge Point. A reservation is released when the reserved idTag is used on the reserved connector (when specified) or on any connector (when unspecified) or when the expiry time is reached or when the reservation is explicitly canceled.
+
+# 3.12. Vendor-specific data transfer
+
+This section is informative.
+
+The mechanism of vendor-specific data transfer allows for the exchange of data or messages not standardized in OCPP. As such, it offers a framework within OCPP for experimental functionality that may find its way into future OCPP versions. Experimenting can be done without creating new (possibly incompatible) OCPP dialects. Secondly, it offers a possibility to implement additional functionality agreed upon between specific Central System and Charge Point vendors.
+
+The operation Vendor Specific Data MAY be initiated either by the Central System or by the Charge Point.
+
+Please use with extreme caution and only for optional functionality, since it will impact your compatibility with other systems that do not make use of this option. We recommend mentioning the usage explicitly in your documentation and/or communication. Please consider consulting the Open Charge Alliance before turning to this option to add functionality.
+
+# 3.13. Smart Charging
+
+This section is normative.
+
+With Smart Charging a Central System gains the ability to influence the charging power or current of a specific EV, or the total allowed energy consumption on an entire Charge Point / a group of Charge Points, for instance, based on a grid connection, energy availability on the gird or the wiring of a building. Influencing the charge power or current is based on energy transfer limits at specific points in time. Those limits are combined in a Charging Profile.
+
+# 3.13.1. Charging profile purposes
+
+A charging profile consists of a charging schedule, which is basically a list of time intervals with their maximum charge power or current, and some values to specify the time period and recurrence of the schedule.
+
+There are three different types of charging profiles, depending on their purpose:
+
+- ChargePointMaxProfile
+
+In load balancing scenarios, the Charge Point has one or more local charging profiles that limit the power or current to be shared by all connectors of the Charge Point. The Central System SHALL configure such a profile with ChargingProfilePurpose set to "ChargePointMaxProfile". ChargePointMaxProfile can only be set at Charge Point ConnectorId 0.
+
+- TxDefaultProfile
+
+Default schedules for new transactions MAY be used to impose charging policies. An example could be a policy that prevents charging during the day. For schedules of this purpose, ChargingProfilePurpose SHALL be set to TxDefaultProfile.
+
+If TxDefaultProfile is set to ConnectorId 0, the TxDefaultProfile is applicable to all Connectors.
+
+If Connectorld is set $>0$ , it only applies to that specific connector.
+
+In the event a TxDefaultProfile for connector 0 is installed, and the Central System sends a new profile with ConnectorId $>0$ , the TxDefaultProfile SHALL be replaced only for that specific connector.
+
+- TxProfile
+
+If a transaction-specific profile with purpose TxProfile is present, it SHALL overrule the default charging profile with purpose TxDefaultProfile for the duration of the current transaction only. After the transaction is stopped, the profile SHOULD be deleted. If there is no transaction active on the connector specified in a charging profile of type TxProfile, then the Charge Point SHALL discard it and return an error status in SetChargingProfile.conf.
+
+The final schedule constraints that apply to a transaction are determined by merging the profiles with purposes ChargePointMaxProfile with the profile TxProfile or the TxDefaultProfile in case no profile of purpose TxProfile is provided. TxProfile SHALL only be set at Charge Point ConnectorId >0.
+
+# 3.13.2. Stacking charging profiles
+
+It is allowed to stack charging profiles of the same charging profile purpose in order to describe complex calendars. For example, one can define a charging profile of purpose TxDefaultProfile with a duration and recurrence of one week that allows full power or current charging on weekdays from 23:00h to 06:00h and from 00:00h to 24:00h in weekends and reduced power or current charging at other times. On top of that, one can define other TxDefaultProfiles that define exception to this rule, for example for holidays.
+
+Precedence of charging profiles is determined by the value of their StackLevel parameter. At any point in time the prevailing charging profile SHALL be the charging profile with the highest stackLevel among the profiles that are valid at that point in time, as determined by their validFrom and validTo parameters.
+
+To avoid conflicts, the existence of multiple Charging Profiles with the same stackLevel and Purposes in a Charge Point is not allowed. Whenever a Charge Point receives a Charging Profile with a stackLevel and Purpose that already exists in the Charge Point, the Charge Point SHALL replace the existing profile.
+
+
+
+In the case an updated charging profile (with the same stackLevel and purpose) is sent with a validFromDateTime in the future, the Charge Point SHALL replace the installed profile and SHALL revert to default behavior until validFrom is reached. It is RECOMMENDED to provide a start time in the past to prevent gaps.
+
+
+
+If you use Stacking without a duration, on the highest stack level, the Charge Point will never fall back to a lower stack level profile.
+
+# 3.13.3. Combining charging profile purposes
+
+The Composite Schedule that will guide the charging level is a combination of the prevailing Charging Profiles of the different chargingProfilePurposes.
+
+This Composite Schedule is calculated by taking the minimum value for each time interval. Note that time intervals do not have to be of fixed length, nor do they have to be the same for every charging profile purpose. This means that a resulting Composite Schedule MAY contain intervals of different lengths.
+
+At any point in time, the available power or current in the Composite Schedule, which is the result of merging the schedules of charging profiles ChargePointMaxProfile and TxDefaultProfile (or TxProfile), SHALL be less than or equal to lowest value of available power or current in any of the merged schedules.
+
+In the case the Charge Point is equipped with more than one Connector, the limit value of ChargePointMaxProfile is the limit for all connectors combined. The combined energy flow of all connectors SHALL NOT be greater then the limit set by ChargePointMaxProfile.
+
+# 3.13.4. Smart Charging Use Cases
+
+This section is informative.
+
+There may be many different uses for smart charging. The following three typical kinds of smart charging will be used to illustrate the possible behavior of smart charging:
+
+- Load balancing
+ Central smart charging
+- Local smart charging
+
+There are more complex use cases possible in which two or more of the above use cases are combined into one more complex system.
+
+# Load Balancing
+
+This section is informative.
+
+The Load Balancing use case is about internal load balancing within the Charge Point, the Charge Point controls the charging schedule per connector. The Charge Point is configured with a fixed limit, for example the maximum current of the connection to the grid.
+
+The optional charging schedule field minChargingRate may be used by the Charge Point to optimize the power distribution between the connectors. The parameter informs the Charge Point that charging below minChargingRate is inefficient, giving the possibility to select another balancing strategy.
+
+
+Figure 6. Load balancing Smart Charging topology
+
+# Central Smart Charging
+
+This section is informative.
+
+With Central smart charging the constraints on the charging schedule, per transaction, are determined by the Central System. The Central System uses these schedules to stay within limits imposed by any external system.
+
+The Central System directly controls the limits on the connectors of the Charge Points.
+
+
+Figure 7. Central Smart Charging topology
+
+Central smart charging assumes that charge limits are controlled by the Central System. The Central System receives a capacity forecast from the grid operator (DSO) or another source in one form or another and calculates charging schedules for some or all charging transactions, details of which are out of scope of this specification.
+
+The Central System imposes charging limits on connectors. In response to a StartTransaction.req PDU The Central System may choose to set charging limits to the transaction using the TxProfile
+
+Central Smart Charging can be done with a Control Pilot signal, albeit with some limitations, because an EV cannot communicate its charging via the Control Pilot signal. In analogy to the Local Smart Charging use case, a connector can execute a charging schedule by the Control Pilot signal. This is illustrated in the Figure below:
+
+
+Figure 8. Sequence Diagram: Central Smart Charging
+
+Explanation for the above figure:
+
+- After authorization the connector will set a maximum current to use via the Control Pilot signal. This limit is based on a (default) charging profile that the connector had previously received from the Central System. The EV starts charging and a StartTransaction.req is sent to the Central System.
+- While charging is in progress the connector will continuously adapt the maximum current or power according to the charging profile. Optionally, at any point in time the Central System may send a new charging profile for the connector that shall be used as a limit schedule for the EV.
+
+# Local Smart Charging
+
+The Local Smart Charging use case describes a use case in which smart charging enabled Charge Points have charging limits controlled locally by a Local Controller, not the Central System. The use case for local smart charging is about limiting the amount of power that can be used by a group of Charge Points, to a certain maximum. A typical use would be a number of Charge Points in a parking garage where the rating of the connection to the grid is less than the sum the ratings of the Charge Points. Another application might be that the Local Controller receives information about the availability of power from a DSO or a local smart grid node.
+
+
+Figure 9. Local Smart Charging topology
+
+Local smart charging assumes the existence of a Local Controller to control a group of Charge Points. The Local Controller is a logical component. It may be implemented either as a separate physical component or as part of a 'master' Charge Point controlling a number of other Charge Points. The Local Control implements the OCPP protocol and is a proxy for the group members' OCPP messages, and may or may not have any connectors of its own.
+
+In the case of local smart charging the Local Controller imposes charging limits on a Charge Point. These limits may be changed dynamically during the charging process in order to keep the power consumption of the group of Charge Points within the group limits. The group limits may be pre-configured in the Local Controller or may have been configured by the Central System.
+
+The optional charging schedule field minChargingRate may be used by the Local Controller to optimize the power distribution between the connectors. The parameter informs the Local Controller that charging below minChargingRate is inefficient, giving the possibility to select another balancing strategy.
+
+The following diagram illustrates the sequence of messages to set charging limits on Charge Points in a Local Smart Charging group. These limits can either be pre-configured in the Local Controller in one way or another, or they can be set by the Central System. The Local Controller contains the logic to distribute this capacity among the connected connectors by adjusting their limits as needed.
+
+
+Figure 10. Presetting Local Group Limits
+
+The next diagram describes the sequence of messages for a typical case of Local Smart Charging. For simplicity's sake, this case only involves one connector.
+
+
+Figure 11. Sequence Diagram: Local Smart Charging
+
+# Explanation for the above figure:
+
+- After authorization the connector will set a maximum current to use, via the Control Pilot signal. This limit is based on a (default) charging profile that the connector had previously received from the Local Controller. The EV starts charging and sends a StartTransaction.req.
+- The StartTransaction.req is sent to the Central System via the Local Controller, so that also the Local Controller knows a transaction has started. The Local Controller just passes on the messages between Charge Point and Central System, so that the Central System can address all the Local Smart Charging group members individually.
+- While charging is in progress the connector will continuously adapt the maximum current according to the charging profile.
+
+Optionally, at any point in time the Local Controller may send a new charging profile to the connector that shall be used as a limit schedule for the EV.
+
+# 3.13.5. Discovery of Charge Point Capabilities
+
+This section is normative.
+
+The smart charging options defined can be used in extensive ways. Because of the possible limitations and differences in capabilities between Charge Points, the Central System needs to be able to discover the Charge Point specific capabilities. This is ensured by the standardized configuration keys as defined in this chapter. A Smart Charging enabled Charge Point SHALL implement, and support reporting of, the following configuration keys through the GetConfiguration.req PDU
+
+# SMART CHARGING CONFIGURATION KEYS
+
+ChargeProfileMaxStackLevel
+
+ChargingScheduleAllowedChargingRateUnit
+
+ChargingScheduleMaxPeriods
+
+MaxChargingProfilesInstalled
+
+A full list of all standardized configuration keys can be found in chapter Standard Configuration Key Names & Values.
+
+# 3.13.6. Offline behavior of smart charging
+
+This section is normative.
+
+If a Charge Point goes offline after having received a transaction-specific charging profile with purpose TxProfile, then it SHALL continue to use this profile for the duration of the transaction.
+
+If a Charge Point goes offline before a transaction is started or before a transaction-specific charging profile with purpose TxProfile was received, then it SHALL use the charging profiles that are available. Zero or more of the following charging profile purposes MAY have been previously received from the Central System:
+
+\*ChargePointMaxProfile
+
+\*TxDefaultProfile
+
+See section Combining Charging Profile Purposes for a description on how to combine charging profiles with different purposes.
+
+If a Charge Point goes offline, without having any charging profiles, then it SHALL execute a transaction as if no constraints apply.
+
+# 3.13.7. Example data structure for smart charging
+
+This section is informative
+
+The following data structure describes a daily default profile that limits the power to 6 kW between 08:00h and 20:00h.
+
+CHARGINGPROFILE
+
+<table><tr><td>chargingProfileId</td><td>100</td><td></td><td></td></tr><tr><td>stackLevel</td><td>0</td><td></td><td></td></tr><tr><td>chargingProfilePurpose</td><td>TxDefaultProfile</td><td></td><td></td></tr><tr><td>chargingProfileKind</td><td>Recurring</td><td></td><td></td></tr><tr><td>recurrencyKind</td><td>Daily</td><td></td><td></td></tr><tr><td>chargingSchedule</td><td>(List of 1 ChargingScheduleelements)</td><td></td><td></td></tr><tr><td></td><td>ChargingSchedule</td><td></td><td></td></tr><tr><td></td><td>duration</td><td>86400 (=24 hours)</td><td></td></tr><tr><td></td><td>startSchedule</td><td>2013-01-01T00:00Z</td><td></td></tr><tr><td></td><td>chargingRateUnit</td><td>W</td><td></td></tr><tr><td></td><td>chargingSchedulePeriod</td><td>(List of 3ChargingSchedulePeriodelements)</td><td></td></tr><tr><td></td><td></td><td>ChargingSchedulePeriod</td><td></td></tr><tr><td></td><td></td><td>startPeriod</td><td>0 (=00:00)</td></tr><tr><td></td><td></td><td>limit</td><td>11000</td></tr><tr><td></td><td></td><td>numberPhases</td><td>3</td></tr><tr><td></td><td></td><td>startPeriod</td><td>28800 (=08:00)</td></tr><tr><td></td><td></td><td>limit</td><td>6000</td></tr><tr><td></td><td></td><td>numberPhases</td><td>3</td></tr><tr><td></td><td></td><td>startPeriod</td><td>72000 (=20:00)</td></tr><tr><td></td><td></td><td>limit</td><td>11000</td></tr><tr><td></td><td></td><td>numberPhases</td><td>3</td></tr></table>
+
+#
+
+The amount of phases used during charging is limited by the capabilities of: The Charge Point, EV and Cable between CP and EV. If any of these 3 is not capable of 3 phase charging, the EV will be charged using 1 phase only.
+
+#
+
+Switching the number of used phases during a schedule or charging session should be done with care. Some EVs may not support this and changing the amount of phases may result in physical damage. With the configuration key: ConnectorSwitch3to1PhaseSupported The Charge Point can tell if it supports switching the amount of phases during a transaction.
+
+#
+
+On days on which DST goes into or out of effect, a special profile might be needed (e.g. for relative profiles).
+
+# 3.14. Time zones
+
+This section is informative.
+
+OCPP does not prescribe the use of a specific time zone for time values. However, it is strongly recommended to use UTC for all time values to improve interoperability between Central Systems and Charge Points.
+
+# 3.15. Time notations
+
+This section is normative.
+
+Implementations MUST use ISO 8601 date time notation. Message receivers must be able to handle fractional seconds and time zone offsets (another implementation might use them). Message senders MAY save data usage by omitting insignificant fractions of seconds.
+
+# 3.16. Metering Data
+
+This section is normative.
+
+Extensive metering data relating to charging sessions can be recorded and transmitted in different ways depending on its intended purpose. There are two obvious use cases (but the use of meter values is not limited to these two):
+
+- Charging Session Meter Values
+- Clock-Aligned Meter Values
+
+Both types of meter readings MAY be reported in standalone MeterValues.req messages (during a transaction) and/or as part of the transactionData element of the StopTransaction.req PDU.
+
+# 3.16.1. Charging Session Meter Values
+
+Frequent (e.g. 1-5 minute interval) meter readings taken and transmitted (usually in "real time") to the Central System, to allow it to provide information updates to the EV user (who is usually not at the charge point), via web, app, SMS, etc., as to the progress of the charging session. In OCPP, this is called "sampled meter data", as the exact frequency and time of readings is not very significant, as long as it is "frequent enough". "Sampled meter data" can be configured with the following configuration keys:
+
+- MeterValuesSampledData
+- MeterValuesSampledDataMaxLength
+- MeterValueSampleInterval
+- StopTxnSampledData
+- StopTxnSampledDataMaxLength
+
+MeterValueSampleInterval is the time (in seconds) between sampling of metering (or other) data, intended to be transmitted by "MeterValues" PDUs. Samples are acquired and transmitted periodically at this interval from the start of the charging transaction.
+
+A value of "0" (numeric zero), by convention, is to be interpreted to mean that no sampled data should be transmitted.
+
+MeterValuesSampledData is a comma separated list that prescribes the set of measurands to be included in a MeterValues.req PDU, every MeterValueSampleInterval seconds. The maximum amount of elements in the MeterValuesSampledData list can be reported by the Charge Point via:
+
+MeterValuesSampledDataMaxLength
+
+StopTxnSampledData is a comma separated list that prescribes the sampled measurands to be included in the TransactionData element of StopTransaction.req PDU, every MeterValueSampleInterval seconds from the start of the Transaction. The maximum amount of elements in the StopTxnSampledData list can be reported by the Charge Point via: StopTxnSampledDataMaxLength
+
+# 3.16.2. Clock-Aligned Meter Values
+
+Grid Operator might require meter readings to be taken from fiscally certified energy meters, at specific Clock aligned times (usually every quarter hour, or half hour).
+
+"Clock-Aligned Billing Data" can be configured with the following configuration keys:
+
+ClockAlignedDataInterval
+
+- MeterValuesAlignedData
+- MeterValuesAlignedDataMaxLength
+- StopTxnAlignedData
+- StopTxnAlignedDataMaxLength
+
+ClockAlignedDataInterval is the size of the clock-aligned data interval (in seconds). This defines the set of evenly spaced meter data 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.
+
+A value of "0" (numeric zero), by convention, is to be interpreted to mean that no clock-aligned data should be transmitted.
+
+MeterValuesAlignedData is a comma separated list that prescribes the set of measurands to be included in a MeterValues.req PDU, every ClockAlignedDataInterval seconds. The maximum amount of elements in the MeterValuesAlignedData list can be reported by the Charge Point via:
+
+StopTxnAlignedData is a comma separated list that prescribes the set of clock-aligned periodic measurands to be included in the TransactionData element of StopTransaction.req PDU for every
+
+ClockAlignedDataInterval of the Transaction. The maximum amount of elements in the
+
+StopTxnAlignedData list can be reported by the Charge Point via: StopTxnAlignedDataMaxLength
+
+# 3.16.3. Multiple Locations/Phases
+
+When a Charge Point 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 keys.
+
+For example: A Charge Point capable of measuring Current.Import on Inlet (all 3 phases) (grid connection) and Outlet (3 phases per connector on both its connectors). Current.Import is set in MeterValuesSampledData.
+
+MeterValueSampleInterval is set to 300 (seconds). Then the Charge Point should send:
+
+- a MeterValues.req with: connectorld = 0; with 3 SampledValue elements, one per phase with location = Inlet.
+- a MeterValues.req with: connectorld = 1; with 3 SampledValue elements, one per phase with location = Outlet.
+- a MeterValues.req with: connectorld = 2; with 3 SampledValue elements, one per phase with location = Outlet.
+
+# 3.16.4. Unsupported measurands
+
+When a Central System sends a ChangeConfiguration.req to a Charge Point with one of the following configuration keys:
+
+- MeterValuesAlignedData
+- MeterValuesSampledData
+- StopTxnAlignedData
+- StopTxnSampledData
+
+If the comma separated list contains one or more measurands that are not supported by this Charge Point, the Charge Point SHALL respond with: ChangeConfiguration.conf with: status = Rejected. No changes SHALL be made to the currently configuration.
+
+# 3.16.5. No metering data in a Stop Transaction
+
+When the configuration keys: StopTxnAlignedData and StopTxnSampledData are set to an empty string, the Charge Point SHALL not put meter values in a StopTransaction.req PDU.
+
+# 4. Operations Initiated by Charge Point
+
+# 4.1. Authorization
+
+
+Figure 12. Sequence Diagram: Authorization
+
+Before the owner of an electric vehicle can start or stop charging, the Charge Point has to authorize the operation. The Charge Point SHALL only supply energy after authorization. When stopping a Transaction, the Charge Point SHALL only send an Authorization.req when the identifier used for stopping the transaction is different from the identifier that started the transaction.
+
+Authorize.req SHOULD only be used for the authorization of an identifier for charging.
+
+A Charge Point MAY authorize identifier locally without involving the Central System, as described in Local Authorization List. If an idTag presented by the user is not present in the Local Authorization List or Authorization Cache, then the Charge Point SHALL send an Authorization.req PDU to the Central System to request authorization. If the idTag is present in the Local Authorization List or Authorization Cache, then the Charge Point MAY send an Authorization.req PDU to the Central System.
+
+Upon receipt of an Authorization.req PDU, the Central System SHALL respond with an Authorization.conf PDU. This response PDU SHALL indicate whether or not the idTag is accepted by the Central System. If the Central System accepts the idTag then the response PDU MAY include a parentIdTag and MUST include an authorization status value indicating acceptance or a reason for rejection.
+
+If Charge Point has implemented an Authorization Cache, then upon receipt of an Invalidate.conf PDU the Charge Point SHALL update the cache entry, if the idTag is not in the Local Authorization List, with the IdTagInfo value from the response as described under Authorization Cache.
+
+# 4.2. Boot Notification
+
+
+Figure 13. Sequence Diagram: Boot Notification
+
+After start-up, a Charge Point SHALL send a request to the Central System with information about its configuration (e.g. version, vendor, etc.). The Central System SHALL respond to indicate whether it will accept the Charge Point.
+
+The Charge Point SHALL send a BootNotification.req PDU each time it boots or reboots. Between the physical power-on/reboot and the successful completion of a BootNotification, where Central System returns Accepted or Pending, the Charge Point SHALL NOT send any other request to the Central System. This includes cached
+
+messages that are still present in the Charge Point from before.
+
+When the Central System responds with a BootNotification.conf with a status Accepted, the Charge Point will adjust the heartbeat interval in accordance with the interval from the response PDU and it is RECOMMENDED to synchronize its internal clock with the supplied Central System's current time. If the Central System returns something other than Accepted, the value of the interval field indicates the minimum wait time before sending a next BootNotification request. If that interval value is zero, the Charge Point chooses a waiting interval on its own, in a way that avoids flooding the Central System with requests. A Charge Point SHOULD NOT send a BootNotification.req earlier, unless requested to do so with a TriggerMessage.req.
+
+If the Central System returns the status Rejected, the Charge Point SHALL NOT send any OCPP message to the Central System until the aforementioned retry interval has expired. During this interval the Charge Point may no longer be reachable from the Central System. It MAY for instance close its communication channel or shut down its communication hardware. Also the Central System MAY close the communication channel, for instance to free up system resources. While Rejected, the Charge Point SHALL NOT respond to any Central System initiated message. the Central System SHOULD NOT initiate any.
+
+The Central System MAY also return a Pending registration status to indicate that it wants to retrieve or set certain information on the Charge Point before the Central System will accept the Charge Point. If the Central System returns the Pending status, the communication channel SHOULD NOT be closed by either the Charge Point or the Central System. The Central System MAY send request messages to retrieve information from the Charge Point or change its configuration. The Charge Point SHOULD respond to these messages. The Charge Point SHALL NOT send request messages to the Central System unless it has been instructed by the Central System to do so with a TriggerMessage.req request.
+
+While in pending state, the following Central System initiated messages are not allowed:
+
+RemoteStartTransaction.req and RemoteStopTransaction.req
+
+# 4.2.1. Transactions before being accepted by a Central System
+
+A Charge Point Operator MAY choose to configure a Charge Point to accept transactions before the Charge Point is accepted by a Central System. Parties who want to implement this such behavior should realize that it is uncertain if those transactions can ever be delivered to the Central System.
+
+After a restart (for instance due to a remote reset command, power outage, firmware update, software error etc.) the Charge Point MUST again contact the Central System and SHALL send a BootNotification request. If the Charge Point fails to receive a BootNotification.conf from the Central System, and has no in-built non-volatile real-time clock hardware that has been correctly preset, the Charge Point may not have a valid date / time setting, making it impossible to later determine the date / time of transactions.
+
+It might also be the case (e.g. due to configuration error) that the Central System indicates a status other than Accepted for an extended period of time, or indefinitely.
+
+It is usually advisable to deny all charging services at a Charge Point if the Charge Point has never before been Accepted by the Central System (using the current connection settings, URL, etc.) since users cannot be authenticated and running transactions could conflict with provisioning processes.
+
+# 4.3. Data Transfer
+
+
+Figure 14. Sequence Diagram: Data Transfer
+
+If a Charge Point needs to send information to the Central System for a function not supported by OCPP, it SHALL use the DataTransfer.req PDU.
+
+The vendorId in the request SHOULD be known to the Central System and uniquely identify the vendor-specific implementation. The VendorId SHOULD be a value from the reversed DNS namespace, where the top tiers of the name, when reversed, should correspond to the publicly registered primary DNS name of the Vendor organisation.
+
+Optionally, the msgeld in the request PDU MAY be used to indicate a specific message or implementation.
+
+The length of data in both the request and response PDU is undefined and should be agreed upon by all parties involved.
+
+If the recipient of the request has no implementation for the specific vendorId it SHALL return a status 'UnknownVendor' and the data element SHALL not be present. In case of a messaged mismatch (if used) the recipient SHALL return status 'UnknownMessageId'. In all other cases the usage of status 'Accepted' or 'Rejected' and the data element is part of the vendor-specific agreement between the parties involved.
+
+# 4.4. Diagnostics Status Notification
+
+
+Figure 15. Sequence Diagram: Diagnostics Status Notification
+
+Charge Point sends a notification to inform the Central System about the status of a diagnostics upload. The Charge Point SHALL send a DiagnosticsStatusNotification.req PDU to inform the Central System that the upload of diagnostics is busy or has finished successfully or failed. The Charge Point SHALL only send the status Idle after receipt of a TriggerMessage for a Diagnostics Status Notification, when it is not busy uploading diagnostics.
+
+Upon receipt of a DiagnosticsStatusNotification.req PDU, the Central System SHALL respond with a DiagnosticsStatusNotification.conf.
+
+# 4.5. Firmware Status Notification
+
+
+Figure 16. Sequence Diagram: Firmware Status Notification
+
+A Charge Point sends notifications to inform the Central System about the progress of the firmware update. The Charge Point SHALL send a FirmwareStatusNotification.req PDU for informing the Central System about the progress of the downloading and installation of a firmware update. The Charge Point SHALL only send the status Idle after receipt of a TriggerMessage for a Firmware Status Notification, when it is not busy downloading/installing firmware.
+
+Upon receipt of a FirmwareStatusNotification.req PDU, the Central System SHALL respond with a FirmwareStatusNotification.conf.
+
+The FirmwareStatusNotification.req PDUs SHALL be sent to keep the Central System updated with the status of the update process, started by the Central System with a FirmwareUpdate.req PDU.
+
+# 4.6. Heartbeat
+
+
+Figure 17. Sequence Diagram: Heartbeat
+
+To let the Central System know that a Charge Point is still connected, a Charge Point sends a heartbeat after a configurable time interval.
+
+The Charge Point SHALL send a Heartbeat.req PDU for ensuring that the Central System knows that a Charge Point is still alive.
+
+Upon receipt of a Heartbeat.req PDU, the Central System SHALL respond with a Heartbeat.conf. The response PDU SHALL contain the current time of the Central System, which is RECOMMENDED to be used by the Charge Point to synchronize its internal clock.
+
+The Charge Point MAY skip sending a Heartbeat.req PDU when another PDU has been sent to the Central System within the configured heartbeat interval. This implies that a Central System SHOULD assume availability of a Charge Point whenever a PDU has been received, the same way as it would have, when it received a Heartbeat.req PDU.
+
+
+
+With JSON over WebSocket, sending heartbeats is not mandatory. However, for time synchronization it is advised to at least send one heartbeat per 24 hour.
+
+# 4.7. Meter Values
+
+
+Figure 18. Sequence Diagram: Meter Values
+
+A Charge Point MAY sample the electrical meter or other sensor/transducer hardware to provide extra information about its meter values. It is up to the Charge Point to decide when it will send meter values. This can be configured using the ChangeConfiguration.req message to data acquisition intervals and specify data to be acquired & reported.
+
+The Charge Point SHALL send a MeterValues.req PDU for offloading meter values. The request PDU SHALL contain for each sample:
+
+1. The id of the Connector from which samples were taken. If the connectorId is 0, it is associated with the entire Charge Point. If the connectorId is 0 and the Measurand is energy related, the sample SHOULD be taken from the main energy meter.
+2. The transactionId of the transaction to which these values are related, if applicable. If there is no transaction in progress or if the values are taken from the main meter, then transaction id may be omitted.
+3. One or more meterValue elements, of type MeterValue, each representing a set of one or more data values taken at a particular point in time.
+
+Each MeterValue element contains a timestamp and a set of one or more individual sampledvalue elements, all captured at the same point in time. Each sampledValue element contains a single value datum. The nature of each sampledValue is determined by the optional measurand, context, location, unit, phase, and format fields.
+
+The optional measurand field specifies the type of value being measured/reported.
+
+The optional context field specifies the reason/event triggering the reading.
+
+The optional location field specifies where the measurement is taken (e.g. Inlet, Outlet).
+
+The optional phase field specifies to which phase or phases of the electric installation the value applies. The Charging Point SHALL report all phase number dependent values from the electrical meter (or grid connection when absent) point of view.
+
+
+
+The phase field is not applicable to all Measurands.
+
+
+
+Two measurands (Current.Offered and Power.Offered) are available that are strictly speaking no measured values. They indicate the maximum amount of current/power that is being offered to the EV and are intended for use in smart charging applications.
+
+For individual connector phase rotation information, the Central System MAY query the ConnectorPhaseRotation configuration key on the Charging Point via GetConfiguration. The Charge Point SHALL report the phase rotation in respect to the grid connection. Possible values per connector are:
+
+NotApplicable, Unknown, RST, RTS, SRT, STR, TRS and TSR. see section Standard Configuration Key Names & Values for more information.
+
+The EXPERIMENTAL optional format field specifies whether the data is represented in the normal (default) form as a simple numeric value ("Raw"), or as "SignedData", an opaque digitally signed binary data block, represented as hex data. This experimental field may be deprecated and subsequently removed in later versions, when a more mature solution alternative is provided.
+
+To retain backward compatibility, the default values of all of the optional fields on a sampledValue element are such that a value without any additional fields will be interpreted, as a register reading of active import energy in Wh (Watt-hour) units.
+
+Upon receipt of a MeterValues.req PDU, the Central System SHALL respond with a MeterValues.conf.
+
+It is likely that The Central System applies sanity checks to the data contained in a MeterValues.req it received. The outcome of such sanity checks SHOULD NOT ever cause the Central System to not respond with a MeterValues.conf. Failing to respond with a MeterValues.conf will only cause the Charge Point to try the same message again as specified in Error responses to transaction-related messages.
+
+# 4.8. Start Transaction
+
+
+Figure 19. Sequence Diagram: Start Transaction
+
+The Charge Point SHALL send a StartTransaction.req PDU to the Central System to inform about a transaction that has been started. If this transaction ends a reservation (see Reserve Now operation), then the StartTransaction.req MUST contain the reservationId.
+
+Upon receipt of a StartTransaction.req PDU, the Central System SHOULD respond with a StartTransaction.conf PDU. This response PDU MUST include a transaction id and an authorization status value.
+
+The Central System MUST verify validity of the identifier in the StartTransaction.req PDU, because the identifier might have been authorized locally by the Charge Point using outdated information. The identifier, for instance, may have been blocked since it was added to the Charge Point's Authorization Cache.
+
+If Charge Point has implemented an Authorization Cache, then upon receipt of a StartTransaction.conf PDU the Charge Point SHALL update the cache entry, if the idTag is not in the Local Authorization List, with the IdTagInfo value from the response as described under Authorization Cache.
+
+It is likely that The Central System applies sanity checks to the data contained in a StartTransaction.req it received. The outcome of such sanity checks SHOULD NOT ever cause the Central System to not respond with a StartTransaction.conf. Failing to respond with a StartTransaction.conf will only cause the Charge Point to try the same message again as specified in Error responses to transaction-related messages.
+
+# 4.9. Status Notification
+
+
+Figure 20. Sequence Diagram: Status Notification
+
+A Charge Point sends a notification to the Central System to inform the Central System about a status change or an error within the Charge Point. The following table depicts changes from a previous status (left column) to a new status (upper row) upon which a Charge Point MAY send a StatusNotification.req PDU to the Central System.
+
+
+
+The Occupied state as defined in previous OCPP versions is no longer relevant. The Occupied state is split into five new statuses: Preparing, Charging, SuspendedEV, SuspendedEVSE and Finishing.
+
+
+
+EVSE is used in Status Notification instead of Socket or Charge Point for future compatibility.
+
+The following table describes which status transitions are possible:
+
+<table><tr><td></td><td>State From \ To:</td><td>1 Available</td><td>2 Preparing</td><td>3 Charging</td><td>4 SuspendedEV</td><td>5 SuspendedEVSE</td><td>6 Finishing</td><td></td><td>7 Reserved</td><td>8 Unavailable</td><td>9 Faulted</td></tr><tr><td>A</td><td>Available</td><td></td><td>A2</td><td>A3</td><td>A4</td><td>A5</td><td></td><td></td><td>A7</td><td>A8</td><td>A9</td></tr><tr><td>B</td><td>Preparing</td><td>B1</td><td></td><td>B3</td><td>B4</td><td>B5</td><td>B6</td><td></td><td></td><td></td><td>B9</td></tr><tr><td>C</td><td>Charging</td><td>C1</td><td></td><td></td><td>C4</td><td>C5</td><td>C6</td><td></td><td></td><td>C8</td><td>C9</td></tr><tr><td>D</td><td>SuspendedEV</td><td>D1</td><td></td><td>D3</td><td></td><td>D5</td><td>D6</td><td></td><td></td><td>D8</td><td>D9</td></tr><tr><td>E</td><td>SuspendedEVSE</td><td>E1</td><td></td><td>E3</td><td>E4</td><td></td><td>E6</td><td></td><td></td><td>E8</td><td>E9</td></tr><tr><td>F</td><td>Finishing</td><td>F1</td><td>F2</td><td></td><td></td><td></td><td></td><td></td><td></td><td>F8</td><td>F9</td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>G</td><td>Reserved</td><td>G1</td><td>G2</td><td></td><td></td><td></td><td></td><td></td><td></td><td>G8</td><td>G9</td></tr><tr><td>H</td><td>Unavailable</td><td>H1</td><td>H2</td><td>H3</td><td>H4</td><td>H5</td><td></td><td></td><td></td><td></td><td>H9</td></tr><tr><td>I</td><td>Faulted</td><td>I1</td><td>I2</td><td>I3</td><td>I4</td><td>I5</td><td>I6</td><td></td><td>I7</td><td>I8</td><td></td></tr></table>
+
+
+
+The table above is only applicable to Connectorld $>0$ . For Connectorld 0, only a limited set is applicable, namely: Available, Unavailable and Faulted.
+
+The next table describes events that may lead to a status change:
+
+<table><tr><td colspan="2">DESCRIPTION</td></tr><tr><td>A2</td><td>Usage is initiated (e.g. insert plug, bay occupancy detection, present idTag, push start button, receipt of a RemoteStartTransaction.req)</td></tr><tr><td>A3</td><td>Can be possible in a Charge Point without an authorization means</td></tr><tr><td>A4</td><td>Similar to A3 but the EV does not start charging</td></tr><tr><td>A5</td><td>Similar to A3 but the EVSE does not allow charging</td></tr><tr><td>A7</td><td>A Reserve Now message is received that reserves the connector</td></tr><tr><td>A8</td><td>A Change Availability message is received that sets the connector to Unavailable</td></tr></table>
+
+# DESCRIPTION
+
+A9 A fault is detected that prevents further charging operations
+B1 Intended usage is ended (e.g. plug removed, bay no longer occupied, second presentation of idTag, time out (configured by the configuration key: ConnectionTimeOut) on expected user action)
+B3 All prerequisites for charging are met and charging process starts
+B4 All prerequisites for charging are met but EV does not start charging
+B5 All prerequisites for charging are met but EVSE does not allow charging
+B6 Timed out. Usage was initiated (e.g. insert plug, bay occupancy detection), but idTag not presented within timeout.
+B9 A fault is detected that prevents further charging operations
+C1 Charging session ends while no user action is required (e.g. fixed cable was removed on EV side)
+C4 Charging stops upon EV request (e.g. S2 is opened)
+C5 Charging stops upon EVSE request (e.g. smart charging restriction, transaction is invalidated by the AuthorizationStatus in a StartTransaction.conf)
+C6 Transaction is stopped by user or a Remote Stop Transaction message and further user action is required (e.g. remove cable, leave parking bay)
+C8 Charging session ends, no user action is required and the connector is scheduled to become Unavailable
+C9 A fault is detected that prevents further charging operations
+D1 Charging session ends while no user action is required
+D3 Charging resumes upon request of the EV (e.g. S2 is closed)
+D5 Charging is suspended by EVSE (e.g. due to a smart charging restriction)
+D6 Transaction is stopped and further user action is required
+D8 Charging session ends, no user action is required and the connector is scheduled to become Unavailable
+D9 A fault is detected that prevents further charging operations
+
+# DESCRIPTION
+
+E1 Charging session ends while no user action is required
+E3 Charging resumes because the EVSE restriction is lifted
+E4 The EVSE restriction is lifted but the EV does not start charging
+E6 Transaction is stopped and further user action is required
+E8 Charging session ends, no user action is required and the connector is scheduled to become Unavailable
+E9 A fault is detected that prevents further charging operations
+
+F1 All user actions completed
+F2 User restart charging session (e.g. reconnects cable, presents idTag again), thereby creating a new Transaction
+F8 All user actions completed and the connector is scheduled to become Unavailable
+F9 A fault is detected that prevents further charging operations
+
+G1 Reservation expires or a Cancel Reservation message is received
+G2 Reservation identity is presented
+G8 Reservation expires or a Cancel Reservation message is received and the connector is scheduled to become Unavailable
+G9 A fault is detected that prevents further charging operations
+H1 Connector is set Available by a Change Availability message
+H2 Connector is set Available after a user had interacted with the Charge Point
+H3 Connector is set Available and no user action is required to start charging
+H4 Similar to H3 but the EV does not start charging
+H5 Similar to H3 but the EVSE does not allow charging
+H9 A fault is detected that prevents further charging operations
+
+11-18
+
+Fault is resolved and status returns to the pre-fault state
+
+
+
+A Charge Point Connector MAY have any of the 9 statuses as shown in the table above. For Connectorld 0, only a limited set is applicable, namely: Available, Unavailable and Faulted. The status of Connectorld 0 has no direct connection to the status of the individual Connectors $(>0)$ .
+
+
+
+If charging is suspended both by the EV and the EVSE, status SuspendedEVSE SHALL have precedence over status SuspendedEV.
+
+
+
+When a Charge Point or a Connector is set to status Unavailable by a Change Availability command, the 'Unavailable' status MUST be persistent across reboot. The Charge Point MAY use the Unavailable status internally for other purposes (e.g. while updating firmware or waiting for an initial Accepted RegistrationStatus).
+
+As the status Occupied has been split into five new statuses (Preparing, Charging, SuspendedEV, SuspendedEVSE and Finishing), more StatusNotification.req PDUs will be sent from Charge Point to the Central System. For instance, when a transaction is started, the Connector status would successively change from Preparing to Charging with a short SuspendedEV and/or SuspendedEVSE inbetween, possibly within a couple of seconds.
+
+To limit the number of transitions, the Charge Point MAY omit sending a StatusNotification.req if it was active for less time than defined in the optional configuration key MinimumStatusDuration. This way, a Charge Point MAY choose not to send certain StatusNotification.req PDUs.
+
+
+
+A Charge Point manufacturer MAY have implemented a minimal status duration for certain status transitions separate of the MinimumStatusDuration setting. The time set in MinimumStatusDuration will be added to this default delay. Setting MinimumStatusDuration to zero SHALL NOT override the default manufacturer's minimal status duration.
+
+
+
+Setting a high MinimumStatusDuration time may result in the delayed sending of all StatusNotifications, since the Charge Point will only send the StatusNotification.req once the MinimumStatusDuration time is passed.
+
+The Charge Point MAY send a StatusNotification.req PDU to inform the Central System of fault conditions. When the 'status' field is not Faulted, the condition should be considered a warning since charging operations are still possible.
+
+
+
+ChargePointErrorCode EVCommunicationError SHALL only be used with status Preparing, SuspendedEV, SuspendedEVSE and Finishing and be treated as warning.
+
+When a Charge Point is configured with StopTransactionOnEVSideDisconnect set to false, a transaction is running and the EV becomes disconnected on EV side, then a StatusNotification.req with the state: SuspendedEV
+
+SHOULD be send to the Central System, with the 'errorCode' field set to: 'NoError'. The Charge Point SHOULD add additional information in the 'info' field, Notifying the Central System with the reason of suspension: 'EV side disconnected'. The current transaction is not stopped.
+
+When a Charge Point is configured with StopTransactionOnEVSideDisconnect set to true, a transaction is running and the EV becomes disconnected on EV side, then a StatusNotification.req with the state: 'Finishing' SHOULD be send to the Central System, with the 'errorCode' field set to: 'NoError'. The Charge Point SHOULD add additional information in the 'info' field, Notifying the Central System with the reason of stopping: 'EV side disconnected'. The current transaction is stopped.
+
+When a Charge Point connects to a Central System after having been offline, it updates the Central System about its status according to the following rules:
+
+1. The Charge Point SHOULD send a StatusNotification.req PDU with its current status if the status changed while the Charge Point was offline.
+2. The Charge Point MAY send a StatusNotification.req PDU to report an error that occurred while the Charge Point was offline.
+3. The Charge Point SHOULD NOT send StatusNotification.req PDUs for historical status change events that happened while the Charge Point was offline and that do not inform the Central System of Charge Point errors or the Charge Point's current status.
+4. The StatusNotification.req messages MUST be sent in the order in which the events that they describe occurred.
+
+Upon receipt of a StatusNotification.req PDU, the Central System SHALL respond with a StatusNotification.conf PDU.
+
+# 4.10. Stop Transaction
+
+
+Figure 21. Sequence Diagram: Stop Transaction
+
+When a transaction is stopped, the Charge Point SHALL send a StopTransaction.req PDU, notifying to the Central System that the transaction has stopped.
+
+A StopTransaction.req PDU MAY contain an optional TransactionData element to provide more details about transaction usage. The optional TransactionData element is a container for any number of MeterValues, using the same data structure as the meterValue elements of the MeterValues.req PDU (See section MeterValues)
+
+Upon receipt of a StopTransaction.req PDU, the Central System SHALL respond with a StopTransaction.conf PDU.
+
+The Central System cannot prevent a transaction from stopping. It MAY only inform the Charge Point it has received the StopTransaction.req and MAY send information about the idTag used to stop the transaction. This information SHOULD be used to update the Authorization Cache, if implemented.
+
+The idTag in the request PDU MAY be omitted when the Charge Point itself needs to stop the transaction. For instance, when the Charge Point is requested to reset.
+
+If a transaction is ended in a normal way (e.g. EV-driver presented his identification to stop the transaction), the Reason element MAY be omitted and the Reason SHOULD be assumed 'Local'. If the transaction is not ended normally, the Reason SHOULD be set to a correct value. As part of the normal transaction termination, the Charge Point SHALL unlock the cable (if not permanently attached).
+
+The Charge Point MAY unlock the cable (if not permanently attached) when the cable is disconnected at the EV. If supported, this functionality is reported and controlled by the configuration key
+
+UnlockConnectorOnEVSideDisconnect.
+
+The Charge Point MAY stop a running transaction when the cable is disconnected at the EV. If supported, this functionality is reported and controlled by the configuration key StopTransactionOnEVSideDisconnect.
+
+If StopTransactionOnEVSideDisconnect is set to false, the transaction SHALL not be stopped when the cable is disconnected from the EV. If the EV is reconnected, energy transfer is allowed again. In this case there is no mechanism to prevent other EVs from charging and disconnecting during that same ongoing transaction. With UnlockConnectorOnEVSideDisconnect set to false, the Connector SHALL remain locked at the Charge Point until the user presents the identifier.
+
+By setting StopTransactionOnEVSideDisconnect to true, the transaction SHALL be stopped when the cable is disconnected from the EV. If the EV is reconnected, energy transfer is not allowed until the transaction is stopped and a new transaction is started. If UnlockConnectorOnEVSideDisconnect is set to true, also the Connector on the Charge Point will be unlocked.
+
+
+
+If StopTransactionOnEVSideDisconnect is set to false, this SHALL have priority over UnlockConnectorOnEVSideDisconnect. In other words: cables always remain locked when the cable is disconnected at EV side when StopTransactionOnEVSideDisconnect is false.
+
+
+
+Setting StopTransactionOnEVSideDisconnect to true will prevent sabotage acts to stop the energy flow by unplugging not locked cables on EV side.
+
+It is likely that The Central System applies sanity checks to the data contained in a StopTransaction.req it received. The outcome of such sanity checks SHOULD NOT ever cause the Central System to not respond with a StopTransaction.conf. Failing to respond with a StopTransaction.conf will only cause the Charge Point to try the same message again as specified in Error responses to transaction-related messages.
+
+If Charge Point has implemented an Authorization Cache, then upon receipt of a StopTransaction.conf PDU the Charge Point SHALL update the cache entry, if the idTag is not in the Local Authorization List, with the IdTagInfo value from the response as described under Authorization Cache.
+
+# 5. Operations Initiated by Central System
+
+# 5.1. Cancel Reservation
+
+
+Figure 22. Sequence Diagram: Cancel Reservation
+
+To cancel a reservation the Central System SHALL send an CancelReservation.req PDU to the Charge Point.
+
+If the Charge Point has a reservation matching the reservationId in the request PDU, it SHALL return status 'Accepted'. Otherwise it SHALL return 'Rejected'.
+
+# 5.2. Change Availability
+
+
+Figure 23. Sequence Diagram: Change Availability
+
+Central System can request a Charge Point to change its availability. A Charge Point is considered available ("operative") when it is charging or ready for charging. A Charge Point is considered unavailable when it does not allow any charging. The Central System SHALL send a ChangeAvailability.req PDU for requesting a Charge Point to change its availability. The Central System can change the availability to available or unavailable.
+
+Upon receipt of a ChangeAvailability.req PDU, the Charge Point SHALL respond with a ChangeAvailability.conf PDU. The response PDU SHALL indicate whether the Charge Point is able to change to the requested availability or not. When a transaction is in progress Charge Point SHALL respond with availability status 'Scheduled' to indicate that it is scheduled to occur after the transaction has finished.
+
+In the event that Central System requests Charge Point to change to a status it is already in, Charge Point SHALL respond with availability status 'Accepted'.
+
+When an availability change requested with a ChangeAvailability.req PDU has happened, the Charge Point SHALL inform Central System of its new availability status with a StatusNotification.req as described there.
+
+
+
+In the case the ChangeAvailability.req contains ConnectorId = 0, the status change applies to the Charge Point and all Connectors.
+
+
+
+Persistent states: for example: Connector set to Unavailable shall persist a reboot.
+
+# 5.3. Change Configuration
+
+
+Figure 24. Sequence Diagram: Change Configuration
+
+Central System can request a Charge Point to change configuration parameters. To achieve this, Central System SHALL send a ChangeConfiguration.req. This request contains a key-value pair, where "key" is the name of the configuration setting to change and "value" contains the new setting for the configuration setting.
+
+Upon receipt of a ChangeConfiguration.req Charge Point SHALL reply with a ChangeConfiguration.conf indicating whether it was able to apply the change to its configuration. Content of "key" and "value" is not prescribed. The Charge Point SHALL set the status field in the ChangeConfiguration.conf according to the following rules:
+
+- If the change was applied successfully, and the change if effective immediately, the Charge Point SHALL respond with a status 'Accepted'.
+- If the change was applied successfully, but a reboot is needed to make it effective, the Charge Point SHALL respond with status 'RebootRequired'.
+- If "key" does not correspond to a configuration setting supported by Charge Point, it SHALL respond with a status 'NotSupported'.
+- If the Charge Point did not set the configuration, and none of the previous statuses applies, the Charge Point SHALL respond with status 'Rejected'.
+
+
+
+Examples of Change Configuration requests to which a Charge Point responds with a ChangeConfiguration.conf with a status of 'Rejected' are requests with out-of-range values and requests with values that do not conform to an expected format.
+
+If a key value is defined as a CSL, it MAY be accompanied with a [ KeyName ]MaxLength key, indicating the max length of the CSL in items. If this key is not set, a safe value of 1 (one) item SHOULD be assumed.
+
+# 5.4. Clear Cache
+
+
+Figure 25. Sequence Diagram: Clear Cache
+
+Central System can request a Charge Point to clear its Authorization Cache. The Central System SHALL send a ClearCache.req PDU for clearing the Charge Point's Authorization Cache.
+
+Upon receipt of a ClearCache.req PDU, the Charge Point SHALL respond with a ClearCache.conf PDU. The response PDU SHALL indicate whether the Charge Point was able to clear its Authorization Cache.
+
+# 5.5. Clear Charging Profile
+
+
+Figure 26. Sequence Diagram: Clear Charging Profile
+
+If the Central System wishes to clear some or all of the charging profiles that were previously sent the Charge Point, it SHALL use the ClearChargingProfile.req PDU.
+
+The Charge Point SHALL respond with a ClearChargingProfile.conf PDU specifying whether it was able to process the request.
+
+# 5.6. Data Transfer
+
+
+Figure 27. Sequence Diagram: Data Transfer
+
+If the Central System needs to send information to a Charge Point for a function not supported by OCPP, it SHALL use the DataTransfer.req PDU.
+
+Behaviour of this operation is identical to the Data Transfer operation initiated by the Charge Point. See Data Transfer for details.
+
+# 5.7. Get Composite Schedule
+
+
+Figure 28. Sequence Diagram: Get Composite Schedule
+
+The Central System MAY request the Charge Point to report the Composite Charging Schedule by sending a GetCompositeSchedule.req PDU. The reported schedule, in the GetCompositeSchedule.conf PDU, is the result of the calculation of all active schedules and possible local limits present in the Charge Point. Local Limits might be taken into account.
+
+Upon receipt of a GetCompositeSchedule.req, the Charge Point SHALL calculate the Composite Charging Schedule intervals, from the moment the request PDU is received: Time X, up to X + Duration, and send them in the GetCompositeSchedule.conf PDU to the Central System.
+
+If the Connectorld in the request is set to '0', the Charge Point SHALL report the total expected power or current the Charge Point expects to consume from the grid during the requested time period.
+
+Please note that the charging schedule sent by the charge point is only indicative for that point in time. This schedule might change over time due to external causes (for instance, local balancing based on grid connection capacity is active and one Connector becomes available).
+
+If the Charge Point is not able to report the requested schedule, for instance if the connectorld is unknown, it SHALL respond with a status Rejected.
+
+# 5.8. Get Configuration
+
+
+Figure 29. Sequence Diagram: Get Configuration
+
+To retrieve the value of configuration settings, the Central System SHALL send a GetConfiguration.req PDU to the Charge Point.
+
+If the list of keys in the request PDU is empty or missing (it is optional), the Charge Point SHALL return a list of all configuration settings in GetConfiguration.conf. Otherwise Charge Point SHALL return a list of recognized keys and their corresponding values and read-only state. Unrecognized keys SHALL be placed in the response PDU as part of the optional unknown key list element of GetConfiguration.conf.
+
+The number of configuration keys requested in a single PDU MAY be limited by the Charge Point. This maximum can be retrieved by reading the configuration key GetConfigurationMaxKeys.
+
+# 5.9. Get Diagnostics
+
+
+Figure 30. Sequence Diagram: Get Diagnostics
+
+Central System can request a Charge Point for diagnostic information. The Central System SHALL send a GetDiagnostics.req PDU for getting diagnostic information of a Charge Point with a location where the Charge Point MUST upload its diagnostic data to and optionally a begin and end time for the requested diagnostic information.
+
+Upon receipt of a GetDiagnostics.req PDU, and if diagnostics information is available then Charge Point SHALL
+
+respond with a GetDiagnostics.conf PDU stating the name of the file containing the diagnostic information that will be uploaded. Charge Point SHALL upload a single file. Format of the diagnostics file is not prescribed. If no diagnostics file is available, then GetDiagnostics.conf SHALL NOT contain a file name.
+
+During uploading of a diagnostics file, the Charge Point MUST send DiagnosticsStatusNotification.req PDUs to keep the Central System updated with the status of the upload process.
+
+# 5.10. Get Local List Version
+
+
+Figure 31. Sequence Diagram: Get Local List Version
+
+In order to support synchronisation of the Local Authorization List, Central System can request a Charge Point for the version number of the Local Authorization List. The Central System SHALL send a GetLocalListVersion.req PDU to request this value.
+
+Upon receipt of a GetLocalListVersion.req PDU Charge Point SHALL respond with a GetLocalListVersion.conf PDU containing the version number of its Local Authorization List. A version number of 0 (zero) SHALL be used to indicate that the local authorization list is empty, and a version number of -1 SHALL be used to indicate that the Charge Point does not support Local Authorization Lists.
+
+# 5.11. Remote Start Transaction
+
+
+Figure 32. Sequence Diagram: Remote Start Transaction
+
+Central System can request a Charge Point to start a transaction by sending a RemoteStartTransaction.req. Upon receipt, the Charge Point SHALL reply with RemoteStartTransaction.conf and a status indicating whether it has accepted the request and will attempt to start a transaction.
+
+The effect of the RemoteStartTransaction.req message depends on the value of the
+
+AuthorizationRemoteTxRequests configuration key in the Charge Point.
+
+- If the value of AuthorizeRemoteTxRequests is true, the Charge Point SHALL behave as if in response to a local action at the Charge Point to start a transaction with the idTag given in the
+
+RemoteStartTransaction.req message. This means that the Charge Point will first try to authorize the idTag, using the Local Authorization List, Authorization Cache and/or an Authorization.req request. A transaction will only be started after authorization was obtained.
+
+- If the value of AuthorizeRemoteTxRequests is false, the Charge Point SHALL immediately try to start a transaction for the idTag given in the RemoteStartTransaction.req message. Note that after the
+
+transaction has been started, the Charge Point will send a StartTransaction request to the Central System, and the Central System will check the authorization status of the idTag when processing this StartTransaction request.
+
+The following typical use cases are the reason for Remote Start Transaction:
+
+- Enable a CPO operator to help an EV driver that has problems starting a transaction.
+- Enable mobile apps to control charging transactions via the Central System.
+- Enable the use of SMS to control charging transactions via the Central System.
+
+The RemoteStartTransaction.req SHALL contain an identifier (idTag), which Charge Point SHALL use, if it is able to start a transaction, to send a StartTransaction.req to Central System. The transaction is started in the same way as described in StartTransaction. The RemoteStartTransaction.req MAY contain a connector id if the transaction is to be started on a specific connector. When no connector id is provided, the Charge Point is in control of the connector selection. A Charge Point MAY reject a RemoteStartTransaction.req without a connector id.
+
+The Central System MAY include a ChargingProfile in the RemoteStartTransaction request. The purpose of this ChargingProfile SHALL be set to TxProfile. If accepted, the Charge Point SHALL use this ChargingProfile for the transaction.
+
+
+
+If a Charge Point without support for Smart Charging receives a RemoteStartTransaction.req with a Charging Profile, this parameter SHOULD be ignored.
+
+# 5.12. Remote Stop Transaction
+
+
+Figure 33. Sequence Diagram: Remote Stop Transaction
+
+Central System can request a Charge Point to stop a transaction by sending a RemoteStopTransaction.req to Charge Point with the identifier of the transaction. Charge Point SHALL reply with RemoteStopTransaction.conf and a status indicating whether it has accepted the request and a transaction with the given transactionId is ongoing and will be stopped.
+
+This remote request to stop a transaction is equal to a local action to stop a transaction. Therefore, the transaction SHALL be stopped, The Charge Point SHALL send a StopTransaction.req and, if applicable, unlock the connector.
+
+The following two main use cases are the reason for Remote Stop Transaction:
+
+- Enable a CPO operator to help an EV driver that has problems stopping a transaction.
+- Enable mobile apps to control charging transactions via the Central System.
+
+# 5.13. Reserve Now
+
+
+Figure 34. Sequence Diagram: Reserve Now
+
+A Central System can issue a ReserveNow.req to a Charge Point to reserve a connector for use by a specific idTag.
+
+To request a reservation the Central System SHALL send a ReserveNow.req PDU to a Charge Point. The Central System MAY specify a connector to be reserved. Upon receipt of a ReserveNow.req PDU, the Charge Point SHALL respond with a ReserveNow.conf PDU.
+
+If the reservationId in the request matches a reservation in the Charge Point, then the Charge Point SHALL replace that reservation with the new reservation in the request.
+
+If the reservationId does not match any reservation in the Charge Point, then the Charge Point SHALL return the status value 'Accepted' if it succeeds in reserving a connector. The Charge Point SHALL return 'Occupied' if the Charge Point or the specified connector are occupied. The Charge Point SHALL also return 'Occupied' when the Charge Point or connector has been reserved for the same or another idTag. The Charge Point SHALL return 'Faulted' if the Charge Point or the connector are in the Faulted state. The Charge Point SHALL return 'Unavailable' if the Charge Point or connector are in the Unavailable state. The Charge Point SHALL return 'Rejected' if it is configured not to accept reservations.
+
+If the Charge Point accepts the reservation request, then it SHALL refuse charging for all incoming idTags on the reserved connector, except when the incoming idTag or the parent idTag match the idTag or parent idTag of the reservation.
+
+When the configuration key: ReserveConnectorZeroSupported is set to true the Charge Point supports reservations on connector 0. If the connectorId in the reservation request is 0, then the Charge Point SHALL NOT reserve a specific connector, but SHALL make sure that at any time during the validity of the reservation, one connector remains available for the reserved idTag. If the configuration key:
+
+ReserveConnectorZeroSupported is not set or set to false, the Charge Point SHALL return 'Rejected'
+
+If the parent idTag in the reservation has a value (it is optional), then in order to determine the parent idTag that is associated with an incoming idTag, the Charge Point MAY look it up in its Local Authorization List or Authorization Cache. If it is not found in the Local Authorization List or Authorization Cache, then the Charge Point SHALL send an Authorized req for the incoming idTag to the Central System. The Authorized.conf response MAY contain the parent-id.
+
+A reservation SHALL be terminated on the Charge Point when either (1) a transaction is started for the reserved idTag or parent idTag and on the reserved connector or any connector when the reserved connectorId is 0, or (2) when the time specified in expiryDate is reached, or (3) when the Charge Point or connector are set to Faulted or Unavailable.
+
+If a transaction for the reserved idTag is started, then Charge Point SHALL send the reservationId in the StartTransaction.req PDU (see Start Transaction) to notify the Central System that the reservation is terminated.
+
+When a reservation expires, the Charge Point SHALL terminate the reservation and make the connector available. The Charge Point SHALL send a status notification to notify the Central System that the reserved connector is now available.
+
+If Charge Point has implemented an Authorization Cache, then upon receipt of a ReserveNow.conf PDU the Charge Point SHALL update the cache entry, if the idTag is not in the Local Authorization List, with the IdTagInfo value from the response as described under Authorization Cache.
+
+
+
+It is RECOMMENDED to validate the Identifier with an authorize.req after reception of a ReserveNow.req and before the start of the transaction.
+
+# 5.14. Reset
+
+
+Figure 35. Sequence Diagram: Reset
+
+The Central System SHALL send a Reset.req PDU for requesting a Charge Point to reset itself. The Central System can request a hard or a soft reset. Upon receipt of a Reset.req PDU, the Charge Point SHALL respond with a Reset.conf PDU. The response PDU SHALL include whether the Charge Point will attempt to reset itself.
+
+After receipt of a Reset.req, The Charge Point SHALL send a StopTransaction.req for any ongoing transaction before performing the reset. If the Charge Point fails to receive a StopTransaction.conf form the Central System, it shall queue the StopTransaction.req.
+
+At receipt of a soft reset, the Charge Point SHALL stop ongoing transactions gracefully and send StopTransaction.req for every ongoing transaction. It should then restart the application software (if possible, otherwise restart the processor/controller).
+
+At receipt of a hard reset the Charge Point SHALL restart (all) the hardware, it is not required to gracefully stop ongoing transaction. If possible the Charge Point sends a StopTransaction.req for previously ongoing transactions after having restarted and having been accepted by the Central System via a BootNotification.conf. This is a last resort solution for a not correctly functioning Charge Points, by sending a "hard" reset, (queued) information might get lost.
+
+
+
+Persistent states: for example: Connector set to Unavailable shall persist.
+
+# 5.15. Send Local List
+
+
+Figure 36. Sequence Diagram: Send Local List
+
+Central System can send a Local Authorization List that a Charge Point can use for authorization of idTags. The list MAY be either a full list to replace the current list in the Charge Point or it MAY be a differential list with updates to be applied to the current list in the Charge Point.
+
+The Central System SHALL send a SendLocalList.req PDU to send the list to a Charge Point. The SendLocalList.req PDU SHALL contain the type of update (full or differential) and the version number that the Charge Point MUST associate with the local authorization list after it has been updated.
+
+Upon receipt of a SendLocalList.req PDU, the Charge Point SHALL respond with a SendLocalList.conf PDU. The response PDU SHALL indicate whether the Charge Point has accepted the update of the local authorization list. If the status is Failed or VersionMismatch and the updateType was Differential, then Central System SHOULD retry sending the full local authorization list with updateType Full.
+
+# 5.16. Set Charging Profile
+
+
+Figure 37. Sequence Diagram: Set Charging Profile
+
+A Central System can send a SetChargingProfile.req to a Charge Point, to set a charging profile, in the following situations:
+
+- At the start of a transaction to set the charging profile for the transaction;
+- In a RemoteStartTransaction.req sent to a Charge Point
+- During a transaction to change the active profile for the transaction;
+- Outside the context of a transaction as a separate message to set a charging profile to a local controller, Charge Point, or a default charging profile to a connector.
+
+These situations are described below.
+
+# 5.16.1. Setting a charging profile at start of transaction
+
+If the Central System receives a StartTransaction.req the Central System SHALL respond with a StartTransaction.conf. If there is a need for a charging profile, The Central System MAY choose to send a SetChargingProfile.req to the Charge Point.
+
+It is RECOMMENDED to check the timestamp in the StartTransaction.req PDU prior to sending a charging profile to check if the transaction is likely to be still ongoing. The StartTransaction.req might have been cached during an offline period.
+
+# 5.16.2. Setting a charge profile in a RemoteStartTransaction request
+
+The Central System MAY include a charging profile in a RemoteStartTransaction request.
+
+If the Central System includes a ChargingProfile, the ChargingProfilePurpose MUST be set to TxProfile and the transactionId SHALL NOT be set.
+
+
+
+The Charge Point SHALL apply the given profile to the newly started transaction. This transaction will get a transactionId assigned by Central System via a StartTransaction.conf. When the Charge Point receives a SetChargingProfile.req, with the transactionId for this transaction, with the same StackLevel as the profile given in the RemoteStartTransaction.req, the Charge Point SHALL replace the existing charging profile, otherwise it SHALL install/stack the profile next to the already existing profile(s).
+
+# 5.16.3. Setting a charging profile during a transaction.
+
+The Central System MAY send a charging profile to a Charge Point to update the charging profile for that transaction. The Central System SHALL use the SetChargingProfile.req PDU for that purpose. If a charging profile with the same chargingProfileld, or the same combination of stackLevel / ChargingProfilePurpose, exists on the Charge Point, the new charging profile SHALL replace the existing charging profile, otherwise it SHALL be added. The Charge Point SHALL then re-evaluate its collection of charge profiles to determine which charging profile will become active. In order to ensure that the updated charging profile applies only to the current transaction, the chargingProfilePurpose of the ChargingProfile MUST be set to TxProfile. (See section: Charging Profile Purposes)
+
+# 5.16.4. Setting a charging profile outside of a transaction
+
+The Central System MAY send charging profiles to a Charge Point that are to be used as default charging profiles. The Central System SHALL use the SetChargingProfile.req PDU for that purpose. Such charging profiles MAY be sent at any time. If a charging profile with the same chargingProfileld, or the same combination of stackLevel / ChargingProfilePurpose, exists on the Charge Point, the new charging profile SHALL replace the existing charging profile, otherwise it SHALL be added. The Charge Point SHALL then re-evaluate its collection of charge profiles to determine which charging profile will become active.
+
+
+
+It is not possible to set a ChargingProfile with purpose set to TxProfile without presence of an active transaction, or in advance of a transaction.
+
+
+
+When a ChargingProfile is refreshed during execution, it is advised to put the startSchedule of the new ChargingProfile in the past, so there is no period of default charging behaviour inbetween the ChargingProfiles. The Charge Point SHALL continue to execute the existing ChargingProfile until the new ChargingProfile is installed.
+
+
+
+If the chargingSchedulePeriod is longer than duration, the remainder periods SHALL not be executed. If duration is longer than the chargingSchedulePeriod, the Charge Point SHALL keep the value of the last chargingSchedulePeriod until duration has ended.
+
+
+
+When concurrencyKind is used in combination with a chargingSchedulePeriod and/or duration that is longer then the recurrence period duration, the remainder periods SHALL not be executed.
+
+
+
+The StartSchedule of the first chargingSchedulePeriod in a chargingSchedule SHALL always be 0.
+
+
+
+When concurrencyKind is used in combination with a chargingSchedule duration shorter than the concurrencyKind period, the Charge Point SHALL fall back to default behaviour after the chargingSchedule duration ends. This fall back means that the Charge Point SHALL use a ChargingProfile with a lower stackLevel if available. If no other ChargingProfile is available, the Charge Point SHALL allow charging as if no ChargingProfile is installed. If the chargingSchedulePeriod and/or duration is longer then the recurrence period duration, the remainder periods SHALL not be executed.
+
+# 5.17. Trigger Message
+
+
+Figure 38. Sequence Diagram: Trigger Message
+
+During normal operation, the Charge Point informs the Central System of its state and any relevant occurrences. If there is nothing to report the Charge Point will send at least a heartBeat at a predefined interval. Under normal circumstances this is just fine, but what if the Central System has (whatever) reason to doubt the last known state? What can a Central System do if a firmware update is in progress and the last status notification it received about it was much longer ago than could reasonably be expected? The same can be asked for the progress of a diagnostics request. The problem in these situations is not that the information needed isn't covered by existing messages, the problem is strictly a timing issue. The Charge Point has the information, but has no way of knowing that the Central System would like an update.
+
+The TriggerMessage.req makes it possible for the Central System, to request the Charge Point, to send Charge
+
+Point-initiated messages. In the request the Central System indicates which message it wishes to receive. For every such requested message the Central System MAY optionally indicate to which connector this request applies. The requested message is leading: if the specified connectorid is not relevant to the message, it should be ignored. In such cases the requested message should still be sent.
+
+Inversely, if the connectorId is relevant but absent, this should be interpreted as "for all allowed connectorld values". For example, a request for a statusNotification for connectorld 0 is a request for the status of the Charge Point. A request for a statusNotification without connectorld is a request for multiple statusNotifications: the notification for the Charge Point itself and a notification for each of its connectors.
+
+
+Figure 39. Sequence Diagram: Trigger Message StatusNotification Example
+
+The Charge Point SHALL first send the TriggerMessage response, before sending the requested message. In the TriggerMessage.conf the Charge Point SHALL indicate whether it will send it or not, by returning ACCEPTED or REJECTED. It is up to the Charge Point if it accepts or rejects the request to send. If the requested message is unknown or not implemented the Charge Point SHALL return NOTIMPLEMENTED.
+
+Messages that the Charge Point marks as accepted SHOULD be sent. The situation could occur that, between accepting the request and actually sending the requested message, that same message gets sent because of normal operations. In such cases the message just sent MAY be considered as complying with the request.
+
+The TriggerMessage mechanism is not intended to retrieve historic data. The messages it triggers should only give current information. A MeterValues.req message triggered in this way for instance SHALL return the most recent measurements for all measurands configured in configuration key MeterValuesSampledData.
+
+StartTransaction and StopTransaction have been left out of this mechanism because they are not state related, but by their nature describe a transition.
+
+# 5.18. Unlock Connector
+
+
+Figure 40. Sequence Diagram: Unlock Connector
+
+Central System can request a Charge Point to unlock a connector. To do so, the Central System SHALL send an UnlockConnector.req PDU.
+
+The purpose of this message: Help EV drivers that have problems unplugging their cable from the Charge Point in case of malfunction of the Connector cable retention. When a EV driver calls the CPO help-desk, an operator could manually trigger the sending of an UnlockConnector.req to the Charge Point, forcing a new attempt to unlock the connector. Hopefully this time the connector unlocks and the EV driver can unplug the cable and drive away.
+
+The UnlockConnector.req SHOULD NOT be used to remotely stop a running transaction, use the Remote Stop Transaction instead.
+
+Upon receipt of an UnlockConnector.req PDU, the Charge Point SHALL respond with a UnlockConnector.conf PDU. The response PDU SHALL indicate whether the Charge Point was able to unlock its connector.
+
+If there was a transaction in progress on the specific connector, then Charge Point SHALL finish the transaction first as described in Stop Transaction.
+
+
+
+UnlockConnector.req is intended only for unlocking the cable retention lock on the Connector, not for unlocking a connector access door.
+
+# 5.19. Update Firmware
+
+
+Figure 41. Sequence Diagram: Update Firmware
+
+Central System can notify a Charge Point that it needs to update its firmware. The Central System SHALL send an UpdateFirmware.req PDU to instruct the Charge Point to install new firmware. The PDU SHALL contain a date and time after which the Charge Point is allowed to retrieve the new firmware and the location from which the firmware can be downloaded.
+
+Upon receipt of an UpdateFirmware.req PDU, the Charge Point SHALL respond with a UpdateFirmware.conf PDU. The Charge Point SHOULD start retrieving the firmware as soon as possible after retrieve-date.
+
+During downloading and installation of the firmware, the Charge Point MUST send
+
+FirmwareStatusNotification.req PDUs to keep the Central System updated with the status of the update process.
+
+The Charge Point SHALL, if the new firmware image is "valid", install the new firmware as soon as it is able to.
+
+If it is not possible to continue charging during installation of firmware, it is RECOMMENDED to wait until Charging Session has ended (Charge Point idle) before commencing installation. It is RECOMMENDED to set connectors that are not in use to UNAVAILABLE while the Charge Point waits for the Session to end.
+
+
+
+The sequence diagram above is an example. It is good practice to first reboot the Charge Point to check the new firmware is booting and able to connect to the Central System, before sending the status: Installed. This is not a requirement.
+
+# 6. Messages
+
+# 6.1. Authorization.req
+
+This contains the field definition of the Authorization.req PDU sent by the Charge Point to the Central System. See also Authorized
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>idTag</td><td>IdToken</td><td>1..1</td><td>Required. This contains the identifier that needs to be authorized.</td></tr></table>
+
+# 6.2. Authorization.conf
+
+This contains the field definition of the Authorization.conf PDU sent by the Central System to the Charge Point in response to a Authorization.req PDU. See also Authorization
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>idTagInfo</td><td>IdTagInfo</td><td>1..1</td><td>Required. This contains information about authorization status, expiry and parent id.</td></tr></table>
+
+# 6.3. BootNotification.req
+
+This contains the field definition of the BootNotification.req PDU sent by the Charge Point to the Central System. See also Boot Notification
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>chargeBoxSerialNumber</td><td>CiString25Type</td><td>0..1</td><td>Optional. This contains a value that identifies the serial number of the Charge Box inside the Charge Point. Deprecated, will be removed in future version</td></tr><tr><td>chargePointModel</td><td>CiString20Type</td><td>1..1</td><td>Required. This contains a value that identifies the model of the ChargePoint.</td></tr><tr><td>chargePointSerialNumber</td><td>CiString25Type</td><td>0..1</td><td>Optional. This contains a value that identifies the serial number of the Charge Point.</td></tr><tr><td>chargePointVendor</td><td>CiString20Type</td><td>1..1</td><td>Required. This contains a value that identifies the vendor of the ChargePoint.</td></tr><tr><td>firmwareVersion</td><td>CiString50Type</td><td>0..1</td><td>Optional. This contains the firmware version of the Charge Point.</td></tr><tr><td>iccid</td><td>CiString20Type</td><td>0..1</td><td>Optional. This contains the ICCID of the modem's SIM card.</td></tr><tr><td>imsi</td><td>CiString20Type</td><td>0..1</td><td>Optional. This contains the IMSI of the modem's SIM card.</td></tr><tr><td>meterSerialNumber</td><td>CiString25Type</td><td>0..1</td><td>Optional. This contains the serial number of the main electrical meter of the Charge Point.</td></tr><tr><td>meterType</td><td>CiString25Type</td><td>0..1</td><td>Optional. This contains the type of the main electrical meter of the Charge Point.</td></tr></table>
+
+# 6.4. BootNotification.conf
+
+This contains the field definition of the BootNotification.conf PDU sent by the Central System to the Charge Point in response to a BootNotification.req PDU. See also Boot Notification
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>currentTime</td><td>dateTime</td><td>1..1</td><td>Required. This contains the Central System's current time.</td></tr><tr><td>interval</td><td>integer</td><td>1..1</td><td>Required. When RegistrationStatus is Accepted, this contains the heartbeat interval in seconds. If the Central System returns something other than Accepted, the value of the interval field indicates the minimum wait time before sending a next BootNotification request.</td></tr><tr><td>status</td><td>RegistrationStatus</td><td>1..1</td><td>Required. This contains whether the Charge Point has been registered within the System Central.</td></tr></table>
+
+# 6.5. CancelReservation.req
+
+This contains the field definition of the CancelReservation.req PDU sent by the Central System to the Charge Point. See also Cancel Reservation
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>reservationId</td><td>integer</td><td>1..1</td><td>Required. Id of the reservation to cancel.</td></tr></table>
+
+# 6.6. CancelReservation.conf
+
+This contains the field definition of the CancelReservation.conf PDU sent by the Charge Point to the Central System in response to a CancelReservation.req PDU. See also Cancel Reservation
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>CancelReservationStatus</td><td>1..1</td><td>Required. This indicates the success or failure of the cancelling of a reservation by Central System.</td></tr></table>
+
+# 6.7. ChangeAvailability.req
+
+This contains the field definition of the ChangeAvailability.req PDU sent by the Central System to the Charge Point. See also Change Availability
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>connectorId</td><td>integer connectorId >= 0</td><td>1..1</td><td>Required. The id of the connector for which availability needs to change. Id '0' (zero) is used if the availability of the Charge Point and all its connectors needs to change.</td></tr><tr><td>type</td><td>AvailabilityType</td><td>1..1</td><td>Required. This contains the type of availability change that the Charge Point should perform.</td></tr></table>
+
+# 6.8. ChangeAvailability.conf
+
+This contains the field definition of the ChangeAvailability.conf PDU return by Charge Point to Central System. See also Change Availability
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>AvailabilityStatus</td><td>1..1</td><td>Required. This indicates whether the Charge Point is able to perform the availability change.</td></tr></table>
+
+# 6.9. ChangeConfiguration.req
+
+This contains the field definition of the ChangeConfiguration.req PDU sent by Central System to Charge Point. It is RECOMMENDED that the content and meaning of the 'key' and 'value' fields is agreed upon between Charge Point and Central System. See also Change Configuration
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>key</td><td>CiString50Type</td><td>1..1</td><td>Required. The name of the configuration setting to change.
+See for standard configuration key names and associated values</td></tr><tr><td>value</td><td>CiString500Type</td><td>1..1</td><td>Required. The new value as string for the setting.
+See for standard configuration key names and associated values</td></tr></table>
+
+# 6.10. ChangeConfiguration.conf
+
+This contains the field definition of the ChangeConfiguration.conf PDU returned from Charge Point to Central System. See also Change Configuration
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>ConfigurationStatus</td><td>1..1</td><td>Required. Returns whether configuration change has been accepted.</td></tr></table>
+
+# 6.11. ClearCache.req
+
+This contains the field definition of the ClearCache.req PDU sent by the Central System to the Charge Point. See also Clear Cache
+
+No fields are defined.
+
+# 6.12. ClearCache.conf
+
+This contains the field definition of the ClearCache.conf PDU sent by the Charge Point to the Central System in response to a ClearCache.req PDU. See also Clear Cache
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>ClearCacheStatus</td><td>1..1</td><td>Required. Accepted if the Charge Point has executed the request, otherwise rejected.</td></tr></table>
+
+# 6.13. ClearChargingProfile.req
+
+This contains the field definition of the ClearChargingProfile.req PDU sent by the Central System to the Charge Point.
+
+The Central System can use this message to clear (remove) either a specific charging profile (denoted by id) or a selection of charging profiles that match with the values of the optional connectorId, stackLevel and chargingProfilePurpose fields. See also Clear Charging Profile
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>id</td><td>integer</td><td>0..1</td><td>Optional. The ID of the charging profile to clear.</td></tr><tr><td>connectorId</td><td>integer</td><td>0..1</td><td>Optional. Specifies the ID of the connector for which to clear charging profiles. A connectorId of zero (0) specifies the charging profile for the overall Charge Point. Absence of this parameter means the clearing applies to all charging profiles that match the other criteria in the request.</td></tr><tr><td>chargingProfilePurpose</td><td>ChargingProfilePurposeType</td><td>0..1</td><td>Optional. Specifies to purpose of the charging profiles that will be cleared, if they meet the other criteria in the request.</td></tr><tr><td>stackLevel</td><td>integer</td><td>0..1</td><td>Optional. specifies the stackLevel for which charging profiles will be cleared, if they meet the other criteria in the request</td></tr></table>
+
+# 6.14. ClearChargingProfile.conf
+
+This contains the field definition of the ClearChargingProfile.conf PDU sent by the Charge Point to the Central System in response to a ClearChargingProfile.req PDU. See also Clear Charging Profile
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>ClearChargingProfileStatus</td><td>1..1</td><td>Required. Indicates if the Charge Point was able to execute the request.</td></tr></table>
+
+# 6.15. DataTransfer.req
+
+This contains the field definition of the DataTransfer.req PDU sent either by the Central System to the Charge Point or vice versa. See also Data Transfer
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>vendorId</td><td>CiString255Type</td><td>1..1</td><td>Required. This identifies the Vendor specific implementation</td></tr><tr><td>messageId</td><td>CiString50Type</td><td>0..1</td><td>Optional. Additional identification field</td></tr><tr><td>data</td><td>TextLength undefined</td><td>0..1</td><td>Optional. Data without specified length or format.</td></tr></table>
+
+# 6.16. DataTransfer.conf
+
+This contains the field definition of the DataTransfer.conf PDU sent by the Charge Point to the Central System or vice versa in response to a DataTransfer.req PDU. See also Data Transfer
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>DataTransferStatus</td><td>1..1</td><td>Required. This indicates the success or failure of the data transfer.</td></tr><tr><td>data</td><td>TextLength undefined</td><td>0..1</td><td>Optional. Data in response to request.</td></tr></table>
+
+# 6.17. DiagnosticsStatusNotification.req
+
+This contains the field definition of the DiagnosticsStatusNotification.req PDU sent by the Charge Point to the Central System. See also Diagnostics Status Notification
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>DiagnosticsStatus</td><td>1..1</td><td>Required. This contains the status of the diagnostics upload.</td></tr></table>
+
+# 6.18. DiagnosticsStatusNotification.conf
+
+This contains the field definition of the DiagnosticsStatusNotification.conf PDU sent by the Central System to the Charge Point in response to a DiagnosticsStatusNotification.req PDU. See also Diagnostics Status Notification
+
+No fields are defined.
+
+# 6.19. FirmwareStatusNotification.req
+
+This contains the field definition of the FirmwareStatusNotificationacion.req PDU sent by the Charge Point to the Central System. See also Firmware Status Notification
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>FirmwareStatus</td><td>1..1</td><td>Required. This contains the progress status of the firmware installation.</td></tr></table>
+
+# 6.20. FirmwareStatusNotification.conf
+
+This contains the field definition of the FirmwareStatusNotification.conf PDU sent by the Central System to the Charge Point in response to a FirmwareStatusNotification.req PDU. See also Firmware Status Notification
+
+No fields are defined.
+
+# 6.21. GetCompositeSchedule.req
+
+This contains the field definition of the GetCompositeSchedule.req PDU sent by the Central System to the Charge Point. See also Get Composite Schedule
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>connectorId</td><td>integer</td><td>1..1</td><td>Required. The ID of the Connector for which the schedule is requested. When ConnectorId=0, the Charge Point will calculate the expected consumption for the grid connection.</td></tr><tr><td>duration</td><td>integer</td><td>1..1</td><td>Required. Time in seconds. length of requested schedule</td></tr><tr><td>chargingRateUnit</td><td>ChargingRateUnitType</td><td>0..1</td><td>Optional. Can be used to force a power or current profile</td></tr></table>
+
+# 6.22. GetCompositeSchedule.conf
+
+This contains the field definition of the GetCompositeSchedule.conf PDU sent by the Charge Point to the Central System in response to a GetCompositeSchedule.req PDU. See also Get Composite Schedule
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>GetCompositeScheduleStatus</td><td>1..1</td><td>Required. Status of the request. The Charge Point will indicate if it was able to process the request</td></tr><tr><td>connectorId</td><td>integer</td><td>0..1</td><td>Optional. The charging schedule contained in this notification applies to a Connector.</td></tr><tr><td>scheduleStart</td><td>dateTime</td><td>0..1</td><td>Optional. Time. Periods contained in the charging profile are relative to this point in time.
+If status is "Rejected", this field may be absent.</td></tr><tr><td>chargingSchedule</td><td>ChargingSchedule</td><td>0..1</td><td>Optional. Planned Composite Charging Schedule, the energy consumption over time. Always relative to ScheduleStart. If status is "Rejected", this field may be absent.</td></tr></table>
+
+# 6.23. GetConfiguration.req
+
+This contains the field definition of the GetConfiguration.req PDU sent by the Central System to the Charge Point. See also Get Configuration
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>key</td><td>CiString50Type</td><td>0..*</td><td>Optional. List of keys for which the configuration value is requested.</td></tr></table>
+
+# 6.24. GetConfiguration.conf
+
+This contains the field definition of the GetConfiguration.conf PDU sent by Charge Point the to the Central System in response to a GetConfiguration.req. See also Get Configuration
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>configurationKey</td><td>KEYValue</td><td>0..*</td><td>Optional. List of requested or known keys</td></tr><tr><td>unknownKey</td><td>CiString50Type</td><td>0..*</td><td>Optional. Requested keys that are unknown</td></tr></table>
+
+# 6.25. GetDiagnostics.req
+
+This contains the field definition of the GetDiagnostics.req PDU sent by the Central System to the Charge Point. See also Get Diagnostics
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>location</td><td>anyURI</td><td>1..1</td><td>Required. This contains the location (directory) where the diagnostics file shall be uploaded to.</td></tr><tr><td>retries</td><td>integer</td><td>0..1</td><td>Optional. This specifies how many times Charge Point must try to upload the diagnostics before giving up. If this field is not present, it is left to Charge Point to decide how many times it wants to retry.</td></tr><tr><td>retrypInterval</td><td>integer</td><td>0..1</td><td>Optional. The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charge Point to decide how long to wait between attempts.</td></tr><tr><td>startTime</td><td>dateTime</td><td>0..1</td><td>Optional. This contains the date and time of the oldest logging information to include in the diagnostics.</td></tr><tr><td>stopTime</td><td>dateTime</td><td>0..1</td><td>Optional. This contains the date and time of the latest logging information to include in the diagnostics.</td></tr></table>
+
+# 6.26. GetDiagnostics.conf
+
+This contains the field definition of the GetDiagnostics.conf PDU sent by the Charge Point to the Central System in response to a GetDiagnostics.req PDU. See also Get Diagnostics
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>fileName</td><td>CiString255Type</td><td>0..1</td><td>Optional. This contains the name of the file with diagnostic information that will be uploaded. This field is not present when no diagnostic information is available.</td></tr></table>
+
+# 6.27. GetLocalListVersion.req
+
+This contains the field definition of the GetLocalListVersion.req PDU sent by the Central System to the Charge Point. See also Get Local List Version
+
+No fields are defined.
+
+# 6.28. GetLocalListVersion.conf
+
+This contains the field definition of the GetLocalListVersion.conf PDU sent by the Charge Point to Central System in response to a GetLocalListVersion.req PDU. See also Get Local List Version
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>listVersion</td><td>integer</td><td>1..1</td><td>Required. This contains the current version number of the local authorization list in the Charge Point.</td></tr></table>
+
+# 6.29. Heartbeat.req
+
+This contains the field definition of the Heartbeat.req PDU sent by the Charge Point to the Central System. See also Heartbeat
+
+No fields are defined.
+
+# 6.30. Heartbeat.conf
+
+This contains the field definition of the Heartbeat.conf PDU sent by the Central System to the Charge Point in response to a Heartbeat.req PDU. See also Heartbeat
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>currentTime</td><td>dateTime</td><td>1..1</td><td>Required. This contains the current time of the Central System.</td></tr></table>
+
+# 6.31. MeterValues.req
+
+This contains the field definition of the MeterValues.req PDU sent by the Charge Point to the Central System. See also Meter Values
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>connectorId</td><td>integer
+connectorId >= 0</td><td>1..1</td><td>Required. This contains a number (>0) designating a connector of the Charge Point:'0'(zero) is used to designate the main powermeter.</td></tr><tr><td>transactionId</td><td>integer</td><td>0..1</td><td>Optional. The transaction to which these meter samples are related.</td></tr><tr><td>meterValue</td><td>MeterValue</td><td>1..*</td><td>Required. The sampled meter values with timestamps.</td></tr></table>
+
+# 6.32. MeterValues.conf
+
+This contains the field definition of the MeterValues.conf PDU sent by the Central System to the Charge Point in response to a MeterValues.req PDU. See also Meter Values
+
+No fields are defined.
+
+# 6.33. RemoteStartTransaction.req
+
+This contains the field definitions of the RemoteStartTransaction.req PDU sent to Charge Point by Central System. See also Remote Start Transaction
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>connectorId</td><td>integer</td><td>0..1</td><td>Optional. Number of the connector on which to start the transaction. connectorId SHALL be > 0</td></tr><tr><td>idTag</td><td>IdToken</td><td>1..1</td><td>Required. The identifier that Charge Point must use to start a transaction.</td></tr><tr><td>chargingProfile</td><td>ChargingProfile</td><td>0..1</td><td>Optional. Charging Profile to be used by the Charge Point for the requested transaction. ChargingProfilePurpose MUST be set to TxProfile</td></tr></table>
+
+# 6.34. RemoteStartTransaction.conf
+
+This contains the field definitions of the RemoteStartTransaction.conf PDU sent from Charge Point to Central System. See also Remote Start Transaction
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>RemoteStartStopStatus</td><td>1..1</td><td>Required. Status indicating whether Charge Point accepts the request to start a transaction.</td></tr></table>
+
+# 6.35. RemoteStopTransaction.req
+
+This contains the field definitions of the RemoteStopTransaction.req PDU sent to Charge Point by Central System. See also Remote Stop Transaction
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>transactionId</td><td>integer</td><td>1..1</td><td>Required. The identifier of the transaction which Charge Point is requested to stop.</td></tr></table>
+
+# 6.36. RemoteStopTransaction.conf
+
+This contains the field definitions of the RemoteStopTransaction.conf PDU sent from Charge Point to Central System. See also Remote Stop Transaction
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>RemoteStartStopStatus</td><td>1..1</td><td>Required. Status indicating whether Charge Point accepts the request to stop a transaction.</td></tr></table>
+
+# 6.37. ReserveNow.req
+
+This contains the field definition of the ReserveNow.req PDU sent by the Central System to the Charge Point. See also Reserve Now
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>connectorId</td><td>integer
+connectorId >= 0</td><td>1..1</td><td>Required. This contains the id of the connector to be reserved. A value of 0 means that the reservation is not for a specific connector.</td></tr><tr><td>expiryDate</td><td>dateTime</td><td>1..1</td><td>Required. This contains the date and time when the reservation ends.</td></tr><tr><td>idTag</td><td>IdToken</td><td>1..1</td><td>Required. The identifier for which the Charge Point has to reserve a connector.</td></tr><tr><td>parentIdTag</td><td>IdToken</td><td>0..1</td><td>Optional. The parent idTag.</td></tr><tr><td>reservationId</td><td>integer</td><td>1..1</td><td>Required. Unique id for this reservation.</td></tr></table>
+
+# 6.38. ReserveNow.conf
+
+This contains the field definition of the ReserveNow.conf PDU sent by the Charge Point to the Central System in response to a ReserveNow.req PDU. See also Reserve Now
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>ReservationStatus</td><td>1..1</td><td>Required. This indicates the success or failure of the reservation.</td></tr></table>
+
+# 6.39. Reset.req
+
+This contains the field definition of the Reset.req PDU sent by the Central System to the Charge Point. See also Reset
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>type</td><td>ResetType</td><td>1..1</td><td>Required. This contains the type of reset that the Charge Point should perform.</td></tr></table>
+
+# 6.40. Reset.conf
+
+This contains the field definition of the Reset.conf PDU sent by the Charge Point to the Central System in response to a Reset.req PDU. See also Reset
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>ResetStatus</td><td>1..1</td><td>Required. This indicates whether the Charge Point is able to perform the reset.</td></tr></table>
+
+# 6.41.SendLocalList.req
+
+This contains the field definition of the SendLocalList.req PDU sent by the Central System to the Charge Point.
+
+If no (empty) localAuthorizationList is given and the updateType is Full, all identifications are removed from the list. Requesting a Differential update without (empty) localAuthorizationList will have no effect on the list. All idTags in the localAuthorizationList MUST be unique, no duplicate values are allowed. See also Send Local List
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>listVersion</td><td>integer</td><td>1..1</td><td>Required. In case of a full update this is the version number of the full list. In case of a differential update it is the version number of the list after the update has been applied.</td></tr><tr><td>localAuthorizationList</td><td>AuthorizationData</td><td>0..*</td><td>Optional. In case of a full update this contains the list of values that form the new local authorization list. In case of a differential update it contains the changes to be applied to the local authorization list in the Charge Point. Maximum number of AuthorizationData elements is available in the configuration key: SendLocalListMaxLength</td></tr><tr><td>updateType</td><td>UpdateType</td><td>1..1</td><td>Required. This contains the type of update (full or differential) of this request.</td></tr></table>
+
+# 6.42.SendLocalList.conf
+
+This contains the field definition of the SendLocalList.conf PDU sent by the Charge Point to the Central System in response to a SendLocalList.req PDU. See also Send Local List
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>UpdateStatus</td><td>1..1</td><td>Required. This indicates whether the Charge Point has successfully received and applied the update of the local authorization list.</td></tr></table>
+
+# 6.43. SetChargingProfile.req
+
+This contains the field definition of the SetChargingProfile.req PDU sent by the Central System to the Charge Point.
+
+The Central System uses this message to send charging profiles to a Charge Point. See also Set Charging Profile
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>connectorId</td><td>integer</td><td>1..1</td><td>Required. The connector to which the charging profile applies. If connectorId = 0, the message contains an overall limit for the Charge Point.</td></tr><tr><td>csChargingProfiles</td><td>ChargingProfile</td><td>1..1</td><td>Required. The charging profile to be set at the Charge Point.</td></tr></table>
+
+# 6.44. SetChargingProfile.conf
+
+This contains the field definition of the SetChargingProfile.conf PDU sent by the Charge Point to the Central System in response to a SetChargingProfile.req PDU. See also Set Charging Profile
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>ChargingProfileStatus</td><td>1..1</td><td>Required. Returns whether the Charge Point has been able to process the message successfully. This does not guarantee the schedule will be followed to the letter. There might be other constraints the Charge Point may need to take into account.</td></tr></table>
+
+# 6.45.StartTransaction.req
+
+This section contains the field definition of the StartTransaction.req PDU sent by the Charge Point to the Central System. See also Start Transaction
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>connectorId</td><td>integer
+connectorId > 0</td><td>1..1</td><td>Required. This identifies which connector of the Charge Point is used.</td></tr><tr><td>idTag</td><td>IdToken</td><td>1..1</td><td>Required. This contains the identifier for which a transaction has to be started.</td></tr><tr><td>meterStart</td><td>integer</td><td>1..1</td><td>Required. This contains the meter value in Wh for the connector at start of the transaction.</td></tr><tr><td>reservationId</td><td>integer</td><td>0..1</td><td>Optional. This contains the id of the reservation that terminates as a result of this transaction.</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. This contains the date and time on which the transaction is started.</td></tr></table>
+
+# 6.46.StartTransaction.conf
+
+This contains the field definition of the StartTransaction.conf PDU sent by the Central System to the Charge Point in response to a StartTransaction.req PDU. See also Start Transaction
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>idTagInfo</td><td>IdTagInfo</td><td>1..1</td><td>Required. This contains information about authorization status, expiry and parent id.</td></tr><tr><td>transactionId</td><td>integer</td><td>1..1</td><td>Required. This contains the transaction id supplied by the Central System.</td></tr></table>
+
+# 6.47. StatusNotification.req
+
+This contains the field definition of the StatusNotification.req PDU sent by the Charge Point to the Central System. See also Status Notification
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>connectorId</td><td>integer connectorId >= 0</td><td>1..1</td><td>Required. The id of the connector for which the status is reported. Id '0' (zero) is used if the status is for the Charge Point main controller.</td></tr><tr><td>errorCode</td><td>ChargePointErrorCode</td><td>1..1</td><td>Required. This contains the error code reported by the Charge Point.</td></tr><tr><td>info</td><td>CiString50Type</td><td>0..1</td><td>Optional. Additional free format information related to the error.</td></tr><tr><td>status</td><td>ChargePointStatus</td><td>1..1</td><td>Required. This contains the current status of the Charge Point.</td></tr><tr><td>timestamp</td><td>dateTime</td><td>0..1</td><td>Optional. The time for which the status is reported. If absent time of receipt of the message will be assumed.</td></tr><tr><td>vendorId</td><td>CiString255Type</td><td>0..1</td><td>Optional. This identifies the vendor-specific implementation.</td></tr><tr><td>vendorErrorCode</td><td>CiString50Type</td><td>0..1</td><td>Optional. This contains the vendor-specific error code.</td></tr></table>
+
+# 6.48.StatusNotification.conf
+
+This contains the field definition of the StatusNotification.conf PDU sent by the Central System to the Charge Point in response to an StatusNotification.req PDU. See also Status Notification
+
+No fields are defined.
+
+# 6.49. StopTransaction.req
+
+This contains the field definition of the StopTransaction.req PDU sent by the Charge Point to the Central System. See also Stop Transaction
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>idTag</td><td>IdToken</td><td>0..1</td><td>Optional. This contains the identifier which requested to stop the charging. It is optional because a Charge Point may terminate charging without the presence of an idTag, e.g. in case of a reset. A Charge Point SHALL send the idTag if known.</td></tr><tr><td>meterStop</td><td>integer</td><td>1..1</td><td>Required. This contains the meter value in Wh for the connector at end of the transaction.</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. This contains the date and time on which the transaction is stopped.</td></tr><tr><td>transactionId</td><td>integer</td><td>1..1</td><td>Required. This contains the transaction-id as received by the StartTransaction.conf.</td></tr><tr><td>reason</td><td>Reason</td><td>0..1</td><td>Optional. This contains the reason why the transaction was stopped. MAY only be omitted when the Reason is "Local".</td></tr><tr><td>transactionData</td><td>MeterValue</td><td>0..*</td><td>Optional. This contains transaction usage details relevant for billing purposes.</td></tr></table>
+
+# 6.50. StopTransaction.conf
+
+This contains the field definition of the StopTransaction.conf PDU sent by the Central System to the Charge Point in response to a StopTransaction.req PDU. See also Stop Transaction
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>idTagInfo</td><td>IdTagInfo</td><td>0..1</td><td>Optional. This contains information about authorization status, expiry and parent id. It is optional, because a transaction may have been stopped without an identifier.</td></tr></table>
+
+# 6.51. TriggerMessage.req
+
+This contains the field definition of the TriggerMessage.req PDU sent by the Central System to the Charge Point. See also Trigger Message
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>requestedMessage</td><td>MessageTrigger</td><td>1..1</td><td>Required.</td></tr><tr><td>connectorId</td><td>integer
+connectorId > 0</td><td>0..1</td><td>Optional. Only filled in when request applies to a specific connector.</td></tr></table>
+
+# 6.52. TriggerMessage.conf
+
+This contains the field definition of the TriggerMessage.conf PDU sent by the Charge Point to the Central System in response to a TriggerMessage.req PDU. See also Trigger Message
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>TriggerMessageStatus</td><td>1..1</td><td>Required. Indicates whether the Charge Point will send the requested notification or not.</td></tr></table>
+
+# 6.53. UnlockConnector.req
+
+This contains the field definition of the UnlockConnector.req PDU sent by the Central System to the Charge Point. See also Unlock Connector
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>connectorId</td><td>integer
+connectorId > 0</td><td>1..1</td><td>Required. This contains the identifier of the connector to be unlocked.</td></tr></table>
+
+# 6.54. UnlockConnector.conf
+
+This contains the field definition of the UnlockConnector.conf PDU sent by the Charge Point to the Central System in response to an UnlockConnector.req PDU. See also Unlock Connector
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>status</td><td>UnlockStatus</td><td>1..1</td><td>Required. This indicates whether the Charge Point has unlocked the connector.</td></tr></table>
+
+# 6.55. UpdateFirmware.req
+
+This contains the field definition of the UpdateFirmware.req PDU sent by the Central System to the Charge Point. See also Update Firmware
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>location</td><td>anyURI</td><td>1..1</td><td>Required. This contains a string containing a URI pointing to a location from which to retrieve the firmware.</td></tr><tr><td>retries</td><td>integer</td><td>0..1</td><td>Optional. This specifies how many times Charge Point must try to download the firmware before giving up. If this field is not present, it is left to Charge Point to decide how many times it wants to retry.</td></tr><tr><td>retrieveDate</td><td>dateTime</td><td>1..1</td><td>Required. This contains the date and time after which the Charge Point is allowed to retrieve the (new) firmware.</td></tr><tr><td>retryInterval</td><td>integer</td><td>0..1</td><td>Optional. The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charge Point to decide how long to wait between attempts.</td></tr></table>
+
+# 6.56. UpdateFirmware.conf
+
+This contains the field definition of the UpdateFirmware.conf PDU sent by the Charge Point to the Central System in response to a UpdateFirmware.req PDU. See also Update Firmware
+
+No fields are defined.
+
+# 7. Types
+
+# 7.1. AuthorizationData
+
+Class
+
+Elements that constitute an entry of a Local Authorization List update.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>idTag</td><td>IdToken</td><td>1..1</td><td>Required. The identifier to which this authorization applies.</td></tr><tr><td>idTagInfo</td><td>IdTagInfo</td><td>0..1</td><td>Optional. (Required when UpdateType is Full) This contains information about authorization status, expiry and parent id. For a Differential update the following applies: If this element is present, then this entry SHALL be added or updated in the Local Authorization List. If this element is absent, than the entry for this idtag in the Local Authorization List SHALL be deleted.</td></tr></table>
+
+# 7.2. AuthorizationStatus
+
+Enumeration
+
+Status in a response to an Invalidate.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Identifier is allowed for charging.</td></tr><tr><td>Blocked</td><td>Identifier has been blocked. Not allowed for charging.</td></tr><tr><td>Expired</td><td>Identifier has expired. Not allowed for charging.</td></tr><tr><td>Invalid</td><td>Identifier is unknown. Not allowed for charging.</td></tr><tr><td>ConcurrentTx</td><td>Identifier is already involved in another transaction and multiple transactions are not allowed. (Only relevant for a StartTransaction.req.)</td></tr></table>
+
+# 7.3. AvailabilityStatus
+
+Enumeration
+
+Status returned in response to ChangeAvailability.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Rejected</td><td>Request has not been accepted and will not be executed.</td></tr><tr><td>Scheduled</td><td>Request has been accepted and will be executed when transaction(s) in progress have finished.</td></tr></table>
+
+# 7.4. AvailabilityType
+
+Enumeration
+
+Requested availability change in ChangeAvailability.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Inoperative</td><td>Charge point is not available for charging.</td></tr><tr><td>Operative</td><td>Charge point is available for charging.</td></tr></table>
+
+# 7.5. CancelReservationStatus
+
+Enumeration
+
+Status in CancelReservation.conf.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Reservation for the identifier has been cancelled.</td></tr><tr><td>Rejected</td><td>Reservation could not be cancelled, because there is no reservation active for the identifier.</td></tr></table>
+
+# 7.6. ChargePointErrorCode
+
+Enumeration
+
+Charge Point status reported in StatusNotification.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>ConnectorLockFailure</td><td>Failure to lock or unlock connector.</td></tr><tr><td>EVCommunicationError</td><td>Communication failure with the vehicle, might be Mode 3 or other communication protocol problem. This is not a real error in the sense that the Charge Point doesn't need to go to the faulted state. Instead, it should go to the SuspendedEVSE state.</td></tr><tr><td>GroundFailure</td><td>Ground fault circuit interrupter has been activated.</td></tr><tr><td>HighTemperature</td><td>Temperature inside Charge Point is too high.</td></tr><tr><td>InternalError</td><td>Error in internal hard- or software component.</td></tr><tr><td>LocalListConflict</td><td>The authorization information received from the Central System is in conflict with the LocalAuthorizationList.</td></tr><tr><td>NoError</td><td>No error to report.</td></tr><tr><td>OtherError</td><td>Other type of error. More information in vendorErrorCode.</td></tr><tr><td>OverCurrentFailure</td><td>Over current protection device has tripped.</td></tr><tr><td>OverVoltage</td><td>Voltage has risen above an acceptable level.</td></tr><tr><td>PowerMeterFailure</td><td>Failure to read electrical/energy/power meter.</td></tr><tr><td>PowerSwitchFailure</td><td>Failure to control power switch.</td></tr><tr><td>ReaderFailure</td><td>Failure with idTag reader.</td></tr><tr><td>ResetFailure</td><td>Unable to perform a reset.</td></tr><tr><td>UnderVoltage</td><td>Voltage has dropped below an acceptable level.</td></tr><tr><td>WeakSignal</td><td>Wireless communication device reports a weak signal.</td></tr></table>
+
+# 7.7. ChargePointStatus
+
+# Enumeration
+
+Status reported in StatusNotification.req. A status can be reported for the Charge Point main controller (connectorId = 0) or for a specific connector. Status for the Charge Point main controller is a subset of the enumeration: Available, Unavailable or Faulted.
+
+States considered Operative are: Available, Preparing, Charging, SuspendedEVSE, SuspendedEV, Finishing, Reserved.
+States considered Inoperative are: Unavailable, Faulted.
+
+<table><tr><td>STATUS</td><td>CONDITION</td></tr><tr><td>Available</td><td>When a Connector becomes available for a new user (Operative)</td></tr><tr><td>Preparing</td><td>When a Connector becomes no longer available for a new user but there is no ongoing Transaction (yet). Typically a Connector is in preparing state when a user presents a tag, inserts a cable or a vehicle occupies the parking bay (Operative)</td></tr><tr><td>Charging</td><td>When the contactor of a Connector closes, allowing the vehicle to charge (Operative)</td></tr><tr><td>SuspendedEVSE</td><td>When the EV is connected to the EVSE but the EVSE is not offering energy to the EV, e.g. due to a smart charging restriction, local supply power constraints, or as the result of StartTransaction.conf indicating that charging is not allowed etc. (Operative)</td></tr><tr><td>SuspendedEV</td><td>When the EV is connected to the EVSE and the EVSE is offering energy but the EV is not taking any energy. (Operative)</td></tr><tr><td>Finishing</td><td>When a Transaction has stopped at a Connector, but the Connector is not yet available for a new user, e.g. the cable has not been removed or the vehicle has not left the parking bay (Operative)</td></tr><tr><td>Reserved</td><td>When a Connector becomes reserved as a result of a Reserve Now command (Operative)</td></tr><tr><td>Unavailable</td><td>When a Connector becomes unavailable as the result of a Change Availability command or an event upon which the Charge Point transitions to unavailable at its discretion. Upon receipt of a Change Availability command, the status MAY change immediately or the change MAY be scheduled. When scheduled, the Status Notification shall be send when the availability change becomes effective (Inoperative)</td></tr><tr><td>Faulted</td><td>When a Charge Point or connector has reported an error and is not available for energy delivery. (Inoperative).</td></tr></table>
+
+# 7.8. ChargingProfile
+
+Class
+
+A ChargingProfile consists of a ChargingSchedule, describing the amount of power or current that can be delivered per time interval.
+
+
+Figure 42. Class Diagram: ChargingProfile
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>chargingProfileId</td><td>integer</td><td>1..1</td><td>Required. Unique identifier for this profile.</td></tr><tr><td>transactionId</td><td>integer</td><td>0..1</td><td>Optional. Only valid if ChargingProfilePurpose is set to TxProfile, the transactionId MAY be used to match the profile to a specific transaction.</td></tr><tr><td>stackLevel</td><td>integer >=0</td><td>1..1</td><td>Required. Value determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.</td></tr><tr><td>chargingProfilePurpose</td><td>ChargingProfilePurposeType</td><td>1..1</td><td>Required. Defines the purpose of the schedule transferred by this message.</td></tr><tr><td>chargingProfileKind</td><td>ChargingProfileKindType</td><td>1..1</td><td>Required. Indicates the kind of schedule.</td></tr><tr><td>reccencyKind</td><td>ReccuracyKindType</td><td>0..1</td><td>Optional. Indicates the start point of a recurrence.</td></tr><tr><td>validFrom</td><td>dateTime</td><td>0..1</td><td>Optional. Point in time at which the profile starts to be valid. If absent, the profile is valid as soon as it is received by the Charge Point.</td></tr><tr><td>validTo</td><td>dateTime</td><td>0..1</td><td>Optional. Point in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.</td></tr><tr><td>chargingSchedule</td><td>ChargingSchedule</td><td>1..1</td><td>Required. Contains limits for the available power or current over time.</td></tr></table>
+
+# 7.9. ChargingProfileKindType
+
+Enumeration
+
+Kind of charging profile, as used in: ChargingProfile.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Absolute</td><td>Schedule periods are relative to a fixed point in time defined in the schedule.</td></tr><tr><td>Recurring</td><td>The schedule restarts periodically at the first schedule period.</td></tr><tr><td>Relative</td><td>Schedule periods are relative to a situation-specific start point (such as the start of a Transaction) that is determined by the charge point.</td></tr></table>
+
+# 7.10. ChargingProfilePurposeType
+
+Enumeration
+
+Purpose of the charging profile, as used in: ChargingProfile.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>ChargePointMaxProfile</td><td>Configuration for the maximum power or current available for an entire Charge Point.</td></tr><tr><td>TxDefaultProfile</td><td>Default profile *that can be configured in the Charge Point. When a new transaction is started, this profile SHALL be used, unless it was a transaction that was started by a RemoteStartTransaction.req with a ChargeProfile that is accepted by the Charge Point.</td></tr><tr><td>TxProfile</td><td>Profile with constraints to be imposed by the Charge Point on the current transaction, or on a new transaction when this is started via a RemoteStartTransaction.req with a ChargeProfile. A profile with this purpose SHALL cease to be valid when the transaction terminates.</td></tr></table>
+
+# 7.11. ChargingProfileStatus
+
+Enumeration
+
+Status returned in response to SetChargingProfile.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Rejected</td><td>Request has not been accepted and will not be executed.</td></tr><tr><td>NotSupported</td><td>Charge Point indicates that the request is not supported.</td></tr></table>
+
+# 7.12. ChargingRateUnitType
+
+Enumeration
+
+Unit in which a charging schedule is defined, as used in: GetCompositeSchedule.req and ChargingSchedule
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>W</td><td>Watts (power).This is the TOTAL allowed charging power.If used for AC Charging, the phase current should be calculated via: Current per phase = Power / (Line Voltage * Number of Phases). The "Line Voltage" used in the calculation is not the measured voltage, but the set voltage for the area (hence, 230 of 110 volt). The "Number of Phases" is the numberPhases from the ChargingSchedulePeriod.It is usually more convenient to use this for DC charging.Note that if numberPhases in a ChargingSchedulePeriod is absent, 3 SHALL be assumed.</td></tr><tr><td>A</td><td>Amperes (current).The amount of Ampere per phase, not the sum of all phases.It is usually more convenient to use this for AC charging.</td></tr></table>
+
+# 7.13. ChargingSchedule
+
+Class
+
+Charging schedule structure defines a list of charging periods, as used in: GetCompositeSchedule.conf and ChargingProfile.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>duration</td><td>integer</td><td>0..1</td><td>Optional. Duration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction in case startSchedule is absent.</td></tr><tr><td>startSchedule</td><td>dateTime</td><td>0..1</td><td>Optional. Starting point of an absolute schedule. If absent the schedule will be relative to start of charging.</td></tr><tr><td>chargingRateUnit</td><td>ChargingRateUnitType</td><td>1..1</td><td>Required. The unit of measure Limit is expressed in.</td></tr><tr><td>chargingSchedulePeriod</td><td>ChargingSchedulePeriod</td><td>1..*</td><td>Required. List of ChargingSchedulePeriod elements defining maximum power or current usage over time. The startSchedule of the first ChargingSchedulePeriod SHALL always be 0.</td></tr><tr><td>minChargingRate</td><td>decimal</td><td>0..1</td><td>Optional. Minimum charging rate supported by the electric vehicle. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates. Accepts at most one digit fraction (e.g. 8.1)</td></tr></table>
+
+# 7.14. ChargingSchedulePeriod
+
+Class
+
+Charging schedule period structure defines a time period in a charging schedule, as used in: ChargingSchedule.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>startPeriod</td><td>integer</td><td>1..1</td><td>Required. Start of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.</td></tr><tr><td>limit</td><td>decimal</td><td>1..1</td><td>Required. Charging rate limit during the schedule period, in the applicable chargingRateUnit, for example in Amperes or Watts. Accepts at most one digit fraction (e.g. 8.1).</td></tr><tr><td>numberPhases</td><td>integer</td><td>0..1</td><td>Optional. The number of phases that can be used for charging. If a number of phases is needed, numberPhases=3 will be assumed unless another number is given.</td></tr></table>
+
+# 7.15. CiString20Type
+
+Type
+
+Generic used case insensitive string of 20 characters.
+
+<table><tr><td>FIELD TYPE</td><td>DESCRIPTION</td></tr><tr><td>CiString[20]</td><td>String is case insensitive.</td></tr></table>
+
+# 7.16. CiString25Type
+
+Type
+
+<table><tr><td>FIELD TYPE</td><td>DESCRIPTION</td></tr><tr><td>CiString[25]</td><td>String is case insensitive.</td></tr></table>
+
+# 7.17. CiString50Type
+
+Type
+
+Generic used case insensitive string of 50 characters.
+
+<table><tr><td>FIELD TYPE</td><td>DESCRIPTION</td></tr><tr><td>CiString[50]</td><td>String is case insensitive.</td></tr></table>
+
+# 7.18. CiString255Type
+
+Type
+
+Generic used case insensitive string of 255 characters.
+
+<table><tr><td>FIELD TYPE</td><td>DESCRIPTION</td></tr><tr><td>CiString[255]</td><td>String is case insensitive.</td></tr></table>
+
+# 7.19. CiString500Type
+
+Type
+
+Generic used case insensitive string of 500 characters.
+
+<table><tr><td>FIELD TYPE</td><td>DESCRIPTION</td></tr><tr><td>CiString[500]</td><td>String is case insensitive.</td></tr></table>
+
+# 7.20. ClearCacheStatus
+
+Enumeration
+
+Status returned in response to ClearCache.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Command has been executed.</td></tr><tr><td></td><td></td></tr><tr><td>Rejected</td><td>Command has not been executed.</td></tr></table>
+
+# 7.21. ClearChargingProfileStatus
+
+Enumeration
+
+Status returned in response to ClearChargingProfile.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Unknown</td><td>No Charging Profile(s) were found matching the request.</td></tr></table>
+
+# 7.22. ConfigurationStatus
+
+Enumeration
+
+Status in ChangeConfiguration.conf.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Configuration key is supported and setting has been changed.</td></tr><tr><td>Rejected</td><td>Configuration key is supported, but setting could not be changed.</td></tr><tr><td>RebootRequired</td><td>Configuration key is supported and setting has been changed, but change will be available after reboot (Charge Point will not reboot itself)</td></tr><tr><td>NotSupported</td><td>Configuration key is not supported.</td></tr></table>
+
+# 7.23. DataTransferStatus
+
+Enumeration
+
+Status in DataTransfer.conf.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Message has been accepted and the contained request is accepted.</td></tr><tr><td>Rejected</td><td>Message has been accepted but the contained request is rejected.</td></tr><tr><td>UnknownMessageld</td><td>Message could not be interpreted due to unknown messageld string.</td></tr><tr><td>UnknownVendorId</td><td>Message could not be interpreted due to unknown vendorId string.</td></tr></table>
+
+# 7.24. DiagnosticsStatus
+
+Enumeration
+
+Status in DiagnosticsStatusNotification.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Idle</td><td>Charge Point is not performing diagnostics related tasks. Status Idle SHALL only be used as in a DiagnosticsStatusNotification.req that was triggered by a TriggerMessage.req</td></tr><tr><td>Uploaded</td><td>Diagnostics information has been uploaded.</td></tr><tr><td>UploadFailed</td><td>Uploading of diagnostics failed.</td></tr><tr><td>Uploading</td><td>File is being uploaded.</td></tr></table>
+
+# 7.25. FirmwareStatus
+
+Enumeration
+
+Status of a firmware download as reported in FirmwareStatusNotification.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Downloaded</td><td>New firmware has been downloaded by Charge Point.</td></tr><tr><td>DownloadFailed</td><td>Charge point failed to download firmware.</td></tr><tr><td>Downloading</td><td>Firmware is being downloaded.</td></tr><tr><td>Idle</td><td>Charge Point is not performing firmware update related tasks. Status Idle SHALL only be used as in a FirmwareStatusNotification.req that was triggered by a TriggerMessage.req</td></tr><tr><td>InstallationFailed</td><td>Installation of new firmware has failed.</td></tr><tr><td>Installing</td><td>Firmware is being installed.</td></tr><tr><td>Installed</td><td>New firmware has successfully been installed in charge point.</td></tr></table>
+
+# 7.26. GetCompositeScheduleStatus
+
+Enumeration
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Rejected</td><td>Request has not been accepted and will not be executed.</td></tr></table>
+
+# 7.27.IdTagInfo
+
+Class
+
+Contains status information about an identifier. It is returned inauthorize,Start Transaction and Stop Transaction responses.
+
+If expiryDate is not given, the status has no end date.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>expireDate</td><td>dateTime</td><td>0..1</td><td>Optional. This contains the date at which idTag should be removed from the Authorization Cache.</td></tr><tr><td>parentIdTag</td><td>IdToken</td><td>0..1</td><td>Optional. This contains the parent-identifier.</td></tr><tr><td>status</td><td>AuthorizationStatus</td><td>1..1</td><td>Required. This contains whether the idTag has been accepted or not by the Central System.</td></tr></table>
+
+# 7.28. IdToken
+
+Type
+
+Contains the identifier to use for authorization. It is a case insensitive string. In future releases this may become a complex type to support multiple forms of identifiers.
+
+<table><tr><td>FIELD TYPE</td><td>DESCRIPTION</td></tr><tr><td>CiString20Type</td><td>IdToken is case insensitive.</td></tr></table>
+
+# 7.29. KeyValue
+
+Class
+
+Contains information about a specific configuration key. It is returned in GetConfiguration.conf.
+
+<table><tr><td>NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>key</td><td>CiString50Type</td><td>1..1</td><td>Required.</td></tr><tr><td>readonly</td><td>boolean</td><td>1..1</td><td>Required. False if the value can be set with the ChangeConfiguration message.</td></tr><tr><td>value</td><td>CString500Type</td><td>0..1</td><td>Optional. If key is known but not set, this field may be absent.</td></tr></table>
+
+# 7.30. Location
+
+Enumeration
+
+Allowable values of the optional "location" field of a value element in SampledValue.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Body</td><td>Measurement inside body of Charge Point (e.g. Temperature)</td></tr><tr><td>Cable</td><td>Measurement taken from cable between EV and Charge Point</td></tr><tr><td>EV</td><td>Measurement taken by EV</td></tr><tr><td>Inlet</td><td>Measurement at network ("grid") inlet connection</td></tr><tr><td>Outlet</td><td>Measurement at a Connector. Default value</td></tr></table>
+
+# 7.31. Measurand
+
+Enumeration
+
+Allowable values of the optional "measurand" field of a Value element, as used in MeterValues.req and StopTransaction.req messages. Default value of "measurand" is always "Energy.Active.Import.Register"
+
+
+
+Import is energy flow from the Grid to the Charge Point, EV or other load. Export is energy flow from the EV to the Charge Point and/or from the Charge Point to the Grid.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Current.Export</td><td>Instantaneous current flow from EV</td></tr><tr><td>Current.Import</td><td>Instantaneous current flow to EV</td></tr><tr><td>Current.Offered</td><td>Maximum current offered to EV</td></tr><tr><td>Energy.Active.Exit.Register</td><td>Numerical value read from the "active electrical energy" (Wh or kWh) register of the (most authoritative) electrical meter measuring energy exported (to the grid).</td></tr><tr><td>Energy.Active.Import.Register</td><td>Numerical value read from the "active electrical energy" (Wh or kWh) register of the (most authoritative) electrical meter measuring energy imported (from the grid supply).</td></tr><tr><td>Energy.Reactive.Export.Register</td><td>Numerical value read from the "reactive electrical energy" (VARh or kVARh) register of the (most authoritative) electrical meter measuring energy exported (to the grid).</td></tr><tr><td>Energy.Reactive.Import.Register</td><td>Numerical value read from the "reactive electrical energy" (VARh or kVARh) register of the (most authoritative) electrical meter measuring energy imported (from the grid supply).</td></tr><tr><td>Energy.ActiveEXPORTInterval</td><td>Absolute amount of "active electrical energy" (Wh or kWh) exported (to the grid) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for "ClockAlignedDataInterval" and "MeterValueSampleInterval".</td></tr><tr><td>Energy.ActiveImportInterval</td><td>Absolute amount of "active electrical energy" (Wh or kWh) imported (from the grid supply) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for "ClockAlignedDataInterval" and "MeterValueSampleInterval".</td></tr><tr><td>Energy.ReactiveExportInterval</td><td>Absolute amount of "reactive electrical energy" (VARh or kVARh) exported (to the grid) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for "ClockAlignedDataInterval" and "MeterValueSampleInterval".</td></tr><tr><td>Energy.Reactive.ImportInterval</td><td>Absolute amount of "reactive electrical energy" (VARh or kVARh) imported (from the grid supply) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for "ClockAlignedDataInterval" and "MeterValueSampleInterval".</td></tr><tr><td>Frequency</td><td>Instantaneous reading of powerline frequency. NOTE: OCPP 1.6 does not have a UnitOfMeasure for frequency, the UnitOfMeasure for any SampledValue with measurand: Frequency is Hertz.</td></tr><tr><td>Power.ActiveExport</td><td>Instantaneous active power exported by EV. (W or kW)</td></tr><tr><td>Power.ActiveImport</td><td>Instantaneous active power imported by EV. (W or kW)</td></tr><tr><td>Power.Factor</td><td>Instantaneous power factor of total energy flow</td></tr><tr><td>Power.Offered</td><td>Maximum power offered to EV</td></tr><tr><td>Power.ReactiveExport</td><td>Instantaneous reactive power exported by EV. (var or kvar)</td></tr><tr><td>Power.Reactive.Import</td><td>Instantaneous reactive power imported by EV. (var or kvar)</td></tr><tr><td>RPM</td><td>Fan speed in RPM</td></tr><tr><td>SoC</td><td>State of charge of charging vehicle in percentage</td></tr><tr><td>Temperature</td><td>Temperature reading inside Charge Point.</td></tr><tr><td>Voltage</td><td>Instantaneous AC RMS supply voltage</td></tr></table>
+
+All "Register" values relating to a single charging transaction, or a non-transactional consumer (e.g. charge point internal power supply, overall supply) MUST be monotonically increasing in time.
+
+
+
+The actual quantity of energy corresponding to a reported ".Register" value is computed as the register value in question minus the register value recorded/reported at the start of the transaction or other relevant starting reference point in time. For improved auditability, ".Register" values SHOULD be reported exactly as they are directly read from a non-volatile register in the electrical metering hardware, and SHOULD NOT be re-based to zero at the start of transactions. This allows any "missing energy" between sequential transactions, due to hardware fault, mis-wiring, fraud, etc. to be identified, by allowing the Central System to confirm that the starting register value of any transaction is identical to the finishing register value of the preceding transaction on the same connector.
+
+# 7.32. MessageTrigger
+
+Enumeration
+
+Type of request to be triggered in a TriggerMessage.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>BootNotification</td><td>To trigger a BootNotification request</td></tr><tr><td>DiagnosticsStatusNotification</td><td>To trigger a DiagnosticsStatusNotification request</td></tr><tr><td>FirmwareStatusNotification</td><td>To trigger a FirmwareStatusNotification request</td></tr><tr><td>Heartbeat</td><td>To trigger a Heartbeat request</td></tr><tr><td>MeterValues</td><td>To trigger a MeterValues request</td></tr><tr><td>StatusNotification</td><td>To trigger a StatusNotification request</td></tr></table>
+
+# 7.33. MeterValue
+
+Class
+
+Collection of one or more sampled values in MeterValues.req and StopTransaction.req. All sampled values in a MeterValue are sampled at the same point in time.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp for measured value(s).</td></tr><tr><td>sampledValue</td><td>SampledValue</td><td>1..*</td><td>Required. One or more measured values</td></tr></table>
+
+# 7.34. Phase
+
+# Enumeration
+
+Phase as used in SampledValue. Phase specifies how a measured value is to be interpreted. Please note that not all values of Phase are applicable to all Measurands.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>L1</td><td>Measured on L1</td></tr><tr><td>L2</td><td>Measured on L2</td></tr><tr><td>L3</td><td>Measured on L3</td></tr><tr><td>N</td><td>Measured on Neutral</td></tr><tr><td>L1-N</td><td>Measured on L1 with respect to Neutral conductor</td></tr><tr><td>L2-N</td><td>Measured on L2 with respect to Neutral conductor</td></tr><tr><td>L3-N</td><td>Measured on L3 with respect to Neutral conductor</td></tr><tr><td>L1-L2</td><td>Measured between L1 and L2</td></tr><tr><td>L2-L3</td><td>Measured between L2 and L3</td></tr><tr><td>L3-L1</td><td>Measured between L3 and L1</td></tr></table>
+
+# 7.35. ReadingContext
+
+# Enumeration
+
+Values of the context field of a value in SampledValue.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Interruption.Begin</td><td>Value taken at start of interruption.</td></tr><tr><td>Interruption.End</td><td>Value taken when resuming after interruption.</td></tr><tr><td>Other</td><td>Value for any other situations.</td></tr><tr><td>Sample.Clock</td><td>Value taken at clock aligned interval.</td></tr><tr><td>Sample.Periodic</td><td>Value taken as periodic sample relative to start time of transaction.</td></tr><tr><td>Transaction.Begin</td><td>Value taken at start of transaction.</td></tr><tr><td>Transaction.End</td><td>Value taken at end of transaction.</td></tr><tr><td>Trigger</td><td>Value taken in response to a TriggerMessage.req</td></tr></table>
+
+# 7.36. Reason
+
+Enumeration
+
+Reason for stopping a transaction in StopTransaction.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>DeAuthorized</td><td>The transaction was stopped because of the authorization status in a StartTransaction.conf</td></tr><tr><td>EmergencyStop</td><td>Emergency stop button was used.</td></tr><tr><td>EVDisconnected</td><td>disconnecting of cable, vehicle moved away from inductive charge unit.</td></tr><tr><td>HardReset</td><td>A hard reset command was received.</td></tr><tr><td>Local</td><td>Stopped locally on request of the user at the Charge Point. This is a regular termination of a transaction. Examples: presenting an RFID tag, pressing a button to stop.</td></tr><tr><td>Other</td><td>Any other reason.</td></tr><tr><td>PowerLoss</td><td>Complete loss of power.</td></tr><tr><td>Reboot</td><td>A locally initiated reset/reboot occurred. (for instance watchdog kicked in)</td></tr><tr><td>Remote</td><td>Stopped remotely on request of the user. This is a regular termination of a transaction. Examples: termination using a smartphone app, exceeding a (non local) prepaid credit.</td></tr><tr><td>SoftReset</td><td>A soft reset command was received.</td></tr><tr><td>UnlockCommand</td><td>Central System sent an Unlock Connector command.</td></tr></table>
+
+# 7.37. ReccurrencyKindType
+
+Enumeration
+
+Type of recurrence of a charging profile, as used in ChargingProfile.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Daily</td><td>The schedule restarts every 24 hours, at the same time as in the startSchedule.</td></tr><tr><td>Weekly</td><td>The schedule restarts every 7 days, at the same time and day-of-the-week as in the startSchedule.</td></tr></table>
+
+# 7.38. RegistrationStatus
+
+Enumeration
+
+Result of registration in response to BootNotification.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Charge point is accepted by Central System.</td></tr><tr><td>Pending</td><td>Central System is not yet ready to accept the Charge Point. Central System may send messages to retrieve information or prepare the Charge Point.</td></tr><tr><td>Rejected</td><td>Charge point is not accepted by Central System. This may happen when the Charge Point id is not known by Central System.</td></tr></table>
+
+# 7.39. RemoteStartStopStatus
+
+Enumeration
+
+The result of a RemoteStartTransaction.req or RemoteStopTransaction.req request.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Command will be executed.</td></tr><tr><td>Rejected</td><td>Command will not be executed.</td></tr></table>
+
+# 7.40. ReservationStatus
+
+Enumeration
+
+Status in ReserveNow.conf.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Reservation has been made.</td></tr><tr><td>Faulted</td><td>Reservation has not been made, because connectors or specified connector are in a faulted state.</td></tr><tr><td>Occupied</td><td>Reservation has not been made. All connectors or the specified connector are occupied.</td></tr><tr><td>Rejected</td><td>Reservation has not been made. Charge Point is not configured to accept reservations.</td></tr><tr><td>Unavailable</td><td>Reservation has not been made, because connectors or specified connector are in an unavailable state.</td></tr></table>
+
+# 7.41. ResetStatus
+
+Enumeration
+
+Result of Reset.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Command will be executed.</td></tr><tr><td>Rejected</td><td>Command will not be executed.</td></tr></table>
+
+# 7.42. ResetType
+
+Enumeration
+
+Type of reset requested by Reset.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Hard</td><td>Restart (all) the hardware, the Charge Point is not required to gracefully stop ongoing transaction. If possible the Charge Point sends a StopTransaction.req for previously ongoing transactions after having restarted and having been accepted by the Central System via a BootNotification.conf. This is a last resort solution for a not correctly functioning Charge Point, by sending a "hard" reset, (queued) information might get lost.</td></tr><tr><td>Soft</td><td>Stop ongoing transactions gracefully and sending StopTransaction.req for every ongoing transaction. It should then restart the application software (if possible, otherwise restart the processor/controller).</td></tr></table>
+
+# 7.43. SampledValue
+
+Class
+
+Single sampled value in MeterValues. Each value can be accompanied by optional fields.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CARD.</td><td>DESCRIPTION</td></tr><tr><td>value</td><td>String</td><td>1..1</td><td>Required. Value as a “Raw” (decimal) number or “SignedData”. Field Type is “string” to allow for digitally signed data readings. Decimal numeric values are also acceptable to allow fractional values for measurands such as Temperature and Current.</td></tr><tr><td>context</td><td>ReadingContext</td><td>0..1</td><td>Optional. Type of detail value: start, end or sample. Default = “Sample.Periodic”</td></tr><tr><td>format</td><td>ValueFormat</td><td>0..1</td><td>Optional. Raw or signed data. Default = “Raw”</td></tr><tr><td>measurand</td><td>Measurand</td><td>0..1</td><td>Optional. Type of measurement. Default = “Energy.Active.Import.Register”</td></tr><tr><td>phase</td><td>Phase</td><td>0..1</td><td>Optional. indicates how the measured value is to be interpreted. For instance between L1 and neutral (L1-N) Please note that not all values of phase are applicable to all Measurands. When phase is absent, the measured value is interpreted as an overall value.</td></tr><tr><td>location</td><td>Location</td><td>0..1</td><td>Optional. Location of measurement. Default="Outlet"</td></tr><tr><td>unit</td><td>UnitOfMeasure</td><td>0..1</td><td>Optional. Unit of the value. Default = "Wh" if the (default) measurand is an "Energy" type.</td></tr></table>
+
+# 7.44. TriggerMessageStatus
+
+Enumeration
+
+Status in TriggerMessage.conf.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Requested notification will be sent.</td></tr><tr><td>Rejected</td><td>Requested notification will not be sent.</td></tr><tr><td>NotImplemented</td><td>Requested notification cannot be sent because it is either not implemented or unknown.</td></tr></table>
+
+# 7.45. UnitOfMeasure
+
+Enumeration
+
+Allowable values of the optional "unit" field of a Value element, as used in SampledValue. Default value of "unit" is always "Wh".
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Wh</td><td>Watt-hours (energy). Default.</td></tr><tr><td>kWh</td><td>kiloWatt-hours (energy).</td></tr><tr><td>varh</td><td>Var-hours (reactive energy).</td></tr><tr><td>kvarh</td><td>kilovar-hours (reactive energy).</td></tr><tr><td>W</td><td>Watts (power).</td></tr><tr><td>kW</td><td>kilowatts (power).</td></tr><tr><td>VA</td><td>VoltAmpere (apparent power).</td></tr><tr><td>kVA</td><td>kiloVolt Ampere (apparent power).</td></tr><tr><td>var</td><td>Vars (reactive power).</td></tr><tr><td>kvar</td><td>kilovars (reactive power).</td></tr><tr><td>A</td><td>Amperes (current).</td></tr><tr><td>V</td><td>Voltage (r.m.s. AC).</td></tr><tr><td>Celsius</td><td>Degrees (temperature).</td></tr><tr><td>Fahrenheit</td><td>Degrees (temperature).</td></tr><tr><td>K</td><td>Degrees Kelvin (temperature).</td></tr><tr><td>Percent</td><td>Percentage.</td></tr></table>
+
+# 7.46. UnlockStatus
+
+Enumeration
+
+Status in response to UnlockConnector.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Unlocked</td><td>Connector has successfully been unlocked.</td></tr><tr><td>UnlockFailed</td><td>Failed to unlock the connector: The Charge Point has tried to unlock the connector and has detected that the connector is still locked or the unlock mechanism failed.</td></tr><tr><td>NotSupported</td><td>Charge Point has no connector lock, or ConnectorId is unknown.</td></tr></table>
+
+# 7.47. UpdateStatus
+
+Enumeration
+
+Type of update for a SendLocalList.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Accepted</td><td>Local Authorization List successfully updated.</td></tr><tr><td>Failed</td><td>Failed to update the Local Authorization List.</td></tr><tr><td>NotSupported</td><td>Update of Local Authorization List is not supported by Charge Point.</td></tr><tr><td>VersionMismatch</td><td>Version number in the request for a differential update is less or equal then version number of current list.</td></tr></table>
+
+# 7.48. UpdateType
+
+Enumeration
+
+Type of update for a SendLocalList.req.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Differential</td><td>Indicates that the current Local Authorization List must be updated with the values in this message.</td></tr><tr><td>Full</td><td>Indicates that the current Local Authorization List must be replaced by the values in this message.</td></tr></table>
+
+# 7.49. ValueFormat
+
+Enumeration
+
+Format that specifies how the value element in SampledValue is to be interpreted.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Raw</td><td>Data is to be interpreted as integer/decimal numeric data.</td></tr><tr><td>SignedData</td><td>Data is represented as a signed binary data block, encoded as hex data.</td></tr></table>
+
+# 8. Firmware and Diagnostics File Transfer
+
+This section is normative.
+
+The supported transfer protocols are controlled by the configuration key SupportedFileTransferProtocols. FTP, FTPS, HTTP, HTTPS (CSL)
+
+# 8.1. Download Firmware
+
+When a Charge Point is notified about new firmware, it needs to be able to download this firmware. The Central System supplies in the request an URL where the firmware can be downloaded. The URL also contains the protocol which must be used to download the firmware.
+
+It is recommended that the firmware is downloaded via FTP or FTPS. FTP(S) is better optimized for large binary data than HTTP. Also FTP(S) has the ability to resume downloads. In case a download is interrupted, the Charge Point can resume downloading after the part it already has downloaded. The FTP URL is of format: ftp://user :password@host:port/path in which the parts user:password@, :password or :port may be excluded.
+
+To ensure that the correct firmware is downloaded, it is RECOMMENDED that the firmware is also digitally signed.
+
+# 8.2. Upload Diagnostics
+
+When a Charge Point is requested to upload a diagnostics file, the Central System supplies in the request an URL where the Charge Point should upload the file. The URL also contains the protocol which must be used to upload the file.
+
+It is recommended that the diagnostics file is downloaded via FTP or FTPS. FTP(S) is better optimized for large binary data than HTTP. Also FTP(S) has the ability to resume uploads. In case an upload is interrupted, the Charge Point can resume uploading after the part it already has uploaded. The FTP URL is of format: ftp://user :password@host:port/path in which the parts user:jpassword@, :password or :port may be excluded.
+
+# 9. Standard Configuration Key Names & Values
+
+Below follows a list of all configuration keys with a role standardized in this specification. The list is separated by Feature Profiles. A required configuration key mentioned under a particular profile only has to be supported by the Charge Point if it supports that profile.
+
+For optional Configuration Keys with a boolean type, the following rules apply for the configuration key in the response to a GetConfiguration.req without a list of keys:
+
+- If the key is present, the Charge Point provides the functionality that is configured by the key, and it can be enabled or disabled by setting the value for the key.
+- If the key is not present, the Charge Point does not provide the functionality that can be configured by the key.
+
+The "Accessibility" property shows if the value for a certain configuration key is read-only ("R") or read-write ("RW"). In case the key is read-only, the Central System can read the value for the key using GetConfiguration, but not write it. In case the accessibility is read-write, the Central System can also write the value for the key using ChangeConfiguration.
+
+# 9.1. Core Profile
+
+# 9.1.1. AllowOfflineTxForUnknownId
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>boolean</td></tr><tr><td>Description</td><td>If this key exists, the Charge Point supports Unknown Offline Authorization. If this key reports a value of true, Unknown Offline Authorization is enabled.</td></tr></table>
+
+# 9.1.2. AuthorizationCacheEnabled
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>boolean</td></tr><tr><td>Description</td><td>If this key exists, the Charge Point supports an Authorization Cache. If this key reports a value of true, the Authorization Cache is enabled.</td></tr></table>
+
+# 9.1.3.authorizeRemoteTxRequests
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td></td><td></td></tr><tr><td>Accessibility</td><td>R or RW. Choice is up to Charge Point implementation.</td></tr><tr><td>Type</td><td>boolean</td></tr><tr><td>Description</td><td>Whether a remote request to start a transaction in the form of a RemoteStartTransaction.req message should be authorized beforehand like a local action to start a transaction.</td></tr></table>
+
+# 9.1.4. BlinkRepeat
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Unit</td><td>times</td></tr><tr><td>Description</td><td>Number of times to blink Charge Point lighting when signalling</td></tr></table>
+
+# 9.1.5. ClockAlignedDataInterval
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Unit</td><td>seconds</td></tr><tr><td>Description</td><td>Size (in seconds) of the clock-aligned data interval. 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.</td></tr></table>
+
+# 9.1.6. ConnectionTimeOut
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Unit</td><td>seconds</td></tr></table>
+
+Description
+
+Interval \*from beginning of status: 'Preparing' until incipient Transaction is automatically canceled, due to failure of EV driver to (correctly) insert the charging cable connector(s) into the appropriate socket(s). The Charge Point SHALL go back to the original state, probably: 'Available'.
+
+# 9.1.7. ConnectorPhaseRotation
+
+Required/optional
+
+required
+
+Accessibility
+
+RW
+
+Type
+
+CSL
+
+Description
+
+The phase rotation per connector in respect to the connector's electrical meter (or if absent, the grid connection). Possible values per connector are:
+
+NotApplicable (for Single phase or DC Charge Points)
+
+Unknown (not (yet) known)
+
+RST (Standard Reference Phasing)
+
+RTS (Reversed Reference Phasing)
+
+SRT (Reversed 240 degree rotation)
+
+STR (Standard 120 degree rotation)
+
+TRS (Standard 240 degree rotation)
+
+TSR (Reversed 120 degree rotation)
+
+R can be identified as phase 1 (L1), S as phase 2 (L2), T as phase 3 (L3).
+
+If known, the Charge Point MAY also report the phase rotation between the grid connection and the main energymeter by using index number Zero (0).
+
+Values are reported in CSL, formatted: 0.RST, 1.RST, 2.RTS
+
+# 9.1.8. ConnectorPhaseRotationMaxLength
+
+Required/optional
+
+optional
+
+Accessibility
+
+R
+
+Type
+
+integer
+
+Description
+
+Maximum number of items in a ConnectorPhaseRotation Configuration Key.
+
+# 9.1.9. GetConfigurationMaxKeys
+
+Required/optional
+
+required
+
+Accessibility
+
+R
+
+Type
+
+integer
+
+Description
+
+Maximum number of requested configuration keys in a GetConfiguration.req PDU.
+
+# 9.1.10. HeartbeatInterval
+
+Required/optional
+
+required
+
+<table><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Unit</td><td>seconds</td></tr><tr><td>Description</td><td>Interval of inactivity (no OCPP exchanges) with central system after which the Charge Point should send a Heartbeat.req PDU</td></tr></table>
+
+# 9.1.11.LightIntensity
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Unit</td><td>%</td></tr><tr><td>Description</td><td>Percentage of maximum intensity at which to illuminate Charge Point lighting</td></tr></table>
+
+# 9.1.12. LocalauthorizeOffline
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>boolean</td></tr><tr><td>Description</td><td>whether the Charge Point, when offline, will start a transaction for locally-authorized identifiers.</td></tr></table>
+
+# 9.1.13. LocalPreauthorize
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>boolean</td></tr><tr><td>Description</td><td>whether the Charge Point, when online, will start a transaction for locally-authorized identifiers without waiting for or requesting an Authorization.conf from the Central System</td></tr></table>
+
+# 9.1.14. MaxEnergyOnInvalidId
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td></td><td></td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Unit</td><td>Wh</td></tr><tr><td>Description</td><td>Maximum energy in Wh delivered when an identifier is invalidated by the Central System after start of a transaction.</td></tr></table>
+
+# 9.1.15. MeterValuesAlignedData
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>CSL</td></tr><tr><td>Description</td><td>Clock-aligned measurand(s) to be included in a MeterValues.req PDU, every ClockAlignedDataInterval seconds</td></tr></table>
+
+# 9.1.16. MeterValuesAlignedDataMaxLength
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>R</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Description</td><td>Maximum number of items in a MeterValuesAlignedData Configuration Key.</td></tr></table>
+
+# 9.1.17. MeterValuesSampledData
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>CSL</td></tr><tr><td>Description</td><td>Sampled measurands to be included in a MeterValues.req PDU, every MeterValueSampleInterval seconds. Where applicable, the Measurand is combined with the optional phase; for instance: Voltage.L1Default: "Energy.Active.Import.Register"</td></tr></table>
+
+# 9.1.18. MeterValuesSampledDataMaxLength
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>R</td></tr></table>
+
+9.1.19. MeterValueSampleInterval
+
+<table><tr><td>Type</td><td>integer</td></tr><tr><td>Description</td><td>Maximum number of items in a MeterValuesSampledData Configuration Key.</td></tr></table>
+
+9.1.20. MinimumStatusDuration
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Unit</td><td>seconds</td></tr><tr><td>Description</td><td>Interval between sampling of metering (or other) data, intended to be transmitted by "MeterValues" PDUs. For charging session data (Connectorld>0), samples are acquired and transmitted periodically at this interval from the start of the charging transaction.A value of "0" (numeric zero), by convention, is to be interpreted to mean that no sampled data should be transmitted.</td></tr></table>
+
+9.1.21.NumberOfConnectors
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Unit</td><td>seconds</td></tr><tr><td>Description</td><td>The minimum duration that a Charge Point or Connector status is stable before a StatusNotification.req PDU is sent to the Central System.</td></tr></table>
+
+9.1.22. ResetRetries
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>R</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Description</td><td>The number of physical charging connectors of this Charge Point.</td></tr></table>
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td></td><td></td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Unit</td><td>times</td></tr><tr><td>Description</td><td>Number of times to retry an unsuccessful reset of the Charge Point.</td></tr></table>
+
+# 9.1.23. StopTransactionOnEVSideDisconnect
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>boolean</td></tr><tr><td>Description</td><td>When set to true, the Charge Point SHALL administratively stop the transaction when the cable is unplugged from the EV.</td></tr></table>
+
+# 9.1.24. StopTransactionOnInvalidId
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>boolean</td></tr><tr><td>Description</td><td>whether the Charge Point will stop an ongoing transaction when it receives a non-Accepted authorization status in a StartTransaction.conf for this transaction</td></tr></table>
+
+# 9.1.25. StopTxnAlignedData
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>CSL</td></tr><tr><td>Description</td><td>Clock-aligned periodic measurand(s) to be included in the TransactionData element of StopTransaction.req MeterValues.req PDU for every ClockAlignedDataInterval of the Transaction</td></tr></table>
+
+# 9.1.26. StopTxnAlignedDataMaxLength
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>R</td></tr></table>
+
+Type integer
+
+Description Maximum number of items in a StopTxnAlignedData Configuration Key.
+
+# 9.1.27. StopTxnSampledData
+
+Required/optional required
+
+Accessibility RW
+
+Type CSL
+
+Description Sampled measurands to be included in the TransactionData element of StopTransaction.req PDU, every MeterValueSampleInterval seconds from the start of the charging session
+
+# 9.1.28. StopTxnSampledDataMaxLength
+
+Required/optional optional
+
+Accessibility R
+
+Type integer
+
+Description Maximum number of items in a StopTxnSampledData Configuration Key.
+
+# 9.1.29. SupportedFeatureProfiles
+
+Required/optional required
+
+Accessibility R
+
+Type CSL
+
+Description A list of supported Feature Profiles. Possible profile identifiers: Core, FirmwareManagement, LocalAuthListManagement, Reservation, SmartCharging and RemoteTrigger.
+
+# 9.1.30. SupportedFeatureProfilesMaxLength
+
+Required/optional optional
+
+Accessibility R
+
+Type integer
+
+Description Maximum number of items in a SupportedFeatureProfiles Configuration Key.
+
+# 9.1.31. TransactionMessageAttempts
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Unit</td><td>times</td></tr><tr><td>Description</td><td>How often the Charge Point should try to submit a transaction-related message when the Central System fails to process it.</td></tr></table>
+
+# 9.1.32. TransactionMessageRetryInterval
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Unit</td><td>seconds</td></tr><tr><td>Description</td><td>How long the Charge Point should wait before resubmitting a transaction-related message that the Central System failed to process.</td></tr></table>
+
+# 9.1.33. UnlockConnectorOnEVSideDisconnect
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>boolean</td></tr><tr><td>Description</td><td>When set to true, the Charge Point SHALL unlock the cable on Charge Point side when the cable is unplugged at the EV.</td></tr></table>
+
+# 9.1.34. WebSocketPingInterval
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Unit</td><td>seconds</td></tr></table>
+
+Description
+
+Only relevant for websocket implementations. 0 disables client side websocket Ping/Pong. In this case there is either no ping/pong or the server initiates the ping and client responds with Pong. Positive values are interpreted as number of seconds between pings. Negative values are not allowed. ChangeConfiguration is expected to return a REJECTED result.
+
+# 9.2. Local Auth List Management Profile
+
+# 9.2.1. LocalAuthListEnabled
+
+Required/optional required
+
+Accessibility RW
+
+Type boolean
+
+Description whether the Local Authorization List is enabled
+
+# 9.2.2. LocalAuthListMaxLength
+
+Required/optional required
+
+Accessibility R
+
+Type integer
+
+Description Maximum number of identifications that can be stored in the Local Authorization List
+
+# 9.2.3.SendLocalListMaxLength
+
+Required/optional required
+
+Accessibility R
+
+Type integer
+
+Description Maximum number of identifications that can be send in a single SendLocalList.req
+
+# 9.3. Reservation Profile
+
+# 9.3.1. ReserveConnectorZeroSupported
+
+Required/optional optional
+
+Accessibility R
+
+Type boolean
+
+# 9.4. Smart Charging Profile
+
+# 9.4.1. ChargeProfileMaxStackLevel
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>R</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Description</td><td>Max StackLevel of a ChargingProfile. The number defined also indicates the max allowed number of installed charging schedules per Charging Profile Purposes.</td></tr></table>
+
+# 9.4.2. ChargingScheduleAllowedChargingRateUnit
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>R</td></tr><tr><td>Type</td><td>CSL</td></tr><tr><td>Description</td><td>A list of supported quantities for use in a ChargingSchedule. Allowed values: 'Current' and 'Power'</td></tr></table>
+
+# 9.4.3. ChargingScheduleMaxPeriods
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>R</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Description</td><td>Maximum number of periods that may be defined per ChargingSchedule.</td></tr></table>
+
+# 9.4.4. ConnectorSwitch3to1PhaseSupported
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>R</td></tr><tr><td>Type</td><td>boolean</td></tr><tr><td>Description</td><td>If defined and true, this Charge Point support switching from 3 to 1 phase during a Transaction.</td></tr></table>
+
+# 9.4.5. MaxChargingProfilesInstalled
+
+<table><tr><td>Required/optional</td><td>required</td></tr><tr><td>Accessibility</td><td>R</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Description</td><td>Maximum number of Charging profiles installed at a time</td></tr></table>
+
+# Appendix A: New in OCPP 1.6
+
+The following changes are made in OCPP 1.6 compared to OCPP 1.5 [OCPP1.5]:
+
+- Smart Charging is added
+- A binding to JSON over WebSocket as a transport protocol is added, reducing data usage and enabling OCPP communication through NAT routers, see: OCPP JSON Specification
+- Extra statuses are added to the ChargePointStatus enumeration, giving the CPO and ultimately end-users more information about the current status of a Charge Point
+- Structure of MeterValues.req is changed to eliminate use of XML Attributes, this is needed for support of JSON (no attribute support in JSON).
+- Extra values are added to the Measurand enumeration, giving Charge Point manufacturers the possibility to send new information to a Central System, such as the State of Charge of an EV
+- The TriggerMessage message is added, giving the Central System the possibility to request information from the Charge Point
+- A new Pending member is added to the RegistrationStatus enumeration used in BootNotification.conf
+- More and clearer configuration keys are added, making it clearer to the CPO how to configure the different business cases in a Charge Point
+- The messages and configuration keys are split into profiles, making it easier to implement OCPP gradually or only in part
+- Known ambiguities are removed (e.g. when to use UnlockConnector.req, how to respond to RemoteStart /Stop, Connector numbering)
+
+# A.1. Updated/New Messages:
+
+- BootNotification.req
+- Change lclld and lmsi to CiString[] to enforce maximum lengths.
+- BootNotification.conf
+- heartbeatInterval to interval, interval now also used for other purposes than heartbeat, need to fix in spec
+- Added status Pending
+- ChargePointErrorCode
+- Added enumvalues: InternalError, LocalListConflict and UnderVoltage
+- Renamed enum value Mode3Error to EVCommunicationError
+- ChargePointStatus
+- Replaced enum value Occupied with the more detailed values: Preparing, Charging, SuspendedEVSE, SuspendedEV and Finishing
+- ChargingRateUnitType
+ New
+
+- ConfigurationStatus
+- Added enum RebootRequired
+- ClearChargingProfile.req
+ New
+- ClearChargingProfile.conf
+ New
+- DiagnosticsStatus
+- Added enum Uploading and Idle
+- FirmwareStatus
+- Added enum Downloading, Installing and Idle
+ GetCompositeSchedule.req
+ New
+- GetCompositeSchedule.conf
+ New
+- Location
+- Added enum Cable and EV
+- Measurand
+- Added enum Current. Offered, Frequency, Power. Factor, Power. Offered, RPM and SoC
+- MeterValuesreq
+- overhaul of complex data structures
+- Added 'phase' field
+- ReadingContext
+- Added enum Trigger and Other
+- RemoteStartTransaction.req
+- Added ChargingProfile optional
+- SendLocalList.req
+- removed hash
+- SendLocalList.conf
+- removed hash
+- SetChargingProfile.req
+ New
+- SetChargingProfile.conf
+ New
+
+- StatusNotification.req
+ Overhaul of states
+- New error codes
+- Connector id 0 can only have status: Available, Unavailable and Faulted.
+
+- StopTransaction.req
+- added explicit and required stop reason
+- TriggerMessage.req
+ New
+- TriggerMessage.conf
+ New
+- UnlockConnector.conf
+- overhaul of UnlockStatus enum
+- UnitOfMeasure
+- Added Fahrenheit, K, Percent, VA, kVA
+- Rename Volt to V, Amp to A
--- /dev/null
+# OCPP
+
+Copyright © 2010 - 2025 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
+
+<table><tr><td>VERSION</td><td>DATE</td><td>DESCRIPTION</td></tr><tr><td>2025-04</td><td>2025-04-30</td><td>Errata sheet release 2025-04.</td></tr><tr><td>v4.1 Draft</td><td>2019-11-15</td><td>Add new errata</td></tr><tr><td>v4.0 Release</td><td>2019-10-23</td><td>4th release of the errata sheet
+New errata are marked with v4.0.</td></tr><tr><td>v3.0 Release</td><td>2017-09-08</td><td>3th release of the errata sheet
+New errata are marked with v3.0.</td></tr><tr><td>v2.0 Release</td><td>2017-03-27</td><td>2nd release of the errata sheet
+Errata have been reordered to match the chronological order of the 1.6 specification.</td></tr><tr><td>v1.0 Release</td><td>2016-03-31</td><td>First release</td></tr></table>
+
+# 1. Scope
+
+This document contains errata on the OCPP 1.6 specification. Any errata added after v3.0 of this errata sheet is an errata on OCPP 1.6 edition 2, and is also applicable for OCPP 1.6 FINAL (the first edition) unless marked otherwise.
+
+# 1.1. Terminology and Conventions
+
+Bold: when needed to clarify differences, bold text might be used.
+
+Since document version v3.0 errata are marked with a version number, indicating when an errata was added.
+
+# 2. Major errata
+
+Problems with the content/definition of the messages, class and enumerations of the protocol.
+
+None known
+
+# 3. Minor errata
+
+Improvements to the descriptions on how the protocol (should) work.
+
+# 3.1. Page 7, section: 2.2: More than IEC 15118 might be taken into account for Smart Charging.
+
+The definition of "Composite Charging Schedule" states that "IEC 15118 limits might be taken into account", but also other limits might be taken into account.
+
+<table><tr><td>Old text</td><td>Also IEC 15118 limits might be taken into account.</td></tr><tr><td>New text</td><td>Local Limits might be taken into account.</td></tr></table>
+
+# 3.2. Page 10, section: 3.3: Feature Profiles should be normative
+
+Added in errata sheet v4.0 The table with messages per feature profiles the columns have been mixed in edition 2.
+
+<table><tr><td>Old text</td><td>New text</td></tr><tr><td>REMOTE TRIGGER</td><td>RESERVATION</td></tr><tr><td>RESERVATION</td><td>SMART CHARGING</td></tr><tr><td>SMART CHARGING</td><td>REMOTE TRIGGER</td></tr></table>
+
+# 3.3. Page 10, section: 3.3: Feature Profiles should be normative
+
+The Feature Profiles paragraph states that it is "informative", but it is "normative".
+
+<table><tr><td>Old text</td><td>This section is informative.</td></tr><tr><td>New text</td><td>This section is normative.</td></tr></table>
+
+# 3.4. Page 13, section: 3.5.1: Missing requirement, cache persists reset
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 16, section 3.4.1
+
+In section 3.4.1 there is a requirement about the persistence of the cache, but it does not mention 'reset'
+
+<table><tr><td>Old text</td><td>Cache values SHOULD be stored in non-volatile memory, and SHOULD be persisted across reboots and power outages.</td></tr><tr><td>New text</td><td>Cache values SHOULD be stored in non-volatile memory, and SHOULD be persisted across reboots , resets and power outages.</td></tr></table>
+
+# 3.5. Page 15, section: 3.5.4: For unlock cable after invalid id in StartTransaction.conf, same identifier should be used.
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 18, section 3.4.4
+
+The text explaining what a Charge Point should do when a StartTransaction.conf is received is not $100\%$ clear that it should be the same identifier, not an identifier of the same owner.
+
+<table><tr><td>Old text</td><td>it SHOULD keep the Charging Cable locked until the owner presents his identifier.</td></tr><tr><td>New text</td><td>it SHOULD keep the Charging Cable locked until the same identifier (or an identifier with the same ParentIdTag) is used to start the transaction (StartTransaction.req) is presented.</td></tr></table>
+
+# 3.6. Page 18, section 3.5: Better description how to determine start/end of Energy Transfer Period
+
+Added in errata sheet v3.0
+
+Description how the Central System can determine start/end of Energy Transfer Period can be improved.
+
+<table><tr><td>Old text</td><td>A Central System MAY deduce the start and end of an Energy Transfer Period from the MeterValues that are sent during the Transaction.</td></tr><tr><td>New text</td><td>A Central System MAY deduce the start and end of an Energy Transfer Period from: the MeterValues that are sent during the Transaction, the status notifications: Charging, SuspendedEV and/or SuspendedEVSE. etc. Central System implementations need to take into account factors such as: Some EVs don't go to state SuspendedEV: they might continue to trickle charge. Some Charge Point don't even have a electrical meter.</td></tr></table>
+
+# 3.7. Page 18, section 3.12.2: Add description of stacking without duration
+
+Added in errata sheet v3.0
+
+When using stacking for Smart Charging: a high stack level without a duration will cause lower profiles to be never executed.
+
+Add note at end of section 3.12.2
+
+<table><tr><td>New text</td><td>NOTE: If you use Stacking without a duration, on the highest stack level, the Charge Point will never fall back to a lower stack level profile."</td></tr></table>
+
+# 3.8. Page 20, section 3.13.1: Effect of updating or deleting TxDefaultProfile during a transaction not defined
+
+Added in errata sheet v4.0
+
+It was not clear that a new TxDefaultProfile not only applies to running transactions with a TxDefaultProfile, but also to running transactions without a ChargingProfile. Furthermore, removing a TxDefaultProfile will cause running transactions to continue without a TxDefaultProfile.
+
+To clarify this best, two additional paragraphs are needed.
+
+<table><tr><td>Page</td><td>Section</td><td>Additional text</td></tr><tr><td>20</td><td>3.13.1</td><td>When an new or updated TxDefaultProfile is received and a transaction is ongoing that is not using a ChargingProfile or using the current TxDefaultProfile, the transaction SHALL continue, but switch to using the new or updated TxDefaultProfile. When TxDefaultProfile is removed, then running transactions, that started with that profile, SHALL continue without a TxDefaultProfile.</td></tr><tr><td>54</td><td>5.16.3</td><td>When the ongoing transaction is not using a ChargingProfile or using the TxDefaultProfile, and a new or updated TxDefaultProfile is received, the transaction SHALL continue, but switch to using the new or updated TxDefaultProfile.</td></tr></table>
+
+# 3.9. Page 29, section: 3.1.6: Missing advice to send meter register value if available
+
+Added in errata sheet v4.0
+
+When a Charge Point has a meter which allows the value of Meter Register (counter) to be read. It is seen as best to send this value instead of start every transaction at 0.
+
+<table><tr><td>Additional text</td><td>If a Charge Point contains a Meter that has a register that can be read (instead of counting pulses or some other way of measuring the amount of energy etc.) It is RECOMMENDED to send this register value in every MeterValue send instead of starting at 0 for every transaction.</td></tr></table>
+
+# 3.10. Page 33, new Chapter about time notations
+
+In addition to "3.13 Time Zones" to following should have been added about time notations:
+
+<table><tr><td>New text</td><td>3.14 Time notations
+Implementations MUST use ISO 8601 date time notation. Message receivers must be able to handle fractional seconds and time zone offsets (another implementation might use them). Message senders MAY save data usage by omitting insignificant fractions of seconds.</td></tr></table>
+
+# 3.11. Page 35, section: 4.2: Boot Notification: Note on behaviour while not accepted by Central system
+
+<table><tr><td>Old text</td><td>While not yet accepted by the Central System, the Charge Point may allow locally authorized transactions if it is configured to do so, as described in Local Authorization & Offline Behaviour. Parties who want to implement this behaviour must realize that it is uncertain if those transactions can ever be delivered to the Central System.</td></tr><tr><td>New text</td><td>A Charge Point Operator MAY choose to configure a Charge Point to accept transactions before the Charge Point is accepted by a Central System. Parties who want to choose to implement this behavior should realize that it is uncertain if those transactions can ever be delivered to the Central System.
+After a restart (for instance due to a remote reset command, power outage, firmware update, software error etc.) the Charge Point MUST again contact the Central System and SHALL send a BootNotification request. If the Charge Point fails to receive a BootNotification.conf from the Central System, and has no in-built non-volatile real-time clock hardware that has been correctly preset, the Charge Point may not have a valid date / time setting, making it impossible to later determine the date / time of transactions.
+It might also be the case (e.g. due to configuration error) that the Central System indicates a status other than Accepted for an extended period of time, or indefinitely.
+It is usually advisable to deny all charging services at a Charge Point if the Charge Point has never before been Accepted by the Central System (using the current connection settings, URL, etc.) since users cannot be authenticated and running transactions could conflict with provisioning processes.</td></tr></table>
+
+# 3.12. Page 37, section: 4.5: Relation between FirmwareStatusNotification.req and FirmwareUpdate.req is missing.
+
+There is no description about the relation between FirmwareUpdate.req and FirmwareStatusNotification.req in the specification.
+
+<table><tr><td>Additional text</td><td>The FirmwareStatusNotification.req PDUs SHALL be sent to keep the Central System updated with the status of the update process, started by the Central System with a FirmwareUpdate.req PDU.</td></tr></table>
+
+# 3.13. Page 38, section: 4.7: Missing description of configuration keys for MeterValues
+
+There are a couple of required configuration keys that have a huge influence of how MeterValues work. But there is no reference or description for them in 4.7 Meter Values:
+
+ClockAlignedDataInterval
+
+- MeterValuesAlignedData
+- MeterValuesAlignedDataMaxLength
+- MeterValuesSampledData
+- MeterValuesSampledDataMaxLength
+- MeterValueSampleInterval
+- StopTxnAlignedData
+- StopTxnAlignedDataMaxLength
+- StopTxnSampledData
+- StopTxnSampledDataMaxLength
+
+# New Chapter to be added to the specification:
+
+# 3.14: Metering Data
+
+This section is normative.
+
+Extensive metering data relating to charging sessions can be recorded and transmitted in different ways depending on its intended purpose. There are two obvious use cases (but the use of meter values is not limited to these two):
+
+- Charging Session Meter Values
+- Clock-Aligned Meter Values
+
+Both types of meter readings MAY be reported in standalone MeterValues.req messages (during a transaction) and/or as part of the transactionData element of the StopTransaction.req PDU.
+
+# 3.14.1 Charging Session Meter Values
+
+Frequent (e.g. 1-5 minute interval) meter readings taken and transmitted (usually in "real time") to the Central System, to allow it to provide information updates to the EV user (who is usually not at the charge point), via web, app, SMS, etc., as to the progress of the charging session. In OCPP, this is called "sampled meter data", as the exact frequency and time of readings is not very significant, as long as it is "frequent enough". "Sampled meter data" can be configured with the following configuration keys:
+
+- MeterValuesSampledData
+- MeterValuesSampledDataMaxLength
+- MeterValueSampleInterval
+- StopTxnSampledData
+- StopTxnSampledDataMaxLength
+
+MeterValueSampleInterval is the time (in seconds) between sampling of metering (or other) data, intended to be transmitted by "MeterValues" PDUs. Samples are acquired and transmitted periodically at this interval from the start of the charging transaction.
+
+A value of "0" (numeric zero), by convention, is to be interpreted to mean that no sampled data should be transmitted.
+
+MeterValuesSampledData is a comma separated list that prescribes the set of measurands to be included in a MeterValues.req PDU, every MeterValueSampleInterval seconds. The maximum amount of elements in the MeterValuesSampledData list can be reported by the Charge Point via: MeterValuesSampledDataMaxLength
+
+StopTxnSampledData is a comma separated list that prescribes the sampled measurands to be included in the TransactionData element of StopTransaction.req PDU, every MeterValueSampleInterval seconds from the start of the charging session. The maximum amount of elements in the StopTxnSampledData list can be reported by the Charge Point via: StopTxnSampledDataMaxLength
+
+# 3.14.2 Clock-Aligned Meter Values
+
+Grid Operator might require meter readings to be taken from fiscally certified energy meters, at specific Clock aligned times (usually every quarter hour, or half hour).
+
+"Clock-Aligned Billing Data" can be configured with the following configuration keys:
+
+- ClockAlignedDataInterval
+- MeterValuesAlignedData
+- MeterValuesAlignedDataMaxLength
+- StopTxnAlignedData
+- StopTxnAlignedDataMaxLength
+
+ClockAlignedDataInterval is the size of the clock-aligned data interval (in seconds). This defines the set of evenly spaced meter data 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.
+
+A value of "0" (numeric zero), by convention, is to be interpreted to mean that no clock-aligned data should be transmitted.
+
+MeterValuesAlignedData is a comma separated list that prescribes the set of measurands to be included in a MeterValues.req PDU, every ClockAlignedDataInterval seconds. The maximum amount of elements in the MeterValuesAlignedData list can be reported by the Charge Point via: MeterValuesAlignedDataMaxLength
+
+StopTxnAlignedData is a comma separated list that prescribes the set of clock-aligned periodic measurands to be included in the TransactionData element of StopTransaction.req PDU for every ClockAlignedDataInterval of the charging session. The maximum amount of elements in the StopTxnAlignedData list can be reported by the Charge Point via: StopTxnAlignedDataMaxLength
+
+# 3.14.3 Multiple Locations/Phases
+
+When a Charge Point 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 keys.
+
+For example: A Charge Point capable of measuring Current.Import on Inlet (all 3 phases) (grid connection) and
+
+Outlet (3 phases per connector on both its connectors). Current.Import is set in MeterValuesSampledData. MeterValueSampleInterval is set to 300 (seconds). Then the Charge Point should send:
+
+- a MeterValue.req with: connectorld = 0; with 3 SampledValue elements, one per phase with location = Inlet.
+- a MeterValue.req with: connectorld = 1; with 3 SampledValue elements, one per phase with location = Outlet.
+- a MeterValue.req with: connectorld = 2; with 3 SampledValue elements, one per phase with location = Outlet.
+
+# 3.14.4Unsupported measurands
+
+When a Central System sends a ChangeConfiguration.req to a Charge Point with one of the following configuration keys:
+
+- MeterValuesAlignedData
+- MeterValuesSampledData
+- StopTxnAlignedData
+- StopTxnSampledData
+
+If the comma separated list contains one or more measurands that are not supported by this Charge Point, the Charge Point SHALL respond with: ChangeConfiguration.conf with: status = Rejected. No changes SHALL be made to the currently configuration.
+
+Added in errata sheet v3.0
+
+# 3.14.5 No metering data in a Stop Transaction
+
+When the configuration keys: StopTxnAlignedData and StopTxnSampledData are set to an empty string, the Charge Point SHALL NOT put meter values in a StopTransaction.req PDU.
+
+# 3.14. Page 31, section: 3.16.5: Missing description of Start and Stop MeterValues in StopTransaction.req
+
+Added in errata sheet v4.0
+
+Additional Section should have been added to 3.16:
+
+# 3.16.6 Start and Stop MeterValues in StopTransaction.req
+
+When the Charge Point is configured to provide metering data in the StopTransaction.req, the Charge Point is RECOMMENDED to always provide the start (Transaction.Begin) and stop (Transaction.End) values of every measurand configured.
+
+If the Charge Point has to drop meter values because it is running out of memory, it is RECOMMENDED not to drop the start and stop values.
+
+# 3.15. Page 36, section: 4.7: make it more explicit that MeterValues are required if they are configured
+
+Added in errata sheet v4.0
+
+The first paragraph of section 4.7 reads:
+
+"A Charge Point MAY sample the electrical meter or other sensor/transducer hardware to provide extra information about its meter values. It is up to the Charge Point to decide when it will send meter values. This can be configured using the ChangeConfiguration.req message to data acquisition intervals and specify data to be acquired & reported."
+
+The keyword "MAY" in this text suggests that it is optional to send MeterValues. However, when the value of the configuration variable MeterValueSampleInterval has been set to a value greater than zero, then it is mandatory to send MeterValues.
+
+Additional text After first section
+
+When the value of the configuration variable MeterValueSampleInterval and/or ClockAlignedDataInterval has been set to a value greater than zero, the Charge Point SHALL send MeterValues at the given interval(s).
+
+# 3.16. Page 36, section: 4.7: Not $100\%$ clear which transaction ID to use in a MeterValue (multiple transactions during interval)
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 38
+
+It was not $100\%$ clear which transactionId to put a MeterValue.req message for a Clock-Aligned meter value sample when during the last period between samples, the previous transaction has ended and a new transaction has started.
+
+Additional text Bullet 2
+
+The transactionId is always the ID of the Transaction that is ongoing (on that connector) at the moment the meter value sample is taken. When the TransactionId is set, only MeterValues related to that transaction can be reported. If the values are taken from the main energy meter, it is advised NOT to add a transactionId.
+
+When reporting Meter Values for connectorld 0 (the main energy meter) it is RECOMMENDED NOT to add a TransactionId.
+
+# 3.17. Page 37, section: 4.8: Unclear how to handle: StartTransaction.conf with idTagInfo not Accepted.
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 40
+
+It is not (clearly) defined what a Charge Point should do when it receives a StartTransaction.conf with authorization status other than Accepted, when it is online.
+
+There is already text that describes what a Charge Point should do, but this text is now in the part explaining what to do when the Charge Point is offline. But because it is in that part, it is not clear that it is also they way a Charge Point should handle the same situation when it is online.
+
+The following text should be moved from: Page 15, section: 3.5.4 (OCPP 1.6 FINAL Page 18, section 3.4.4) to: Page 37, section 4.8 (OCPP 1.6 FINAL Page 40)
+
+"When the authorization status in the StartTransaction.conf is not Accepted, and the transaction is still ongoing, the Charge Point SHOULD:
+
+- when StopTransactionOnInvalidld is set to true: stop the transaction normally as stated in Stop Transaction. The Reason field in the Stop Transaction request should be set to DeAuthorized. If the Charge Point has the possibility to lock the Charging Cable, it SHOULD keep the Charging Cable locked until the owner presents his identifier.
+- when StopTransactionOnInvalidld is set to false: only stop energy delivery to the vehicle.
+
+Note: In the case of an invalid identifier, an operator MAY choose to charge the EV with a minimum amount of energy so the EV is able to drive away. This amount is controlled by the optional configuration key: MaxEnergyOnInvalidId."
+
+# 3.18. Page 37, section: 4.8: How to deliver Transaction related messages when no transactionId is known.
+
+Added in errata sheet v4.0
+
+This section mentions at the end, that failing to respond with a StartTransaction.conf will cause the Charge Point to retry several times. However, it is not specified how to deal with Transaction related messages for which no transactionId is known, when this happens.
+
+At the end of section 4.8 add the following text:
+
+<table><tr><td>Additional text</td><td>If the Charge Point was unable to deliver the StartTransaction.req despite repeated attempts, or if the Central System was unable to deliver the StartTransaction.conf response, then the Charge Point will not receive a transactionId.
+In that case, the Charge Point SHALL send any Transaction related messages for this transaction to the Central System with a transactionId = -1. The Central System SHALL respond as if these messages refer to a valid transactionId, so that the Charge Point is not blocked by this.</td></tr></table>
+
+# 3.19. Page 38, section: 4.9: Not defined that StatusNotification should always be send.
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 40
+
+The specification on page 38 states: "The following table depicts changes from a previous status (left column) to a new status (upper row) upon which a Charge Point MAY send a StatusNotification.req PDU to the Central System."
+
+But the idea has always been that the Charge Point has to send a StatusNotification when the state changes.
+
+<table><tr><td>Old text</td><td>a Charge Point MAY send a StatusNotification.req PDU to the Central System.</td></tr><tr><td>New text</td><td>a Charge Point SHALL send a StatusNotification.req PDU to the Central System, taking into account some minimum status duration.</td></tr></table>
+
+# 3.20. Page 41, section: 4.9: Status transition from Preparing to Finishing (B6) is possible
+
+Added in errata sheet v3.0
+
+The original 1.6 does not allow a transition from Preparing to Finishing (B6). But there is a use case where this is possible:
+
+A Charge Point with 2 connectors and 1 RFID reader. Driver 1 connects his charging cable. State goes to "Preparing" User does not authorize, times out. Then the Charge Point has to go to state: "Finishing". It should NOT go to "Available". Because if the charging cable remains plugged in and another EV driver swipes his RFID (before plugging in), that would start a transaction on the already plugged in cable. By going to "Finishing" this is prevented.
+
+<table><tr><td>Table top page 41</td><td>Add B6</td></tr><tr><td>Table on page 42</td><td>B6: Timed out. Usage was initiated (e.g. insert plug, bay occupancy detection), but idTag not presented within timeout.</td></tr></table>
+
+# 3.21. Page 42, section: 4.9 (B1): Missing reference to configuration key: "ConnectionTimeOut"
+
+The configuration key: "ConnectionTimeOut" is never referenced in the specification, section: 4.9 needs a note explaining how the state: "Preparing" and the configuration key: "ConnectionTimeOut" work together.
+
+<table><tr><td>Old text</td><td>Intended usage is ended (e.g. plug removed, bay no longer occupied, second presentation of idTag, time out on expected user action)</td></tr><tr><td>New text</td><td>Intended usage is ended (e.g. plug removed, bay no longer occupied, second presentation of idTag, time out (configured by the configuration key: ConnectionTimeOut) on expected user action)</td></tr></table>
+
+# 3.22. Page 43, section: 4.9: Not defined that StatusBar should always be send after BootNotification accepted.
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 45
+
+There is no description of behaviour that is expected and is implemented by every known implementation of OCPP: After being accepted via BootNotification.conf(Accepted) the Charge Point has to report its current status.
+
+<table><tr><td>Additional text</td><td>After the Central System accept a Charge Point by sending a BootNotification.conf with a status Accepted, the Charge Point SHALL send a StatusNotification.req PDU for connectorId 0 and all connectors with the current status.</td></tr></table>
+
+# 3.23. Page 46, section: 5.4. Clear Cache when Cache is not implemented not defined.
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 49
+
+In OCPP 1.6, the Cache is not required, but the message: ClearCache.req is required to be implemented. OCPP does not define what the expected behaviour is.
+
+Additional text
+
+When the Authorization Cache is not implemented and the Charge Point receives a ClearCache.req message. The Charge Point SHALL response with ClearCache.conf with the status: Rejected.
+
+# 3.24. Page 46, section 5.8: Missing requirement about chargingRateUnit in GetCompositeSchedule
+
+Added in errata sheet v4.0
+
+The following note must be added at the end of this section:
+
+
+
+If an invalid value is used for chargingRateUnit in GetCompositeSchedule.req, e.g. when using a value for chargingRateUnit that is not 'A' or 'W', then Charge Point SHALL respond with RPC Framework CALLERROR: PropertyConstraintViolation (JSON) or SOAP Fault: Sender, ProtocolError (SOAP).
+
+# 3.25. Page 47, section 5.5: Unclear how to match fields in a ClearChargingProfile request
+
+Added in errata sheet v4.0
+
+The following note must be added at the end of this section:
+
+
+
+If no fields are specified in the ClearChargingProfile.req message, then Charge Point SHALL clear all ChargingProfiles. If one or more fields are specified in the ClearChargingProfile.req message, then Charge Point SHALL clear all ChargingProfiles that match (logical AND) all of the provided fields.
+
+# 3.26. Page 63, section 6.13: Unclear how to match fields in a ClearChargingProfile request
+
+Added in errata sheet v4.0
+
+The following sentence in the description of ClearChargingProfile.req must be replaced with new text:
+
+Old text
+
+The Central System can use this message to clear (remove) either a specific charging profile (denoted by id) or a selection of charging profiles that match with the values of the optional connectorId, stackLevel and chargingProfilePurpose fields.
+
+<table><tr><td>New text</td><td>The Central System can use this message to clear (remove) either a specific charging profile (denoted by id) or a selection of charging profiles that match (logical AND) with the values of the optional connectorId, stackLevel and chargingProfilePurpose fields.
+If no fields are provided, then all charging profiles will be cleared.
+If id is specified, then all other fields are ignored.</td></tr></table>
+
+# 3.27. Page 50, section: 5.7: More than IEC 15118 might be taken into account for Smart Charging.
+
+It is stated that "IEC 15118 limits might be taken into account", but also other limits might be taken into account.
+
+<table><tr><td>Old text</td><td>Also IEC 15118 limits might be taken into account.</td></tr><tr><td>New text</td><td>Local Limits might be taken into account.</td></tr></table>
+
+# 3.28. Page 51, section: 5.7: Get Composite Schedule: First sentences is not clear
+
+In the description of Get Composite Schedule, it is not clear, what are the start and end points in time of the schedule that is to be sent.
+
+<table><tr><td>Old text</td><td>Upon receipt of a GetCompositeSchedule.req, the Charge Point SHALL calculate the scheduled time intervals up to the Duration is met and send them to the central system.</td></tr><tr><td>New text</td><td>Upon receipt of a GetCompositeSchedule.req, the Charge Point SHALL calculate the Composite Charging Schedule intervals, from the moment the request PDU is received: Time X, up to X + Duration, and send them in the GetCompositeSchedule.conf PDU to the central system.</td></tr></table>
+
+# 3.29. Page 51, section: 5.7: Get Composite Schedule: First sentences is not clear
+
+Added in errata sheet v4.0
+
+The description of Get Composite Schedule, can be clarified a bit more.
+
+<table><tr><td>Old text</td><td>Upon receipt of a GetCompositeSchedule.req, the Charge Point SHALL calculate the Composite Charging Schedule intervals, from the moment the request PDU is received: Time X, up to X + Duration, and send them in the GetCompositeSchedule.conf PDU to the central system.</td></tr><tr><td>New text</td><td>Upon receipt of a GetCompositeSchedule.req, the Charge Point SHALL calculate the scheduled time intervals from the moment of message receipt up to the Duration (in seconds) and send them to the central system.</td></tr></table>
+
+# 3.30. Page 51, section: 5.7: Improve use of connectorld '0' in GetCompositeSchedule
+
+In the description of the use of connectorld '0' in GetCompositeSchedule it is not clear that it can also mean the Charge Point reports current instead of power.
+
+<table><tr><td>Old text</td><td>If the ConnectorId in the request is set to '0', the Charge Point SHALL report the total expected energy flow of the Charge Point for the requested time period.</td></tr><tr><td>New text</td><td>If the ConnectorId in the request is set to '0', the Charge Point SHALL report the total expected power or current the Charge Point expects to consume from the grid during the requested time period.</td></tr></table>
+
+# 3.31. Page 51, section: 5.9: Relation between GetDiagnostics.req and DiagnosticsStatusNotification.req is missing.
+
+There is no description about the relation between GetDiagnostics.req and DiagnosticsStatusNotification.req in the specification.
+
+The following diagram should replace the diagram in 5.9.
+
+
+Figure 1. Sequence Diagram: get diagnostics
+
+<table><tr><td>Additional text</td><td>During uploading of a diagnostics file, the Charge Point MUST send DiagnosticsStatusNotification.req PDUs to keep the Central System updated with the status of the upload process.</td></tr></table>
+
+# 3.32. Page 52, section: 5.11. Remote Start Transaction: .conf status is accepted request
+
+<table><tr><td>Old text</td><td>Central System can request a Charge Point to start a transaction by sending a RemoteStartTransaction.req. Upon receipt, the Charge Point SHALL reply with RemoteStartTransaction.conf and a status indicating whether it is able to start a transaction or not.</td></tr><tr><td>New text</td><td>Central System can request a Charge Point to start a transaction by sending a RemoteStartTransaction.req. Upon receipt, the Charge Point SHALL reply with RemoteStartTransaction.conf and a status indicating whether it has accepted the request and will attempt to start a transaction.</td></tr></table>
+
+# 3.33. page 54, section: 5.12. Remote Stop Transaction:.conf status is accepted request
+
+<table><tr><td>Old text</td><td>RemoteStopTransaction.req to Charge Point with the identifier of the transaction. Charge Point SHALL reply with RemoteStopTransaction.conf to indicate whether it is indeed able to stop the transaction.</td></tr><tr><td>New text</td><td>RemoteStopTransaction.req to Charge Point with the identifier of the transaction. Charge Point SHALL reply with RemoteStopTransaction.conf and a status indicating whether it has accepted the request and a transaction with the given transactionId is ongoing and will be stopped.</td></tr></table>
+
+# 3.34. page 54, section: 5.16. Not defined how a Charge Point should process a Charging Profile with more phases then being used.
+
+Added in errata sheet v4.0
+
+<table><tr><td>Additional Text</td><td>When the Charge Point receives a Charging Profile with 'numberPhases' higher then the currently used amount of phases or maximum amount of phases this Charge Point can use, The Charge Point SHALL use the 'limit' as is given, for the amount of phases that are/can be used for charging. The Charge Point SHALL NOT calculate a new 'limit' based on the amount of phases possible and given in the 'numberPhases' field.</td></tr></table>
+
+# 3.35. page 55, section: 5.17. TriggerMessage(BootNotification) after being accepted may be rejected
+
+Added in errata sheet v4.0
+
+The following scenario is not defined in OCPP 1.6: "When the Charge Point is accepted by the Central System and the Central System sends a TriggerMessage for requesting a BootNotification. The Charge Point will accept this TriggerMessage and sends a BootNotification.req to the Central System. What should be the behavior of the Charge Point when the Central System is responding with the status Pending or Rejected?"
+
+As this can cause a lot of confusing situations, what to do with ongoing transaction etc. It is allowed to reject such a TriggerMessage.req.
+
+<table><tr><td>Additional text</td><td>After the Charge Point has received a BootNotification.conf(Accepted), until the next reset/reboot/reconnect, the Charge Point is RECOMMENDED to Reject a TriggerMessage request for BootNotification.</td></tr></table>
+
+# 3.36. Page 56, section: 5.14: Improved description of Soft/Hard Reset
+
+Added in errata sheet v3.0
+
+The descriptions of Soft/Hard reset can be improved, not very clear what is the difference between the two.
+
+<table><tr><td>Additional text, between par 1 & 2</td><td>After receipt of a Reset.req, The Charge Point SHALL send a StopTransaction.req for any ongoing transaction before performing the reset. If the Charge Point fails to receive a StopTransaction.conf from the Central System, it SHALL queue the StopTransaction.req.</td></tr></table>
+
+<table><tr><td>Old text</td><td>At receipt of a soft reset, the Charge Point SHALL return to a state that behaves as just having been booted. If any transaction is in progress it SHALL be terminated normally, before the reset, as in Stop Transaction.</td></tr><tr><td>New text</td><td>At receipt of a soft reset request, the Charge Point SHALL stop ongoing transactions gracefully and send StopTransaction.req for every ongoing transaction. It should then restart the application software (if possible, otherwise restart the processor/controller).</td></tr><tr><td colspan="2"></td></tr><tr><td>Old text</td><td>At receipt of a hard reset the Charge Point SHALL attempt to terminate any transaction in progress normally as in StopTransaction and then perform a reboot.</td></tr><tr><td colspan="2"></td></tr><tr><td>New text</td><td>At receipt of a hard reset request, the Charge Point SHALL restart (all) the hardware, it is not required to gracefully stop ongoing transaction. If possible the Charge Point sends a StopTransaction.req for previously ongoing transactions after having restarted and having been accepted by the Central System via a BootNotification.conf. This is a last resort solution for a not correctly functioning Charge Point, by sending a "hard" reset, (queued) information might get lost.</td></tr></table>
+
+# 3.37. Page 53, section: 5.16: Unclear ChargingProfiles should persist reboots
+
+Added in errata sheet v4.0
+
+There is no text that explain that it is expected of a Charge Point to store ChargingProfiles in persistent memory.
+
+<table><tr><td>Additional text</td><td>ChargingProfiles set via SetChargingProfile.req SHALL be persistent across reboots/power cycles.</td></tr></table>
+
+# 3.38. Page 55, section 5.16: Missing requirement about ChargingSchedule's ChargingRateUnit
+
+Added in errata sheet v4.0
+
+The following note must be added at the end of this section:
+
+
+
+If an invalid value is used for an enumeration in ChargingProfile or ChargingSchedule, e.g. when using a value for chargingRateUnit that is not 'A' or 'W', then Charge Point SHALL respond with RPC Framework CALLERROR: PropertyConstraintViolation (JSON) or SOAP Fault: Sender, ProtocolError (SOAP).
+
+# 3.39. Page 55, section: 5.16: SetChargingProfile may be rejected
+
+Added in errata sheet v4.0
+
+The following notes must be added at the end of this section:
+
+
+
+If an invalid value for connectorld is used in SetChargingProfile.req, then the Charge Point SHALL respond with RPC Framework CALLERROR: PropertyConstraintViolation (JSON) or SOAP Fault: Sender, ProtocolError (SOAP).
+
+
+
+If the Charge Point does not support smart charging, then it SHALL respond with RPC Framework CALLERROR: NotSupported (JSON) or SOAP Fault: Receiver, NotSupported (SOAP).
+
+# 3.40. Page 56, section: 5.18: TriggerMessage(BootNotification) not allowed after BootNotificationResponse(Accepted)
+
+Added in errata sheet v4.0
+
+Add the following note at the end of this section:
+
+
+
+Once a CSMS has sent a BootNotification.conf message with status registrationStatus = Accepted to the Charge Point, then CSMS SHALL not send a TriggerMessage to request for a new BootNotification until the Charge Point sends a BootNotification.req message.
+
+# 3.41. Page 58, section: 5.16.2: RemoteStart with ChargingProfile: TransactionId should not be set
+
+It is not clear that in a remoteStartTransaction.req with ChargingProfile, the transactionId should not be set.
+
+<table><tr><td>Old text</td><td>If the Central System includes a ChargingProfile, the ChargingProfilePurpose MUST be set to TxProfile.</td></tr><tr><td>New text</td><td>If the Central System includes a ChargingProfile, the ChargingProfilePurpose MUST be set to TxProfile and the transactionId SHALL NOT be set.</td></tr></table>
+
+# 3.42. Page 58, section: 5.16.2: Meaning of note on RemoteStart with ChargingProfile is not clear
+
+In the description of RemoteStartTransaction with a ChargingProfile there is a note, but the meaning of the note is not clear.
+
+<table><tr><td>Old text</td><td>The Charge Point SHOULD add the TransactionId to the received profile once the transaction is reported to the central system.</td></tr><tr><td>New text</td><td>The Charge Point SHALL apply the given profile to the newly started transaction. This transaction will get a transactionId assigned by Central System via a startTransaction.conf.
+When the Charge Point receives a setChargingProfile.req, with the transactionId for this transaction, with the same StackLevel as the profile given in the remoteStartTransaction.req, the Charge Point SHALL replace the existing charging profile, otherwise it SHALL install/stack the profile next to the already existing profile(s).</td></tr></table>
+
+# 3.43. Page 58, Section 5.16.4: Smart Charging fall back to default unclear
+
+Added in errata sheet v3.0
+
+<table><tr><td>Old text</td><td>When concurrencyKind is used in combination with a chargingSchedule duration shorter than the concurrencyKind period, the Charge Point SHALL fall back to default behavior after the chargingSchedule duration ends.</td></tr><tr><td>New text</td><td>When concurrencyKind is used in combination with a chargingSchedule duration shorter than the concurrencyKind period, the Charge Point SHALL fall back to default behavior after the chargingSchedule duration ends. This fall back means that the Charge Point SHALL use a ChargingProfile with a lower stackLevel if available. If no other ChargingProfile is available, the Charge Point SHALL allow charging as if no ChargingProfile is installed. If the chargingSchedulePeriod and/or duration is longer than the concurrencyKind period, the remainder periods SHALL NOT be executed.</td></tr></table>
+
+# 3.44. Page 58, Section 5.16.4: Not defined what to do with a charging schedule period longer then recurrence.
+
+Added in errata sheet v3.0
+
+It is not defined what to do with a chargingSchedulePeriod and/or duration that is longer than the recurrence period.
+
+Add the following note after the NOTE about "chargingSchedulePeriod longer than duration"
+
+<table><tr><td>New text</td><td>NOTE: When concurrencyKind is used in combination with a chargingSchedulePeriod and/or duration that is longer than the recurrence period duration, the remainder periods SHALL NOT be executed.</td></tr></table>
+
+# 3.45. Page 58, Section 5.16.4: First ChargingSchedulePeriod should start with StartSchedule = 0
+
+Added in errata sheet v3.0
+
+The obvious is not defined: The first ChargingSchedulePeriod StartSchedule in a ChargingSchedule should be 0.
+
+Add the following note after the NOTE about "chargingSchedulePeriod longer than duration"
+
+<table><tr><td>New text</td><td>NOTE: The startPeriod of the first ChargingSchedulePeriod in a ChargingSchedule SHALL always be 0.</td></tr></table>
+
+# 3.46. Page 60, section: 5.17: Description TriggerMessage for MeterValues not clear
+
+The description of what a Charge Point should do when it receives a TriggerMessage.req PDU with requestedMessage: MeterValues, is not clear.
+
+<table><tr><td>Old text</td><td>A MeterValues message triggered in this way for instance SHOULD return the most recent measurements for all measurands configured in configuration key MeterValuesSampledData.</td></tr><tr><td>New text</td><td>A MeterValues message triggered in this way for instance SHALL return the most recent measurements for all measurands configured in configuration key MeterValuesSampledData.</td></tr></table>
+
+# 3.47. Page 61, section: 5.19: Relation between FirmwareUpdate.req and FirmwareStatusNotification.req is missing.
+
+There is no description about the relation between FirmwareUpdate.req and FirmwareStatusNotification.req in the specification. In paragraph 3.3 on page 15, there is a more elaborate diagram of firmware update, including the relationship between UpdateFirmware.req and FirmwareStatusNotification.req, but that paragraph is informative.
+
+The following diagram should replace the diagram in 5.19.
+
+
+Figure 2. Sequence Diagram: firmware update
+
+<table><tr><td>Additional text</td><td>During downloading and installation of the firmware, the Charge Point MUST send FirmwareStatusNotification.req PDUs to keep the Central System updated with the status of the update process.
+The sequence diagram above is an example. It is good practice to first reboot the Charge Point to check the new firmware is booting and able to connect to the Central System, before sending the status: Installed. It is not a requirement.</td></tr></table>
+
+# 3.48. Page 61, section: 5.19: No description new firmware should be installed.
+
+There is no requirement on the installation of new firmware.
+
+<table><tr><td>Additional text</td><td>The Charge Point SHALL, if the new firmware image is "valid", install the new firmware as soon as it is able to.</td></tr></table>
+
+# 3.49. page 61, section: 5.19. Firmware installation during charging session
+
+It is advised to not stop charging session to install new firmware, but wait until session has ended.
+
+<table><tr><td>Additional text</td><td>If it is not possible to continue charging during installation of firmware, it is RECOMMENDED to wait until Charging Session has ended (Charge Point idle) before commencing installation. It is RECOMMENDED to set connectors that are not in use to UNAVAILABLE while the Charge Point waits for the Session to end.</td></tr></table>
+
+This errata note is also applicable for OCPP versions 1.2 and 1.5.
+
+# 3.50. Page 66, section: 6.25: Description of retries incorrect
+
+Added in errata sheet v4.0
+
+In the description of the field retries the word "try" should be "retry".
+
+<table><tr><td>Old text</td><td>Optional. This specifies how many times Charge Point must try to upload the diagnostics before giving up. If this field is not present, it is left to Charge Point to decide how many times it wants to retry.</td></tr><tr><td>New text</td><td>Optional. This specifies how many times Charge Point must retry to upload the diagnostics before giving up. If this field is not present, it is left to Charge Point to decide how many times it wants to retry.</td></tr></table>
+
+# 3.51. Page 70, section: 6.22: Unclear when to use the fields: scheduleStart and chargingSchedule in GetCompositeSchedule.conf.
+
+The message: GetCompositeSchedule.conf contains 3 optional fields, for two of these fields: "scheduleStart" and "chargingSchedule" it is not clear when they should or should not be used:
+
+<table><tr><td>Add to the description the field: scheduleStart</td><td>If status is "Rejected", this field may be absent.</td></tr><tr><td>Add to the description the field: chargingSchedule</td><td>If status is "Rejected", this field may be absent.</td></tr></table>
+
+# 3.52. Page 70, section: 6.41: SendLocalList list version should never be 0
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 77
+
+In GetLocalListVersion.conf listVersion = 0 and -1 have a special meaning, so they should not be used in SetLocalList.req
+
+<table><tr><td>Old text</td><td>Required. In case of a full update this is the version number of the full list. In case of a differential update it is the version number of the list after the update has been applied.</td></tr><tr><td>New text</td><td>Required. In case of a full update this is the version number of the full list. In case of a differential update it is the version number of the list after the update has been applied. SHALL NOT be -1 or 0 as these have a special meaning in GetLocalListVersion.conf</td></tr></table>
+
+# 3.53. Page 70, section: 6.43: Description connectorId = 0 in SetChargingProfile.req causes confusion
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 78
+
+The description of the connectorld in the SetChargingProfile.req does not take into account that it can also be used for setting a TxDefaultProfile. It seems to only take into account a ChargePointMaxProfile.
+
+<table><tr><td>Old text</td><td>If connectorId = 0, the message contains an overall limit for the Charge Point.</td></tr><tr><td>New text</td><td>If connectorId = 0, and the message contains a ChargePointMaxProfile it contains an overall limit for the Charge Point. If connectorId = 0, and the message contains a TxDefaultProfile it contains limits that are to be used for any new transaction on any connector of that Charge Point.</td></tr></table>
+
+# 3.54. Page 71, section: 6.46: Useful values for Transaction ID not clear
+
+Added in errata sheet v4.0
+
+It is not clear to some that the expected value for Transaction IDs are unique positive integers.
+
+<table><tr><td>Old description</td><td>Required. This contains the transaction id supplied by the Central System.</td></tr><tr><td>New description</td><td>Required. This contains the transaction id supplied by the Central System.
+It is RECOMMENDED to use unique positive numbers for transactionIds. Negative numbers and zero (0) are possible, but don't have any special meaning to the Charge Point (they don't mean the transaction is rejected or something like that.) Note that the Charge Point might use transactionId = -1 in transaction related message when the Charge Point was not able to successfully deliver the StartTransaction.req.</td></tr></table>
+
+# 3.55. Page 77, section: 7.7: Definition of SuspendedEV is too confusing
+
+Added in errata sheet v4.0
+
+The new text for SuspendedEV is too confusing. The way it is written now implies that, even if the EVSE is in charging state (C2 with contactor closed) and the EV is not consuming any power that the state should be SuspendedEV.
+
+<table><tr><td>SuspendedEV</td><td>Old text</td><td>When the EV is connected to the EVSE and the EVSE is offering energy but the EV is not taking any energy. (Operative)</td></tr><tr><td>SuspendedEV</td><td>New text</td><td>When the EV is connected to the EVSE and the EVSE is willing and ready to offer energy, but EV is not asking or taking energy. For example: A Charge Point using mode 3: if the EV is in B2 this also means SuspendedEV. (Operative)</td></tr></table>
+
+# 3.56. Page 79, section: 7.8: concurrencyKind only to be used with chargingProfileKind: Recurring
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 90
+
+There is no description/explanation that the field "recurrencyKind" should only be used when "chargingProfileKind" is "Recurring"
+
+<table><tr><td>Old description</td><td>Optional. Indicates the start point of a recurrence.</td></tr><tr><td>New description</td><td>Optional. Indicates the start point of a recurrence.
+SHALL only be used when the field: concurrencyKind is set to: Recurring.</td></tr></table>
+
+# 3.57. Page 80, section: 7.13: GetCompositeScheduleResponse unclear how/when to use which start field
+
+Added in errata sheet v4.0
+
+The description of the field startSchedule must be replaced by the following.
+
+<table><tr><td>Old text</td><td>Optional. Starting point of an absolute schedule. If absent the schedule will be relative to start of charging.</td></tr><tr><td>New text</td><td>Optional. Starting point of an absolute schedule. If absent the schedule will be relative to start of charging.
+When ChargingSchedule is used as part of a GetCompositeSchedule.conf message, then this field must be omitted.</td></tr></table>
+
+# 3.58. Page 81, section: 7.15: Improved definition of string types: CiString20Type.
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 94
+
+Description of: CiString20Type can now be read as: "A String that has to be exactly 20 characters long." This is a maximum length, not a required length.
+
+<table><tr><td>Old text</td><td>Generic used case insensitive string of 20 characters.</td></tr><tr><td>New text</td><td>A case insensitive string with a maximum length of 20 characters.</td></tr></table>
+
+# 3.59. Page 81, section: 7.16: Improved definition of string types: CiString25Type.
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 94
+
+Description of: CiString25Type can now be read as: "A String that has to be exactly 25 characters long." This is a
+
+maximum length, not a required length.
+
+<table><tr><td>Old text</td><td>Generic used case insensitive string of 25 characters.</td></tr><tr><td>New text</td><td>A case insensitive string with a maximum length of 25 characters.</td></tr></table>
+
+# 3.60. Page 82, section: 7.17: Improved definition of string types: CiString50Type.
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 94
+
+Description of: CiString50Type can now be read as: "A String that has to be exactly 50 characters long." This is a maximum length, not a required length.
+
+<table><tr><td>Old text</td><td>Generic used case insensitive string of 50 characters.</td></tr><tr><td>New text</td><td>A case insensitive string with a maximum length of 50 characters.</td></tr></table>
+
+# 3.61. Page 82, section: 7.18: Improved definition of string types: CiString255Type.
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 95
+
+Description of: CiString255Type can now be read as: "A String that has to be exactly 255 characters long." This is a maximum length, not a required length.
+
+<table><tr><td>Old text</td><td>Generic used case insensitive string of 255 characters.</td></tr><tr><td>New text</td><td>A case insensitive string with a maximum length of 255 characters.</td></tr></table>
+
+# 3.62. Page 82, section: 7.19: Improved definition of string types: CiString500Type.
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 95
+
+Description of: CiString500Type can now be read as: "A String that has to be exactly 500 characters long." This is a maximum length, not a required length.
+
+<table><tr><td>Old text</td><td>Generic used case insensitive string of 500 characters.</td></tr><tr><td>New text</td><td>A case insensitive string with a maximum length of 500 characters.</td></tr></table>
+
+# 3.63. Page 84, section: 6.55: Description for UpdateFirmware.req: retrieveDate is ambiguous
+
+The description of the field: "retrieveDate" is ambiguous. It should not be "must", but: "is allowed to"
+
+<table><tr><td>Old text</td><td>Required. This contains the date and time after which the Charge Point must retrieve the (new) firmware.</td></tr><tr><td>New text</td><td>Required. This contains the date and time after which the Charge Point is allowed to retrieve the (new) firmware.</td></tr></table>
+
+# 3.64. Page 88, section: 7.7: Description SuspendedEVSE and SuspendedEV too strict, not all chargers have a contactor
+
+Descriptions for SuspendedEVSE and SuspendedEV seems to imply that an EVSE has a contactor, but that is not always the case, for example: wireless charging.
+
+<table><tr><td>SuspendedEVSE</td><td>Old text</td><td>When the contactor of a Connector opens upon request of the EVSE, e.g. due to a smart charging restriction or as the result of StartTransaction.conf indicating that charging is not allowed (Operative)</td></tr><tr><td>SuspendedEVSE</td><td>New text</td><td>When the EV is connected to the EVSE but the EVSE is not offering energy to the EV, e.g. due to a smart charging restriction, local supply power constraints, or as the result of StartTransaction.conf indicating that charging is not allowed etc. (Operative)</td></tr><tr><td>SuspendedEV</td><td>Old text</td><td>When the EVSE is ready to deliver energy but contactor is open, e.g. the EV is not ready.</td></tr><tr><td>SuspendedEV</td><td>New text</td><td>When the EV is connected to the EVSE and the EVSE is offering energy but the EV is not taking any energy. (Operative)</td></tr></table>
+
+# 3.65. Page 90, section: 7.8: validFrom fields are allowed for TxProfiles.
+
+In the class definition of ChargingProfile, the field: "validFrom", is defined as: "Not to be used when
+
+ChargingProfilePurpose is TxProfile." The specification denotes that the field ValidTo and ValidFrom are not to be used in combination with profiletype TxProfile. This note should have been deleted in the final version. With the decision to support stacking in combination with ProfileType TxProfile, the use of ValidFrom and ValidTo fields is unavoidable, since otherwise the profile with the highest StackLevel will be active until it is uninstalled.
+
+<table><tr><td>Old text</td><td>Optional. Point in time at which the profile starts to be valid. If absent, the profile is valid as soon as it is received by the Charge Point. Not to be used when ChargingProfilePurpose is TxProfile.</td></tr><tr><td>New text</td><td>Optional. Point in time at which the profile starts to be valid. If absent, the profile is valid as soon as it is received by the Charge Point.</td></tr></table>
+
+# 3.66. Page 91, section: 7.8: validTo fields are allowed for TxProfiles.
+
+In the class definition of ChargingProfile, the field: "validTo", is defined as: "Not to be used when
+
+ChargingProfilePurpose is TxProfile." The specification denotes that the field ValidTo and ValidFrom are not to be used in combination with profiletype TxProfile. This note should have been deleted in the final version. With the decision to support stacking in combination with ProfileType TxProfile, the use of ValidFrom and ValidTo fields is
+
+unavoidable, since otherwise the profile with the highest profile will be active until it is uninstalled.
+
+<table><tr><td>Old text</td><td>Optional. Point in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile. Not to be used when ChargingProfilePurpose is TxProfile.</td></tr><tr><td>New text</td><td>Optional. Point in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.</td></tr></table>
+
+# 3.67. Page 91, section: 7.10: Description of TxProfile/TxDefaultProfile in ChargingProfilePurposeType in relation with RemoteStartTransaction unclear
+
+It is not completely clear what the correct ProfilePurpose should be in a remoteStartTransaction.req.
+
+<table><tr><td>TxDefaultProfile</td><td>Old text</td><td>Default profile to be used for new transactions.</td></tr><tr><td>TxDefaultProfile</td><td>New text</td><td>Default profile that can be configured in the Charge Point. When a new transaction is started, this profile SHALL be used, unless it was a transaction that was started by a remoteStartTransaction.req with a ChargeProfile that is accepted by the Charge Point.</td></tr><tr><td>TxProfile</td><td>Old text</td><td>Profile with constraints to be imposed by the Charge Point on the current transaction. A profile with this purpose SHALL cease to be valid when the transaction terminates.</td></tr><tr><td>TxProfile</td><td>New text</td><td>Profile with constraints to be imposed by the Charge Point on the current transaction, or on a new transaction when this is started via a RemoteStartTransaction.req with a ChargingProfile. A profile with this purpose SHALL cease to be valid when the transaction terminates.</td></tr></table>
+
+# 3.68. Page 91, section: 7.38: BootNotification Rejected because of unknown ID not logical for JSON
+
+NEW: errata sheet v4.1
+
+With OCPP-J an unknown Charge Point will not receive a BootNotification Rejected, but an HTTP 404, as specified in the OCPP-J specification (Section 3.2).
+
+Therefor another example in the Rejected description is better.
+
+<table><tr><td>Old text</td><td>Charge point is not accepted by Central System. This may happen when the Charge Point id is not known by Central System.</td></tr><tr><td>New text</td><td>Charge point is not accepted by Central System. This may happen when the ims i is not known by Central System.</td></tr></table>
+
+# 3.69. Page 92, section: 7.12: ChargingRateUnit value descriptions need more clarification
+
+Using a ChargingRateUnit W for AC charging is potentially very complicated, and, if used, the calculation is tricky. The description of the values of the ChargingRateUnit should be improved.
+
+<table><tr><td>VAL
+UE</td><td>OLD
+DESCRIPTION</td><td>NEW DESCRIPTION</td></tr><tr><td>W</td><td>Watts (power).</td><td>Watts (power). This is the TOTAL allowed charging power. If used for AC Charging, the phase current should be calculated via: Current per phase = Power / (Line Voltage * Number of Phases). The "Line Voltage" used in the calculation is not the measured voltage, but the set voltage for the area (hence, 230 or 110 volt). The "Number of Phases" is the numberPhases from the ChargingSchedulePeriod. It is usually more convenient to use this for DC charging. Note that if numberPhases in a ChargingSchedulePeriod is absent, 3 SHALL be assumed.</td></tr><tr><td>A</td><td>Amperes (current).</td><td>Amperes (current). The amount of Ampere per phase, not the sum of all phases. It is usually more convenient to use this for AC charging.</td></tr></table>
+
+# 3.70. Page 93, section: 7.13: First ChargingSchedulePeriod should start with StartSchedule = 0
+
+Added in errata sheet v3.0
+
+There is no requirement that explains the obvious: The first ChargingSchedulePeriod should start with StartSchedule = 0.
+
+Updated description for the chargingSchedulePeriod field:
+
+<table><tr><td>Old text</td><td>Required. List of ChargingSchedulePeriod elements defining maximum power or current usage over time.</td></tr><tr><td>New text</td><td>Required. List of ChargingSchedulePeriod elements defining maximum power or current usage over time. The StartSchedule of the first ChargingSchedulePeriod SHALL always be 0.</td></tr></table>
+
+# 3.71. page 94, section: 7.14 ChargingSchedulePeriod Limit can also be in Watts
+
+ChargingSchedulePeriod field: Limit can be in Watts or Ampere.
+
+<table><tr><td>Old text</td><td>Required. Power limit during the schedule period, expressed in Amperes. Accepts at most one digit fraction (e.g. 8.1).</td></tr><tr><td>New text</td><td>Required. Charging rate limit during the schedule period, in the applicable chargingRateUnit, for example in Amperes or Watts. Accepts at most one digit fraction (e.g. 8.1).</td></tr></table>
+
+# 3.72. page 94 - 95, section: 7.15 - 7.19 CiStringXXXType should be defined as type
+
+The CiStringXXTypes are defined as Class, that contain a Field Name, but they should have been defined as Type (without Field Name)
+
+Paragraphs effected:
+
+- 7.15 CiString20Type
+- 7.16 CiString25Type
+- 7.17 CiString50Type
+- 7.18 CiString255Type
+- 7.19 CiString500Type
+
+Old definition:
+
+# 7.15 CiString20Type
+
+Class
+
+Generic used case insensitive string of 20 characters.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>DESCRIPTION</td></tr><tr><td>cstring20</td><td>CString[20]</td><td>String is case insensitive.</td></tr></table>
+
+New definition:
+
+# 7.15 CiString20Type
+
+Type
+
+Generic used case insensitive string of 20 characters.
+
+<table><tr><td>FIELD TYPE</td><td>DESCRIPTION</td></tr><tr><td>CiString[20]</td><td>String is case insensitive.</td></tr></table>
+
+These Changes have no effect on the WSDL and JSON definitions, they are defined correct in WSDL and JSON Schemas.
+
+# 3.73. Page 98, section: 7.27: Definition of IdTagInfo misses cardinality
+
+Every class definition in OCPP 1.6 contains a column called: "Card." (cardinality), but this column is missing in the definition of IdTagInfo.
+
+New definition:
+
+# 7.27 IdTagInfo
+
+Contains status information about an identifier. It is returned inauthorize,Start Transaction and Stop Transaction responses.
+
+If expiryDate is not given, the status has no end date.
+
+<table><tr><td>FIELD NAME</td><td>FIELD TYPE</td><td>CAR
+D.</td><td>DESCRIPTION</td></tr><tr><td>expireDate</td><td>dateTime</td><td>0..1</td><td>Optional. This contains the date at which idTag should be removed from the Authorization Cache.</td></tr><tr><td>parentIdTag</td><td>IdToken</td><td>0..1</td><td>Optional. This contains the parent-identifier.</td></tr><tr><td>status</td><td>AuthorizationStatus</td><td>1..1</td><td>Required. This contains whether the idTag has been accepted or not by the Central System.</td></tr></table>
+
+# 3.74. page 98, section: 7.28. Token: Token field is of wrong type
+
+The field: idToken should have been of the type CiString20Type, it is case insensitive.
+
+<table><tr><td>Old text</td><td>String[20]</td></tr><tr><td>New text</td><td>CiString20Type</td></tr></table>
+
+To prevent interoperability issues: Do NOT update WSDL files!
+
+Note: For future version: Token was missed when added the StringXXTypes. Might be removed as type, and all field of the type idToken in other Classes will then be replaced by String20Type.
+
+# 3.75. Page 98, section: 7.28: IdToken should be defined as type
+
+The IdToken is defined as Class, that contain a Field Name, but they should have been defined as Type (without Field Name) The WSDL and JSON Schema are correct, was only wrong in the specification. (was also wrong in OCPP 1.5)
+
+New definition:
+
+# 7.28 IdToken
+
+Type
+
+Contains the identifier to use for authorization. It is a case insensitive string. In future releases this may become a complex type to support multiple forms of identifiers.
+
+<table><tr><td>FIELD TYPE</td><td>DESCRIPTION</td></tr><tr><td>CString20Type</td><td>IdToken is case insensitive.</td></tr></table>
+
+# 3.76. Page 98, section: 9.1.5: Incorrect text about duration in MeterValue
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 111
+
+There is some text in the description of the configuration key: ClockAlignedDataInterval, talking about MeterValue duration. There is no duration of a MeterValue. This is old text from OCPP 1.5, which was already incorrect in OCPP 1.5. This text should have been removed.
+
+Ignore incorrect text:
+
+"and (optional) duration interval value, represented according to the ISO8601 standard"
+
+# 3.77. Page 98, section: 9.1.6: Improved description configuration key: "ConnectionTimeOut"
+
+Added in errata sheet v4.0
+
+The description of the configuration key: "ConnectionTimeOut" can be improved even further
+
+<table><tr><td>Old text</td><td>Interval from beginning of status: 'Preparing' until incipient session is automatically canceled, due to failure of EV driver to (correctly) insert the charging cable connector(s) into the appropriate socket(s). The Charge Point SHALL go back to the original state, probably: 'Available'</td></tr><tr><td>New text</td><td>Interval from beginning of status: 'Preparing' until incipient session is automatically canceled, due to failure of EV driver to (correctly) insert the charging cable connector(s) into the appropriate socket(s). The Charge Point SHALL go back to the original state, typically: 'Available'</td></tr></table>
+
+# 3.78. Page 99, section: 7.31: No definition of .register and .interval.
+
+The are a couple of measurands that are defined as .register or .interval. But there is no definition of what that means.
+
+Old:
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Energy.Active.ImportantlyRegister</td><td>Energy exported by EV (Wh or kWh)</td></tr><tr><td>Energy.Active.ImportantlyRegister</td><td>Energy imported by EV (Wh or kWh)</td></tr><tr><td>Energy.Reactive.Importantly Register</td><td>Reactive energy exported by EV (varh or kvarh)</td></tr><tr><td>Energy.Reactive.Importantly Register</td><td>Reactive energy imported by EV (varh or kvarh)</td></tr><tr><td>Energy.Active.Importantly Interval</td><td>Energy exported by EV (Wh or kWh)</td></tr><tr><td>Energy.Active.Importantly Interval</td><td>Energy imported by EV (Wh or kWh)</td></tr><tr><td>Energy.Reactive.Importantly Interval</td><td>Reactive energy exported by EV. (varh or kvarh)</td></tr><tr><td>Energy.Reactive.Importantly Interval</td><td>Reactive energy imported by EV. (varh or kvarh)</td></tr></table>
+
+New:
+
+
+
+Import is energy flow from the Grid to the Charge Point, EV or other load. Export is energy flow from the EV to the Charge Point and/or from the Charge Point to the Grid.
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Energy.Active.Export.Register</td><td>Numerical value read from the "active electrical energy" (Wh or kWh) register of the (most authoritative) electrical meter measuring energy exported (to the grid).</td></tr><tr><td>Energy.Active.Import.Register</td><td>Numerical value read from the "active electrical energy" (Wh or kWh) register of the (most authoritative) electrical meter measuring energy imported (from the grid supply).</td></tr><tr><td>Energy.Reactive.Export.Register</td><td>Numerical value read from the "reactive electrical energy" (VARh or kVARh) register of the (most authoritative) electrical meter measuring energy exported (to the grid).</td></tr><tr><td>Energy.Reactive.Import.Register</td><td>Numerical value read from the "reactive electrical energy" (VARh or kVARh) register of the (most authoritative) electrical meter measuring energy imported (from the grid supply).</td></tr><tr><td>Energy.Active.ImportInterval</td><td>Absolute amount of "active electrical energy" (Wh or kWh) exported (to the grid) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for "ClockAlignedDataInterval" and "MeterValueSampleInterval".</td></tr><tr><td>Energy.Active.ImportInterval</td><td>Absolute amount of "active electrical energy" (Wh or kWh) imported (from the grid supply) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for "ClockAlignedDataInterval" and "MeterValueSampleInterval".</td></tr><tr><td>Energy.Reactive.ImportInterval</td><td>Absolute amount of "reactive electrical energy" (VARh or kVARh) exported (to the grid) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for "ClockAlignedDataInterval" and "MeterValueSampleInterval".</td></tr><tr><td>Energy.Reactive.Import.Interval</td><td>Absolute amount of "reactive electrical energy" (VARh or kVARh) imported (from the grid supply) during an associated time "interval", specified by a Metvalues ReadingContext, and applicable interval duration configuration values (in seconds) for "ClockAlignedDataInterval" and "MeterValueSampleInterval".</td></tr></table>
+
+
+
+All "Register" values relating to a single charging transaction, or a non-transactional consumer (e.g. charge point internal power supply, overall supply) MUST be monotonically increasing in time.
+
+The actual quantity of energy corresponding to a reported ".Register" value is computed as the register value in question minus the register value recorded/reported at the start of the transaction or other relevant starting reference point in time. For improved auditability, ".Register" values SHOULD be reported exactly as they are directly read from a non-volatile register in the electrical metering hardware, and SHOULD NOT be re-based to zero at the start of transactions. This allows any "missing energy" between sequential transactions, due to hardware fault, mis-wiring, fraud, etc. to be identified, by allowing the Central System to confirm that the starting register value of any transaction is identical to the finishing register value of the preceding transaction on the same connector.
+
+# 3.79. Page 103, section: 7.37: RecurrencyKindType definition is ambiguous.
+
+Added in errata sheet v3.0
+
+The definition of RecurrencyKindType is ambiguous. It is not clear when a Charging Profile should recur.
+
+Changes to the table
+
+<table><tr><td>VALUE</td><td>OLD DESCRIPTION</td><td>NEW DESCRIPTION</td></tr><tr><td>Daily</td><td>The schedule restarts at the beginning of the next day.</td><td>The schedule restarts every 24 hours, at the same time as in the startSchedule.</td></tr><tr><td>Weekly</td><td>The schedule restarts at the beginning of the next week (defined as Monday morning).</td><td>The schedule restarts every 7 days, at the same time and day-of-the-week as in the startSchedule.</td></tr></table>
+
+# 3.80. Page 103, section: 9.1.23: Configuration key: "StopTransactionOnEVSideDisconnect" should not be required
+
+Added in errata sheet v4.0
+
+OCPP 1.6 FINAL Page 116
+
+The description of the configuration key: StopTransactionOnEVSideDisconnect is required. It was added to OCPP to support EVs without lock at the car side. But this is now never the case, it was only the case with the first version of the Mitsubishi Outlander PHEV.
+
+The German eichrect does not allow this configuration key to be implemented.
+
+<table><tr><td>Old value Required/optional</td><td>required</td></tr><tr><td>New value Required/optional</td><td>optional</td></tr><tr><td>Old value Accessibility</td><td>RW</td></tr><tr><td>New value Accessibility</td><td>R or RW. Choice is up to Charge Point implementation.</td></tr></table>
+
+# 3.81. Page 104, section: 9.1.30: Unneeded configuration key: "SupportedFeatureProfilesMaxLength"
+
+Added in errata sheet v4.0
+
+The description of the configuration key: SupportedFeatureProfilesMaxLength has no use.
+
+SupportedFeatureProfiles is a readily configuration key. SupportedFeatureProfiles could have been removed from the specification.
+
+<table><tr><td>Additiona textbeforetable</td><td>NOTE: This configuration key does not have to be implemented. It should not have been part of OCPP 1.6, "SupportedFeatureProfiles" is a readily configuration key.</td></tr></table>
+
+# 3.82. Page 105, section: 7.42: Improved description of Soft/Hard Reset
+
+Added in errata sheet v3.0
+
+The descriptions of Soft/Hard reset can be improved, not very clear what is the difference between the two.
+
+Changes to the table
+
+<table><tr><td>VALUE</td><td>OLD DESCRIPTION</td><td>NEW DESCRIPTION</td></tr><tr><td>Hard</td><td>Full reboot of Charge Point software.</td><td>Restart (all) the hardware, the Charge Point is not required to gracefully stop ongoing transaction. If possible the Charge Point sends a StopTransaction.req for previously ongoing transactions after having restarted and having been accepted by the Central System via a BootNotification.conf. This is a last resort solution for a not correctly functioning Charge Point, by sending a "hard" reset, (queued) information might get lost.</td></tr><tr><td>Soft</td><td>Return to initial status, gracefully terminating any transactions in progress.</td><td>Stop ongoing transactions gracefully and sending StopTransaction.req for every ongoing transaction. It should then restart the application software (if possible, otherwise restart the processor/controller).</td></tr></table>
+
+# 3.83. Page 105, section: 9.1: Missing standard Configuration Key for Message Timeout
+
+Added in errata sheet v4.0
+
+OCPP does not define what the required message timeout is. As OCPP is used for a lot of different transport layers, from 3G to fiber, timing can be very different. A CPO needs to be able to configure this, based on the network used. But OCPP did not define a standard configuration key for this. So now almost every Charge Point manufacturer defines his own name for the same thing.
+
+New definition:
+
+# 9.1 Core Profile
+
+9.1.15 MessageTimeout
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td>Description</td><td>Defines the OCPP Message timeout in seconds.
+If the Charge Point has not received a response to a request within this timeout, the Charge Point SHALL consider the request timed out.</td></tr></table>
+
+# 3.84. (2025-04) - Page 105 - section: 9.1.33 - Allow UnlockConnectorOnEVSideDisconnect to be implemented as R for non-fixed cable Charge Points
+
+Note: This erratum revises erratum: Page 105, section: 9.1.33: Unclear how to implement UnlockConnectorOnEVSideDisconnect with a Charge Point with a fixed cable
+
+The TWG decided that it should be allowed to implement the configuration key UnlockConnectorOnEVSideDisconnect as ReadOnly for types of implementations other than only Charge Points with a fixed cable. For example, when a Charge Point does not support local authorization and there is no way for the user to unlock the connector. Therefore, the specification will not require this configuration key to be ReadWrite anymore. However, a Charge Point implementer should still make this configuration key ReadWrite in case this is feasible.
+
+<table><tr><td>Accessibility</td><td>R or RW (RO in case of fixed cable)</td></tr><tr><td>Description</td><td>When set to true, the Charge Point SHALL unlock the cable on Charge Point side when the cable is unplugged at the EV. A Charge Point with a fixed cable SHALL always report this value as false and SHALL not allow this value to be changed. A Charge Point SHOULD implement this configuration key as RW, in case the EV driver is not blocked from unlocking the connector when this value is set to false.</td></tr></table>
+
+# 3.85. Page 105, section: 9.1.33: Unclear how to implement UnlockConnectorOnEVSideDisconnect with a Charge Point with a fixed cable
+
+Added in errata sheet v4.0
+
+Note: This erratum is revised by erratum: (2025-04) - Page 105 - section: 9.1.33 - Allow
+
+In the table describing the variable UnlockConnectorOnEVSideDisconnect change the text of the following rows:
+
+<table><tr><td>Accessibility</td><td>RW (RO in case of fixed cable)</td></tr><tr><td>Description</td><td>When set to true, the Charge Point SHALL unlock the cable on Charge Point side when the cable is unplugged at the EV. A Charge Point with a fixed cable SHALL always report this value as false and SHALL not allow this value to be changed.</td></tr></table>
+
+# 3.86. Page 106, section: 7.45: No UnitOfMeasure for Measurand Frequency.
+
+There is no UnitOfMeasure for Measurand: Frequency.
+
+<table><tr><td>Add to the description for Frequency on page 100, section: 7.31:</td><td>OCPP 1.6 does not have a UnitOfMeasure for frequency, the UnitOfMeasure for any SampledValue with measurand: Frequency is Hertz.</td></tr></table>
+
+# 3.87. Page 107, section: 7.42: UnlockConnector with unknown ConnectorId
+
+Added in errata sheet v3.0
+
+It has not been specified how a Charge Point should respond when a Central System request an Unlock Connector for an unknown ConnectorId.
+
+Preferably the response would have been: "Rejected", so that will be added to OCPP 2.0. For OCPP 1.6 we cannot add extra states, so we have to use "NotSupported". "UnlockFailed" should not be used for this, "UnlockFailed" is really for when the locking mechanism detects a failed unlock attempt.
+
+Changes to the table
+
+<table><tr><td>VALUE</td><td>OLD DESCRIPTION</td><td>NEW DESCRIPTION</td></tr><tr><td>UnlockFailed</td><td>Failed to unlock the connector.</td><td>Failed to unlock the connector: The Charge Point has tried to unlock the connector and has detected that the connector is still locked or the unlock mechanism failed.</td></tr><tr><td>NotSupported</td><td>Charge Point has no connector lock</td><td>Charge Point has no connector lock, or ConnectorId is unknown.</td></tr></table>
+
+# 3.88. Page 107, section: 9.4.2: Configuration key: "ChargingScheduleAllowedChargingRateUnit" values confusing
+
+Added in errata sheet v4.0
+
+The configuration key: ChargingScheduleAllowedChargingRateUnit has two allowed values: 'Current' and 'Power'. While ChargingRateUnitType (page 80, section: 7.12) has the possible values: 'A' and 'W'. This is confusing.
+
+It would have been better if the allowed values for ChargingScheduleAllowedChargingRateUnit would also
+
+have been: 'A' and 'W'. That will be the solution for OCPP 2.0.
+
+For OCPP 1.6 an extra explanation is added.
+
+<table><tr><td>AdditionaI descriptiOn</td><td>‘Current' means only ChargingSchedules with ChargingRateUnit: 'A' allowed‘Power' means only ChargingSchedules with ChargingRateUnit: 'W' allowed</td></tr></table>
+
+# 3.89. Page 112, section: 9.1.6: Improved description configuration key: "ConnectionTimeOut"
+
+The description of the configuration key: "ConnectionTimeOut" can be improved
+
+<table><tr><td>Old text</td><td>Interval (from successful authorization) until incipient charging session is automatically canceled due to failure of EV user to (correctly) insert the charging cable connector(s) into the appropriate connector(s).</td></tr><tr><td>New text</td><td>Interval from beginning of status: 'Preparing' until incipient session is automatically canceled, due to failure of EV driver to (correctly) insert the charging cable connector(s) into the appropriate socket(s). The Charge Point SHALL go back to the original state, probably: 'Available'</td></tr></table>
+
+# 3.90. Page 121, section: 9: Missing definition for SupportedFileTransferProtocols
+
+Added in errata sheet v4.0
+
+In chapter 8, page 96 (OCPP 1.6 FINAL: page 109), there is a reference to a configuration key: SupportedFileTransferProtocols. This configuration key is not defined in chapter 9.
+
+New definition:
+
+# 9.5 Firmware Management
+
+9.5.1 SupportedFileTransferProtocols
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>R</td></tr><tr><td>Type</td><td>CSL</td></tr><tr><td>Description</td><td>This configuration key tells the Central System which file transfer protocols are supported by the Charge Point. Allowed values: 'FTP', 'FTPS', 'HTTP' and 'HTTPS'.</td></tr></table>
+
+# 3.91. Page 121, section: 9.1: Central System needs to known maximum amount of meter values in StopTransaction
+
+Added in errata sheet v4.0
+
+When a Charge Point is configured to provide meter values in the StopTransaction via: StopTxnSampledData and/or StopTxnAlignedData, and the Transaction takes really long (think: EV parked for days at an airport) or the interval in configured to a low value in: ClockAlignedDataInterval or MeterValueSampleInterval, the Charge Point might collect more meter values than it can store or send in a StopTransaction. In this case the Charge Point needs to drop intermediate values to prevent crashes etc. But the Central System needs to know at what point this happens.
+
+New definition:
+
+# 9.1 Core Profile
+
+# 9.1.23 StopTransactionMaxMeterValues
+
+<table><tr><td>Required/optional</td><td>optional</td></tr><tr><td>Accessibility</td><td>R</td></tr><tr><td>Type</td><td>integer</td></tr><tr><td rowspan="2">Description</td><td>The maximum amount of meter values that this Charge Point can report in the transactionData field of a StopTransaction.req. When the amount of meter values collected for a transaction exceeds: StopTransactionMaxMeterValues, the Charge Point MAY drop intermediate meter values, to prevent running out of memory, or being unable to send the StopTransaction.req (overrunning the transmit buffer size). The Start and Stop meter values SHALL never be dropped.</td></tr><tr><td>When the Charge Point needs to store more intermediate values than: StopTransactionMaxMeterValues, it is RECOMMENDED not to start dropping messages from the start, or stop storing new values. It is better to drop intermediate messages first (1st message, 3th message, 5th message etc.), or uses a smart algorithm, for example remove duplicate values first. etc.</td></tr></table>
+
+# 4. Typos
+
+Typos, fixes to incorrect links/reference, improve terms used etc. that have no impact on the description of the way the protocol works.
+
+# 4.1. Generic: Tipo Field Type: DateTime should be DateTime
+
+dateTime field type is misspelled a couple of times as: DateTime (with upper-case D)
+
+<table><tr><td>PAGE</td><td>SECTION</td><td>MESSAGE/CLASS</td><td>FIELD NAME</td></tr><tr><td>24</td><td>3.12.2</td><td>NOTE add the bottom</td><td>validFrom</td></tr><tr><td>70</td><td>6.22</td><td>GetCompositeSchedule.conf</td><td>scheduleStart</td></tr><tr><td>90</td><td>7.8</td><td>ChargingProfile</td><td>validFrom</td></tr><tr><td>91</td><td>7.8</td><td>ChargingProfile</td><td>validTo</td></tr><tr><td>93</td><td>7.13</td><td>ChargingProfile</td><td>startSchedule</td></tr></table>
+
+# 4.2. Generic: Use of Energy Meter vs Power Meter
+
+The terms Energy Meter and Power Meter are use throughout the specification, but they are not used consistently and the term: Electrical Meter seems to fit most cases even better.
+
+List of all textual improvements for this:
+
+<table><tr><td>PAGE</td><td>SECTION</td><td>OLD TEXT</td><td>NEW TEXT</td></tr><tr><td>8</td><td>2.2</td><td>Defines the wiring order of the phases between the energy meter (or if absent, the grid connection), and the Charge Point connector.</td><td>Defines the wiring order of the phases between the electrical meter (or if absent, the grid connection), and the Charge Point connector.</td></tr><tr><td>38</td><td>4.7</td><td>A Charge Point MAY sample the energy meter or other sensor/transducer hardware to provide extra information about its meter values.</td><td>A Charge Point MAY sample the electrical meter or other sensor/transducer hardware to provide extra information about its meter values.</td></tr><tr><td>38</td><td>4.7</td><td>The Charging Point SHALL report all phase number dependent values from the power meter (or grid connection when absent) point of view.</td><td>The Charging Point SHALL report all phase number dependent values from the electrical meter (or grid connection when absent) point of view.</td></tr><tr><td>63</td><td>6.3</td><td>This contains the serial number of the main power meter of the Charge Point.</td><td>This contains the serial number of the main electrical meter of the Charge Point.</td></tr><tr><td>63</td><td>6.3</td><td>This contains the type of the main power meter of the Charge Point.</td><td>This contains the type of the main electrical meter of the Charge Point.</td></tr><tr><td>87</td><td>7.6</td><td>Failure to read power meter.</td><td>Failure to read electrical/energy/ power meter.</td></tr><tr><td>116</td><td>9.1.21</td><td>The phase rotation per connector in respect to the connector's energy meter (or if absent, the grid connection).</td><td>The phase rotation per connector in respect to the connector's electrical meter (or if absent, the grid connection).</td></tr></table>
+
+# 4.3. Page 13, section: 3.2: Tipo in text about SupportedFeatureProfiles
+
+Below the table with the mapping of messages to feature profiles, there is a typo: "charging profiles" instead of "feature profiles".
+
+<table><tr><td>Old text</td><td>The support for the specific charging profiles is reported by the SupportedFeatureProfiles configuration key.</td></tr><tr><td>New text</td><td>The support for the specific feature profiles is reported by the SupportedFeatureProfiles configuration key.</td></tr></table>
+
+# 4.4. Page 18, section: 3.4.4: Tipo in Unknown Offline Authorization
+
+There is a typo in the text about Unknown Offline Authorization.
+
+<table><tr><td>Old text</td><td>When connection the the Central Server is restored</td></tr><tr><td>New text</td><td>When connection to the Central Server is restored</td></tr></table>
+
+# 4.5. Page 19, section: 3.5: Definition of OCPP Transaction, Session, EnergyOfferPeriod etc missing.
+
+In the table on page 19, there are some terms used that are never described in the specification.
+
+Changes to the diagram on page 19:
+
+<table><tr><td>OLD TEXT</td><td>NEW TEXT</td></tr><tr><td>Session</td><td>Charging Session</td></tr><tr><td>OCPP Transaction</td><td>Transaction</td></tr></table>
+
+Update diagram for section: 3.5 on page 19:
+
+
+Changes to the table of definitions in section:. 2.2 on page 7
+
+<table><tr><td>TERM</td><td>OLD DESCRIPTION</td><td>NEW DESCRIPTION</td></tr><tr><td>Charging Session</td><td>Part of a transaction during which the EV is allowed to request energy</td><td>a Charging Session is started when first interaction with user or EV occurs. This can be a card swipe, remote start of transaction, connection of cable and/or EV, parking bay occupancy detector, etc.</td></tr></table>
+
+Additions to the table of definitions in section:. 2.2 on page 7
+
+<table><tr><td>TERM</td><td>DESCRIPTION</td></tr><tr><td>Energy Offer Period</td><td>Energy Offer Period starts when the EVSE is ready and willing to supply energy.</td></tr><tr><td>Energy Offer SuspendPeriod</td><td>During a transaction, there may be periods the EnergyOffer to EV is suspended by the EVSE, for instance due to Smart Charging or local balancing.</td></tr></table>
+
+Changes throughout the entire specification, correcting incorrect term use.
+
+<table><tr><td>PAGE</td><td>PAR.</td><td>OLD TEXT</td><td>NEW TEXT</td></tr><tr><td>42</td><td>4.9</td><td>C6: Charging session is stopped by user or a Remote Stop Transaction message and further user action is required (e.g. remove cable, leave parking bay)</td><td>C6: Transaction is stopped by user or a Remote Stop Transaction message and further user action is required (e.g. remove cable, leave parking bay)</td></tr><tr><td>42</td><td>4.9</td><td>D6: Charging session is stopped and further user action is required</td><td>D6: Transaction is stopped and further user action is required</td></tr><tr><td>43</td><td>4.9</td><td>E6: Charging session is stopped and further user action is required</td><td>E6: Transaction is stopped and further user action is required</td></tr><tr><td>43</td><td>4.9</td><td>F2: User restart charging session (e.g. reconnects cable, presents idTag again)</td><td>F2: User restart charging session (e.g. reconnects cable, presents idTag again), thereby creating a new Transaction</td></tr><tr><td>88</td><td>7.7</td><td>Preparing: When a Connector becomes no longer available for a new user but no charging session is active. Typically a Connector is occupied when a user presents a tag, inserts a cable or a vehicle occupies the parking bay</td><td>Preparing: When a Connector becomes no longer available for a new user but there is no ongoing Transaction (yet). Typically a Connector is in preparing state when a user presents a tag, inserts a cable or a vehicle occupies the parking bay</td></tr><tr><td>88</td><td>7.7</td><td>Finishing: When a charging session has stopped at a Connector, but the Connector is not yet available for a new user, e.g. the cable has not been removed or the vehicle has not left the parking bay</td><td>Finishing: When a Transaction has stopped at a Connector, but the Connector is not yet available for a new user, e.g. the cable has not been removed or the vehicle has not left the parking bay.</td></tr><tr><td>91</td><td>7.9</td><td>such as the start of a session</td><td>such as the start of a Transaction</td></tr><tr><td>111</td><td>9.1.5</td><td>or partial interval, at the beginning or end of a charging session</td><td>or partial interval, at the beginning or end of a Transaction</td></tr><tr><td>112</td><td>9.1.6</td><td>Interval (from successful authorization) until incipient charging session is automatically canceled due to failure of EV user to (correctly) insert the charging cable connector(s) into the appropriate connector(s).</td><td>Interval (from successful authorization) until incipient Transaction is automatically canceled due to failure of EV user to (correctly) insert the charging cable connector(s) into the appropriate connector(s).</td></tr><tr><td>117</td><td>9.1.25</td><td>Clock-aligned periodic measurand(s) to be included in the TransactionData element of StopTransaction.req MeterValues.req PDU for every ClockAlignedDataInterval of the charging session</td><td>Clock-aligned periodic measurand(s) to be included in the TransactionData element of StopTransaction.req MeterValues.req PDU for every ClockAlignedDataInterval of the Transaction</td></tr><tr><td>117</td><td>9.1.27</td><td>Sampled measurands to be included in the TransactionData element of StopTransaction.req PDU, every MeterValueSampleInterval seconds from the start of the charging session</td><td>Sampled measurands to be included in the TransactionData element of StopTransaction.req PDU, every MeterValueSampleInterval seconds from the start of the Transaction</td></tr><tr><td>121</td><td>9.4.4</td><td>If defined and true, this Charge Point support switching from 3 to 1 phase during a charging session.</td><td>If defined and true, this Charge Point support switching from 3 to 1 phase during a Transaction.</td></tr></table>
+
+# 4.6. Page 34, section: 4.2: Boot Notification diagram: Interval
+
+Figure 13: "Sequence Diagram: Boot Notification" contains a typo.
+
+<table><tr><td>Old text</td><td>BootNotification.conf(currentTime, heartbeatInterval, status)</td></tr><tr><td>New text</td><td>BootNotification.conf(currentTime, interval, status)</td></tr></table>
+
+# 4.7. Page 35, section: 4.21: Tipo in description
+
+Added in errata sheet v4.0
+
+This errata does not effect OCPP 1.6 Final (first edition)
+
+The text in contains: "this such" which is just wrong.
+
+<table><tr><td>Old text</td><td>Parties who want to implement this such behaviour must realize that it is uncertain if those transactions can ever be delivered to the Central System.</td></tr><tr><td>New text</td><td>Parties who want to implement this behaviour must realize that it is uncertain if those transactions can ever be delivered to the Central System.</td></tr></table>
+
+# 4.8. Page 35, section: 4.5. Wrong message name for UpdateFirmware
+
+Added in errata sheet v4.0
+
+This errata does not effect OCPP 1.6 Final (first edition)
+
+Last sentence of this section contains a reference to UpdateFirmware.req, but is has an incorrect name
+
+<table><tr><td>Old text</td><td>started by the Central System with a FirmwareUpdate.req PDU</td></tr><tr><td>New text</td><td>started by the Central System with a UpdateFirmware.req PDU</td></tr></table>
+
+# 4.9. Page 39, section: 4.9. Tipo in table: Preparing
+
+Added in errata sheet v4.0
+
+This errata does not effect OCPP 1.6 Final (first edition)
+
+The title of column 2 contains a typo
+
+<table><tr><td>Old text</td><td>Prepairing</td></tr><tr><td>New text</td><td>Preparing</td></tr></table>
+
+# 4.10. Page 47, section: 4.10: Tipo description in stop transaction
+
+There is a typo in the description of StopTransactionOnEVSideDisconnect set to true.
+
+<table><tr><td>Old text</td><td>Setting StopTransactionOnEVSideDisconnect to true will prevent sabotage acts top stop the energy flow by unplugging not locked cables on EV side.</td></tr><tr><td>New text</td><td>Setting StopTransactionOnEVSideDisconnect to true will prevent sabotage acts to stop the energy flow by unplugging not locked cables on EV side.</td></tr></table>
+
+# 4.11. Page 50, section: 5.5: Clear Charging Profile sequence diagram: incorrect .conf message
+
+The sequence diagram on page 50 for Clear Charging Profile contains a typo. It contains the incorrect response: "ClearCache.conf" instead of "ClearChargingProfile.conf"
+
+Update diagram for section: 5.5 on page 50:
+
+
+Figure 3. Updated Sequence Diagram: Clear Charging Profile
+
+# 4.12. Page 55, section: 5.13: Missing MAY in description Reservation Parent idTag
+
+The text MAY is missing in the description of getting the parent-id for a reservation via Authorization.req.
+
+<table><tr><td>Old text</td><td>The Authorization.conf response contains the parent-id.</td></tr><tr><td>New text</td><td>The Authorization.conf response MAY contain the parent-id</td></tr></table>
+
+# 4.13. Page 55, section: 5.16.4: Tipo in note about first chargingSchedulePeriod
+
+Added in errata sheet v4.0
+
+This errata does not effect OCPP 1.6 Final (first edition)
+
+There is a typo in the note about the first chargingSchedulePeriod
+
+<table><tr><td>Old text</td><td>The StartSchedule of the first chargingSchedulePeriod in a chargingSchedule SHALL always be 0.</td></tr><tr><td>New text</td><td>The startPeriod of the first chargingSchedulePeriod in a chargingSchedule SHALL always be 0.</td></tr></table>
+
+# 4.14. Page 56, section: 5.14: Tipo in reset description
+
+Added in errata sheet v3.0
+
+There is a typo in the description of Reset response.
+
+<table><tr><td>Old text</td><td>The response PDU SHALL include whether the Charge Point is will attempt to reset itself.</td></tr><tr><td>New text</td><td>The response PDU SHALL include whether the Charge Point will attempt to reset itself.</td></tr></table>
+
+# 4.15. Page 60, section: 5.18: Central System sends Unlock Connector
+
+In the paragraph about Unlock Connector, "Charge Point" and "Central Server" are mixed up.
+
+<table><tr><td>Old text</td><td>To do so, The Charge Point SHALL send</td></tr><tr><td>New text</td><td>To do so, The Central System SHALL send</td></tr></table>
+
+# 4.16. Page 71, section: 6.23: Tipo in GetConfiguration.req
+
+There is a typo in the text about GetConfiguration.req.
+
+<table><tr><td>Old text</td><td>This contains the field definition of the GetConfiguration.req PDU sent by the the Central System to the Charge Point</td></tr><tr><td>New text</td><td>This contains the field definition of the GetConfiguration.req PDU sent by the Central System to the Charge Point</td></tr></table>
+
+# 4.17. Page 81, section: 7.13: Tipo in ChargingSchedule chargingSchedulePeriod description
+
+Added in errata sheet v4.0
+
+There is a typo in the description of chargingSchedulePeriod
+
+<table><tr><td>Old text</td><td>The startSchedule of the first ChargingSchedulePeriod SHALL always be 0.</td></tr><tr><td>New text</td><td>The startPeriod of the first ChargingSchedulePeriod SHALL always be 0.</td></tr></table>
+
+# 4.18. Page 91, section: 7.9: ChargingProfileKindType misses description and 'where used'
+
+There is no 'where used' in the definition of ChargingProfileKindType
+
+<table><tr><td>Additional text</td><td>Kind of charging profile, as used in: ChargingProfile</td></tr></table>
+
+# 4.19. Page 91, section: 7.10: Description of ChargePointMaxProfile in ChargingProfilePurposeType contains unused words
+
+The description ChargePointMaxProfile in ChargingProfilePurposeType contains words that should not have been here.
+
+<table><tr><td>Old text</td><td>Configuration for the maximum power or current available for an entire Charge Point.SetChargingProfile.req message.</td></tr><tr><td>New text</td><td>Configuration for the maximum power or current available for an entire Charge Point.</td></tr></table>
+
+# 4.20. Page 91, section: 7.10: ChargingProfilePurposeType misses description and 'where used'
+
+There is no 'where used' in the definition of ChargingProfilePurposeType
+
+<table><tr><td>Additional text</td><td>Purpose of the charging profile, as used in: ChargingProfile</td></tr></table>
+
+# 4.21. Page 92, section: 7.13: ChargingSchedule misses description and 'where used'
+
+There is no 'where used' in the definition of ChargingSchedule.
+
+<table><tr><td>Additional text</td><td>Charging schedule structure defines a list of charging periods, as used in: GetCompositeSchedule.conf and ChargingProfile</td></tr></table>
+
+# 4.22. Page 93, section: 7.14: ChargingSchedulePeriod misses description and 'where used'
+
+There is no 'where used' in the definition of ChargingSchedulePeriod.
+
+<table><tr><td>Additional text</td><td>Charging schedule period structure defines a time period in a charging schedule, as used in: ChargingSchedule</td></tr></table>
+
+# 4.23. Page 96, section: 7.22. Tipo in descriptions ConfigurationStatus
+
+Word 'is' is missing in descriptions of ConfigurationStatus
+
+<table><tr><td>OLD TEXT</td><td>NEW TEXT</td></tr><tr><td>Configuration key supported and setting has been changed.</td><td>Configuration key is supported and setting has been changed.</td></tr><tr><td>Configuration key supported, but setting could not be changed.</td><td>Configuration key is supported, but setting could not be changed.</td></tr><tr><td>Configuration key supported and setting has been changed,</td><td>Configuration key is supported and setting has been changed,</td></tr></table>
+
+# 4.24. Page 101, section: 7.33: MeterValue misses used by StopTransaction.req
+
+In the description of MeterValue there is a link to the usage of MeterValue: MeterValue.req, MeterValue it is also used in StopTransaction.req.
+
+<table><tr><td>Old text</td><td>Collection of one or more sampled values in MeterValues.req.</td></tr><tr><td>New text</td><td>Collection of one or more sampled values in MeterValues.req and StopTransaction.req.</td></tr></table>
+
+# 4.25. Page 102, section: 7.35: Descriptions Transaction.Begin, Transaction.End swapped
+
+The descriptions of Transaction.Begin and Transaction.End are swapped.
+
+Old:
+
+New:
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Transaction.Begin</td><td>Value taken at end of transaction.</td></tr><tr><td>Transaction.End</td><td>Value taken at start of transaction.</td></tr></table>
+
+<table><tr><td>VALUE</td><td>DESCRIPTION</td></tr><tr><td>Transaction.Begin</td><td>Value taken at start of transaction.</td></tr><tr><td>Transaction.End</td><td>Value taken at end of transaction.</td></tr></table>
+
+# 4.26. Page 106, section: 7.45: UnitOfMeasure links to incorrect usage
+
+In the description of UnitOfMeasure there are links to the usage of UnitOfMeasure. There incorrectly say: MeterValues.req and StopTransaction.req, should be: SampledValue
+
+<table><tr><td>Old text</td><td>Allowable values of the optional "unit" field of a Value element, as used in MeterValues.req and StopTransaction.req messages.</td></tr><tr><td>New text</td><td>Allowable values of the optional "unit" field of a Value element, as used in SampledValue.</td></tr></table>
+
+# 4.27. Page 110, section: 9: Tipo in Standard Configuration Key Names & Values
+
+There is a typo in the text about Standard Configuration Key Names & Values.
+
+<table><tr><td>Old text</td><td>In case the the accessibility is read-write, the Central System can also write the value for the key using ChangeConfiguration</td></tr><tr><td>New text</td><td>In case the accessibility is read-write, the Central System can also write the value for the key using ChangeConfiguration.</td></tr></table>
+
+# 4.28. Page 121, section: 9.4.4: ConnectorSwitch3to1PhaseSupported: Type should be boolean
+
+There is a typo in the type definition of the configuration key: ConnectorSwitch3to1PhaseSupported: Type should be boolean, is now bool.
+
+<table><tr><td>Old type</td><td>bool</td></tr><tr><td>New type</td><td>boolean</td></tr></table>
+
+# 4.29. Page 123, section: A.1: Power.Factor is missing in the list of new enum values
+
+In the list of new values for the enum: Measurand, the value: Power.Factor is missing, should be added.
+
+<table><tr><td>Old text</td><td>Added enum Current. Offered, Frequency, Power. Offered, RPM and SoC</td></tr><tr><td>New text</td><td>Added enum Current. Offered, Frequency, Power. Factor, Power. Offered, RPM and SoC</td></tr></table>
+
+# 5. Known issues that will not be fixed
+
+None known
--- /dev/null
+# OCPP
+
+Copyright © 2010 - 2025 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
+
+<table><tr><td>VERSION</td><td>DATE</td><td>DESCRIPTION</td></tr><tr><td>2025-04</td><td>2025-04-30</td><td>Errata sheet release 2025-04.</td></tr><tr><td>v1.0 Release</td><td>2019-12-04</td><td>Release of the OCPP-J errata sheet</td></tr></table>
+
+# 1. Scope
+
+This document contains errata on the OCPP 1.6-J specification (JSON) and JSON-Schema files.
+
+# 1.1. JSON Schema files
+
+With the release of this version of the erratasheet (2025-04) also a OCPP 1.6 JSON Schema file was updated.
+
+Version information has been added to all the files: ID field. The updated StopTransaction.req JSON Schema file for this version is marked with: "urn:OCPP:1.6:2025:04"
+
+# 1.2. Terminology and Conventions
+
+Underlined: when needed to clarify differences, they might be underlined.
+
+# 2. Major errata
+
+Problems with the content/definition of the messages, class and enumerations of the protocol.
+
+# 2.1. (2025-04) - MeterValues.json and StopTransaction.json incorrect spelling of Celsius V2
+
+Note: This erratum supersedes erratum: MeterValues.json and StopTransaction.json incorrect spelling of Celsius
+
+There are several issues with the original erratum that needs to be revised.
+
+The erratum advises Central System implementers to update their own JSON schemas to also allow the correct spelling. This brings risks, as the erratum is easily missed and the JSON schema's will be used as available on the website.
+
+In addition, the erratum advises the Charge Point implementers to update their messages to use the corrected spelling. This poses significant risk as this will cause interoperability issues with all Central Systems that have not updated their JSON schemas.
+
+Finally, while the erratum mentions that the JSON schemas will not be fixed, the MeterValues.req JSON schema was updated. Unfortunately the StopTransaction.req JSON schema was missed. Updating the JSON schemas so they contain both spellings is the correct decision, because the main purpose of the JSON schemas is that they are being used for JSON Schema validation. In this case we always want to allow both spellings, to maximize interoperability. The secondary purpose is generating the message data model from them, but even in that case the Charge Point implementer makes an active decision on which unit of measure to send. Both spellings would be a valid choice, but when a Charge Point implementer reads this erratum, it recommends to use the not corrected version of the spelling; Celcius, to maximize interoperability.
+
+# Summary:
+
+1. The JSON schema StopTransaction.req is updated to also include the corrected spelling Celsius.
+2. Charge Point implementers are advised to remain using the not corrected version of the spelling Celcius.
+
+3. Central System implementers are advised to use the updated JSON schema for their JSON schema validation and accept both spellings; Celsius and Celcius.
+
+# 2.2. MeterValues.json and StopTransaction.json incorrect spelling of Celsius
+
+Note: This erratum has been superseded by erratum: (2025-04) - MeterValues.json and StopTransaction.json incorrect spelling of Celsius V2
+
+The OCPP 1.6 JSON schema message definitions set, as originally published, contains a typo that renders it inconsistent with both the written OCPP 1.6 specification and the SOAP/XML Schema/WSDLs schema definitions.
+
+In the MeterValues and StopTransaction message structure (in MeterValues.json and StopTransaction.json), the definition of Celsius as a unit has been misspelled as: "Celcius".
+
+We advise implementers of an OCPP 1.6 JSON Central System to add the correct spelling (Celsius) to the enumeration. This way your implementation will support both the correct and the incorrect spellings. Somebody implementing a OCPP 1.6 JSON Charge Point, and using the object generated by the WSDL files to serialize JSON might send the correct spelling to a Central System.
+
+We advise the implementers of OCPP 1.6 JSON Charge Points to correct the spelling mistake.
+
+
+
+This issue will not be fixed in future schema files, Central Systems need to support both, and adding both in the Schema could be confusing for Charge Point implementers.
+
+# 2.3. SendLocalList.json schema file incorrect
+
+The OCPP 1.6 JSON schema file for SendLocalList is incorrect, as it is not a valid JSON Schema draft-04.
+
+The part that defines the "idTagInfo" is incorrect: "expireDate" and " parentIdTag" should have been part of the properties.
+
+Incorrect
+
+```javascript
+"idTagInfo": { "type": "object", "expirationDate": { "type": "string", "format": "date-time" }, "parentIdTag": { "type": "string", "maxLength": 20 }, "properties": { "status": { "type": "string", "enum": [ "Accepted", "Blocked", "Expired", "Invalid",
+```
+
+Corrected
+
+```javascript
+"ConcurrentTx" ] } }， "required":[ status" ] 1
+```
+
+```txt
+"idTagInfo": { "type": "object", "properties": { "expireDate": { "type": "string", "format": "date-time" }, "parentIdTag": { "type": "string", "maxLength": 20 }, "status": { "type": "string", "enum": [ "Accepted", "Blocked", "Expired", "Invalid", "ConcurrentTx"] } }, "required": [ "status"] }
+```
+
+A newer JSON Schema will be provided. When using JSON Schemas, this newer schema SHALL be used, the older version cannot be parsed by (most) JSON schema tools.
+
+# 2.4. BootNotificationResponse.json schema file incorrect
+
+The OCPP 1.6 JSON schema file for BootNotificationResponse contains an error. The field "interval" is defined as a 'number', but should have been: 'integer'
+
+The WSDL files for OCPP-S is correct.
+
+Incorrect
+
+```powershell
+{ "$schema": "http://json-schema.org/draft-04-schema#"， "title": "BootNotificationResponse"，
+```
+
+Corrected
+
+```txt
+"type": "object",
+"properties": \{
+ status": \{
+ "type": "string",
+ "enum": [ accepted ],
+ "Pending",
+ "Rejected"
+ \},
+ "currentTime": \{
+ "type": "string",
+ "format": "date-time"
+ \},
+ "interval": \{
+ "type": "number"
+ \}
+\},
+"additionalProperties": false,
+"required": [ status",
+"Now time",
+"interval"
+]
+```
+
+```json
+"\\(schema": "http://json-schema.org/draft-04-schema#",
+"title": "BootNotificationResponse",
+"type": "object",
+"properties": {
+ "status": {
+ "type": "string",
+ "enum": [
+ "Accepted",
+ "Pending",
+ "Rejected"
+ ]
+ },
+ "currentTime": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "interval": {
+ "type": "integer"
+ }
+},
+"additionalProperties": false,
+"required": [
+ "status",
+ "currentTime",
+ "interval"
+]
+```
+
+}
+
+# 2.5. UpdateFirmware.json schema file incorrect
+
+The OCPP 1.6 JSON schema file for UpdateFirmware contains 2 errors. The fields "retries" and "retryInterval" are defined as a 'number', but should have been: 'integer'
+
+The WSDL files for OCPP-S is correct.
+
+Incorrect
+
+```json
+{
+ "$schema": "http://json-schema.org/draft-04-schema#",
+ "title": "UpdateFirmwareRequest",
+ "type": "object",
+ "properties": {
+ "location": {
+ "type": "string",
+ "format": "uri"
+ },
+ "retries": {
+ "type": "number"
+ },
+ "retrieveDate": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "retryInterval": {
+ "type": "number"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["location", "retrieveDate"]
+}
+```
+
+Corrected
+
+```txt
+{
+"\$"schema": "http://json-schema.org/draft-04-schema#"， "title": "UpdateFirmwareRequest"， "type": "object"， "properties": { "location": { "type": "string", "format": "uri" }, "retries": { "type": "integer" }, "retrieveDate": {
+```
+
+```txt
+"type": "string", "format": "date-time" }, "retryInterval": { "type": "integer" } }, "additionalProperties": false, "required": [ "location", "retrieveDate" ] }
+```
+
+# 2.6. StopTransaction.json "reason" incorrectly required
+
+The OCPP 1.6 JSON schema message definitions set, as originally published, contain an error that renders it inconsistent with both the written OCPP 1.6 specification and the SOAP/XML Schema/WSDLs schema definitions. In the StopTransactionRequest message structure (StopTransaction.json), the "reason" element is incorrectly marked as being "required", whereas the human-readable protocol specification document and the SOAP WSDL service definition file both explicitly define it to be "optional", with an explicitly defined implied default value ("Local"), as stated in Sections 4.10 (p46) and 6.49 (p82) of the OCPP 1.6 Specification.
+
+We advise implementers of an OCPP 1.6 JSON to remove the "reason" field from the list of required fields at the bottom of the file, or download the correct set of JSON schema from the OCA website.
+
+To the best understanding of the TWG, the only case where any existing OCPP 1.6 implementation would be impacted by this correction is when a Central System implementation currently enforces the "required" status of "reason" in received JSON StopTransaction requests, and is controlling a network containing Charge Points that are using OCPP 1.6 JSON, but omitting the StopTransaction "reason", as is allowed by the specification.
+
+# 3. Minor errata
+
+Improvements to the descriptions on how the protocol (should) work.
+
+# 3.1. Page 11 - (2025-04) - Section 4.1.4. Message ID - Improved text for unique message ID
+
+<table><tr><td>Old text</td><td>The message ID serves to identify a request. A message ID for a CALL message MUST be different from all message IDs previously used by the same sender for CALL messages on the same WebSocket connection. 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.</td></tr><tr><td>New text</td><td>The message ID serves to identify a request. A message ID for a CALL message MUST be different from all message IDs previously used by the same sender for CALL messages on any WebSocket connection using the same unique Charging Station identifier. The message ID for a retrieved message (e.g. when no response was received within timeout) MAY be identical to the message ID of the original message. 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.</td></tr></table>
+
+# 3.2. JSON Schema files do allow for extra fields within inner objects.
+
+It is not allowed to add extra fields/values to OCPP messages, this could cause interoperability issues in the field.
+
+The WSDL files are correct, the original JSON Schema files allow extra fields on inner objects and extra values on enums, which was not intended.
+
+Most of the JSON Schema files have been updated to fix this. The line: "additionalProperties": false has been added to the definition of all object and enum definitions.
+
+# 3.3. No definition of: 'failure to process the message'
+
+The OCPP 1.6 spec points to the OCPP-J spec for a definition on how a JSON implementation should respond to a request to indicate: 'failure to process message', but there was no definition of: 'failure to process the message' in the OCPP-J spec.
+
+To following text should be added to: Page 9, par 3.2:
+
+"For a definition on how a server SHALL report a 'failure to process the message', see: CallError"
+
+To following text should be added to: Page 13, par 4.2.3:
+
+"When a server needs to report a 'failure to process the message', the server SHALL use a Message Type: CallError (MessageTypeNumber = 4)."
+
+# 3.4. Page 8, section: 3.2: Missing Charge Point should retry after having received HTTP 404.
+
+When a Charge Point tries to connect the a Central System, the Central System, when it does not know the Charge Point might reject the connection by responding with HTTP 404 as defined in Section 3.2.
+
+The Charge Point is then expected to retry the connection every X times, same as with the BootNotification, but this is not specified.
+
+Addition text for the first bullet in Section 3.2
+
+Additional text
+
+The Charge Point SHALL retry with an appropriate back-off mechanism to prevent overloading the Central System.
+
+# 3.5. Page 10, section: 4.1.1: Synchronicity explanation can be improved
+
+Not clear to all implementers that the Central System does not have to wait for a response from Charging Station 1 when sending something to Charging Station 2.
+
+The following is to be added at the end of the first paragraph
+
+Additional text
+
+This does not mean that the Central System cannot send a message to another Charge Point, while waiting for a response of a first Charge Point, this rule is per OCPP-J connection.
+
+# 3.6. Page 10, par 4.1.3: 'Client-to-Server' and 'Server-to-Client' is confusing.
+
+The table on page 9 contains a definition of the 3 different types of messages in the OCPP RPC framework. But the direction is confusing. With WebSockets, on the WebSocket level, the Central System is always the Server.
+
+<table><tr><td>Old text</td><td>New text</td></tr><tr><td>Direction</td><td>Description</td></tr><tr><td>Client-to-Server</td><td>Request message</td></tr><tr><td>Server-to-Client (CALLRESULT)</td><td>Response message</td></tr><tr><td>Server-to-Client (CALLERROR)</td><td>Error response to a request message</td></tr></table>
+
+# 3.7. Page 11, Section 4.1.4. The message ID must be unique [DRAFT]
+
+Below text uses the wording 'on the same WebSocket connection', however this can be interpreted in multiple ways. It was intended to mean that the msgageld must be different from all msgagelds previously used by the same sender for any other CALL message on any WebSocket connection with the same 'connection URL' as defined by section 3.1.1. The connection URL. The current wording seems to indicate that it may use the same msgageld after every reconnect, however this may cause major issues. Especially when looking at the OCPP message queuing mechanisms.
+
+# Old text:
+
+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 same WebSocket connection. 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 1. Unique Message ID
+
+<table><tr><td>NAME</td><td>DATATYPE</td><td>RESTRICTIONS</td></tr><tr><td>messageld</td><td>string</td><td>Unique message ID, maximum length of 36 characters, to allow for UUIDs/GUIDs</td></tr></table>
+
+# New text:
+
+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 with the same 'connection URL' as defined by section 3.1.1. The connection URL. 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 2. Unique Message ID
+
+<table><tr><td>NAME</td><td>DATATYPE</td><td>RESTRICTIONS</td></tr><tr><td>messageId</td><td>string</td><td>Unique message ID, maximum length of 36 characters, to allow for UUIDs/GUIDs</td></tr></table>
+
+# 3.8. Page 11, par 4.2: No reference to the JSON Schemas
+
+The OCPP-J Spec has no reference to the JSON Schemas and schema version.
+
+Additional reference in 1.6 references on page 3:
+
+[JSON_SCHEMA]
+
+http://json-schema.org/
+
+Additional text:
+
+4.2.4 Schemas Together with this document, there are also JSON Schema files provided. These schemas can be used for validation of OCPP-J messages.
+
+The OCPP-J 1.6 Schema files are [JSON_SCHEMA] draft-04 schemas.
+
+# 3.9. Page 14, section: 4.2.3: No example of CallError
+
+There is no example of a CallError in the document, the following is an example.
+
+```json
+[4, "162376037", "NotSupported", "SendLocalList.req not implemented", {}]
+```
+
+# 3.10. Page 15, section: 5: Explanation how to respond to message before Charge Point is accepted.
+
+There is no explanation for how a Central System should respond to any CALL message from the Charge Point (other then BootNotification.req) before being accepted by the Central System.
+
+Additional section
+
+5.6 Charge Point CALL message before accepted
+
+When a Central System receives CALL messages (other then BootNotification) from a Charge Point before the Charge Point is
+
+accepted, the Central System is RECOMMENDED to respond with and RPC CallError: SecurityError.
+
+# 3.11. Page 20, section: 7: How to handle half open connections not clear
+
+It can sometimes happen that WebSockets connections are not opened or closed correctly. When this happens, a WebSocket ping should detect this and cause a WebSocket to be closed. By sending WebSockets pings at a regular interval, it should never happen that messages are dropped because of a half open connection.
+
+<table><tr><td>Additional text</td><td>Recommended to configure: WebSocketPingInterval smaller then: TransactionMessageAttempts * TransactionMessageRetryInterval.</td></tr></table>
+
+# 3.12. Page 20, section: 7: Missing configurationKey: AuthorizationKey
+
+On page 17, a ConfigKey is named, but it is not listed in the list on page 20:
+
+New text:
+
+<table><tr><td>KEY</td><td>VALUE</td></tr><tr><td rowspan="3">AuthorizationKey</td><td>String</td></tr><tr><td>WriteOnly</td></tr><tr><td>Hexadecimal representation of the password that the Charging Station uses to authenticate itself if HTTP Basic authentication is used. Maximum string length is 40 characters. This configuration key is write-only, so that it cannot be accidentally stored in plaintext by the Central System when it reads out all configuration keys.</td></tr></table>
+
+# 4. Typos
+
+Typos, fixes to incorrect links/reference, improve terms used etc. that have no impact on the description of the way the protocol works.
+
+None known
+
+# 5. Known issues that will not be fixed
+
+# 5.1. Page 14, par 4.2.3: CallError: Tipo in enum
+
+Typo in enum: OccurrenceConstraintViolation
+
+<table><tr><td>Old text</td><td>OccurrenceConstraintViolation</td></tr><tr><td>New text</td><td>OccurrenceConstraintViolation</td></tr></table>
+
+Do not fix, this is a message level change, might break implementations
+
+Note: In the next version of OCPP we will add the correct spelling and make the incorrect (typo) value deprecated.
+
+# 5.2. Page 14, par 4.2.3. CallError: incorrect name in enum: FormationViolation
+
+Incorrect name in enum: FormationViolation
+
+<table><tr><td>Old text</td><td>FormationViolation</td></tr><tr><td>New text</td><td>FormatViolation</td></tr></table>
+
+Do not fix, this is a message level change, might break implementations
+
+Note: In the next version of OCPP we will add the correct spelling and make the incorrect (typo) value deprecated.
--- /dev/null
+# Open Charge Point Protocol JSON 1.6, OCPP-J 1.6 Specification
+
+# Table of Contents
+
+1. Introduction. 4
+
+1.1. Purpose of this document 4
+1.2. Intended audience 4
+1.3. OCPP-S and OCPP-J 4
+1.4. Conventions 4
+1.5. Definitions & Abbreviations 4
+1.6. References 5
+
+2. Benefits & Issues. 6
+
+3. Connection 6
+
+3.1. Client request. 6
+3.2. Server response 8
+3.3. More information 9
+
+4. RPC framework. 9
+
+4.1. Introduction 9
+4.2. Message structures for different message types 11
+
+5. Connection 14
+
+5.1. Compression 14
+5.2. Data integrity. 14
+5.3. WebSocket Ping in relation to OCPP Heartbeat 14
+5.4. Reconnecting 15
+5.5. Network node hierarchy 15
+
+6. Security 15
+
+6.1. Network-level security 15
+6.2. OCPP-J over TLS 15
+
+7. Configuration 20
+
+<table><tr><td>Document Version</td><td>1.6</td></tr><tr><td>Document Status</td><td>FINAL</td></tr><tr><td>Document Release Date</td><td>2015-10-08</td></tr></table>
+
+Copyright © 2010 - 2015 Open Charge Alliance. All rights reserved.
+
+This document is made available under the _Creative Commons Attribution-NoDerivatives 4.0 International License_
+
+(https://creativecommons.org/licenses/by-nd/4.0/legalcode).
+
+Version History
+
+<table><tr><td>Version</td><td>Date</td><td>Author</td><td>Description</td></tr><tr><td>1.6</td><td>2015-10-08</td><td>Patrick Rademakers Reinier Lamers Robert de Leeuw</td><td>Updated to 1.6 Asciidoc formatting, remove JSON schema for 1.5 Some clarification Added 1.5 json schema</td></tr></table>
+
+# Contents
+
+# 1. Introduction
+
+# 1.1. Purpose of this document
+
+The purpose of this document is to give the reader the information required to create a correct interoperable OCPP JSON implementation (OCPP-J). We will try to explain what is mandatory, what is considered good practice and what one should not do, based on our own experience. Undoubtedly misunderstandings or ambiguities will remain but by means of this document we aim to prevent them as much as possible.
+
+# 1.2. Intended audience
+
+This document is intended for developers looking to understand and/or implement OCPP JSON in a correct and interoperable way. Rudimentary knowledge of implementing web services on a server or embedded device is assumed.
+
+# 1.3. OCPP-S and OCPP-J
+
+With the introduction of OCPP 1.6, there are two different flavours of OCPP; next to the SOAP based implementations, there is the possibility to use the much more compact JSON alternative. To avoid confusion in communication on the type of implementation we recommend using the distinct suffixes -J and -S to indicate JSON or SOAP. In generic terms this would be OCPP-J for JSON and OCPP-S for SOAP. Version specific terminology would be OCPP1.6J or OCPP1.2S. If no suffix is specified for OCPP 1.2 or 1.5 then a SOAP implementation must be assumed. As of release 1.6 this can no longer be implicit and should always be made clear. If a system supports both the JSON and SOAP variant it is considered good practice to label this OCPP1.6JS instead of just OCPP1.6.
+
+This document describes OCPP-J, for OCPP-S see: [OCPP_IMP_S]
+
+# 1.4. Conventions
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
+
+# 1.5. Definitions & Abbreviations
+
+<table><tr><td>IANA</td><td>Internet Assigned Numbers Authority (www.iana.org).</td></tr><tr><td>OCPP-J</td><td>OCPP communication over WebSocket using JSON. Specific OCPP versions should be indicated with the J extension. OCPP1.5J means we are talking about a JSON/WebSocket implementation of 1.5.</td></tr><tr><td>OCPP-S</td><td>OCPP communication over SOAP and HTTP(S). As of version 1.6 this should explicitly mentioned. Older versions are assumed to be S unless clearly specified otherwise, e.g. OCPP1.5 is the same as OCPP1.5S</td></tr><tr><td>RPC</td><td>Remote procedure call</td></tr><tr><td>WAMP</td><td>WAMP is an open WebSocket subprotocol that provides messaging patterns to handle asynchronous data.</td></tr></table>
+
+# 1.6. References
+
+<table><tr><td>[JSON]</td><td>http://www.json.org/</td></tr><tr><td>[OCPP_IMP_S]</td><td>OCPP SOAP implementation specification</td></tr><tr><td>[RFC2119]</td><td>“Key words for use in RFCs to Indicate Requirement Levels”. S. Bradner. March 1997. http://www.ietf.org/rfc/rfc2119.txt</td></tr><tr><td>[RFC2616]</td><td>“Hypertext Transfer Protocol — HTTP/1.1”. http://tools.ietf.org/html/rfc2616</td></tr><tr><td>[RFC2617]</td><td>“HTTP Authentication: Basic and Digest Access Authentication”. http://tools.ietf.org/html/rfc2617</td></tr><tr><td>[RFC3629]</td><td>“UTF-8, a transformation format of ISO 10646”. http://tools.ietf.org/html/rfc3629</td></tr><tr><td>[RFC3986]</td><td>“Uniform Resource Identifier (URI): Generic Syntax”. http://tools.ietf.org/html/rfc3986</td></tr><tr><td>[RFC5246]</td><td>“The Transport Layer Security (TLS) Protocol; Version 1.2”. http://tools.ietf.org/html/rfc5246</td></tr><tr><td>[RFC6455]</td><td>“The WebSocket Protocol”. http://tools.ietf.org/html/rfc6455</td></tr><tr><td>[WAMP]</td><td>http://wamp.ws/</td></tr><tr><td>[WIKIWS]</td><td>http://en.wikipedia.org/wiki/WebSocket</td></tr><tr><td>[WS]</td><td>http://www.websocket.org/</td></tr></table>
+
+# 2. Benefits & Issues
+
+The WebSocket protocol is defined in [RFC6455]. Working implementations of earlier draft WebSocket specifications exist, but OCPP-J implementations SHOULD use the protocol described in [RFC6455].
+
+Be aware that WebSocket defines its own message structure on top of TCP. Data sent over aWebSocket, on a TCP level, is wrapped in a WebSocket frame with a header. When using a framework this is completely transparent. When working for an embedded system however, WebSocket libraries may not be available and then one has to frame messages correctly according to [RFC6455] him/herself.
+
+# 3. Connection
+
+For the connection between a Charge Point and a Central System using OCPP-J, the Central System acts as a WebSocket server and the Charge Point acts as a WebSocket client.
+
+# 3.1. Client request
+
+To set up a connection, the Charge Point initiates a WebSocket connection as described in [RFC6455] section 4, "Opening Handshake".
+
+OCPP-J imposes extra constraints on the URL and the WebSocket subprotocol, detailed in the following two sections 4.1.1 and 4.1.2.
+
+# 3.1.1. The connection URL
+
+To initiate a WebSocket connection, the Charge Point needs a URL ([RFC3986]) to connect to. This URL is henceforth called the "connection URL". This connection URL is specific to a charge point. The charge point's connection URL contains the charge point identity so that the Central System knows which charge point a WebSocket connection belongs to.
+
+A Central System supporting OCPP-J MUST provide at least one OCPP-J endpoint URL, from which the Charge Point SHOULD derive its connection URL. This OCPP-J endpoint URL can be any URL with a "ws" or "wss" scheme. How the Charge Point obtains an OCPP-J endpoint URL is outside of the scope of this document.
+
+To derive its connection URL, the Charge Point modifies the OCPP-J endpoint URL by appending to the path first a '/' (U+002F SOLIDUS) and then a string uniquely identifying the Charge Point. This uniquely identifying string has to be percent-encoded as necessary as described in [RFC3986].
+
+Example 1: for a charge point with identity “CP001” connecting to a Central System with OCPP-J endpoint URL "ws://centralsystem.example.com/ocpp" this would give the following connection URL:
+
+ws://centralsystem.example.com/ocpp/CP001
+
+Example 2: for a charge point with identity "RDAM 123" connecting to a Central System with OCPP-J endpoint URL "wss://centralsystem.example.com/ocppj" this would give the following URL:
+
+wss://centralsystem.example.com/ocppj/RDAM%20123
+
+# 3.1.2.OCPP version
+
+The exact OCPP version MUST be specified in the Sec-Websocket-Protocol field. This SHOULD be one of the following values:
+
+Table 1:OCPP Versions
+
+<table><tr><td>OCPP version</td><td>WebSocket subprotocol name</td></tr><tr><td>1.2</td><td>ocpp1.2</td></tr><tr><td>1.5</td><td>ocpp1.5</td></tr><tr><td>1.6</td><td>ocpp1.6</td></tr><tr><td>2.0</td><td>ocpp2.0</td></tr></table>
+
+The ones for OCPP 1.2, 1.5 and 2.0 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.
+
+# 3.1.3. Example of an opening HTTP request
+
+The following is an example of an opening HTTP request of an OCPP-J connection handshake:
+
+GET /webServices/ocpp/CP3211 HTTP/1.1
+
+Host: some.server.com:33033
+
+Upgrade: websocket
+
+Connection: Upgrade
+
+Sec-WebSocket-Key: x3JJHMcDL1EzLkh9GBhXDw==
+
+Sec-WebSocket-Protocol: ocpp1.6, ocpp1.5
+
+Sec-WebSocket-Version: 13
+
+The bold parts are found as such in every WebSocket handshake request, the other parts are specific to this example.
+
+In this example, the Central System's OCPP-J endpoint URL is
+
+"ws://some.server.com:33033/webServices/ocpp". The Charge Point's unique identifier is "CP3211", so the path to request becomes "webServices/ocpp/CP3211".
+
+With the Sec-WebSocket-Protocol header, the Charge Point indicates here that it can use OCPP1.6J and OCPP1.5J, with a preference for the former.
+
+The other headers in this example are part of the HTTP and WebSocket protocols and are not relevant to those implementing OCPP-J on top of third-party WebSocket libraries. The roles of these headers are explained in [RFC2616] and [RFC6455].
+
+# 3.2. Server response
+
+Upon receiving the Charge Point's request, the Central System has to finish the handshake with a response as described in [RFC6455].
+
+The following OCPP-J-specific conditions apply:
+
+- If the Central System does not recognize the charge point identifier in the URL path, it SHOULD send an HTTP response with status 404 and abort the WebSocket connection as described in [RFC6455].
+- If the Central System does not agree to using one of the subprotocols offered by the client, it MUST complete the WebSocket handshake with a response without a Sec-WebSocket-Protocol header and then immediately close the WebSocket connection.
+
+So if the Central System accepts the above example request and agrees to using OCPP 1.6J with the Charge Point, the Central System's response will look as follows:
+
+HTTP/1.1 101 Switching Protocols
+
+Upgrade: WebSocket
+
+Connection: Upgrade
+
+Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
+
+Sec-WebSocket-Protocol: ocpp1.6
+
+The bold parts are found as such in every WebSocket handshake response, the other parts are specific to this example.
+
+The role of the Sec-WebSocket-Accept header is explained in [RFC6455].
+
+The Sec-WebSocket-Protocol header indicates that the server will be using OCPP1.6J on this connection.
+
+# 3.3. More information
+
+For those doing their own implementation of the WebSocket handshake, [WS] and [WIKIWS] give more information on the WebSocket protocol.
+
+# 4. RPC framework
+
+# 4.1. Introduction
+
+A WebSocket is a full-duplex connection, simply put a pipe where data goes in and data can come out and without a clear relation between in and out. The WebSocket protocol by itself provides no way to relate messages as requests and responses. To encode these request/response relations we need a small protocol on top of WebSocket. This problem occurs in more use cases of WebSocket so there are existing schemes to solve it. The most widely-used is WAMP (see [WAMP]) but with the current version of that framework handling RPCs symmetrically is not WAMP compliant. Since the required framework is very simple we decided to define our own framework, inspired by WAMP, leaving out what we do not need and adding what we find missing.
+
+Basically what we need is very simple: we need to send a message (CALL) and receive a reply (CALLRESULT) or an explanation why the message could not be handled properly (CALLERROR). For possible future compatibility we will keep the numbering of these message in sync with WAMP. Our actual OCPP message will be put into a wrapper that at least contains the type of message, a unique message ID and the payload, the OCPP message itself.
+
+# 4.1.1. Synchronicity
+
+A Charge Point or Central System SHOULD NOT send a CALL message to the other party unless all the CALL messages it sent before have been responded to or have timed out. A CALL message has been responded to when a CALLERROR or CALLRESULT message has been received with the message ID of the CALL message.
+
+A CALL message has timed out when:
+
+- it has not been responded to, and
+- an implementation-dependent timeout interval has elapsed since the message was sent.
+
+Implementations are free to choose this timeout interval. It is RECOMMENDED that they take into account the kind of network used to communicate with the other party. Mobile networks typically have much longer worst-case round-trip times than fixed lines.
+
+# NOTE
+
+The above requirements do not rule out that a Charge Point or Central System will receive a CALL message from the other party while it is waiting for a CALLERROR or CALLRESULT. Such a situation is difficult to prevent because CALL messages from both sides can always cross each other.
+
+# 4.1.2. Character encoding
+
+The whole message consisting of wrapper and payload MUST be valid JSON encoded with the UTF-8 (see [RFC3629]) character encoding.
+
+Note that all valid US-ASCII text is also valid UTF-8, so if a system sends only US-ASCII text, all messages it sends comply with the UTF-8 requirement. A Charge Point or Central System SHOULD only use characters not in US-ASCII for sending natural-language text. An example of such natural-language text is the text in the LocalizedText type in OCPP 2.0.
+
+# 4.1.3. The message type
+
+To identify the type of message one of the following Message Type Numbers MUST be used.
+
+Table 2: Message types
+
+<table><tr><td>MessageType</td><td>MessageTypeNumber</td><td>Direction</td></tr><tr><td>CALL</td><td>2</td><td>Client-to-Server</td></tr><tr><td>CALLRESULT</td><td>3</td><td>Server-to-Client</td></tr><tr><td>CALLERROR</td><td>4</td><td>Server-to-Client</td></tr></table>
+
+When a server receives a message with a Message Type Number not in this list, it SHALL ignore the message payload. Each message type may have additional required fields.
+
+# 4.1.4. The message ID
+
+The message ID serves to identify a request. A message ID for a CALL message MUST be different from all message IDs previously used by the same sender for CALL messages on the same WebSocket connection. 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 3: Unique Message ID
+
+<table><tr><td>Name</td><td>Datatype</td><td>Restrictions</td></tr><tr><td>messageId</td><td>string</td><td>Maximum of 36 characters, to allow for GUIs</td></tr></table>
+
+# 4.2. Message structures for different message types
+
+# NOTE
+
+You may find the charge point identity missing in the following paragraphs. The identity is exchanged during the WebSocket connection handshake and is a property of the connection. Every message is sent by or directed at this identity. There is therefore no need to repeat it in each message.
+
+# 4.2.1. Call
+
+A Call always consists of 4 elements: The standard elements MessageTypeDef and UniqueId, a specific Action that is required on the other side and a payload, the arguments to the Action. The syntax of a call looks like this:
+
+[ \langle MessageTypeError \rangle, \langle UniqueId \rangle, \langle Action \rangle, \{ \langle Payload \} \} ]
+
+Table 4: Call Fields
+
+<table><tr><td>Field</td><td>Meaning</td></tr><tr><td>UniqueId</td><td>this is a unique identifier that will be used to match request and result.</td></tr><tr><td>Action</td><td>the name of the remote procedure or action. This will be a case-sensitive string containing the same value as the Action-field in SOAP-based messages, without the preceding slash.</td></tr><tr><td>Payload</td><td>Payload is a JSON object containing the arguments relevant to the Action. If there is no payload JSON allows for two different notations: null or and empty object {}. Although it seems trivial we consider it good practice to only use the empty object statement. Null usually represents something undefined, which is not the same as empty, and also {}. is shorter.</td></tr></table>
+
+For example, a BootNotification request could look like this:
+
+```json
+[
+ 2,
+ "19223201",
+ "BootNotification",
+ { "chargePointVendor": "VendorX", "chargePointModel": "SingleSocketCharger" }
+]
+```
+
+# 4.2.2. CallResult
+
+If the call can be handled correctly the result will be a regular CallResult. Error situations that are covered by the definition of the OCPP response definition are not considered errors in this context. They are regular results and as such will be treated as a normal CallResult, even if the result is undesirable for the recipient.
+
+A CallResult always consists of 3 elements: The standard elements MessageTypeError and UniqueId and a payload, containing the response to the Action in the original Call. The syntax of a call looks like this:
+
+[ \left[ <\text{MessageTypeId}>, "<\text{UniqueId}>" \right], \left\{\langle\text{Payload}\rangle \right] ]
+
+Table 5: CallResult Fields
+
+<table><tr><td>Field</td><td>Meaning</td></tr><tr><td>UniqueId</td><td>This must be the exact same ID that is in the call request so that the recipient can match request and result.</td></tr><tr><td>Payload</td><td>Payload is a JSON object containing the results of the executed Action. If there is no payload JSON allows for two different notations: null or and empty object {}. Although it seems trivial we consider it good practice to only use the empty object statement. Null usually represents something undefined, which is not the same as empty, and also {}. is shorter.</td></tr></table>
+
+For example, a BootNotification response could look like this:
+
+```jsonl
+[
+ 3,
+ "19223201",
+ {
+ "status": "Accepted",
+ "currentTime": "2013-02-01T20:53:32.486Z",
+ "heartbeatInterval": 300
+ }
+]
+```
+
+# 4.2.3. CallError
+
+We only use CallError in two situations:
+
+1. An error occurred during the transport of the message. This can be a network issue, an availability of service issue, etc.
+2. The call is received but the content of the call does not meet the requirements for a proper message. This could be missing mandatory fields, an existing call with the same unique identifier is being handled already, unique identifier too long, etc.
+
+A CallError always consists of 5 elements: The standard elements MessageTypeError and UniqueId, an errorCode string, an errorDescription string and an errorDetails object. The syntax of a call looks like this:
+
+[ \text{[<MessageTypeId>}, \text{"<UniqueId>"} \text{"<errorCode>"} \text{"<errorDescription>"} \text{, {<errorDetails>}}\} ]
+
+Table 6: CallError Fields
+
+<table><tr><td>Field</td><td>Meaning</td></tr><tr><td>UniqueId</td><td>This must be the exact same id that is in the call request so that the recipient can match request and result.</td></tr><tr><td>ErrorCode</td><td>This field must contain a string from theErrorCode table below.</td></tr><tr><td>Description</td><td>Should be filled in if possible, otherwise a clear empty string “”.</td></tr><tr><td>ErrorDetails</td><td>This JSON object describes error details in an undefined way. If there are no error details you MUST fill in an empty object {}.</td></tr></table>
+
+Table 7: Valid Error Codes
+
+<table><tr><td>Error Code</td><td>Description</td></tr><tr><td>NotImplemented</td><td>Requested Action is not known by receiver</td></tr><tr><td>NotSupported</td><td>Requested Action is recognized but not supported by the receiver</td></tr><tr><td>InternalError</td><td>An internal error occurred and the receiver was not able to process the requested Action successfully</td></tr><tr><td>ProtocolError</td><td>Payload for Action is incomplete</td></tr><tr><td>SecurityError</td><td>During the processing of Action a security issue occurred preventing receiver from completing the Action successfully</td></tr><tr><td>FormationViolation</td><td>Payload for Action is syntactically incorrect or not conform the PDU structure for Action</td></tr><tr><td>PropertyConstraintViolation</td><td>Payload is syntactically correct but at least one field contains an invalid value</td></tr><tr><td>OccurrenceConstraintViolation</td><td>Payload for Action is syntactically correct but at least one of the fields violates occurrence constraints</td></tr><tr><td>TypeConstraintViolation</td><td>Payload for Action is syntactically correct but at least one of the fields violates data type constraints (e.g. “somestring”: 12)</td></tr><tr><td>GenericError</td><td>Any other error not covered by the previous ones</td></tr></table>
+
+# 5. Connection
+
+# 5.1. Compression
+
+Since JSON is very compact we recommend not to use compression in any other form than allowed as part of the WebSocket [RFC6455] specification. Otherwise it may compromise interoperability.
+
+# 5.2. Data integrity
+
+For data integrity we rely on the underlying TCP/IP transport layer mechanisms.
+
+# 5.3. WebSocket Ping in relation to OCPP Heartbeat
+
+The WebsSocket specification defines Ping and Pong frames that are used to check if the remote endpoint is still responsive. In practice this mechanism is also used to prevent the network operator from quietly closing the underlying network connection after a certain period of inactivity. This websocket feature can be used as a substitute for most of the OCPP Heartbeat messages, but cannot
+
+replace all of its functionality.
+
+An important aspect of the Heartbeat response is time synchronisation. The Ping and Pong frames cannot be used for this so at least one original Heartbeat message a day is recommended to ensure a correct clock setting on the Charge Point.
+
+# 5.4. Reconnecting
+
+When reconnecting a charge point should not send a BootNotification unless one or more of the elements in the BootNotification have changed since the last connection. For the previous SOAP based solutions this was considered good practice but when using WebsSocket the server can already make the match between the identity and a communication channel at the moment the connection is established. There is no need for an additional message.
+
+# 5.5. Network node hierarchy
+
+The physical network topology is not influenced by a choice for JSON or SOAP. In case of JSON however the issues with Network Address Translation (NAT) have been resolved by letting the Charge Point open a TCP connection to the Central System and keeping this connection open for communication initiated by the Central System. It is therefore no longer necessary to have a smart device capable of interpreting and redirecting SOAP calls in between the Central System and the Charge Point.
+
+# 6. Security
+
+Two approaches exist for security with OCPP-J. Either one can rely on network-level security, or one uses OCPP-J over TLS. Both approaches are described below.
+
+It is important that at all times, one of these approaches is used. Practically, this means that a Central System SHOULD NOT listen for incoming unencrypted OCPP-J connections from the internet.
+
+# 6.1. Network-level security
+
+For security one MAY rely on the security at a network level. This has historically been done with OCPP-S, and on networks that are set up appropriately one can also use OCPP-J without additional encryption or authentication measures.
+
+# 6.2. OCPP-J over TLS
+
+Sometimes however a secured network is not available between Charge Point and Central System. In that case one can use OCPP-J over TLS. This section explains how this is done.
+
+The security needed for OCPP communication actually consists of two separate features: encryption and charge point authentication.
+
+Encryption means that the OCPP messages are encrypted so no unauthorized third party can see the messages exchanged.
+
+Charge point authentication means that Central System can verify the identity of a charge point, so that no unauthorized third party can pretend to be a charge point and send malicious messages to a central system.
+
+# 6.2.1. Encryption
+
+The industry standard for encryption on the internet is Transport Layer Security (TLS) [RFC5246]. Therefore OCPP is also adopting protocol for encrypting the connection between Central System and Charge Point. TLS with WebSocket is widely supported by libraries and for clients should be hardly more difficult than using unencrypted WebSocket.
+
+When using TLS, the central system MAY also provide a signed certificate that a charge point can use to verify the central system's identity.
+
+As some Charge Point implementations are using embedded systems with limited computing resources, we impose an additional restriction on the TLS configuration on the server side:
+
+- The TLS certificate SHALL be an RSA certificate with a size no greater than 2048 bytes
+
+# 6.2.2. Charge point authentication
+
+For authentication, OCPP-J over TLS uses the HTTP Basic authentication scheme ([RFC2617]). The relatively simple HTTP Basic authentication can be used because the connection is already TLS-encrypted, so there is no need to encrypt the credentials a second time.
+
+When using HTTP Basic authentication, the client, i.e. the Charge Point, has to provide a username and password with its request. The username is equal to the charge point identity, which is the identifying string of the charge point as it uses it in the OCPP-J connection URL. The password is a 20-byte key that is stored on the charge point.
+
+# Example
+
+If we have a charge point with:
+
+- charge point identity "AL1000"
+- authorization key 0001020304050607FFFFFFCCCCCCCCCCCC
+
+the HTTP authorization header should be:
+
+Authorization: Basic QUwxxMDAwOgABAgMEBQYH////
+
+# A note on encryption
+
+The authentication mechanism via HTTP Basic Authentication is meant to be used on TLS-encrypted
+
+connections. Using this mechanism on an unencrypted connection means that anyone who can see the network traffic between Charge Point and Central System can see the charge point credentials, and can thus impersonate the Charge Point.
+
+# Setting the charge point's credentials
+
+For this charge point authentication scheme, the charge point needs to have an authentication key. This authentication key has to be transferred onto the charge point in some way. What is a good way depends on the business model of the charge point manufacturer and central system operator.
+
+# Setting during or before installation
+
+The desired, secure situation is that every charge point has its own, unique authorization key. If an authorization key is not unique, an attacker who discovers the authorization key of a single charge point can impersonate many or even all charge points in an operator's Central System.
+
+The simplest way to achieve this is to install the authorization key on the charge point during manufacture or installation. In these cases, the key will be securely communicated between the central system operator and installer or manufacturer by communication channels outside of OCPP. This scenario is secure because the key is not sent over the channel it is meant to secure, so an attacker eavesdropping the connection between Charge Point and Central System cannot impersonate the Charge Point.
+
+# Setting the key over OCPP
+
+If the processes of manufacturing, sale and installation of a charge point are not under the central system operator's control, there is no way to put a unique key on each individual charge point and also make sure the central system operator knows these keys and the charge points they belong to. For such scenarios, it is desirable for all charge points of a series to have the same "master" key when they leave the factory and are installed, or to have keys that are derived from the charge point identity by the same algorithm. Still the Central System operator will want to keep adversaries from impersonating all charge points of a series if the master key is leaked. For this use case, there is a possibility for the Central System to send a unique key to the charge point via OCPP after charge point installation.
+
+To set a charge point's authorization key via OCPP, the Central System SHALL send the Charge Point a ChangeConfiguration.req message with the key AuthorizationKey and as the value a 40-character hexadecimal representation of the 20-byte authorization key. If the Charge Point responds to this ChangeConfiguration.req with a ChangeConfiguration.conf with status Accepted, the Central System SHALL assume that the authorization key change was successful, and no longer accept the credentials previously used by the charge point. If the Charge Point responds to the ChangeConfiguration.req with a ChangeConfiguration.conf with status Rejected or NotSupported, the Central System SHALL keep accepting the old credentials. While the Central System SHALL still accept an OCPP-J connection from the Charge Point in this case, it MAY treat the Charge Point's OCPP messages differently, e.g. by not accepting the Charge Point's boot notifications.
+
+sd Onboarding a charge point, setting a new authorization key
+
+
+
+The charge point should not give back the authorization key in response to a GetConfiguration request. It can either not report the AuthorizationKey key at all or give back a value that is not related to the actual authorization key.
+
+Note that while sending a key over the channel to be secured is normally considered a bad practice, we believe it is appropriate here to at least offer the possibility to do so. Typically the authorization key will be set when a charge point is first 'on-boarded' in the central system. If the charge point then later produces the key that was set during on-boarding, it at least means this is the same system that connected during the on-boarding. While it may be possible to successfully on-board a spoofed new charge point to an adversary who knows the single "master" key for all new charge points, it is not
+
+possible to pretend to be an already-installed and operating charge point. This makes still makes a number of conceivable attacks impossible:
+
+- "reservation" of a charge point by spoofing messages marking it as occupied
+- marking your just-started session on a public charge point as stopped so you won't have to pay as much
+- sending many spoofed transactions and/or errors from already on-board charge points to confuse a central system operator's operations
+- send spoofed transactions with another person's token ID to the central system to incur financial damage to the token ID's owner
+
+It is RECOMMENDED that the Central System operator makes setting the authorization key part of a charge point onboarding procedure, using the new OCPP 1.6 Pending value of the registration status in BootNotification.conf. A newly-connecting Charge Point will first get a Pending registration status on its first BootNotification.conf. The Central System will then set the Charge Point's unique authorization key with a ChangeConfiguration.req. Only when this ChangeConfiguration.req has been responded to with a ChangeConfiguration.conf with a status of Accepted, will the Central System respond to a boot notification with an Accepted registration status.
+
+It is RECOMMENDED that the Central System operator checks for anomalies in the newly-connecting charge points. Thus he can try to detect if an attacker has managed to steal the master key or key derivation algorithm, and a list of registered charge point identities. For example, if the rate at which new charge points connect suddenly increases, this may indicate an attack.
+
+# Storing the credentials
+
+It is important that the credentials are stored on the Charge Point in such a way that they are not easily lost or reset. If the credentials are lost, erased or changed unilaterally, the Charge Point can no longer connect to the Central System and requires on-site servicing to install new credentials.
+
+On the Central System side, it is RECOMMENDED to store the authorization key hashed, with a unique salt, using a cryptographic hash algorithm designed for secure storage of passwords. This makes sure that if the database containing the charge points' authorization keys is leaked, the attackers still cannot authenticate as the charge points to the Central System.
+
+# 6.2.3. What it does and does not secure
+
+The scope of these security measures is limited to authentication and encryption of the connection between Charge Point and Central System. It does not address every current security issue in the EV Charging IT landscape.
+
+It does provide the following things:
+
+- authentication of the Charge Point to the Central System (using HTTP Basic Authentication)
+- encryption of the connection between Charge Point and Central System
+
+- authentication of the Central System to the Charge Point (with a TLS certificate)
+
+It does not provide:
+
+- A guarantee that the meter values are not tampered with between the meter and the Central System
+ Authentication of the driver
+- Protection against people physically tampering with a charge point
+
+# 6.2.4. Applicability to OCPP-S
+
+The approach of OCPP-J over TLS cannot be applied to OCPP-S. There are two reasons.
+
+Firstly, in OCPP-S a new TCP connection is created for every request-response exchange. One would thus have to do a new TLS handshake for each such request-response exchange, incurring a great bandwidth overhead.
+
+Secondly, in OCPP-S the Charge Point also acts as a server, and would thus need a server certificate. It would be a great administrative burden to keep track of so many server certificates and the charge points they belong to.
+
+# 7. Configuration
+
+The following items in OCPP Get/ChangeConfiguration messages are added to control JSON/WebSockets behaviour:
+
+Table 8: Additional OCPP Keys
+
+<table><tr><td>Key</td><td>Value</td></tr><tr><td>WebSocketPingInterval</td><td>integer A value of 0 disables client side websocket Ping / Pong. In this case there is either no ping / pong or the server initiates the ping and client responds with Pong. Positive values are interpreted as number of seconds between pings. Negative values are not allowed. ChangeConfiguration is expected to return a REJECTED result.</td></tr></table>
--- /dev/null
+# OCPP
+
+Copyright © 2010 - 2019 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
+
+<table><tr><td>VERSION</td><td>DATE</td><td>AUTHOR</td><td>DESCRIPTION</td></tr><tr><td>v1.0 Release</td><td>2019-12-04</td><td>Robert de Leeuw
+IHomer</td><td>Release of the OCPP-S errata sheet</td></tr></table>
+
+# 1. Scope
+
+This document contains errata on the OCPP 1.6-S specification (SOAP).
+
+# 1.1. Terminology and Conventions
+
+Underlined: when needed to clarify differences, they might be underlined.
+
+# 2. Major errata
+
+Non known
+
+# 3. Minor errata
+
+Improvements to the descriptions on how the protocol (should) work.
+
+# 3.1. Page 9, par 4. No definition of: 'failure to process the message'
+
+The OCPP 1.6 spec points to the OCPP-S spec for a definition on how a SOAP implementation should respond to a request to indicate: 'failure to process message', but there was no definition of: 'failure to process the message' in the OCPP-S spec.
+
+<table><tr><td>Old text</td><td>In cases where the receiving party (e.g. Charge Point or Central System) cannot process the request and the corresponding confirmation PDU does not have to ability to report the error, then the SOAP Fault Response Message SHOULD be used.</td></tr><tr><td>New text</td><td>In cases where the receiving party (e.g. Charge Point or Central System) cannot process the OCPP request and the corresponding confirmation PDU does not have to ability to report the error, the receiving party needs to report: 'failure to process the message'. In such a case, the receiving party SHALL use the SOAP Fault Response Message.</td></tr></table>
+
+# 3.2. Page 9, par 4. Contradiction in definition of resending 'transaction related messages'
+
+The OCPP 1.6 spec states:
+
+"It is permissible for the Charge Point to skip a transaction-related message if and only if the Central System repeatedly reports a `failure to process the message'."
+
+But the OCPP-S specification states:
+
+"If a sender receives a SOAP Fault Response from the receiver, the sender SHOULD NOT resend the same message."
+
+The following errata should fix this:
+
+<table><tr><td>Old text</td><td>If a sender receives a SOAP Fault Response from the receiver, the sender SHOULD NOT resend the same message.</td></tr><tr><td rowspan="2">New text</td><td>If a sender receives a SOAP Fault Response from the receiver, or a HTTP response with a status code indicating an error, the sender SHOULD NOT resend the same message, except transaction-related message, a Charge Point SHALL retry these a couple of times.</td></tr><tr><td>To determine if there is a 'failure to process the message', or a connection issue. The Charge Point SHALL send a simple proven message like a HeartBeat.req PDU. If the Charge Point does receive a HeartBeat.conf from the Central System it knows the problem is with the message itself: 'failure to process the message'.</td></tr></table>
+
+# 3.3. Page 9, par 4. Text about SubCode is not clear
+
+There is something written about SOAP Fault SubCodes, but that is not really clear and/or helpful.
+
+<table><tr><td>Old text</td><td>The following fault codes can be used by the service:Code, Reason and Value belong to the namespace "http://www.w3.org/2003/05SOAP-envelope".This example SubCode belongs to the namespace "urn://Ocpp/Cs/2015/10"[TABLE WITH SUBCODES]</td></tr><tr><td>New text</td><td>When the receiver needs to return a fault, the following SubCodes can be used inside the SOAP fault, to give more detail about the type of problem the receiver encountered:[TABLE WITH SUBCODES]Note about the namespaces of the different fields of a SOAP fault:Code, Reason and Value belong to the namespace "http://www.w3.org/2003/05SOAP-envelope".SubCode belongs to the namespace "urn:/Ocpp/Cs/2015/10"Note: The given SubCodes are part of the OCPP namespace, but are not (yet) part of the OCPP WSDL files. This might change in future versions. Client implementations SHALL accept any SubCode, not only the given list above.</td></tr></table>
+
+# 4. Typos
+
+Typos, fixes to incorrect links/reference, improve terms used etc. that have no impact on the description of the way the protocol works.
+
+Non known
+
+# 5. Known issues that will not be fixed
+
+Non known
--- /dev/null
+# Open Charge Point Protocol SOAP 1.6, OCPP-S 1.6 Specification
+
+# Table of Contents
+
+1. Introduction. 4
+
+1.1. Purpose of this document 4
+1.2. Intended audience 4
+1.3. OCPP-S and OCPP-J 4
+1.4. Conventions 4
+1.5. Definitions & Abbreviations 4
+1.6. References 5
+
+2. Binding to Transport Protocol 5
+
+3. SOAPHeader 5
+
+3.1. XML Declaration 6
+3.2. SOAP synchronicity 6
+3.3. Charge Point Identity 6
+3.4. Action 7
+3.5. MessageID. 7
+3.6. RelatesTo. 8
+3.7. From 8
+3.8. ReplyTo 8
+3.9. To 9
+
+4. Fault Response 9
+
+5. Mobile Networks 10
+
+6. Connection 11
+
+6.1. Compression 11
+6.2. Security 11
+
+7. SOAP specific OCPP requirements 11
+
+7.1. BootNotification 11
+
+8. WSDL. 11
+
+<table><tr><td>Document Version</td><td>1.6</td></tr><tr><td>Document Status</td><td>FINAL</td></tr><tr><td>Document Release Date</td><td>2015-10-08</td></tr></table>
+
+Copyright © 2010 - 2015 Open Charge Alliance. All rights reserved.
+
+This document is made available under the _Creative Commons Attribution-NoDerivatives 4.0 International License_
+
+(https://creativecommons.org/licenses/by-nd/4.0/legalcode).
+
+Version History
+
+<table><tr><td>Version</td><td>Date</td><td>Author</td><td>Description</td></tr><tr><td>1.6</td><td>2015-10-08</td><td>Patrick Rademakers Robert de Leeuw Reinier Lamers Christophe Giaume Olger Warnier</td><td>Updated to 1.6 Added description of BootNotification when reconnecting Added soap header section</td></tr></table>
+
+# Contents
+
+# 1. Introduction
+
+# 1.1. Purpose of this document
+
+The purpose of this document is to give the reader the information required to create a correct interoperable OCPP SOAP implementation (OCPP-S). We will try to explain what is mandatory, what's considered good practice and what you should not do, based on our own experience. Undoubtedly there will remain misunderstandings or ambiguities but by means of this document we aim to prevent them as much as possible.
+
+# 1.2. Intended audience
+
+This document is intended for developers looking to understand and/or implement OCPP SOAP in a correct and interoperable way. Rudimentary knowledge of implementing web services on a server or embedded device is assumed.
+
+# 1.3.OCPP-S and OCPP-J
+
+With the introduction of OCPP 1.6, there are two different flavours of OCPP; next to the SOAP based implementations, there is the possibility to use the much more compact JSON alternative. To avoid confusion in communication on the type of implementation we recommend using the distinct extensions J and S to indicate JSON or SOAP. In generic terms this would be OCPP-J for JSON and OCPP-S for SOAP. Version specific terminology would be OCPP1.6J or OCPP1.2S. If no extension is specified for OCPP 1.2 or 1.5 then a SOAP implementation must be assumed. As of release 1.6 this can no longer be implicit and should always be made clear. If a system supports both the JSON and SOAP variant it is considered good practice to label this OCPP1.6JS i.s.o. just OCPP1.6.
+
+This document describes OCPP-S, for OCPP-J see: [OCPP_IMP_J]
+
+# 1.4. Conventions
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
+
+# 1.5. Definitions & Abbreviations
+
+<table><tr><td>IANA</td><td>Internet Assigned Numbers Authority (www.iana.org).</td></tr><tr><td>OCPP-J</td><td>OCPP communication over WebSockets using JSON. Specific OCPP versions should be indicated with the J extension. OCPP1.6J means we are talking about a JSON/WebSockets implementation of 1.6.</td></tr><tr><td>OCPP-S</td><td>OCPP communication over SOAP and HTTP(s). As of version 1.6 this should explicitly mentioned. Older versions are assumed to be S unless clearly specified otherwise, e.g. OCPP1.5 is the same as OCPP1.5S</td></tr><tr><td>RPC</td><td>Remote procedure call</td></tr><tr><td>SOAP</td><td>Simple Object Access Protocol</td></tr><tr><td>WSDL</td><td>Web Service Definition Language</td></tr></table>
+
+# 1.6. References
+
+<table><tr><td>[OCPP_IMP_J]</td><td>OCPP JSON implementation specification</td></tr><tr><td>[RFC2119]</td><td>“Key words for use in RFCs to Indicate Requirement Levels”. S. Bradner. March 1997. http://www.ietf.org/rfc/rfc2119.txt</td></tr><tr><td>[WSA]</td><td>http://www.w3.org/TR/ws-addr-core/</td></tr></table>
+
+# 2. Binding to Transport Protocol
+
+This section describes how the OCPP PDUs can be conveyed over SOAP.
+
+The rationale behind using SOAP as a transport is that SOAP already provides the infrastructure of sending messages. SOAP has a good support in the industry, which results in tools that improve the ease of implementing the protocol.
+
+The used version of SOAP MUST be 1.2. See [SOAP]. Please note that this has no relationship with the 1.2 version number of the OCPP specification.
+
+# 3. SOAP Header
+
+Although we refer to the officially released version of the WS-Addressing specification we see a lot of confusion on the meaning and necessity of fields in the SOAP header. To avoid confusion we will explicitly state what should be in a SOAP header. Anything that we do not specify in this chapter is
+
+optional or not necessary, in compliance with the WS-A specification.
+
+# 3.1. XML Declaration
+
+An XML declaration is not part of the soap message but is necessary for some systems to correctly interpret the message. It specifies the XML version and encoding of what is to come. Therefore each OCPP-S message SHOULD be preceded by the following:
+
+```txt
+<?xml version="1.0" encoding="UTF-8"?
+```
+
+Just to be clear, this should be outside of the SOAP envelope containing the header and body.
+
+# 3.2. SOAP synchronicity
+
+When an OCPP-S implementation receives an OCPP request in an HTTP request, the response to that request MUST be given in the HTTP response. It is not possible to use asynchronous SOAP calls with OCPP.
+
+# 3.3. Charge Point Identity
+
+# Required: Yes
+
+To be able for the Central System to uniquely identify a Charge Point, a Charge Point MUST send its identifier in the SOAP header of each request PDU. The header name "chargeBoxIdentity" SHALL be treated as case insensitive. For example:
+
+```txt
+<!-- Header with the identifier of the sending Charge Point -->
+<!--- xmlns:se="http://www.w3.org/2003/05/soap-envelope" -->
+<!--- xmlns:cs="urn://Ocpp/Cs/2015/10/" -->
+<cs:chargeBoxIdentity se:mustUnderstand="true">CP1234</cs:chargeBoxIdentity>
+```
+
+When a Central System needs to send requests to a Charge Point, the Central System MUST specify in each request the "chargeBoxIdentity" of the Charge Point for which the request is intended. If the receiving Charge Point is not the intended one, and it cannot relay the message to a node that knows this Charge Point, then the Charge Point MUST send a SOAP Fault Response message, indicating that the identity is wrong (e.g. sub-code is "IdentityMismatch").
+
+The mustUnderstand attribute indicates enforces that the receiver MUST send an error of it cannot handle the specified field, in this case chargeBoxIdentity. If mustUnderstand is not specified or false, the receiver could choose to ignore messages for unknown identities.
+
+# 3.4. Action
+
+# Required: Yes
+
+The action field contains the type of OCPP message for which the parameters are included in the body. The content of this field should always start with a “/”, followed by the name of the message, starting with a capital letter. For response messages the action keyword must be extended with “Response”.
+
+Example:
+
+```asp
+<!--- xmlns:se="http://www.w3.org/2003/05/soap-envelope" --> <wsa5:Action se:mustUnderstand="true"></Heartbeat</wsa5:Action>
+```
+
+or
+
+```txt
+<!--- xmlns:se="http://www.w3.org/2003/05/soap-envelope" --> <wsa5:Action se:mustUnderstand="true"/>HeartbeatResponse</wsa5:Action>
+```
+
+Note that here we also use the mustUnderstand to enforce that messages containing an unknown action are not discarded but trigger an error response.
+
+# 3.5. MessageID
+
+# Required: Yes
+
+Each message can be given a unique message ID before sending. The purpose of this field is enable matching of an incoming response to a previously sent request.
+
+At first glance the official 1.0 Web Service Addressing Core specification ([WSA]) marks this field as “/OPTIONAL”. However, in paragraph 3.4 of this spec (Formulating a Reply Message), section 1 (Select the appropriate EPR), third bullet it casually states:
+
+"In either of the above cases, if the related message lacks a [message id] property, the processor MUST fault."
+
+The mentioned "related message" refers to the request. So, even though it is optional this line makes not having it in the request a reason to reject the message and thus implicitly makes it mandatory in a request-response context.
+
+# NOTE
+
+Because of this mandatory/optional discussion for this particular field we discovered that in most pre-releases of the official 1.0 WSA Core spec the MessageID is mandatory. We also discovered that some frameworks are actually based on those pre-releases and may contain other errors as well. Please verify that (if you use a framework) your framework is based on the final specification.
+
+# 3.6. RelatesTo
+
+# Required: Yes, for responses only
+
+RelatesTo should not be filled in for request messages. It only has meaning, and must be present, in response messages. When used it should contain the value of the MessageID field of the related request message.
+
+# 3.7. From
+
+# Required: Yes
+
+According to the WS-A 1.0 Core specification the from-field is marked as optional. However, for OCPP the field MUST be filled in. It is the only way for a Central System to know how to address server-initiated messages to a Charge Point. The address specified must be the address where the sender listens for incoming SOAP requests.
+
+# Example:
+
+```xml
+<wsa5:From> <wsa5:Address>http://62.133.94.210:12345</wsa5:Address> </wsa5:From>
+```
+
+# 3.8. ReplyTo
+
+# Required: Yes
+
+According to the WS-A 1.0 Core specification this field is marked as optional. If omitted, the default value is "http://www.w3.org/2005/08/addressing/anonymous". In accordance with section 5.1.2 of the WS-A 1.0 SOAP Binding specification the use of such anonymous response endpoints forces the response to be in the same instance of the SOAP request-response MEP. In other words, omitting or explicitly specifying the anonymous url makes the soap communication synchronous.
+
+Strictly speaking for OCPP this means that any other explicit value than the anonymous url would be an incorrect value.
+
+# Example:
+
+```rdf
+<wsa5:ReplyTo SOAP-ENV:mustUnderstand="true"> <wsa5:Address> http://www.w3.org/2005/08/addressing/anonymous </wsa5:Address> </wsa5:ReplyTo>
+```
+
+# 3.9. To
+
+# Required: Yes
+
+According to the WS-A 1.0 Core specification this field is marked as optional. However, if this field is omitted because it is optional the implicit value is "http://www.w3.org/2005/08/addressing/anonymous". What this means of how it should affect SOAP behavior is unspecified. For OCPP we require the To field to be filled in with the correct web service address of the recipient.
+
+# Example:
+
+```txt
+<wsa5:To SOAP-ENV:mustUnderstand="true">
+http://some.backoffice.com/ocpp/v1/5
+</wsa5:To>
+```
+
+# 4. Fault Response
+
+In cases where the receiving party (e.g. Charge Point or Central System) cannot process the request and the corresponding confirmation PDU does not have to ability to report the error, then the SOAP Fault Response Message SHOULD be used. This can be used, for instance, when the operation is not implemented or when an internal error has occurred.
+
+If a sender receives a SOAP Fault Response from the receiver, the sender SHOULD NOT resend the same message.
+
+The following fault codes can be used by the service:
+
+Code, Reason and Value belong to the namespace "http://www.w3.org/2003/05/soap-envelope".
+
+This example SubCode belongs to the namespace "urn://Ocpp/Cs/2015/10"
+
+Table 1: Fault Response SubCodes
+
+<table><tr><td colspan="2">Code</td><td>Reason</td></tr><tr><td>Value</td><td>SubCode</td><td></td></tr><tr><td>Sender</td><td>SecurityError</td><td>Sender failed authentication or is not authorized to use the requested operation.</td></tr><tr><td>Sender</td><td>IdentityMismatch</td><td>Sender sent the wrong identity value.</td></tr><tr><td>Sender</td><td>ProtocolError</td><td>Sender's message does not comply with protocol specification.</td></tr><tr><td>Receiver</td><td>InternalError</td><td>An internal error occurred and the receiver is not able to complete the operation.</td></tr><tr><td>Receiver</td><td>NotSupported</td><td>The receiver does not support the requested operation.</td></tr></table>
+
+# 5. Mobile Networks
+
+In cases where Charge Points use an IP based mobile data network (GPRS, UMTS, HSPDA, etc.) to communicate with the Central System, it's possible that the Central System cannot initiate a network connection to a Charge Point directly. For example, a Network Operator may use dynamic IP addresses.
+
+To overcome this problem, a Central System SHOULD send a SMS to a Charge Point. The SMS SHOULD contain the Charge Point identifier, but the SMS MAY also be empty. How an SMS is sent to an SMSC and delivered to the Charge Point is outside the scope of this specification. Upon receipt of a SMS, the Charge Point MUST send a Heartbeat.req PDU to the Central System with WS-Addressing header "From", with the URL of the Charge Point. See [WS-ADDR] for a description of the Web Service Addressing standard. The Central System SHOULD use this URL for sending a pending command to.
+
+When Charge Points are deployed in a mobile network, the Charge Point SHOULD set its URL in the WS-Addressing "From" field when sending a request. This way a Central System can first try sending commands to the supplied URL, before waking up the Charge Point via SMS.
+
+
+sd Wake-up of a charge point by SMS
+
+# 6. Connection
+
+# 6.1. Compression
+
+In cases where bandwidth needs to be reduced, a communicating party can use of the HTTP capability of compressing data. HTTP defines a 'Content-Encoding' header, which contains the compression method.
+
+The Charge Point and Central System MAY use HTTP compression. Compression can be performed on a HTTP request and/or response.
+
+The Charge Point and Central System MUST support the 'gzip' and 'deflate' compression methods. These are the most common compression methods.
+
+When using compression, one should take great care if indeed the message size decreases. If the message is small, then it's possible that the compression will increase the size.
+
+# 6.2. Security
+
+To avoid exposure of private sensitive data, the transport of SOAP messages SHOULD be secured with SSL/TLS (e.g. HTTPS).
+
+For a receiving party to trust a received message, the sending party SHOULD use a client certificate.
+
+# 7. SOAP specific OCPP requirements
+
+# 7.1. BootNotification
+
+If the SOAP connection to the Central System is lost, the Charge Point SHALL re-establish it. If the Charge Point is not sure that its IP Address has not changed, it SHOULD send a new BootNotification to the Central Server. In other words: If the IP Address of the Charge Point can have changed, the Charge Point SHOULD send a new BootNotification. The Central System needs the new IP Address, to be able to send Central System initiated messages to the Charge Point.
+
+# 8. WSDL
+
+The following table lists the applicable urn's for the different versions of OCP:
+
+Table 2:OCPP URNs
+
+<table><tr><td>OCPP Version</td><td>Part</td><td>Urn</td></tr><tr><td>OCPP 1.2</td><td>Central System service</td><td>urn://Ocpp/Cs/2010/08/</td></tr><tr><td></td><td>Charge Point service</td><td>urn://Ocpp/Cp/2010/08/</td></tr><tr><td>OCPP 1.5</td><td>Central System service</td><td>urn://Ocpp/Cs/2012/06/</td></tr><tr><td></td><td>Charge Point service</td><td>urn://Ocpp/Cp/2012/06/</td></tr><tr><td>OCPP 1.6</td><td>Central System service</td><td>urn://Ocpp/Cs/2015/10</td></tr><tr><td></td><td>Charge Point service</td><td>urn://Ocpp/Cp/2015/10</td></tr></table>
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:AuthorizeRequest",
+ "title": "AuthorizeRequest",
+ "type": "object",
+ "properties": {
+ "idTag": {
+ "type": "string",
+ "maxLength": 20
+ }
+ },
+ "additionalProperties": false,
+ "required": ["idTag"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:AuthorizeResponse",
+ "title": "AuthorizeResponse",
+ "type": "object",
+ "properties": {
+ "idTagInfo": {
+ "type": "object",
+ "properties": {
+ "expiryDate": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "parentIdTag": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Blocked", "Expired", "Invalid", "ConcurrentTx"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["idTagInfo"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:BootNotificationRequest",
+ "title": "BootNotificationRequest",
+ "type": "object",
+ "properties": {
+ "chargePointVendor": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "chargePointModel": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "chargePointSerialNumber": {
+ "type": "string",
+ "maxLength": 25
+ },
+ "chargeBoxSerialNumber": {
+ "type": "string",
+ "maxLength": 25
+ },
+ "firmwareVersion": {
+ "type": "string",
+ "maxLength": 50
+ },
+ "iccid": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "imsi": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "meterType": {
+ "type": "string",
+ "maxLength": 25
+ },
+ "meterSerialNumber": {
+ "type": "string",
+ "maxLength": 25
+ }
+ },
+ "additionalProperties": false,
+ "required": ["chargePointVendor", "chargePointModel"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:BootNotificationResponse",
+ "title": "BootNotificationResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Pending", "Rejected"]
+ },
+ "currentTime": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "interval": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status", "currentTime", "interval"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:CancelReservationRequest",
+ "title": "CancelReservationRequest",
+ "type": "object",
+ "properties": {
+ "reservationId": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["reservationId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:CancelReservationResponse",
+ "title": "CancelReservationResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:ChangeAvailabilityRequest",
+ "title": "ChangeAvailabilityRequest",
+ "type": "object",
+ "properties": {
+ "connectorId": {
+ "type": "integer"
+ },
+ "type": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Inoperative", "Operative"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["connectorId", "type"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:ChangeAvailabilityResponse",
+ "title": "ChangeAvailabilityResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Scheduled"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:ChangeConfigurationRequest",
+ "title": "ChangeConfigurationRequest",
+ "type": "object",
+ "properties": {
+ "key": {
+ "type": "string",
+ "maxLength": 50
+ },
+ "value": {
+ "type": "string",
+ "maxLength": 500
+ }
+ },
+ "additionalProperties": false,
+ "required": ["key", "value"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:ChangeConfigurationResponse",
+ "title": "ChangeConfigurationResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "RebootRequired", "NotSupported"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:ClearCacheRequest",
+ "title": "ClearCacheRequest",
+ "type": "object",
+ "properties": {},
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:ClearCacheResponse",
+ "title": "ClearCacheResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:ClearChargingProfileRequest",
+ "title": "ClearChargingProfileRequest",
+ "type": "object",
+ "properties": {
+ "id": {
+ "type": "integer"
+ },
+ "connectorId": {
+ "type": "integer"
+ },
+ "chargingProfilePurpose": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ChargePointMaxProfile", "TxDefaultProfile", "TxProfile"]
+ },
+ "stackLevel": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:ClearChargingProfileResponse",
+ "title": "ClearChargingProfileResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Unknown"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:DataTransferRequest",
+ "title": "DataTransferRequest",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ },
+ "messageId": {
+ "type": "string",
+ "maxLength": 50
+ },
+ "data": {
+ "type": "string"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["vendorId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:DataTransferResponse",
+ "title": "DataTransferResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "UnknownMessageId", "UnknownVendorId"]
+ },
+ "data": {
+ "type": "string"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:DiagnosticsStatusNotificationRequest",
+ "title": "DiagnosticsStatusNotificationRequest",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Idle", "Uploaded", "UploadFailed", "Uploading"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:DiagnosticsStatusNotificationResponse",
+ "title": "DiagnosticsStatusNotificationResponse",
+ "type": "object",
+ "properties": {},
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:FirmwareStatusNotificationRequest",
+ "title": "FirmwareStatusNotificationRequest",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Downloaded",
+ "DownloadFailed",
+ "Downloading",
+ "Idle",
+ "InstallationFailed",
+ "Installing",
+ "Installed"
+ ]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:FirmwareStatusNotificationResponse",
+ "title": "FirmwareStatusNotificationResponse",
+ "type": "object",
+ "properties": {},
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:GetCompositeScheduleRequest",
+ "title": "GetCompositeScheduleRequest",
+ "type": "object",
+ "properties": {
+ "connectorId": {
+ "type": "integer"
+ },
+ "duration": {
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["A", "W"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["connectorId", "duration"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:GetCompositeScheduleResponse",
+ "title": "GetCompositeScheduleResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "connectorId": {
+ "type": "integer"
+ },
+ "scheduleStart": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingSchedule": {
+ "type": "object",
+ "properties": {
+ "duration": {
+ "type": "integer"
+ },
+ "startSchedule": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingRateUnit": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["A", "W"]
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "items": {
+ "type": "object",
+ "properties": {
+ "startPeriod": {
+ "type": "integer"
+ },
+ "limit": {
+ "type": "number",
+ "multipleOf": 0.1
+ },
+ "numberPhases": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["startPeriod", "limit"]
+ }
+ },
+ "minChargingRate": {
+ "type": "number",
+ "multipleOf": 0.1
+ }
+ },
+ "additionalProperties": false,
+ "required": ["chargingRateUnit", "chargingSchedulePeriod"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:GetConfigurationRequest",
+ "title": "GetConfigurationRequest",
+ "type": "object",
+ "properties": {
+ "key": {
+ "type": "array",
+ "items": {
+ "type": "string",
+ "maxLength": 50
+ }
+ }
+ },
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:GetConfigurationResponse",
+ "title": "GetConfigurationResponse",
+ "type": "object",
+ "properties": {
+ "configurationKey": {
+ "type": "array",
+ "items": {
+ "type": "object",
+ "properties": {
+ "key": {
+ "type": "string",
+ "maxLength": 50
+ },
+ "readonly": {
+ "type": "boolean"
+ },
+ "value": {
+ "type": "string",
+ "maxLength": 500
+ }
+ },
+ "additionalProperties": false,
+ "required": ["key", "readonly"]
+ }
+ },
+ "unknownKey": {
+ "type": "array",
+ "items": {
+ "type": "string",
+ "maxLength": 50
+ }
+ }
+ },
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:GetDiagnosticsRequest",
+ "title": "GetDiagnosticsRequest",
+ "type": "object",
+ "properties": {
+ "location": {
+ "type": "string",
+ "format": "uri"
+ },
+ "retries": {
+ "type": "integer"
+ },
+ "retryInterval": {
+ "type": "integer"
+ },
+ "startTime": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "stopTime": {
+ "type": "string",
+ "format": "date-time"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["location"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:GetDiagnosticsResponse",
+ "title": "GetDiagnosticsResponse",
+ "type": "object",
+ "properties": {
+ "fileName": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:GetLocalListVersionRequest",
+ "title": "GetLocalListVersionRequest",
+ "type": "object",
+ "properties": {},
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:GetLocalListVersionResponse",
+ "title": "GetLocalListVersionResponse",
+ "type": "object",
+ "properties": {
+ "listVersion": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["listVersion"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:HeartbeatRequest",
+ "title": "HeartbeatRequest",
+ "type": "object",
+ "properties": {},
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:HeartbeatResponse",
+ "title": "HeartbeatResponse",
+ "type": "object",
+ "properties": {
+ "currentTime": {
+ "type": "string",
+ "format": "date-time"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["currentTime"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:MeterValuesRequest",
+ "title": "MeterValuesRequest",
+ "type": "object",
+ "properties": {
+ "connectorId": {
+ "type": "integer"
+ },
+ "transactionId": {
+ "type": "integer"
+ },
+ "meterValue": {
+ "type": "array",
+ "items": {
+ "type": "object",
+ "properties": {
+ "timestamp": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "sampledValue": {
+ "type": "array",
+ "items": {
+ "type": "object",
+ "properties": {
+ "value": {
+ "type": "string"
+ },
+ "context": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Interruption.Begin",
+ "Interruption.End",
+ "Sample.Clock",
+ "Sample.Periodic",
+ "Transaction.Begin",
+ "Transaction.End",
+ "Trigger",
+ "Other"
+ ]
+ },
+ "format": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Raw", "SignedData"]
+ },
+ "measurand": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Energy.Active.Export.Register",
+ "Energy.Active.Import.Register",
+ "Energy.Reactive.Export.Register",
+ "Energy.Reactive.Import.Register",
+ "Energy.Active.Export.Interval",
+ "Energy.Active.Import.Interval",
+ "Energy.Reactive.Export.Interval",
+ "Energy.Reactive.Import.Interval",
+ "Power.Active.Export",
+ "Power.Active.Import",
+ "Power.Offered",
+ "Power.Reactive.Export",
+ "Power.Reactive.Import",
+ "Power.Factor",
+ "Current.Import",
+ "Current.Export",
+ "Current.Offered",
+ "Voltage",
+ "Frequency",
+ "Temperature",
+ "SoC",
+ "RPM"
+ ]
+ },
+ "phase": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["L1", "L2", "L3", "N", "L1-N", "L2-N", "L3-N", "L1-L2", "L2-L3", "L3-L1"]
+ },
+ "location": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Cable", "EV", "Inlet", "Outlet", "Body"]
+ },
+ "unit": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Wh",
+ "kWh",
+ "varh",
+ "kvarh",
+ "W",
+ "kW",
+ "VA",
+ "kVA",
+ "var",
+ "kvar",
+ "A",
+ "V",
+ "K",
+ "Celcius",
+ "Celsius",
+ "Fahrenheit",
+ "Percent"
+ ]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["value"]
+ }
+ }
+ },
+ "additionalProperties": false,
+ "required": ["timestamp", "sampledValue"]
+ }
+ }
+ },
+ "additionalProperties": false,
+ "required": ["connectorId", "meterValue"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:MeterValuesResponse",
+ "title": "MeterValuesResponse",
+ "type": "object",
+ "properties": {},
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:RemoteStartTransactionRequest",
+ "title": "RemoteStartTransactionRequest",
+ "type": "object",
+ "properties": {
+ "connectorId": {
+ "type": "integer"
+ },
+ "idTag": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "chargingProfile": {
+ "type": "object",
+ "properties": {
+ "chargingProfileId": {
+ "type": "integer"
+ },
+ "transactionId": {
+ "type": "integer"
+ },
+ "stackLevel": {
+ "type": "integer"
+ },
+ "chargingProfilePurpose": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ChargePointMaxProfile", "TxDefaultProfile", "TxProfile"]
+ },
+ "chargingProfileKind": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Absolute", "Recurring", "Relative"]
+ },
+ "recurrencyKind": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Daily", "Weekly"]
+ },
+ "validFrom": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "validTo": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingSchedule": {
+ "type": "object",
+ "properties": {
+ "duration": {
+ "type": "integer"
+ },
+ "startSchedule": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingRateUnit": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["A", "W"]
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "items": {
+ "type": "object",
+ "properties": {
+ "startPeriod": {
+ "type": "integer"
+ },
+ "limit": {
+ "type": "number",
+ "multipleOf": 0.1
+ },
+ "numberPhases": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["startPeriod", "limit"]
+ }
+ },
+ "minChargingRate": {
+ "type": "number",
+ "multipleOf": 0.1
+ }
+ },
+ "additionalProperties": false,
+ "required": ["chargingRateUnit", "chargingSchedulePeriod"]
+ }
+ },
+ "additionalProperties": false,
+ "required": [
+ "chargingProfileId",
+ "stackLevel",
+ "chargingProfilePurpose",
+ "chargingProfileKind",
+ "chargingSchedule"
+ ]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["idTag"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:RemoteStartTransactionResponse",
+ "title": "RemoteStartTransactionResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:RemoteStopTransactionRequest",
+ "title": "RemoteStopTransactionRequest",
+ "type": "object",
+ "properties": {
+ "transactionId": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["transactionId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:RemoteStopTransactionResponse",
+ "title": "RemoteStopTransactionResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:ReserveNowRequest",
+ "title": "ReserveNowRequest",
+ "type": "object",
+ "properties": {
+ "connectorId": {
+ "type": "integer"
+ },
+ "expiryDate": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "idTag": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "parentIdTag": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "reservationId": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["connectorId", "expiryDate", "idTag", "reservationId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:ReserveNowResponse",
+ "title": "ReserveNowResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Faulted", "Occupied", "Rejected", "Unavailable"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:ResetRequest",
+ "title": "ResetRequest",
+ "type": "object",
+ "properties": {
+ "type": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Hard", "Soft"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["type"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:ResetResponse",
+ "title": "ResetResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:SendLocalListRequest",
+ "title": "SendLocalListRequest",
+ "type": "object",
+ "properties": {
+ "listVersion": {
+ "type": "integer"
+ },
+ "localAuthorizationList": {
+ "type": "array",
+ "items": {
+ "type": "object",
+ "properties": {
+ "idTag": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "idTagInfo": {
+ "type": "object",
+ "properties": {
+ "expiryDate": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "parentIdTag": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Blocked", "Expired", "Invalid", "ConcurrentTx"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["idTag"]
+ }
+ },
+ "updateType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Differential", "Full"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["listVersion", "updateType"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:SendLocalListResponse",
+ "title": "SendLocalListResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Failed", "NotSupported", "VersionMismatch"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:SetChargingProfileRequest",
+ "title": "SetChargingProfileRequest",
+ "type": "object",
+ "properties": {
+ "connectorId": {
+ "type": "integer"
+ },
+ "csChargingProfiles": {
+ "type": "object",
+ "properties": {
+ "chargingProfileId": {
+ "type": "integer"
+ },
+ "transactionId": {
+ "type": "integer"
+ },
+ "stackLevel": {
+ "type": "integer"
+ },
+ "chargingProfilePurpose": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ChargePointMaxProfile", "TxDefaultProfile", "TxProfile"]
+ },
+ "chargingProfileKind": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Absolute", "Recurring", "Relative"]
+ },
+ "recurrencyKind": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Daily", "Weekly"]
+ },
+ "validFrom": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "validTo": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingSchedule": {
+ "type": "object",
+ "properties": {
+ "duration": {
+ "type": "integer"
+ },
+ "startSchedule": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingRateUnit": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["A", "W"]
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "items": {
+ "type": "object",
+ "properties": {
+ "startPeriod": {
+ "type": "integer"
+ },
+ "limit": {
+ "type": "number",
+ "multipleOf": 0.1
+ },
+ "numberPhases": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["startPeriod", "limit"]
+ }
+ },
+ "minChargingRate": {
+ "type": "number",
+ "multipleOf": 0.1
+ }
+ },
+ "additionalProperties": false,
+ "required": ["chargingRateUnit", "chargingSchedulePeriod"]
+ }
+ },
+ "additionalProperties": false,
+ "required": [
+ "chargingProfileId",
+ "stackLevel",
+ "chargingProfilePurpose",
+ "chargingProfileKind",
+ "chargingSchedule"
+ ]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["connectorId", "csChargingProfiles"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:SetChargingProfileResponse",
+ "title": "SetChargingProfileResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotSupported"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:StartTransactionRequest",
+ "title": "StartTransactionRequest",
+ "type": "object",
+ "properties": {
+ "connectorId": {
+ "type": "integer"
+ },
+ "idTag": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "meterStart": {
+ "type": "integer"
+ },
+ "reservationId": {
+ "type": "integer"
+ },
+ "timestamp": {
+ "type": "string",
+ "format": "date-time"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["connectorId", "idTag", "meterStart", "timestamp"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:StartTransactionResponse",
+ "title": "StartTransactionResponse",
+ "type": "object",
+ "properties": {
+ "idTagInfo": {
+ "type": "object",
+ "properties": {
+ "expiryDate": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "parentIdTag": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Blocked", "Expired", "Invalid", "ConcurrentTx"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+ },
+ "transactionId": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["idTagInfo", "transactionId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:StatusNotificationRequest",
+ "title": "StatusNotificationRequest",
+ "type": "object",
+ "properties": {
+ "connectorId": {
+ "type": "integer"
+ },
+ "errorCode": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ConnectorLockFailure",
+ "EVCommunicationError",
+ "GroundFailure",
+ "HighTemperature",
+ "InternalError",
+ "LocalListConflict",
+ "NoError",
+ "OtherError",
+ "OverCurrentFailure",
+ "PowerMeterFailure",
+ "PowerSwitchFailure",
+ "ReaderFailure",
+ "ResetFailure",
+ "UnderVoltage",
+ "OverVoltage",
+ "WeakSignal"
+ ]
+ },
+ "info": {
+ "type": "string",
+ "maxLength": 50
+ },
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Available",
+ "Preparing",
+ "Charging",
+ "SuspendedEVSE",
+ "SuspendedEV",
+ "Finishing",
+ "Reserved",
+ "Unavailable",
+ "Faulted"
+ ]
+ },
+ "timestamp": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ },
+ "vendorErrorCode": {
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "additionalProperties": false,
+ "required": ["connectorId", "errorCode", "status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:StatusNotificationResponse",
+ "title": "StatusNotificationResponse",
+ "type": "object",
+ "properties": {},
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2025:04:StopTransactionRequest",
+ "title": "StopTransactionRequest",
+ "type": "object",
+ "properties": {
+ "idTag": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "meterStop": {
+ "type": "integer"
+ },
+ "timestamp": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "transactionId": {
+ "type": "integer"
+ },
+ "reason": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "EmergencyStop",
+ "EVDisconnected",
+ "HardReset",
+ "Local",
+ "Other",
+ "PowerLoss",
+ "Reboot",
+ "Remote",
+ "SoftReset",
+ "UnlockCommand",
+ "DeAuthorized"
+ ]
+ },
+ "transactionData": {
+ "type": "array",
+ "items": {
+ "type": "object",
+ "properties": {
+ "timestamp": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "sampledValue": {
+ "type": "array",
+ "items": {
+ "type": "object",
+ "properties": {
+ "value": {
+ "type": "string"
+ },
+ "context": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Interruption.Begin",
+ "Interruption.End",
+ "Sample.Clock",
+ "Sample.Periodic",
+ "Transaction.Begin",
+ "Transaction.End",
+ "Trigger",
+ "Other"
+ ]
+ },
+ "format": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Raw", "SignedData"]
+ },
+ "measurand": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Energy.Active.Export.Register",
+ "Energy.Active.Import.Register",
+ "Energy.Reactive.Export.Register",
+ "Energy.Reactive.Import.Register",
+ "Energy.Active.Export.Interval",
+ "Energy.Active.Import.Interval",
+ "Energy.Reactive.Export.Interval",
+ "Energy.Reactive.Import.Interval",
+ "Power.Active.Export",
+ "Power.Active.Import",
+ "Power.Offered",
+ "Power.Reactive.Export",
+ "Power.Reactive.Import",
+ "Power.Factor",
+ "Current.Import",
+ "Current.Export",
+ "Current.Offered",
+ "Voltage",
+ "Frequency",
+ "Temperature",
+ "SoC",
+ "RPM"
+ ]
+ },
+ "phase": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["L1", "L2", "L3", "N", "L1-N", "L2-N", "L3-N", "L1-L2", "L2-L3", "L3-L1"]
+ },
+ "location": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Cable", "EV", "Inlet", "Outlet", "Body"]
+ },
+ "unit": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Wh",
+ "kWh",
+ "varh",
+ "kvarh",
+ "W",
+ "kW",
+ "VA",
+ "kVA",
+ "var",
+ "kvar",
+ "A",
+ "V",
+ "K",
+ "Celcius",
+ "Celsius",
+ "Fahrenheit",
+ "Percent"
+ ]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["value"]
+ }
+ }
+ },
+ "additionalProperties": false,
+ "required": ["timestamp", "sampledValue"]
+ }
+ }
+ },
+ "additionalProperties": false,
+ "required": ["transactionId", "timestamp", "meterStop"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:StopTransactionResponse",
+ "title": "StopTransactionResponse",
+ "type": "object",
+ "properties": {
+ "idTagInfo": {
+ "type": "object",
+ "properties": {
+ "expiryDate": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "parentIdTag": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Blocked", "Expired", "Invalid", "ConcurrentTx"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+ }
+ },
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:TriggerMessageRequest",
+ "title": "TriggerMessageRequest",
+ "type": "object",
+ "properties": {
+ "requestedMessage": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "BootNotification",
+ "DiagnosticsStatusNotification",
+ "FirmwareStatusNotification",
+ "Heartbeat",
+ "MeterValues",
+ "StatusNotification"
+ ]
+ },
+ "connectorId": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["requestedMessage"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:TriggerMessageResponse",
+ "title": "TriggerMessageResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotImplemented"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:UnlockConnectorRequest",
+ "title": "UnlockConnectorRequest",
+ "type": "object",
+ "properties": {
+ "connectorId": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["connectorId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:UnlockConnectorResponse",
+ "title": "UnlockConnectorResponse",
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Unlocked", "UnlockFailed", "NotSupported"]
+ }
+ },
+ "additionalProperties": false,
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:UpdateFirmwareRequest",
+ "title": "UpdateFirmwareRequest",
+ "type": "object",
+ "properties": {
+ "location": {
+ "type": "string",
+ "format": "uri"
+ },
+ "retries": {
+ "type": "integer"
+ },
+ "retrieveDate": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "retryInterval": {
+ "type": "integer"
+ }
+ },
+ "additionalProperties": false,
+ "required": ["location", "retrieveDate"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "urn:OCPP:1.6:2019:12:UpdateFirmwareResponse",
+ "title": "UpdateFirmwareResponse",
+ "type": "object",
+ "properties": {},
+ "additionalProperties": false
+}
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+OCPP Central System service description
+Version 1.6 FINAL
+
+Copyright © 2010 – 2015 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).
+-->
+<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
+ xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
+ xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
+ xmlns:s="http://www.w3.org/2001/XMLSchema"
+ xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
+ xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
+ xmlns:tns="urn://Ocpp/Cs/2015/10/"
+ targetNamespace="urn://Ocpp/Cs/2015/10/"
+ xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
+ xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
+ xmlns:wsa="http://www.w3.org/2005/08/addressing"
+ xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
+ xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
+
+ <wsp:Policy wsu:Id="ServicePolicy">
+ <wsp:ExactlyOne>
+ <wsp:All>
+ <wsaw:UsingAddressing/>
+ </wsp:All>
+ </wsp:ExactlyOne>
+ </wsp:Policy>
+
+ <wsdl:types>
+ <s:schema targetNamespace="urn://Ocpp/Cs/2015/10/" elementFormDefault="qualified">
+
+ <!-- Begin of types shared with ChargePointService -->
+ <s:simpleType name="IdToken">
+ <s:annotation>
+ <s:documentation>Type of string defining identification token, e.g. RFID or credit card number. To be treated as case insensitive.</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:maxLength value="20"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="CiString20Type">
+ <s:annotation>
+ <s:documentation>String of maximum 20 printable characters. To be treated as case insensitive.</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:maxLength value="20"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="CiString25Type">
+ <s:annotation>
+ <s:documentation>String of maximum 25 printable characters. To be treated as case insensitive.</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:maxLength value="25"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="CiString50Type">
+ <s:annotation>
+ <s:documentation>String of maximum 50 printable characters. To be treated as case insensitive.</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:maxLength value="50"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="CiString255Type">
+ <s:annotation>
+ <s:documentation>String of maximum 255 printable characters. To be treated as case insensitive.</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:maxLength value="255"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="CiString500Type">
+ <s:annotation>
+ <s:documentation>String of maximum 500 printable characters. To be treated as case insensitive.</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:maxLength value="500"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="AuthorizationStatus">
+ <s:annotation>
+ <s:documentation>Defines the authorization-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted"/>
+ <s:enumeration value="Blocked"/>
+ <s:enumeration value="Expired"/>
+ <s:enumeration value="Invalid"/>
+ <s:enumeration value="ConcurrentTx"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="IdTagInfo">
+ <s:sequence>
+ <s:element name="status" type="tns:AuthorizationStatus" minOccurs="1" maxOccurs="1"/>
+ <s:element name="expiryDate" type="s:dateTime" minOccurs="0" maxOccurs="1"/>
+ <s:element name="parentIdTag" type="tns:IdToken" minOccurs="0" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+ <!-- End of types shared with ChargePointService -->
+
+ <s:complexType name="AuthorizeRequest">
+ <s:annotation>
+ <s:documentation>Defines the Authorize.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="idTag" type="tns:IdToken" minOccurs="1" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="AuthorizeResponse">
+ <s:annotation>
+ <s:documentation>Defines the Authorize.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="idTagInfo" type="tns:IdTagInfo" minOccurs="1" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="StartTransactionRequest">
+ <s:annotation>
+ <s:documentation>Defines the StartTransaction.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="connectorId" type="s:int" minOccurs="1" maxOccurs="1"/>
+ <s:element name="idTag" type="tns:IdToken" minOccurs="1" maxOccurs="1"/>
+ <s:element name="timestamp" type="s:dateTime" minOccurs="1" maxOccurs="1"/>
+ <s:element name="meterStart" type="s:int" minOccurs="1" maxOccurs="1"/>
+ <s:element name="reservationId" type="s:int" minOccurs="0" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="StartTransactionResponse">
+ <s:annotation>
+ <s:documentation>Defines the StartTransaction.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="transactionId" type="s:int" minOccurs="1" maxOccurs="1"/>
+ <s:element name="idTagInfo" type="tns:IdTagInfo" minOccurs="1" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="Reason">
+ <s:annotation>
+ <s:documentation>Reason for stopping a transaction</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="EmergencyStop"/>
+ <s:enumeration value="EVDisconnected"/>
+ <s:enumeration value="HardReset"/>
+ <s:enumeration value="Local"/>
+ <s:enumeration value="Other"/>
+ <s:enumeration value="PowerLoss"/>
+ <s:enumeration value="Reboot"/>
+ <s:enumeration value="Remote"/>
+ <s:enumeration value="SoftReset"/>
+ <s:enumeration value="UnlockCommand"/>
+ <s:enumeration value="DeAuthorized"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="StopTransactionRequest">
+ <s:annotation>
+ <s:documentation>Defines the StopTransaction.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="transactionId" type="s:int" minOccurs="1" maxOccurs="1"/>
+ <s:element name="idTag" type="tns:IdToken" minOccurs="0" maxOccurs="1"/>
+ <s:element name="timestamp" type="s:dateTime" minOccurs="1" maxOccurs="1"/>
+ <s:element name="meterStop" type="s:int" minOccurs="1" maxOccurs="1"/>
+ <s:element name="reason" type="tns:Reason" minOccurs="0" maxOccurs="1"/>
+ <s:element name="transactionData" type="tns:MeterValue" minOccurs="0" maxOccurs="unbounded"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="StopTransactionResponse">
+ <s:annotation>
+ <s:documentation>Defines the StopTransaction.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="idTagInfo" type="tns:IdTagInfo" minOccurs="0" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="HeartbeatRequest">
+ <s:annotation>
+ <s:documentation>Defines the Heartbeat.req PDU</s:documentation>
+ </s:annotation>
+ </s:complexType>
+
+ <s:complexType name="HeartbeatResponse">
+ <s:annotation>
+ <s:documentation>Defines the Heartbeat.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="currentTime" type="s:dateTime" minOccurs="1" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="ReadingContext">
+ <s:restriction base="s:string">
+ <s:enumeration value="Interruption.Begin"/>
+ <s:enumeration value="Interruption.End"/>
+ <s:enumeration value="Other"/>
+ <s:enumeration value="Sample.Clock"/>
+ <s:enumeration value="Sample.Periodic"/>
+ <s:enumeration value="Transaction.Begin"/>
+ <s:enumeration value="Transaction.End"/>
+ <s:enumeration value="Trigger"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="Measurand">
+ <s:restriction base="s:string">
+ <s:enumeration value="Current.Export"/>
+ <s:enumeration value="Current.Import"/>
+ <s:enumeration value="Current.Offered"/>
+ <s:enumeration value="Energy.Active.Export.Register"/>
+ <s:enumeration value="Energy.Active.Import.Register"/>
+ <s:enumeration value="Energy.Reactive.Export.Register"/>
+ <s:enumeration value="Energy.Reactive.Import.Register"/>
+ <s:enumeration value="Energy.Active.Export.Interval"/>
+ <s:enumeration value="Energy.Active.Import.Interval"/>
+ <s:enumeration value="Energy.Reactive.Export.Interval"/>
+ <s:enumeration value="Energy.Reactive.Import.Interval"/>
+ <s:enumeration value="Frequency"/>
+ <s:enumeration value="Power.Active.Export"/>
+ <s:enumeration value="Power.Active.Import"/>
+ <s:enumeration value="Power.Factor"/>
+ <s:enumeration value="Power.Offered"/>
+ <s:enumeration value="Power.Reactive.Export"/>
+ <s:enumeration value="Power.Reactive.Import"/>
+ <s:enumeration value="RPM"/>
+ <s:enumeration value="SoC"/>
+ <s:enumeration value="Temperature"/>
+ <s:enumeration value="Voltage"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="ValueFormat">
+ <s:restriction base="s:string">
+ <s:enumeration value="Raw"/>
+ <s:enumeration value="SignedData"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="UnitOfMeasure">
+ <s:restriction base="s:string">
+ <s:enumeration value="Celsius"/>
+ <s:enumeration value="Fahrenheit"/>
+ <s:enumeration value="Wh"/>
+ <s:enumeration value="kWh"/>
+ <s:enumeration value="varh"/>
+ <s:enumeration value="kvarh"/>
+ <s:enumeration value="W"/>
+ <s:enumeration value="kW"/>
+ <s:enumeration value="VA"/>
+ <s:enumeration value="kVA"/>
+ <s:enumeration value="var"/>
+ <s:enumeration value="kvar"/>
+ <s:enumeration value="A"/>
+ <s:enumeration value="V"/>
+ <s:enumeration value="K"/>
+ <s:enumeration value="Percent"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="Phase">
+ <s:restriction base="s:string">
+ <s:enumeration value="L1"/>
+ <s:enumeration value="L2"/>
+ <s:enumeration value="L3"/>
+ <s:enumeration value="N"/>
+ <s:enumeration value="L1-N"/>
+ <s:enumeration value="L2-N"/>
+ <s:enumeration value="L3-N"/>
+ <s:enumeration value="L1-L2"/>
+ <s:enumeration value="L2-L3"/>
+ <s:enumeration value="L3-L1"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="Location">
+ <s:restriction base="s:string">
+ <s:enumeration value="Body"/>
+ <s:enumeration value="Cable"/>
+ <s:enumeration value="EV"/>
+ <s:enumeration value="Inlet"/>
+ <s:enumeration value="Outlet"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="SampledValue">
+ <s:annotation>
+ <s:documentation>Defines the SampledValue-value</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="value" type="s:string" minOccurs="1" maxOccurs="1" /> <!-- default="Sample.Periodic" -->
+ <s:element name="context" type="tns:ReadingContext" minOccurs="0" maxOccurs="1"/> <!-- default="Sample.Periodic" -->
+ <s:element name="format" type="tns:ValueFormat" minOccurs="0" maxOccurs="1"/> <!-- default="Raw" -->
+ <s:element name="measurand" type="tns:Measurand" minOccurs="0" maxOccurs="1"/> <!-- default="Energy.Active.Import.Register" -->
+ <s:element name="phase" type="tns:Phase" minOccurs="0" maxOccurs="1"/> <!-- default="Energy.Active.Import.Register" -->
+ <s:element name="location" type="tns:Location" minOccurs="0" maxOccurs="1"/> <!-- default="Outlet" -->
+ <s:element name="unit" type="tns:UnitOfMeasure" minOccurs="0" maxOccurs="1"/> <!-- default="Wh" -->
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="MeterValue">
+ <s:annotation>
+ <s:documentation>Defines single value of the meter-value-value</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="timestamp" type="s:dateTime" minOccurs="1" maxOccurs="1"/>
+ <s:element name="sampledValue" type="tns:SampledValue" minOccurs="1" maxOccurs="unbounded"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="MeterValuesRequest">
+ <s:annotation>
+ <s:documentation>Defines the MeterValues.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="connectorId" type="s:int" minOccurs="1" maxOccurs="1"/>
+ <s:element name="transactionId" type="s:int" minOccurs="0" maxOccurs="1"/>
+ <s:element name="meterValue" type="tns:MeterValue" minOccurs="0" maxOccurs="unbounded"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="MeterValuesResponse">
+ <s:annotation>
+ <s:documentation>Defines the MeterValues.conf PDU</s:documentation>
+ </s:annotation>
+ </s:complexType>
+
+ <s:complexType name="BootNotificationRequest">
+ <s:annotation>
+ <s:documentation>Defines the BootNotification.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="chargePointVendor" type="tns:CiString20Type" minOccurs="1" maxOccurs="1"/>
+ <s:element name="chargePointModel" type="tns:CiString20Type" minOccurs="1" maxOccurs="1"/>
+ <s:element name="chargePointSerialNumber" type="tns:CiString25Type" minOccurs="0" maxOccurs="1"/>
+ <s:element name="chargeBoxSerialNumber" type="tns:CiString25Type" minOccurs="0" maxOccurs="1"/>
+ <s:element name="firmwareVersion" type="tns:CiString50Type" minOccurs="0" maxOccurs="1"/>
+ <s:element name="iccid" type="tns:CiString20Type" minOccurs="0" maxOccurs="1"/>
+ <s:element name="imsi" type="tns:CiString20Type" minOccurs="0" maxOccurs="1"/>
+ <s:element name="meterType" type="tns:CiString25Type" minOccurs="0" maxOccurs="1"/>
+ <s:element name="meterSerialNumber" type="tns:CiString25Type" minOccurs="0" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="RegistrationStatus">
+ <s:annotation>
+ <s:documentation>Defines the registration-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted"/>
+ <s:enumeration value="Pending"/>
+ <s:enumeration value="Rejected"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="BootNotificationResponse">
+ <s:annotation>
+ <s:documentation>Defines the BootNotification.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:RegistrationStatus" minOccurs="1" maxOccurs="1"/>
+ <s:element name="currentTime" type="s:dateTime" minOccurs="1" maxOccurs="1"/>
+ <s:element name="interval" type="s:int" minOccurs="1" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="ChargePointErrorCode">
+ <s:annotation>
+ <s:documentation>Defines the charge-point-error-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="ConnectorLockFailure"/>
+ <s:enumeration value="EVCommunicationError"/>
+ <s:enumeration value="GroundFailure"/>
+ <s:enumeration value="HighTemperature"/>
+ <s:enumeration value="InternalError"/>
+ <s:enumeration value="LocalListConflict"/>
+ <s:enumeration value="NoError"/>
+ <s:enumeration value="OtherError"/>
+ <s:enumeration value="OverCurrentFailure"/>
+ <s:enumeration value="OverVoltage"/>
+ <s:enumeration value="PowerMeterFailure"/>
+ <s:enumeration value="PowerSwitchFailure"/>
+ <s:enumeration value="ReaderFailure"/>
+ <s:enumeration value="ResetFailure"/>
+ <s:enumeration value="UnderVoltage"/>
+ <s:enumeration value="WeakSignal"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="ChargePointStatus">
+ <s:annotation>
+ <s:documentation>Defines the charge-point-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Available"/>
+ <s:enumeration value="Preparing"/>
+ <s:enumeration value="Charging"/>
+ <s:enumeration value="SuspendedEV"/>
+ <s:enumeration value="SuspendedEVSE"/>
+ <s:enumeration value="Finishing"/>
+ <s:enumeration value="Reserved"/>
+ <s:enumeration value="Faulted"/>
+ <s:enumeration value="Unavailable"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="StatusNotificationRequest">
+ <s:annotation>
+ <s:documentation>Defines the StatusNotification.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="connectorId" type="s:int" minOccurs="1" maxOccurs="1"/>
+ <s:element name="status" type="tns:ChargePointStatus" minOccurs="1" maxOccurs="1"/>
+ <s:element name="errorCode" type="tns:ChargePointErrorCode" minOccurs="1" maxOccurs="1"/>
+ <s:element name="info" type="tns:CiString50Type" minOccurs="0" maxOccurs="1"/>
+ <s:element name="timestamp" type="s:dateTime" minOccurs="0" maxOccurs="1"/>
+ <s:element name="vendorId" type="tns:CiString255Type" minOccurs="0" maxOccurs="1"/>
+ <s:element name="vendorErrorCode" type="tns:CiString50Type" minOccurs="0" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="StatusNotificationResponse">
+ <s:annotation>
+ <s:documentation>Defines the StatusNotification.conf PDU</s:documentation>
+ </s:annotation>
+ </s:complexType>
+
+ <s:simpleType name="FirmwareStatus">
+ <s:annotation>
+ <s:documentation>Defines the firmware-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Downloaded"/>
+ <s:enumeration value="DownloadFailed"/>
+ <s:enumeration value="Downloading"/>
+ <s:enumeration value="Idle"/>
+ <s:enumeration value="InstallationFailed"/>
+ <s:enumeration value="Installed"/>
+ <s:enumeration value="Installing"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="FirmwareStatusNotificationRequest">
+ <s:annotation>
+ <s:documentation>Defines the FirmwareStatusNotification.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:FirmwareStatus" minOccurs="1" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="FirmwareStatusNotificationResponse">
+ <s:annotation>
+ <s:documentation>Defines the FirmwareStatusNotification.conf PDU</s:documentation>
+ </s:annotation>
+ </s:complexType>
+
+ <s:simpleType name="DiagnosticsStatus">
+ <s:annotation>
+ <s:documentation>Defines the diagnostics-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Idle"/>
+ <s:enumeration value="Uploaded"/>
+ <s:enumeration value="UploadFailed"/>
+ <s:enumeration value="Uploading"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="DiagnosticsStatusNotificationRequest">
+ <s:annotation>
+ <s:documentation>Defines the DiagnosticsStatusNotification.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:DiagnosticsStatus" minOccurs="1" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="DiagnosticsStatusNotificationResponse">
+ <s:annotation>
+ <s:documentation>Defines the DiagnosticsStatusNotification.conf PDU</s:documentation>
+ </s:annotation>
+ </s:complexType>
+
+ <s:complexType name="DataTransferRequest">
+ <s:annotation>
+ <s:documentation>Defines the DataTransfer.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="vendorId" type="tns:CiString255Type" minOccurs="1" maxOccurs="1"/>
+ <s:element name="messageId" type="tns:CiString50Type" minOccurs="0" maxOccurs="1"/>
+ <s:element name="data" type="s:string" minOccurs="0" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="DataTransferStatus">
+ <s:annotation>
+ <s:documentation>Defines the status returned in DataTransfer.conf</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted"/>
+ <s:enumeration value="Rejected"/>
+ <s:enumeration value="UnknownMessageId"/>
+ <s:enumeration value="UnknownVendorId"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="DataTransferResponse">
+ <s:annotation>
+ <s:documentation>Defines the DataTransfer.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:DataTransferStatus" minOccurs="1" maxOccurs="1"/>
+ <s:element name="data" type="s:string" minOccurs="0" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:element name="chargeBoxIdentity" type="s:string"/>
+ <s:element name="authorizeRequest" type="tns:AuthorizeRequest"/>
+ <s:element name="authorizeResponse" type="tns:AuthorizeResponse"/>
+ <s:element name="bootNotificationRequest" type="tns:BootNotificationRequest"/>
+ <s:element name="bootNotificationResponse" type="tns:BootNotificationResponse"/>
+ <s:element name="dataTransferRequest" type="tns:DataTransferRequest"/>
+ <s:element name="dataTransferResponse" type="tns:DataTransferResponse"/>
+ <s:element name="diagnosticsStatusNotificationRequest" type="tns:DiagnosticsStatusNotificationRequest"/>
+ <s:element name="diagnosticsStatusNotificationResponse" type="tns:DiagnosticsStatusNotificationResponse"/>
+ <s:element name="firmwareStatusNotificationRequest" type="tns:FirmwareStatusNotificationRequest"/>
+ <s:element name="firmwareStatusNotificationResponse" type="tns:FirmwareStatusNotificationResponse"/>
+ <s:element name="heartbeatRequest" type="tns:HeartbeatRequest"/>
+ <s:element name="heartbeatResponse" type="tns:HeartbeatResponse"/>
+ <s:element name="meterValuesRequest" type="tns:MeterValuesRequest"/>
+ <s:element name="meterValuesResponse" type="tns:MeterValuesResponse"/>
+ <s:element name="startTransactionRequest" type="tns:StartTransactionRequest"/>
+ <s:element name="startTransactionResponse" type="tns:StartTransactionResponse"/>
+ <s:element name="statusNotificationRequest" type="tns:StatusNotificationRequest"/>
+ <s:element name="statusNotificationResponse" type="tns:StatusNotificationResponse"/>
+ <s:element name="stopTransactionRequest" type="tns:StopTransactionRequest"/>
+ <s:element name="stopTransactionResponse" type="tns:StopTransactionResponse"/>
+ </s:schema>
+ </wsdl:types>
+
+ <wsdl:message name="Header">
+ <wsdl:part name="ChargeBoxIdentity" element="tns:chargeBoxIdentity"/>
+ </wsdl:message>
+
+ <wsdl:message name="AuthorizeInput">
+ <wsdl:part name="parameters" element="tns:authorizeRequest"/>
+ </wsdl:message>
+
+ <wsdl:message name="AuthorizeOutput">
+ <wsdl:part name="parameters" element="tns:authorizeResponse"/>
+ </wsdl:message>
+
+ <wsdl:message name="BootNotificationInput">
+ <wsdl:part name="parameters" element="tns:bootNotificationRequest"/>
+ </wsdl:message>
+
+ <wsdl:message name="BootNotificationOutput">
+ <wsdl:part name="parameters" element="tns:bootNotificationResponse"/>
+ </wsdl:message>
+
+ <wsdl:message name="DataTransferInput">
+ <wsdl:part name="parameters" element="tns:dataTransferRequest"/>
+ </wsdl:message>
+
+ <wsdl:message name="DataTransferOutput">
+ <wsdl:part name="parameters" element="tns:dataTransferResponse"/>
+ </wsdl:message>
+
+ <wsdl:message name="DiagnosticsStatusNotificationInput">
+ <wsdl:part name="parameters" element="tns:diagnosticsStatusNotificationRequest"/>
+ </wsdl:message>
+
+ <wsdl:message name="DiagnosticsStatusNotificationOutput">
+ <wsdl:part name="parameters" element="tns:diagnosticsStatusNotificationResponse"/>
+ </wsdl:message>
+
+ <wsdl:message name="FirmwareStatusNotificationInput">
+ <wsdl:part name="parameters" element="tns:firmwareStatusNotificationRequest"/>
+ </wsdl:message>
+
+ <wsdl:message name="FirmwareStatusNotificationOutput">
+ <wsdl:part name="parameters" element="tns:firmwareStatusNotificationResponse"/>
+ </wsdl:message>
+
+ <wsdl:message name="HeartbeatInput">
+ <wsdl:part name="parameters" element="tns:heartbeatRequest"/>
+ </wsdl:message>
+
+ <wsdl:message name="HeartbeatOutput">
+ <wsdl:part name="parameters" element="tns:heartbeatResponse"/>
+ </wsdl:message>
+
+ <wsdl:message name="MeterValuesInput">
+ <wsdl:part name="parameters" element="tns:meterValuesRequest"/>
+ </wsdl:message>
+
+ <wsdl:message name="MeterValuesOutput">
+ <wsdl:part name="parameters" element="tns:meterValuesResponse"/>
+ </wsdl:message>
+
+ <wsdl:message name="StartTransactionInput">
+ <wsdl:part name="parameters" element="tns:startTransactionRequest"/>
+ </wsdl:message>
+
+ <wsdl:message name="StartTransactionOutput">
+ <wsdl:part name="parameters" element="tns:startTransactionResponse"/>
+ </wsdl:message>
+
+ <wsdl:message name="StatusNotificationInput">
+ <wsdl:part name="parameters" element="tns:statusNotificationRequest"/>
+ </wsdl:message>
+
+ <wsdl:message name="StatusNotificationOutput">
+ <wsdl:part name="parameters" element="tns:statusNotificationResponse"/>
+ </wsdl:message>
+
+ <wsdl:message name="StopTransactionInput">
+ <wsdl:part name="parameters" element="tns:stopTransactionRequest"/>
+ </wsdl:message>
+
+ <wsdl:message name="StopTransactionOutput">
+ <wsdl:part name="parameters" element="tns:stopTransactionResponse"/>
+ </wsdl:message>
+
+
+ <wsdl:portType name="CentralSystemService">
+
+ <wsdl:operation name="Authorize">
+ <wsdl:input message="tns:AuthorizeInput" wsaw:Action="/Authorize"/>
+ <wsdl:output message="tns:AuthorizeOutput" wsaw:Action="/AuthorizeResponse"/>
+ </wsdl:operation>
+
+ <wsdl:operation name="BootNotification">
+ <wsdl:input message="tns:BootNotificationInput" wsaw:Action="/BootNotification"/>
+ <wsdl:output message="tns:BootNotificationOutput" wsaw:Action="/BootNotificationResponse"/>
+ </wsdl:operation>
+
+ <wsdl:operation name="DataTransfer">
+ <wsdl:input message="tns:DataTransferInput" wsaw:Action="/DataTransfer"/>
+ <wsdl:output message="tns:DataTransferOutput" wsaw:Action="/DataTransferResponse"/>
+ </wsdl:operation>
+
+ <wsdl:operation name="DiagnosticsStatusNotification">
+ <wsdl:input message="tns:DiagnosticsStatusNotificationInput" wsaw:Action="/DiagnosticsStatusNotification"/>
+ <wsdl:output message="tns:DiagnosticsStatusNotificationOutput" wsaw:Action="/DiagnosticsStatusNotificationResponse"/>
+ </wsdl:operation>
+
+ <wsdl:operation name="FirmwareStatusNotification">
+ <wsdl:input message="tns:FirmwareStatusNotificationInput" wsaw:Action="/FirmwareStatusNotification"/>
+ <wsdl:output message="tns:FirmwareStatusNotificationOutput" wsaw:Action="/FirmwareStatusNotificationResponse"/>
+ </wsdl:operation>
+
+ <wsdl:operation name="Heartbeat">
+ <wsdl:input message="tns:HeartbeatInput" wsaw:Action="/Heartbeat"/>
+ <wsdl:output message="tns:HeartbeatOutput" wsaw:Action="/HeartbeatResponse"/>
+ </wsdl:operation>
+
+ <wsdl:operation name="MeterValues">
+ <wsdl:input message="tns:MeterValuesInput" wsaw:Action="/MeterValues"/>
+ <wsdl:output message="tns:MeterValuesOutput" wsaw:Action="/MeterValuesResponse"/>
+ </wsdl:operation>
+
+ <wsdl:operation name="StartTransaction">
+ <wsdl:input message="tns:StartTransactionInput" wsaw:Action="/StartTransaction"/>
+ <wsdl:output message="tns:StartTransactionOutput" wsaw:Action="/StartTransactionResponse"/>
+ </wsdl:operation>
+
+ <wsdl:operation name="StatusNotification">
+ <wsdl:input message="tns:StatusNotificationInput" wsaw:Action="/StatusNotification"/>
+ <wsdl:output message="tns:StatusNotificationOutput" wsaw:Action="/StatusNotificationResponse"/>
+ </wsdl:operation>
+
+ <wsdl:operation name="StopTransaction">
+ <wsdl:input message="tns:StopTransactionInput" wsaw:Action="/StopTransaction"/>
+ <wsdl:output message="tns:StopTransactionOutput" wsaw:Action="/StopTransactionResponse"/>
+ </wsdl:operation>
+
+ </wsdl:portType>
+
+
+ <wsdl:binding name="CentralSystemServiceSoap" type="tns:CentralSystemService">
+ <soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/>
+ <wsp:PolicyReference URI="#ServicePolicy"/>
+
+ <wsdl:operation name="Authorize">
+ <soap12:operation soapAction="/Authorize" style="document"/>
+ <wsdl:input>
+ <soap12:header message="tns:Header" part="ChargeBoxIdentity" use="literal"/>
+ <soap12:body use="literal"/>
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="BootNotification">
+ <soap12:operation soapAction="/BootNotification" style="document"/>
+ <wsdl:input>
+ <soap12:header message="tns:Header" part="ChargeBoxIdentity" use="literal"/>
+ <soap12:body use="literal"/>
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="DataTransfer">
+ <soap12:operation soapAction="/DataTransfer" style="document"/>
+ <wsdl:input>
+ <soap12:header message="tns:Header" part="ChargeBoxIdentity" use="literal"/>
+ <soap12:body use="literal"/>
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="DiagnosticsStatusNotification">
+ <soap12:operation soapAction="/DiagnosticsStatusNotification" style="document"/>
+ <wsdl:input>
+ <soap12:header message="tns:Header" part="ChargeBoxIdentity" use="literal"/>
+ <soap12:body use="literal"/>
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="FirmwareStatusNotification">
+ <soap12:operation soapAction="/FirmwareStatusNotification" style="document"/>
+ <wsdl:input>
+ <soap12:header message="tns:Header" part="ChargeBoxIdentity" use="literal"/>
+ <soap12:body use="literal"/>
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="Heartbeat">
+ <soap12:operation soapAction="/Heartbeat" style="document"/>
+ <wsdl:input>
+ <soap12:header message="tns:Header" part="ChargeBoxIdentity" use="literal"/>
+ <soap12:body use="literal"/>
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="MeterValues">
+ <soap12:operation soapAction="/MeterValues" style="document"/>
+ <wsdl:input>
+ <soap12:header message="tns:Header" part="ChargeBoxIdentity" use="literal"/>
+ <soap12:body use="literal"/>
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="StartTransaction">
+ <soap12:operation soapAction="/StartTransaction" style="document"/>
+ <wsdl:input>
+ <soap12:header message="tns:Header" part="ChargeBoxIdentity" use="literal"/>
+ <soap12:body use="literal"/>
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="StatusNotification">
+ <soap12:operation soapAction="/StatusNotification" style="document"/>
+ <wsdl:input>
+ <soap12:header message="tns:Header" part="ChargeBoxIdentity" use="literal"/>
+ <soap12:body use="literal"/>
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="StopTransaction">
+ <soap12:operation soapAction="/StopTransaction" style="document"/>
+ <wsdl:input>
+ <soap12:header message="tns:Header" part="ChargeBoxIdentity" use="literal"/>
+ <soap12:body use="literal"/>
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal"/>
+ </wsdl:output>
+ </wsdl:operation>
+
+ </wsdl:binding>
+
+ <!-- The OCPP Central System Service -->
+ <wsdl:service name="CentralSystemService">
+ <wsdl:documentation>The Central System Service for the Open Charge Point Protocol</wsdl:documentation>
+ <wsdl:port name="CentralSystemServiceSoap12" binding="tns:CentralSystemServiceSoap">
+ <soap12:address location="http://localhost/Ocpp/CentralSystemService/"/>
+ </wsdl:port>
+ </wsdl:service>
+
+</wsdl:definitions>
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+OCPP Charge Point service description
+Version 1.6 FINAL
+
+Copyright © 2010 – 2015 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).
+-->
+
+<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
+ xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
+ xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
+ xmlns:s="http://www.w3.org/2001/XMLSchema"
+ xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
+ xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
+ xmlns:tns="urn://Ocpp/Cp/2015/10/"
+ targetNamespace="urn://Ocpp/Cp/2015/10/"
+ xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
+ xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
+ xmlns:wsa="http://www.w3.org/2005/08/addressing"
+ xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
+ xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
+
+ <wsp:Policy wsu:Id="ServicePolicy">
+ <wsp:ExactlyOne>
+ <wsp:All>
+ <wsaw:UsingAddressing />
+ </wsp:All>
+ </wsp:ExactlyOne>
+ </wsp:Policy>
+
+ <wsdl:types>
+ <s:schema elementFormDefault="qualified" targetNamespace="urn://Ocpp/Cp/2015/10/">
+
+ <!-- Begin of types shared with CentralSystemService -->
+ <s:simpleType name="IdToken">
+ <s:annotation>
+ <s:documentation>Type of string defining identification token, e.g. RFID or credit card number. To be treated as case insensitive.</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:maxLength value="20"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="DecimalOne">
+ <s:annotation>
+ <s:documentation>Decimal with one digit fraction</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:decimal">
+ <s:fractionDigits value="1" />
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="CiString20Type">
+ <s:annotation>
+ <s:documentation>String of maximum 20 printable characters. To be treated as case insensitive.</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:maxLength value="20"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="CiString25Type">
+ <s:annotation>
+ <s:documentation>String of maximum 25 printable characters. To be treated as case insensitive.</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:maxLength value="25"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="CiString50Type">
+ <s:annotation>
+ <s:documentation>String of maximum 50 printable characters. To be treated as case insensitive.</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:maxLength value="50"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="CiString255Type">
+ <s:annotation>
+ <s:documentation>String of maximum 255 printable characters. To be treated as case insensitive.</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:maxLength value="255"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="CiString500Type">
+ <s:annotation>
+ <s:documentation>String of maximum 500 printable characters. To be treated as case insensitive.</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:maxLength value="500"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="AuthorizationStatus">
+ <s:annotation>
+ <s:documentation>Defines the authorization-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted"/>
+ <s:enumeration value="Blocked"/>
+ <s:enumeration value="Expired"/>
+ <s:enumeration value="Invalid"/>
+ <s:enumeration value="ConcurrentTx"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="IdTagInfo">
+ <s:sequence>
+ <s:element name="status" type="tns:AuthorizationStatus" minOccurs="1" maxOccurs="1"/>
+ <s:element name="expiryDate" type="s:dateTime" minOccurs="0" maxOccurs="1"/>
+ <s:element name="parentIdTag" type="tns:IdToken" minOccurs="0" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+ <!-- End of types shared with CentralSystemService -->
+
+ <s:simpleType name="UnlockStatus">
+ <s:annotation>
+ <s:documentation>Defines the unlock-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Unlocked" />
+ <s:enumeration value="UnlockFailed" />
+ <s:enumeration value="NotSupported" />
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="UnlockConnectorRequest">
+ <s:annotation>
+ <s:documentation>Defines the UnlockConnector.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="connectorId" type="s:int" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="UnlockConnectorResponse">
+ <s:annotation>
+ <s:documentation>Defines the UnlockConnector.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:UnlockStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="ResetType">
+ <s:annotation>
+ <s:documentation>Defines the reset-type-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Hard" />
+ <s:enumeration value="Soft" />
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="ResetRequest">
+ <s:annotation>
+ <s:documentation>Defines the Reset.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="type" type="tns:ResetType" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="ResetStatus">
+ <s:annotation>
+ <s:documentation>Defines the reset-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted" />
+ <s:enumeration value="Rejected" />
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="ResetResponse">
+ <s:sequence>
+ <s:element name="status" type="tns:ResetStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="AvailabilityType">
+ <s:annotation>
+ <s:documentation>Defines the availability-type-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Inoperative" />
+ <s:enumeration value="Operative" />
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="ChangeAvailabilityRequest">
+ <s:annotation>
+ <s:documentation>Defines the ChangeAvailability.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="connectorId" type="s:int" minOccurs="1" maxOccurs="1" />
+ <s:element name="type" type="tns:AvailabilityType" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="AvailabilityStatus">
+ <s:annotation>
+ <s:documentation>Defines the availability-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted" />
+ <s:enumeration value="Rejected" />
+ <s:enumeration value="Scheduled" />
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="ChangeAvailabilityResponse">
+ <s:annotation>
+ <s:documentation>Defines the ChangeAvailability.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:AvailabilityStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="GetDiagnosticsRequest">
+ <s:annotation>
+ <s:documentation>Defines the GetDiagnostics.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="location" type="s:anyURI" minOccurs="1" maxOccurs="1" />
+ <s:element name="startTime" type="s:dateTime" minOccurs="0" maxOccurs="1" />
+ <s:element name="stopTime" type="s:dateTime" minOccurs="0" maxOccurs="1" />
+ <s:element name="retries" type="s:int" minOccurs="0" maxOccurs="1" />
+ <s:element name="retryInterval" type="s:int" minOccurs="0" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="GetDiagnosticsResponse">
+ <s:annotation>
+ <s:documentation>Defines the GetDiagnostics.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="fileName" type="tns:CiString255Type" minOccurs="0" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="ClearCacheRequest">
+ <s:annotation>
+ <s:documentation>Defines the ClearCache.req PDU</s:documentation>
+ </s:annotation>
+ </s:complexType>
+
+ <s:simpleType name="ClearCacheStatus">
+ <s:annotation>
+ <s:documentation>Defines the clear-cache-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted" />
+ <s:enumeration value="Rejected" />
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="ClearCacheResponse">
+ <s:annotation>
+ <s:documentation>Defines the ClearCache.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:ClearCacheStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="ChargingProfilePurposeType">
+ <s:annotation>
+ <s:documentation>Defines the charging-profile-purpose-type-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="ChargePointMaxProfile" />
+ <s:enumeration value="TxDefaultProfile" />
+ <s:enumeration value="TxProfile" />
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="ClearChargingProfileRequest">
+ <s:annotation>
+ <s:documentation>Defines the ClearChargingProfile.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="id" type="s:int" minOccurs="0" maxOccurs="1" />
+ <s:element name="connectorId" type="s:int" minOccurs="0" maxOccurs="1" />
+ <s:element name="chargingProfilePurpose" type="tns:ChargingProfilePurposeType" minOccurs="0" maxOccurs="1" />
+ <s:element name="stackLevel" type="s:int" minOccurs="0" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="ClearChargingProfileStatus">
+ <s:annotation>
+ <s:documentation>Defines the clear-charging-profile-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted" />
+ <s:enumeration value="Unknown" />
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="ClearChargingProfileResponse">
+ <s:annotation>
+ <s:documentation>Defines the ClearChargingProfile.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:ClearChargingProfileStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="UpdateFirmwareRequest">
+ <s:annotation>
+ <s:documentation>Defines the UpdateFirmware.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="retrieveDate" type="s:dateTime" minOccurs="1" maxOccurs="1" />
+ <s:element name="location" type="s:anyURI" minOccurs="1" maxOccurs="1" />
+ <s:element name="retries" type="s:int" minOccurs="0" maxOccurs="1" />
+ <s:element name="retryInterval" type="s:int" minOccurs="0" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="UpdateFirmwareResponse">
+ <s:annotation>
+ <s:documentation>Defines the UpdateFirmware.conf PDU</s:documentation>
+ </s:annotation>
+ </s:complexType>
+
+ <s:complexType name="ChangeConfigurationRequest">
+ <s:annotation>
+ <s:documentation>Defines the ChangeConfiguration.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="key" type="tns:CiString50Type" minOccurs="1" maxOccurs="1" />
+ <s:element name="value" type="tns:CiString500Type" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="ConfigurationStatus">
+ <s:annotation>
+ <s:documentation>Defines the configuration-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted" />
+ <s:enumeration value="NotSupported" />
+ <s:enumeration value="RebootRequired" />
+ <s:enumeration value="Rejected" />
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="ChangeConfigurationResponse">
+ <s:annotation>
+ <s:documentation>Defines the ChangeConfiguration.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:ConfigurationStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="RemoteStartTransactionRequest">
+ <s:annotation>
+ <s:documentation>Defines the RemoteStartTransaction.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="connectorId" type="s:int" minOccurs="0" maxOccurs="1" />
+ <s:element name="idTag" type="tns:IdToken" minOccurs="1" maxOccurs="1" />
+ <s:element name="chargingProfile" type="tns:ChargingProfile" minOccurs="0" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="RemoteStartStopStatus">
+ <s:annotation>
+ <s:documentation>Defines the remote-start-stop-status-value</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted" />
+ <s:enumeration value="Rejected" />
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="RemoteStartTransactionResponse">
+ <s:annotation>
+ <s:documentation>Defines the RemoteStartTransaction.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:RemoteStartStopStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="RemoteStopTransactionRequest">
+ <s:annotation>
+ <s:documentation>Defines the RemoteStopTransaction.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="transactionId" type="s:int" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="RemoteStopTransactionResponse">
+ <s:annotation>
+ <s:documentation>Defines the RemoteStopTransaction.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:RemoteStartStopStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="CancelReservationRequest">
+ <s:annotation>
+ <s:documentation>Defines the CancelReservation.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="reservationId" type="s:int" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="CancelReservationStatus">
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted"/>
+ <s:enumeration value="Rejected"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="CancelReservationResponse">
+ <s:annotation>
+ <s:documentation>Defines the CancelReservation.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:CancelReservationStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="DataTransferRequest">
+ <s:annotation>
+ <s:documentation>Defines the DataTransfer.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="vendorId" type="tns:CiString255Type" minOccurs="1" maxOccurs="1" />
+ <s:element name="messageId" type="tns:CiString50Type" minOccurs="0" maxOccurs="1" />
+ <s:element name="data" type="s:string" minOccurs="0" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="DataTransferStatus">
+ <s:annotation>
+ <s:documentation>Defines the status returned in DataTransfer.conf</s:documentation>
+ </s:annotation>
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted" />
+ <s:enumeration value="Rejected" />
+ <s:enumeration value="UnknownMessageId" />
+ <s:enumeration value="UnknownVendorId" />
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="DataTransferResponse">
+ <s:annotation>
+ <s:documentation>Defines the DataTransfer.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:DataTransferStatus" minOccurs="1" maxOccurs="1" />
+ <s:element name="data" type="s:string" minOccurs="0" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="GetConfigurationRequest">
+ <s:annotation>
+ <s:documentation>Defines the GetConfiguration.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="key" type="tns:CiString50Type" minOccurs="0" maxOccurs="unbounded" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="KeyValue">
+ <s:annotation>
+ <s:documentation>Key-Value pairs returned by GetConfiguration.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="key" type="tns:CiString50Type" minOccurs="1" maxOccurs="1" />
+ <s:element name="readonly" type="s:boolean" minOccurs="1" maxOccurs="1" />
+ <s:element name="value" type="tns:CiString500Type" minOccurs="0" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="GetConfigurationResponse">
+ <s:annotation>
+ <s:documentation>Defines the GetConfiguration.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="configurationKey" type="tns:KeyValue" minOccurs="0" maxOccurs="unbounded" />
+ <s:element name="unknownKey" type="tns:CiString50Type" minOccurs="0" maxOccurs="unbounded" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="GetLocalListVersionRequest">
+ <s:annotation>
+ <s:documentation>Defines the GetLocalListVersion.req PDU</s:documentation>
+ </s:annotation>
+ </s:complexType>
+
+ <s:complexType name="GetLocalListVersionResponse">
+ <s:annotation>
+ <s:documentation>Defines the GetLocalListVersion.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="listVersion" type="s:int" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="ChargingRateUnitType">
+ <s:restriction base="s:string">
+ <s:enumeration value="W"/>
+ <s:enumeration value="A"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="ChargingSchedulePeriod">
+ <s:sequence>
+ <s:element name="startPeriod" type="s:int" minOccurs="1" maxOccurs="1" />
+ <s:element name="limit" type="tns:DecimalOne" minOccurs="1" maxOccurs="1" />
+ <s:element name="numberPhases" type="s:int" minOccurs="0" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="ChargingSchedule">
+ <s:sequence>
+ <s:element name="duration" type="s:int" minOccurs="0" maxOccurs="1" />
+ <s:element name="startSchedule" type="s:dateTime" minOccurs="0" maxOccurs="1"/>
+ <s:element name="chargingRateUnit" type="tns:ChargingRateUnitType" minOccurs="1" maxOccurs="1"/>
+ <s:element name="chargingSchedulePeriod" type="tns:ChargingSchedulePeriod" minOccurs="1" maxOccurs="unbounded"/>
+ <s:element name="minChargingRate" type="tns:DecimalOne" minOccurs="0" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="GetCompositeScheduleRequest">
+ <s:annotation>
+ <s:documentation>Defines the GetCompositeSchedule.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="connectorId" type="s:int" minOccurs="1" maxOccurs="1" />
+ <s:element name="duration" type="s:int" minOccurs="1" maxOccurs="1" />
+ <s:element name="chargingRateUnit" type="tns:ChargingRateUnitType" minOccurs="0" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="GetCompositeScheduleStatus">
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted"/>
+ <s:enumeration value="Rejected"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="GetCompositeScheduleResponse">
+ <s:annotation>
+ <s:documentation>Defines the GetCompositeSchedule.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:GetCompositeScheduleStatus" minOccurs="1" maxOccurs="1" />
+ <s:element name="connectorId" type="s:int" minOccurs="0" maxOccurs="1" />
+ <s:element name="scheduleStart" type="s:dateTime" minOccurs="0" maxOccurs="1" />
+ <s:element name="chargingSchedule" type="tns:ChargingSchedule" minOccurs="0" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="ReserveNowRequest">
+ <s:annotation>
+ <s:documentation>Defines the ReserveNow.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="connectorId" type="s:int" minOccurs="1" maxOccurs="1" />
+ <s:element name="expiryDate" type="s:dateTime" minOccurs="1" maxOccurs="1" />
+ <s:element name="idTag" type="tns:IdToken" minOccurs="1" maxOccurs="1" />
+ <s:element name="parentIdTag" type="tns:IdToken" minOccurs="0" maxOccurs="1" />
+ <s:element name="reservationId" type="s:int" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="ReservationStatus">
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted"/>
+ <s:enumeration value="Faulted"/>
+ <s:enumeration value="Occupied"/>
+ <s:enumeration value="Rejected"/>
+ <s:enumeration value="Unavailable"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="ReserveNowResponse">
+ <s:annotation>
+ <s:documentation>Defines the ReserveNow.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:ReservationStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="AuthorizationData">
+ <s:sequence>
+ <s:element name="idTag" type="tns:IdToken" minOccurs="1" maxOccurs="1"/>
+ <s:element name="idTagInfo" type="tns:IdTagInfo" minOccurs="0" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="UpdateType">
+ <s:restriction base="s:string">
+ <s:enumeration value="Differential"/>
+ <s:enumeration value="Full"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="SendLocalListRequest">
+ <s:annotation>
+ <s:documentation>Defines the SendLocalList.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="listVersion" type="s:int" minOccurs="1" maxOccurs="1" />
+ <s:element name="localAuthorizationList" type="tns:AuthorizationData" minOccurs="0" maxOccurs="unbounded" />
+ <s:element name="updateType" type="tns:UpdateType" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="UpdateStatus">
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted"/>
+ <s:enumeration value="Failed"/>
+ <s:enumeration value="NotSupported"/>
+ <s:enumeration value="VersionMismatch"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="SendLocalListResponse">
+ <s:annotation>
+ <s:documentation>Defines the SendLocalList.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:UpdateStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="ChargingProfileKindType">
+ <s:restriction base="s:string">
+ <s:enumeration value="Absolute"/>
+ <s:enumeration value="Recurring"/>
+ <s:enumeration value="Relative"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:simpleType name="RecurrencyKindType">
+ <s:restriction base="s:string">
+ <s:enumeration value="Daily"/>
+ <s:enumeration value="Weekly"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="ChargingProfile">
+ <s:sequence>
+ <s:element name="chargingProfileId" type="s:int" minOccurs="1" maxOccurs="1" />
+ <s:element name="transactionId" type="s:int" minOccurs="0" maxOccurs="1" />
+ <s:element name="stackLevel" type="s:int" minOccurs="1" maxOccurs="1" />
+ <s:element name="chargingProfilePurpose" type="tns:ChargingProfilePurposeType" minOccurs="1" maxOccurs="1"/>
+ <s:element name="chargingProfileKind" type="tns:ChargingProfileKindType" minOccurs="1" maxOccurs="1"/>
+ <s:element name="recurrencyKind" type="tns:RecurrencyKindType" minOccurs="0" maxOccurs="1"/>
+ <s:element name="validFrom" type="s:dateTime" minOccurs="0" maxOccurs="1"/>
+ <s:element name="validTo" type="s:dateTime" minOccurs="0" maxOccurs="1"/>
+ <s:element name="chargingSchedule" type="tns:ChargingSchedule" minOccurs="1" maxOccurs="1"/>
+ </s:sequence>
+ </s:complexType>
+
+ <s:complexType name="SetChargingProfileRequest">
+ <s:annotation>
+ <s:documentation>Defines the SetChargingProfile.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="connectorId" type="s:int" minOccurs="1" maxOccurs="1" />
+ <s:element name="csChargingProfiles" type="tns:ChargingProfile" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="ChargingProfileStatus">
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted"/>
+ <s:enumeration value="Rejected"/>
+ <s:enumeration value="NotSupported"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="SetChargingProfileResponse">
+ <s:annotation>
+ <s:documentation>Defines the SetChargingProfile.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:ChargingProfileStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="MessageTrigger">
+ <s:restriction base="s:string">
+ <s:enumeration value="BootNotification"/>
+ <s:enumeration value="DiagnosticsStatusNotification"/>
+ <s:enumeration value="FirmwareStatusNotification"/>
+ <s:enumeration value="Heartbeat"/>
+ <s:enumeration value="MeterValues"/>
+ <s:enumeration value="StatusNotification"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="TriggerMessageRequest">
+ <s:annotation>
+ <s:documentation>Defines the TriggerMessage.req PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="requestedMessage" type="tns:MessageTrigger" minOccurs="1" maxOccurs="1" />
+ <s:element name="connectorId" type="s:int" minOccurs="0" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+ <s:simpleType name="TriggerMessageStatus">
+ <s:restriction base="s:string">
+ <s:enumeration value="Accepted"/>
+ <s:enumeration value="Rejected"/>
+ <s:enumeration value="NotImplemented"/>
+ </s:restriction>
+ </s:simpleType>
+
+ <s:complexType name="TriggerMessageResponse">
+ <s:annotation>
+ <s:documentation>Defines the TriggerMessage.conf PDU</s:documentation>
+ </s:annotation>
+ <s:sequence>
+ <s:element name="status" type="tns:TriggerMessageStatus" minOccurs="1" maxOccurs="1" />
+ </s:sequence>
+ </s:complexType>
+
+
+ <s:element name="chargeBoxIdentity" type="s:string" />
+ <s:element name="cancelReservationRequest" type="tns:CancelReservationRequest" />
+ <s:element name="cancelReservationResponse" type="tns:CancelReservationResponse" />
+ <s:element name="changeAvailabilityRequest" type="tns:ChangeAvailabilityRequest" />
+ <s:element name="changeAvailabilityResponse" type="tns:ChangeAvailabilityResponse" />
+ <s:element name="changeConfigurationRequest" type="tns:ChangeConfigurationRequest" />
+ <s:element name="changeConfigurationResponse" type="tns:ChangeConfigurationResponse" />
+ <s:element name="clearCacheRequest" type="tns:ClearCacheRequest" />
+ <s:element name="clearCacheResponse" type="tns:ClearCacheResponse" />
+ <s:element name="clearChargingProfileRequest" type="tns:ClearChargingProfileRequest" />
+ <s:element name="clearChargingProfileResponse" type="tns:ClearChargingProfileResponse" />
+ <s:element name="dataTransferRequest" type="tns:DataTransferRequest" />
+ <s:element name="dataTransferResponse" type="tns:DataTransferResponse" />
+ <s:element name="getCompositeScheduleRequest" type="tns:GetCompositeScheduleRequest" />
+ <s:element name="getCompositeScheduleResponse" type="tns:GetCompositeScheduleResponse" />
+ <s:element name="getConfigurationRequest" type="tns:GetConfigurationRequest" />
+ <s:element name="getConfigurationResponse" type="tns:GetConfigurationResponse" />
+ <s:element name="getDiagnosticsRequest" type="tns:GetDiagnosticsRequest" />
+ <s:element name="getDiagnosticsResponse" type="tns:GetDiagnosticsResponse" />
+ <s:element name="getLocalListVersionRequest" type="tns:GetLocalListVersionRequest" />
+ <s:element name="getLocalListVersionResponse" type="tns:GetLocalListVersionResponse" />
+ <s:element name="remoteStartTransactionRequest" type="tns:RemoteStartTransactionRequest" />
+ <s:element name="remoteStartTransactionResponse" type="tns:RemoteStartTransactionResponse" />
+ <s:element name="remoteStopTransactionRequest" type="tns:RemoteStopTransactionRequest" />
+ <s:element name="remoteStopTransactionResponse" type="tns:RemoteStopTransactionResponse" />
+ <s:element name="reserveNowRequest" type="tns:ReserveNowRequest" />
+ <s:element name="reserveNowResponse" type="tns:ReserveNowResponse" />
+ <s:element name="resetRequest" type="tns:ResetRequest" />
+ <s:element name="resetResponse" type="tns:ResetResponse" />
+ <s:element name="sendLocalListRequest" type="tns:SendLocalListRequest" />
+ <s:element name="sendLocalListResponse" type="tns:SendLocalListResponse" />
+ <s:element name="setChargingProfileRequest" type="tns:SetChargingProfileRequest" />
+ <s:element name="setChargingProfileResponse" type="tns:SetChargingProfileResponse" />
+ <s:element name="triggerMessageRequest" type="tns:TriggerMessageRequest" />
+ <s:element name="triggerMessageResponse" type="tns:TriggerMessageResponse" />
+ <s:element name="unlockConnectorRequest" type="tns:UnlockConnectorRequest" />
+ <s:element name="unlockConnectorResponse" type="tns:UnlockConnectorResponse" />
+ <s:element name="updateFirmwareRequest" type="tns:UpdateFirmwareRequest" />
+ <s:element name="updateFirmwareResponse" type="tns:UpdateFirmwareResponse" />
+ </s:schema>
+ </wsdl:types>
+
+
+ <wsdl:message name="Header">
+ <wsdl:part name="ChargeBoxIdentity" element="tns:chargeBoxIdentity" />
+ </wsdl:message>
+
+ <wsdl:message name="CancelReservationInput">
+ <wsdl:part name="parameters" element="tns:cancelReservationRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="CancelReservationOutput">
+ <wsdl:part name="parameters" element="tns:cancelReservationResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="ChangeAvailabilityInput">
+ <wsdl:part name="parameters" element="tns:changeAvailabilityRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="ChangeAvailabilityOutput">
+ <wsdl:part name="parameters" element="tns:changeAvailabilityResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="ChangeConfigurationInput">
+ <wsdl:part name="parameters" element="tns:changeConfigurationRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="ChangeConfigurationOutput">
+ <wsdl:part name="parameters" element="tns:changeConfigurationResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="ClearCacheInput">
+ <wsdl:part name="parameters" element="tns:clearCacheRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="ClearCacheOutput">
+ <wsdl:part name="parameters" element="tns:clearCacheResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="ClearChargingProfileInput">
+ <wsdl:part name="parameters" element="tns:clearChargingProfileRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="ClearChargingProfileOutput">
+ <wsdl:part name="parameters" element="tns:clearChargingProfileResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="DataTransferInput">
+ <wsdl:part name="parameters" element="tns:dataTransferRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="DataTransferOutput">
+ <wsdl:part name="parameters" element="tns:dataTransferResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="GetDiagnosticsInput">
+ <wsdl:part name="parameters" element="tns:getDiagnosticsRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="GetConfigurationInput">
+ <wsdl:part name="parameters" element="tns:getConfigurationRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="GetConfigurationOutput">
+ <wsdl:part name="parameters" element="tns:getConfigurationResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="GetDiagnosticsOutput">
+ <wsdl:part name="parameters" element="tns:getDiagnosticsResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="GetLocalListVersionInput">
+ <wsdl:part name="parameters" element="tns:getLocalListVersionRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="GetLocalListVersionOutput">
+ <wsdl:part name="parameters" element="tns:getLocalListVersionResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="RemoteStartTransactionInput">
+ <wsdl:part name="parameters" element="tns:remoteStartTransactionRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="RemoteStartTransactionOutput">
+ <wsdl:part name="parameters" element="tns:remoteStartTransactionResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="RemoteStopTransactionInput">
+ <wsdl:part name="parameters" element="tns:remoteStopTransactionRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="RemoteStopTransactionOutput">
+ <wsdl:part name="parameters" element="tns:remoteStopTransactionResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="GetCompositeScheduleInput">
+ <wsdl:part name="parameters" element="tns:getCompositeScheduleRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="GetCompositeScheduleOutput">
+ <wsdl:part name="parameters" element="tns:getCompositeScheduleResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="ReserveNowInput">
+ <wsdl:part name="parameters" element="tns:reserveNowRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="ReserveNowOutput">
+ <wsdl:part name="parameters" element="tns:reserveNowResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="ResetInput">
+ <wsdl:part name="parameters" element="tns:resetRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="ResetOutput">
+ <wsdl:part name="parameters" element="tns:resetResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="SendLocalListInput">
+ <wsdl:part name="parameters" element="tns:sendLocalListRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="SendLocalListOutput">
+ <wsdl:part name="parameters" element="tns:sendLocalListResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="SetChargingProfileInput">
+ <wsdl:part name="parameters" element="tns:setChargingProfileRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="SetChargingProfileOutput">
+ <wsdl:part name="parameters" element="tns:setChargingProfileResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="TriggerMessageInput">
+ <wsdl:part name="parameters" element="tns:triggerMessageRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="TriggerMessageOutput">
+ <wsdl:part name="parameters" element="tns:triggerMessageResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="UnlockConnectorInput">
+ <wsdl:part name="parameters" element="tns:unlockConnectorRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="UnlockConnectorOutput">
+ <wsdl:part name="parameters" element="tns:unlockConnectorResponse" />
+ </wsdl:message>
+
+ <wsdl:message name="UpdateFirmwareInput">
+ <wsdl:part name="parameters" element="tns:updateFirmwareRequest" />
+ </wsdl:message>
+
+ <wsdl:message name="UpdateFirmwareOutput">
+ <wsdl:part name="parameters" element="tns:updateFirmwareResponse" />
+ </wsdl:message>
+
+
+ <wsdl:portType name="ChargePointService">
+
+ <wsdl:operation name="CancelReservation">
+ <wsdl:input message="tns:CancelReservationInput" wsaw:Action="/CancelReservation" />
+ <wsdl:output message="tns:CancelReservationOutput" wsaw:Action="/CancelReservationResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="ChangeAvailability">
+ <wsdl:input message="tns:ChangeAvailabilityInput" wsaw:Action="/ChangeAvailability" />
+ <wsdl:output message="tns:ChangeAvailabilityOutput" wsaw:Action="/ChangeAvailabilityResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="ChangeConfiguration">
+ <wsdl:input message="tns:ChangeConfigurationInput" wsaw:Action="/ChangeConfiguration" />
+ <wsdl:output message="tns:ChangeConfigurationOutput" wsaw:Action="/ChangeConfigurationResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="ClearCache">
+ <wsdl:input message="tns:ClearCacheInput" wsaw:Action="/ClearCache" />
+ <wsdl:output message="tns:ClearCacheOutput" wsaw:Action="/ClearCacheResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="ClearChargingProfile">
+ <wsdl:input message="tns:ClearChargingProfileInput" wsaw:Action="/ClearChargingProfile" />
+ <wsdl:output message="tns:ClearChargingProfileOutput" wsaw:Action="/ClearChargingProfileResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="DataTransfer">
+ <wsdl:input message="tns:DataTransferInput" wsaw:Action="/DataTransfer" />
+ <wsdl:output message="tns:DataTransferOutput" wsaw:Action="/DataTransferResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="GetConfiguration">
+ <wsdl:input message="tns:GetConfigurationInput" wsaw:Action="/GetConfiguration" />
+ <wsdl:output message="tns:GetConfigurationOutput" wsaw:Action="/GetConfigurationResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="GetDiagnostics">
+ <wsdl:input message="tns:GetDiagnosticsInput" wsaw:Action="/GetDiagnostics" />
+ <wsdl:output message="tns:GetDiagnosticsOutput" wsaw:Action="/GetDiagnosticsResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="GetLocalListVersion">
+ <wsdl:input message="tns:GetLocalListVersionInput" wsaw:Action="/GetLocalListVersion" />
+ <wsdl:output message="tns:GetLocalListVersionOutput" wsaw:Action="/GetLocalListVersionResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="RemoteStartTransaction">
+ <wsdl:input message="tns:RemoteStartTransactionInput" wsaw:Action="/RemoteStartTransaction" />
+ <wsdl:output message="tns:RemoteStartTransactionOutput" wsaw:Action="/RemoteStartTransactionResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="RemoteStopTransaction">
+ <wsdl:input message="tns:RemoteStopTransactionInput" wsaw:Action="/RemoteStopTransaction" />
+ <wsdl:output message="tns:RemoteStopTransactionOutput" wsaw:Action="/RemoteStopTransactionResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="GetCompositeSchedule">
+ <wsdl:input message="tns:GetCompositeScheduleInput" wsaw:Action="/GetCompositeSchedule" />
+ <wsdl:output message="tns:GetCompositeScheduleOutput" wsaw:Action="/GetCompositeScheduleResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="ReserveNow">
+ <wsdl:input message="tns:ReserveNowInput" wsaw:Action="/ReserveNow" />
+ <wsdl:output message="tns:ReserveNowOutput" wsaw:Action="/ReserveNowResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="Reset">
+ <wsdl:input message="tns:ResetInput" wsaw:Action="/Reset" />
+ <wsdl:output message="tns:ResetOutput" wsaw:Action="/ResetResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="SendLocalList">
+ <wsdl:input message="tns:SendLocalListInput" wsaw:Action="/SendLocalList" />
+ <wsdl:output message="tns:SendLocalListOutput" wsaw:Action="/SendLocalListResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="SetChargingProfile">
+ <wsdl:input message="tns:SetChargingProfileInput" wsaw:Action="/SetChargingProfile" />
+ <wsdl:output message="tns:SetChargingProfileOutput" wsaw:Action="/SetChargingProfileResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="TriggerMessage">
+ <wsdl:input message="tns:TriggerMessageInput" wsaw:Action="/TriggerMessage" />
+ <wsdl:output message="tns:TriggerMessageOutput" wsaw:Action="/TriggerMessageResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="UnlockConnector">
+ <wsdl:input message="tns:UnlockConnectorInput" wsaw:Action="/UnlockConnector" />
+ <wsdl:output message="tns:UnlockConnectorOutput" wsaw:Action="/UnlockConnectorResponse" />
+ </wsdl:operation>
+
+ <wsdl:operation name="UpdateFirmware">
+ <wsdl:input message="tns:UpdateFirmwareInput" wsaw:Action="/UpdateFirmware" />
+ <wsdl:output message="tns:UpdateFirmwareOutput" wsaw:Action="/UpdateFirmwareResponse" />
+ </wsdl:operation>
+
+ </wsdl:portType>
+
+
+ <wsdl:binding name="ChargePointServiceSoap" type="tns:ChargePointService">
+
+ <wsp:PolicyReference URI="#ServicePolicy" />
+ <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />
+
+ <wsdl:operation name="CancelReservation">
+ <soap12:operation soapAction="/CancelReservation" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="ChangeAvailability">
+ <soap12:operation soapAction="/ChangeAvailability" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="ChangeConfiguration">
+ <soap12:operation soapAction="/ChangeConfiguration" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="ClearCache">
+ <soap12:operation soapAction="/ClearCache" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="ClearChargingProfile">
+ <soap12:operation soapAction="/ClearChargingProfile" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="DataTransfer">
+ <soap12:operation soapAction="/DataTransfer" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="GetConfiguration">
+ <soap12:operation soapAction="/GetConfiguration" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="GetDiagnostics">
+ <soap12:operation soapAction="/GetDiagnostics" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="GetLocalListVersion">
+ <soap12:operation soapAction="/GetLocalListVersion" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="RemoteStartTransaction">
+ <soap12:operation soapAction="/RemoteStartTransaction" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="RemoteStopTransaction">
+ <soap12:operation soapAction="/RemoteStopTransaction" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="GetCompositeSchedule">
+ <soap12:operation soapAction="/GetCompositeSchedule" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="ReserveNow">
+ <soap12:operation soapAction="/ReserveNow" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="Reset">
+ <soap12:operation soapAction="/Reset" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="SendLocalList">
+ <soap12:operation soapAction="/SendLocalList" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="SetChargingProfile">
+ <soap12:operation soapAction="/SetChargingProfile" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="TriggerMessage">
+ <soap12:operation soapAction="/TriggerMessage" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="UnlockConnector">
+ <soap12:operation soapAction="/UnlockConnector" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ <wsdl:operation name="UpdateFirmware">
+ <soap12:operation soapAction="/UpdateFirmware" style="document" />
+ <wsdl:input>
+ <soap12:header use="literal" message="tns:Header" part="ChargeBoxIdentity"/>
+ <soap12:body use="literal" />
+ </wsdl:input>
+ <wsdl:output>
+ <soap12:body use="literal" />
+ </wsdl:output>
+ </wsdl:operation>
+
+ </wsdl:binding>
+
+
+ <!-- The OCPP ChargePoint service -->
+ <wsdl:service name="ChargePointService">
+ <wsdl:documentation>The ChargePoint Service for the Open Charge Point Protocol</wsdl:documentation>
+ <wsdl:port name="ChargePointServiceSoap12" binding="tns:ChargePointServiceSoap">
+ <soap12:address location="http://localhost/Ocpp/ChargePointService/" />
+ </wsdl:port>
+ </wsdl:service>
+</wsdl:definitions>
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:CertificateSigned.req",
+ "type": "object",
+ "properties": {
+ "certificateChain": {
+ "type": "string",
+ "maxLength": 10000
+ }
+ },
+ "additionalProperties": false,
+ "required": ["certificateChain"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:CertificateSigned.conf",
+ "definitions": {
+ "CertificateSignedStatusEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/CertificateSignedStatusEnumType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:DeleteCertificate.req",
+ "definitions": {
+ "HashAlgorithmEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "CertificateHashDataType": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "type": "string",
+ "maxLength": 40
+ }
+ },
+ "required": ["hashAlgorithm", "issuerNameHash", "issuerKeyHash", "serialNumber"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateHashData": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ }
+ },
+ "required": ["certificateHashData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:DeleteCertificate.conf",
+ "definitions": {
+ "DeleteCertificateStatusEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Failed", "NotFound"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/DeleteCertificateStatusEnumType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:ExtendedTriggerMessage.req",
+ "definitions": {
+ "MessageTriggerEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "BootNotification",
+ "LogStatusNotification",
+ "FirmwareStatusNotification",
+ "Heartbeat",
+ "MeterValues",
+ "SignChargePointCertificate",
+ "StatusNotification"
+ ]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "requestedMessage": {
+ "$ref": "#/definitions/MessageTriggerEnumType"
+ },
+ "connectorId": {
+ "type": "integer"
+ }
+ },
+ "required": ["requestedMessage"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:ExtendedTriggerMessage.conf",
+ "definitions": {
+ "TriggerMessageStatusEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotImplemented"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/TriggerMessageStatusEnumType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:GetInstalledCertificateIds.req",
+ "definitions": {
+ "CertificateUseEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CentralSystemRootCertificate", "ManufacturerRootCertificate"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateType": {
+ "$ref": "#/definitions/CertificateUseEnumType"
+ }
+ },
+ "required": ["certificateType"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:GetInstalledCertificateIds.conf",
+ "definitions": {
+ "GetInstalledCertificateStatusEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "NotFound"]
+ },
+ "HashAlgorithmEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "CertificateHashDataType": {
+ "javaType": "CertificateHashData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "type": "string",
+ "maxLength": 40
+ }
+ },
+ "required": ["hashAlgorithm", "issuerNameHash", "issuerKeyHash", "serialNumber"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateHashData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ },
+ "minItems": 1
+ },
+ "status": {
+ "$ref": "#/definitions/GetInstalledCertificateStatusEnumType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:GetLog.req",
+ "definitions": {
+ "LogEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["DiagnosticsLog", "SecurityLog"]
+ },
+ "LogParametersType": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "remoteLocation": {
+ "type": "string",
+ "maxLength": 512
+ },
+ "oldestTimestamp": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "latestTimestamp": {
+ "type": "string",
+ "format": "date-time"
+ }
+ },
+ "required": ["remoteLocation"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "log": {
+ "$ref": "#/definitions/LogParametersType"
+ },
+ "logType": {
+ "$ref": "#/definitions/LogEnumType"
+ },
+ "requestId": {
+ "type": "integer"
+ },
+ "retries": {
+ "type": "integer"
+ },
+ "retryInterval": {
+ "type": "integer"
+ }
+ },
+ "required": ["logType", "requestId", "log"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:GetLog.conf",
+ "definitions": {
+ "LogStatusEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "AcceptedCanceled"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/LogStatusEnumType"
+ },
+ "filename": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:InstallCertificate.req",
+ "definitions": {
+ "CertificateUseEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CentralSystemRootCertificate", "ManufacturerRootCertificate"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateType": {
+ "$ref": "#/definitions/CertificateUseEnumType"
+ },
+ "certificate": {
+ "type": "string",
+ "maxLength": 5500
+ }
+ },
+ "required": ["certificateType", "certificate"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:InstallCertificate.conf",
+ "definitions": {
+ "InstallCertificateStatusEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Failed", "Rejected"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/InstallCertificateStatusEnumType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:LogStatusNotification.req",
+ "definitions": {
+ "UploadLogStatusEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "BadMessage",
+ "Idle",
+ "NotSupportedOperation",
+ "PermissionDenied",
+ "Uploaded",
+ "UploadFailure",
+ "Uploading"
+ ]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/UploadLogStatusEnumType"
+ },
+ "requestId": {
+ "type": "integer"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:LogStatusNotification.conf",
+ "type": "object",
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:SecurityEventNotification.req",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "type": "string",
+ "maxLength": 50
+ },
+ "timestamp": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "techInfo": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["type", "timestamp"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:SecurityEventNotification.conf",
+ "type": "object",
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:SignCertificate.req",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "csr": {
+ "type": "string",
+ "maxLength": 5500
+ }
+ },
+ "required": ["csr"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:SignCertificate.conf",
+ "definitions": {
+ "GenericStatusEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:SignedFirmwareStatusNotification.req",
+ "definitions": {
+ "FirmwareStatusEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Downloaded",
+ "DownloadFailed",
+ "Downloading",
+ "DownloadScheduled",
+ "DownloadPaused",
+ "Idle",
+ "InstallationFailed",
+ "Installing",
+ "Installed",
+ "InstallRebooting",
+ "InstallScheduled",
+ "InstallVerificationFailed",
+ "InvalidSignature",
+ "SignatureVerified"
+ ]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/FirmwareStatusEnumType"
+ },
+ "requestId": {
+ "type": "integer"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:SignedFirmwareStatusNotification.conf",
+ "type": "object",
+ "additionalProperties": false
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:SignedUpdateFirmware.req",
+ "definitions": {
+ "FirmwareType": {
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "location": {
+ "type": "string",
+ "maxLength": 512
+ },
+ "retrieveDateTime": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "installDateTime": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "signingCertificate": {
+ "type": "string",
+ "maxLength": 5500
+ },
+ "signature": {
+ "type": "string",
+ "maxLength": 800
+ }
+ },
+ "required": ["location", "retrieveDateTime", "signingCertificate", "signature"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "retries": {
+ "type": "integer"
+ },
+ "retryInterval": {
+ "type": "integer"
+ },
+ "requestId": {
+ "type": "integer"
+ },
+ "firmware": {
+ "$ref": "#/definitions/FirmwareType"
+ }
+ },
+ "required": ["requestId", "firmware"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:1.6:2020:3:SignedUpdateFirmware.conf",
+ "definitions": {
+ "UpdateFirmwareStatusEnumType": {
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Rejected",
+ "AcceptedCanceled",
+ "InvalidCertificate",
+ "RevokedCertificate"
+ ]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/UpdateFirmwareStatusEnumType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+Component ; Description
+AlignedDataCtrlr; Logical Component responsible for configuration relating to the reporting of clock-aligned meter data.
+AuthCtrlr; Logical Component responsible for configuration relating to the use of authorization for Charging Station use.
+AuthCacheCtrlr; Logical Component responsible for configuration relating to the use of a local cache for authorization for Charging Station use.
+CHAdeMOCtrlr; A CHAdeMO Controller component communicates with an EV using the wired CANbus protocol to exchange information and control charging using the CHAdeMO protocol
+ClockCtrlr; Provides a means to configure management of time tracking by Charging Station.
+DeviceDataCtrlr; Logical Component responsible for configuration relating to the exchange and storage of Charging Station Device Model data.
+DisplayMessageCtrlr; Logical Component responsible for configuration relating to the display of messages to Charging Station users.
+ISO15118Ctrlr; Communicates with an EV to exchange information and control charging using the ISO 15118 protocol.
+LocalAuthListCtrlr; Logical Component responsible for configuration relating to the use of Local Authorization Lists for Charging Station use.
+MonitoringCtrlr; Logical Component responsible for configuration relating to the exchange of monitoring event data.
+OCPPCommCtrlr; Logical Component responsible for configuration relating to information exchange between Charging Station and CSMS.
+ReservationCtrlr; Logical Component responsible for configuration relating to reservations.
+SampledDataCtrlr; Logical Component responsible for configuration relating to the reporting of sampled meter data.
+SecurityCtrlr; Logical Component responsible for configuration relating to security of communications between Charging Station and CSMS.
+SmartChargingCtrlr; Logical Component responsible for configuration relating to smart charging.
+TariffCostCtrlr; Logical Component responsible for configuration relating to tariff and cost display.
+TxCtrlr; Logical Component responsible for configuration relating to transaction characteristics and behaviour.
+AccessBarrier; Allows physical access of vehicles to a charging site to be controlled.
+AcDcConverter; Provides a variable DC current source to force energy directly into an EV battery stack, under tight control of the EV's battery management system.
+AcPhaseSelector; Allows a specific AC phase to be selected (typically at EVSE tier) for single phase vehicle charging in order to lower overall (e.g. site) phase imbalance.
+Actuator; A general purpose electro-mechanical output system, with optional completion tracking sensing. Each output should use a Variable instance key indicating the nature of the output.
+AirCoolingSystem; Fans (or equivalent devices) used to provide cooling.
+AreaVentilation; Fans (or equivalent devices) used to ensure that EVs that require ventilation during charging
+BayOccupancySensor; Sensor (optical, ground loop, ultrasonic, etc.) to detect whether the associated parking/charging bay is physically vacant, or is occupied by a vehicle or other obstruction
+BeaconLighting; Beacon Lighting to help EV drivers to locate nearby charging places, and/or to determine charging availability state, usually by color variation.
+CableBreakawaySensor; A sensor that detects when a charging cable (captive or removable) has been forcibly pulled from the Charging Station.
+CaseAccessSensor; Reports when an access door/panel is open
+ChargingStation; The entire Charging Station as a logical entity
+ChargingStatusIndicator; The Charging Status Indicator, provides visible feedback to the user about the connection and charging status of an EVSE/Connector. This is commonly in the form of multi-colored lighting.
+ConnectedEV; ConnectedEV is a component that represents a connected vehicle for which data is received via an ISO 15118 or CHAdeMO interface. The generic information that is received, is represented as variables of ConnectedEV. Any protocol-specific information is represented in variables of the ISO15118Ctrlr or CHAdeMOCtrlr component.
+Connector; A means to connect an EV to a Charging Station with either a socket, an attached cable & inline connector, or any wireless power transfer device.
+ConnectorHolsterRelease; A mechanism present in a connector holster to prevent the connector from being removed inappropriately: typically unlocks connector after authorization.
+ConnectorHolsterSensor; A mechanism to report when a tethered cable connector has been removed from its normal stowage position. May be used for detection of connectors left un-holstered, and possible penalty billing.
+ConnectorPlugRetentionLock; Locking mechanism to retain an inserted plug, both to prevent on-load disconnection, and to prevent theft of charging cables
+ConnectorProtectionRelease; External protective mechanism (e.g. an external shutter or a connector holster lock mechanism) to prevent contact with conductors that may become 'live' under other failure modes
+Controller; An embedded logic controller
+ControlMetering; Energy, Power, Electricity meter, used to measure energy, current, voltages etc.
+CPPWMController; Control Pilot PWM Controller: provides and senses the IEC 61851-1 / SAE J1772 low voltage DC and PWM signalling between an EVSE and EV over a control pilot line.
+DataLink; Provides a communications link from a Charging Station to a CSMS. It may use fixed infrastructure, mobile telephony data services, WiFi, or other connectivity channels.
+Display; Provides information and feedback to the user.
+DistributionPanel; Defines the Distribution Panel, with it's fuses and connections to both Charging Stations and other Distribution Panel's.
+ElectricalFeed; Represents an incoming electrical connection to a Charging Station, that may be a grid/distribution network connection, of a connection to local power generation and/or storage. Each electrical feed can record the electrical and other characteristics of that feed, including power rating, fusing, upstream metering, etc. When a Charging Station has more than one electrical feed, it must represent which feed supplies each EVSE, and which feed supplies the house load of the Charging Station itself. Simple Charging Stations with only a single electrical feed may omit all electrical feed information, in which case it is inferred that all power is supplied from a single feed, and what would otherwise be ElectricalFeed data (Variables) may be reported as being associated with the ChargingStation component.
+ELVSupply; Represents the low voltage power supply (typically 12V DC and often other ELV voltages) that provides operating power for controllers, relays, and other electrical components.
+EmergencyStopSensor; An 'Emergency Stop' button that should be pressed by the user or other nearby persons if serious faulty behavior is observed (e.g. smoke/flames from EV or Charging Station).
+EnvironmentalLighting; Provides reporting/control of general illumination lighting in use at Charging Station.
+EVRetentionLock; A locking mechanism on the EV side as a safety measure to prevent it being disconnected while high currents are flowing.
+EVSE; The entire chain of components responsible for transporting energy from the incoming supply to the electric vehicle (or vice versa)
+ExternalTemperatureSensor; Reports ambient air temperature
+FiscalMetering; Provides energy transfer readings that are the basis for billing.
+FloodSensor; A sensor reporting whether the Charging Station is experiencing water ingress/pooling.
+GroundIsolationProtection; An Isolation Tester as part of their own self-test mechanisms, to confirm the isolation of floating circuitry when no Evs are connected
+Heater; Heater to ensure reliable operation in cold environments
+HumiditySensor; Reports relative air humidity
+LightSensor; Reports ambient light levels.
+LiquidCoolingSystem; A liquid based cooling system, typically used to cool the connector cables of very high power Charging Stations.
+LocalAvailabilitySensor; Accepts local signal inputs controlling whether new Charging Sessions can start and/or whether ongoing sessions should continue. Typically connected to a site/building power supply, to automatically report unavailability when closed.
+LocalController; The entire Local Controller as a logical entity
+LocalEnergyStorage; Energy storage
+OverCurrentProtection; Protects equipment by disconnecting the electrical supply when the current drawn (on any phase) exceeds the rated value to a substantial degree.
+OverCurrentProtectionRecloser; Recloser mechanism of an OverCurrentProtection to perform re-arm retries after a trip, or may be set for remotely controlled re-arming on command.
+PowerContactor; Switches on and off the power to the EV after all authorization and safety requirements have been met. May have secondary contacts to report closure state.
+RCD; A Residual Current Device (US: ground fault breaker) protects human life and/or downstream equipment by quickly detecting abnormal current flows (usually indicative in earth faults) in the Charging Station, cable, or EV during charging.
+RCDRecloser; A motorized recloser mechanism of an RCD that may be configured to perform re-arm retries after a trip, or may be set for remotely controlled re-arming on command.
+RealTimeClock; Represents realtime clock hardware that can maintain accurate date & time information in a Charging Station, even in the case of simultaneous CSMS uncontactability and power outages or resets.
+ShockSensor; Measures impact forces/accelerations experienced, indicative of possible damage.
+SpacesCountSignage; Electronic signage allowing a charging controller for a large charging facility to advertise counts of available spaces to passing traffic.
+Switch; A general purpose electromechanical input device, with optional remote defaulting/resetting of values. Each input should use a Variable instance key indicating the nature of the input.
+TemperatureSensor; Temperature sensor at a point inside the Charging Station, multiple sensing points for a single sensing controller. Multiple sensing points for a single sensing controller may be reported using distinct Variable instance keys.
+TiltSensor; Measures Tilt angle from normal reference position (normally 90 degree vertical).
+TokenReader; An authorization token reader (e.g. RFID)
+UpstreamProtectionTrigger; Circuitry designed to trigger the disconnection of power to the structure by an upstream protection device after a severe problem has been detected
+UIInput; A logical input mechanism (e.g. set of buttons) that is part of a UI whose use may be communicated to the CSMS (in near real time). May support momentary inputs ('Operated') or modal state ('Active'). Multiple input sources should use explicit Variable instance keys (where the input function is key name).
+VehicleIdSensor; Reports an identifier associated with a vehicle occupying a charging bay. The identifier may be a vehicle registration number via ANPR hardware, a VIN, or other local identifier of the vehicle based on medium range/active RFID, or any other relevant technology and result.
+
--- /dev/null
+Specific Component;Variable;Instance;Required?;DataType;Unit;Description
+<generic>;ACCurrent;;no;decimal;A;RMS AC Current (in amperes). For 3-phase circuits, each phase (and optional neutral) is represented by a Variable instance equal to a value of the PhaseEnumType (e.g. L1,N). Unkeyed values reported for a Component declared to be multi-phase are assumed to be an average of all per-phase readings and written values are common per-phase settings. Example(s): ChargingStation: Total AC current consumption (all EVSE’s, ancillaries), EVSE: Total current consumed by EVSE: includes losses (AC->DC) and EVSE specific ancillaries (e.g. fans), ElectricalFeed: Inflow AC current on feed
+<generic>;Active;;no;boolean;;Component is in its non-resting / active state: e.g: On, Engaged, Locked. Some Components may have secondary functions that have corresponding Active Variables with an explicit Variable instance., Note: Monitoring of changes in the Active state of any Component can be specified by setting Delta monitoring on the boolean value with a delta values of 1. Setting/clearing an Active Variable activates/stops the associated functionality, where remotely controllable. Only components that are Available and Enabled can be in the Active state.
+<generic>;ACVoltage;;no;decimal;V;RMS AC Voltage (in volts). For 3-phase circuits, each phase (and optional neutral) is represented by a Variable instance equal to a value of the PhaseEnumType (e.g. L1,N). Unkeyed values reported for a Component declared to be multi-phase are assumed to be an average ofall per-phase readings and written values are common per-phase settings. Example(s): ElectricalFeed: Input Voltage
+<generic>;AllowReset;;no;boolean;;Component can be reset.
+<generic>;Angle;;no;decimal;Deg;Angle(s) relative to normal/design idle position. Multiple Variable instance values may be used to indicate angular position in multiple axes (e.g. Left-Right, Forward-Back).
+<generic>;Attempts;;no;integer;;Number of attempts (INCLUDING the original attempt) in the last successful or attempted, cycle of operation. Applies typically to self-monitoring motorized electro-mechanical equipment, etc. {Null}: Unknown, 0: Not Attempted/Not allowed, 1: Single attempt/No retries [allowed], 2-N: [up to] N tries [allowed]
+<generic>;Available;;no;boolean;;The Component exists and is locally configured/wired for use, but might not be (remotely) Enabled.
+<generic>;Certificate;;no;string;;Digital Certificate (in Base64 encoding)
+<generic>;Color;;no;string;;Standard 24 bit hexadecimal RGB values. Reg Green Blue color intensity, expressed as standard 24 bit hexadecimal RGB values: 3 00-FF (0-255), in order RRGGBB). E.g. 000000: Black, FF0000: Red, 00FF00: Green, 0000FF: Blue, FFFF00:Yellow, FFFFFF: White, 008000: Medium intensity green.
+<generic>;Complete;;no;boolean;;Component operation cycle has completed. Used only in event notifications, where it is always true.
+<generic>;ConnectedTime;;no;decimal;s;Time since logical connection established
+<generic>;Count;;no;integer;;General purpose integer count variable for Component state reporting
+<generic>;CurrentImbalance;;no;decimal;Percent;Percentage current imbalance in an AC three phase supply.
+<generic>;DataText;;no;string;;Text associated with a Component, e.g. a Display.
+<generic>;DateTime;;no;dateTime;;Point in time value, in [RFC3339] datetime format. Time zone optional.
+<generic>;DCCurrent;;no;decimal;A;DC Current (in amperes). May be an instantaneous measurement, or a period average, depending on context/equipment.
+<generic>;DCVoltage;;no;decimal;V;DC Voltage (volts). May be an instantaneous measurement, or a period average, depending on context/equipment.
+<generic>;ECVariant;;no;string;;Production series variants reflecting internal design changes or sub-component substitutions not affecting external functionality.
+<generic>;Enabled;;no;boolean;;The Component is Enabled for operation. For Available components that cannot be selectively (remotely) enabled / disabled, this value is always true. Note: Available cannot be false of Enabled is true, so during inventory reporting, Enabled=1 also logically states Available=true
+<generic>;Energy;;no;decimal;Wh, kWh;Energy quantity (in Wh) for reporting/configuring values related to stored energy (i.e. not transferred energy).
+<generic>;Entries;;no;integer;;General purpose variable for reporting/managing numbers of entries in repetitive data structures. maxLimit characteristic reports maximum possible entries.
+<generic>;Fallback;;no;boolean;;Component is operating in a fallback, or backup mode. In inventory reports, a Value of 1 for the maxLimit characteristic indicates that the component can enter a fallback state (i.e. a fallback mode is present).
+<generic>;FanSpeed;;no;decimal;RPM;Fan Speed (in RPM). A value of 0 represents stopped/stalled. An empty value indicates that fan speed cannot be read.
+<generic>;FirmwareVersion;;no;string;;Version number of firmware.
+<generic>;Force;;no;decimal;N;Reports (impact) force/ acceleration values (estimates) in one or more directions, in units of Newtons or “g”. Multiple force readings in different (orthogonal) dimensions may be reported using Variable instance values, such as Down, Right, Forward.
+<generic>;Formats;;no;MemberList;;List of message formats supported by this Charging Station. Possible values: ASCII, HTML, URI, UTF-8.
+<generic>;Frequency;;no;decimal;Hz;Frequency of AC power, signal, or component operation.
+<generic>;FuseRating;;no;decimal;A;Current rating of a fuse/breaker. Variable instances keyed by phase identifier (L1/L2/L3/N).
+<generic>;Height;;no;decimal;m;Height above(+)/below(-) reference level (ground level unless context demands otherwise).
+<generic>;Humidity;;no;decimal;RH;The relative humidity in %.
+<generic>;Hysteresis;;no;decimal;Percent;Specifies the width of a 'dead band' (as a percentage of the threshold) around the central value of a threshold setting (e.g. MinSet, MaxSet, monitor thresholds) to avoid repeated triggering when the measured quantity lies close to the threshold and is subject to small variations.
+<generic>;ICCID;;no;string;;ICCID (Integrated Circuit Card IDentifier) of mobile data SIM card.
+<generic>;Impedance;;no;decimal;Ohm;Impedance: Primary value is real (resistive only) impedance. Where a complex impedance is to be reported, the imaginary part (reactance) must be represented with a separate Variable instance value of 'reactance'. Reactance values are expressed at the (nominal) relevant operating frequency of the Component (e.g. 50/60Hz for mains electricity feed).
+<generic>;IMSI;;no;string;;IMSI (International Mobile Subscriber Identity) number of mobile data SIM card
+<generic>;Interval;;no;integer;s;Minimum Interval (in seconds) between (attempted) operations.
+<generic>;Length;;no;decimal;m;General Purpose linear distance measure.
+<generic>;Light;;no;decimal;lx;(Ambient) light level. The value is in Lux.
+<generic>;Manufacturer;;no;string;;Component Manufacturer name
+<generic>;Message;;no;string;;Specific stored message for display.
+<generic>;MinimumStatusDuration;;no;integer;s;Minimum duration that a Charging Station or EVSE status is stable before StatusNotificationRequest is sent to the CSMS.
+<generic>;Mode;;no;string;;Operating mode string from among valid options (communicated by OptionList, etc. during capability/configuration discovery).
+<generic>;Model;;no;string;;"Manufacturer's Model code/number of Component, including suffixes etc. to identify functional, regional or linguistic variation, but NOT engineering change level internal variation not affecting external behaviour, etc."
+<generic>;NetworkAddress;;no;string;;Current network address of a Component.
+<generic>;Operated;;no;boolean;;The Component operated in an instantaneous, transient, or immediately self-resetting pattern. Used only in event notifications, where it is always true.
+<generic>;OperatingTimes;;no;string;;Recurring operating times in iCalendar RRULE format.
+<generic>;Overload;;no;boolean;;Component is in Overload state.
+<generic>;Percent;;no;decimal;Percent;Generic dimensionless value reporting/setting value.
+<generic>;PhaseRotation;;no;OptionList;;The phase wiring of Component, relative to it's upstream feed Component/device. This variable describes the phase rotation of a Component relative to its parent Component, using a three letter string consisting of the letters: R, S, T and x. The letter 'R' can be identified as phase 1 (L1), 'S' as phase 2 (L2), 'T' as phase 3 (L3). The lower case 'x' is used to designate a phase that is not connected. An empty string means that phase rotation is not applicable or not known.
+<generic>;PostChargingTime;;no;decimal;s;Elapsed time in seconds since last substantive energy transfer
+<generic>;Power;;no;decimal;W, kW;Instantaneous (real) Power (measured/calculated, including power factor for AC). Where a component (e.g. AC to DC Power Converter) has multiple power measurements, the default (unkeyed) instance is “input” power.
+<generic>;Problem;;no;boolean;;Component itself has a 'Problem' condition that impacts in any significant way on its normal operation. By definition, 'Problem' state includes (logical OR) 'Fault' state. 'Problem' specifically INCLUDES inability to operate that is propagated (up/down/sideways) from any other associated/connected/containing/contained Component.
+<generic>;Protecting;;no;boolean;;Applies to 'sensor' type Components that have an associated protection capability, whereby they can disconnect power (e.g. using the main PowerContactor) if the sensed quantity is outside preset/configured limits. If Protecting is true, the Component is actively preventing/interrupting charging.
+<generic>;SerialNumber;;no;string;;Serial number of Component.
+<generic>;SignalStrength;;no;decimal;dBm;(Radio/Wired/Optical) data signal strength, in ASU (typically 0-31 or 99 for unknown). Or dbmW (typically -140 to -50).
+<generic>;State;;no;string;;A state code or name identifier string, to allow the internal state of components to be reported and/or controlled
+<generic>;StateOfCharge;;no;decimal;Percent;Energy Storage Device (e.g. battery) state of charge, expressed as a percentage of nominal design 0-100% operating range. Note: Values below or above 0-100% are possible and represent over discharged/charged states.
+<generic>;Storage;;no;integer;B;In bytes. Amount of storage occupied. Storage(maxLimit) specifies absolute limit Storage(MaxSet) restricts usage to specified Max, if supported.
+<generic>;SupplyPhases;;no;integer;;Number of alternating current phases connected/available. 1 or 3 for AC, 0 means DC (no alternating phases). Null value indicates that the number of phases (e.g. in use) is unknown.
+<generic>;Suspending;;no;boolean;;If Suspending is true, the Component can is currently suspending charging.
+<generic>;Suspension;;no;boolean;;Applies to 'sensor' type Components that have a charging suspension capability, typically for safety or equipment protection reasons. If Suspension is true, the component can suspend charging when the sensed quantity is outside preset/configured limits.
+<generic>;Temperature;;no;decimal;Celsius, Fahrenheit;Temperature(s) of component (in Celsius, by default). Components may have multiple indexed temperature sensors.
+<generic>;Time;;no;dateTime;;Point in time value, in ISO 8601 datetime format. Time zone optional.
+<generic>;Timeout;;no;decimal;s;Generic timeout value for Component operation (in seconds).
+<generic>;Tries;;no;integer;;Number of attempts done by a Component.
+<generic>;Tripped;;no;boolean;;Single-shot device requires explicit intervention to re-prime/activate to normal.
+<generic>;VendorName;;no;string;;Vendor or manufacturer of component.
+<generic>;VersionDate;;no;dateTime;;Version date of component in [RFC3339] format.
+<generic>;VersionNumber;;no;string;;Version number of hardware
+<generic>;VoltageImbalance;;no;decimal;Percent;Percentage voltage imbalance in three phase supply.
+AlignedDataCtrlr;Available;;no;boolean;;If this variable reports a value of true, Clock-Aligned Data is supported.
+AlignedDataCtrlr;Enabled;;no;boolean;;If this variable reports a value of true, Clock-Aligned Data is enabled
+AlignedDataCtrlr;Interval;;yes;integer;s;Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the MeterValuesRequest message.
+AlignedDataCtrlr;Measurands;;yes;MemberList;;Clock-aligned measurand(s) to be included in MeterValuesRequest, every AlignedDataInterval seconds.
+AlignedDataCtrlr;SendDuringIdle;;no;boolean;;If set to true, the Charging Station SHALL NOT send clock aligned meter values when a transaction is ongoing.
+AlignedDataCtrlr;SignReadings;;no;boolean;;If set to true, the Charging Station SHALL include signed meter values in the SampledValueType in the MeterValuesRequest to the CSMS.
+AlignedDataCtrlr;TxEndedInterval;;yes;integer;s;Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the TransactionEventRequest (eventType = Ended) message.
+AlignedDataCtrlr;TxEndedMeasurands;;yes;MemberList;;Clock-aligned measurands to be included in the meterValues element of TransactionEventRequest (eventType = Ended), every SampledDataTxEndedInterval seconds from the start of the transaction.
+AuthCacheCtrlr;Available;;no;boolean;;Authorization caching is available, but not necessarily enabled.
+AuthCacheCtrlr;Enabled;;no;boolean;;If set to true, Authorizaiton caching is enabled.
+AuthCacheCtrlr;LifeTime;;no;integer;;Indicates how long it takes until a token expires in the authorization cache since it is last used
+AuthCacheCtrlr;Policy;;no;OptionList;;Cache Entry Replacement Policy: least recently used, least frequently used, first in first out, other custom mechanism.
+AuthCacheCtrlr;Storage;;no;integer;B;Indicates the number of bytes currently used by the Authorization Cache. MaxLimit indicates the maximum number of bytes that can be used by the Authorization Cache.
+AuthCacheCtrlr;DisablePostAuthorize;;no;boolean;;When set to true this variable disables the behavior to request authorization for an idToken that is stored in the cache with a status other than Accepted, as stated in C10.FR.03 and C12.FR.05.
+AuthCtrlr;AdditionalInfoItemsPerMessage;;no;integer;;Maximum number of AdditionalInfo items that can be sent in one message.
+AuthCtrlr;AuthorizeRemoteStart;;yes;boolean;;Whether a remote request to start a transaction in the form of RequestStartTransactionRequest message should be authorized beforehand like a local action to start a transaction.
+AuthCtrlr;Enabled;;no;boolean;;If set to false, then no authorization is done before starting a transaction or when reading an idToken. If an idToken was provided, then it will be put in the idToken field of the TransactionEventRequest. If no idToken was provided, then idToken in TransactionEventRequest will be left empty and type is set to NoAuthorization.
+AuthCtrlr;LocalAuthorizeOffline;;yes;boolean;;Whether the Charging Station, when Offline, will start a transaction for locally-authorized identifiers
+AuthCtrlr;LocalPreAuthorize;;yes;boolean;;Whether the Charging Station, when online, will start a transaction for locally-authorized identifiers without waiting for or requesting an AuthorizeResponse from the CSMS.
+AuthCtrlr;MasterPassGroupId;;no;string;;IdTokens that have this id as groupId belong to the Master Pass Group. Meaning they can stop any ongoing transaction, but cannot start transactions.
+AuthCtrlr;OfflineTxForUnknownIdEnabled;;no;boolean;;Support for unknown offline transactions.
+AuthCtrlr;DisableRemoteAuthorization;;no;boolean;;When set to true this instructs the Charging Station to not issue any AuthorizationRequests, but only use Authorization Cache and Local Authorization List to determine validity of idTokens.
+CHAdeMOCtrlr;SelftestActive;;no;boolean;;Self-test is active or self-test is started by setting to true.
+CHAdeMOCtrlr;CHAdeMOProtocolNumber;;no;integer;;CHAdeMO protocol number (H'102.0)
+CHAdeMOCtrlr;VehicleStatus;;no;boolean;;Vehicle status (H'102.5.3)
+CHAdeMOCtrlr;DynamicControl;;no;boolean;;Vehicle is compatible with dynamic control (H'110.0.0)
+CHAdeMOCtrlr;HighCurrentControl;;no;boolean;;Vehicle is compatible with high current control (H'110.0.1)
+CHAdeMOCtrlr;HighVoltageControl;;no;boolean;;Vehicle is compatible with high voltage control (H'110.1.2)
+CHAdeMOCtrlr;AutoManufacturerCode;;no;integer;;Auto manufacturer code (H'700.0)
+ChargingStation;AllowNewSessionsPendingFirmwareUpdate;;no;boolean;;Indicates whether new sessions can be started on EVSEs, while Charging Station is waiting for all EVSEs to become Available in order to start a pending firmware update
+ChargingStation;AvailabilityState;;yes;OptionList;;This variable reports current availability state for the ChargingStation
+ChargingStation;Available;;yes;boolean;;Component exists
+ChargingStation;Model;;no;string;;Charging station model as reported in BootNotification.
+ChargingStation;SupplyPhases;;yes;integer;;Number of alternating current phases connected/available.
+ChargingStation;VendorName;;no;string;;Charging station vendor name as reported in BootNotification.
+ClockCtrlr;DateTime;;yes;dateTime;;Contains the current date and time
+ClockCtrlr;NextTimeOffsetTransitionDateTime;;no;dateTime;;Date time of the next time offset transition.
+ClockCtrlr;NtpServerUri;;no;string;;This contains the address of the NTP server.
+ClockCtrlr;NtpSource;;no;OptionList;;When an NTP client is implemented, this variable can be used to configure the client
+ClockCtrlr;TimeAdjustmentReportingThreshold;;no;integer;;If set, then time adjustments with an absolute value in seconds larger than this need to be reported as a security event SettingSystemTime
+ClockCtrlr;TimeOffset;;no;string;;A Time Offset with respect to Coordinated Universal Time (aka UTC or Greenwich Mean Time) in the form of an [RFC3339] time (zone) offset suffix, including the mandatory “+” or “-“ prefix.
+ClockCtrlr;TimeSource;;yes;SequenceList;;Via this variable, the Charging Station provides the CSMS with the option to configure multiple clock sources
+ClockCtrlr;TimeZone;;no;string;;"Configured current local time zone in the format: ""Europe/Oslo"", ""Asia/Singapore"" etc. For display purposes."
+ConnectedEV;ProtocolAgreed;;no;string;;Information about uri and version that was agreed upon between EV and EVSE in the supportedAppProtocolReq message from ISO 15118. Example: urn:iso:15118:2:2013:MsgDef,2,0
+ConnectedEV;ProtocolSupportedByEV;<Priority>;no;string;;Information from the supportedAppProtocolReq message from ISO 15118. Each priority is given its own variable instance. Example: urn:iso:15118:2:2013:MsgDef,2,0
+ConnectedEV;VehicleID;;no;string;;EVCCID (from ISO 15118 SessionSetupReq)
+Connector;AvailabilityState;;no;OptionList;;This variable reports current availability state for the Connector. Optional, because already reported in StatusNotification.
+Connector;Available;;yes;boolean;;Component exists
+Connector;ChargeProtocol;;no;string;;The Charging Control Protocol applicable to a Connector. CHAdeMO: CHAdeMO protocol, ISO15118: ISO15118 V2G protocol (wired or wireless) as used with CCS, CPPWM: IEC61851-1 / SAE J1772 protocol (ELV DC & PWM signalling via Control Pilot wire), Uncontrolled: No charging power management applies (e.g. Schuko socket), Undetermined: Yet to be determined (e.g. before plugged in), Unknown: Not determinable, NOTE: ChargeProtocol is distinct from and orthogonal to connectorType.
+Connector;ConnectorType;;yes;string;;A value of ConnectorEnumType (See part 2) plus additionally: cGBT, cChaoJi, OppCharge. Specific type of connector, including sub-variant information. Note: Distinct and orthogonal to Charging Protocol, Power Type, Phases.
+Connector;SupplyPhases;;yes;integer;;Number of alternating current phases connected/available.
+Controller;MaxMsgElements;;no;integer;;Array of implementation-defined limits to the number of elements of specific type that the Charging Station can accept in one message.
+CPPWMController;State;;no;string;;"IEC 61851-1 states (""A"" to ""E"")"
+CustomizationCtrlr;CustomImplementationEnabled;<vendorId>;no;boolean;;Custom implementation <vendorId> has been enabled.
+DeviceDataCtrlr;BytesPerMessage;GetReport;yes;integer;;Maximum number of bytes in a message related to instance name: GetReport, GetVariables, SetVariables
+DeviceDataCtrlr;BytesPerMessage;GetVariables;yes;integer;;Maximum number of bytes in a message related to instance name: GetReport, GetVariables, SetVariables
+DeviceDataCtrlr;BytesPerMessage;SetVariables;yes;integer;;Maximum number of bytes in a message related to instance name: GetReport, GetVariables, SetVariables
+DeviceDataCtrlr;ConfigurationValueSize;;no;integer;;The limit to the following fields: SetVariableData.attributeValue and VariableCharacteristics.valueList. The max size of these values will always remain equal.
+DeviceDataCtrlr;ItemsPerMessage;GetReport;yes;integer;;Maximum number of ComponentVariable entries in message related to the instance name: GetReport, GetVariables, SetVariables
+DeviceDataCtrlr;ItemsPerMessage;GetVariables;yes;integer;;Maximum number of ComponentVariable entries in message related to the instance name: GetReport, GetVariables, SetVariables
+DeviceDataCtrlr;ItemsPerMessage;SetVariables;yes;integer;;Maximum number of ComponentVariable entries in message related to the instance name: GetReport, GetVariables, SetVariables
+DeviceDataCtrlr;ReportingValueSize;;no;integer;;The limit to the following fields: GetVariableResult.attributeValue, VariableAttribute.value and EventData.actualValue. The max size of these values will always remain equal.
+DeviceDataCtrlr;ValueSize;;no;integer;;Can be used to limit the following fields: SetVariableData.attributeValue, GetVariableResult.attributeValue, VariableAttribute.value, VariableCharacteristics.valueList and EventData.actualValue.
+DisplayMessageCtrlr;Available;;no;boolean;;Whether display messages are supported.
+DisplayMessageCtrlr;DisplayMessages;;yes;integer;;Amount of different messages that are currently configured in this Charging Station, via SetDisplayMessageRequest
+DisplayMessageCtrlr;Enabled;;no;boolean;;Whether display messages are enabled.
+DisplayMessageCtrlr;PersonalMessageSize;;no;integer;;Max size (in characters) of the personal message element of the IdTokenInfo data (0 specifies no personal data may be stored).
+DisplayMessageCtrlr;SupportedFormats;;yes;MemberList;;List of message formats supported by this Charging Station.
+DisplayMessageCtrlr;SupportedPriorities;;yes;MemberList;;List of the priorities supported by this Charging Station.
+DistributionPanel;ChargingStation;;no;string;;Identity of charging station connected to the distribution panel.
+DistributionPanel;DistributionPanel;;no;string;;List of Distribution Panels InstanceNames connected to this LocalController.
+DistributionPanel;Fuse;<n>;no;integer;A;Fuse (index n) is the fuse for phase Ln in Ampere
+EVSE;AllowReset;;no;boolean;;Can be used to announce that an EVSE can be reset individually
+EVSE;AvailabilityState;;yes;OptionList;;This variable reports current availability state for the EVSE
+EVSE;Available;;yes;boolean;;Component exists
+EVSE;EvseId;;no;string;;The name of the EVSE in the string format as required by ISO 15118 and IEC 63119-2.
+EVSE;Power;;yes;decimal;W, kW;The variableCharacteristic maxLimit, that holds the maximum power that this EVSE can provide, is required. The Actual value of the instantaneous (real) power is desired, but not required.
+EVSE;SupplyPhases;;yes;integer;;Number of alternating current phases connected/available.
+EVSE;ISO15118EvseId;;no;string;;"The name of the EVSE in the string format as required by ISO 15118 and IEC 63119-2. Example: ""DE*ICE*E*1234567890*1"""
+FiscalMetering;EnergyExport;;no;decimal;Wh, kWh;Total energy transferred: e.g. from EV during (ongoing or terminated) charging session (in wH by default)
+FiscalMetering;EnergyExportRegister;;no;decimal;Wh, kWh;Cumulative export kWh register value, such as from a (certified) fiscal energy meter.
+FiscalMetering;EnergyImport;;no;decimal;Wh, kWh;Total energy transferred.
+FiscalMetering;EnergyImportRegister;;no;decimal;Wh, kWh;Cumulative export kWh register value, such as from a (certified) fiscal energy meter.
+ISO15118Ctrlr;CentralContractValidationAllowed;;no;boolean;;If this variable exists and has the value true, then Charging Station can provide a contract certificate that it cannot validate, to the CSMS for validation as part of the AuthorizeRequest.
+ISO15118Ctrlr;ContractValidationOffline;;yes;boolean;;If this variable is true, then Charging Station will try to validate a contract certificate when it is offline
+ISO15118Ctrlr;SeccId;;no;string;;The ID of the SECC in string format as defined by ISO15118.
+ISO15118Ctrlr;MaxScheduleEntries;;no;integer;;Maximum number of allowed schedule periods.
+ISO15118Ctrlr;RequestedEnergyTransferMode;;no;OptionList;;The requested energy transfer mode.
+ISO15118Ctrlr;RequestMeteringReceipt;;no;boolean;;If true, then Charging Station shall request a metering receipt from EV.
+ISO15118Ctrlr;CountryName;;no;string;;"The countryName of the SECC in the ISO 3166-1 format. It is used as the countryName (C) of the SECC leaf certificate. Example: ""DE"""
+ISO15118Ctrlr;OrganizationName;;no;string;;"The organizationName of the CSO operating the charging station. It is used as the organizationName (O) of the SECC leaf certificate. Example: ""John Doe Charging Services Ltd"" Note: This value will usually be identical to SecurityCtrlr.OrganizationName, but it does not have to be."
+ISO15118Ctrlr;PnCEnabled;;no;boolean;;If this variable is true, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is enabled. If this variable is false, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is disabled.
+ISO15118Ctrlr;V2GCertificateInstallationEnabled;;no;boolean;;If this variable is true, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station is enabled. If this variable is false, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station is disabled.
+ISO15118Ctrlr;ContractCertificateInstallationEnabled;;no;boolean;;If this variable is true, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is enabled. If this variable is false, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is disabled.
+LocalAuthListCtrlr;Available;;no;boolean;;Local Authorization List is available.
+LocalAuthListCtrlr;BytesPerMessage;;yes;integer;;Maximum number of bytes in a SendLocalList message.
+LocalAuthListCtrlr;Enabled;;no;boolean;;If this variable exists and reports a value of true, Local Authorization List is enabled.
+LocalAuthListCtrlr;Entries;;yes;integer;;Amount of IdTokens currently in the Local Authorization List
+LocalAuthListCtrlr;ItemsPerMessage;;yes;integer;;Maximum number of records in SendLocalList
+LocalAuthListCtrlr;Storage;;no;integer;B;Indicates the number of bytes currently used by the Local Authorization List. MaxLimit indicates the maximum number of bytes that can be used by the Local Authorization List.
+LocalAuthListCtrlr;DisablePostAuthorize;;no;boolean;;When set to true this variable disables the behavior to request authorization for an idToken that is stored in the local authorization list with a status other than Accepted, as stated in C14.FR.03.
+LocalEnergyStorage;Capacity;;no;decimal;Wh;Maximum storage capacity
+MonitoringCtrlr;Available;;no;boolean;;Whether monitoring is available
+MonitoringCtrlr;BytesPerMessage;ClearVariableMonitoring;no;integer;;Maximum number of bytes in a ClearVariableMonitoring message.
+MonitoringCtrlr;BytesPerMessage;SetVariableMonitoring;yes;integer;;Maximum number of bytes in a SetVariableMonitoring message
+MonitoringCtrlr;Enabled;;no;boolean;;Whether monitoring is enabled.
+MonitoringCtrlr;ItemsPerMessage;ClearVariableMonitoring;no;integer;;Maximum number of IDs in a ClearVariableMonitoringRequest.
+MonitoringCtrlr;ItemsPerMessage;SetVariableMonitoring;yes;integer;;Maximum number of setMonitoringData elements that can be sent in one setVariableMonitoringRequest message.
+MonitoringCtrlr;OfflineQueuingSeverity;;no;integer;;When set and the Charging Station is offline, the Charging Station shall queue any notifyEventRequest messages triggered by a monitor with a severity number equal to or lower than the severity configured here.
+MonitoringCtrlr;MonitoringBase;;no;OptionList;;Currently used monitoring base (readonly)
+MonitoringCtrlr;MonitoringLevel;;no;integer;;Currently used monitoring level (readonly)
+MonitoringCtrlr;ActiveMonitoringBase;;no;OptionList;;Shows the currently used MonitoringBase. Valid values according MonitoringBaseEnumType: All, FactoryDefault, HardwiredOnly.
+MonitoringCtrlr;ActiveMonitoringLevel;;no;integer;;Shows the currently used MonitoringLevel. Valid values are severity levels of SetMonitoringLevelRequest: 0-9.
+OCPPCommCtrlr;ActiveNetworkProfile;;no;string;;Indicates the configuration profile the station uses at that moment to connect to the network.
+OCPPCommCtrlr;FileTransferProtocols;;yes;MemberList;;List of supported file transfer protocols
+OCPPCommCtrlr;HeartbeatInterval;;no;integer;s;Interval of inactivity (no OCPP exchanges) with CSMS after which the Charging Station should send HeartbeatRequest.
+OCPPCommCtrlr;MessageTimeout;Default;yes;integer;s;MessageTimeout(Default) specifies after which time a message times out. It is configured in the network connection profile.
+OCPPCommCtrlr;MessageAttemptInterval;TransactionEvent;yes;integer;;MessageAttemptInterval(TransactionEvent) specifies long the Charging Station should wait before resubmitting a TransactionEventRequest message that the CSMS failed to process.
+OCPPCommCtrlr;MessageAttempts;TransactionEvent;yes;integer;;MessageAttempts(TransactionEvent) specifies how often the Charging Station should try to submit a TransactionEventRequest message when the CSMS fails to process it.
+OCPPCommCtrlr;NetworkConfigurationPriority;;yes;string;;A comma separated ordered list of the priority of the possible Network Connection Profiles.
+OCPPCommCtrlr;NetworkProfileConnectionAttempts;;yes;integer;;Specifies the number of connection attempts the Charging Station executes before switching to a different profile.
+OCPPCommCtrlr;OfflineThreshold;;yes;integer;s;When the offline period of a Charging Station exceeds the OfflineThreshold it is recommended to send a StatusNotificationRequest for all its Connectors.
+OCPPCommCtrlr;PublicKeyWithSignedMeterValue;;no;OptionList;;This Configuration Variable can be used to configure whether a public key needs to be sent with a signed meter value. Note, that the field is required, so it needs to be present as an empty string when the public key is not sent.
+OCPPCommCtrlr;QueueAllMessages;;no;boolean;;When this variable is set to true, the Charging Station will queue all message until they are delivered to the CSMS.
+OCPPCommCtrlr;ResetRetries;;yes;integer;;Number of times to retry a reset of the Charging Station when a reset was unsuccessful
+OCPPCommCtrlr;RetryBackOffRandomRange;;no;integer;;When the Charging Station is reconnecting, after a connection loss, it will use this variable as the maximum value for the random part of the back-off time
+OCPPCommCtrlr;RetryBackOffRepeatTimes;;no;integer;;When the Charging Station is reconnecting, after a connection loss, it will use this variable for the amount of times it will double the previous back-off time.
+OCPPCommCtrlr;RetryBackOffWaitMinimum;;no;integer;;When the Charging Station is reconnecting, after a connection loss, it will use this variable as the minimum back-off time, the first time it tries to reconnect.
+OCPPCommCtrlr;UnlockOnEVSideDisconnect;;yes;boolean;;When set to true, the Charging Station SHALL unlock the cable on the Charging Station side when the cable is unplugged at the EV. For an EVSE with only fixed cables, the mutability SHALL be ReadOnly and the actual value SHALL be false. For a charging station with fixed cables and sockets, the variable is only applicable to the sockets.
+OCPPCommCtrlr;WebSocketPingInterval;;no;integer;s;0 disables client side websocket Ping/Pong. In this case there is either no ping/pong or the server initiates the ping and client responds with Pong. Positive values are interpreted as number of seconds between pings. Negative values are not allowed.
+OCPPCommCtrlr;FieldLength;;no;integer;;This variable is used to report the length of <field> in <message> when it is larger than the length that is defined in the standard OCPP message schema.
+ReservationCtrlr;Available;;no;boolean;;Whether reservation is supported.
+ReservationCtrlr;Enabled;;no;boolean;;Whether reservation is enabled.
+ReservationCtrlr;NonEvseSpecific;;no;boolean;;If this configuration variable is present and set to true: Charging Station supports Reservation where EVSE id is not specified.
+SampledDataCtrlr;Available;;no;boolean;;If this variable reports a value of true, Sampled Data is supported
+SampledDataCtrlr;Enabled;;no;boolean;;If this variable reports a value of true, Sampled Data is enabled.
+SampledDataCtrlr;SignReadings;;no;boolean;;If set to true, the Charging Station SHALL include signed meter values in the TransactionEventRequest to the CSMS
+SampledDataCtrlr;TxEndedInterval;;yes;integer;s;Interval between sampling of metering (or other) data, intended to be transmitted in the TransactionEventRequest (eventType = Ended) message.
+SampledDataCtrlr;TxEndedMeasurands;;yes;MemberList;;Sampled measurands to be included in the meterValues element of TransactionEventRequest (eventType = Ended), every SampledDataTxEndedInterval seconds from the start of the transaction.
+SampledDataCtrlr;TxStartedMeasurands;;yes;MemberList;;Sampled measurand(s) to be taken at the start of any transaction to be included in the meterValues field of the first TransactionEventRequest message send at the start of a transaction (eventType = Started)
+SampledDataCtrlr;TxUpdatedInterval;;yes;integer;s;Interval between sampling of metering (or other) data, intended to be transmitted via TransactionEventRequest (eventType = Updated) messages
+SampledDataCtrlr;TxUpdatedMeasurands;;yes;MemberList;;Sampled measurands to be included in the meterValues element of TransactionEventRequest (eventType = Ended)
+SampledDataCtrlr;RegisterValuesWithoutPhases;;no;boolean;;If this variable reports a value of true, then meter values of measurand Energy.Active.Import.Register will only report the total energy over all phases without reporting the individual phase values. If this variable is absent or false, then the value for each phase is reported, possibly also with a total value (depending on the meter).
+SecurityCtrlr;AdditionalRootCertificateCheck;;no;boolean;;Required for all security profiles except profile 1.
+SecurityCtrlr;BasicAuthPassword;;no;passwordString;;The basic authentication password is used for HTTP Basic Authentication.
+SecurityCtrlr;CertificateEntries;;yes;integer;;Amount of Certificates currently installed on the Charging Station
+SecurityCtrlr;CertSigningRepeatTimes;;no;integer;;Number of times to resend a SignCertificateRequest when CSMS does nor return a signed certificate.
+SecurityCtrlr;CertSigningWaitMinimum;;no;integer;s;Seconds to wait before generating another CSR in case CSMS does not return a signed certificate.
+SecurityCtrlr;Identity;;no;identifierString;;The Charging Station identity.
+SecurityCtrlr;MaxCertificateChainSize;;no;integer;;Limit of the size of the 'certificateChain' field from the CertificateSignedRequest
+SecurityCtrlr;OrganizationName;;yes;string;;The organization name of the CSO or an organization trusted by the CSO. This organization name is used to specify the subject field in the client certificate.
+SecurityCtrlr;SecurityProfile;;yes;integer;;The security profile used by the Charging Station.
+SmartChargingCtrlr;ACPhaseSwitchingSupported;;no;boolean;;This variable can be used to indicate an on-load/in-transaction capability. If defined and true, this EVSE supports the selection of which phase to use for 1 phase AC charging.
+SmartChargingCtrlr;Available;;no;boolean;;Whether smart charging is supported.
+SmartChargingCtrlr;Enabled;;no;boolean;;Whether smart charging is enabled.
+SmartChargingCtrlr;Entries;ChargingProfiles;yes;integer;;Entries(ChargingProfiles) is the amount of Charging profiles currently installed on the Charging Station
+SmartChargingCtrlr;ExternalControlSignalsEnabled;;no;boolean;;Indicates whether a Charging Station should respond to external control signals that influence charging.
+SmartChargingCtrlr;LimitChangeSignificance;;yes;decimal;Percent;If at the Charging Station side a change in the limit in a ChargingProfile is lower than this percentage, the Charging Station MAY skip sending a NotifyChargingLimitRequest or a TransactionEventRequest message to the CSMS.
+SmartChargingCtrlr;NotifyChargingLimitWithSchedules;;no;boolean;;Indicates if the Charging Station should include the externally set charging limit/schedule in the message when it sends a NotifyChargingLimitRequest message.
+SmartChargingCtrlr;PeriodsPerSchedule;;yes;integer;;Maximum number of periods that may be defined per ChargingSchedule.
+SmartChargingCtrlr;Phases3to1;;no;boolean;;If defined and true, this Charging Station supports switching from 3 to 1 phase during a transaction
+SmartChargingCtrlr;ProfileStackLevel;;yes;integer;;Maximum acceptable value for stackLevel in a ChargingProfile. Since the lowest stackLevel is 0, this means that if SmartChargingCtrlr.ProfileStackLevel = 1, there can be at most 2 valid charging profiles per Charging Profile Purpose per EVSE.
+SmartChargingCtrlr;RateUnit;;yes;MemberList;;A list of supported quantities for use in a ChargingSchedule. Allowed values: 'A' and 'W
+TariffCostCtrlr;Available;Tariff;no;boolean;;Instance Tariff: Whether tariffs are supported.
+TariffCostCtrlr;Available;Cost;no;boolean;;Instance Cost: Wheter costs are supported.
+TariffCostCtrlr;Currency;;yes;string;;Currency used by this Charging Station in a ISO 4217 [ISO4217] formatted currency code.
+TariffCostCtrlr;Enabled;Tariff;no;boolean;;Instance Tariff: Whether tariffs are enabled.
+TariffCostCtrlr;Enabled;Cost;no;boolean;;Instance Cost: Wheter costs are enabled.
+TariffCostCtrlr;TariffFallbackMessage;;yes;string;;Message (and/or tariff information) to be shown to an EV Driver when there is no driver specific tariff information available.
+TariffCostCtrlr;TotalCostFallbackMessage;;yes;string;;Message to be shown to an EV Driver when the Charging Station cannot retrieve the cost for a transaction at the end of the transaction.
+TokenReader;Token;;no;string;;String of bytes representing an ID token.
+TokenReader;TokenType;;no;OptionList;;Type of Token. Value is one of IdTokenEnumType.
+TxCtrlr;ChargingTime;;no;decimal;s;Time from earliest to latest substantive energy transfer
+TxCtrlr;EVConnectionTimeOut;;yes;integer;s;"Interval from between ""starting"" of a transaction until incipient transaction is automatically canceled, due to failure of EV driver to (correctly) insert the charging cable connector(s) into the appropriate socket(s). "
+TxCtrlr;MaxEnergyOnInvalidId;;no;integer;;Maximum amount of energy in Wh delivered when an identifier is deauthorized by the CSMS after start of a transaction.
+TxCtrlr;StopTxOnEVSideDisconnect;;yes;boolean;;When set to true, the Charging Station SHALL deauthorize the transaction when the cable is unplugged from the EV.
+TxCtrlr;StopTxOnInvalidId;;yes;boolean;;Whether the Charging Station will deauthorize an ongoing transaction when it receives a non- Accepted authorization status in TransactionEventResponse for this transaction.
+TxCtrlr;TxBeforeAcceptedEnabled;;no;boolean;;Allow charging before having received a BootNotificationResponse with RegistrationStatus: Accepted.
+TxCtrlr;TxStartPoint;;yes;MemberList;;Defines when the Charging Station starts a new transaction
+TxCtrlr;TxStopPoint;;yes;MemberList;;Defines when the Charging Station ends a transaction
--- /dev/null
+Reason Code;Description;Typically used for
+CSNotAccepted;BootNotification of Charging Station has not (yet) been accepted by CSMS.;RequestStartTransaction, RequestStopTransaction
+DuplicateProfile;A charging profile with same _stackLevel - chargingProfilePurpose_ combination already exists on the Charging Station and has an overlapping validity period.;SetChargingProfile
+DuplicateRequestId;A _requestId_ is provided, that has already been used for this type of request.;UpdateFirmware, PublishFirmware and requests for reports.
+FixedCable;The connector has its own fixed cable that cannot be unlocked.;UnlockConnector
+FwUpdateInProgress;Operation is not possible, because a firmware update is in progress.;Reset
+InternalError;Operation cannot be completed due to an internal error.;(generic)
+InvalidCertificate;Provided certificate is invalid.;CertificateSigned, InstallCertificate
+InvalidCSR;Provided CSR is invalid;SignCertificate
+InvalidIdToken;Provided _idToken_ is not valid.;RequestStartTransaction
+InvalidMessageSeq;Message should not be sent at this moment in current scenario.;(generic), SetChargingProfile with ISO15118
+InvalidProfile;Provided _chargingProfile_ contains invalid elements.;SetChargingProfile, RequestStartTransaction
+InvalidSchedule;Provided _chargingSchedule_ contains invalid elements.;SetChargingProfile, RequestStartTransaction
+InvalidStackLevel;Provided value for _stackLevel_ is invalid.;SetChargingProfile
+InvalidURL;Provided URL is invalid.;UpdateFirmware, PublishFirmware
+InvalidValue;An invalid value has been provided.;(generic)
+MissingDevModelInfo;Information needed for operation is missing from Device Model;(generic)
+MissingParam;A parameter that is required for the request is missing.;(generic)
+NoCable;No cable is connected at this time.;UnlockConnector
+NoError;No error has occurred, but some extra information is in _additionalInfo_ .;(generic)
+NotEnabled;Feature is not enabled.;ClearCache
+NotFound;No object(s) found that match a provided ID or criteria.;ClearVariableMonitoring, CustomerInformation, GetChargingProfiles, GetDisplayMessages, GetInstalledCertificateIds, GetReport
+OutOfMemory;Operation not possible, because system does not have enough memory.;(generic)
+OutOfStorage;Operation not possible, because system does not have enough storage.;(generic)
+ReadOnly;Targeted variable is read-only and cannot be set.;SetVariables
+TooLargeElement;Provided element is too large to handle.;CertificateSigned, InstallCertificate
+TooManyElements;Too many elements have been provided.;SetChargingProfile, SetVariables, SendLocalList
+TxInProgress;A transaction is in progress.;ChangeAvailability, Reset, RequestStartTransaction
+TxNotFound;There is no such transaction.;RequestStopTransaction, SetChargingProfile
+TxStarted;A transaction had already started (e.g. due to cable being plugged in).;RequestStartTransaction
+UnknownConnectorId;Connector Id is not known on EVSE;ChangeAvailability, UnlockConnector
+UnknownConnectorType;Connector type is not known on EVSE;ReserveNow
+UnknownEvse;EVSE is not known on Charging Stations;ChangeAvailability, ReserveNow, RequestStartTransaction
+UnknownTxId;Provided _transactionId_ is not known.;RequestStopTransaction
+Unspecified;No reason is specified, but some extra information is in _additionalInfo_;(generic)
+UnsupportedParam;A parameter was provided that is not supported.;(generic)
+UnsupportedRateUnit;A _chargingRateUnit_ is provided that is not supported.;SetChargingProfile
+UnsupportedRequest;This request is not supported.;(generic)
+ValueOutOfRange;Provided value is out of range.;SetVariables, SetVariableMonitoring
+ValuePositiveOnly;Provided value is not greater than zero.;(generic)
+ValueTooHigh;Provided value is too high.;(generic)
+ValueTooLow;Provided value is too low.;(generic)
+ValueZeroNotAllowed;Provided value cannot be zero.;(generic)
+WriteOnly;Targeted variable is write-only and cannot be read.;GetVariables
--- /dev/null
+Security Event;Description;Critical
+FirmwareUpdated;The Charging Station firmware is updated;Yes
+FailedToAuthenticateAtCsms;The authentication credentials provided by the Charging Station were rejected by the CSMS;No
+CsmsFailedToAuthenticate;The authentication credentials provided by the CSMS were rejected by the Charging Station;No
+SettingSystemTime;The system time on the Charging Station was changed more than `ClockCtrlr.TimeAdjustmentReportingThreshold` seconds;Yes
+StartupOfTheDevice;The Charging Station has booted;Yes
+ResetOrReboot;The Charging Station was rebooted or reset;Yes
+SecurityLogWasCleared;The security log was cleared;Yes
+ReconfigurationOfSecurityParameters;Security parameters, such as keys or the security profile used, were changed;No
+MemoryExhaustion;The Flash or RAM memory of the Charging Station is getting full;Yes
+InvalidMessages;The Charging Station has received messages that are not valid OCPP messages, if signed messages, signage invalid/incorrect;No
+AttemptedReplayAttacks;The Charging Station has received a replayed message (other than the CSMS trying to resend a message because it there was for example a network problem);No
+TamperDetectionActivated;The physical tamper detection sensor was triggered;Yes
+InvalidFirmwareSignature;The firmware signature is not valid;Yes
+InvalidFirmwareSigningCertificate;The certificate used to verify the firmware signature is not valid;Yes
+InvalidCsmsCertificate;The certificate that the CSMS uses was not valid or could not be verified;Yes
+InvalidChargingStationCertificate;The certificate sent to the Charging Station using the CertificateSignedRequest message is not a valid certificate;Yes
+InvalidTLSVersion;The TLS version used by the CSMS is lower than 1.2 and is not allowed by the security specification;Yes
+InvalidTLSCipherSuite;The CSMS did only allow connections using TLS cipher suites that are not allowed by the security specification;Yes
+MaintenanceLoginAccepted;Successful login to the local maintenance interface. It is recommended to include information like the user identification and the origin of the login attempt, which can be an ip-address or a touch screen for example, to the techInfo field. For this the following format is strongly recommended: '{\'user\': \'...\', \'origin\': \'...\'}';Yes
+MaintenanceLoginFailed;Failed login attempt to the local maintenance interface. It is recommended to include information like the user identification and the origin of the login attempt, which can be an ip-address or a touch screen for example, to the techInfo field. For this the following format is strongly recommended: '{\'user\': \'...\', \'origin\': \'...\'}';Yes
--- /dev/null
+Value;Description
+A;Amperes (current)
+ASU;Arbitrary Strength Unit (Signal Strength)
+B;Bytes
+Celsius;Degrees (temperature)
+dB;Decibel (for example Signal Strength)
+dBm;Power relative to 1mW (^10^log(P/1mW))
+Deg;Degrees (angle/rotation)
+Fahrenheit;Degrees (temperature)
+Hz;Hertz (frequency)
+K;Degrees Kelvin (temperature)
+lx;Lux (Light Intensity)
+m;Meter (length)
+ms2;m/s^2^ (Acceleration)
+N;Newtons (Force)
+Ohm;Ohm (Impedance)
+kPa;kiloPascal (Pressure)
+Percent;Percentage
+RH;Relative Humidity%
+RPM;Revolutions per Minute
+s;Seconds (Time)
+V;Voltage (DC or r.m.s. AC)
+VA;Volt-Ampere (apparent power)
+kVA;kiloVolt-Ampere (apparent power)
+VAh;Volt-Ampere-hours (apparent energy)
+kVAh;kiloVolt-Ampere-hours (apparent energy)
+var;vars (reactive power)
+kvar;kilovars (reactive power)
+varh;var-hours (reactive energy)
+kvarh;kilovar-hours (reactive energy)
+W;Watts (power)
+kW;kilowatts (power)
+Wh;Watt-hours (energy). Default
+kWh;kilowatt-hours (energy)
--- /dev/null
+Name ; DataType ; Unit ; Description
+ACCurrent;decimal;A ; RMS AC Current (in amperes). For 3-phase circuits, each phase (and optional neutral) is represented by a Variable instance equal to a value of the PhaseEnumType (e.g. L1,N). Unkeyed values reported for a Component declared to be multi-phase are assumed to be an average of all per-phase readings and written values are common per-phase settings. Example(s): ChargingStation: Total AC current consumption (all EVSE’s, ancillaries), EVSE: Total current consumed by EVSE: includes losses (AC->DC) and EVSE specific ancillaries (e.g. fans), ElectricalFeed: Inflow AC current on feed
+Active;boolean; ; Component is in its non-resting / active state: e.g: On, Engaged, Locked. Some Components may have secondary functions that have corresponding Active Variables with an explicit Variable instance., Note: Monitoring of changes in the Active state of any Component can be specified by setting Delta monitoring on the boolean value with a delta values of 1. Setting/clearing an Active Variable activates/stops the associated functionality, where remotely controllable. Only components that are Available and Enabled can be in the Active state.
+ACVoltage;decimal;V; RMS AC Voltage (in volts). For 3-phase circuits, each phase (and optional neutral) is represented by a Variable instance equal to a value of the PhaseEnumType (e.g. L1,N). Unkeyed values reported for a Component declared to be multi-phase are assumed to be an average ofall per-phase readings and written values are common per-phase settings. Example(s): ElectricalFeed: Input Voltage
+AllowReset ; boolean ; ; Component can be reset. Can be used to announce that an EVSE can be reset individually.
+Angle;decimal; Deg ; Angle(s) relative to normal/design idle position. Multiple Variable instance values may be used to indicate angular position in multiple axes (e.g. Left-Right, Forward-Back).
+Attempts; integer ;; Number of attempts (INCLUDING the original attempt) in the last successful or attempted, cycle of operation. Applies typically to self-monitoring motorized electro-mechanical equipment, etc. {Null}: Unknown, 0: Not Attempted/Not allowed, 1: Single attempt/No retries [allowed], 2-N: [up to] N tries [allowed]
+AvailabilityState;OptionList; ; A value of ConnectorStatusEnumType (See part 2): replicates ConnectorStatus values reported in StatusNotification messages.
+Available;boolean; ; The Component exists and is locally configured/wired for use, but might not be (remotely) Enabled.
+Certificate;string ; ;Digital Certificate (in Base64 encoding)
+ChargeProtocol; ; ;The Charging Control Protocol applicable to a Connector. CHAdeMO: CHAdeMO protocol, ISO15118: ISO15118 V2G protocol (wired or wireless) as used with CCS, CPPWM: IEC61851-1 / SAE J1772 protocol (ELV DC & PWM signalling via Control Pilot wire), Uncontrolled: No charging power management applies (e.g. Schuko socket), Undetermined: Yet to be determined (e.g. before plugged in), Unknown: Not determinable, NOTE: ChargeProtocol is distinct from and orthogonal to connectorType.
+ChargingCompleteBulk;boolean;;Charging up to StateOfChargeBulk has completed.
+ChargingCompleteFull;boolean;;Charging up to StateOfCharge.maxSet has completed.
+ChargingTime;decimal;s ; Time from earliest to latest substantive energy transfer
+Color;string ; ; Standard 24 bit hexadecimal RGB values. Reg Green Blue color intensity, expressed as standard 24 bit hexadecimal RGB values: 3 00-FF (0-255), in order RRGGBB). E.g. 000000: Black, FF0000: Red, 00FF00: Green, 0000FF: Blue, FFFF00:Yellow, FFFFFF: White, 008000: Medium intensity green.
+Complete;boolean; ; Component’s operation cycle has completed. Used only in event notifications, where it is always true.
+ConnectedTime;decimal;s ; Time since logical connection established
+ConnectorType; OptionList ; ; A value of ConnectorEnumType (See part 2) plus additionally: `cGBT`, `cChaoJi`, `OppCharge`. Specific type of connector, including sub-variant information. Note: Distinct and orthogonal to Charging Protocol, Power Type, Phases.
+Count;integer; ; General purpose integer count variable for Component state reporting
+Currency;string;;Currency in a ISO 4217 formatted currency code.
+CurrentImbalance;decimal;Percent ;Percentage current imbalance in an AC three phase supply.
+DataText ; string; ; Text associated with a Component, e.g. a Display.
+DateTime;dateTime;;Point in time value, in [RFC3339] datetime format. Time zone optional.
+DCCurrent;decimal;A ; DC Current (in amperes). May be an instantaneous measurement, or a period average, depending on context/equipment.
+DCVoltage;decimal;V ; DC Voltage (volts). May be an instantaneous measurement, or a period average, depending on context/equipment.
+DepartureTime;dateTime;;Time in [RFC3339] datetime format, when an EV intends to leave the charging station.
+ECVariant;string; ; Production series variants reflecting internal design changes or sub-component substitutions not affecting external functionality.
+Enabled;boolean; ; The Component is Enabled for operation. For Available components that cannot be selectively (remotely) enabled / disabled, this value is always true. Note: Available cannot be false of Enabled is true, so during inventory reporting, Enabled=1 also logically states Available=true
+Energy;decimal;Wh;Energy quantity (in Wh) for reporting/configuring values related to stored energy (i.e. not transferred energy).
+EnergyCapacity;decimal;Wh ;Energy capacity in Wh of an energy storage device.
+EnergyExport;decimal;Wh ; Total energy transferred: e.g. from EV during (ongoing or terminated) charging session (in wH by default)
+EnergyExportRegister;decimal;Wh; Cumulative export kWh register value, such as from a (certified) fiscal energy meter.
+EnergyImport;decimal;Wh ; Total energy transferred.
+EnergyImportRegister;decimal;Wh ; Cumulative export kWh register value, such as from a (certified) fiscal energy meter.
+Entries;integer;;General purpose variable for reporting/managing numbers of entries in repetitive data structures. maxLimit characteristic reports maximum possible entries.
+Fallback;boolean; ; Component is operating in a fallback, or backup mode. In inventory reports, a Value of 1 for the maxLimit characteristic indicates that the component can enter a fallback state (i.e. a fallback mode is present).
+FanSpeed;decimal ;RPM ; Fan Speed (in RPM). A value of 0 represents stopped/stalled. An empty value indicates that fan speed cannot be read.
+FirmwareVersion;string ;; Version number of firmware.
+Force;decimal;N ; Reports (impact) force/ acceleration values (estimates) in one or more directions, in units of Newtons or “g”. Multiple force readings in different (orthogonal) dimensions may be reported using Variable instance values, such as Down, Right, Forward.
+Formats;MemberList;;List of message formats supported by this Charging Station. Possible values: ASCII, HTML, URI, UTF-8.
+Frequency;decimal;Hz ; Frequency of AC power, signal, or component operation.
+FuseRating;decimal;A;Current rating of a fuse/breaker. Variable instances keyed by phase identifier (L1/L2/L3/N).
+Height;decimal;m ; Height above(+)/below(-) reference level (ground level unless context demands otherwise).
+Humidity;decimal;RH; The relative humidity in %.
+Hysteresis;decimal;Percent;Specifies the width of a 'dead band' (as a percentage of the threshold) around the central value of a threshold setting (e.g. MinSet, MaxSet, monitor thresholds) to avoid repeated triggering when the measured quantity lies close to the threshold and is subject to small variations.
+ICCID; string ; ; ICCID (Integrated Circuit Card IDentifier) of mobile data SIM card.
+Impedance;decimal;Ohm ; Impedance: Primary value is real (resistive only) impedance. Where a complex impedance is to be reported, the imaginary part (reactance) must be represented with a separate Variable instance value of 'reactance'. Reactance values are expressed at the (nominal) relevant operating frequency of the Component (e.g. 50/60Hz for mains electricity feed).
+IMSI; string ;; IMSI (International Mobile Subscriber Identity) number of mobile data SIM card
+Interval;integer;s ; Minimum Interval (in seconds) between (attempted) operations.
+ISO15118EvseId;string;;EVSE ID in string format as used in ISO 15118 and IEC 63119-2
+Length ;decimal; m; General Purpose linear distance measure.
+Light;decimal;lx ; (Ambient) light level. The value is in Lux.
+Manufacturer; string ; ; Component Manufacturer name
+Message;string;;Specific stored message for display.
+MinimumStatusDuration;integer;s;Minimum duration that a Charging Station or EVSE status is stable before StatusNotificationRequest is sent to the CSMS.
+Mode;string; ; Operating mode string from among valid options (communicated by OptionList, etc. during capability/configuration discovery).
+Model;string ; ; Manufacturer's Model code/number of Component, including suffixes etc. to identify functional, regional or linguistic variation, but NOT engineering change level internal variation not affecting external behaviour, etc.
+NetworkAddress ; string; ; Current network address of a Component.
+Operated;boolean; ; The Component operated in an instantaneous, transient, or immediately self-resetting pattern. Used only in event notifications, where it is always true.
+OperatingTimes;string; ; Recurring operating times in iCalendar RRULE format.
+Overload;boolean; ; Component is in Overload state.
+Percent;decimal; Percent ;Generic dimensionless value reporting/setting value.
+PhaseRotation;OptionList ; ; The phase wiring of Component, relative to it's upstream feed Component/device. This variable describes the phase rotation of a Component relative to its parent Component, using a three letter string consisting of the letters: R, S, T and x. The letter 'R' can be identified as phase 1 (L1), 'S' as phase 2 (L2), 'T' as phase 3 (L3). The lower case 'x' is used to designate a phase that is not connected. An empty string means that phase rotation is not applicable or not known.
+PostChargingTime;decimal;s ; Elapsed time in seconds since last substantive energy transfer
+Power;decimal;W,kW ; Instantaneous (real) Power (measured/calculated, including power factor for AC). Where a component (e.g. AC to DC Power Converter) has multiple power measurements, the default (unkeyed) instance is “input” power.
+Problem;boolean; ; Component itself has a 'Problem' condition that impacts in any significant way on its normal operation. By definition, 'Problem' state includes (logical OR) 'Fault' state. 'Problem' specifically INCLUDES inability to operate that is propagated (up/down/sideways) from any other associated/connected/containing/contained Component.
+Protecting;boolean;;Applies to 'sensor' type Components that have an associated protection capability, whereby they can disconnect power (e.g. using the main PowerContactor) if the sensed quantity is outside preset/configured limits. If Protecting is true, the Component is actively preventing/interrupting charging.
+RemainingTimeBulk;integer;s;Number of seconds remaining to charge to bulk state of charge, given by StateOfChargeBulk.
+RemainingTimeFull;integer;s;Number of seconds remaining to charge to 100% state of charge.
+SeccId;string;;The name of the SECC in the string format as required by ISO 15118.
+SerialNumber;string ;; Serial number of Component.
+SignalStrength;decimal;dBm ; (Radio/Wired/Optical) data signal strength, in ASU (typically 0-31 or 99 for unknown). Or dbmW (typically -140 to -50).
+State;string; ; A state code or name identifier string, to allow the internal state of components to be reported and/or controlled
+StateOfCharge;decimal;Percent ; Energy Storage Device (e.g. battery) state of charge, expressed as a percentage of nominal design 0-100% operating range. The value of StateOfCharge.maxSet represents the maximum state of charge for a full battery and is usually at or near 100%.
+StateOfChargeBulk;decimal;Percent; Energy Storage Device (e.g. battery) state of charge up to which fast charging is possible. Above this percentage charging speed will drop significantly.
+Storage;integer;B; In bytes. Amount of storage occupied. Storage(maxLimit) specifies absolute limit Storage(MaxSet) restricts usage to specified Max, if supported.
+SupplyPhases; integer ; ; Number of alternating current phases connected/available. 1 or 3 for AC, 0 means DC (no alternating phases). Null value indicates that the number of phases (e.g. in use) is unknown.
+Suspending;boolean;;If Suspending is true, the Component can is currently suspending charging.
+Suspension;boolean;;Applies to 'sensor' type Components that have a charging suspension capability, typically for safety or equipment protection reasons. If Suspension is true, the component can suspend charging when the sensed quantity is outside preset/configured limits.
+Temperature;decimal;Celsius, Fahrenheit ; Temperature(s) of component (in Celsius, by default). Components may have multiple indexed temperature sensors.
+Time;dateTime; ; Point in time value, in ISO 8601 datetime format. Time zone optional.
+TimeOffset;string;; A Time Offset with respect to Coordinated Universal Time (aka UTC or Greenwich Mean Time) in the form of an [RFC3339] time (zone) offset suffix, including the mandatory “+” or “-“ prefix.
+Timeout;decimal;s; Generic timeout value for Component operation (in seconds).
+Token; string ;; String of bytes representing an ID token.
+TokenType; OptionList;; Type of Token. Value is one of IdTokenEnumType.
+Tries ; integer; ; Number of attempts done by a Component.
+Tripped;boolean; ; Single-shot device requires explicit intervention to re-prime/activate to normal.
+VehicleId;string;;ID that EV provides to charging station. Encoded as a hexbinary string. In ISO 15118 the EVCCID is 6 bytes (MAC address), in CHAdeMO the vehicle id can be 24 bytes.
+VersionDate;dateTime;;[RFC3339]
+VersionNumber;string;;Version number of hardware
+VoltageImbalance;decimal;Percent; Percentage voltage imbalance in three phase supply.
--- /dev/null
+# OCPP
+
+OCPP 2.0.1 Edition 3
+
+Errata 2025-09
+
+# Table of Contents
+
+Disclaimer 1
+
+Scope 2
+
+Terminology and Conventions 2
+
+0. Part 0 3
+
+1. Part 1 4
+ 1.1. Page 9 - (2025-01) - 3.4. Monitoring. 4
+2. Part 2 5
+ 2.1. Page 5 - (2025-01) - Updated limitations on BasicAuthPassword to increase security. 5
+ 2.2. Page 14 - (2025-04) - Section 2.7. ISO 15118 support - Alligned ISO 15118 timeout table with updated version in OCPP 2.1
+ 2.3. Page 15 - (2025-01) - Improved text FR.04
+ 2.4. Page 19 - (2025-01) - Removed requirement A00.FR.003 as the precondition never occurs 6
+ 2.5. Page 19/41 - (2025-01) - Allow downgrading security profile from 3 to 2. 7
+ 2.6. Page 26 - (2025-01) - 1.3.7. TLS with Client Side Certificates Profile - Requirements 9
+ 2.7.Page 28-(2025-01)-CertificateHierarchy 9
+ 2.8. Page 31 - (2025-01) - A02/A03 - Updated error handling 10
+ 2.9. Page 34 - (2025-01) - Disallow client certificates future validity date 10
+ 2.10. Page 58/60 - (2025-01) - Missing requirement information about omitting the value for WriteOnly variables 13
+ 2.11. Page 63 - (2025-09) - B09.FR.02/04/05 - Added optional reasonCode 14
+ 2.12. Page 64 - (2025-09) - B09.FR.31/31 - Improved definition 14
+ 2.13. Page 66 - (2025-04) - B10.FR.03/04/10 - Migrate to new NetworkConnectionProfile. 15
+ 2.14. Page 67 - (2025-06) - B11 - Clarify meaning of OnIdle for Reset 16
+ 2.15. Page 69 - (2025-01) - B11 - Reset without Ongoing Transaction - Requirements 16
+ 2.16. Page 73 - (2025-01) - B12 - Reset with Ongoing Transaction - Requirements 16
+ 2.17. Page 77 - (2025-01) - 1.6 Relationship between authorization and transaction. 17
+ 2.18. Page 80 - (2025-01) - C01 - EV Driver Authorization using RFID - Requirements. 18
+ 2.19. Page 80 - (2025-01) - C01 - EV Driver Authorization using RFID - Requirements. 18
+ 2.20. Page 99 - (2025-01) - C09- Authorization by Groupld - Requirements 18
+ 2.21. Page 101 - (2025-01) - Updated requirements related to clarify the relation between AuthCacheLifeTime and cacheExpiryDateTime 18
+ 2.22. Page 113 - (2025-01) - C16 - Stop Transaction with a Master Pass - Requirements 19
+ 2.23. Page 129 - (2025-01) - Updated sequence diagram E01 S5 20
+ 2.24. Page 151 - (2025-02) - E06.FR.05 for DataSigned as TxStopPoint is invalid 20
+ 2.25. Page 152 - (2025-01) - E07 - Improved scenario description names 20
+ 2.26. Page 154 - (2025-01) - E07 - Transaction locally stopped by IdToken 21
+ 2.27. Page 155 - (2025-09) - E07.FR.07 - Improved precondition 22
+ 2.28. Page 198 - (2025-01) - G01 - Status Notification - Requirements 22
+ 2.29. Page 197 - (2025-01) - G01 - Status Notification - State transition overview for connecting/disconnecting 23
+ 2.30. Page 208 - (2025-01) - H. Reservation - Introduction. 23
+ 2.31. Page 213 - (2025-02) - H02 - Added missing requirements 23
+ 2.32. Page 214/215 - (2025-01) - Improved use case scenario descriptions and added S3 25
+ 2.33. Page 226 - (2025-01) - I06.FR.02 Improved requirement text. 28
+ 2.34. Page 231 - (2025-01) - Updated section Multiple Locations/Phases 29
+ 2.35. Page 243 - (2025-01) - Improved section on external Smart Charging Control Signals 29
+ 2.36. Page 248 - (2025-01) - 3.7 Avoiding Phase Conflicts 30
+ 2.37. Page 275 - (2025-06) - Updated remark of K11 31
+ 2.38. Page 251 - (2025-06) - Updated note of K01.FR.05 31
+ 2.39. Page 251 - (2025-06) - Add cross-references to K01.FR.06 and K01.FR.39 31
+ 2.40. Page 254 - (2025-06) - K01.FR.50 requirement is a SHALL 32
+ 2.41. Page 257 - (2025-06) - K02 Updated remark of use case about merging profiles 33
+ 2.42. Page 282 - (2025-01) - K15 - ISO 15118-2 Charging with load leveling - Requirements 33
+ 2.43. Page 282 - (2025-09) - K15.FR.20 is not part of OCPP 2.0.1 [1061]. 34
+ 2.44. Page 286 - (2025-01) - K16 - Renegotiation initiated by CSMS - Requirements 34
+ 2.45. Page 284 - (2025-09) - K15 Added rule for composite schedules in case of multiple charging schedules [1002] .34
+ 2.45.1.K15-ISO15118-2. 34
+ 2.46. Page 259/260 - (2025-01) - K03 - Updated use case description and sequence diagram 35
+
+2.47. Page 274/275/276/277 - (2025-01) - K11/K12 - Updated use case descriptions and sequence diagrams 37
+2.48. Page 278/279 - (2025-01) - K13 - Updated requirement preconditions. 39
+2.49. Page 279 - (2025-01) - K14 - Updated use case scenario description. 40
+2.50. Page 284 - (2025-09) - K16 use case description update 40
+2.50.1. Page 285 41
+2.51. Page 292 - (2025-01) - Use case L01 - Added clarification to step 3 about when to start downloading the firmware . . . . . . 41
+2.52. Page 306 - (2025-01) - M. ISO 15118 Certificate Management 41
+2.53. Page 308 - (2025-01) - Update introduction sequence diagram ISO 15118 42
+2.54. Page 330 - (2025-01) - N03 Set Monitoring Base: Improved text of Remark 44
+2.55. Page 331 - (2025-01) - N03.FR.04: text improvement 44
+2.56. Page 350 - (2025-02) - 001 - Added missing requirements 44
+2.57. Page 446 - (2025-01) - ActiveNetworkProfile is incorrectly marked as optional 45
+2.58. Page 327 - (2025-09) - N01.FR.12 - Improved definition 45
+2.59. Page 328 - (2025-09) - N02: changed empty to absent. 45
+2.60. Page 453 - (2025-01) - References to monitorValue changed to value [354] 46
+2.61. Page 454 - (2025-01) - N04.FR.06 Improved limit definition of thresholds [353] 46
+2.62. Page 456 - (2025-02) - New configuration variable to allow TLS wildcard certificates. 46
+2.63. Page 458 - (2025-01) - Added optional variable to allow the Charging Station to report its supported idTokenTypes.... 47
+2.64. Page 462 - (2025-01) - Added note to EnergyTransfer description as TxStartPoint 47
+2.65. Page 467 - (2025-09) - Error in description of Associated data interval variables [1043] 47
+2.65.1. AlignedDataInterval 47
+2.65.2. AlignedDataTxEndInterval 48
+2.66. Page 476 - (2025-01) - Added Connector component to AvailabilityState referenced variable 48
+3. Part 3 49
+4. Part 4 50
+4.1. Page 6 - (2025-01) - 3.1.1. The connection URL 50
+4.2. Page 7-(2025-01)-3.1.2.OCPP version 50
+4.3. Page 8-(2025-01)-3.3.WebSocket Compression 50
+4.4. Page 10 - (2025-01) - 4.1.3. The message type 50
+4.5. Page 10 - (2025-01) - 4.1.3. The message type 50
+4.6. Page 10-(2024-09)-4.1.4.Message ID 51
+4.7. Page 13-(2025-01)-4.2.3.CALLERROR.. 51
+4.8. Page 15-(2025-01)-5.Connection. 51
+4.9. TLS fragment length 51
+4.10. Page 15 - (2025-01) - 5.3. WebSocket Ping in relation to OCPP Heartbeat. 52
+4.11. Page 15 - (2025-01) - 5 Connection - Added section about TLS fragment length 52
+4.12. Page 16 - (2025-04) - 5.3 Reconnecting - reset backoff wait timer 52
+4.13. Page 18 - (2025-02) - 6.3 Connection loss - Allow Local Controller to keep connection open 52
+5. Part 5 54
+5.1. General - (2025-02) - Renamed OCTT to Test System 54
+5.2. Page 7-48 - (2025-09) - Add additional support for different types of Charging Stations 54
+5.3. Page 7 - (2025-02) - Changed definition of C-01 Support for offline authorization of transactions. 54
+5.4. Page 9 - (2024-11) - Optional feature list for charging station - Change name R-3 55
+5.5. Page 9 - (2025-02) - Optional feature list for charging station - Added AQ-10 to make TC_N_48_CS conditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+5.6. Page 9/11/27/48/52 - (2025-02) - Removed feature ISO-3, added additional question AQ-11 55
+5.7. Page 9/10 - (2025-06) - Optional feature list for charging station & CSMS - Add optional feature for Security Profile 1 . . . . 56
+5.8. Page 13 - (2025-09) - Added TC_B_14_CS (as optional) to the Core profile 57
+5.9. Page 13 - (2025-02) - Updated Id's of the additional questions of CSMSs in the appendix 57
+5.10. Page 15 - (2025-04) - Addition of new testcase for CSMS to test WebSocket Subprotocol negotiation 57
+5.11. Page 17/33 - (2025-02) - Test Cases Local Authorization List Management & Authorization Cache - Update conditions.. . 57
+5.12. Page 19 - (2024-09) - TC_E_04_CS Updated condition for test case to exclude it for MacAddress and ISO 15118 PnC . . . 61
+5.13. Page 22 - (2024-09) - TC_E_17_CS Updated condition for test case to correctly specify the applicable TxStopPoint combinations 61
+5.14. Page 33 - (2025-06) - Fixed incorrect feature no reference 62
+5.15. Page 39 - (2025-02) - TC_N_48_CS Made conditional 62
+5.16. Page 40 - (2024-11) - TC_H_13_CS Updated invalid condition for test case 62
+5.17. Page 42 - (2025-02) - Removed TC_O_15_CS from certification program 63
+5.18. Test Cases Advanced User Interface 63
+5.19. Page 42 - (2025-06) - Make optional feature R-1 available for Charging Stations 63
+5.20. Page 44 - (2025-02) - Removed TC_A_13_CS and TC_A_13_CSMS from certification program 64
+5.21. Page 48 - (2024-06) - Added additional questions to appendix 64
+5.22. Page 48 - (2025-02) - Updated Id's of the additional questions for CSMSs in the appendix. 64
+5.23. Page 48 - (2025-04) - Duplicate AQ-11 id 65
+
+6. Part 6 66
+
+6.1. General 66
+
+6.1.1. Page XX - (2024-11) - All testcases - Updated table structure of all testcases 66
+6.1.2. Page XX - (2025-02) - Renamed OCTT to Test System 66
+
+6.2. Charging Station 66
+
+6.2.1. Page 4 - (2025-02) - TC_A_01_CS - Updated old identifierString reference in description. 66
+6.2.2. Page 7 - (2024-11) - TC_A_05_CS - Successfully reconnecting after every failed connection attempt 66
+6.2.3. Page 7-(2025-02)-TC_A_05_CS 67
+6.2.4. Page 7 - (2025-04) - TC_A_05_CS - Updated before steps to take into account the AllowCSMSTLSWildcards variable 68
+6.2.5. Page 20 - (2025-02) - TC_A_23_CS - CSMS returns a CertificateSigned message for each request 68
+6.2.6. Page 22 - (2024-09) - TC_A_19_CS - Fixed references to ConfigurationSlot [O20-4762]. 69
+6.2.7. Page 22 - (2025-06) - TC_A_19_CS - Added steps to validate the Charging Station does not downgrade back to security profile 1. 70
+6.2.8. Page 24 - (2025-02) - TC_A_20_CS - Testcase did not take into account that the used configuration slot could already be set. 72
+6.2.9. Page 24 - (2025-04) - TC_A_20_CS - SetNetworkConnectionProfile is allowed to be rejected . 73
+6.2.10. Page 25 - (2025-02) - TC_A_21_CS. 73
+6.2.11.Page 26-(2025-02)-TC_A_22_CS. 74
+6.2.12. Page 51 - (2025-02) - TC_B_16_CS - Correctly validate result of reading WriteOnly component variables. 74
+6.2.13. Page 56 - (2024-09) - TC_B_20_CS - Added check on omitting evseld [4390] 75
+6.2.14. Page 57 - (2024-09) - TC_B_21_CS - Added check on omitting evseld [4390] 75
+6.2.15. Page 58 - (2024-09) - TC_B_22_CS - Added check on omitting evseld [4390] 76
+6.2.16. Page 63 - (2025-02) - Changed reset to Immediate 76
+6.2.17. Page 72-81 - (2025-04) - TC_B_45_CS & TC_B_46_CS & TC_B_47_CS & TC_B_49_CS & TC_B_50_CS & TC_A_19_CS - Clarified NetworkProfile configurationSlot usage 76
+6.2.18. Page 72-81 - (2025-06) - TC_B_45_CS & TC_B_46_CS & TC_A_19_CS - ResetRequest will always be sent by the Test System to ensure the Charging Station switches NetworkProfile 80
+6.2.19. Page 85 - (2025-04) - TC_B_53_CS - Check if all required values are provided. 81
+6.2.20. Page 89 - (2025-02) - Add setting of NetworkProfileConnectionAttempts 81
+6.2.21. Page 89/621 - (2025-04) - Addition of new testcase for CSMS to test WebSocket Subprotocol negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+6.2.22. Page 117/141 - (2025-02) - Added remote support for Authorization Cache & Local Authorization List testcases . . 82
+6.2.23. Page 101 - (2025-04) - TC_C_14_CS - Fixing invalid component variable reference 83
+6.2.24. Page 102 - (2025-04) - TC_C_15_CS - Fixing invalid component variable reference 84
+6.2.25. Page 104-(2025-04)-TC_C_16_CS-Fixing invalid component variable reference 84
+6.2.26. Page 105 - (2025-04) - TC_C_17_CS - Fixing invalid component variable reference 84
+6.2.27. Page 108 - (2025-04) - TC_C_18_CS - Fixing invalid component variable reference 84
+6.2.28. Page 120 - (2025-04) - TC_C_34_CS - Making use of the Deauthorized reusable state. 84
+6.2.29. Page 128 - (2025-04) - TC_C_41_CS - Fixing invalid component variable reference 85
+6.2.30. Page 134 - (2025-04) - TC_C_44_CS - Fixing invalid component variable reference 85
+6.2.31. Page 137 - (2025-04) - TC_C_46_CS - Fixing invalid component variable reference 85
+6.2.32. Page 138 - (2024-09) - TC_C_47_CS - StoppedReason must be validated in Ended event [O20-4467] 85
+6.2.33. Page 145 - (2025-04) - TC_C_25_CS - Fixing invalid component variable reference 86
+6.2.34. Page 146 - (2024-11) - TC_C_26_CS - Allow StatusNotification status = Occupied. 86
+6.2.35. Page 147-153-(2025-04)-TC_C_50_CS,TC_C_51_CS,TC_C_52_CS,TC_C_53_CS,TC_C_54_CS,TC_C_55_CS - Always re-install V2G certificates 87
+6.2.36. Page 147-(2025-02)-TC_C_50_CS 87
+6.2.37. Page 148-(2025-02)-TC_C_51_CS 88
+6.2.38. Page 149-(2025-02)-TC_C_52_CS 88
+6.2.39. Page 150-(2025-02)-TC_C_53_CS 89
+6.2.40. Page 151 - (2024-09) - TC_C_54_CS - removed reusable state IdTokenCached [O20-3510] 90
+6.2.41. Page 151-(2025-02)-TC_C_54_CS 90
+6.2.42. Page 153-(2024-09)-TC_C_55_CS-removed reusable state IdTokenCached [O20-3510] 91
+6.2.43. Page 153-(2025-02)-TC_C_55_CS 91
+6.2.44. Page 165/169 - (2025-02) - TC_E_01_CS/TC_E_09_CS/TC_E_10_CS/TC_E_12_CS/TC_E_13_CS - Extended the
+
+testcases until the Charging Station start charging 92
+6.2.45. Page 174 - (2025-04) - TC_E_17_CS - Aligned configuration before steps with updated prerequisites. 93
+6.2.46. Page 174 - (2024-09) - TC_E_17_CS - Updated prerequisite for test case to correctly specify the applicable TxStopPoint combinations. 94
+6.2.47. Page 176-(2024-11)-TC_E_39_CS-MissingStatusNotificationRequest/NotifyEventRequest. 94
+6.2.48. Page 182 - (2025-04) - TC_E_52_CS - Testcase is not able to determine the authorization is refused in case TxStartPoint is not Authorized. 95
+6.2.49. Page 185 - (2024-09) - TC_E_35_CS - StoppedReason must be validated in Ended event [O20-4467] 95
+6.2.50. Page 188 - (2025-02) - TC_E_22_CS - Stop transaction options - EnergyTransfer stopped - will end transaction . . . . . . 96
+6.2.51. Page 189 - (2025-06) - TC_E_14_CS - StoppedReason validation too strict for remote 96
+6.2.52. Page 199 - (2025-04) - TC_E_27_CS - Remove manual action between step 4/5. 97
+6.2.53. Page 204 - (2025-02) - TC_E_31_CS - Add steps for when running the testcase in Remote mode 97
+6.2.54. Page 214 - (2024-06) TC_E_43_CS Move reusable state TransactionEventsInQueueEnded to Before [768] 98
+6.2.55. Page 217 - (2025-04) - TC_E_46_CS - Testcase updated to use the specialized Authorized15118 reusable state . . . 99
+6.2.56. Page 221 - (2024-06) TC_F_04_CS Made mandatory in part 5, but prerequisite in part 6 was not updated .99
+6.2.57. Page 221 - (2025-02) TC_F_04_CS Prerequisite only if supported. 100
+6.2.58. Page 295 - (2024-09) - TC_J_XX_CS Meter Values 100
+6.2.59. Page 236 - (2025-02) - TC_F_19_CS - The testcase ends while the firmware update is still ongoing . 100
+6.2.60. Page 272 - (2025-02) - TC_H_08_CS Reserve an unspecified EVSE - Accepted 101
+6.2.61. Page 279/280 - (2025-06) - TC_H_15_CS & TC_H_16_CS can only be executed when the connector type of the Charging Station is part of the connectorEnumType. 102
+6.2.62. Page 282 - (2025-02) - TC_H_17_CS - made more explicit on what to validate 102
+6.2.63. Page 297 - (2025-02) - TC_J_02_CS Clock-aligned Meter Values - reporting multiple phases. 104
+6.2.64. Page 297 - (2024-09) - TC_J_02_CS Clock-aligned Meter Values 104
+6.2.65. Page 306 - (2024-06) - TC_J_10_CS - Remove reference to non-existing requirements [4697] 105
+6.2.66. Page 318 - (2025-04) TC_K_09_CS: Removed validFrom/To from test. 105
+6.2.67. Page 343 - (2025-04) TC_K_23_CS: Removed validFrom/To from test. 106
+6.2.68. Page 337 - (2025-04) TC_K_28_CS: Removed validFrom/To from test. 106
+6.2.69. Page 345 - (2025-02) TC_K_XX_CS: Use realistic values for composite schedules 107
+6.2.70. Page 345 - (2024-06) TC_K_35_CS Get Charging Profile - Evseld > 0 + chargingProfilePurpose [773] 108
+6.2.71. Page 352 - (2025-04) - TC_K_39_CS - Validation of scheduleStart 108
+6.2.72. Page 353 - (2025-04) - TC_K_40_CS: startSchedule improvements 109
+6.2.73. Page 355 - (2025-04) - TC_K_41_CS: startSchedule improvement 111
+6.2.74. Page 354/355 - (2025-02) - TC_K_40_CS & TC_K_41_CS - Updated composite schedule validation 112
+6.2.75. Page 355 - (2025-04) - TC_K_41_CS: Added missing EnergyTransferStarted reusable state. 114
+6.2.76. Page 359 - (2025-04) - TC_K_53_CS: Added missing validations. 115
+6.2.77. Page 360 - (2025-02) - TC_K_54_CS: EVConnected must be before Authorization 116
+6.2.78. Page 362 - (2025-02) - TC_K_56_CS: EVConnected must be before Authorization 117
+6.2.79. Page 364 - (2025-02) - TC_K_57_CS: EVConnected must be before Authorization 117
+6.2.80. Page 362 - (2024-09) - TC_K_56_CS Removed expecting triggerReason=ChargingRateChanged [776] 117
+6.2.81. Page 366-(2025-02)-TC_K_58_CS 118
+6.2.82. Page 384 - TC_L_10_CS - Allow Download/InstallationFailed upon AcceptedCanceled 118
+6.2.83. Page 387 - TC_L_06_CS - SecurityEventNotification and FirmwareStatusNotification can be sent in any order.... 119
+6.2.84. Page 422 - (2025-02) - TC_M_15_CS - V2GCertificateChain is not installed before being retrieved . 120
+6.2.85. Page 430 - (2025-06) - TC_M_24_CS - A GetCertificateStatusRequest is also sent for the subCAs 120
+6.2.86. Page 436 - (2025-02) - TC_N_01_CS - Made used component variable configurable 121
+6.2.87. Page 455 - (2025-02) - TC_N_12_CS - Updating test case for using configuration variables 121
+6.2.88. Page 456 - (2025-02) - TC_N_13_CS - Updating test case for using more specific configuration variables. 123
+6.2.89. Page 463 - (2025-02) TC_N_20_CS - Updating test case for using more specific configuration variables. 125
+6.2.90. Page 468 - (2024-06) TC_N_23_CS Offline Notification - OfflineMonitoringEventQueuingSeverity set higher than severityLevel of the monitor [772]. 128
+6.2.91. Page 470 - (2024-09) - TC_N_24_CS - Referring to incorrect use case and requirements [O20-4793] 129
+6.2.92. Page 492 - (2025-02) - TC_N_39_CS - Test case now searches suitable variables to do test with .130
+6.2.93. Page 472 - (2024-12) - TC_N_26_CS - Made test case more explicit and more time before ending . 132
+6.2.94. Page 470 - (2024-12) - TC_N_24_CS - Test case now searches suitable variable to do test with 133
+6.2.95. Page 470 - (2025-02) - TC_N_24_CS - Updating test case for using more specific configuration variables. 135
+6.2.96. Page 482 - (2025-02) - TC_N_63_CS - Clear Customer Information - add manual action to stop session 136
+6.2.97. Page 487 - (2025-04) - TC_N_36_CS - LogStatusNotification(AcceptedCanceled) allowed before GetLogResponse. 137
+
+6.2.98. Page 482 - (2025-04) - TC_N_63_CS - Added missing reusable state EnergyTransferStarted at before steps . . . . . . 138
+6.2.99. Page 493 - (2024-09) - TC_N_41_CS - Set Variable Monitoring - Return to FactoryDefault. 139
+6.2.100. Page 482 - (2024-09) - TC_N_63_CS - Clear Customer Information - Clear and report - customerCertificate....... 139
+6.2.101. Page 482 - (2025-02) - TC_N_63_CS - Added missing configuration state and authorize explicit using Plug and Charge (PnC). 140
+6.2.102. Page 493 - (2024-09) - TC_N_41_CS - Set Variable Monitoring - Return to FactoryDefault. 141
+6.2.103. Page 493 - (2025-02) - TC_N_41_CS - Made less dependent on test case configuration variables, enables predefines monitors 141
+6.2.104. Page 495 - (2024-11) - TC_N_43_CS - Remove incorrect tool validation StatusInfo 145
+6.2.105. Page 495 - (2025-02) - TC_N_43_CS - Updating test case for using more specific configuration variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+6.2.106. Page 497 - (2025-02) - TC_N_45_CS - Updating test case for using more specific configuration variables . . . . . . 148
+6.2.107. Page 501 - (2025-02) - TC_N_51_CS - Updating test case for using more specific configuration variables . . . . . . . 150
+6.2.108. Page 503 - (2025-02) - TC_N_52_CS - Updating test case for using more specific configuration variables . . . . . . . 152
+6.2.109. Page 504 - (2025-02) - TC_N_53_CS - Updating test case for using more specific configuration variables . . . . . . . 154
+6.2.110. Page 505 - (2025-02) - TC_N_56_CS - Made test case configurable using configuration variables 155
+6.2.111. Page 506 - (2025-06) - TC_O_XX_CS - Updated configurations 156
+6.2.112. Page 520 - (2025-02) - TC_O_15_CS - Test case removed 160
+6.2.113. Page 530 - (2025-02) - TC_O_28_CS - Transaction id should be specified for DisplayMessage 160
+6.2.114. Page 533 - (2025-02) - TC_O_32_CS - Made notes about display behaviour more explicit. 160
+6.2.115. Page 544 - (2025-02) - TC_O_39_CS - Wait for StatusNotificationRequest or NotifyEventRequest. 161
+6.2.116. Page 555 - (2024-11) - Remove StatusNotificationRequest from Authorized reusable state Main B steps. 164
+6.2.117. Page 560 - (2025-04) - Reusable states StopAuthorized & Deauthorized. 164
+6.2.118.Deauthorized 166
+6.2.119. Page 566 - (2025-02) - Reusable state RenegotiateChargingLimits 166
+6.2.120. Page 573/151 - (2025-04) - Removed Main steps B from IdTokenCached reusable state and added IdTokenCached15118 167
+6.2.121. Page 574 - (2025-04) - IdTokenLocalAuthList memory state - set Enable to true if implemented 169
+6.2.122. Page 575 - (2024-09) - Reusable state RenewChargingStationCertificate expects a reconnection [784]. 169
+6.2.123. Page 575 - (2025-02) - Reusable state RenewChargingStationCertificate must not do a Reset [5281] . 170
+
+6.3.CSMS 172
+
+6.3.1. Page 593 - (2025-04) - TC_A_11_CSMS - Added post scenario validation for clarification. 172
+6.3.2. Page 593 - (2024-09) - TC_A_11_CSMS - Reconnect using new client certificate 172
+6.3.3. Page 596 - (2024-09) - TC_A_14_CSMS - Update Charging Station Certificate by request of CSMS - Invalid certificate 172
+6.3.4. Page 597 - (2025-04) - TC_A_19_CSMS - Added main steps and clarified tool validations 173
+6.3.5. Page 597 - (2024-09) - TC_A_19_CSMS - Added additional information regarding the use of the client certificates . 174
+6.3.6. Page 597 - (2024-09) - TC_A_19_CSMS - Removed validation of OcppCsmsUrl [O20-4355] 175
+6.3.7. Page 637 - (2024-11) - TC_C_50_CSMS - Changed reference to configured valid idToken to a specific eMAID idToken. 175
+6.3.8. Page 639 - (2024-09) - TC_C_52_CSMS - TC does not use <Configured contract_certificates> 176
+6.3.9. Page 639 - (2025-02) - TC_C_52_CSMS - Certificate needs at least one subCA 176
+6.3.10. Page 640 - (2025-04) - TC_D_01_CSMS - Missing tool validation that the idTokenInfo must be provided for all list entries. 177
+6.3.11. Page 712 - (2024-09) - TC_I_01_CSMS - Show EV Driver running total cost 177
+6.3.12. Page 715 - (2025-02) - TC_I_02_CSMS - Added explicit information about CSMS tariff configuration and sending in needed metervalues 178
+6.3.13. Page 726-760 - (2025-04) - TC_K_XX_CSMS - Improved tool validations to be sure valid Charging Profiles are used 179
+6.3.14. Page 728 - (2024-09) - TC_K_03_CSMS - Not requiring validFrom/To fields in charging profile [O20-4592] and chargingProfileKind must be Absolute [O20-4591]. 186
+6.3.15. Page 733 - (2024-09) - TC_K_10_CSMS - Not requiring validFrom/To fields in charging profile [O20-4592] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+6.3.16. Page 734 - (2024-09) - TC_K_15_CSMS - Not requiring validFrom/To fields in charging profile [O20-4592] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+6.3.17. Page 752 - (2025-06) - TC_K_53_CSMS - Validate that the CSMS let's the Charging Station charging, according to the negotiated limits. 188
+6.3.18.Page 753-(2024-09)-TC_K_55_CSMS,TC_K_57_CSMS,TC_K_58_CSMS,TC_K_59_CSMS Removed triggerReason $=$ ChargingRateChanged [776] 188
+6.3.19. Page 760 - (2024-11) - TC_K_70_CSMS - Updated tool validation chargingProfiles and added preparation step. . . 188
+6.3.20. Page 805/806 - (2025-06) - TC_N_01_CSMS & TC_N_02_CSMS - omit filter fields that are not tested 189
+6.3.21. Page 806 - (2025-06) - TC_N_02_CSMS - component and variable instance need to be omitted 190
+
+6.3.22. Page 824 - (2025-04) - TC_N_62_CSMS - Check only single identifier is provided. 190
+6.3.23. Page 830 - (2024-11) - TC_N_46_CSMS - Updated tool validation sendLocalListRequest 191
+6.3.24. Page 830 - (2025-02) - TC_N_46_CSMS - Aligning configuration variable usage. 191
+6.3.25. Page 854 - (2025-02) - TC_O_27_CSMS - Fixing validations to be more specific for test case 193
+6.3.26. Page 855 - (2025-02) - TC_O_28_CSMS - Fixing validations to be more specific for test case 193
+
+# Disclaimer
+
+Copyright © 2010 - 2025 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
+
+<table><tr><td>Version</td><td>Date</td><td>Description</td></tr><tr><td>2025-09</td><td>2025-09-30</td><td>Includes errata for Part 1, 2, 4, 5 and 6 of OCPP 2.0.1 Edition 3.</td></tr><tr><td>2025-06</td><td>2025-07-08</td><td>Includes errata for Part 2, 5 and 6 of OCPP 2.0.1 Edition 3.</td></tr><tr><td>2025-04</td><td>2025-04-30</td><td>Includes errata for Part 2, 5 and 6 of OCPP 2.0.1 Edition 3.</td></tr><tr><td>2025-02</td><td>2025-03-06</td><td>Includes errata for Part 2, 5 and 6 of OCPP 2.0.1 Edition 3.</td></tr><tr><td>2025-01</td><td>2025-01-23</td><td>Includes errata for Part 1-4 of OCPP 2.0.1 Edition 3</td></tr><tr><td>2024-11</td><td>2024-11-14</td><td>Includes errata for Part 5 and Part 6 of OCPP 2.0.1 Edition 3</td></tr><tr><td>2024-09</td><td>2024-09-25</td><td>Includes errata for Part 4, Part 5 and Part 6 of OCPP 2.0.1 Edition 3</td></tr><tr><td>2024-06</td><td>2024-06-27</td><td>Includes errata for Part 5 and Part 6.</td></tr></table>
+
+# 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 3.
+
+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 2025-09 of the errata. The errata of this version are marked with "(2025-09)" in the section title.
+
+In some cases 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]".
+
+# 0. Part 0
+
+Currently no new errata for OCPP 2.0.1 Edition 3 part 0.
+
+# 1. Part 1
+
+# 1.1. Page 9 - (2025-01) - 3.4. Monitoring
+
+The first sub-bullit is further clarified that it refers to the absolute difference:
+
+<table><tr><td></td><td>Description</td></tr><tr><td>Old</td><td>When thedataType of the variable is integer or decimal, this value represents the difference to be reached to trigger the monitor.</td></tr><tr><td>New</td><td>When thedataType of the variable is integer or decimal, this value represents the absolute difference to be reached to trigger the monitor.</td></tr></table>
+
+# 2. Part 2
+
+# 2.1. Page 5 - (2025-01) - Updated limitations on BasicAuthPassword to increase security
+
+A "passwordString" should not be limited to any set of symbols as this limits its security greatly. There is also no reason for limiting the password size.
+
+Table 1. Primitive Datatypes
+
+<table><tr><td>Datatype</td><td>Description</td></tr><tr><td>passwordString</td><td>This is a UTF-8 encoded case-sensitive string. that can only contain characters from the following character set: "a-z", "A-Z", "0-9" or any of the following limited set of symbols: * - - : + | @ -</td></tr></table>
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>Old text</td><td>A00.FR.205</td><td></td><td>The password SHALL be stored in the BasicAuthPassword configuration variable. It SHALL be a randomly chosen passwordString with a sufficiently high entropy, consisting of minimum 16 and maximum 40 characters (alpha-numeric 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).</td></tr><tr><td>New text</td><td>A00.FR.205</td><td></td><td>The password SHALL be stored in the BasicAuthPassword configuration variable. It SHALL be a randomly chosen passwordString with a sufficiently high entropy, consisting of minimum 16 and a maximum as defined by the maxLimit of configuration variable BasicAuthPassword , which must be at least 40 characters and at most 64. The password SHALL be sent as a UTF-8 encoded string (NOT encoded into octet string or base64).</td></tr><tr><td>Old text</td><td>A00.FR.304</td><td>A00.FR.302</td><td>The password SHALL be stored in the BasicAuthPassword Configuration Variable. It SHALL be a randomly chosen passwordString with a sufficiently high entropy, consisting of minimum 16 and maximum 40 characters (alpha-numeric 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). (Same as A00.FR.205)</td></tr><tr><td>New text</td><td>A00.FR.304</td><td>A00.FR.302</td><td>The password SHALL be stored in the BasicAuthPassword Configuration Variable. It SHALL be a randomly chosen passwordString with a sufficiently high entropy, consisting of minimum 16 and a maximum as defined by the maxLimit of configuration variable BasicAuthPassword , which must be at least 40 characters and at most 64. The password SHALL be sent as a UTF-8 encoded string (NOT encoded into octet string or base64). (Same as A00.FR.205)</td></tr></table>
+
+# 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.
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BasicAuthPassword</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>WriteOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>At least 40, at most 64.</td></tr><tr><td>Description</td><td>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 a maximum as defined by the maxLimit of BasicAuthPassword , which must be at least 40 characters and at most 64. 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.</td></tr></table>
+
+# 2.2. Page 14 - (2025-04) - Section 2.7. ISO 15118 support - Alligned ISO 15118 timeout table with updated version in OCPP 2.1
+
+For reference, the current timing constraints for ISO 15118-2:2014 are:
+
+Table 2. ISO 15118-2 Timing constrains
+
+<table><tr><td>Timeout</td><td>Default</td></tr><tr><td>Sequence Timeouts</td><td>60 seconds</td></tr><tr><td>Sequence Performance Timeouts</td><td>40 seconds</td></tr><tr><td>PaymentDetailsReq/Res</td><td>4.5 seconds</td></tr><tr><td>AuthorizationReq/Res</td><td>1.5 seconds</td></tr><tr><td>CertificateUpdateReq/Res</td><td>4.5 seconds</td></tr><tr><td>CertificateInstallationReq/Res</td><td>4.5 seconds</td></tr></table>
+
+# 2.3. Page 15 - (2025-01) - Improved text FR.04
+
+The requirement did not take into account the pending status and should refer to the applicable use cases B02 and B03.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old text</td><td>FR.04</td><td>When the CSMS did not accept the BootNotificationRequest from the Charging Station AND The Charging Station sends a message other than BootNotificationRequest</td><td>The CSMS SHALL respond with a RPC Framework: CALLERROR:SecurityError.</td><td></td></tr><tr><td>New text</td><td>FR.04</td><td>When the CSMS rejected the BootNotificationRequest from the Charging Station AND The Charging Station sends a message other than BootNotificationRequest</td><td>The CSMS SHALL respond with a RPC Framework: CALLERROR:SecurityError.</td><td>See use cases B0 2 and B03 for details.</td></tr></table>
+
+# 2.4. Page 19 - (2025-01) - Removed requirement A00.FR.003 as the precondition never occurs
+
+Requirement A00.FR.003 describes a precondition that never occurs in which the CSMS connects to the Charging Station. The requirement is therefore removed.
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.003</td><td>If the CSMS tries to connect with a different profile than the Charging Station is using</td><td>The Charging Station SHALL terminate the connection.</td></tr></table>
+
+# 2.5. Page 19/41 - (2025-01) - Allow downgrading security profile from 3 to 2
+
+For migration purposes a Charging Station implementer has now the option for their Charging Stations to allow downgrading the security profile from 3 to 2, because not all CSMSs support security profile 3. ENCS was consulted to identify if this would pose any security risks. This was not the case as security profile 2 still uses TLS, which provides sufficient security.
+
+Table 3. A05 - Upgrade Charging Station Security Profile
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Upgrade Charging Station Security Profile</td></tr><tr><td>2</td><td>ID</td><td>A05</td></tr><tr><td></td><td>Functional block</td><td>A. Security</td></tr><tr><td>3</td><td>Objective(s)</td><td>The CSO wants to increase change the security of the OCPP connection between CSMS and a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>Use case when migrating from OCPP 1.6 without security profiles to OCPP 2.0.1. Before migrating to a security profile, the prerequisites, like installed certificates or password, need to be configured.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sets a new value for the NetworkConfigurationPriority Configuration Variable via SetVariablesRequest, such that the NetworkConnectionProfile for the new (higher) security profile becomes first in the list and the existing connection profile becomes second in the list.
+2. The Charging Station responds with a SetVariablesResponse with status Accepted
+3. The CSMS sends a ResetRequest(OnIdle)
+4. The Charging Station reboots and connects via the new primary NetworkConnectionProfile</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The CSO ensures that a NetworkConnectionProfile has been set using (higher) an allowed security profile AND that the prerequisite(s) for going to a higher the new security profile are met before sending the command to change to a higher the new security profile.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station was successfully upgraded to a higher new security profile.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>For security reasons it is by default not allowed to revert to a lower Security Profile using OCPP.
+Only when the variable AllowSecurityProfileDowngrade is implemented and is set to true, it is allowed to downgrade from profile 3 to profile 2. Even in that case, it is not allowed to revert from profile 2 or profile 3 to security profile 1 using OCPP.</td></tr></table>
+
+Changed A00 requirement:
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>Old text</td><td>A00.FR.005</td><td></td><td>Lowering the security profile that is used, to a less secure profile, is for security reasons, not part of the OCPP specification, and MUST be done through another method, not via OCPP. OCPP messages SHALL NOT be used for this (e.g. SetVariablesRequest or DataTransferRequest).</td></tr><tr><td>New text</td><td>A00.FR.005</td><td></td><td>Lowering the security profile that is used, to a less secure profile, is for security reasons, not recommended.The Charging Station SHALL only allow to lower the security profile if the variable AllowSecurityProfileDowngrade is implemented and set to true . In that case, the Charging Station SHALL only allow to downgrade from profile 3 to profile 2. The Charging Station SHALL NOT allow to downgrade from profile 2 or profile 3 to profile 1 using the OCPP protocol.</td></tr></table>
+
+Added A05 requirements:
+
+Changed/added B09 requirements:
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>New requirement</td><td>A05.FR.08</td><td>The variableAllowSecurityProfileDowngrade is implemented and set to true ANDThe currently active‘SecurityProfile' is 3 ANDThe Charging Station receives SetVariablesRequest for NetworkConfigurationPriority containing profile slots for NetworkConnectionProfiles with a 'securityProfile' value equal to 2.</td><td>The Charging Station SHALL respond with SetVariablesResponse (Accepted)</td></tr><tr><td>New requirement</td><td>A05.FR.09</td><td>The variableAllowSecurityProfileDowngrade is implemented and set to true ANDThe currently active‘SecurityProfile' is higher than 1 ANDThe Charging Station receives SetVariablesRequest for NetworkConfigurationPriority containing profile slots for NetworkConnectionProfiles with a 'securityProfile' value equal to 1.</td><td>The Charging Station SHALL respond with SetVariablesResponse (Rejected)</td></tr><tr><td>New requirement</td><td>A05.FR.10</td><td>The variableAllowSecurityProfileDowngrade is not implemented or implemented and set to false ANDThe Charging Station receives SetVariablesRequest for NetworkConfigurationPriority containing profile slots for NetworkConnectionProfiles with a 'securityProfile' value lower than the currently active security profile</td><td>The Charging Station SHALL respond with SetVariablesResponse (Rejected)</td></tr></table>
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>Old text</td><td>B09.FR.04</td><td>On receipt of the SetNetworkProfileRequest AND the NetworkConnectionProfile contains a lower securityProfile than stored at the configuration variable SecurityProfile</td><td>The Charging Station SHALL respond by sending a SetNetworkProfileResponse message, with status Rejected</td></tr><tr><td>New text</td><td>B09.FR.04</td><td>The variable AllowSecurityProfileDowngrade is not implemented or implemented and set to false AND The Charging Station receives a SetNetworkProfileRequest AND the NetworkConnectionProfile contains a lower securityProfile than the currently active security profile</td><td>The Charging Station SHALL respond by sending a SetNetworkProfileResponse message, with status Rejected</td></tr><tr><td rowspan="2">New requirement</td><td rowspan="2">B09.FR.31</td><td>The variable
+AllowSecurityProfileDowngrade is implemented and set to true</td><td rowspan="2">The Charging Station SHALL respond with SetVariablesResponse (Accepted)</td></tr><tr><td>AND
+The currently active
+'SecurityProfile' is 3 AND
+The Charging Station receives a
+SetNetworkProfileRequest AND
+the NetworkConnectionProfile
+contains a securityProfile with a
+value of 2.</td></tr><tr><td rowspan="3">New requirement</td><td rowspan="3">B09.FR.32</td><td>The variable
+AllowSecurityProfileDowngrade is implemented and set to true</td><td rowspan="3">The Charging Station SHALL respond with
+SetVariablesResponse (Rejected)</td></tr><tr><td>AND
+The currently active
+'SecurityProfile' is higher than 1</td></tr><tr><td>AND
+The Charging Station receives a
+SetNetworkProfileRequest AND
+the NetworkConnectionProfile
+contains a securityProfile with a
+value of 1.</td></tr></table>
+
+Added referenced variable:
+
+AllowSecurityProfileDowngrade
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>ijklname</td><td colspan="2">AllowSecurityProfileDowngrade</td></tr><tr><td>ijklattributes</td><td>mutability</td><td>ReadWrite/ReadOnly</td></tr><tr><td>ijklcharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable is implemented and set to true, then the Charging Station allows downgrading the security profile from 3 to 2.
+For security reasons it is not allowed to revert from profile 2 or profile 3 to security profile 1 using OCPP.</td></tr></table>
+
+# 2.6. Page 26 - (2025-01) - 1.3.7. TLS with Client Side Certificates Profile - Requirements
+
+A new requirement is added to support A00.FR.429:
+
+New requirement
+
+Table 4. Security Profile 3 - TLS with Client Side Certificates - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.430</td><td>If the Charging Station certificate has expired</td><td>The Charging Station SHOULD still attempt to establish a connection with the CSMS and leave the decision to accept the connection up to the CSMS.</td></tr></table>
+
+# 2.7. Page 28 - (2025-01) - Certificate Hierarchy
+
+A note has been added to the specification to warn OCPP implementers about the potential risks involved with the installation of CA bundles.
+
+# 2.8. Page 31 - (2025-01) - A02/A03 - Updated error handling
+
+NOT RECOMMENDED in the error handling is confusing as there is already a requirement that explicitly states that the Charging Station SHALL retry after "CertSigningWaitMinimum".
+
+<table><tr><td>7</td><td>Error handling</td><td>The CSMS accepts the CSR request from the Charging Station, before forwarding it to the CA. But when the CA cannot be reached, or rejects the CSR, the Charging Station will never be known. The CSMS may do some checks on the CSR, but cannot do all the checks that a CA does, and it does not prevent connection timeout to the CA. When something like this goes wrong, either the CA is offline or the CSR send by the Charging Station is not correct, according to the CA. In both cases this is something an operator at the CSO needs to be notified of. The operator then needs to investigate the issue. When resolved, the operator can re-run A02. It is NOT RECOMMENDED to let the Charging Station retry when the certificate is not send within X minutes or hours. When the CSR is incorrect, that will not be resolved automatically. It is possible that only a new firmware will fix this.</td></tr></table>
+
+# 2.9. Page 34 - (2025-01) - Disallow client certificates future validity date
+
+Currently the specification is unclear on whether accepting client certificates with a future validity date is intended behavior. If it would be allowed behavior, several problems were identified. For example, there would be no way for the CSMS to manage these (ghost) client certificates using OCPP. ENCS was consulted if there would be any security risks when not allowing accepting client certificates with a future validity date. ENCS identified no security risks, therefore it was decided to not allow accepting client certificates with a future validity date. In addition clarifications have been made to describe how to handle non-happy flow scenarios in which the Charging Station is unable to successfully connect using the new client certificate in combination with the NetworkConnectionProfile mechanism described at use case B10.
+
+Changed/added A02 requirements:
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old text</td><td>A02.FR.06</td><td></td><td>The Charging Station SHALL verify the validity of the signed certificate in the CertificateSignedRequest message, checking at least the period when the certificate is valid, the properties in Certificate Properties, and that it is part of the Charging Station Operator certificate hierarchy as described in Certificate Hierarchy.</td><td></td></tr><tr><td>New text</td><td>A02.FR.06</td><td></td><td>The Charging Station SHALL verify the validity of the signed certificate in the CertificateSignedRequest message, checking that the current date (at the time of the update) is within the certificate's validity period, the properties in Certificate Properties, and that it is part of the Charging Station Operator certificate hierarchy as described in Certificate Hierarchy.</td><td>When providing a newly signed client certificate with a start period that equals the current time, the CSMS should take into account that there might be a slight discrepancy in the time between the Charging Station and CSMS. This could cause the Charging Station to reject the new certificate, because in case a small time difference exists, the validity period might (just) be in the future for the device.</td></tr><tr><td>Old text</td><td>A02.FR.08</td><td></td><td>The Charging Station SHALL switch to the new certificate as soon as the current date and time is after the 'Not valid before' field in the certificate (e.g. by closing the websocket and TLS connection and reconnecting with the new certificate).</td><td></td></tr></table>
+
+Changed/added A03 requirements:
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>New text</td><td>A02.FR.08</td><td>If the certificate is valid.</td><td>The Charging Station SHALL respond to the CertificateSignedRequest with status Accepted AND the Charging Station SHALL switch to the new certificate by reconnecting the websocket and TLS connection.</td><td></td></tr><tr><td>Old text</td><td>A02.FR.09</td><td>If the Charging Station contains more than one valid certificate of the ChargingStationCertificat e type.</td><td>The Charging Station SHALL use the newest certificate, as measured by the start of the validity period.</td><td></td></tr><tr><td>New text</td><td>A02.FR.09</td><td></td><td><Requirement removed></td><td></td></tr><tr><td>Old text</td><td>A02.FR.10</td><td>A02.FR.09 AND When the Charging Station has validated that the new certificate works</td><td>The Charging Station MAY discard the old certificate. It is RECOMMENDED to store old certificates for one month, as fallback.</td><td></td></tr><tr><td>New text</td><td>A02.FR.10</td><td>(A02.FR.08 OR A02.FR.28) AND The Charging Station successfully connected to the CSMS using either one of the certificates.</td><td>The Charging Station SHALL discard the client certificate that is NOT in use.</td><td>This is to prevent having multiple client certificates installed at the Charging Station, which the CSMS is unable to manage.</td></tr><tr><td>New requirement</td><td>A02.FR.28</td><td>A02.FR.08 AND the charging station was not able to successfully connect to any of the configured entries of NetworkConfigurati onPriority using the new certificate AND The Charging Station supports either one or both reconnection mechanisms described at requirements; B10.FR.07 and B10.FR.08.</td><td>The Charging Station SHALL for the reconnection mechanism described at B10.FR.07 fallback to the old client certificate AND for the reconnection mechanism described at B10.FR.08 alternate between using the old and new client certificate after all NetworkConfigurationPriority entries.</td><td>As described by requirement B10.FR.09, the Charging Station SHOULD NOT stop trying to reconnect to the CSMS. This is to prevent the Charging Station from becoming a stranded asset.</td></tr><tr><td>New requirement</td><td>A02.FR.29</td><td>A02.FR.10 AND The Charging Station discarded the new client certificate.</td><td>The Charging Station SHOULD send a SecurityEventNotification DiscardedRenewedClientCertificate to the CSMS.</td><td>Otherwise the CSMS is not aware that the Charging Station discarded the new client certificate and the CSMS should again trigger a client certificate renewal.</td></tr></table>
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old text</td><td>A03.FR.06</td><td></td><td>The Charging Station SHALL verify the validity of the signed certificate in the CertificateSignedRequest message, checking at least the period when the certificate is valid, the properties in Certificate Properties, and that it is part of the Charging Station Operator certificate hierarchy as described in Certificate Hierarchy. (Same as A02.FR.06)</td><td></td></tr><tr><td>New text</td><td>A03.FR.06</td><td></td><td>The Charging Station SHALL verify the validity of the signed certificate in the CertificateSignedRequest message, checking that the current date (at the time of the update) is within the certificate's validity period, the properties in Certificate Properties, and that it is part of the Charging Station Operator certificate hierarchy as described in Certificate Hierarchy. (Same as A02.FR.06)</td><td>When providing a newly signed client certificate with a start period that equals the current time, the CSMS should take into account that there might be a slight discrepancy in the time between the Charging Station and CSMS. This could cause the Charging Station to reject the new certificate, because in case a small time difference exists, the validity period might (just) be in the future for the device.</td></tr><tr><td>Old text</td><td>A03.FR.08</td><td></td><td>The Charging Station SHALL switch to the new certificate as soon as the current date and time is after the 'Not valid before' field in the certificate (e.g. by closing the websocket and TLS connection and reconnecting with the new certificate). (Same as A02.FR.08)</td><td></td></tr><tr><td>New text</td><td>A03.FR.08</td><td>If the certificate is valid.</td><td>The Charging Station SHALL respond to the CertificateSignedRequest with status Accepted AND the Charging Station SHALL switch to the new certificate by reconnecting the websocket and TLS connection. (Same as A02.FR.08)</td><td></td></tr><tr><td>Old text</td><td>A03.FR.09</td><td>If the Charging Station contains more than one valid certificate of the ChargingStationCertificate type.</td><td>The Charging Station SHALL use the newest certificate, as measured by the start of the validity period. (Same as A02.FR.09)</td><td></td></tr><tr><td>New text</td><td>A03.FR.09</td><td></td><td><Requirement removed></td><td></td></tr><tr><td>Old text</td><td>A03.FR.10</td><td>A03.FR09 AND When the Charging Station has validated that the new certificate works</td><td>The Charging Station MAY discard the old certificate. It is RECOMMENDED to store old certificates for one month, as fallback. (Same as A02.FR.10)</td><td></td></tr><tr><td>New text</td><td>A03.FR.10</td><td>(A03.FR.08 OR A03.FR.24) AND The Charging Station successfully connected to the CSMS using either one of the certificates.</td><td>The Charging Station SHALL discard the client certificate that is NOT in use. (Same as A02.FR.10)</td><td>This is to prevent having multiple client certificates installed at the Charging Station, which the CSMS is unable to manage.</td></tr><tr><td>New requirement</td><td>A03.FR.24</td><td>A03.FR.08 AND the charging station was not able to successfully connect to any of the configured entries of NetworkConfigurati onPriority using the new certificate AND The Charging Station supports either one or both reconnection mechanisms described at requirements; B10.FR.07 and B10.FR.08.</td><td>The Charging Station SHALL for the reconnection mechanism described at B10.FR.07 fallback to the old client certificate AND for the reconnection mechanism described at B10.FR.08 alternate between using the old and new client certificate after all NetworkConfigurationPriority entries. (Same as A02.FR.28)</td><td>As described by requirement B10.FR.09, the Charging Station SHOULD NOT stop trying to reconnect to the CSMS. This is to prevent the Charging Station from becoming a stranded asset.</td></tr><tr><td>New requirement</td><td>A03.FR.25</td><td>A03.FR.10 AND The Charging Station discarded the new client certificate.</td><td>The Charging Station SHOULD send a SecurityEventNotification DiscardedRenewedClientCertificate to the CSMS. (Same as A02.FR.29)</td><td>Otherwise the CSMS is not aware that the Charging Station discarded the new client certificate and the CSMS may need to trigger a new client certificate renewal.</td></tr></table>
+
+Changed/added B10 requirements:
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old text</td><td>B10.FR.07</td><td>B10.FR.03 AND
+All
+NetworkProfileConn
+ctionAttempts for
+every entry of
+NetworkConfigurati
+onPriority failed.</td><td>The Charging Station SHOULD fallback and start
+'reconnecting' to the NetworkConnectionProfile for
+which the last successful connection was made.</td><td>'reconnecting' in this
+requirement, refers to the
+reconnection mechanism
+described at section 5.3.
+Reconnecting from "Part
+4 - JSON over
+WebSockets
+implementation guide".</td></tr><tr><td>New text</td><td>B10.FR.07</td><td>B10.FR.09</td><td>The Charging Station SHOULD fallback and start
+'reconnecting' to the NetworkConnectionProfile for
+which the last successful connection was made.</td><td>'reconnecting' in this
+requirement, refers to the
+reconnection mechanism
+described at section 5.3.
+Reconnecting from "Part
+4 - JSON over
+WebSockets
+implementation guide".</td></tr><tr><td>New requirement</td><td>B10.FR.08</td><td>B10.FR.09</td><td>The Charging Station SHOULD restart connecting
+with all configured entries of the
+NetworkConfigurationPriority</td><td></td></tr><tr><td>New requirement</td><td>B10.FR.09</td><td>B10.FR.03 AND
+All
+NetworkProfileConn
+ctionAttempts for
+every entry of
+NetworkConfigurati
+onPriority failed.</td><td>The Charging Station SHOULD NOT stop trying to
+reconnect to the CSMS. The Charging Station
+SHOULD implement either one or both reconnecting
+mechanisms described at requirements; B10.FR.07
+and B10.FR.08.</td><td>This is to prevent the
+Charging Station from
+becoming a stranded
+asset.</td></tr></table>
+
+# 2.10. Page 58/60 - (2025-01) - Missing requirement information about omitting the value for WriteOnly variables
+
+The specification does describe already that the value for WriteOnly variables need to be omitted, however this information is not part of a requirement yet.
+
+Changed B07 requirement:
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old text</td><td>B07.FR.03</td><td>B07.FR.01</td><td>The Charging Station SHALL send the requested information via one or more NotifyReportRequest messages to the CSMS.</td><td>It is good practice to send the report data in as few messages as possible in order to limit data overhead.</td></tr><tr><td>New text</td><td>B07.FR.03</td><td>B07.FR.01</td><td>The Charging Station SHALL send the requested information, excluding the value of WriteOnly variables, via one or more NotifyReportRequest messages to the CSMS.</td><td>It is good practice to send the report data in as few messages as possible in order to limit data overhead.</td></tr></table>
+
+Changed B08 requirement:
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>Old text</td><td>B08.FR.03</td><td>B08.FR.01</td><td>The Charging Station SHALL send the requested information via one or more NotifyReportRequest messages to the CSMS.</td></tr><tr><td>New text</td><td>B08.FR.03</td><td>B08.FR.01</td><td>The Charging Station SHALL send the requested information, excluding the value of WriteOnly variables, via one or more NotifyReportRequest messages to the CSMS.</td></tr></table>
+
+# 2.11. Page 63 - (2025-09) - B09.FR.02/04/05 - Added optional reasonCode
+
+A mention of adding an optional reasonCode when a SetNetworkProfileRequest is rejected, has been added.
+
+Changed requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B09.FR.02</td><td>On receipt of the SetNetworkProfileRequest</td><td>The Charging Station SHALL validate the content. If the content is invalid, the Charging Station SHALL respond by sending a SetNetworkProfileResponse message, with status Rejected and optional statusInforeasonCode = "InvalidNetworkConf"</td><td>Matches B09.FR.34 for NetworkConfiguration.</td></tr><tr><td>B09.FR.04</td><td>The variable AllowSecurityProfileDowngrade is not implemented or implemented and set to false AND the Charging Station receives a SetNetworkProfileRequest AND the NetworkConnectionProfile contains a lower securityProfile than the currently active security profile</td><td>The Charging Station SHALL respond by sending a SetNetworkProfileResponse message, with status Rejected and optional statusInforeasonCode = "NoSecurityDowngrade"</td><td>Matches B09.FR.35 for NetworkConfiguration.</td></tr><tr><td>B09.FR.05</td><td>When the value of configurationSlot in SetNetworkProfileRequest does not match an entry in valuesList of NetworkConfigurationPriority</td><td>The Charging Station SHALL respond by sending a SetNetworkProfileResponse message with status Rejected with optional statusInforeasonCode = "InvalidConfSlot"</td><td></td></tr></table>
+
+# 2.12. Page 64 - (2025-09) - B09.FR.31/31 - Improved definition
+
+Requirement B09.FR.31 has been rephrased to reject downgrading from any security profile to profile 1, rather than allowing a downgrade from 3 to 2 and disallowing from 2 to 1. As a result B09.FR.32 has now been removed.
+
+Changed requirements
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>B09.FR.31</td><td>The variableAllowSecurityProfileDowngrade isimplemented and set to true ANDThe currently active‘SecurityProfile' is 3 ANDThe Charging Station receives aSetNetworkProfileRequest ANDthe NetworkConnectionProfilecontains a securityProfile with a value of 2.</td><td>The Charging Station SHALL respond with SetVariablesResponse(Accepted)</td><td></td></tr><tr><td>New</td><td>B09.FR.31</td><td>The variableAllowSecurityProfileDowngrade isimplemented and set to true AND the currently active 'SecurityProfile' is higher than 1 AND the Charging Station receives a SetNetworkProfileRequest with a NetworkConnectionProfile with securityProfile = 1</td><td>The Charging Station SHALL respond with SetNetworkProfileResponse with statusRejected and optional statusInforeasonCode = "NoSecurityDowngrade"</td><td></td></tr><tr><td>Delete</td><td>B09.FR.32</td><td>The variableAllowSecurityProfileDowngrade isimplemented and set to true AND The currently active 'SecurityProfile' is higher than 1 AND The Charging Station receives a SetNetworkProfileRequest AND the NetworkConnectionProfile contains a securityProfile with a value of 1.</td><td>The Charging Station SHALL respond with SetVariablesResponse(Rejected)</td><td></td></tr></table>
+
+# 2.13. Page 66 - (2025-04) - B10.FR.03/04/10 - Migrate to new NetworkConnectionProfile
+
+Changed requirements
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>B10.FR.03</td><td>B10.FR.04 AND When connecting fails</td><td>The Charging Station SHALL make the number of attempts as configured in NetworkProfileConnectionAttempts per entry of NetworkConfigurationPriority.</td><td></td></tr><tr><td>New</td><td>B10.FR.03</td><td>After a reboot OR When connection to CSMS is lost</td><td>The Charging Station SHALL make the number of attempts as configured in NetworkProfileConnectionAttempts per entry of NetworkConfigurationPriority.</td><td></td></tr><tr><td>Old</td><td>B10.FR.04</td><td>B10.FR.01 OR B09.FR.01 AND After a reboot</td><td>The Charging Station SHALL begin connecting to the first entry of NetworkConfigurationPriority</td><td>Same as A05.FR.05</td></tr><tr><td>New</td><td>B10.FR.04</td><td>(B10.FR.01 OR B09.FR.01) AND After a reboot</td><td>The Charging Station SHALL begin connecting to the first entry of NetworkConfigurationPriority</td><td>Same as A05.FR.05</td></tr></table>
+
+The following requirement is added to make explicit that a BootNotification must be sent, or else Charging Station might connect to a new CSMS without it, in which case CSMS would respond with a CALLERROR(SecurityEvent).
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B10.FR.10 (new)</td><td>B10.FR.03 AND Charging Station successfully connected after having switched to a different NetworkConnectionProfile</td><td>Charging Station SHALL send a BootNotificationRequest to CSMS to reestablish its registration status, even if it has not rebooted since last being accepted by any CSMS.</td><td>Charging Station does not need to check whether the CSMS it connected to, is actually one that it has not connected to before.</td></tr></table>
+
+# 2.14. Page 67 - (2025-06) - B11 - Clarify meaning of OnIdle for Reset
+
+The "idle state" is defined in Terminology as: "In both use cases and sequence diagrams, Idle status is referred as the state in which a Charging Station is not performing any use case related tasks. Condition during which the equipment can promptly provide a primary function but is not doing so." This is a broader concept, than having an active transaction. A remark is added to the use case to explain that.
+
+The sentence about persistent states and ResetResponse did not belong in Remarks section.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reset - Without Ongoing Transaction</td></tr><tr><td>...</td><td>...</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>Persistent states: for example, EVSE set to Unavailable SHALL persist.
++ [line-through]#The Charging Station responds with ResetResponse.
+OnIdle refers to the "idle state" of a charging station. This is when the Charging Station is not performing any use case related tasks that might interfere with a reset process. The most obvious case is being involved in an active transaction, but there are other conditions when the Charging Station is not idle, for example, when a firmware update process is ongoing, a log file is uploaded to CSMS, a reservation is pending or a cable is still locked in the Charging Station.</td></tr></table>
+
+# 2.15. Page 69 - (2025-01) - B11 - Reset without Ongoing Transaction - Requirements
+
+The definition of B11.FR.06 has been improved:
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>Old text</td><td>B11.FR.06</td><td>B11.FR.01ANDFor example there is a firmware update ongoing that cannot be interrupted.</td><td>The Charging Station SHALL respond with a status Rejected.</td></tr><tr><td>New text</td><td>B11.FR.06</td><td>B11.FR.01ANDCharging Station is at this moment not able to perform a reset</td><td>The Charging Station SHALL respond with a status Rejected.</td></tr></table>
+
+# 2.16. Page 73 - (2025-01) - B12 - Reset with Ongoing Transaction - Requirements
+
+The requirement B12.FR.04, 08 and added B12.FR.10 have been improved:
+
+At the (2025-04) version, the old text requirement definitions have been corrected, because they already contained the revision instead of the original text from the edition 3 specification. In addition, requirement B12.FR.10 was newly added to edition 3, not updated.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>Old text (Corrected in 2025-04)</td><td>B12.FR.04</td><td>If no evseld is supplied AND If any transaction is in progress and an Immediate Reset is received.</td><td>The Charging Station SHALL attempt to terminate any transaction in progress and send a TransactionRequest(eventType = Ended) message before performing a reboot.</td></tr><tr><td>New text</td><td>B12.FR.04</td><td>If no evseld is supplied AND If any transaction is in progress and an Immediate Reset is received.</td><td>The Charging Station SHALL attempt to terminate any transaction in progress and send a TransactionRequest(eventType = Ended) message with triggerReason = ResetCommand and transactionInfo.stoppedReason = ImmediateReset for each terminated transaction before performing a reboot.</td></tr><tr><td>Old text (Corrected in 2025-04)</td><td>B12.FR.08</td><td>If an evseld is supplied AND If a transaction is in progress on the EVSE and an Immediate Reset is received.</td><td>The Charging Station SHALL attempt to terminate the transaction in progress on the EVSE and send a TransactionEventRequest (eventType = Ended) message before performing a reset.</td></tr><tr><td>New text</td><td>B12.FR.08</td><td>If an evseld is supplied AND If a transaction is in progress on the EVSE and an Immediate Reset is received.</td><td>The Charging Station SHALL attempt to terminate the transaction in progress on the EVSE and send a TransactionEventRequest (eventType = Ended) message with triggerReason = ResetCommand and transactionInfo.stoppedReason = ImmediateReset before resetting the EVSE.</td></tr><tr><td>Added (Corrected in 2025-04)</td><td>B12.FR.10</td><td>B12.FR.02 AND Charging Station is at this moment not able to perform an Immediate reset for a reason other than the fact that a transaction is in progress</td><td>The Charging Station SHALL return a ResetResponse Rejected</td></tr></table>
+
+# 2.17. Page 77 - (2025-01) - 1.6 Relationship between authorization and transaction
+
+A new section has been added after 1.5 Unknown Offline Authorization
+
+This section is informative.
+
+The purpose of authorization is twofold. It ensures in the first place, that energy is only offered to a known user (represented by the idToken), which is essential for billing. In the second place, it ensures that only the user who was authorized in the first place (or a member of the same group of users) is allowed to unplug the cable. This is an important safeguard against cable theft in situations where the charging station does not have a fixed cable and the user brings its own charging cable.
+
+Authorization and the duration of the authorization period are not strictly tied to a transaction: it is possible to have transactions without explicit authorization, e.g. in the case of a charging station that can be started with a push button. In that case one could say that there is a permanent authorization for anyone to charge.
+
+The start of the authorization period:
+
+- can take place before a transaction is started (e.g. when a cable is not yet connected), or
+- can cause a transaction to be started (e.g. when authorization is defined as the start of a transaction by setting TxStartPoint = Authorized), or
+- can happen after a transaction has already started (e.g. when connection of the cable is defined as the start of a transaction by setting TxStartPoint = EVConnected).
+
+(See chapter E.1.1 "Flexible transaction start/stop" for a description of transaction start and stop points.)
+
+In any case, authorization (or authorization period) ends when the same idToken is presented again for authorization, or when the transaction ends. This means that ending of the authorization period:
+
+- can happen during a transaction without ending the transaction (e.g. when idToken is presented again, but TxStopPoint = EVConnected), or
+- can cause the transaction to end (e.g. when idToken is presented again and TxStopPoint = Authorized), or
+- can be caused by the end of the transaction (e.g. when idToken is not presented for authorization, but the cable is disconnected and TxStopPoint = EVConnected). or
+- can be caused by cable plug-out if no transaction was started.
+
+A Charging Station defines when authorization starts (i.e. upon receiving theauthorizeResponse, or when authorizing locally via authorization cache or local authorization list) and when authorization ends (i.e. when idToken is presented a second time, or when the transaction ends). Charging Station notifies CSMS about this, as follows:
+
+- If authorization occurs before start of the transaction, Charging Station tells CSMS that authorization has taken place, by including the idToken in the first TransactionEventRequest of the transaction.
+- If authorization occurs within a transaction or at the start of a transaction, Charging Station reports this by including the idToken in TransactionEventRequest together with a triggerReason = Authorized.
+
+# 2.18. Page 80 - (2025-01) - C01 - EV Driver Authorization using RFID - Requirements
+
+A requirement has been added to define when two idTokens are considered equal:
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C01.FR.25</td><td></td><td>Two [idtokentype] elements are considered to be equal when they have the same value for the fields idToken.idToken and idToken.type</td><td>additionalInfo is not taken into account when comparing. See C01.FR.02, C01.FR.03, C01.FR.05 for idToken requirements where idTokens are compared.</td></tr></table>
+
+# 2.19. Page 80 - (2025-01) - C01 - EV Driver Authorization using RFID - Requirements
+
+A requirement has been added to make explicit that authorization ends after EVConnectionTimeout:
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C01.FR.26</td><td>When an idToken has been authorized and the EV Driver does not plug in the charging cable before the timeout set by the Configuration Variable: EVConnectionTimeOut</td><td>Charging Station SHALL end the authorization of idToken</td><td>See also E03.FR.05 and F02.FR.07/08 for additional behavior in case a transaction had already been started.</td></tr></table>
+
+# 2.20. Page 99 - (2025-01) - C09- Authorization by Groupld - Requirements
+
+A GroupIdToken is controlled by CSMS. This should be reflected in the type.
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C09.FR.13</td><td></td><td>The field idToken.type of a GroupIdToken SHOULD be Central</td></tr></table>
+
+# 2.21. Page 101 - (2025-01) - Updated requirements related to clarify the relation between AuthCacheLifeTime and cacheExpiryDateTime
+
+The OCPP specification already describes the relation between AuthCacheLifeTime and cacheExpiryDateTime at section 1.3 Authorization Cache, however the requirements are missing this information.
+
+Changed C10 requirements:
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old text</td><td>C10.FR.10</td><td>When the validity of an Authorization Cache entry expires.</td><td>The Authorization Cache entry SHALL be removed from the cache or changed to Expired.</td><td></td></tr><tr><td>New text</td><td>C10.FR.10</td><td>NOT C10.FR.13 AND when more than AuthCacheLifeTime seconds have passed since idTokenInfo was last updated</td><td>The Authorization Cache entry SHALL be removed from the cache or changed to Expired.</td><td>A cacheExpirationDateTime in the past will prevent an idToken from being stored in the authorization cache, or remove it from authorization cache if it was already present. This is used e.g. for prepaid accounts that should not be kept in authorization cache.</td></tr><tr><td>Old text</td><td>C10.FR.13</td><td>When IdTokenInfoType contains a value for cacheExpiryDateTime</td><td>The time a token is considered to be present in the cache is determined by cacheExpiryDateTime. This variable indicates the date and time after which a token expires in the Authorization Cache.</td><td>This expiry of the cache is not the same as the expiration date that is set for the IdToken (e.g. RFID card expiry date).</td></tr><tr><td>New text</td><td>C10.FR.13</td><td>When IdTokenInfoType contains a value for cacheExpiryDateTime and current time is greater than idTokenInfo.cacheExpiry DateTime</td><td>The Authorization Cache entry SHALL be removed from the cache or changed to Expired.</td><td>This expiry of the cache is not the same as the expiration date that is set for the IdToken (e.g. RFID card expiry date).</td></tr></table>
+
+# 2.22. Page 113 - (2025-01) - C16 - Stop Transaction with a Master Pass - Requirements
+
+Requirements about actual stopping of transactions have been added/updated:
+
+Updated requirement
+
+Table 5. C16 - Stop Transaction with a Master Pass - Requirements
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>Old text</td><td>C16.FR.01</td><td>User presents an IdToken that has a groupId equal to MasterPassGroupId AND The Charging Station has a UI with input capabilities.</td><td>The Charging Station SHALL "show" the Master Pass UI to let user select which transaction to stop.</td></tr><tr><td>New text</td><td>C16.FR.01</td><td>User presents an IdToken that has a groupId equal to MasterPassGroupId AND The Charging Station has a UI with input capabilities.</td><td>The Charging Station SHALL "show" the Master Pass UI to let user select which transaction to stop.</td></tr><tr><td>Old text</td><td>C16.FR.02</td><td>User presents an IdToken that has a groupId equal to MasterPassGroupId AND the Charging Station does NOT have a UI.</td><td>The Charging Station SHALL stop all ongoing transactions as described in use case E07.</td></tr><tr><td>New text</td><td>C16.FR.02</td><td>User presents an IdToken that has a groupId equal to MasterPassGroupId AND the Charging Station does NOT have a UI.</td><td>The Charging Station SHALL stop all ongoing transactions as described in use case E07.</td></tr></table>
+
+New requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C16.FR.07</td><td>C16.FR.01 OR C16.FR.02</td><td>Charging Station SHALL stop the transaction as described in use case E07.</td></tr><tr><td>C16.FR.07</td><td>C16.FR.07</td><td>Charging Station SHALL set transactionInfo.stoppedReason = MasterPass in TransactionRequest with eventType = Ended.</td></tr></table>
+
+# 2.23. Page 129 - (2025-01) - Updated sequence diagram E01 S5
+
+After all added clarifications on the PowerPathClosed TxStartPoint the corresponding sequence diagram was not updated to reflect this.
+
+
+Figure 43. Sequence Diagram: Start Transaction options - PowerPathClosed
+
+# 2.24. Page 151 - (2025-02) - E06.FR.05 for DataSigned as TxStopPoint is invalid
+
+DataSigned cannot be used as a TxStopPoint. This requirement is therefore invalid and confusing when present.
+
+Deleted requirement
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>Delete</td><td>E06.FR.05</td><td>TxStopPoint contains: DataSigned AND Charging Station can no longer retrieve signed meter values.</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr></table>
+
+# 2.25. Page 152 - (2025-01) - E07 - Improved scenario description names
+
+The use case did not clearly indicate when the scenario and the alternative scenario are applicable.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Transaction locally stopped by IdToken</td></tr><tr><td>2</td><td>ID</td><td>E07</td></tr><tr><td>3</td><td>Objective(s)</td><td>The EV Driver wants to stop an ongoing transaction, by locally presenting his IdToken.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the EV Driver can stop a transaction when he wants to leave the charging station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario descriptionReportingStopAuthorized withend of transaction</td><td>TxStopPoint = Authorized (or PowerPathClosed)1. The EV Driver presents IdToken a second time to end charging.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 TransactionRequest (eventType = Ended) with triggerReason = StopAuthorized and stoppedReason = Local.4. The CSMS responds with a TransactionResponse.</td></tr><tr><td></td><td>Alternative scenario(s)ReportingStopAuthorized inUpdate event first, thenend transaction</td><td>TxStopPoint = Authorized (or PowerPathClosed)1. The EV Driver presents IdToken a second time to end charging.2. The Charging Station sends a TransactionRequest (eventType = Updated) with triggerReason = StopAuthorized3. The CSMS responds with a TransactionResponse.4. The Charging Station stops the energy transfer and if the cable is not permanently attached, the Charging Station unlocks the cable.5. The Charging Station sends a TransactionRequest (eventType = Ended) with triggerReason = ChargingStateChanged, transactionInfo.chargingState = EVConnected6. The CSMS responds with a TransactionResponse.</td></tr><tr><td colspan="3">...</td></tr></table>
+
+# 2.26. Page 154 - (2025-01) - E07 - Transaction locally stopped by IdToken
+
+Sequence diagram Fig. 55 is updated to fix an error.
+
+The fourth TransactionEventRequest needs to have: triggerReason = ChargingStateChanged, chargingState = EVConnected
+
+
+Figure 55. Sequence Diagram: Transaction locally stopped by IdToken with TransactionEventRequest reported strictly by TxStopPoint configuration
+
+# 2.27. Page 155 - (2025-09) - E07.FR.07 - Improved precondition
+
+The precondition of E07.FR.07 was written as text, but it is more precise to refer another requirement.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>E07.FR.07</td><td>As part of the normal transaction termination.</td><td>The Charging Station SHALL unlock the cable (if not permanently attached).</td><td></td></tr><tr><td>New</td><td>E07.FR.07</td><td>E07.FR.02</td><td>The Charging Station SHALL unlock the cable (if not permanently attached).</td><td></td></tr></table>
+
+# 2.28. Page 198 - (2025-01) - G01 - Status Notification - Requirements
+
+A requirement is added to make explicit that a plug-in on reserved connector does not automatically change status to Occupied.
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>G01.FR.09</td><td>The connector is Reserved when an EV is connecting AND
+( No IdToken is presented OR
+EV driver presents an IdToken not matching the reservation )</td><td>Connector status SHALL not change.</td></tr></table>
+
+# 2.29. Page 197 - (2025-01) - G01 - Status Notification - State transition overview for connecting/disconnecting
+
+The following text from the table has to be removed:
+
+<table><tr><td>Initial</td><td>Cable plugin</td><td>Cable unplug</td></tr><tr><td>Available</td><td>→ Occupied</td><td>-</td></tr><tr><td>Occupied</td><td>-</td><td>→ Available
+(→ Unavailable, if scheduled to become Unavailable)</td></tr><tr><td>Reserved</td><td>(→ Occupied, only if authorized for reserved IdToken)</td><td>-</td></tr><tr><td>Unavailable</td><td>-</td><td>-</td></tr><tr><td>Faulted</td><td>-</td><td>-</td></tr></table>
+
+# 2.30. Page 208 - (2025-01) - H. Reservation - Introduction
+
+The Introduction text has been updated:"
+
+<table><tr><td>Old text</td><td>This Functional Block describes the reservation functionality of OCPP. The reservation functionality enables an EV Driver to make a reservation of a Charging Station/EVSE, ensuring an available Connector at a Charging Station when he arrives.
+With Charging Stations not being abundantly available, and EVs having limited range, EV Drivers plan their trips from Charging Station to Charging Station. They need to know for sure they can use a Charging Station they plan to go to. They don't like it when another EV Driver has started using the Charging Station in the time they were traveling to the Charging Station.
+For the EV Driver it is useful to be able to reserve a specific Type of Connector, or, when the EV Driver has no preference, an unspecified EVSE at a Charging Station. So he knows for sure he can charge at the Charging Station when he arrives.</td></tr><tr><td>New text</td><td>This Functional Block describes the reservation functionality of OCPP. The reservation functionality enables an EV Driver to reserve an EVSE at a Charging Station until a certain time in order to ensure that this EVSE cannot be occupied by another user.
+OCPP allows to reserve a specific EVSE at a Charging Station or a specific connector type. The EV Driver can also reserve an unspecified EVSE, in which case the Charging Station will make sure that at least one EVSE remains available for the EV Driver.
+Only available EVSEs can be reserved, since a Charging Station cannot know in advance when an occupied EVSE will become available again. This makes it impossible to guarantee a reservation for an EVSE that is currently occupied.
+NOTE: A CSMS would still be able to support the reservation functionality for occupied EVSEs by delaying the sending of the reservation message to the Charging Station until the EVSE becomes available, but there is no guarantee that it is available in time.</td></tr></table>
+
+# 2.31. Page 213 - (2025-02) - H02 - Added missing requirements
+
+Added missing requirements explicitly specifying behaviour of Charging Station when a reservation is cancelled.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td colspan="3">[...]</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver asks the CSMS to cancel a reservation.
+2. To cancel a reservation, the CSMS sends CancelReservationRequest to the Charging Station.
+3. If the Charging Station has a reservation matching the reservationId in the request PDU, it returns the status Accepted.
+4. If a specific EVSE was reserved for this reservation, the Charging Station sends StatusNotificationRequest with the status Available or a NotifyEventRequest with AvailabilityState set to Available for all the Connectors of that EVSE.
+5. If needed, the Charging Station sends StatusNotificationRequest with the status Available or a NotifyEventRequest with AvailabilityState set to Available for all the Connectors of EVSEs that became available.
+6. The CSMS responds with StatusNotificationResponse or NotifyEventResponse to the Charging Station.
+7. The reservation is canceled.</td></tr><tr><td colspan="3">[...]</td></tr></table>
+
+Removed details from sequence diagram
+
+Old:
+
+
+
+Sequence Diagram: Cancel Reservation
+
+New:
+
+
+
+Sequence Diagram: Cancel Reservation
+
+New requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>H02.FR.03</td><td>H02.FR.02 AND
+If a specific EVSE was reserved for this reservation</td><td>The Charging Station SHALL allow charging again on this EVSE.</td></tr><tr><td>H02.FR.04</td><td>H02.FR.03</td><td>The Charging Station SHALL send a StatusNotificationRequest with status Available or a NotifyEventRequest with AvailabilityState set to Available to the CSMS for each connector, notifying the CSMS that all the connectors of this EVSE are available again for any EV Driver.</td></tr><tr><td>H02.FR.05</td><td>H02.FR.02 AND If no specific EVSE was reserved for this reservation</td><td>The Charging Station SHALL allow charging on all EVSE which were not reserved explicitly.</td></tr><tr><td>H02.FR.06</td><td>H01.FR.05 AND before cancelling the reservation the amount of EVSEs reserved was equal to the amount of reservations</td><td>The Charging Station SHALL send for all connectors of all EVSEs which were not reserved explicitly: - a NotifyEventRequest with component = "Connector", variable = "AvailabilityState", trigger = "Delta", actual/Value = "Available", OR - a StatusNotificationRequest with connectorStatus = Available.</td></tr></table>
+
+# 2.32. Page 214/215 - (2025-01) - Improved use case scenario descriptions and added S3
+
+The scenario descriptions have been updated to better explain the actual claiming of a reservation and have been clearly divided based on the configured TxStartPoint(s). In addition, A S3 has been added: 'Use an EVSE when Charging Station has a reservation for idToken, but connector status is Available.' This happens when reservation is for an unspecified EVSE and multiple EVSEs are available.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Use a reserved EVSE</td></tr><tr><td>2</td><td>ID</td><td>H03</td></tr><tr><td>3</td><td>Objective(s)</td><td>Use a reserved EVSE</td></tr><tr><td>4</td><td>Description</td><td>This use cases covers how a reserved EVSE can be used based on IdToken and GroupIdToken information.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td>S1</td><td>Scenario objective</td><td>Use an EVSE with connector status Reserved, that is reserved for this IdToken</td></tr><tr><td></td><td>Scenario description</td><td>TxStartPoint = "Authorized"; IdToken presented first
+1. The EV Driver presents an IdTokenType at the Charging Station that is the same as the reservation's IdTokenType.
+2. Charging Station matches IdTokenType with the reservation.
+3. Connector status becomes Available, since reservation has now been consumed.
+4. Charging Station optionally authorizes the IdTokenType via an InvalidateRequest.
+5. If authorization accepted, or authorization step was skipped:
+a. Charging Station starts a transaction as in E03 - Start Transaction - IdToken First.
+b. Connector status will become Occupied when cable is connected.</td></tr><tr><td></td><td>Scenario description #2</td><td>TxStartPoint = "EVConnected"; Cable plugged in first
+1. The EV Driver connects the cable.
+2. Charging Station starts a transaction, but EVSE connector status remains Reserved.
+3. The EV Driver presents an IdTokenType at the Charging Station that is the same as the reservation's IdTokenType
+4. Charging Station matches IdTokenType with the reservation
+5. Connector status becomes Occupied, since reservation has now been consumed
+6. Charging Station optionally authorizes the IdTokenType via an InvalidateRequest
+7. If authorization accepted, or authorization step was skipped:
+a. Charging Station starts a transaction as in E02 - Start Transaction - Cable Plugin First</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>EVSE has been reserved for IdToken and connector status is Reserved.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr></table>
+
+
+Figure 82. Sequence Diagram: Use a reserved EVSE with IdToken
+
+<table><tr><td>S2</td><td>Scenario objective</td><td>Use an EVSE with connector status Reserved, that is reserved for this GroupIdToken</td></tr><tr><td></td><td>Scenario description</td><td>TxStartPoint = "Authorized"; IdToken presented first
+1. The EV Driver presents an IdTokenType at the Charging Station that is not the same as the reservation's IdTokenType, but the reservation contains a groupIdToken.
+2. Charging Station authorizes the IdTokenType via anauthorizeRequest, Local Authorization List or Authorization Cache, and checks if the groupldToken of the IdTokenType matches with the reservation.
+3. If groupldTokens match:
+ a. Connector status becomes Available, since reservation has now been consumed.
+ b. Charging Station starts a transaction as in E03 - Start Transaction - IdToken First
+ c. Connector status will become Occupied when cable is connected</td></tr><tr><td></td><td>Scenario description #2</td><td>TxStartPoint = "EVConnected", Cable plugged in first
+1. The EV Driver connects the cable.
+2. Charging Station starts a transaction, but connector status remains Reserved.
+3. The EV Driver presents an IdTokenType at the Charging Station that is not the same as the reservation's IdTokenType, but the reservation contains a groupldToken.
+4. Charging Station authorizes the IdTokenType via anauthorizeRequest, Local Authorization List or Authorization Cache, and checks if the groupldToken of the IdTokenType matches with the reservation.
+5. If groupldTokens match:
+ a. Connector status becomes Occupied, since reservation has now been consumed.
+ b. Charging Station starts a transaction as in E02 - Start Transaction - Cable Plugin First</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>EVSE has been reserved for GroupldToken. EVSE connectorStatus = Reserved.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr></table>
+
+
+Figure 83. Sequence Diagram: Use a reserved EVSE with GroupId
+
+<table><tr><td>S3</td><td>Scenario objective</td><td>Use an EVSE when Charging Station has a reservation for idToken, but connector status is Available. This happens when reservation is for an unspecified EVSE and multiple EVSEs are available.</td></tr><tr><td></td><td>Scenario description</td><td>TxStartPoint = "Authorized"; IdToken presented first + Identical to scenario S1 above.</td></tr><tr><td></td><td>Scenario description #2</td><td>TxStartPoint = "EVConnected"; Cable plugged in first
+1. The EV Driver connects the cable
+2. Charging Station reports connector status as occupied
+3. Charging Station starts a transaction
+4. The EV Driver presents an IdTokenType at the Charging Station that is the same as the reservation's IdTokenType
+5. Charging Station matches IdTokenType with the reservation
+6. Charging Station optionally authorizes the IdTokenType via an InvalidateRequest
+7. If authorization accepted, or authorization step was skipped:
+a. Charging Station starts a transaction as in E02 - Start Transaction - Cable Plugin First</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Unspecified EVSE has been reserved for idToken. EVSE connector status is Available.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr></table>
+
+Added note:
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>It is RECOMMENDED to validate the Identifier with an InvalidateRequest after reception of ReserveNowRequest and before the start of the transaction.
+If an idToken is presented that does not match the reservation (and groupldTokens do not match either), then this idToken is not authorized to charge.
+If TxStartPoint = Authorized or PowerPathClosed then a transaction would not be started in this case.
+If TxStartPoint = EVConnected or ParkingBayOccupancy then a transaction would be started by cable plug-in or occupancy of parking bay, but charging would not start. Assuming a TxStopPoint of EVConnected the transaction would be ended at cable plug-out.</td></tr></table>
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old text</td><td>H03.FR.09</td><td>When an idToken or groupldToken is presented that matches a reservation</td><td>Charging Station SHALL consider the reservation to be used (consumed)</td><td></td></tr><tr><td>New text</td><td>H03.FR.09</td><td>When an idToken or groupldToken is presented that matches a reservation</td><td>Charging Station SHALL consider the reservation to be used (consumed)</td><td>The (group)IdToken can be presented locally at a card reader, but can also be part of a RequestStartTransaction.</td></tr></table>
+
+# 2.33. Page 226 - (2025-01) - I06.FR.02 Improved requirement text
+
+<table><tr><td>Old</td><td>I06.FR.02</td><td>I06.FR.01 AND
+When there is updated tariff information available.</td><td>The CSMS SHALL respond with a TransactionResponse message to the Charging Station, containing the updated tariff information in the PersonalMessage field.</td></tr><tr><td>New</td><td>I06.FR.02</td><td>I06.FR.01 AND
+When there is updated tariff information available.</td><td>The CSMS SHALL respond with a TransactionResponse message to the Charging Station, containing the updated tariff information in the updatedPersonalMessage field.</td></tr></table>
+
+# 2.34. Page 231 - (2025-01) - Updated section Multiple Locations/Phases
+
+The section now specifies the 'relevant' configuration variables that apply.
+
+<table><tr><td>Old</td><td>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.</td></tr><tr><td>New</td><td>When a Charging Station has measurands configured in SampledDataTxStarted/Updated/EndedMeasurands and/or AlignedDataMeasurands / AlignedDataTxEndedMeasurands , that can be measured on multiple locations or phases, then all possible locations and/or phases SHALL be reported.</td></tr></table>
+
+# 2.35. Page 243 - (2025-01) - Improved section on external Smart Charging Control Signals
+
+To be inline with the EMS scenario additions to OCPP 2.1, this section also has been improved for OCPP 2.0.1.
+
+Old text:
+
+The OCPP protocol is originally developed for communication between a CSMS and one or more Charging Stations. As described in the above, this means that a Charging Station Operator (CSO) CSMS controls a Charging Station and, based on the charging limits of both the EV and the Charging Station, the CSO determines how fast the EV is charged. However, in some situations / applications of OCPP enabled Charging Stations, these are not the only 2 factors that determine the charging speed. Other inputs that determine charging speed could be DSO signals (e.g. via IEC 61850 [IEC61850-7-420], IEC 60870 [IEC60870-5-104], DNP3 [DNP3] or OpenADR [OPENADR]) or signals from a Building / Home Energy Management System. Although these signals are out of scope for OCPP, it seems clear from an OCPP perspective that the CSMS is to be informed of changes in charging by external signals. However, this also leads to a number of questions, such as how to deal with conflicting signals. The figure below presents an example setup with an Energy Management System, where the external signals are visualized both in a setup with direct communication to the Charging Station as well as a multiple Charging Station setup using a Local Controller:
+
+
+Figure 97. External Smart Charging
+
+New text:
+
+The OCPP protocol is developed for communication between a CSMS and one or more Charging Stations. As described in the above, this means that a CSMS of a Charging Station Operator (CSO) controls a Charging Station and, based on the charging limits of both the EV and the Charging Station, the CSO controls how fast the EV is charged. In some situations there are other factors that might control charging power: A DSO can send signals to change charging power (e.g. via IEC 61850 [IEC61850-7-420], IEC 60870 [IEC60870-5-104], DNP3 [DNP3] or OpenADR [OPENADR]), or a Home Energy Management System or a smart meter may be in place to limit charging power.
+
+An external actor can connect to a Charging Station with any protocol that is supported by the Charging Station for this purpose, like Modbus, EEBUS, and even OCPP. This control signal can be a single limit value or a schedule. In both cases Charging Station will represent the limit internally as a charging profile of purpose ChargingStationExternalConstraints.
+
+A CSMS may need to be informed of changes in charging rate as a result of external signals. OCPP provides a NotifyChargingLimitRequest message to report such changes.
+
+
+EMS control directly to Charging Stations
+
+# 2.36. Page 248 - (2025-01) - 3.7 Avoiding Phase Conflicts
+
+The following paragraph about Avoiding Phase Conflicts has been added:
+
+In the situation where a ChargingStationMaxProfile or a ChargingStationExternalConstraints define a value for numberPhases or phaseToUse, then a possible conflict might arise if such values are also specified in a TxDefaultProfile or TxProfile. The following rules apply in that case:
+
+# numberPhases
+
+The lowest value for a schedule period of all applicable profiles is used for the composite schedule period. If ChargingStationMaxProfile has numberPhases = 3 and TxProfile has numberPhases = 1, then the value 1 is used. The same applies to the reverse situation.
+
+# phaseToUse
+
+When there is a conflicting value of phaseToUse between the schedule periods of applicable profiles, then there is no way to create a composite schedule period. For example, a CSMS should not submit a charging profile of purpose
+
+ChargingStationMaxProfile for phaseToUse = 1 and then a TxProfile for phaseToUse = 3, because the charging station will not know which value has preference. Therefore, a SetChargingProfileRequest that causes such a conflict will have to be rejected.
+
+When a relative TxProfile is being used and different phases occur in various schedule periods, then it may become difficult to detect if and where such a phase conflict occurs. A charging station should only accept a
+
+SetChargingProfileRequest when it can be certain, that there is a no risk of a phase conflict. This means, that when the charging station is not able to verify that no phase conflict occurs in any schedule period (which can happen when the TxProfile is received for a transaction, but charging has not yet started, so that start time of the first schedule period is not known), that it cannot accept a charging profile if any of the schedule periods contains a value for phaseToUse that differs from the value used in the ChargingStationMaxProfile or ChargingStationExternalConstraints.
+
+NOTE
+
+A value of phaseToUse may only be used when numberOfPhases = 1.
+
+# 2.37. Page 275 - (2025-06) - Updated remark of K11
+
+Added sentence to Remarks a new charging profile for an update of external limit can use the same charging profile id.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>...</td><td>...</td><td>...</td></tr><tr><td>8</td><td>Remarks</td><td>[...]If the external limit is represented by an Absolute or RelativeChargingStationExternalConstraints charging profile, then every update of the external limit requires (K11.FR.06) that the existingChargingStationExternalConstraints charging profile is replaced by a new one. This one can use the samechargingProfile.id, however.</td></tr></table>
+
+# 2.38. Page 251 - (2025-06) - Updated note of K01.FR.05
+
+Note suggested that ChargingStationExternalConstraints cannot be replaced at all. Updated note to clarify that a ChargingStationExternalConstraints cannot be replaced by CSMS.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>K01.FR.05</td><td>When a SetChargingProfileRequest with an already known ChargingProfile.id is received AND the existing ChargingProfile does NOT have chargingProfilePurpose = ChargingStationExternalConstraints</td><td>The Charging Station SHALL replace the existing ChargingProfile with the one specified.</td><td>ChargingStationExternalConstraints profile cannot be replaced.</td></tr><tr><td>New</td><td>K01.FR.05</td><td>When a SetChargingProfileRequest with an already known ChargingProfile.id is received AND the existing ChargingProfile does NOT have chargingProfilePurpose = ChargingStationExternalConstraints</td><td>The Charging Station SHALL replace the existing ChargingProfile with the one specified.</td><td>ChargingStationExternalConstraints profile cannot be replaced by CSMS.</td></tr></table>
+
+# 2.39. Page 251 - (2025-06) - Add cross-references to K01.FR.06 and K01.FR.39
+
+Requirement K01.FR.06 and K01.FR.39 are similar, but located far apart in the table. It is convenient to add a cross-reference between both.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>K01.FR.06</td><td>When chargingProfilePurpose is NOT TxProfile</td><td>The CSMS SHALL NOT send a ChargingProfile with a stackLevel - chargingProfilePurpose - evsId combination that already exists in another ChargingProfile (with different id) on the Charging Station and has an overlapping validity period.</td><td>This is to ensure that no two charging profiles with same stack level and purpose can be valid at the same time.</td></tr><tr><td>New</td><td>K01.FR.06</td><td>When chargingProfilePurpose is NOT TxProfile</td><td>The CSMS SHALL NOT send a ChargingProfile with a stackLevel - chargingProfilePurpose - evseld combination that already exists in another ChargingProfile (with different id) on the Charging Station and has an overlapping validity period.</td><td>This is to ensure that no two charging profiles with same stack level and purpose can be valid at the same time.
+(See also K01.FR.39)</td></tr><tr><td>Old</td><td>K01.FR.39</td><td>When chargingProfilePurpose is TxProfile</td><td>The CSMS SHALL NOT send a ChargingProfile with a stackLevel - transactionId combination that already exists in another ChargingProfile (with different id) with purpose TxProfile.</td><td>This is to ensure that no two charging profiles with same stack level and purpose can be valid at the same time.</td></tr><tr><td>New</td><td>K01.FR.39</td><td>When chargingProfilePurpose is TxProfile</td><td>The CSMS SHALL NOT send a ChargingProfile with a stackLevel - transactionId combination that already exists in another ChargingProfile (with different id) with purpose TxProfile.</td><td>This is to ensure that no two charging profiles with same stack level and purpose can be valid at the same time.
+(See also K01.FR.06)</td></tr></table>
+
+# 2.40. Page 254 - (2025-06) - K01.FR.50 requirement is a SHALL
+
+Physics determines how to convert power to current. This cannot be a "should" requirement, but is a SHALL.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>K01.FR.49</td><td>When a SetChargingProfileRequest without a value for numberPhases is received AND the EVSE is of type AC</td><td>The Charging Station SHALL assume numberPhases = 3 as a default value.</td><td></td></tr><tr><td>New</td><td>K01.FR.49</td><td>When a SetChargingProfileRequest without a value for numberPhases is received AND the EVSE is of type AC</td><td>The Charging Station SHALL assume numberPhases = 3 as a default value.</td><td>Regions with a single phase network should always provide numberPhases = 1, otherwise 3 phases will be assumed.</td></tr><tr><td>Old</td><td>K01.FR.50</td><td>When a SetChargingProfileRequest with a chargingRateUnit = W is received AND The ChargingSchedule is used for AC charging</td><td>The Charging Station SHOULD calculate the phase current limit via: Current per phase = Power / (Line Voltage * Number of Phases).</td><td>The "Line Voltage" used in the calculation is not the measured voltage, but the set voltage for the area (for example, 230 or 110 V). The "Number of Phases" is the numberPhases from the ChargingSchedulePeriod. It is usually more convenient to use chargingRateUnit = A for AC charging.</td></tr><tr><td>New</td><td>K01.FR.50</td><td>When a SetChargingProfileRequest with a chargingRateUnit = W is received AND The charging profile is used for AC charging</td><td>The Charging Station SHALL calculate the phase current limit via: Current per phase = limit / (Line Voltage * numberPhases), in which limit and numberPhases are the values from the ChargingSchedulePeriod.</td><td>The "Line Voltage" used in the calculation is not the measured voltage, but the set voltage for the area (for example, 230 or 110 V). . The limit and numberPhases are the values from the ChargingSchedulePeriod. When numberPhases is not specified, a value of 3 is assumed (see K01.FR.49). It is usually more convenient to use chargingRateUnit = A for AC charging, since in that case the limit does not change depending on number of phases in use.</td></tr></table>
+
+# 2.41. Page 257 - (2025-06) - K02 Updated remark of use case about merging profiles
+
+The description of merging profiles in the remark was not complete. It has been updated to refer to the appropriate requirement.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>...</td><td>...</td><td>...</td></tr><tr><td>8</td><td>Remark(s)</td><td>[...]The final schedule constraints that apply to a transaction are determined by merging the profiles with purposes ChargingStationMaxProfile with the profile TxProfile or TxDefaultProfile in case no profile of purpose TxProfile is provided. Zero or more of the following ChargingProfile purposes MAY have been previously received from the CSMS: ChargingStationMaxProfile or TxDefaultProfile, as described in requirement SC.01 in Chapter 4. Smart Charging Signals to a Charging Station from Multiple Actors. [...]</td></tr></table>
+
+# 2.42. Page 282 - (2025-01) - K15 - ISO 15118-2 Charging with load leveling - Requirements
+
+Note: This erratum has been superseded by erratum: Page 282 - (2025-09) - K15.FR.20 is not part of OCPP 2.0.1 [1061]
+
+Added recommendation for timestamp when offline:
+
+New/Updatedrequirements
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Changed</td><td>K15.FR.01</td><td>When the Charging Station receives charging needs from the EV</td><td>The Charging Station SHALL send a NotifyEVChargingNeedsRequest to the CSMS.</td><td>See also K15.FR.20</td></tr><tr><td>New</td><td>K15.FR.20</td><td>K15.FR.01 AND Charging Station is offline</td><td>Charging Station SHOULD add timestamp to the NotifyEVChargingNeedsRequest with the time when charging needs were received from EV</td><td>This will tell CSMS how old this data is, if it was not immediately sent because of an offline period.</td></tr><tr><td>New</td><td>K15.FR.21</td><td>K15.FR.10</td><td>Charging Station SHOULD set selectedScheduleTupleId to the Id of the chargingSchedule that EV selected from the provided ChargingProfile(s).</td><td></td></tr></table>
+
+# 2.43. Page 282 - (2025-09) - K15.FR.20 is not part of OCPP 2.0.1 [1061]
+
+Note: This erratum supersedes erratum: Page 282 - (2025-01) - K15 - ISO 15118-2 Charging with load leveling - Requirements
+
+The above-mentioned requirement about K15.FR.20 as a new requirement in OCPP 2.0.1 is wrong. K15.FR.20 does not apply to OCPP 2.0.1, because the timestamp field was only added in OCPP 2.1.
+
+Delete requirement
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Delete</td><td>K15.FR.20</td><td>K15.FR.01 AND Charging Station is offline</td><td>Charging Station SHOULD add timestamp to the NotifyEVChargingNeedsRequest with the time when charging needs were received from EV</td><td>This will tell CSMS how old this data is, if it was not immediately sent because of an offline period.</td></tr></table>
+
+# 2.44. Page 286 - (2025-01) - K16 - Renegotiation initiated by CSMS - Requirements
+
+The following requirement was added:
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>NOTE</td></tr><tr><td>K16.FR.14</td><td>K16.FR.05</td><td>Charging Station SHOULD set selectedScheduleTupleId to the Id of the chargingSchedule that EV selected from the provided ChargingProfileType(s).</td><td></td></tr></table>
+
+# 2.45. Page 284 - (2025-09) - K15 Added rule for composite schedules in case of multiple charging schedules [1002]
+
+In the theoretical situation that 2 TxProfiles are submitted with different stack levels and multiple charging schedules (which can only be the case for an ISO 15118 session) and, because of different durations of these schedules, parts of each of these schedules will be valid at one point or another, then how is the composite schedule calculated? It is not $3 \times 3$ composite schedules (all possible combinations), but only 3 composite schedules, because schedule #1 is always combined with schedule #1, #2 with #2 and #3 with #3. Other chargingProfilePurposes, like ChargingStationMaxProfile need also to be taken into account when calculating the composite schedule.
+
+A new requirement is added to define this behavior.
+
+# 2.45.1. K15 - ISO 15118-2
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K15.FR.22</td><td>When calculating CompositeSchedule(s) to create a SAScheduleList for ISO 15118-2 to send to EV AND multiple ChargingProfileTypes of chargingProfilePurpose = TxProfile with different stackLevels are valid AND some or all these ChargingProfileTypes have more than one chargingSchedule</td><td>Charging Station SHALL create up to three CompositeSchedules as defined in K08.FR.04, by combining the first chargingSchedule with the first chargingSchedule of other stack levels, the second with second (if existing), the third with the third (if existing), based on their order in the ChargingProfileTypes.</td><td>This is about a corner case when multiple TxProfiles with different stack levels and multiple charging schedules have been sent to the Charging Station.</td></tr></table>
+
+# 2.46. Page 259/260 - (2025-01) - K03 - Updated use case description and sequence diagram
+
+The use case description and sequence diagram have been updated to provide more information on how local load-balancing can be performed. (Requirements for K03 have not changed).
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Local Smart Charging</td></tr><tr><td>2</td><td>ID</td><td>K03</td></tr><tr><td>3</td><td>Objective(s)</td><td>To illustrate the process of local load-balancing by a Local Cluster.</td></tr><tr><td>4</td><td>Description</td><td>This use case is an example of how local load-balancing can be performed. It does not imply that other approaches would not be correct. The process has been simplified for clarity and should not be regarded as prescriptive.A Local Controller is configured with a value for maximum current for the total cluster by CSMS via a charging profile of type ChargingStationMaxProfile to the Local Controller, or an EMS may have set a ChargingStationExternalConstraints charging profile.The Local Controller divides the maximum current among the active transactions. Whenever a transaction starts or finishes, the Local Controller will update the charging profiles of the remaining transactions to divide the maximum current equally.For simplicity's sake, this use case does not differentiate on departure time or state of charge of vehicles, nor does it take the actual energy consumption of vehicles into account.</td></tr><tr><td></td><td>Actors</td><td>Charging Station (CS01, CS02), Local Controller (LC), CSMS</td></tr><tr><td></td><td>Scenario description</td><td>Assume no transactions are active in the local cluster and the maximum current for the local cluster has been configured to be 100 A. The charging stations all have a TxDefaultProfile that allows a current of only 6 A, so that vehicles cannot immediately start charging at full power before the LC had the chance to set a charging profile.1. A transaction starts on charging station CS01. It sends a TransactionEventRequest(Started) to LC.2. LC is configured to do local load-balancing (i.e. its SmartChargingCtrl.Enabled = true), so it registers the transaction id TX1 of the transaction that has been started on CS01, before forwarding the message on the websocket for CS01 towards CSMS.3. LC sends a SetChargingProfileRequest to CS01 with chargingProfilePurpose = TxProfile, chargingProfileKind = Relative, transactionId = TX1 and a chargingSchedule with a chargingRateUnit = A that contains one chargingSchedulePeriod with a limit of 94 A, so that the entire quota is available to this transaction minus the TxDefaultProfile amount for new transactions.4. Another transaction starts on charging station CS02. It sends a TransactionEventRequest(Started) to LC.5. LC registers the new transaction id TX2 and forwards the message on the websocket for CS02 to CSMS.6. LC divides the available quota by allowing each transaction a maximum of 47 A.7. LC sends a SetChargingProfile message to CS01 that updates the existing TxProfile and sets the limit to 47 A.8. LC sends new SetChargingProfile to CS02 with chargingProfilePurpose = TxProfile, chargingProfileKind = Relative, transactionId = TX2 and a chargingSchedule with a chargingRateUnit = A that contains one chargingSchedulePeriod with a limit of 47 A.9. The transaction of CS01 finishes. It sends a TransactionEventRequest(Ended) to LC.10. LC registers that transaction TX1 on CS01 has finished and forwards the message on the websocket for CS01 to CSMS.11. LC now allows the maximum to TX2. It sends a SetChargingProfile message to CS02 that updates the existing TxProfile and sets the limit to 94 A. (Note, that the TxProfile for TX1 on CS01 has automatically ceased to exist upon termination of the transaction.)</td></tr><tr><td>5</td><td>Prerequisites</td><td>The LC has been configured with a fixed maximum current level.The SmartChargingCtrl component of Local Controller has been Enabled, which will trigger the Local Controller to read and interpret TransactionEventRequest messages from connected Charging Stations.</td></tr><tr><td>6</td><td>Post conditions</td><td></td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>As described in Part 1, a Local Controller replicates all web sockets from Charging Stations in the cluster towards CSMS, and forwards messages from Charging Station to CSMS on the appropriate web socket (and vice versa). This allows the Local Controller to read messages, such as a TransactionEventRequest message, from the Charging Station.The Local Controller for local smart charging can be implemented in different ways, for example: as a separate physical component or as part of a "master" Charging Station controlling a number of other Charging Stations. The Local Controller MAY or MAY NOT have any EVSEs of its own.The limits on Charging Stations in a Local Smart Charging group can either be pre-configured in the Local Controller in one way or another, or they can be set by the CSMS. The Local Controller contains the logic to distribute this capacity among the connected EVSEs by adjusting their limits as needed.</td></tr></table>
+
+
+Local Controller performing local load-balancing
+
+# 2.47. Page 274/275/276/277 - (2025-01) - K11/K12 - Updated use case descriptions and sequence diagrams
+
+The use case descriptions and sequence diagrams have been updated to describe the more likely scenario of a smart meter or EMS as external actor.
+
+# K11 - Set / Update External Charging Limit With Ongoing Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set / Update External Charging Limit With Ongoing Transaction</td></tr><tr><td>2</td><td>ID</td><td>K11</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS of a charging schedule or charging limit imposed by an External Control System on the Charging Station with ongoing transaction(s).</td></tr><tr><td>4</td><td>Description</td><td>An External Control System sends a charging limit/schedule to a Charging Station. This limit is sent to the CSMS. The External Control System can be a DSO, but also a smart meter or a home energy management system. The interface between External Control System and Charging Station is not specified. It can be any protocol that is supported by Charging Station for this purpose, even OCPP.</td></tr><tr><td></td><td>Actors</td><td>External Control System, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. External control system sends charging limit/schedule to Charging Station.
+2. Optional: Charging Station calculates new charging schedule.
+3. Charging Station adjusts the charging speed of the ongoing transaction(s).
+4. If the charging limit changed by more than: LimitChangeSignificance, the Charging Station sends a NotifyChargingLimitRequest message to CSMS with optionally the set charging limit/schedule.
+5. The CSMS responds with NotifyChargingLimitResponse to the Charging Station.
+6. If the charging rate changes by more than: LimitChangeSignificance, the Charging Station sends a TransactionEventRequest message to inform the CSMS.
+7. The CSMS responds with TransactionEventResponse to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station is not in error state.
+The external system can set/clear a charging limit/schedule on the Charging Station via a direct connection to the Charging Station.</td></tr><tr><td colspan="3">...</td></tr></table>
+
+
+Sequence diagram of the use case "Setting / Updating External Charging Limit with Ongoing Transaction"
+
+# K12 - Set / Update External Charging Limit Without Ongoing Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set / Update External Charging Limit Without Ongoing Transaction</td></tr><tr><td>2</td><td>ID</td><td>K12</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS of a charging schedule or charging limit imposed by an external system on the Charging Station for new transactions or on the grid connection.</td></tr><tr><td>4</td><td>Description</td><td>To inform the CSMS of a charging schedule or charging limit imposed by an external system on the Charging Station for new transactions or on the grid connection. The External Control System can be a DSO, but also a smart meter or a home energy management system. The interface between External Control System and Charging Station is not specified. It can be any protocol that is supported by Charging Station for this purpose, even OCPP.</td></tr><tr><td></td><td>Actors</td><td>External Control System, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. External Control System sends a charging limit to Charging Station (not during a transaction).2. Optional: Charging Station calculates new charging schedule.3. Charging Station adjusts the charging speed.4. If the charging limit changed by more than: LimitChangeSignificance, the Charging Station sends a NotifyChargingLimitRequest message to CSMS with optionally the set charging limit/schedule.5. The CSMS responds with a NotifyChargingLimitResponse to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station is not in error state.The external system can set/clear a charging limit/schedule on the Charging Station via a direct connection to the Charging Station.</td></tr><tr><td colspan="3">...</td></tr></table>
+
+
+
+Sequence diagram of the use case "Set / Update External Charging Limit Without Ongoing Transaction"
+
+# 2.48. Page 278/279 - (2025-01) - K13 - Updated requirement preconditions
+
+Moved precondition "transaction is ongoing" from K13.FR.01 to K13.FR.03.
+
+Changed K13 requirements:
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirements</td></tr><tr><td>Old text</td><td>K13.FR.01</td><td>A transaction is ongoing AND External charging limit is released/removed</td><td>The Charging Station SHALL NOT limit charging anymore based on the previously received limit.</td></tr><tr><td>New text</td><td>K13.FR.01</td><td>External charging limit is released/removed</td><td>The Charging Station SHALL NOT limit charging anymore based on the previously received limit.</td></tr><tr><td>Old text</td><td>K13.FR.03</td><td>K13.FR.01 AND Charging rate changed by more than: LimitChangeSignificance</td><td>The Charging Station SHALL send a TransactionEventRequest message to the CSMS with trigger = ChargingRateChanged.</td></tr><tr><td>New text</td><td>K13.FR.03</td><td>K13.FR.01 AND A transaction is ongoing AND Charging rate changed by more than: LimitChangeSignificance</td><td>The Charging Station SHALL send a TransactionRequest message to the CSMS with trigger = ChargingRateChanged.</td></tr></table>
+
+# 2.49. Page 279 - (2025-01) - K14 - Updated use case scenario description
+
+Improved scenario step description 5 and 7.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Handle external charging limit with a local controller</td></tr><tr><td>2</td><td>ID</td><td>K14</td></tr><tr><td>3</td><td>Objective(s)</td><td>To adjust the charging limits according to the External Control System requirements.</td></tr><tr><td>4</td><td>Description</td><td>An external control system sends a charging limit to the Local Controller. The Local Controller notifies the CSMS, calculates the new charging schedules and sends a SetChargingProfileRequest messages to all Charging Stations for which the charging profile has changed.</td></tr><tr><td></td><td>Actors</td><td>External control system, Local Controller, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. External control system sends a charging limit/schedule to Local Controller.
+2. Local Controller sends a NotifyChargingLimitRequest message to the CSMS.
+3. Local Controller calculates new Charging Profiles for all connected Charging Stations.
+4. Local Controller sends a SetChargingProfileRequest message to all Charging Stations for which the charging profile has changed.
+5. External control releases a charging limit/schedule to Local Controller.
+6. Local Controller sends a ClearedChargingLimitRequest message to the CSMS.
+7. Local Controller clears Charging Profiles for all connected Charging Stations.
+8. Local Controller sends a ClearChargingProfileRequest messages to all affected Charging Stations.</td></tr><tr><td colspan="3">...</td></tr></table>
+
+# 2.50. Page 284 - (2025-09) - K16 use case description update
+
+The use case description refers to SetChargingProfile in step 7, but that is too restricting. It is the composite schedule that is provided to EV.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>...</td><td>...</td><td>...</td></tr><tr><td></td><td>Scenario description</td><td>1 CSMS sends a SetChargingProfileRequest to the Charging Station.
+2 Charging Station responds with a SetChargingProfileResponse to the CSMS.
+3 When EV sends the next CurrentDemandReq (for DC) or ChargingStatusReq (for AC), the Charging Station will respond with evseNotification = ReNegotiation.
+4 EV sends a PowerDeliveryReq with chargeProgress = ReNegotiate to confirm this.
+5 Charging Station responds with a PowerDeliveryRes.
+6 EV sends a ChargeParameterDiscoveryReq.
+7 Charging Station responds with a ChargeParameterDiscoveryRes with an SAScheduleList that contains the composite schedule(s) for the EVSE ChargingSchedule data from the SetChargingProfileRequest.
+8 EV sends a PowerDeliveryReq with chargeProgress = Start (with an optional charging profile) to confirm this.
+9 Charging Station responds with PowerDeliveryRes and, if charging was suspended at start of the renegotiation, will resume power delivery.
+10 If EV provided a charging profile in the previous step, then Charging Station will send a NotifyEVChargingScheduleRequest to the CSMS.</td></tr></table>
+
+# 2.50.1. Page 285
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirements</td><td>NOTE</td></tr><tr><td>Old</td><td>K16.FR.02</td><td>K16.FR.01</td><td>Charging Station SHALL initiate schedule renegotiation with EV.</td><td>In ISO 15118 this is done by replying with EVSENotification=ReNegotiation to a CurrentDemandReq (for DC) or ChargingStatusReq (for AC) message.</td></tr><tr><td>New</td><td>K16.FR.02</td><td>When the composite schedule for the EVSE changes</td><td>Charging Station SHALL initiate schedule renegotiation with EV.</td><td>This can be caused by a Set/ClearChargingProfileRequest or a change in ChargingStationExternalConstraints/Local Generation charging profiles. In ISO 15118 this is done by replying with EVSENotification=ReNegotiation to a CurrentDemandReq (for DC) or ChargingStatusReq (for AC) message.</td></tr><tr><td>Old</td><td>K16.FR.03</td><td>K16.FR.02</td><td>Charging Station SHALL provide the ChargingSchedule data to the EV.</td><td>In ISO 15118 this is done in the ChargeParameterDiscoverRes message.</td></tr><tr><td>New</td><td>K16.FR.03</td><td>K16.FR.02</td><td>Charging Station SHALL provide the composite schedule(s) ChargingSchedule data to the EV.</td><td>In ISO 15118 this is done in the ChargeParameterDiscoverRes message.</td></tr></table>
+
+# 2.51. Page 292 - (2025-01) - Use case L01 - Added clarification to step 3 about when to start downloading the firmware
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Secure Firmware Update</td></tr><tr><td>2</td><td>ID</td><td>L01</td></tr><tr><td>3</td><td>Objective(s)</td><td>Download and install a Secure firmware update.</td></tr><tr><td>4</td><td>Description</td><td>Illustrate how a Charging Station processes a Secure firmware update.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends an UpdateFirmwareRequest message that contains the location of the firmware, the time after which it should be retrieved, and information on how many times the Charging Station should retry downloading the firmware.
+2. The Charging Station verifies the validity of the certificate against the Manufacturer root certificate.
+3. If the certificate is valid AND the retrieveDateTime has passed, the Charging Station starts downloading the firmware, and sends a FirmwareStatusNotificationRequest with status Downloading.
+If the certificate is not valid or could not be verified, the Charging Station aborts the firmware update process and sends a UpdateFirmwareResponse with status InvalidCertificate and a SecurityEventNotificationRequest with the security event InvalidFirmwareSigningCertificate (See part 2 appendices for the full list of security events).
+...</td></tr></table>
+
+# 2.52. Page 306 - (2025-01) - M. ISO 15118 Certificate Management
+
+The functional block ISO 15118 Certificate Management is renamed to Certificate Management since this also contains certificate management of non-ISO 15118 related certificates.
+
+# 2.53. Page 308 - (2025-01) - Update introduction sequence diagram ISO 15118
+
+Not all ISO 15118 message sequences were complete, so the sequence diagram has been updated to show a more complete version of the message flow.
+
+
+Figure 122. Sequence with Authorization and Scheduling with ISO 15118-2
+
+# 2.54. Page 330 - (2025-01) - N03 Set Monitoring Base: Improved text of Remark
+
+<table><tr><td>Old</td><td>8</td><td>Remark(s)</td><td>Upon receipt of a SetMonitoringBaseRequest for HardWiredOnly or FactoryDefault the Charging Station will discard of any previously configured custom monitors and will activate the monitoring settings that are related to given MonitoringBase.For a MonitoringBase = All the Charging Station will activate all pre-configured monitors and leave previously configured custom monitors intact. This includes the custom monitors that were created when changing an existing pre-configured monitor.When the set of pre-configured monitors for All and FactoryDefault is the same, then the difference between the two is, that with FactoryDefault all custom monitors are deleted before the factory default pre-configured monitors are restored.</td></tr><tr><td>New</td><td>8</td><td>Remark(s)</td><td>Upon receipt of a SetMonitoringBaseRequest for:monitoringBase = HardWiredOnly: the Charging Station will deactivate all pre-configured monitors and remove any previously configured custom monitors. Only the HardWiredMonitor monitors remain-monitoringBase = FactoryDefault: the Charging Station will (re)activate all PreconfiguredMonitor monitors and remove all custom monitors-monitoringBase = All: the Charging Station will activate all pre-configured monitors and leave previously configured CustomMonitor monitors intact. This includes the custom monitors that were created when changing an existing pre-configured monitor.</td></tr></table>
+
+# 2.55. Page 331 - (2025-01) - N03.FR.04: text improvement
+
+Improved requirement text for N03.FR.04.
+
+<table><tr><td>Old</td><td>N03.FR.04</td><td>N03.FR.01 AND
+When the Charging Station received a setMonitoringBaseRequest with monitoringBase FactoryDefault</td><td>Then the Charging Station SHALL delete all custom monitors (including overruled pre-configured monitors) and activate the default monitoring settings as recommended by the manufacturer.</td></tr><tr><td>New</td><td>N03.FR.04</td><td>N03.FR.01 AND
+When the Charging Station received a setMonitoringBaseRequest with monitoringBase FactoryDefault</td><td>Then the Charging Station SHALL delete all custom monitors (including overruled pre-configured monitors) and activate the pre-configured monitors of the Charging Station.</td></tr></table>
+
+# Page 434 - MonitoringBaseEnumType description update
+
+The description has been updated to be better aligned with the use case.
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>All</td><td>Activate all pre-configured monitors while leaving custom monitors intact, including those that overrule a pre-configured monitor.</td></tr><tr><td>FactoryDefault</td><td>(Re)activate the default monitoring settings has recommended by the manufacturer. This is a subset of all pre-configured monitors of Charging Station and remove all custom monitors.</td></tr><tr><td>HardWiredOnly</td><td>Removes all custom monitors and disables all pre-configured monitors.</td></tr></table>
+
+# 2.56. Page 350 - (2025-02) - 001 - Added missing requirements
+
+Added missing requirements explicitly specifying behaviour of Charging Station it contains one or more displays.
+
+New requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td colspan="3">Multiple Display support</td></tr><tr><td>001.FR.20</td><td>When Charging Station has multiple displays AND Charging Station receives a [setdisplaymessagerequest] without a display element in its MessageInfoType</td><td>Charging Station SHOULD use the message for the main display(s)</td></tr><tr><td>001.FR.21</td><td>When receiving a GetBaseReportRequest AND Charging Station has one or more displays</td><td>Charging Station SHOULD include in the report a Display component for every display it contains.</td></tr><tr><td>001.FR.22</td><td>When Charging Station receives a [setdisplaymessagerequest] with Display element referencing an unknown Display in its MessageInfoType</td><td>Charging Station SHOULD respond with a [setdisplaymessageresponse] with status = Rejected.</td></tr><tr><td>001.FR.23</td><td>When Charging Station receives a [setdisplaymessagerequest] with Display element referencing a known Display in its MessageInfoType</td><td>Charging Station SHOULD use the message only for the specified display.</td></tr></table>
+
+# 2.57. Page 446 - (2025-01) - ActiveNetworkProfile is incorrectly marked as optional
+
+The referenced variable OCPPCommCtrlActiveNetworkProfile is incorrectly marked as optional. As the description states this variable needs to be implemented when the Charging Station supports the NetworkConnectionProfile use cases B09/B10. These use cases are an integral part of the Core of OCPP. In addition, all other NetworkConnectionProfile related referenced variables are already required; OCPPCommCtrl.NetworkConfigurationPriority and OCPPCommCtrl.NetworkProfileConnectionAttempts. Therefore, OCPPCommCtrl.ActiveNetworkProfile should also be marked as required.
+
+ActiveNetworkProfile
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ActiveNetworkProfile</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">This variable indicates the NetworkConnectionProfile configuration slot the Charging Station currently uses for its connection with the CSMS.</td></tr></table>
+
+# 2.58. Page 327 - (2025-09) - N01.FR.12 - Improved definition
+
+Updated requirement definition to clarify the AcceptedCanceled status.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>Old</td><td>N01.FR.12</td><td>When a Charging Station is assembling or uploading the log file AND the Charging Station receives a new GetLogRequest</td><td>The Charging Station SHOULD cancel the ongoing log file upload AND respond with status AcceptedCanceled.</td></tr><tr><td>New</td><td>N01.FR.12</td><td>When a Charging Station is assembling or uploading the log file AND the Charging Station receives a new GetLogRequest</td><td>The Charging Station SHOULD cancel the ongoing log file upload AND respond GetLogResponse with status AcceptedCanceled.</td></tr></table>
+
+# 2.59. Page 328 - (2025-09) - N02: changed empty to absent.
+
+A number of requirements previously stated "empty" when they should have indicated "absent." For example, the phrases referring to monitoringCriteria and componentVariables being "empty" are incorrect. These arrays cannot be empty; they must be absent
+
+# 2.60. Page 453 - (2025-01) - References to monitorValue changed to value [354]
+
+The specification in N Diagnostics consistently refers to a variable monitorValue, but this variable is called value in JSON schemas.
+
+All occurrences of monitorValue in N Diagnostics have been changed to value.
+
+# 2.61. Page 454 - (2025-01) - N04.FR.06 Improved limit definition of thresholds [353]
+
+The requirement has been defined more exact, because limits for upper and lower differ slightly.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>N04.FR.06</td><td>When the Charging Station receives a SetVariableMonitoringRequest with monitor type UpperThreshold or LowerThreshold AND the monitorValue is lower or higher than the range of the given Variable</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: Rejected.</td><td>More information can be provided in the optional statusInfo element.</td></tr><tr><td>New</td><td>N04.FR.06</td><td>When the Charging Station receives a SetVariableMonitoringRequest with (monitor type = UpperThreshold AND monitorValue < minLimit OR monitorValue > maxLimit) OR (monitor type = LowerThreshold AND monitorValue < minLimit OR monitorValue > maxLimit)</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: Rejected.</td><td>minLimit and maxLimit refer to the [cmn_variablecharacteristictype] for the [cmn_variabletype]. Be aware that setting a UpperThreshold to the maxLimit or setting a LowerThreshold to the minLimit will result in a monitor that will never trigger. More information on the reason of rejection can be provided in the optional statusInfo element.</td></tr></table>
+
+# 2.62. Page 456 - (2025-02) - New configuration variable to allow TLS wildcard certificates
+
+New configuration key
+
+# AllowCSMSTLSWildcards
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>名字</td><td colspan="2">AllowCSMSTLSWildcards</td></tr><tr><td>attributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>characteristics</td><td>dataType</td><td>boolean</td></tr></table>
+
+<table><tr><td>Description</td><td>This variable allows a Charging Station to support non-compliant OCPP behavior and connect to a CSMS that uses a wildcard TLS server certificate for the OCPP connection.
+If this variable is present it SHALL be ReadWrite. If this variable is not implemented or has value false, the OCPP-compliant behavior is that a Charging Station rejects a connection from a CSMS that presents a wildcard certificate.
+It is highly RECOMMENDED to not allow wildcard certificates.</td></tr></table>
+
+# 2.63. Page 458 - (2025-01) - Added optional variable to allow the Charging Station to report its supported idTokenTypes
+
+Currently there is no method for the Charging Station to report which idTokenTypes it supports. This would be very useful for a CSMS to know and will improve the automated onboarding of Charging Stations.
+
+# SupportedIdTokentypes
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportedIdTokenTypes</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>List of IdTokenEnumType.</td></tr><tr><td>Description</td><td colspan="3">The subset of the list of supported IdTokenTypes as defined by IdTokenEnumtype, that is supported by the Charging Station.</td></tr></table>
+
+# 2.64. Page 462 - (2025-01) - Added note to EnergyTransfer description as TxStartPoint
+
+A note has been added to the description of the EnergyTransfer TxStartPoint to warn for potential skews of the values of the energy meter readings associated with start of the transaction.
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td rowspan="2">EnergyTransfer</td><td>Energy is being transferred between EV and EVSE.</td></tr><tr><td>Note: Since energy needs to start flowing first to cause the transaction to be started, there is a small time gap (order of milliseconds) between the start of energy transfer and start of transaction. Depending on the implementation this may potentially skew the value of the energy meter reading associated with start of the transaction. Use PowerPathClosed as TxStartPoint to avoid this situation.</td></tr></table>
+
+# 2.65. Page 467 - (2025-09) - Error in description of AssociatedData interval variables [1043]
+
+The Interval and TxEndInterval variables of AssociatedDataCtrl mention an incorrect time and duration format (ISO8601) that is not supported by OCPP.
+
+# 2.65.1.AlignedDataInterval
+
+<table><tr><td>...</td><td>...</td></tr><tr><td>Description</td><td>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.
+A value of "0" (numeric zero), by convention, is to be interpreted to mean that no clock-aligned data should be transmitted.</td></tr></table>
+
+# 2.65.2.AlignedDataTxEndedInterval
+
+<table><tr><td>...</td><td>...</td></tr><tr><td>Description</td><td>Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the TransactionRequest (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 intervals are transmitted (if so enabled) at the end of the transaction in 1 TransactionRequest (eventType = Ended) message.
+This is not a recommended practice, since the size of the message can become very large.</td></tr></table>
+
+# 2.66. Page 476 - (2025-01) - Added Connector component to AvailabilityState referenced variable
+
+It was already possible to report the AvailabilityState of the Connector component, however the definition was missing at this table.
+
+# AvailabilityState
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td rowspan="4">Components</td><td rowspan="3">componentName</td><td colspan="2">ChargingStation</td></tr><tr><td colspan="2">EVSE</td></tr><tr><td colspan="2">Connector</td></tr><tr><td>evse</td><td colspan="2">* (for EVSE and Connector)</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">AvailabilityState</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>optionList</td></tr><tr><td>valuesList</td><td>Available, Occupied, Reserved, Unavailable, Faulted</td></tr><tr><td>Description</td><td colspan="3">This variable reports current availability state for the ChargingStation, EVSE and Connector. When this variable reports the Connector AvailabilityState, it replicates the connectorStatus values as would be reported by the StatusNotification messages.
+An EVSE or Connector component is addressed on its own tier. So, EVSE #1 is addressed as component EVSE on tier evse.id = 1, and EVSE #1, Connector #1 is addressed as component Connector on tier evse.id = 1, evseconnectorId = 1.</td></tr></table>
+
+# 3. Part 3
+
+Currently no new errata for OCPP 2.0.1 part 3.
+
+# 4. Part 4
+
+# 4.1. Page 6 - (2025-01) - 3.1.1. The connection URL
+
+The following clarifying text was added:
+
+<table><tr><td>Old text</td><td>[...] percent-encoded [...]</td></tr><tr><td>New text</td><td>[...] percent-encoded / URL encoded [...]</td></tr></table>
+
+# 4.2. Page 7 - (2025-01) - 3.1.2. OCPP version
+
+The following text has been rewritten for clarity:
+
+<table><tr><td>Old text</td><td>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.</td></tr><tr><td>New text</td><td>If the OCPP version is part of the OCPP-J endpoint URL it SHALL not determine the OCPP version to use, because the OCPP version is selected via the websocket protocol negotiation mechanism, as explained in section 3.3 [server-response].</td></tr></table>
+
+# 4.3. Page 8 - (2025-01) - 3.3. WebSocket Compression
+
+The following text was duplicate. The duplication has been removed and the text has been clarified:
+
+<table><tr><td>Old text</td><td>OCPP Requires the CSMS (and Local Controller) to support RFC 7692, WebSocket compression is seen as a relative simple way to reduce mobile data usage. For a Charging Station this is not a hard requirement, as this might be more complex to implement on an embedded platform, but as this is seen as efficient solution to reduce mobile data usage, it is RECOMMENDED to be implemented on a Charging Station that uses a mobile data connection.
+OCPP Requires the CSMS (and Local Controller) to support RFC 7692, WebSocket compression is seen as a relative simple way to reduce mobile data usage. For a Charging Station this is not a hard requirement, as this might be more complex to implement on an embedded platform, but as this is seen as efficient solution to reduce mobile data usage, it is RECOMMENDED to be implemented on a Charging Station that uses a mobile data connection.</td></tr><tr><td>New text</td><td>The CSMS (and Local Controller) SHALL support RFC 7692, WebSocket compression, which is a relative simple way to reduce mobile data usage. For a Charging Station this is not a hard requirement, as this might be more complex to implement on an embedded platform. It is RECOMMENDED to be implemented on a Charging Station, because it is an efficient solution to reduce mobile data usage.</td></tr></table>
+
+# 4.4. Page 10 - (2025-01) - 4.1.3. The message type
+
+OLD: |CALL |2 | Request message |CALLRESULT |3 | Response message
+
+New:
+
+|CALL |2 | Request message, i.e. messages ending in "Request" |CALLRESULT |3 | Response message, i.e. message ending in "Response"
+
+# 4.5. Page 10 - (2025-01) - 4.1.3. The message type
+
+Refer to 'system', instead of 'server'.
+
+<table><tr><td>Old text</td><td>When a server receives a message with a Message Type Number not in this list, it SHALL ignore the message payload. Each message type may have additional required fields.</td></tr><tr><td>New text</td><td>When a system receives a message with a Message Type Number not in this list, it SHALL ignore the message payload. Each message type may have additional required fields.</td></tr></table>
+
+# 4.6. Page 10 - (2024-09) - 4.1.4. Message ID
+
+Change the following text in paragraph 4.1.4:
+
+<table><tr><td>Old text</td><td>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 any WebSocket connection using the same unique Charging Station identifier. This also applies to retries of messages.</td></tr><tr><td>New text</td><td>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 any WebSocket connection using the same unique Charging Station identifier. The message ID for a retracted message (e.g. when no response was received within timeout) MAY be identical to the message ID of the original message.</td></tr></table>
+
+# 4.7. Page 13 - (2025-01) - 4.2.3. CALLERROR
+
+In the example, the ErrorDescription text has been updated:
+
+<table><tr><td>Old text</td><td>"SetDisplayMessageRequest not implemented"</td></tr><tr><td>New text</td><td>"SetDisplayMessageRequest not supported"</td></tr></table>
+
+# 4.8. Page 15 - (2025-01) - 5. Connection
+
+The following clarifying text has been added related to the TLS fragment length:
+
+# 4.9. TLS fragment length
+
+TLS involves sending "Records" between peers. Records can be of type "Handshake", "Alert", "ChangeCipherSpec", "Heartbeat" or "Application". OCPP messages are sent in Application records. The payload contains a "fragment" of the application data. The record layer fragments information blocks into TLS plaintext records carrying data in chunks of 2^14 bytes (16kB) or less.
+
+TLS peers need to maintain an input and an output buffer to store an entire fragment of $16\mathrm{~kB}$ . For a low resource device it is a large cost to allocate $32\mathrm{~kB}$ for the TLS connection.
+
+
+Peers allocating standard 16 kB TLS buffers
+
+A TLS extension is defined in TLS Extensions RFC6066 Section 4, that allows the client to ask for a different maximum fragment length than the default $16\mathrm{kB}$ . A client can ask for a maximum fragment length of $0.5\mathrm{kB}, 1\mathrm{kB}, 2\mathrm{kB}$ or $4\mathrm{kB}$ . This TLS extension is, however, not widely supported and native managed cloud TLS termination services typically don't support this.
+
+A resource-constrained Charging Station SHOULD try to negotiate a smaller TLS maximum fragment size, and if that is not accepted by the peer, then Charging Station MAY unilaterally decide to allocate less memory to its TLS output buffer. A TLS maximum fragment length of $2\mathrm{kB}$ is suggested based on data collection during certification tests, which shows that $99\%$ of the messages fit in a $2\mathrm{kB}$ buffer.
+
+
+Charging Station allocating a 2 kB TLS output buffer
+
+# 4.10. Page 15 - (2025-01) - 5.3. WebSocket Ping in relation to OCPP Heartbeat
+
+The following clarifying text was added:
+
+New text
+
+A Heartbeat message checks connectivity end-to-end, whereas a WebSocket ping/pong only checks from point-to-point. This makes a difference in an extended network topology with a Local Controller between Charging Station and CSMS.
+
+# 4.11. Page 15 - (2025-01) - 5 Connection - Added section about TLS fragment length
+
+As a result of the discussions at the OCPP lite taskgroup, a section has been added providing guidance on implementing TLS fragment negotiation.
+
+# 4.12. Page 16 - (2025-04) - 5.3 Reconnecting - reset backoff wait timer
+
+The RetryBackOffWaitMinimum timer is to be used the first time it tries to connect. A sentence has been added to below paragraph to make it explicit that it needs to be reset after successful connection.
+
+The first reconnection attempts SHALL be after a back-off time of: RetryBackOffWaitMinimum seconds, plus a random value with a maximum of RetryBackOffRandomRange seconds. After every failed reconnection attempt the Charging Station SHALL double the previous back-off time, with a maximum of RetryBackOffRepeatTimes, adding a new random value with a maximum of RetryBackOffRandomRange seconds to every reconnection attempt. After RetryBackOffRepeatTimes reconnection attempts, the Charging Station SHALL keep reconnecting with the last back-off time, not increasing it any further. After a successful connection the backoff wait timer SHALL be reset to RetryBackOffWaitMinimum seconds.
+
+# 4.13. Page 18 - (2025-02) - 6.3 Connection loss - Allow Local Controller to keep connection open
+
+The sentence in this section was too strict about requiring a Local Controller to always close the connection with its charging stations when the connection with CSMS is lost. The sentence has been updated in order to allow for Local Controller implementations that are able to manage the local charging stations locally (for a limited time) when the connection with CSMS is down.
+
+Old text
+
+Whenever one or more WebSocket connections between CSMS and the Local Controller are lost, the Local Controller SHALL close all corresponding WebSocket to the Charging Stations that are connected to it.
+
+<table><tr><td>New text</td><td>Whenever one or more WebSocket connections between CSMS and the Local Controller are lost, the Local Controller SHALL close all corresponding WebSocket to the Charging Stations that are connected to it, unless the Local Controller is capable of responding to Charging Station requests, and forwards transaction-related requests to the CSMS once the connection is restored.</td></tr></table>
+
+# 5. Part 5
+
+# 5.1. General - (2025-02) - Renamed OCTT to Test System
+
+Updated (2025-04)
+
+In the entire document, the term A few references to "OCTT" have been replaced by "Test System" (mostly "OCTT Id" has been replaced by "TC id").
+
+# 5.2. Page 7-48 - (2025-09) - Add additional support for different types of Charging Stations
+
+Added support for additional different types of Charging Stations:
+
+- Wireless inductive Charging Stations
+
+。For this a product subtype Wireless Charging Station has been added.
+
+- Charging Stations with different connectorTypes (like sType1) without (automatic) mechanized locking mechanisms
+
+. For this an additional question has been added: AQ-18: Does your Charging Station have at least one connector with an (automatic) mechanized locking mechanism on Charging Station side? (this is always true for connectorTypes; sType2 and sType3)
+
+- Charging Stations with a RFID reader to start a transaction and a stop button to stop the transaction.
+
+For this new stop local authorization methods C-70, C-71, C-72 and C-75 have been added, which makes it possible to have different authorization methods for the start and for the stop.
+
+As a result of above additions/updates, many testcase conditions have been updated to incorporate them accordingly.
+
+# 5.3. Page 7 - (2025-02) - Changed definition of C-01 Support for offline authorization of transactions
+
+The current definition is does not take into account the supported local authorization methods in relation to the features to locally store Tokens.
+
+<table><tr><td>Old</td><td>C-01</td><td>Support for offline authorization of transactions</td><td>Optional.
+Supporting this feature depends on whether at least one of the following is supported;
+- Certification Profile: Local Authorization List Management
+- C-02: Support for allowing offline authorization for unknown ids
+- C-49: Authorization Cache (AuthCacheEnabled)</td></tr><tr><td>New</td><td>C-01</td><td>Support for offline authorization of transactions</td><td>Conditional.
+Supporting this feature depends on whether at least one of the following feature combinations is supported;
+- Certification Profile: Local Authorization List Management AND at least one of the following local authorization options; C-30 or C-31 or C-32 or C-34.
+- C-02: Support for allowing offline authorization for unknown ids AND at least one of the following local authorization options; C-30 or C-31 or C-32 or C-33 or C-34.
+- C-49: Authorization Cache AND at least one of the following local authorization options; C-30 or C-31 or C-32 or C-34.
+- C-35: Local Authorization - NoAuthorization (Because there is no authorization, no local authorization mechanism is needed.)</td></tr></table>
+
+# 5.4. Page 9 - (2024-11) - Optional feature list for charging station - Change name R-3
+
+The specified name of feature R-3 is not correct. It should reflect the ability to disable reservations.
+
+<table><tr><td>Old</td><td>R-3</td><td>Reservation support (ReservationEnabled)</td><td>Configuration Variable for H01</td></tr><tr><td>New</td><td>R-3</td><td>Support for disabling Reservations (ReservationEnabled)</td><td>Configuration Variable for H01</td></tr></table>
+
+# 5.5. Page 9 - (2025-02) - Optional feature list for charging station - Added AQ-10 to make TC_N_48_CS conditional
+
+Added AQ-10 to make TC_N_48_CS conditional.
+
+<table><tr><td>Id</td><td>Additional questions for lab testing</td></tr><tr><td>AQ-10</td><td>Does your Charging Station support setting a Delta monitor on the WriteOnly component(variable SecurityCtrl.BasicAuthPassword?</td></tr></table>
+
+# 5.6. Page 9/11/27/48/52 - (2025-02) - Removed feature ISO-3, added additional question AQ-11
+
+# Page 9 - Optional feature list for charging station
+
+<table><tr><td></td><td colspan="3">ISO 15118 support</td></tr><tr><td>Removed</td><td>ISO-3</td><td>Combined charging station Certificate (for both OCPP and ISO 15118)</td><td>Optional</td></tr></table>
+
+Page 11 - Optional feature list for CSMS
+
+<table><tr><td></td><td colspan="3">ISO 15118 support</td></tr><tr><td>Removed</td><td>ISO-3</td><td>Combined charging station certificate (for both OCPP and ISO 15118)</td><td>Optional</td></tr></table>
+
+Page 27 - Test Cases Core
+
+<table><tr><td></td><td></td><td>Trigger message</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Old</td><td>TC_F_27</td><td>NotImplemented</td><td>C</td><td>M</td><td>For CS: can only be done when SignCombinedCertificate is notimplemented</td><td>NOT ISO-3</td><td></td></tr><tr><td>New</td><td>TC_F_27</td><td>NotImplemented</td><td>C</td><td>M</td><td>For CS: can only be done when SignCombinedCertificate is notimplemented</td><td>NOT AQ-11</td><td></td></tr></table>
+
+Page 48 - Questions for Charging Stations
+
+<table><tr><td></td><td>Id</td><td>Additional questions for lab testing</td></tr><tr><td>Added</td><td>AQ-11</td><td>Does your Charging Station support a combined charging station Certificate (for both OCPP and ISO 15118)</td></tr></table>
+
+Page 52 - Appendix C: Features vs. OCPP use cases
+
+<table><tr><td></td><td>Id</td><td>Feature</td><td>Related use cases</td></tr><tr><td></td><td colspan="3">ISO 15118 support</td></tr><tr><td>Removed</td><td>ISO-3</td><td>Combined charging station certificate (for both OCPP and ISO 15118)</td><td>A02/A03</td></tr></table>
+
+# 5.7. Page 9/10 - (2025-06) - Optional feature list for charging station & CSMS - Add optional feature for Security Profile 1
+
+Security profile 1 has become optional for Core certification.
+
+<table><tr><td>Added</td><td>C-61</td><td colspan="4">Security Profile 1 - Unsecured Transport with Basic Authentication</td><td colspan="2">Optional</td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_A_20</td><td>No valid CSMSRootCertificate installed</td><td>C</td><td></td><td>If the last CSMSRootCertificate can be removed and Security Profile 1 is supported.</td><td>AQ-1 and C-61</td><td>Can the last CSMSRootCertificate be removed?
+Security Profile 1 - Unsecured
+Transport with Basic
+Authentication</td><td></td></tr></table>
+
+# 5.8. Page 13 - (2025-09) - Added TC_B_14_CS (as optional) to the Core profile
+
+TC_B_14_CS was already a mandatory part of the Advanced Device Management profile, however it should also be possible to support the Summary inventory as part of the Core profile. Therefore, it will be added as an optional part of the Core profile.
+
+<table><tr><td>Added to Core</td><td>TC_B_14</td><td>SummaryInventory</td><td>C</td><td></td><td></td><td>C-56</td><td></td></tr></table>
+
+# 5.9. Page 13 - (2025-02) - Updated Id's of the additional questions of CSMSs in the appendix
+
+The following Id's of additional questions for CSMSs have been updated:
+
+<table><tr><td>Old</td><td>TC_B_30</td><td>Pending/Rejected - SecurityError</td><td>M</td><td>C</td><td>For CSMS: if CSMS can be configured to first respond to a BootNotificationRequest with status Pending or Rejected</td><td>C-44 or NOT AQ-6</td><td>BootNotification Pending or Does the CSMS reject unknown Charging Stations during websocket connection setup?</td></tr><tr><td>New</td><td>TC_B_30</td><td>Pending/Rejected - SecurityError</td><td>M</td><td>C</td><td>For CSMS: if CSMS can be configured to first respond to a BootNotificationRequest with status Pending or Rejected</td><td>C-44 or NOT AQ-16</td><td>BootNotification Pending or Does the CSMS reject unknown Charging Stations during websocket connection setup?</td></tr><tr><td>Old</td><td>TC_B_31</td><td>Pending/Rejected - TriggerMessage</td><td></td><td>C</td><td>For CSMS: if CSMS can be configured to first respond to a BootNotificationRequest with status Pending or Rejected</td><td>C-44 or NOT AQ-6</td><td>BootNotification Pending or Does the CSMS reject unknown Charging Stations during websocket connection setup?</td></tr><tr><td>New</td><td>TC_B_31</td><td>Pending/Rejected - TriggerMessage</td><td></td><td>C</td><td>For CSMS: if CSMS can be configured to first respond to a BootNotificationRequest with status Pending or Rejected</td><td>C-44 or NOT AQ-16</td><td>BootNotification Pending or Does the CSMS reject unknown Charging Stations during websocket connection setup?</td></tr></table>
+
+# 5.10. Page 15 - (2025-04) - Addition of new testcase for CSMS to test WebSocket Subprotocol negotiation
+
+New
+
+TC_B_58
+
+WebSocket Subprotocol negotiation
+
+M
+
+# 5.11. Page 17/33 - (2025-02) - Test Cases Local Authorization List Management & Authorization Cache - Update conditions
+
+Testcases marked as mandatory have conditions that are not applicable and should be removed. The CWG decided that online local authorization list and authorization cache testcase can also be tested with remote authorization. In addition, local auth method C-34 MacAddress has been added to the offline conditions as possible method to use.
+
+Authorization Cache
+
+<table><tr><td></td><td>Store Authorization Data in the Authorization Cache</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_32</td><td>Persistent over reboot</td><td>C</td><td></td><td>If the Charging Station has an authorization cache, then it must support this use case</td><td>C-49</td><td>Authorization Cache</td></tr><tr><td>TC_C_33</td><td>Update onauthorizeResponse</td><td>C</td><td></td><td>If the Charging Station has an authorization cache, then it must support this use case</td><td>C-49</td><td>Authorization Cache</td></tr><tr><td>TC_C_34</td><td>Update on TransactionResponse</td><td>C</td><td></td><td>If the Charging Station has an authorization cache, then it must support this use case</td><td>C-49</td><td>Authorization Cache</td></tr><tr><td>TC_C_36</td><td>AuthCacheCtrl.LocalPreAuthorize = false</td><td>C</td><td></td><td>If the Charging Station has an authorization cache and AuthCacheEnabled is implemented</td><td>C-49</td><td>Authorization Cache</td></tr><tr><td>TC_C_46</td><td>AuthCacheLifeTime</td><td>C</td><td></td><td>If the Charging Station has an authorization cache and supports to set a lifetime for its entries.</td><td>C-49 and C-53</td><td>Authorization Cache & AuthCacheLifeTime</td></tr><tr><td></td><td>Clear Authorization Data in Authorization Cache</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_37</td><td>Accepted</td><td>C</td><td>M</td><td>If the Charging Station has an authorization cache, then it must support this use case</td><td>C-49</td><td>Authorization Cache</td></tr><tr><td>TC_C_38</td><td>Rejected</td><td>C</td><td>M</td><td>If the Charging Station has an authorization cache and AuthCacheEnabled is implemented</td><td>C-49</td><td>Authorization Cache</td></tr><tr><td></td><td>Authorization by GroupId</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_41</td><td>Success with Authorization Cache</td><td>C</td><td></td><td>For CS:- The Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32, C-34- If the Charging Station has an authorization cache.</td><td>C-49 and (C-30 or C-31 or C-32 or C-34)</td><td>Authorization Cache</td></tr><tr><td>TC_C_44</td><td>Invalid status with Authorization Cache</td><td>C</td><td></td><td>For CS:- The Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32, C-34- If the Charging Station has an authorization cache.</td><td>C-49 and (C-30 or C-31 or C-32 or C-34)</td><td>Authorization Cache</td></tr><tr><td></td><td>Authorization through authorization cache</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_08</td><td>Accepted</td><td>C</td><td>M</td><td>If the Charging Station has an authorization cache</td><td>C-49</td><td>Authorization Cache</td></tr><tr><td>TC_C_09</td><td>Invalid & Not Accepted</td><td>C</td><td></td><td>If the Charging Station has an authorization cache</td><td>C-49</td><td>Authorization Cache</td></tr><tr><td>TC_C_12</td><td>Invalid & Accepted</td><td>C</td><td></td><td>If the Charging Station has an authorization cache</td><td>C-49</td><td>Authorization Cache</td></tr><tr><td>TC_C_10</td><td>Blocked</td><td>C</td><td></td><td>If the Charging Station has an authorization cache</td><td>C-49</td><td>Authorization Cache</td></tr><tr><td>TC_C_11</td><td>Expired</td><td>C</td><td></td><td>If the Charging Station has an authorization cache</td><td>C-49</td><td>Authorization Cache</td></tr><tr><td>TC_C_13</td><td>Accepted but cable not connected yet.</td><td>C</td><td></td><td>If the Charging Station has an authorization cache</td><td>C-49</td><td>Authorization Cache</td></tr><tr><td>TC_C_15</td><td>StopTxOnInvalidld = false, MaxEnergyOnInvalidld > 0</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32, C-34If MaxEnergyOnInvalidld is implemented.</td><td>C-49 and C-03 and (C-30 or C-31 or C-32 or C-34)</td><td>Authorization Cache & MaxEnergyOnInvalidld</td></tr><tr><td>TC_C_16</td><td>StopTxOnInvalidld = true</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32, C-34</td><td>C-49 and (C-30 or C-31 or C-32 or C-34)</td><td>Authorization Cache</td></tr><tr><td>TC_C_17</td><td>StopTxOnInvalidld = false</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32, C-34</td><td>C-49 and (C-30 or C-31 or C-32 or C-34)</td><td>Authorization Cache</td></tr><tr><td>TC_C_18</td><td>StopTxOnInvalidld = true, MaxEnergyOnInvalidld > 0</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32, C-34If MaxEnergyOnInvalidld is implemented.</td><td>C-49 and C-03 and (C-30 or C-31 or C-32 or C-34)</td><td>AuthorizationCache & MaxEnergyOnInvalidld</td></tr><tr><td>TC_C_20</td><td>Invalid</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_C_57</td><td>AuthCacheDisablePostAuthorize</td><td>C</td><td></td><td>If the Charging Station supports the option for disabling remote authorization for cached invalid Tokens AND has an authorization cache</td><td>C-59 and C-49</td><td></td></tr><tr><td></td><td>Local start transaction - Authorization first</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>....</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_52</td><td>DisableRemoteAuthorization</td><td>C</td><td></td><td>If the Charging Station supports the option for disabling remote authorization and The Charging Station supports at least one of the following local start authorization options C-30, C-31, C-32, C-34 and Either Authorization Cache or Local Authorization List is supported.</td><td>C-58 and (C-30 or C-31 or C-32 or C-34) and (C-49 or Local Authorization List Managem ent)</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode / MacAddress & Authorization Cache & Local Authorization List.</td></tr><tr><td></td><td>....</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Offline Behaviour</td><td></td><td></td><td></td><td></td><td></td></tr></table>
+
+Local Authorization List Management
+
+<table><tr><td></td><td>Store Authorization Data in the Authorization Cache</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_45</td><td>Stop transaction during offline period - Same GroupId</td><td>C</td><td></td><td>For CS: the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32, C-34 and Local Authorization List or Authorization Cache</td><td>(C-30 or C-31 or C-32 or C-34) AND (Local Authorization List Management or C-49)</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode / MacAddress and Local Authorization List or Authorization Cache</td></tr></table>
+
+<table><tr><td colspan="5"></td><td colspan="2">Related features</td></tr><tr><td>TC Id</td><td>OCPP Compliance Testing Tool scenario</td><td>Conf. Test for Charging Station</td><td>Conf. test for CSMS</td><td>Condition / remark</td><td>Feature no.</td><td>Feature</td></tr><tr><td></td><td>Offline authorization through local authorization list</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_21</td><td>Accepted</td><td>C</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32, C-34</td><td>C-30 or C-31 or C-32 or C-34</td><td></td></tr><tr><td>TC_C_22</td><td>Invalid</td><td>C</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32, C-34</td><td>C-30 or C-31 or C-32 or C-34</td><td></td></tr><tr><td>TC_C_23</td><td>Blocked</td><td>C</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32, C-34</td><td>C-30 or C-31 or C-32 or C-34</td><td></td></tr><tr><td>TC_C_24</td><td>Expired</td><td>C</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32, C-34</td><td>C-30 or C-31 or C-32 or C-34</td><td></td></tr><tr><td>TC_C_25</td><td>Local Authorization List > Authorization Cache</td><td>C</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32, C-34</td><td>C-30 or C-31 or C-32 or C-34</td><td></td></tr><tr><td></td><td>Online authorization through local authorization list</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_27</td><td>Accepted</td><td>M</td><td></td><td><Removed></td><td><Removed></td><td></td></tr><tr><td>TC_C_28</td><td>Invalid & Not Accepted</td><td>M</td><td></td><td><Removed></td><td><Removed></td><td></td></tr><tr><td>TC_C_31</td><td>Invalid & Accepted</td><td>M</td><td></td><td><Removed></td><td><Removed></td><td></td></tr><tr><td>TC_C_29</td><td>Blocked</td><td>M</td><td></td><td><Removed></td><td><Removed></td><td></td></tr><tr><td>TC_C_30</td><td>Expired</td><td>M</td><td></td><td><Removed></td><td><Removed></td><td></td></tr><tr><td>TC_C_58</td><td>LocalAuthListDisablePostAuthorize</td><td>C</td><td></td><td>The Charging Station supports the option for disabling remote authorization for invalid idTokens stored at the Local Authorization List.</td><td>LA-3</td><td></td></tr><tr><td></td><td>Authorization by GroupId</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_40</td><td>Success with Local Authorization List</td><td>C</td><td>M</td><td>For CS:- The Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32, C-34</td><td>C-30 or C-31 or C-32 or C-34</td><td></td></tr><tr><td>TC_C_43</td><td>Invalid status with Local Authorization List</td><td>C</td><td>M</td><td>For CS:- The Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32, C-34</td><td>C-30 or C-31 or C-32 or C-34</td><td></td></tr></table>
+
+# 5.12. Page 19 - (2024-09) - TC_E_04_CS Updated condition for test case to exclude it for MacAddress and ISO 15118 PnPc
+
+This test case cannot be performed with the local authorization option MacAddress or ISO 15118 PnC.
+
+<table><tr><td></td><td></td><td>Local start transaction - Authorization first</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Old</td><td>TC_E_04</td><td>Success</td><td>C</td><td>M</td><td>Applicable if one or more of the local start authorization options is implemented.</td><td>C-30 - C-35 or ISO 15118 support</td><td>Authorization options for local start</td></tr><tr><td>New</td><td>TC_E_04</td><td>Success</td><td>C</td><td>M</td><td>Applicable if one or more of the local start authorization options is implemented.</td><td>(C-30 or C-31 or C-32 or C-33 or C-35)</td><td>Authorization options for local start</td></tr></table>
+
+# 5.13. Page 22 - (2024-09) - TC_E_17_CS Updated condition for test case to correctly specify the applicable TxStopPoint combinations
+
+This testcase allows for a limited set of TxStopPoint combinations, otherwise it is not applicable.
+
+<table><tr><td></td><td></td><td>Local start transaction - Authorization first</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Old</td><td>TC_E_17</td><td>Deauthorized - EV side disconnect</td><td>C</td><td>M</td><td>-TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value Authorized or PowerPathClosed is a supported value.
+- StopTxOnEVSideDisconnect needs to ReadWrite or ReadOnly with value true</td><td>(C-10.2 or C-10.3) and C-06.2 and AQ-9</td><td>Supported Transaction Stop points</td></tr><tr><td>New</td><td>TC_E_17</td><td>Deauthorized - EV side disconnect</td><td>C</td><td>M</td><td>This testcase is applicable if the value Authorized is a supported value for TxStopPoint AND EVConnected, PowerPathClosed and EnergyTransfer must not be set as TxStopPoint AND StopTxOnEVSideDisconnect true must be a supported value.</td><td>C-10.2 and C-06.2 and AQ-9 and NOT (NOT C-52 AND (10.1 OR C-10.3 OR 10.4))</td><td>Supported Transaction Stop points</td></tr></table>
+
+# 5.14. Page 33 - (2025-06) - Fixed incorrect feature no reference
+
+TC_A_21 referred to AQ-1, instead of AQ-3. This has been fixed.
+
+<table><tr><td>TC_A_21</td><td>No valid ChargingStationCertificate installed</td><td>C</td><td></td><td>If the last ChargingStationCertificate can be removed (Via other means than OCPP).</td><td>AQ-3</td><td></td></tr></table>
+
+# 5.15. Page 39 - (2025-02) - TC_N_48_CS Made conditional
+
+This test case is only applicable if the Charging Station supports Delta monitoring on the SecurityCtrl.BasicAuthPassword component variable.
+
+<table><tr><td>Old</td><td>TC_N_48</td><td>Variable monitoring on write only</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>New</td><td>TC_N_48</td><td>Variable monitoring on write only</td><td>C</td><td></td><td>CS: if the CS supports Delta monitoring on the SecurityCtrl.BasicAuthPassword</td><td>AQ-10</td><td></td></tr></table>
+
+# 5.16. Page 40 - (2024-11) - TC_H_13_CS Updated invalid condition for test case
+
+The condition should have been reversed.
+
+<table><tr><td>Old</td><td>TC_H_13</td><td>Rejected</td><td>C</td><td></td><td>Depending on configuration variable
+ReservationNonSpecificEVSE</td><td>R-2</td><td>Support reservations of unspecified EVSE</td></tr><tr><td>New</td><td>TC_H_13</td><td>Rejected</td><td>C</td><td></td><td>Depending on the Charging Station not supporting the configuration variable ReservationNonSpecificEVSE</td><td>NOT R-2</td><td>Support reservations of unspecified EVSE</td></tr></table>
+
+# 5.17. Page 42 - (2025-02) - Removed TC_O_15_CS from certification program
+
+# 5.18. Test Cases Advanced User Interface
+
+<table><tr><td></td><td colspan="5"></td><td colspan="2">Related features</td></tr><tr><td>Removed</td><td>TC_O_15</td><td>Language preference of the EV Driver</td><td>M</td><td></td><td></td><td></td><td></td></tr></table>
+
+# 5.19. Page 42 - (2025-06) - Make optional feature R-1 available for Charging Stations
+
+The ConnectorEnumType list does not contain all connectorTypes. At OCPP 2.1 this enum has been changed to a string and can be extended, however this is not possible for OCPP 2.0.1. Therefore the reservation of connectorType testcases will not work for connectorTypes that are not part of the enum. It is not a major issue, because the CSMS can always reserve a specific EVSE based on the connectorTypes specified at the device model.
+
+<table><tr><td></td><td colspan="5"></td><td colspan="2">Related features</td></tr><tr><td>Old</td><td>TC_H_15</td><td>Success</td><td>C</td><td>C</td><td></td><td>CSMS: R-1CS: R-2</td><td>For CSMS: Supportreservations of connectorType, For CS: Support forreservation of unspecifiedEVSE</td></tr><tr><td>New</td><td>TC_H_15</td><td>Success</td><td>C</td><td>C</td><td></td><td>R-1</td><td>Support reservations ofconnectorType</td></tr><tr><td>Old</td><td>TC_H_16</td><td>Amount of available connectors of a type equals theamount of reservations</td><td>C</td><td></td><td></td><td>R-2</td><td>Support for reservation ofunspecified EVSE</td></tr><tr><td>New</td><td>TC_H_16</td><td>Amount of available connectors of a type equals theamount of reservations</td><td>C</td><td></td><td></td><td>R-1</td><td>Support reservations ofconnectorType</td></tr></table>
+
+Added for Charging Station:
+
+<table><tr><td>Added</td><td>R-1</td><td>Support reservations of connectorType</td><td>Conditional.
+Supporting this feature depends on whether at least one connectorType is supported that is part of the ConnectorEnumType list from part 2 specification.</td></tr></table>
+
+# 5.20. Page 44 - (2025-02) - Removed TC_A_13_CS and TC_A_13_CSMS from certification program
+
+# Test Cases ISO 15118 Support
+
+<table><tr><td></td><td colspan="5"></td><td colspan="2">Related features</td></tr><tr><td>Removed</td><td>TC_A_13</td><td>Success - Combined Certificate</td><td>C</td><td>C</td><td>If Combined Charging Station Certificate is supported.</td><td>ISO-3</td><td>Combined Charging Station Certificate</td></tr></table>
+
+# 5.21. Page 48 - (2024-06) - Added additional questions to appendix
+
+Note: This erratum is extended by erratum: Page 48 - (2025-02) - Updated ld's of the additional questions for CSMSs in the appendix
+
+The following additional questions are added for CSMSs:
+
+<table><tr><td>Id</td><td>Additional questions for lab testing</td></tr><tr><td>AQ-3</td><td>Does your CSMS support Absolute values for the following Charging Profiles:</td></tr><tr><td>AQ-3.1</td><td>TxDefaultProfile</td></tr><tr><td>AQ-3.2</td><td>ChargingStationMaxProfile</td></tr><tr><td>AQ-4</td><td>Does your CSMS support Recurring values for the following Charging Profiles:</td></tr><tr><td>AQ-4.1</td><td>TxDefaultProfile</td></tr><tr><td>AQ-4.2</td><td>ChargingStationMaxProfile</td></tr></table>
+
+# 5.22. Page 48 - (2025-02) - Updated Id's of the additional questions for CSMSs in the appendix
+
+Note: This erratum extends erratum: Page 48 - (2024-06) - Added additional questions to appendix
+
+Note: This erratum is extended by erratum: Page 48 - (2025-04) - Duplicate AQ-11 id
+
+The following Id's of additional questions for CSMSs have been updated:
+
+<table><tr><td>Old Id</td><td>New Id</td></tr><tr><td>AQ-1</td><td>AQ-11</td></tr><tr><td>AQ-2</td><td>AQ-12</td></tr><tr><td>AQ-3.1</td><td>AQ-13.1</td></tr><tr><td>AQ-3.2</td><td>AQ-13.2</td></tr><tr><td>AQ-4</td><td>AQ-14</td></tr><tr><td>AQ-4.1</td><td>AQ-14.1</td></tr><tr><td>AQ-4.2</td><td>AQ-14.2</td></tr><tr><td>AQ-6</td><td>AQ-16</td></tr></table>
+
+# 5.23. Page 48 - (2025-04) - Duplicate AQ-11 id
+
+Note: This erratum extends erratum: Page 48 - (2025-02) - Updated Id's of the additional questions for CSMSs in the appendix
+
+At the 2025-02 errata sheet release, both for Charging Station and CSMS an additional question was added with id AQ-11, but these should be kept unique. The following Id's of additional questions for CSMSs have been updated:
+
+<table><tr><td>Old Id</td><td>New Id</td></tr><tr><td>AQ-11</td><td>AQ-17</td></tr></table>
+
+# 6. Part 6
+
+# 6.1. General
+
+# 6.1.1. Page XX - (2024-11) - All testcases - Updated table structure of all testcases
+
+The table structure of all testcases have been updated. This has been done for multiple reasons:
+
+- It improves readability by providing more space for the main steps.
+- It decreases the chance of testcase tables being broken, resulting in missing steps at the bottom of a testcase.
+- It makes it easier for the Technical Editors to update testcases.
+
+# 6.1.2. Page XX - (2025-02) - Renamed OCTT to Test System
+
+In the entire document, the term "OCTT" has been replaced by "Test System".
+
+# 6.2. Charging Station
+
+# 6.2.1. Page 4 - (2025-02) - TC_A_01_CS - Updated old identifierString reference in description
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+[...]</td></tr><tr><td>- BasicAuthPassword may only contain alpha-numeric characters and the special characters allowed by identifierString.</td></tr><tr><td>- BasicAuthPassword may only contain alpha-numeric characters and the special characters allowed by passwordString.</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+# 6.2.2. Page 7 - (2024-11) - TC_A_05_CS - Successfully reconnecting after every failed connection attempt
+
+It is needed to reconnect after every (intended) failed connection, otherwise the retryBackoffTime may double itself several time, resulting in a very large number that may exceed the configured timeouts.
+
+Table 6. Test Case Id: TC_A_05_CS
+
+<table><tr><td>Test case name</td><td>TLS - server-side certificate - Invalid certificate</td></tr><tr><td>Test case Id</td><td>TC_A_05_CS</td></tr><tr><td>Use case Id(s)</td><td>A00</td></tr><tr><td>Requirement(s)</td><td>A00.FR.309,A00.FR.310,A00.FR.311,A00.FR.412,A00.FR.413,A00.FR.414</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>The CSMS uses a server-side certificate to identify itself to the Charging Station, when using security profile 2 or 3.</td></tr><tr><td>Purpose</td><td>To verify whether the Charging Station is able to terminate the connection when the received server certificate is invalid.</td></tr><tr><td>Prerequisite(s)</td><td>- The charging station supports security profile 2 and/or 3
+- The active NetworkConnectionProfile uses either security profile 2 OR 3.
+<Removed></td></tr><tr><td>Test case name</td><td colspan="2">TLS - server-side certificate - Invalid certificate</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:OCPPCommCtrlt.NetworkConfigurationPriority only contains <Value from ActiveNetworkProfile></td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="9">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT aborts the connection with the Charging Station.</td></tr><tr><td>2. The Charging Station initiates a TLS handshake and sends a Client Hello to the OCTT.</td><td>3. The OCTT responds with a Server HelloWith a <Configured valid server certificate>Note(s):- The OCTT will use this as an indication of the time it takes the Charging Station to reconnect.</td></tr><tr><td colspan="2">4. The OCTT aborts the connection with the Charging Station.</td></tr><tr><td>5. The Charging Station initiates a TLS handshake and sends a Client Hello to the OCTT.</td><td>6. The OCTT responds with a Server HelloWith a <Configured invalid server certificate></td></tr><tr><td>7. The Charging Station deems the server certificate invalid and terminates the connection.</td><td></td></tr><tr><td colspan="2">Note: The OCTT will wait two times the measured reconnection time from step 3, before switching the server certificate back to the valid server certificate. The reason for this is that the OCTT is not always able to detect a failed connection attempt.</td></tr><tr><td>8. The Charging Station initiates a TLS handshake and sends a Client Hello to the OCTT.</td><td>9. The OCTT responds with a Server HelloWith a <Configured valid server certificate>Note(s):- The OCTT will accept the connection to prevent doubling of the RetryBackOffWaitMinimum.</td></tr><tr><td>10 The Charging Station sends aSecurityEventNotificationRequest</td><td>11 The OCTT responds with aSecurityEventNotificationResponse</td></tr><tr><td></td><td colspan="2">Note(s):- Steps 4 to 11 are repeated per configured invalid server certificate.- In case default certificates are being used, the OCTT will use three different invalid server certificates; "Not signed by installed Root certificate", "Expired", "CommonName that does not equal the FQDN of the server".- In case custom certificates are being used, the OCTT will loop through all certificates configured at the 'CSMS Keystore Invalid'.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 11:Message: SecurityEventNotificationRequest-type must be InvalidCsmsCertificate</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+# 6.2.3. Page 7 - (2025-02) - TC_A_05_CS
+
+Before (Preparations)
+
+<table><tr><td>Configuration State:
+OCPPCommCtrlr.NetworkProfileConnectionAttempts is 3
+OCPPCommCtrlr.NetworkConfigurationPriority only contains <Value from ActiveNetworkProfile></td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">[...]</td></tr><tr><td>5. The Charging Station initiates a TLS handshake and sends a Client Hello to the Test System.</td><td>6. The Test System responds with a Server Hello With-a<Configured invalid server certificate>With a <Generated invalid server certificate></td></tr><tr><td colspan="2">[...]</td></tr><tr><td>10 The Charging Station sends a SecurityEventNotificationRequest</td><td>11 The Test System responds with a SecurityEventNotificationResponse</td></tr><tr><td>Note(s):
+-Steps 4 to 11 are repeated per configured invalid server certificate.
+-In case default certificates are being used, the Test System will use three different invalid server certificates;
+"Not signed by installed Root certificate", "Expired", "CommonName that does not equal the FQDN of the server".
+-In case custom certificates are being used, the Test System will loop through all certificates configured at the 'CSMS Keystore Invalid'.
+The Test System will loop through steps 4 to 11 for a set of generated invalid certificates;
+"Expired", "Future validity date", "Not signed by installed CSMS Root certificate", "CommonName that does not equal the FQDN of the server", "CommonName containing a wildcard hostname matching the FQDN".</td><td></td></tr></table>
+
+# 6.2.4. Page 7 - (2025-04) - TC_A_05_CS - Updated before steps to take into account the AllowCSMSTLSWildcard variables
+
+<table><tr><td>Test case name</td><td>TLS - server-side certificate - Invalid certificate</td></tr><tr><td>Test case Id</td><td>TC_A_05_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+OCPPCommCtrl.NetworkProfileConnectionAttempts is 3
+OCPPCommCtrl.NetworkConfigurationPriority only contains <Value from ActiveNetworkProfile>
+SecurityCtrl.AllowCSMSTLSWildcards is false (If implemented)</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+# 6.2.5. Page 20 - (2025-02) - TC_A_23_CS - CSMS returns a CertificateSigned message for each request
+
+TC_A_23_CS: Update Charging Station Certificate by request of CSMS - CertificateSignedRequest Timeout
+
+<table><tr><td>Test case name</td><td>Update Charging Station Certificate by request of CSMS - CertificateSignedRequest Timeout</td></tr><tr><td>Test case Id</td><td>TC_A_23_CS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Purpose</td><td>To verify if the Charging Station is able to send a new signCertificateRequest when it did not receive a certificateSignedRequest after the configured timeout. CSMS will after a delay send a CertificateSignedRequest for each SignCertificateRequest that it has accepted.</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+# Before (Preparations)
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>12. The Charging Station responds with a CertificateSignedResponse</td><td>11. The Test System sends a CertificateSignedRequest With certificateChain <Certificate generated from the received CSR from step 3 and signed by the provided CSMS Root certificate> certificateType ChargingStationCertificate</td></tr><tr><td>14. The Charging Station responds with a CertificateSignedResponse</td><td>13. The Test System sends a CertificateSignedRequest With certificateChain <Certificate generated from the received CSR from step 6 and signed by the provided CSMS Root certificate> certificateType ChargingStationCertificate</td></tr><tr><td>16. The Charging Station responds with a CertificateSignedResponse</td><td>15. The Test System sends a CertificateSignedRequest With certificateChain <Certificate generated from the received CSR from step 9 and signed by the provided CSMS Root certificate> certificateType ChargingStationCertificate</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>...</td></tr><tr><td>* Step 12, 14, 16:
+Message: CertificateSignedResponse
+- status must be Accepted or Rejected</td></tr><tr><td>Post scenario validations:
+Note: It does not matter whether Charging Station accepts first or last or all certificates.
+At least one CertificateSignedResponse must have status Accepted</td></tr></table>
+
+# 6.2.6. Page 22 - (2024-09) - TC_A_19_CS - Fixed references to ConfigurationSlot [O20-4762]
+
+<table><tr><td>Test case name</td><td>Upgrade Charging Station Security Profile - Accepted</td></tr><tr><td>Test case Id</td><td>TC_A_19_CS</td></tr><tr><td colspan="2"></td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Upgrade Charging Station Security Profile - Accepted</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The OCTT sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use -connectionData.messageTimeout <Configured messageTimeout> -connectionData.ocppCsmsUrl <Configured ocppCsmsUrl> -connectionData.ocpplInterface <Configured ocplInterface> -connectionData.ocppVersion OCPP20 -connectionData.securityProfile <Configured securityProfile + 1></td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The OCTT sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is "<Configured configurationSlot2>,<Configured configurationSlot>"</td></tr><tr><td>...</td><td>...</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message SetNetworkProfileResponse
+- status Accepted
+* Step 4:
+Message SetVariablesResponse
+- setVariableResult[0].attributeStatus Accepted OR RebootRequired
+* Step 6:
+Message ResetResponse
+- status Accepted
+* Step 11:
+Message GetVariablesResponse
+- getVariableResult[0].attributeValue <Configured securityProfile + 1>
+* Step 13:
+Message GetVariablesResponse
+- getVariableResult[0].attributeValue Does not contain the configurationSlot with the previous (lower) security profile</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.2.7. Page 22 - (2025-06) - TC_A_19_CS - Added steps to validate the Charging Station does not downgrade back to security profile 1.
+
+Added steps to validate the Charging Station does not downgrade back to security profile 1 after having upgraded to security profile 2.
+
+<table><tr><td>Test case name</td><td colspan="2">Upgrade Charging Station Security Profile - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_19_CS</td></tr><tr><td colspan="3">...</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td colspan="2">CSMS</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The Test System sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use -connectionData.messageTimeout <Configured messageTimeout> -connectionData.ocppCsmsUrl <Configured ocppCsmsUrl> -connectionData.ocpptInterface <Configured ocpptInterface> -connectionData.ocppVersion OCPP20 -connectionData.securityProfile <Configured securityProfile + 1> Note(s): -The Test System checks the ActiveNetworkProfile variable to see which slot is currently active. -The Test System prevents overwriting the NetworkProfile at the active slot, as this is not recommended.</td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The Test System sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is <configurationSlot set at Step 1, the other configured configurationSlot></td></tr><tr><td>6. The Charging Station responds with a ResetResponse</td><td>5. The Test System sends a ResetRequest with type OnIdle</td></tr><tr><td></td><td>7. The Test System restarts the WebSocket server using <Configured securityProfile + 1></td></tr><tr><td>8. The Charging Station reconnects to the Test System using <Configured securityProfile + 1></td><td>9. The Test System accepts the connection attempt.</td></tr><tr><td colspan="2">10. Execute Reusable State Booted</td></tr><tr><td>12. The Charging Station responds with GetVariablesResponse</td><td>11. Test System sends GetVariablesRequest with: -variable.name = "SecurityProfile" -component.name = "SecurityCtrl"</td></tr><tr><td>14. The Charging Station responds with GetVariablesResponse</td><td>13. Test System sends GetVariablesRequest with: -variable.name = "NetworkConfigurationPriority" -component.name = "OCPPCommCtrl"</td></tr><tr><td colspan="2">The following steps are only executed when this testcase is upgrading from Security Profile 1 to Security Profile 2.</td></tr><tr><td>16. The Charging Station does NOT reconnect to the Test System using Security Profile 1.</td><td>15. The Test System closes the connection and restarts the WebSocket server using Security profile 1 and waits the <Configured long operation timeout>.</td></tr><tr><td>18. The Charging Station reconnects to the Test System using Security Profile 2.</td><td>17. The Test System restarts the WebSocket server using Security Profile 2.</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+Message SetNetworkProfileResponse
+- status Accepted
+* Step 4:
+Message SetVariablesResponse
+- setVariableResult[0].attributeStatus Accepted OR RebootRequired
+* Step 6:
+Message ResetResponse
+- status Accepted
+* Step 12:
+Message GetVariablesResponse
+- getVariableResult[0].attributeValue <Configured securityProfile + 1>
+* Step 14:
+Message GetVariablesResponse
+- getVariableResult[0].attributeValue Does not contain the configurationSlot with the previous (lower) security profile</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.2.8. Page 24 - (2025-02) - TC_A_20_CS - Testcase did not take into account that the used configuration slot could already be set
+
+The testcase did not take into account that the NetworkConnectionProfile slot updated during the main steps, might already be set at the OCPPCommCtrl.NetworkConfigurationPriority. This would cause setting the networkConnectionProfile to be rejected already.
+
+<table><tr><td>Test case name</td><td>Upgrade Charging Station Security Profile - No valid CSMSRootCertificate installed</td></tr><tr><td>Test case Id</td><td>TC_A_20_CS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>- The Test System connectionData configuration for SUT Charging Station only allows for ip addresses the Test System is able to bind.
+- The Charging Station supports at least 2 security profiles, one of which is security profile 1.
+- The Charging Station does not have a valid CSMSRootCertificate installed.
+- The first Test System connectionData configuration slot must be configured for security profile 1.
+- The second Test System connectionData configuration slot must be configured for security profile 2 or 3.
+- The Charging Station is connected using security profile 1.
+- When starting this testcase the Test System will start another WebSocket server for the secondconnectionData slot.</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+OCPPCommCtrlr.NetworkConfigurationPriority is <ActiveNetworkProfile slot> (All others are removed)</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The Test System sends a SetNetworkProfileRequest with - configurationSlot is <Configured configurationSlot 2> or <Configured configurationSlot> (the one currently not used for the active connection)
+- connectionData.messageTimeout <Configured messageTimeout2>
+- connectionData.ocppCsmsUrl <ocppCsmsUrl that is not currently active>
+- connectionData.ocpptInterface <Configured ocpptInterface2>
+- connectionData.ocppVersion OCPP20
+- connectionData.securityProfile <Configured securityProfile2></td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The Test System sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority"
+component.name is "OCPPCommCtrlr"
+attributeValue is <configurationSlot set at step 1>,<previous configurationSlot></td></tr></table>
+
+# 6.2.9. Page 24 - (2025-04) - TC_A_20_CS - SetNetworkConnectionProfile is allowed to be rejected
+
+<table><tr><td>Test case name</td><td>Upgrade Charging Station Security Profile - No valid CSMSRootCertificate installed</td></tr><tr><td>Test case Id</td><td>TC_A_20_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+Message SetNetworkProfileResponse
+- status Accepted or Rejected
+* Step 4:
+Message SetVariablesResponse
+- setVariableResult[0].attributeStatus Rejected</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.2.10. Page 25 - (2025-02) - TC_A_21_CS
+
+# TC_A_21_CS: Upgrade Charging Station Security Profile - No valid ChargingStationCertificate installed
+
+<table><tr><td>Test case name</td><td>Upgrade Charging Station Security Profile - No valid ChargingStationCertificate installed</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Description</td><td>The CSMS is able to change the connectionData at the Charging Station. By doing this it is able to upgrade the connection to a security profile 3.</td></tr><tr><td>Purpose</td><td>To verify if the Charging Station is able to reject upgrading to a security profile 3 when it does not have a valid ChargingStationCertificate installed.</td></tr><tr><td>Prerequisite(s)</td><td>- The Test System connectionData configuration for SUT Charging Station only allows for ip addresses the Test System is able to bind.
+- The Charging Station support at least 2 security profiles.
+- The Charging Station does not have a valid ChargingStationCertificate installed.
+- The Charging Station has a valid CSMSRootCertificate installed.
+- The second Test System connectionData configuration slot must be configured for security profile 3.
+- When starting this testcase the Test System will start another webSocket server for the second connectionData slot.</td></tr><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The Test System 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.ocpplInterface <Configured ocplInterface2> - connectionData.ocppVersion OCPP20 - connectionData.securityProfile <Configured.securityProfile2> 3</td></tr></table>
+
+# 6.2.11. Page 26 - (2025-02) - TC_A_22_CS
+
+# TC_A_22_CS: Upgrade Charging Station Security Profile - Downgrade security profile - Rejected
+
+<table><tr><td>Test case name</td><td>Upgrade Charging Station Security Profile - Downgrade security profile - Rejected</td></tr><tr><td colspan="2">[...]</td></tr><tr><td>Description</td><td>The CSMS is able to change the connectionData at the Charging Station. It tries to downgrade the connection to a lower security profile 1.</td></tr><tr><td>Purpose</td><td>To verify if the Charging Station is able to reject downgrading to a lower security profile than the currently active security profile.1.</td></tr><tr><td>Prerequisite(s)</td><td>- The Test System connectionData configuration for SUT Charging Station only allows for ip addresses the Test System is able to bind.
+- The Charging Station supports security profile 2 and/or 3.
+- The second Test System connectionData configuration slot must be configured for a security profile lower than the first Test System connectionData configuration slot.
+- The Charging Station has a connection using security profile 2 or 3.
+- When starting this testcase the Test System will start another webSocket server for the second connectionData slot.</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The Test System sends a SetNetworkProfileRequest with: -configurationSlot is <ConfiguredConfigurationSlot> or <Configured configurationSlot> depending on which one is already in use - configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use - connectionData.messageTimeout <Configured messageTimeout2> - connectionData.ocppCsmsUrl <ocppCsmsUrl that is not currently active> - connectionData.ocpptInterface <Configured ocpptInterface2> - connectionData.ocppVersion OCPP20 -connectionData.securityProfile <Configured-securityProfile2> -connectionData.securityProfile 1</td></tr></table>
+
+# 6.2.12. Page 51 - (2025-02) - TC_B_16_CS - Correctly validate result of reading WriteOnly component variables
+
+<table><tr><td>Test case name</td><td>Get Custom Report - with component criteria</td></tr><tr><td>Test case Id</td><td>TC_B_16_CS</td></tr><tr><td>Use case Id(s)</td><td>B08</td></tr><tr><td>Requirement(s)</td><td>B08.FR.01, B08.FR.03, B08.FR.04, B08.FR.07, B08.FR.09, B089.FR.10, B08.FR.12, B08.FR.13, B08.FR.14, B06.FR.09</td></tr><tr><td colspan="2">[...]</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>[...]</td></tr><tr><td>* Step 6:
+Message: GetVariablesResponse with:
+For component variables where NotifyReportRequest.reportData variableAttribute.mutability from step 3 is not WriteOnly
+- attributeStatus = Accepted
+- attributeValue = true
+For component variables where NotifyReportRequest.reportData variableAttribute.mutability from step 3 is WriteOnly
+- attributeStatus = Rejected
+- attributeValue = <omitted></td></tr><tr><td>[...]</td></tr></table>
+
+# 6.2.13. Page 56 - (2024-09) - TC_B_20_CS - Added check on omitting evseld [4390]
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Charging Station - Without ongoing transaction - OnIdle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_20_CSMS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message ResetRequest
+- evseld must be omitted
+* Step 4:
+Message BootNotificationResponse
+- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.2.14. Page 57 - (2024-09) - TC_B_21_CS - Added check on omitting evseld [4390]
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Charging Station - With Ongoing Transaction - OnIdle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_21_CSMS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message ResetRequest
+- type OnIdle
+- evseld must be omitted
+* Step 8:
+Message BootNotificationResponse
+- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.2.15. Page 58 - (2024-09) - TC_B_22_CS - Added check on omitting evseld [4390]
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Charging Station - With Ongoing Transaction - Immediate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_22_CSMS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message ResetRequest
+- type Immediate
+- evseld is omitted
+* Step 6:
+Message BootNotificationResponse
+- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.2.16. Page 63 - (2025-02) - Changed reset to Immediate
+
+The reset in step #1 has been changed to "Immediate", because having a reservation pending is not an "idle" situation. As a result a Charging Station would respond with status "Scheduled" instead of resetting.
+
+<table><tr><td>Test case name</td><td>Reset Charging Station - Reserved persists reset</td></tr><tr><td>Test case Id</td><td>TC_B_24_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The Test System sends a ResetRequest with type Immediate</td></tr><tr><td colspan="2">...</td></tr></table>
+
+# 6.2.17. Page 72-81 - (2025-04) - TC_B_45_CS & TC_B_46_CS & TC_B_47_CS & TC_B_49_CS & TC_B_50_CS & TC_A_19_CS - Clarified NetworkProfile configurationSlot usage
+
+The Test system has two endpoints it is able to switch between. Depending on which one is active at the start of the testcase, it makes the SUT switch to the other endpoint.
+
+<table><tr><td>Test case name</td><td>Migrate to new ConnectionProfile - Success - Same CSMS Root</td></tr><tr><td>Test case Id</td><td>TC_B_45_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The Test System sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use - connectionData.messageTimeout <Configured messageTimeout> or <Configured messageTimeout2> - connectionData.ocppCsmsUrl <ocppCsmsUrl that is not currently active> - connectionData.ocpplInterface <Configured ocplInterface> or <Configured ocplInterface2> - connectionData.ocppVersion OCPP20 - connectionData.securityProfile <Configured securityProfile> or <Configured securityProfile2> Note(s): - The Test System checks the ActiveNetworkProfile variable to see which slot is currently active. - The Test System prevents overwriting the NetworkProfile at the active slot, as this is not recommended.</td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The Test System sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is <configurationSlot set at Step 1, the other configured configurationSlot></td></tr><tr><td colspan="2">...</td></tr><tr><td colspan="2">7. Execute Reusable State Booted</td></tr><tr><td colspan="2">Note(s): - The Charging Station connects to the slot configured at step 1.</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Migrate to new ConnectionProfile - Failback mechanism - Same CSMS Root</td></tr><tr><td>Test case Id</td><td>TC_B_46_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The Test System sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use
+- connectionData.messageTimeout <Configured messageTimeout> or <Configured messageTimeout2>
+- connectionData.ocppCsmsUrl <ocppCsmsUrl that is not currently active>
+- connectionData.ocpplInterface <Configured ocplInterface> or <Configured ocplInterface2>
+- connectionData.ocppVersion OCPP20
+- connectionData.securityProfile <Configured securityProfile> or <Configured securityProfile2></td></tr><tr><td></td><td>Note(s):
+- The Test System checks the ActiveNetworkProfile variable to see which slot is currently active.
+- The Test System prevents overwriting the NetworkProfile at the active slot, as this is not recommended.</td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The Test System sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is <configurationSlot set at Step 1, the other configured configurationSlot></td></tr><tr><td colspan="2">...</td></tr><tr><td colspan="2">9. Execute Reusable State Booted Note(s): - The Charging Station connects to the second slot configured at the NetworkConfigurationPriority at step 3.</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Migrate to new ConnectionProfile - Fallback after NetworkProfileConnectionAttempts per NetworkConfigurationPriority failed - New CSMS Root - New CSMS</td></tr><tr><td>Test case Id</td><td>TC_B_47_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td rowspan="2">2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The Test System sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use
+- connectionData.messageTimeout <Configured messageTimeout> or <Configured messageTimeout2>
+- connectionData.ocppCsmsUrl <ocppCsmsUrl that is not currently active>
+- connectionData.ocpplInterface <Configured ocppInterface> or <Configured ocppInterface2>
+- connectionData.ocppVersion OCPP20
+- connectionData.securityProfile <Configured securityProfile> or <Configured securityProfile2></td></tr><tr><td>Note(s):
+- The Test System checks the ActiveNetworkProfile variable to see which slot is currently active.
+- The Test System prevents overwriting the NetworkProfile at the active slot, as this is not recommended.</td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The Test System sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl"
+attributeValue is <configurationSlot set at Step 1, the other configured configurationSlot></td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Migrate to new ConnectionProfile - Failback after NetworkProfileConnectionAttempts per NetworkConfigurationPriority failed - Same CSMS Root</td></tr><tr><td>Test case Id</td><td>TC_B_49_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The Test System sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use - connectionData.messageTimeout <Configured messageTimeout> or <Configured messageTimeout2> - connectionData.ocppCsmsUrl <ocppCsmsUrl that is not currently active> - connectionData.ocpplInterface <Configured ocplInterface> or <Configured ocplInterface2> - connectionData.ocppVersion OCPP20 - connectionData.securityProfile <Configured securityProfile> or <Configured securityProfile2> Note(s): - The Test System checks the ActiveNetworkProfile variable to see which slot is currently active. - The Test System prevents overwriting the NetworkProfile at the active slot, as this is not recommended.</td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The Test System sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is <configurationSlot set at Step 1, the other configured configurationSlot></td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Migrate to new ConnectionProfile - Success - New CSMS Root - New CSMS</td></tr><tr><td>Test case Id</td><td>TC_B_50_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The Test System sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use - connectionData.messageTimeout <Configured messageTimeout> or <Configured messageTimeout2> - connectionData.ocppCsmsUrl <ocppCsmsUrl that is not currently active> - connectionData.ocpplInterface <Configured ocplInterface> or <Configured ocplInterface2> - connectionData.ocppVersion OCPP20 - connectionData.securityProfile <Configured securityProfile> or <Configured securityProfile2> Note(s): - The Test System checks the ActiveNetworkProfile variable to see which slot is currently active. - The Test System prevents overwriting the NetworkProfile at the active slot, as this is not recommended.</td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The Test System sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is <configurationSlot set at Step 1, the other configured configurationSlot></td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Upgrade Charging Station Security Profile - Accepted</td></tr><tr><td>Test case Id</td><td>TC_A_19_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The Test System sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use - connectionData.messageTimeout <Configured messageTimeout> - connectionData.ocppCsmsUrl <Configured ocppCsmsUrl> - connectionData.ocpptInterface <Configured ocpptInterface> - connectionData.ocppVersion OCPP20 - connectionData.securityProfile <Configured securityProfile + 1> Note(s): - The Test System checks the ActiveNetworkProfile variable to see which slot is currently active. - The Test System prevents overwriting the NetworkProfile at the active slot, as this is not recommended.</td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The Test System sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is <configurationSlot set at Step 1, the other configured configurationSlot></td></tr><tr><td colspan="2">...</td></tr></table>
+
+# 6.2.18. Page 72-81 - (2025-06) - TC_B_45_CS & TC_B_46_CS & TC_A_19_CS - ResetRequest will always be sent by the Test System to ensure the Charging Station switches NetworkProfile
+
+ResetRequest will always be sent by the Test System to ensure the Charging Station switches NetworkProfile.
+
+<table><tr><td>Test case Id</td><td>TC_B_45_CS / C_B_46_CS / TC_A_19_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td rowspan="2">6. The Charging Station responds with a ResetResponse</td><td>5. The Test System sends a ResetRequest with type Idle</td></tr><tr><td>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.</td></tr><tr><td colspan="2">...</td></tr></table>
+
+# 6.2.19. Page 85 - (2025-04) - TC_B_53_CS - Check if all required values are provided
+
+The testcase currently does not explicitly describe that the value fields for standardized component_variables should not be omitted (with EVSE.Power as an exception. For this only the maxLimit is required). These are optional at the JSON schema, because they are allowed to omit in case of WriteOnly variables.
+
+<table><tr><td>Test case name</td><td colspan="2">Get Base Report - Test mandatory DM variables via FullInventory</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_53_CS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">...</td></tr><tr><td colspan="2">Post scenario validations:
+The Test System checks that all implemented standardized components / variables are implemented correctly according to the OCPP specification:
+- The components / variables that are required according to the OCPP specification are implemented.
+- For each component/variable, where variableCharacteristics.dataType is set to OptionList, SequenceList or MemberList, the variableCharacteristics.valuesList is not omitted or empty.
+- For each component/variable, where variableCharacteristics.dataType is OptionList, SequenceList or MemberList, the variableAttribute.value is allowed based on the values in the provided variableCharacteristics.valuesList.
+- For variables with mutability set to WriteOnly the variableAttribute.value is omitted in the NotifyReportRequest.
+- For variables with mutability NOT set to WriteOnly the variableAttribute.value is NOT omitted in the NotifyReportRequest. There is one exception to this rule and that is for EVSE.Power. This variable only has a maxLimit .</td></tr></table>
+
+# 6.2.20. Page 89 - (2025-02) - Add setting of NetworkProfileConnectionAttempts
+
+TC_B_57_CS: Network Reconnection - After connection loss
+
+<table><tr><td>Test case name</td><td>Network Reconnection - After connection loss</td></tr><tr><td>Test case Id</td><td>TC_B_57_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>OCPPCommCtrletworkProfileConnectionAttempts is 3</td></tr><tr><td>OCPPCommCtrl.RetryBackOffRepeatTimes is 2</td></tr><tr><td>OCPPCommCtrl.RetryBackOffRandomRange is 0</td></tr><tr><td>OCPPCommCtrl.RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum></td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+# 6.2.21. Page 89/621 - (2025-04) - Addition of new testcase for CSMS to test WebSocket Subprotocol negotiation
+
+TC_B_58_CSMS: WebSocket Subprotocol negotiation
+
+<table><tr><td>Test case name</td><td>WebSocket Subprotocol validation</td></tr><tr><td>Test case Id</td><td>TC_B_58_CSMS</td></tr><tr><td>Use case Id(s)</td><td>Part 4 - JSON over WebSockets implementation guide</td></tr><tr><td>Requirement(s)</td><td>Section 3.1.2. OCPP version</td></tr><tr><td>System under test</td><td>CSMS</td></tr><tr><td>Description</td><td>OCPP-J imposes extra constraints on the WebSocket subprotocol, detailed in the following section 3.1.2.</td></tr><tr><td>Purpose</td><td>To verify whether the CSMS is able to select a supported OCPP version, when also a different unsupported version is supported by the Charging Station and relays this selection via the Sec-Websocket-Protocol header.</td></tr><tr><td>Prerequisite(s)</td><td>N/a</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Test System disconnects the WebSocket connection and reconnects by sending a HTTP upgrade request with the header;Sec-WebSocket-Protocol: ocpp0.1</td><td>2. The CSMS rejects the connection attempt and does NOT upgrade the connection to a WebSocket connection.</td></tr><tr><td>3. The Test System disconnects the WebSocket connection and reconnects by sending a HTTP upgrade request with the header;Sec-WebSocket-Protocol: ocpp0.1,ocpp<SelectedOCPP version></td><td>4. The CSMS accepts the connection attempt and upgrades the connection to a WebSocket connection.</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 4: The authorization header of the HTTP upgrade response must contain the header Sec-WebSocket-Protocol, and it must comply to the following:- The header is formatted as follows; Sec-WebSocket-Protocol: ocpp<Selected OCPP version></td></tr><tr><td>Post scenario validations:N/a</td></tr></table>
+
+# 6.2.22. Page 117/141 - (2025-02) - Added remote support for Authorization Cache & Local Authorization List testcases
+
+The CWG decided that online local authorization list and authorization cache testcase can also be tested with remote authorization.
+
+<table><tr><td>...</td><td>...</td></tr><tr><td>Test case Id</td><td>TC_C_08_CS, TC_C_09_CS, TC_C_10_CS, TC_C_11_CS, TC_C_12_CS, TC_C_13_CS, TC_C_33_CS, TC_C_34_CS, TC_C_36_CS, TC_C_37_CS, TC_C_38_CS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>-AuthCacheCtrl.Available is implemented with value true
+The Charging Station has an authorization cache AND
+the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32, C-34 OR supports at least one of the following remote start authorization options: C-36, C-37</td></tr></table>
+
+<table><tr><td>...</td><td>...</td></tr><tr><td>Test case Id</td><td>TC_C_57_CS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>-AuthCacheCtrl.Available is implemented with-value true
+-AuthCacheCtrl_DISABLEPostAuthorize is implemented
+AuthCacheCtrl_DISABLEPostAuthorize is implemented AND
+The Charging Station has an authorization cache AND
+the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32, C-34 OR supports at least one of the following remote start authorization options: C-36, C-37</td></tr></table>
+
+<table><tr><td>...</td><td>...</td></tr><tr><td>Test case Id</td><td>TC_C_27_CS, TC_C_28_CS, TC_C_29_CS, TC_C_30_CS, TC_C_31_CS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>- LocalAuthListCtrl.LocalAuthListAvailable is implemented with value true AND
+- The Charging Station must support an authorization method other than NoAuthorization or Central</td></tr></table>
+
+<table><tr><td>...</td><td>...</td></tr><tr><td>Test case Id</td><td>TC_C_58_CS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>- LocalAuthListCtrlr.Available is implemented with value true
+- LocalAuthListCtrlrDISABLEPostAuthorize is implemented AND
+- The Charging Station must support an authorization method other than NoAuthorization or Central</td></tr></table>
+
+<table><tr><td>...</td><td>...</td></tr><tr><td>Test case Id</td><td>TC_C_32_CS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>-The Charging Station supports the Authorization Cache feature
+-Authorization cache is stored in the non-volatile memory.
+The Charging Station has an authorization cache AND
+Authorization cache is stored in the non-volatile memory AND
+the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32, C-34 OR supports at least one of the following remote start authorization options: C-36, C-37</td></tr></table>
+
+<table><tr><td>Main (Test scenario)</td></tr><tr><td>Main steps have been updated to use the Reusable State Authorized based on the configured scenario Local or Remote.</td></tr><tr><td>...</td></tr></table>
+
+# 6.2.23. Page 101 - (2025-04) - TC_C_14_CS - Fixing invalid component variable reference
+
+<table><tr><td>Test case name</td><td>Authorization through authorization cache - GroupID equal to MasterPassGroupId.</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>AuthCacheCtrl.AuthCacheAvailable AuthCacheCtrl.Available is implemented with value true
+The Charging station supports MasterPass feature.
+The Charging Station supports authorization methods other than NoAuthorization</td></tr></table>
+
+# 6.2.24. Page 102 - (2025-04) - TC_C_15_CS - Fixing invalid component variable reference
+
+<table><tr><td>Test case name</td><td>Authorization through authorization cache - StopTxOnInvalidId = false, MaxEnergyOnInvalidId > 0</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>- AuthCacheCtrl.AuthCacheAvailable AuthCacheCtrl.Available is implemented with value true
+- The Charging Station has MaxEnergyOnInvalidId implemented
+- At least one of the following must be supported; Local auth list, auth cache, StartTxUnknownIds.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr></table>
+
+# 6.2.25. Page 104 - (2025-04) - TC_C_16_CS - Fixing invalid component variable reference
+
+<table><tr><td>Test case name</td><td>Authorization through authorization cache - StopTxOnInvalidId = true</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>- AuthCacheCtrl.AuthCacheAvailable AuthCacheCtrl.Available is implemented with value true
+- At least one of the following must be supported; Local auth list, auth cache, StartTxUnknownIds.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr></table>
+
+# 6.2.26. Page 105 - (2025-04) - TC_C_17_CS - Fixing invalid component variable reference
+
+<table><tr><td>Test case name</td><td>Authorization through authorization cache - StopTxOnInvalidId = false</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>- AuthCacheCtrl.AuthCacheAvailable AuthCacheCtrl.Available is implemented with value true
+- At least one of the following must be supported; Local auth list, auth cache, StartTxUnknownIds.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr></table>
+
+# 6.2.27. Page 108 - (2025-04) - TC_C_18_CS - Fixing invalid component variable reference
+
+<table><tr><td>Test case name</td><td>Authorization through authorization cache - StopTxOnInvalidId = true, MaxEnergyOnInvalidId > 0</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>- AuthCacheCtrl.AuthCacheAvailable AuthCacheCtrl.Available is implemented with value true
+- The Charging Station has MaxEnergyOnInvalidId implemented.
+- At least one of the following must be supported; Local auth list, auth cache, StartTxUnknownIds.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr></table>
+
+# 6.2.28. Page 120 - (2025-04) - TC_C_34_CS - Making use of the Deauthorized reusable state
+
+<table><tr><td>Test case name</td><td>Store Authorization Data in the Authorization Cache - Update on TransactionResponse</td></tr><tr><td>Test case Id</td><td>TC_C_34_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>AuthCacheEnabled is true (If implemented)</td></tr><tr><td>LocalPreauthorize is true</td></tr><tr><td>LocalAuthListEnabled is true</td></tr><tr><td>StopTxOnInvalidId is true</td></tr><tr><td>MaxEnergyOnInvalidId is 0</td></tr><tr><td>Memory State:
+IdTokenCached for <Configured valid IdToken fields></td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized (Cached idToken, idTokenInfo.status invalid)</td></tr><tr><td colspan="2">2. Execute Reusable State Deauthorized</td></tr><tr><td colspan="2">3. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">4. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">5. Execute Reusable State ParkingBayOccupied</td></tr><tr><td colspan="2">6. Execute Reusable State Authorized (idTokenInfo.status invalid)</td></tr></table>
+
+# 6.2.29. Page 128 - (2025-04) - TC_C_41_CS - Fixing invalid component variable reference
+
+<table><tr><td>Test case name</td><td>Authorization by Groupld - Success with Authorization Cache</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>- AuthCacheCtrlAuthCacheAvailable AuthCacheCtrl.Available is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr></table>
+
+# 6.2.30. Page 134 - (2025-04) - TC_C_44_CS - Fixing invalid component variable reference
+
+<table><tr><td>Test case name</td><td>Authorization by Groupld - Invalid status with Authorization Cache</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>- AuthCacheCtrlAuthCacheAvailable AuthCacheCtrl.Available is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr></table>
+
+# 6.2.31. Page 137 - (2025-04) - TC_C_46_CS - Fixing invalid component variable reference
+
+<table><tr><td>Test case name</td><td>Store Authorization Data in the Authorization Cache - AuthCacheLifeTime</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>- AuthCacheCtrl.AuthCacheAvailable AuthCacheCtrl.Available is implemented with value true
+- Configuration variable AuthCacheLifeTime is implemented</td></tr></table>
+
+# 6.2.32. Page 138 - (2024-09) - TC_C_47_CS - StoppedReason must be validated in Ended event [O20-4467]
+
+<table><tr><td>Test case name</td><td colspan="2">Stop Transaction with a Master Pass - With UI - All transactions</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_47_CS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Test case name</td><td>Stop Transaction with a Master Pass - With UI - All transactions</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+MessageauthorizeRequest
+-idToken.idToken <Configured masterpass_idtoken_idtoken>
+-idToken.type <Configured masterpass_idtoken_type>
+* Step 3:
+Message TransactionEventRequest
+- transactionInfo.stoppedReason MasterPass (in last TransactionEventRequest)
+-idToken omit or
+-idToken.idToken <Configured masterpass_idtoken_idtoken> and
+-idToken.type <Configured masterpass_idtoken_type> (once per stopped transaction)
+-eventType Ended (in last TransactionEventRequest)</td></tr><tr><td>Post scenario validations:
+-N/a</td></tr></table>
+
+# 6.2.33. Page 145 - (2025-04) - TC_C_25_CS - Fixing invalid component variable reference
+
+<table><tr><td>Test case name</td><td>Offline authorization through local authorization list - Local Authorization List > Authorization Cache</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Prerequisite(s)</td><td>- LocalAuthListCtrl.LocalAuthListAvailable is implemented with value true
+- AuthCacheCtrl.AuthCacheAvailable AuthCacheCtrl.Available is implemented with value true
+- OfflineTxForUnknownIdEnabled is implemented.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr></table>
+
+# 6.2.34. Page 146 - (2024-11) - TC_C_26_CS - Allow StatusNotification status = Occupied
+
+The connector status change should be reported after the connection is restored. The Charging Station should be allowed to report StatusNotificationRequest status = Occupied (or NotifyEventRequest).
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Periodic event</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_26_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C15 & C13</td></tr><tr><td>Requirement(s)</td><td colspan="2">C15.FR.02,C15.FR.06,C15.FR.08,C13.FR.04</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="7">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>1. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td>...</td><td>...</td></tr><tr><td colspan="2">3. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">4. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">5. Execute Reusable State EVDisconnected</td></tr><tr><td>Test case name</td><td>Set Variable Monitoring - Periodic event</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: StatusNotificationRequest
+- connectorStatus must be Occupied
+Message: NotifyEventRequest
+- eventData[0].trigger must be Delta
+- eventData[0].actualValue must be Occupied
+- eventData[0].component.name must be Connector
+- eventData[0].variable.name must be AvailabilityState
+...</td></tr><tr><td>Post scenario validations:
+N/A</td></tr></table>
+
+# 6.2.35. Page 147-153 - (2025-04) - TC_C_50_CS, TC_C_51_CS, TC_C_52_CS, TC_C_53_CS, TC_C_54_CS, TC_C_55_CS - Always re-install V2G certificates
+
+Note: This erratum revises erratum: Page 147 - (2025-02) - TC_C_50_CS and the related errata below
+
+It is not possible to detect whether all expected certificates are installed, when reusing the SubCAs. Therefore the Test System always re-installs the V2G certificates.
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Memory State:</td></tr><tr><td>CertificateInstalled for certificateType V2GRootCertificate</td></tr><tr><td>CertificateInstalled for certificateType MORootCertificate</td></tr><tr><td>RenewV2GChargingStationCertificate (If none are present, when checking with GetInstalledCertificates.certificateType = V2GCertificateChain)</td></tr></table>
+
+# 6.2.36. Page 147 - (2025-02) - TC_C_50_CS
+
+Note: This erratum and the related errata below are revised by erratum: Page 147-153 - (2025-04) - TC_C_50_CS, TC_C_51_CS, TC_C_52_CS, TC_C_53_CS, TC_C_54_CS, TC_C_55_CS - Always re-install V2G certificates
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>TxCtrl.RxStartPoint contains one or more of PowerPathClosed, Authorized, EVConnected, ParkingBayOccupancy</td></tr><tr><td>AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)</td></tr><tr><td>AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr><td>For the ISO15118Ctrl of the EVSE used in the PnC transaction:</td></tr><tr><td>ISO15118Ctrl.CentralContractValidationAllowed is false</td></tr><tr><td>ISO15118Ctrl.ContractCertificateInstallationEnabled is true</td></tr><tr><td>ISO15118Ctrl.V2GCertificateInstallationEnabled is true</td></tr><tr><td>ISO15118Ctrl.PnCEnowled is true</td></tr><tr><td>ISO15118Ctrl.Seeold is configured seeold</td></tr><tr><td>ISO15118Ctrl.CountryName is NL</td></tr><tr><td>ISO15118Ctrl.OrganizationName is configured vendorId</td></tr><tr><td>Memory State:</td></tr><tr><td>CertificatesInstalled for certificateType V2GRootCertificate</td></tr><tr><td>CertificatesInstalled for certificateType MORootCertificate</td></tr><tr><td>RenewV2GChargingStationCertificate (If none are present, when checking with GetInstalledCertificates.certificateType = V2GCertificateChain)</td></tr><tr><td>Reusable State(s):</td></tr><tr><td>State is EVConnectedPreSession</td></tr><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">[...]</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest Note(s): - This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy or (EVConnected, in the case this testcase was initiated from state EVConnectedPreSession.)</td><td>4. The Test System responds with a TransactionEventResponse With idTokenInfo.status Accepted</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr></table>
+
+# 6.2.37. Page 148 - (2025-02) - TC_C_51_CS
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>TxCtrl.TxStartPoint contains one or more of PowerPathClosed, Authorized, EVConnected, ParkingBayOccupancy</td></tr><tr><td>AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)</td></tr><tr><td>AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr><td>For the ISO15118Ctrl of the EVSE used in the PnC transaction:</td></tr><tr><td>ISO15118Ctrl.CentralContractValidationAllowed is false</td></tr><tr><td>ISO15118Ctrl.PnCEnabled is true</td></tr><tr><td>Memory State:</td></tr><tr><td>CertificateInstalled for certificateType V2GRootCertificate</td></tr><tr><td>CertificateInstalled for certificateType MORootCertificate</td></tr><tr><td>RenewV2GChargingStationCertificate (If none are present, when checking with GetInstalledCertificates.certificateType = V2GCertificateChain)</td></tr><tr><td>Reusable State(s):</td></tr><tr><td>State is EVConnectedPreSession</td></tr></table>
+
+# 6.2.38. Page 149 - (2025-02) - TC_C_52_CS
+
+# TC_C_52_CS: Authorization using Contract Certificates 15118 - Online - Central contract certificate validation - Accepted
+
+<table><tr><td>Test case name</td><td>Authorization using Contract Certificates 15118 - Online - Central contract certificate validation - Accepted</td></tr><tr><td>Test case Id</td><td>TC_C_52_CS</td></tr><tr><td>Use case Id(s)</td><td>C07</td></tr><tr><td>Requirement(s)</td><td>C07.FR.01,C07.FR.02,C07.FR.06</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>The Charging Station is able to authorize with contract certificates when it supports ISO 15118.</td></tr><tr><td>Purpose</td><td>To verify if the Charging Station is able to authorize, while not being able to locally validate the contract certificate and then send it to the CSMS.</td></tr><tr><td>Prerequisite(s)</td><td>- The V2G/MO Root certificate that is needed to validate the EV Contract certificate must NOT be installed at the Charging Station.- The Charging Station supports central contract validation.</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>TxCtrl.RxStartPoint contains one or more of PowerPathClosed, Authorized, EVConnected, ParkingBayOccupancy</td></tr><tr><td>AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)</td></tr><tr><td>AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr><td>For the ISO15118Ctrl of the EVSE used for the PnC transaction:</td></tr><tr><td>ISO15118Ctrl.CentralContractValidationAllowed is true</td></tr><tr><td>ISO15118Ctrl.ContractCertificateInstallationEnabled is true</td></tr><tr><td>ISO15118Ctrl.V2GCertificateInstallationEnabled is true</td></tr><tr><td>ISO15118Ctrl.PnCEnowled is true</td></tr><tr><td>ISO15118Ctrl.Seeold is configured seeeld</td></tr><tr><td>ISO15118Ctrl.CountryName is NL</td></tr><tr><td>ISO15118Ctrl.OrganizationName is configured vendorId</td></tr><tr><td>Memory State:</td></tr><tr><td>N/a- CertificateInstalled for certificateType V2GRootCertificate</td></tr><tr><td>RenewV2GChargingStationCertificate (If none are present, when checking with GetInstalledCertificates.certificateType = V2GCertificateChain)</td></tr><tr><td>Reusable State(s):</td></tr><tr><td>State is EVConnectedPreSession</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">[...]</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest Note(s): - This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy or (EVConnected, in the case this testcase was initiated from state EVConnectedPreSession.)</td><td>4. The Test System responds with a TransactionEventResponse With idTokenInfo.status Accepted</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr></table>
+
+# 6.2.39. Page 150 - (2025-02) - TC_C_53_CS
+
+TC_C_53_CS: Authorization using Contract Certificates 15118 - Online - Central contract validation fails
+
+<table><tr><td>Test case name</td><td>Authorization using Contract Certificates 15118 - Online - Central contract validation fails</td></tr><tr><td>Test case Id</td><td>TC_C_53_CS</td></tr><tr><td>Use case Id(s)</td><td>C07</td></tr><tr><td>Requirement(s)</td><td>N/a</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>The Charging Station is able to authorize with contract certificates when it supports ISO 15118.</td></tr><tr><td>Purpose</td><td>To verify if the Charging Station is able to handle an invalid contract certificate.</td></tr><tr><td>Prerequisite(s)</td><td>- The V2G/MO Root certificate that is needed to validate the EV Contract certificate must NOT be installed at the Charging Station.
+- The Charging Station supports central contract validation.</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>TxCtrl.RxStartPoint contains one or more of PowerPathClosed, Authorized, EVConnected, ParkingBayOccupancy</td></tr><tr><td>AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)</td></tr><tr><td>AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr><td>For the ISO15118Ctrl of the EVSE involved in the PnC transaction:</td></tr><tr><td>ISO15118Ctrl.CentralContractValidationAllowed is true</td></tr><tr><td>ISO15118Ctrl.PnCEnabled is true</td></tr><tr><td>Memory State:</td></tr><tr><td>N/a - CertificateInstalled for certificateType V2GRootCertificate</td></tr><tr><td>RenewV2GChargingStationCertificate (If none are present, when checking with GetInstalledCertificates.certificateType = V2GCertificateChain)</td></tr><tr><td>Reusable State(s):</td></tr><tr><td>State is EVConnectedPreSession</td></tr></table>
+
+# 6.2.40. Page 151 - (2024-09) - TC_C_54_CS - removed reusable state IdTokenCached [O20-3510]
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization using Contract Certificates 15118 - Offline - ContractValidationOffline is true</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_54_CS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="4">Before
+(Preparations)</td><td colspan="2">Configuration State:</td></tr><tr><td colspan="2">...</td></tr><tr><td colspan="2">Memory State: CertificateInstalled for certificateType V2GRootCertificate CertificateInstalled for certificateType MORootCertificate IdTokenCached for <Configured valid IdToken fields> (If implemented) IdTokenLocalAuthList for <Configured valid IdToken fields> (If implemented)</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td colspan="3">...</td></tr></table>
+
+# 6.2.41. Page 151 - (2025-02) - TC_C_54_CS
+
+<table><tr><td>Test case name</td><td>Authorization using Contract Certificates 15118 - Offline - ContractValidationOffline is true</td></tr><tr><td colspan="2">[...]</td></tr><tr><td>Description</td><td>The Charging Station is able to authorize with contract certificates when it supports ISO 15118. for an EMAID that exists in authorization cache or local authorization list, while offline.</td></tr><tr><td colspan="2">[...]</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>[...]</td></tr><tr><td>Memory State: CertificateInstalled for certificateType V2GRootCertificate CertificateInstalled for certificateType MORootCertificate RenewV2GChargingStationCertificate (If none are present, when checking with GetInstalledCertificates.certificateType = V2GCertificateChain ) IdTokenCached for <Configured valid IdToken fields> (If implemented) IdTokenLocalAuthList for <Configured valid IdToken fields> (If implemented)</td></tr><tr><td>Reusable State(s): N/a</td></tr><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">[...]</td></tr><tr><td>5. The Charging Station sends a TransactionEventRequest Note(s): - This step needs to be executed when TxStartPoint contains EVConnected OR the transaction already started -So in the case TxStartPoint contains ParkingBayOccupancy (in the case TxStartPoint contains ParkingBayOccupancy_)</td><td>6. The Test System responds with a TransactionEventResponse</td></tr><tr><td>7. The Charging Station sends a TransactionEventRequest Note(s): - This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy or EVConnected.</td><td>8. The Test System responds with a TransactionEventResponse With idTokenInfo.status Accepted</td></tr><tr><td colspan="2">9. Execute Reusable State EnergyTransferStarted</td></tr></table>
+
+# 6.2.42. Page 153 - (2024-09) - TC_C_55_CS - removed reusable state IdTokenCached [O20-3510]
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization using Contract Certificates 15118 - Offline - ContractValidationOffline is false</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_55_CS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="6">Before
+(Preparations)</td><td colspan="2">Configuration State:
+...</td></tr><tr><td colspan="2">Memory State:
+CertificateInstalled for certificateType V2GRootCertificate</td></tr><tr><td colspan="2">CertificateInstalled for certificateType MORootCertificate</td></tr><tr><td colspan="2">IdTokenCached for <Configured valid IdToken fields> (If implemented)</td></tr><tr><td colspan="2">IdTokenLocalAuthList for <Configured valid IdToken fields> (If implemented)</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td colspan="3">...</td></tr></table>
+
+# 6.2.43. Page 153 - (2025-02) - TC_C_55_CS
+
+<table><tr><td>Test case name</td><td>Authorization using Contract Certificates 15118 - Offline - ContractValidationOffline is false</td></tr><tr><td colspan="2">[...]</td></tr><tr><td>Description</td><td>The Charging Station is able to authorize with contract certificates when it supports ISO 15118. The Charging Station will not authorize with contract certificates when offline.</td></tr><tr><td colspan="2">[...]</td></tr><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>TxCtrl.TxStartPoint contains one or more of PowerPathClosed, Authorized, EVConnected, ParkingBayOccupancy</td></tr><tr><td>AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)</td></tr><tr><td>AuthCacheCtrl.Enabled is true OR LocalAuthListCtrl.Enabled is true</td></tr><tr><td>OfflineTxForUnknownIdEnabled is true (If implemented)</td></tr><tr><td>OfflineTxForUnknownIdEnabled is false (If implemented)</td></tr><tr><td>OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + 60.0</td></tr><tr><td>RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration></td></tr><tr><td>RetryBackOffRandomRange is 0</td></tr><tr><td>Note:</td></tr><tr><td><Configured RetryBackOffWaitMinimum_duration should be long enough to execute manual tasks></td></tr><tr><td>For the ISO15118Ctrlr of the EVSE involved in the PnC transaction:</td></tr><tr><td>ISO15118Ctrlr ContractValidationOffline is false</td></tr><tr><td>ISO15118Ctrlr.PnCEnabled is true</td></tr><tr><td>Memory State:</td></tr><tr><td>CertificatesInstalled for certificateType V2GRootCertificate</td></tr><tr><td>CertificatesInstalled for certificateType MORootCertificate</td></tr><tr><td>RnewV2GChargingStationCertificate (If none are present, when checking with GetInstalledCertificates.certificateType = V2GCertificateChain)</td></tr><tr><td>IdTokenCached for <Configured valid IdToken fields> (If implemented)</td></tr><tr><td>IdTokenLocalAuthList for <Configured valid IdToken fields> (If implemented)</td></tr><tr><td>Reusable State(s):</td></tr><tr><td>N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">[...]</td></tr><tr><td>5. The Charging Station sends a TransactionEventRequest Note(s): - This step needs to be executed when TxStartPoint contains EVConnected OR the transaction already started -So in the case TxStartPoint contains ParkingBayOccupancy (in the case TxStartPoint contains ParkingBayOccupancy_)</td><td>6. The Test System responds with a TransactionEventResponse</td></tr><tr><td colspan="2">[...]</td></tr></table>
+
+# 6.2.44. Page 165/169 - (2025-02) -
+
+# TC_E_01_CS/TC_E_09_CS/TC_E_10_CS/TC_E_12_CS/TC_E_13_CS - Extended the testcases until the Charging Station start charging
+
+This is needed to test the TransactionEventRequest with eventType Updated messages, while specific TxStartPoints are configured.
+
+<table><tr><td>Test case name</td><td>Start transaction options - PowerPathClosed</td></tr><tr><td>Test case Id</td><td>TC_E_01_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">2. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>Test case name</td><td>Start transaction options - EVConnected</td></tr><tr><td>Test case Id</td><td>TC_E_09_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">2. Execute Reusable State Authorized</td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Start transaction options - Authorized - Local</td></tr><tr><td>Test case Id</td><td>TC_E_10_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized (Local)</td></tr><tr><td colspan="2">2. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Start transaction options - ParkingBayOccupied</td></tr><tr><td>Test case Id</td><td>TC_E_12_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State ParkingBayOccupied</td></tr><tr><td colspan="2">2. Execute Reusable State Authorized</td></tr><tr><td colspan="2">3. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">4. Execute Reusable State EnergyTransferStarted</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Start transaction options - Authorized - Remote</td></tr><tr><td>Test case Id</td><td>TC_E_13_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized (Remote)</td></tr><tr><td colspan="2">2. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr></table>
+
+# 6.2.45. Page 174 - (2025-04) - TC_E_17_CS - Aligned configuration before steps with updated prerequisites
+
+Note: This erratum extends erratum: Page 174 - (2024-09) - TC_E_17_CS - Updated prerequisite for test case to correctly specify the applicable TxStopPoint combinations
+
+The prerequisite was updated, but the before configuration steps were not aligned with this change.
+
+<table><tr><td>Test case name</td><td>Stop transaction options - Deauthorized - EV side disconnect</td></tr><tr><td>Test case Id</td><td>TC_E_17_CS</td></tr><tr><td colspan="2">...</td></tr><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>If the mutability of TxStopPoint is ReadWrite then TxStopPoint contains PowerPathClosed AND/OR Authorized</td></tr><tr><td>StopTxOnEVSideDisconnect is true</td></tr><tr><td>UnlockOnEVSideDisconnect is false</td></tr><tr><td>AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)</td></tr><tr><td>AuthCtrl_DISABLERemoteAuthorization is false (If implemented)</td></tr></table>
+
+# 6.2.46. Page 174 - (2024-09) - TC_E_17_CS - Updated prerequisite for test case to correctly specify the applicable TxStopPoint combinations
+
+Note: This erratum is extended by erratum: Page 174 - (2025-04) - TC_E_17_CS - Aligned configuration before steps with updated prerequisites
+
+This testcase allows for a limited set of TxStopPoint combinations, otherwise it is not applicable.
+
+<table><tr><td>Test case name</td><td>Stop transaction options - Deauthorized - EV side disconnect</td></tr><tr><td>Test case Id</td><td>TC_E_17_CS</td></tr><tr><td colspan="2">...</td></tr><tr><td>Old: Prerequisite(s)</td><td>- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND the value Authorized OR PowerPathClosed is NOT set OR (EnergyTransfer OR DataSigned OR EVConnected is set).
+- If the mutability of TxStopPoint is _ReadWrite, then the value Authorized OR PowerPathClosed must be supported.</td></tr><tr><td>New: Prerequisite(s)</td><td>This testcase is applicable if the value Authorized is a supported value for TxStopPoint AND EVConnected, PowerPathClosed and EnergyTransfer must not be set as TxStopPoint AND StopTxOnEVSideDisconnect true must be a supported value.</td></tr></table>
+
+# 6.2.47. Page 176 - (2024-11) - TC_E_39_CS - Missing StatusNotificationRequest/NotifyEventRequest
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - Deauthorized - timeout</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_39_CS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE on EV side.</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE on EVSE side.</td></tr><tr><td>3. The Charging Station notifies the CSMS about the status change of the connector.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Test case name</td><td>Stop transaction options - Deauthorized - timeout</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: TransactionRequest
+- triggerReason must be EVConnectTimeout
+- eventType must be Updated if TxStartPoint is ParkingBayOccupancy, else Ended
+- transactionInfo.stoppedReason must be Timeout
+* Step 3:
+Message: StatusNotificationRequest
+- connectorStatus must be Occupied
+Message: NotifyEventRequest
+- eventData[0].trigger must be Delta
+- eventData[0].actualValue must be Occupied
+- eventData[0].component.name must be Connector
+- eventData[0].variable.name must be AvailabilityState
+* Step 5:
+Message: TransactionEventRequest
+- triggerReason can only be CablePluggedIn
+- transactionInfo.chagringState should not be Charging
+- eventType must be Updated if TxStartPoint is ParkingBayOccupancy, else Ended</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+# 6.2.48. Page 182 - (2025-04) - TC_E_52_CS - Testcase is not able to determine the authorization is refused in case TxStartPoint is not Authorized
+
+The testcase is not able to verify the authorization is refused when the TxStartPoint is not Authorized. Therefore the testcase is extended to also plugin the cable to determine whether the authorization was actually refused.
+
+<table><tr><td>Test case name</td><td>Local start transaction - Authorization first - DisableRemoteAuthorization</td></tr><tr><td>Test case Id</td><td>TC_E_52_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present an idToken which is not configured in the Local Authorization List nor present in Authorization Cache.</td></tr><tr><td>1. The Charging Station does NOT send aauthorizeRequest</td><td></td></tr><tr><td colspan="2">2. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">3. The Charging Station does NOT start charging.</td></tr></table>
+
+# 6.2.49. Page 185 - (2024-09) - TC_E_35_CS - StoppedReason must be validated in Ended event [O20-4467]
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - PowerPathClosed - Remote stop</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_35_CS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Test case name</td><td>Stop transaction options - PowerPathClosed - Remote stop</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message: RequestStopTransactionResponse
+- status must be Accepted
+* Step 3:
+Message: TransactionRequest
+- triggerReason must be RemoteStop (for one of the TransactionRequest)
+- transactionInfo.stoppedReason must be Remote (for the last TransactionRequest)
+-eventType must be Ended (for the last TransactionRequest)</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+# 6.2.50. Page 188 - (2025-02) - TC_E_22_CS - Stop transaction options - EnergyTransfer stopped - will end transaction
+
+When TxStopPoint is EnergyTransfer this will end transaction when EV suspends energy.
+
+TC_E_22_CS: Stop transaction options - EnergyTransfer stopped - SuspendedEV
+
+<table><tr><td>Test case name</td><td>Stop transaction options - EnergyTransfer stopped - SuspendedEV</td></tr><tr><td>Test case Id</td><td>TC_E_22_CS</td></tr><tr><td>..</td><td>..</td></tr></table>
+
+6.2.51. Page 189 - (2025-06) - TC_E_14_CS - StoppedReason validation too strict for remote
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message: TransactionRequest
+- 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 (if chargingState is EVConnected) -OR
+-eventType must be Updated (if chargingState is SuspendedEV)</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Stop transaction options - EVDisconnected - Charging Station side</td></tr><tr><td>Test case Id</td><td>TC_E_14_CS</td></tr><tr><td colspan="2">...</td></tr><tr><td>Tool validations</td></tr><tr><td>* Step 1:</td></tr><tr><td>Message: StatusNotificationRequest</td></tr><tr><td>- connectorStatus must be Available</td></tr><tr><td>Message: NotifyEventRequest</td></tr><tr><td>- eventData[0].trigger must be Delta</td></tr><tr><td>- eventData[0].actualValue must be Available</td></tr><tr><td>- eventData[0].component.name must be Connector</td></tr><tr><td>- eventData[0].variable.name must be AvailabilityState</td></tr><tr><td>* Step 3:</td></tr><tr><td>Message: TransactionEventRequest</td></tr><tr><td>- triggerReason must be EVCommunicationLost</td></tr><tr><td>- transactionInfo.chargingState must be Idle</td></tr><tr><td>- If the Test System is configured to stop transactions using a RequestStopTransactionRequest message then transactionInfo.stoppedReason must be Remote or EVDisconnected.</td></tr><tr><td>Else transactionInfo.stoppedReason must be Local, EVDisconnected or be omitted.</td></tr><tr><td>-/eventType must be Ended</td></tr><tr><td>Post scenario validations:</td></tr><tr><td>N/a</td></tr></table>
+
+# 6.2.52. Page 199 - (2025-04) - TC_E_27_CS - Remove manual action between step 4/5
+
+There seems to have been copy/paste errors between testcase TC_E_26_CS and TC_E_27_CS. The cable should not have been reconnected between these steps as we are trying to trigger the timeout.
+
+<table><tr><td>Test case name</td><td>Disconnect cable on EV-side - Suspend transaction - Fixed cable connection timeout</td></tr><tr><td>Test case Id</td><td>TC_E_27_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE on EV side (EVSE loses connection with EV).</td></tr><tr><td>1. The Charging Station sends a TransactionRequest</td><td>2. The Test System responds with a TransactionResponse</td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of the connector.Note(s):–This step needs to be executed when the Charging Station has a permanently attached cable on the Charging Station side.</td><td>4. The Test System responds accordingly.</td></tr><tr><td colspan="2">Manual Action: Reconnect the EV and EVSE on EV side.Note(s):–If the Charging Station has a permanently attached cable on the Charging Station side, then this step needs to be executed before the configured EVConnectionTimeout expires.</td></tr><tr><td>5. The Charging Station sends a TransactionRequest</td><td>6. The Test System responds with a TransactionResponse</td></tr><tr><td colspan="2">Note(s):–Optionally the Charging Station can send a StatusNotificationRequest or NotifyEventRequest with status Available</td></tr></table>
+
+# 6.2.53. Page 204 - (2025-02) - TC_E_31_CS - Add steps for when running the testcase in Remote mode
+
+As the Charging Station will go offline, the transaction must be stopped from EV side in case of remote authorization.
+
+# TC_E_31_CS: Check Transaction status - Transaction with id ended - with message in queue
+
+<table><tr><td>Test case name</td><td>Check Transaction status - Transaction with id ended - with message in queue</td></tr><tr><td>Test case Id</td><td>TC_E_31_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+# Before (Preparations)
+
+# Configuration State:
+
+···
+
+UnlockOnEVSideDisconnect is true (If ReadWrite)
+
+…
+
+# Main (Test scenario)
+
+<table><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td></td><td>The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Present the same idToken as used to start the transaction.
+Notes(s): Only if configured scenario is local</td></tr><tr><td colspan="2">Manual Action: Stop the energy transfer via the EV.
+Notes(s): Only if configured scenario is remote</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE.</td></tr><tr><td colspan="2">Manual Action: Drive EV out of parking bay. (Only needed if TxStopPoint is ParkingBayOccupancy)</td></tr><tr><td colspan="2">...</td></tr></table>
+
+# Tool validations
+
+···
+
+- Step 3:
+
+Message: TransactionEventRequest
+
+The tool validations from the reusable states need to be used to verify whether all required TransactionEventRequests have been received.
+
+From StopAuthorized through ParkingBayUnoccupied (in case of scenario Local).
+
+And from EnergyTransferSuspended through ParkingBayUnoccupied (in case of scenario Remote).
+
+Post scenario validations:
+
+N/a
+
+# 6.2.54. Page 214 - (2024-06) TC_E_43_CS Move reusable state TransactionEventsInQueueEnded to Before [768]
+
+State TransactionEventsInQueueEnded is moved to Before stage.
+
+Test Case Id: TC_E_43_CS
+
+<table><tr><td>Test case name</td><td>Offline Behaviour - Transaction during offline period</td></tr><tr><td>Test case Id</td><td>TC_E_43_CS</td></tr><tr><td>Use case Id(s)</td><td>E12</td></tr><tr><td>Requirement(s)</td><td>E12.FR.01,E12.FR.02,E12.FR.06</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>The Charging Station queues TransactionEvent messages to inform the CSMS that a transaction occurred while the Charging Station was Offline.</td></tr><tr><td>Purpose</td><td>To verify if the Charging Station is able to queue TransactionEvent messages while it was offline.</td></tr><tr><td>Prerequisite(s)</td><td>The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td>Test case name</td><td colspan="2">Offline Behaviour - Transaction during offline period</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is TransactionEventsInQueueEnded</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State TransactionEventsInQueueEnded</td></tr><tr><td>1. The Charging Stations sends a TransactionRequest
+Note(s):
+- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionRequest messages</td><td>2. The OCTT responds with a TransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+All messages: TransactionRequest
+-offline must be true
+One of the messages: TransactionRequest
+-eventType Started
+One of the messages: TransactionRequest
+-eventType Ended</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+# 6.2.55. Page 217 - (2025-04) - TC_E_46_CS - Testcase updated to use the specialized Authorized15118 reusable state
+
+Testcase updated to use the specialized Authorized15118 reusable state for starting the transaction, instead of the standard Authorized reusable state.
+
+<table><tr><td>Test case name</td><td>End of charging process 15118</td></tr><tr><td>Test case Id</td><td>TC_E_46_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+State is EVConnectedPreSession
+State is Authorized15118
+State is EnergyTransferStarted</td></tr></table>
+
+# 6.2.56. Page 221 - (2024-06) TC_F_04_CS Made mandatory in part 5, but prerequisite in part 6 was not updated
+
+Removed Prerequisite(s):
+
+<table><tr><td>Old</td><td>The Charging Station supports TxCtrl.TxStartPoint ParkingBayOccupancy OR Authorized.</td></tr><tr><td>New</td><td>N/a</td></tr></table>
+
+And added to Preparations:
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>- TxCtrl.TxStartPoint is ParkingBayOccupancy OR Authorized (If supported)</td></tr></table>
+
+# 6.2.57. Page 221 - (2025-02) TC_F_04_CS Prerequisite only if supported
+
+Update Preparation(s):
+
+Updated Preparations to only set TxStartPoint if supported:
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>- TxCtrl.TxStartPoint is ParkingBayOccupancy OR Authorized (If supported)</td></tr></table>
+
+# 6.2.58. Page 295 - (2024-09) - TC_J_XX_CS Meter Values
+
+Meter values cannot have location $=$ "EV", unless it is for measurand "SoC".
+
+For all test cases in J add the following Post scenario validation:
+
+<table><tr><td colspan="2">...</td></tr><tr><td rowspan="2">Tool validations</td><td>...</td></tr><tr><td>Post scenario validations:
+Message: MeterValuesRequest/TransactionRequest
+- ...
+- None of the provided sampledValues shall have location = EV, except when measurand = SoC.</td></tr></table>
+
+# 6.2.59. Page 236 - (2025-02) - TC_F_19_CS - The testcase ends while the firmware update is still ongoing
+
+Testcase TC_F_19_CS starts a firmware update and ends the testcase while it is still ongoing. This may cause problems for the next testcase, without proper cleanup. Therefore an invalid signature is given to prevent a full firmware update as this can take quite some time. These messages are then handled by the cleanup, but these described steps are not part of the scope of the testcase and therefore the SUT is unable to fail during these steps.
+
+<table><tr><td>Test case name</td><td>Trigger message - FirmwareStatusNotification - Downloading</td></tr><tr><td>Test case Id</td><td>TC_F_19_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponse</td><td>1. The Test System sends a UpdateFirmwareRequest firmware.location is <Configured firmware_location> firmware.retrieveDateTime is <Current dateTime - 2 hours> firmware.installDateTime is omitted firmware signingCertificate is <Configured signingCertificate> firmwaresignature is <Configured invalid firmware signature></td></tr><tr><td colspan="2">...</td></tr><tr><td colspan="2">Note : Step 9 through 14 are cleanup to prevent an ongoing firmware update after the testcase is already ended. The behavior part of these steps is part of TC_L_06_CS and therefore not part of the scope for this testcase.</td></tr><tr><td>9. The Charging Station sends a FirmwareStatusNotificationRequest . With status Downloaded</td><td>10. The Test System responds with a FirmwareStatusNotificationResponse .</td></tr><tr><td>11. The Charging Station sends a FirmwareStatusNotificationRequest . With status InvalidSignature</td><td>12. The Test System responds with a FirmwareStatusNotificationResponse .</td></tr><tr><td>13. The Charging Station sends a SecurityEventNotificationRequest . With type Invalid FirmwareSignature</td><td>14. The Test System responds with a SecurityEventNotificationResponse .</td></tr></table>
+
+# 6.2.60. Page 272 - (2025-02) - TC_H_08_CS Reserve an unspecified EVSE - Accepted
+
+Wrong token was used for RequestStartTransaction.
+
+TC_H_08_CS: Reserve an unspecified EVSE - Accepted
+
+<table><tr><td>Test case name</td><td>Reserve an unspecified EVSE - Accepted</td></tr><tr><td>Test case Id</td><td>TC_H_08_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>…</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td colspan="2">5. Execute Reusable State AuthorizedNote(s):- <Configured valid_idtoken_idtoken> is used for the authorization.</td></tr><tr><td colspan="2">...</td></tr><tr><td>Tool validations</td></tr><tr><td>* Step 2:Message: ReserveNowResponse- status must be Accepted* Step 3: (Optional)Message: StatusNotificationRequest- connectorStatus must be Reserved-evseld must be <Configured evseld> - connectorld must be <Configured connectorld>Message: NotifyEventRequest- trigger must be Delta-actualValue must be "Reserved"- component.name must be "Connector"- evse.id must be <Configured evseld>- eyesconnectorld must be <Configured connectorld>- variable.name must be "AvailabilityState"(Optional)Message: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Available-eventData[0].component.name must be EVSE-eventData[0].variable.name must be AvailabilityState</td></tr><tr><td>Post scenario validations:N/a</td></tr></table>
+
+# 6.2.61. Page 279/280 - (2025-06) - TC_H_15_CS & TC_H_16_CS can only be executed when the connector type of the Charging Station is part of the connectorEnumType.
+
+The ConnectorEnumType list does not contain all connectorTypes. At OCPP 2.1 this enum has been changed to a string and can be extended, however this is not possible for OCPP 2.0.1. Therefore the reservation of connectorType testcases will not work for connectorTypes that are not part of the enum. It is not a major issue, because the CSMS can always reserve a specific EVSE based on the connectorTypes specified at the device model.
+
+<table><tr><td>Test case name</td><td>Reserve a connector with a specific type - Success</td></tr><tr><td>Test case Id</td><td>TC_H_15_CS</td></tr><tr><td>Prerequisite(s)</td><td>- The configuration variable ReservationCtrl.ReservationAvailable is implemented with value true
+- The Charging Station supports the reservation of a specific connector type, that is part of the ConnectorEnumType.</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Reserve a connector with a specific type - Amount of available connectors of a type equals the amount of reservations</td></tr><tr><td>Test case Id</td><td>TC_H_16_CS</td></tr><tr><td>Prerequisite(s)</td><td>- The configuration variable ReservationCtrlr.ReservationAvailable is implemented with value true
+- The Charging Station supports the reservation of a specific connector type, that is part of the ConnectorEnumType.</td></tr></table>
+
+# 6.2.62. Page 282 - (2025-02) - TC_H_17_CS - made more explicit on what to validate
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:Message: CancelReservationResponse - status must be Accepted * Step 3:For each connector on the <Configured evseld> one of the following messages must be sent:Message: StatusNotificationRequest - connectorStatus must be Available - evseld must be <Configured evseld> - connectorld must be <Configured connectorld>Message: NotifyEventRequest - trigger must be Delta - actualValue must be "Available" - component.name must be "Connector" - evse.id must be <Configured evseld> - eyesconnectorld must be <Configured connectorld> - variable.name must be "AvailabilityState"</td></tr><tr><td>Post scenario validations: N/a</td></tr></table>
+
+# 6.2.63. Page 297 - (2025-02) - TC_J_02_CS Clock-aligned Meter Values - reporting multiple phases
+
+An erratum was added on adding support for validating reporting measurands on multiple phases: TC_J_02_CS Clock-aligned Meter Values (2024-09). However the validation is too strict, so this erratum supersedes it. Reporting measurands per phase must be done, when the energy meter supports it and it is applicable for the specified measurand.
+
+<table><tr><td>Test case name</td><td colspan="2">Clock-aligned Meter Values - Transaction ongoing</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J01</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AlignedDataInterval is <Configured clock-aligned Meter Values interval>
+AlignedDataSendDuringIdle is false (If implemented)
+RegisterValuesWithoutPhases is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">Note: The following steps do not need to be sent in a specific order.
+* Step 1:
+Message: MeterValuesRequest
+- meterValue[0].sampledValue[0].context must be Sample.Circle
+- meterValue[0].sampledValue must contain <An element per configured measurand at the
+AlignedDataMeasurands>
+Notes :
+- The measurand field may be omitted when the measurand is "Energy.Active.Import.Register"
+- It is possible that measurands are reported on multiple locations or phases, based on the capabilities of the
+energy meter.
+* Step 3:
+Message: TransactionEventRequest
+- triggerReason must be MeterValueClock
+- metervalue[0].sampledValue[0].context must be Sample.Circle
+- metervalue[0].sampledValue must contain <An element per configured measurand at the
+AlignedDataMeasurands>
+Notes :
+- The measurand field may be omitted when the measurand is "Energy.Active.Import.Register"
+- It is possible that measurands are reported on multiple locations or phases, based on the capabilities of the
+energy meter.</td></tr><tr><td colspan="2">Post scenario validations:
+...</td></tr></table>
+
+# 6.2.64. Page 297 - (2024-09) - TC_J_02_CS Clock-aligned Meter Values
+
+Meter values must be reported for all phases.
+
+<table><tr><td>Test case name</td><td>Clock-aligned Meter Values - Transaction ongoing</td></tr><tr><td>Test case Id</td><td>TC_J_02_CS</td></tr><tr><td>Use case Id(s)</td><td>J01</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Clock-aligned Meter Values - Transaction ongoing</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:AlignedDataInterval is <Configured clock-aligned Meter Values interval>AlignedDataSendDuringIdle is false (If implemented)RegisterValuesWithoutPhases is false (If implemented)</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">Note: The following steps do not need to be sent in a specific order.* Step 1:Message: MeterValuesRequest-meterValue[0].sampledValue[0].context must be Sample.Circle-meterValue[0].sampledValue must contain <An element per configured measurand at theAlignedDataMeasurands for the number of phases reported in SupplyPhases. The measurand field may be omitted when the measurand is "Energy.Active.Import.Register">* Step 3:Message: TransactionEventRequest-triggerReason must be MeterValueClock-metervalue[0].sampledValue[0].context must be Sample.Circle-metervalue[0].sampledValue must contain <An element per configured measurand at theAlignedDataMeasurands for the number of phases reported in SupplyPhases. The measurand field may be omitted when the measurand is "Energy.Active.ImportREGISTER"></td></tr><tr><td colspan="2">Post scenario validations:...</td></tr></table>
+
+# 6.2.65. Page 306 - (2024-06) - TC_J_10_CS - Remove reference to non-existing requirements [4697]
+
+<table><tr><td>Test case name</td><td>Sampled Meter Values - EventType Ended</td></tr><tr><td>Test case Id</td><td>TC_J_10_CS</td></tr><tr><td>Use case Id(s)</td><td>J02 & (E06,E07,E08,E09,E10,E12)</td></tr><tr><td>Requirement(s)</td><td>J02.FR.01,J02.FR.02,J02.FR.03,J02.FR.04,J02.FR.10, E06.FR.11, E06.FR.17, E07.FR.08, E07.FR.13,E08.FR.09,E09.FR.05,E10.FR.04,E12.FR.07</td></tr><tr><td colspan="2">...</td></tr></table>
+
+# 6.2.66. Page 318 - (2025-04) TC_K_09_CS: Removed validFrom/To from test
+
+<table><tr><td>Test case name</td><td>Clear Charging Profile - Clearing a TxDefaultProfile - With ongoing transaction</td></tr><tr><td>Test case Id</td><td>TC_K_09_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+SmartChargingCtrl.LimitChangeSignificance is 1.0</td></tr><tr><td>Memory State:</td></tr><tr><td>SetChargingProfile with</td></tr><tr><td>ChargingProfile 1:</td></tr><tr><td>chargingProfilePurpose is TxDefaultProfile</td></tr><tr><td>chargingProfileKind should be Absolute</td></tr><tr><td>stackLevel should be 0</td></tr><tr><td>evseld <Configured evseld></td></tr><tr><td>validFrom <currentDateTime><Configured max time deviation> seconds></td></tr><tr><td>validTo <currentDateTime><Configured max time deviation> + 401 seconds></td></tr><tr><td>startSchedule <currentDateTime></td></tr><tr><td>numberPhases <Configured numberPhases></td></tr><tr><td>ChargingSchedule:</td></tr><tr><td>duration 400 + <Configured max time deviation></td></tr><tr><td>...</td></tr></table>
+
+# 6.2.67. Page 343 - (2025-04) TC_K_23_CS: Removed validFrom/To from test
+
+<table><tr><td>Test case name</td><td>Set Charging Profile - StartSchedule</td></tr><tr><td>Test case Id</td><td>TC_K_23_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The Test System sends a SetChargingProfileRequest with chargingProfile.chargingProfilePurpose is TxDefaultProfile chargingProfile.chargingProfileKind is Absolute evseld <configured evseld> chargingProfile.validFrom <current dateTime><Configured max time deviation> + 50 seconds> chargingProfile.validTo <current dateTime><Configured max time deviation> + 400 seconds> chargingProfile.chargingSchedule[0].startSchedule <current dateTime> + 60 seconds> chargingProfile.chargingSchedule[0].chargingSchedulePeriod[]. numberPhases <Configured numberPhases> chargingProfile.chargingSchedule[0].chargingSchedulePeriod[]. startPeriod 0 chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0 ].limit 6 * <limit multiplier> Note: Check [csKSmartChargingChargingProfileLimits] for <limit multiplier></td></tr><tr><td>...</td><td>...</td></tr></table>
+
+# 6.2.68. Page 337 - (2025-04) TC_K_28_CS: Removed validFrom/To from test
+
+<table><tr><td>Test case name</td><td>Set Charging Profile - TxDefaultProfile with transaction ongoing</td></tr><tr><td>Test case Id</td><td>TC_K_28_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The Test System sends a SetChargingProfileRequest with chargingProfile.chargingProfilePurpose is TxDefaultProfile chargingProfile.chargingProfileKind is Absolute chargingProfile.chargingSchedule[0].duration is <400 + <Configured max time deviation> seconds> evseld <Configured evseld> chargingProfile.validFrom <current dateTime - <Configured max time deviation> seconds> chargingProfile.validTo <current dateTime + <Configured max time deviation> + 401 seconds> chargingProfile.chargingSchedule[0].startSchedule <current dateTime - <Configured max time deviation> seconds> chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0 ].numberPhases <Configured numberPhases> chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0 ].startPeriod 0 chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0 ].limit 6 * <limit multiplier> ...</td></tr></table>
+
+# 6.2.69. Page 345 - (2025-02) TC_K_XX_CS: Use realistic values for composite schedules
+
+In order to use realistic limits for charging profiles, the limit of a charging profile will be determined by <Configured chargingRateUnit> and <Configured numberPhases>.
+
+# Added new section to section K Smart Charging
+
+# Determine Charging Profile Limit Multiplier
+
+Not all chargers support setting limits in A or W. This can be configured with the configuration variable <ConfiguredchargingRateUnit>. To calculate the limit to be used, the following rules must be followed:
+
+If <Configured chargingRateUnit> is A, then <limit multiplier> is 1
+
+If <Configured chargingRateUnit> is W and <Configured numberPhases> is 1, then <limit multiplier> is 230
+
+If <Configured chargingRateUnit> is W and <Configured numberPhases> is 2, then <limit multiplier> is 460
+
+If <Configured chargingRateUnit> is W and <Configured numberPhases> is 3, then <limit multiplier> is 690
+
+# Example 1
+
+Given a test case is configured with:
+
+<Configured chargingRateUnit> W
+
+<Configured numberPhases> 2
+
+When the test case specifies:
+
+chargingProfile.chargingSchedule.chargingSchedulePeriodlimit 6 \* <limit multiplier>
+
+Then it should set
+
+chargingProfile.chargingSchedule.chargingSchedulePeriodlimit 2760
+
+Example 2
+
+Given a test case is configured with:
+
+<Configured chargingRateUnit> A
+
+<Configured numberPhases> 3
+
+When the test case specifies:
+
+chargingProfile.chargingSchedule.chargingSchedulePeriodlimit 6 \* <limit multiplier>
+
+Then it should set
+
+chargingProfile.chargingSchedule.chargingSchedulePeriodlimit 6
+
+# All test cases using limits are updated
+
+<table><tr><td>Test case name</td><td>[...]</td></tr><tr><td>Test case Id</td><td>TC_K_01_CS / TC_K_03_CS / TC_K_04_CS / TC_K_09_CS / TC_K_10_CS / TC_K_13_CS / TC_K_21_CS / TC_K_22_CS / TC_K_23_CS / TC_K_28_CS / TC_K_60_CS / TC_K_37_CS / TC_K_38_CS / TC_K_40_CS / TC_K_41_CS / TC_K_56_CS / TC_K_58_CS</td></tr><tr><td colspan="2">[...]</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>[...]</td><td>[...]Replace all *.limit assignments with:*.limit ? * <limit multiplier>Note: Check [csKSmartChargingChargingProfileLimits] for <limit multiplier></td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+Replace all *.limit validations with:
+*.limit <?> * <limit multiplier></td></tr><tr><td>Note: Check [csKSmartChargingChargingProfileLimits] for <limit multiplier></td></tr><tr><td>Post scenario validations:
+[...]</td></tr></table>
+
+# 6.2.70. Page 345 - (2024-06) TC_K_35_CS Get Charging Profile - Evseld > 0 + chargingProfilePurpose [773]
+
+Change initial charging state from "N/A" to:
+
+<table><tr><td colspan="2">Charging State:
+State is EnergyTransferStarted</td></tr></table>
+
+# 6.2.71. Page 352 - (2025-04) - TC_K_39_CS - Validation of scheduleStart
+
+<table><tr><td>Test case name</td><td>Get Composite Schedule - No ChargingProfile installed on Charging Station</td></tr><tr><td>Test case Id</td><td>TC_K_39_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+(Message: GetCompositeScheduleResponse)
+status Accepted
+evseld 0</td></tr><tr><td>scheduleStart <The time the GetCompositeScheduleRequest was transmitted +/- <Configured max time deviation>></td></tr><tr><td>duration is 300</td></tr><tr><td>chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td>startPeriod 0</td></tr><tr><td>Post scenario validations:</td></tr><tr><td>...</td></tr></table>
+
+# 6.2.72. Page 353 - (2025-04) - TC_K_40_CS: startSchedule improvements
+
+Now using same startSchedule time for both profiles.
+
+<table><tr><td>Test case name</td><td>Get Composite Schedule - Stacking ChargingProfiles</td></tr><tr><td>Test case Id</td><td>TC_K_40_CS</td></tr><tr><td>Use case Id(s)</td><td>K08</td></tr><tr><td>Requirement(s)</td><td>K08.FR.02,K08.FR.06</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>The CSMS requests a composite schedule which is a combination of local limits and the prevailing Charging Profiles of the different chargingProfilePurposes and stack levels.
+2 ChargingProfiles with same startSchedule and different stackLevels are submitted.</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:</td></tr><tr><td>set <startScheduleTime> = <current dateTime> - <Configured max time deviation></td></tr><tr><td>SetChargingProfile with</td></tr><tr><td>ChargingProfile 1:</td></tr><tr><td>chargingProfilePurpose is TxDefaultProfile</td></tr><tr><td>chargingProfileKind should be Absolute</td></tr><tr><td>stackLevel should be 0</td></tr><tr><td>evseld <Configured evseld></td></tr><tr><td>validFrom <current dateTime> <Configured max time deviation> seconds></td></tr><tr><td>validTo <current dateTime + <Configured max time deviation> + 401 seconds></td></tr><tr><td>startSchedule <startScheduleTime></td></tr><tr><td>numberPhases <Configured numberPhases></td></tr><tr><td>ChargingSchedule:</td></tr><tr><td>duration 400 <Configured max time deviation></td></tr><tr><td>chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td>startPeriod 0, limit 6 * <limit multiplier></td></tr><tr><td>startPeriod 100, limit 8 * <limit multiplier></td></tr><tr><td>startPeriod 200, limit 10 * <limit multiplier></td></tr><tr><td>Note: Check [csKSmartChargingChargingProfileLimits] for <limit multiplier></td></tr><tr><td>ChargingProfile 2:</td></tr><tr><td>chargingProfilePurpose is TxDefaultProfile</td></tr><tr><td>chargingProfileKind should be Absolute</td></tr><tr><td>stackLevel should be 1</td></tr><tr><td>evseld <Configured evseld></td></tr><tr><td>validFrom <current dateTime> <Configured max time deviation> seconds></td></tr><tr><td>validTo <current dateTime + <Configured max time deviation> + 401 seconds></td></tr><tr><td>startSchedule <startScheduleTime></td></tr><tr><td>numberPhases <Configured numberPhases></td></tr><tr><td>ChargingSchedule:</td></tr><tr><td>duration 150 <Configured max time deviation></td></tr><tr><td>chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td>startPeriod 0, limit 7 * <limit multiplier></td></tr><tr><td>Note: Check [csKSmartChargingChargingProfileLimits] for <limit multiplier></td></tr><tr><td>startPeriod 100, limit 9 * <limit multiplier></td></tr><tr><td>Note: Check [csKSmartChargingChargingProfileLimits] for <limit multiplier></td></tr><tr><td>Reusable State(s):</td></tr><tr><td>N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetCompositeScheduleResponse</td><td>1. The Test System sends a GetCompositeScheduleRequest with evseld <Configured evseld>
+duration is 350
+chargingRateUnit <Configured chargingRateUnit></td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+(Message: GetCompositeScheduleResponse)
+status Accepted
+evseld <Configured evseld>
+ChargingSchedule:
+duration 350
+chargingRateUnit <Configured chargingRateUnit>
+scheduleStart <The time the GetCompositeScheduleRequest was transmitted> plus/minus <Configured max time deviation>
+Note: The period of time between the scheduleStart from the SetChargingProfileRequest with ChargingProfile 2 and the scheduleStart from the GetCompositeScheduleResponse is called x.
+Note: The period of time between the scheduleStart from the SetChargingProfileRequest with ChargingProfile 1 and the scheduleStart from the GetCompositeScheduleResponse is called y-
+startPeriod 0, limit 7 * <limit multiplier> ( stackLevel 1 )
+startPeriod (100 - x), limit 9 * <limit multiplier> ( stackLevel 1 )
+startPeriod (150 - x + <Configured max time deviation>, limit 8 * <limit multiplier> ( stackLevel 0 )
+startPeriod (200 - x), limit 10 * <limit multiplier> ( stackLevel 0 )
+Note: Check [csKSmartChargingChargingProfileLimits] for <limit multiplier></td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+# 6.2.73. Page 355 - (2025-04) - TC_K_41_CS: startSchedule improvement
+
+<table><tr><td>Test case name</td><td>Get Composite Schedule - Combining chargingProfilePurposes</td></tr><tr><td>Test case Id</td><td>TC_K_41_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+set <startScheduleTime> = <current dateTime> - <Configured max time deviation> seconds</td></tr><tr><td>Note: Set MaxProfile for the next 24 hours:
+SetChargingProfile with
+ChargingProfile 1:
+chargingProfilePurpose is ChargingStationMaxProfile
+chargingProfileKind should be Absolute
+stackLevel should be 0
+evseld 0
+startSchedule <startScheduleTime>
+numberPhases <Configured numberPhases>
+ChargingSchedule:
+duration 86400
+chargingRateUnit <Configured chargingRateUnit>
+startPeriod 0, limit 10 * <limit multiplier>
+Note: Check [csKSmartChargingChargingProfileLimits] for <limit multiplier></td></tr><tr><td colspan="2">Before (Preparations)</td></tr><tr><td>Note: Set a default profile for 300 seconds</td><td>Note: set a TxProfile for 260 seconds:</td></tr><tr><td>ChargingProfile 2:</td><td>ChargingProfile 3:</td></tr><tr><td>chargingProfilePurpose is TxDefaultProfile</td><td>chargingProfilePurpose is TxProfile</td></tr><tr><td>chargingProfileKind should be Absolute</td><td>chargingProfileKind should be Absolute</td></tr><tr><td>stackLevel should be 0</td><td>stackLevel should be 0</td></tr><tr><td>evseld <Configured evseld></td><td>evseld <Configured evseld></td></tr><tr><td>validFrom <currentDateTime><Configured max time deviation></td><td>validFrom <currentDateTime><Configured max time deviation></td></tr><tr><td>seconds></td><td>seconds></td></tr><tr><td>validTo <currentDateTime><Configured max time deviation> + 401 seconds></td><td>validTo <currentDateTime><Configured max time deviation> + 401 seconds></td></tr><tr><td>startSchedule <startScheduleTime></td><td>startSchedule <startScheduleTime></td></tr><tr><td>numberPhases <Configured numberPhases></td><td>numberPhases <Configured numberPhases></td></tr><tr><td>ChargingSchedule:</td><td>ChargingSchedule:</td></tr><tr><td>duration 300</td><td>duration 260</td></tr><tr><td>chargingRateUnit <Configured chargingRateUnit></td><td>chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td>startPeriod 0,60,120,180,260, limit 6,10,8,15,8 * <limit multiplier></td><td>startPeriod 0,50,140,200,240, limit 8,11,16,6,12 * <limit multiplier></td></tr><tr><td>Note: Check [csKSmartChargingChargingProfileLimits] for <limit multiplier></td><td>Note: Check [csKSmartChargingChargingProfileLimits] for <limit multiplier></td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+(Message: GetCompositeScheduleResponse)</td></tr><tr><td>status Accepted</td></tr><tr><td>evseld <Configured evseld></td></tr><tr><td>ChargingSchedule:</td></tr><tr><td>duration 400</td></tr><tr><td>chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td>scheduleStart <The time the GetCompositeScheduleRequest was transmitted +/- <Configured max time deviation>></td></tr><tr><td>Note: The period of time between the scheduleStart from the SetChargingProfileRequest with ChargingProfile 3 and the scheduleStart from the GetCompositeScheduleResponse is called x.</td></tr><tr><td>Note: The period of time between the scheduleStart from the SetChargingProfileRequest with ChargingProfile 2 and the scheduleStart from the GetCompositeScheduleResponse is called y.</td></tr><tr><td>startPeriod 0, limit 8 * <limit multiplier> (TxProfile)</td></tr><tr><td>startPeriod (50 - x), limit 10 * <limit multiplier> (ChargingStationMaxProfile)</td></tr><tr><td>startPeriod (200 - x), limit 6 * <limit multiplier> (TxProfile)</td></tr><tr><td>startPeriod (240 - x), limit 10 * <limit multiplier> (ChargingStationMaxProfile)</td></tr><tr><td>startPeriod (260 - x), limit 8 * <limit multiplier> (TxDefaultProfile)</td></tr><tr><td>startPeriod (300 - x), limit 10 * <limit multiplier> (ChargingStationMaxProfile)</td></tr><tr><td>Note: Check [csKSmartChargingChargingProfileLimits] for <limit multiplier></td></tr><tr><td>Post scenario validations:</td></tr><tr><td>N/a</td></tr></table>
+
+# 6.2.74. Page 354/355 - (2025-02) - TC_K_40_CS & TC_K_41_CS - Updated composite schedule validation
+
+The startPeriod validation did not take the (to the duration added) <configured max time deviation> into account.
+
+<table><tr><td>Test case name</td><td>Get Composite Schedule - Stacking ChargingProfiles</td></tr><tr><td>Test case Id</td><td>TC_K_40_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+(Message: GetCompositeScheduleResponse)
+status Accepted
+evseld <Configured evseld>
+ChargingSchedule:
+duration 350
+chargingRateUnit <Configured chargingRateUnit>
+scheduleStart <The time the GetCompositeScheduleRequest was transmitted \+/- <Configured max time deviation>>
+Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.
+Note: The period of time between sending the second SetChargingProfileRequest and the scheduleStart from the
+GetCompositeScheduleResponse is called x:
+-Note: The period of time between the scheduleStart from the SetChargingProfileRequest with ChargingProfile 3 and the
+scheduleStart from the GetCompositeScheduleResponse is called x:
+Note: The period of time between the scheduleStart from the SetChargingProfileRequest with ChargingProfile 2 and the
+scheduleStart from the GetCompositeScheduleResponse is called y:
+startPeriod 0, limit 7
+startPeriod (100-x), limit 9
+startPeriod (150-x)
+startPeriod-(200-x), limit 10
+startPeriod 0, limit 8
+startPeriod (50-x), limit 10
+startPeriod (200-x), limit 6
+startPeriod (240-x), limit 10
+startPeriod (260-x + <Configured max time deviation>), limit 8 (TxDefaultProfile)
+startPeriod (300-y + <Configured max time deviation>), limit 10 (ChargingStationMaxProfile)</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Get Composite Schedule - Combining chargingProfilePurposes</td></tr><tr><td>Test case Id</td><td>TC_K_41_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+SetChargingProfile with
+ChargingProfile 1:
+chargingProfilePurpose is ChargingStationMaxProfile
+chargingProfileKind should be Absolute
+stackLevel should be 0
+evseld 0
+startSchedule <currentDateTime - <Configured max time deviation> seconds>
+numberPhases <Configured numberPhases>
+ChargingSchedule:
+duration <86400 <Configured max time deviation> seconds>
+chargingRateUnit <Configured chargingRateUnit>
+Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.
+startPeriod 0, limit 10</td></tr><tr><td colspan="2">Before (Preparations)</td></tr><tr><td>ChargingProfile 2:
+chargingProfilePurpose is TxDefaultProfile
+chargingProfileKind should be Absolute
+stackLevel should be 0
+evseld <Configured evseld>
+validFrom <currentDateTime - <Configured max time deviation>
+seconds>
+validTo <currentDateTime + <Configured max time deviation> +
+401 seconds>
+startSchedule <currentDateTime - <Configured max time
+deviation> seconds>
+numberPhases <Configured numberPhases>
+ChargingSchedule:
+duration <300 <Configured max time deviation> seconds>
+chargingRateUnit <Configured chargingRateUnit>
+Note: If <Configured chargingRateUnit> is W, then the limit field
+will be multiplied by 1000.
+startPeriod 0,60,120,180,260, limit 6,10,8,15,8</td><td>ChargingProfile 3:
+chargingProfilePurpose is TxProfile
+chargingProfileKind should be Absolute
+stackLevel should be 0
+evseld <Configured evseld>
+validFrom <currentDateTime - <Configured max time deviation>
+seconds>
+validTo <currentDateTime + <Configured max time deviation> +
+401 seconds>
+startSchedule <currentDateTime - <Configured max time
+deviation> seconds>
+numberPhases <Configured numberPhases>
+ChargingSchedule:
+ duration <260 <Configured max time deviation> seconds>
+chargingRateUnit <Configured chargingRateUnit>
+ Note: If <Configured chargingRateUnit> is W, then the limit field
+will be multiplied by 1000.
+startPeriod 0,50,140,200,240, limit 8,11,16,6,12</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+(Message: GetCompositeScheduleResponse)</td></tr><tr><td>status Accepted</td></tr><tr><td>evseld <Configured evseld></td></tr><tr><td>ChargingSchedule:</td></tr><tr><td>duration 400</td></tr><tr><td>chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td>Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.</td></tr><tr><td>Note: The period of time between sending the second SetChargingProfileRequest and the scheduleStart from the GetCompositeScheduleResponse is called x:</td></tr><tr><td>startPeriod 0, limit 8</td></tr><tr><td>startPeriod (50 - x), limit 10</td></tr><tr><td>startPeriod (200 - x), limit 6</td></tr><tr><td>startPeriod (240 - x), limit 10</td></tr><tr><td>startPeriod (260 - x + <Configured max time deviation>), limit 8 (TxDefaultProfile)</td></tr><tr><td>startPeriod (300 - x + <Configured max time deviation>), limit 10 (ChargingStationMaxProfile)</td></tr><tr><td>Post scenario validations:</td></tr><tr><td>N/a</td></tr></table>
+
+# 6.2.75. Page 355 - (2025-04) - TC_K_41_CS: Added missing EnergyTransferStarted reusable state
+
+A transaction needs to be started to be able to set a TxProfile. The tool already started a transaction for this reason, but the testcase description lacks this information.
+
+<table><tr><td>Test case name</td><td>Get Composite Schedule - Combining chargingProfilePurposes</td></tr><tr><td>Test case Id</td><td>TC_K_41_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:</td></tr><tr><td>...</td></tr><tr><td>Reusable State(s):</td></tr><tr><td>State is EnergyTransferStarted</td></tr></table>
+
+# 6.2.76. Page 359 - (2025-04) - TC_K_53_CS: Added missing validations
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+State is Authorized (local)
+State is EVConnectedPreSession</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized15118</td></tr><tr><td>2. The Charging Station sends a NotifyEVChargingNeedsRequest</td><td>3. The Test System responds with a NotifyEVChargingNeedsResponse with status Accepted</td></tr><tr><td>5. The Charging Station responds with a SetChargingProfileResponse</td><td>4. The Test System sends a SetChargingProfileRequest with chargingProfile.chargingProfilePurpose TxProfile chargingProfile transactionld <transactionld> chargingProfile.chargingSchedule[0].id <Id generated by Test System> chargingProfile.chargingSchedule[0].chargingRateUnit <Configured chargingRateUnit> chargingProfile.chargingSchedule[0].chargingSchedulePeriod.s startPeriod 0 chargingProfile.chargingSchedule[0].chargingSchedulePeriod.limit 6 * <limit multiplier> Note: Check [csKSmartChargingChargingProfileLimits] for <limit multiplier></td></tr><tr><td>6. The Charging Station sends a NotifyEVChargingScheduleRequest</td><td>7. The Test System responds with a NotifyEVChargingScheduleResponse with status Accepted</td></tr><tr><td colspan="2">4. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>8. The Charging Station sends a TransactionEventRequest.</td><td>9. The Test System responds with a TransactionEventResponse</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:</td></tr><tr><td>Message: TransactionEventRequest of Authorized15118 step 3</td></tr><tr><td>- eventType must be Updated or Started</td></tr><tr><td>- triggerReason must be Authorized</td></tr><tr><td>* Step 2:</td></tr><tr><td>Message: NotifyEVChargingNeedsRequest</td></tr><tr><td>IF chargingNeeds.acChargingParameters is <omitted> THEN</td></tr><tr><td>chargingNeeds.dcChargingParameters must be <not omitted></td></tr><tr><td>END IF</td></tr><tr><td>IF chargingNeeds.dcChargingParameters is <omitted> THEN</td></tr><tr><td>chargingNeeds.acChargingParameters must be <not omitted></td></tr><tr><td>END IF</td></tr><tr><td>* Step 5:</td></tr><tr><td>Message: SetChargingProfileResponse</td></tr><tr><td>- status must be Accepted</td></tr><tr><td>* Step 6:</td></tr><tr><td>Message: NotifyEVChargingScheduleRequest</td></tr><tr><td>- chargingSchedule must be within bounds of chargingSchedule of step 4</td></tr><tr><td>* Step 8:</td></tr><tr><td>Message: TransactionEventRequest</td></tr><tr><td>- triggerReason must be ChargingStateChanged</td></tr><tr><td>- transactionInfo.chargingState must be Charging</td></tr><tr><td>Post scenario validations:</td></tr><tr><td>N/a</td></tr></table>
+
+# 6.2.77. Page 360 - (2025-02) - TC_K_54_CS: EVConnected must be before Authorization
+
+TC_K_54_CS: Charging with load leveling based on High Level Communication - No SASchedule (rejected)
+
+<table><tr><td>Test case name</td><td>Charging with load leveling based on High Level Communication - No SASchedule (rejected)</td></tr><tr><td>Test case Id</td><td>TC_K_54_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+State is EVConnectedPreSession
+State is Authorized (local)</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized15118</td></tr><tr><td>2. The Charging Station sends a NotifyEVChargingNeedsRequest.</td><td>3. The Test System responds with a NotifyEVChargingNeedsResponse. With status Rejected</td></tr><tr><td colspan="2">[...]</td></tr></table>
+
+# 6.2.78. Page 362 - (2025-02) - TC_K_56_CS: EVConnected must be before Authorization
+
+TC_K_56_CS: Charging with load leveling based on High Level Communication - Offline
+
+<table><tr><td>Test case name</td><td>Charging with load leveling based on High Level Communication - Offline</td></tr><tr><td>Test case Id</td><td>TC_K_56_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum></td></tr><tr><td>Memory State:
+...</td></tr><tr><td>Reusable State(s):
+State is EVConnectedPreSession
+State is Authorized (local)</td></tr></table>
+
+# 6.2.79. Page 364 - (2025-02) - TC_K_57_CS: EVConnected must be before Authorization
+
+TC_K_57_CS: Renegotiating a Charging Schedule - Initiated by EV
+
+<table><tr><td>Test case name</td><td>Renegotiating a Charging Schedule - Initiated by EV</td></tr><tr><td>Test case Id</td><td>TC_K_57_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+State is EVConnectedPreSession
+State is Authorized (local)
+State is RenegotiateChargingLimits</td></tr></table>
+
+# 6.2.80. Page 362 - (2024-09) - TC_K_56_CS Removed expecting triggerReason=ChargingRateChanged [776]
+
+A trigger reason ChargingStateChange must only be sent, when an external actor (not CSMS) changes the charging rate. Therefore, removed the check that triggerReason=ChargingStateChanged is sent. Also added a check that the EV charging schedule fits within the given charging profile.
+
+<table><tr><td>Test case name</td><td colspan="2">Charging with load leveling based on High Level Communication - Offline</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_56_CS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS 6. The OCTT responds with a TransactionResponse.</td></tr><tr><td colspan="2">...</td></tr><tr><td>Test case name</td><td>Charging with load leveling based on High Level Communication - Offline</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 3:
+(Message: NotifyEVChargingScheduleRequest)
+evseld <Configured evseld>
+chargingSchedule.chargingSchedule[0].chargingRateUnit <Configured chargingRateUnit>
+chargingSchedule.chargingSchedule[0].chargingSchedulePeriod[0].startPeriod 0
+If <Configured chargingRateUnit> is W:
+chargingSchedule.chargingSchedule[0].chargingSchedulePeriod[0].limit <= 8000
+Else:
+chargingSchedule.chargingSchedule[0].chargingSchedulePeriod[0].limit <= 8 * Step-5:
+Message: TransactionEventRequest
+-triggerReason must be ChargingStateChanged
+-transactionInfo.chargingState must be Charging
+-offline true</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+# 6.2.81. Page 366 - (2025-02) - TC_K_58_CS
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+State is Authorized (local)
+State is EVConnectedPreSession
+State is RenegotiateChargingLimits
+State is EVConnectedPreSession
+State is Authorized15118
+State is EnergyTransferStarted</td></tr></table>
+
+# 6.2.82. Page 384 - TC_L_10_CS - Allow Download/InstallationFailed upon AcceptedCanceled
+
+When a new firmware update is issued, the ongoing firmware update is canceled, but Charging Station may still send a FirmwareStatusNotification(DownloadFailed/InstallationFailed)
+
+<table><tr><td>Test case name</td><td>Secure Firmware Update - AcceptedCanceled</td></tr><tr><td>Test case Id</td><td>TC_L_10_CS</td></tr><tr><td>...</td><td>...</td></tr><tr><td colspan="2"></td></tr><tr><td colspan="2">Before (Preparations)</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a Update FirmwareResponse With status Accepted</td><td>1. The Test System sends a Update FirmwareRequest with requestId = <#1> firmware.installDateTime <Current DateTime - 2 hours> firmware.location <Configured firmware_location> firmware.retrieveDateTime <Current DateTime - 2 hours> firmware/signingCertificate <Configured signingCertificate> firmwaresignature <Configured signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequest With requestId <#1> and status Downloading</td><td>4. The Test System responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>6. The Charging Station responds with a UpdateFirmwareResponse With requestId <#1> and status AcceptedCanceled</td><td>5. The Test System sends a UpdateFirmwareRequest with requestId = <#2> firmware.installDateTime <Current DateTime - 2 hours> firmware.location <Configured firmware_location> firmware.retrieveDateTime <Current DateTime - 2 hours> firmware/signingCertificate <Configured signingCertificate> firmwaresignature <Configured signature></td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequest With requestId <#2> and status Downloading</td><td>8. The Test System responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+Message UpdateFirmwareResponse
+- status Accepted
+* Step 3:
+Message FirmwareStatusNotificationRequest
+- status Downloading
+- requestId = <#1>
+* Step 6:
+Message UpdateFirmwareResponse
+- status AcceptedCanceled
+A FirmwareStatusNotificationRequest DownloadFailed or InstallationFailed may be sent for requestId <#1> before or after step 6.</td></tr><tr><td>(The requestId at the FirmwareStatusNotificationRequest messages must refer to the id <#2> from the second
+UpdateFirmwareRequest from this point on)
+* Step 7:
+Message FirmwareStatusNotificationRequest
+- status Downloading
+...</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+# 6.2.83. Page 387 - TC_L_06_CS - SecurityEventNotification and FirmwareStatusNotification can be sent in any order
+
+The SecurityEventNotification with type InvalidFirmwareSignature and the FirmwareStatusNotification with status InvalidSignature can be sent in any order. These events are triggered simultaneously, so which message is transmitted first may vary.
+
+<table><tr><td>Test case name</td><td>Secure Firmware Update - InvalidSignature</td></tr><tr><td>Test case Id</td><td>TC_L_06_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponse</td><td>1. The Test System sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours> firmware.location <Configured firmware_location> firmware.retrieveDateTime <Current DateTime - 2 hours> firmware signingCertificate <Configured signingCertificate> firmwaresignature <Configured invalid firmware signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequest. With status Downloading</td><td>4. The Test System responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>5. The Charging Station sends a FirmwareStatusNotificationRequest. With status Downloaded</td><td>6. The Test System responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td colspan="2">Note: Step 7 through 10 can be sent in a different order.</td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequest. With status InvalidSignature</td><td>8. The Test System responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>9. The Charging Station sends a SecurityEventNotificationRequest. With type InvalidFirmwareSignature</td><td>10. The Test System responds with a SecurityEventNotificationResponse.</td></tr></table>
+
+# 6.2.84. Page 422 - (2025-02) - TC_M_15_CS - V2GCertificateChain is not installed before being retrieved
+
+<table><tr><td>Test case name</td><td>Retrieve certificates from Charging Station - V2G CertificateChain</td></tr><tr><td>Test case Id</td><td>TC_M_15_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+RenewV2GChargingStationCertificate</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+# 6.2.85. Page 430 - (2025-06) - TC_M_24_CS - A GetCertificateStatusRequest is also sent for the subCAs
+
+According to requirement M06.FR.07, the Charging Station sends a GetCertificateStatusRequest for the V2G Charging Station certificate (leaf) and the subCAs.
+
+<table><tr><td>Test case name</td><td>Get Charging Station Certificate status - Success</td></tr><tr><td>Test case Id</td><td>TC_M_24_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends a GetCertificateStatusRequest</td><td>2. The Test System responds with a GetCertificateStatusResponse with status Accepted ocspResult <OCSPResponse class as defined in IETF RFC 6960. DER encoded (as defined in IETF RFC 6960), and then base64 encoded.></td></tr><tr><td colspan="2">Note: Step 1/2 are repeated for the V2G Charging Station (leaf), the subCA1 and subCA2 certificates.</td></tr></table>
+
+# 6.2.86. Page 436 - (2025-02) - TC_N_01_CS - Made used component variable configurable
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+The following monitors (on arbitrary variables) must be present as 'hard-wired' or 'preconfigured' or must have been configured by GSMS:
+-LowerThreshold
+-UpperThreshold
+-Delta
+-Periodie
+-PeriodicClockAligned
+The following monitors must have been configured by CSMS for Component Variable <Configured threshold monitor component variable ></td></tr><tr><td>variable>:
+-LowerThreshold using value <Configured threshold monitor component variable LowerThreshold trigger value>
+-UpperThreshold using value <Configured threshold monitor component variable UpperThreshold trigger value>
+-Periodic using value <Configured Clock Aligned MeterValues Interval></td></tr><tr><td>The following monitors must have been configured by CSMS for Component Variable <Configured numeric delta component variable>
+-Delta using value <Configured numeric delta component variable Delta numeric trigger value>
+-PeriodicClockAligned using value <Configured Clock Aligned MeterValues Interval></td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+# 6.2.87. Page 455 - (2025-02) - TC_N_12_CS - Updating test case for using configuration variables
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Value out of range - Delta monitor</td></tr><tr><td colspan="3">[...]</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.
+This test case assumes the following component exists and can be monitored:
+-Component "EVSE", evse "1", variable "AvailabilityState", monitor type Delta
+Note: Variable _AvailabilityState is mandatory for an EVSE and it is likely (but not guaranteed), that it can be monitored=
+This test case assumes a numeric component variable exists which can be monitored.</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">Main (Test scenario)</td></tr><tr><td colspan="2">Charging Station</td><td>CSMS</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>2. Charging Station responds with: SetVariableMonitoringResponse</td><td>Install monitors
+1. Test System sends SetVariableMonitoringRequest with:
+- setMonitoringData[0].value = -1
+- setMonitoringData[0].type = Delta
+- setMonitoringData[0].severity = <Configured severity>
+- setMonitoringData[0].component.name = "EVSE"
+- setMonitoringData[0].component.evse.id = <Configured evseId>
+- setMonitoringData[0].variable.name = "AvailabilityState"
+- setMonitoringData[0].component = <Configured numeric delta component>
+- setMonitoringData[0].variable = <Configured numeric delta component variable></td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+Message: SetVariableMonitoringResponse with (in arbitrary order):
+setMonitoringResult = {
+- id is absent
+- status = Rejected
+- type = Delta
+- severity = <Configured severity>
+-component.name = "EVSE"
+-component.evse.id = <Configured evseld>
+-variable.name = "AvailabilityState"
+- component = <Configured numeric delta component variable>
+- variable = <Configured numeric delta component variable>
+-statusInfo is absent or statusInfoReasonCode = "ValueOfRange" or statusInfoReasonCode = "ValuePositiveOnly" }</td></tr><tr><td>Post scenario validations:
+N/A</td></tr></table>
+
+# 6.2.88. Page 456 - (2025-02) - TC_N_13_CS - Updating test case for using more specific configuration variables
+
+# TC_N_13_CS: Set Variable Monitoring - Value out of range - Threshold monitor
+
+<table><tr><td>Test case name</td><td>Set Variable Monitoring - Value out of range - Threshold monitor</td></tr><tr><td>Test case Id</td><td>TC_N_13_CS</td></tr><tr><td>Use case Id(s)</td><td>N04</td></tr><tr><td>Requirement(s)</td><td>N04.FR.13 N04.FR.06</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>CSMS tries to set a threshold monitor with a value that is out of range.</td></tr><tr><td>Purpose</td><td>To test that Charging Station checks that value is within range of variable.</td></tr><tr><td rowspan="2">Prerequisite(s)</td><td>Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td>This test case assumes the <Configured threshold monitor component variable> component_variable exists and can be monitored and has variableCharacteristics.maxLimit < <Configured threshold monitor value> This test case assumes the <Configured threshold monitor component variable with maxLimit> component_variable exists and can be monitored and has variableCharacteristics.maxLimit < <Configured threshold monitor component variable with maxLimit exceeding maxLimit value> + Note: Variable _Power(maxLimit) is mandatory for an EVSE, but the actual value not, but it is likely (but not guaranteed), that it can be monitored._</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with: SetVariableMonitoringResponse</td><td>Install monitors1. Test System sends SetVariableMonitoringRequest with:-setMonitoringData[0].value = <Configured threshold monitor value> - setMonitoringData[0].value = <Configured threshold monitor component variable with maxLimit exceeding maxLimit value> - setMonitoringData[0].type = UpperThreshold- setMonitoringData[0].severity = <Configured severity> -setMonitoringData[0].component.name = <Configured threshold monitor component variable> -setMonitoringData[0].component.evse.id = <Configured evseId> -setMonitoringData[0].variable.name = <Configured threshold monitor component variable> - setMonitoringData[0].component = <Configured threshold monitor component variable with maxLimit> - setMonitoringData[0].variable = <Configured threshold monitor component variable with maxLimit></td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+Message: SetVariableMonitoringResponse with (in arbitrary order):
+setMonitoringResult = {
+- id is absent
+- status = Rejected
+- type = UpperThreshold
+- severity = <Configured severity>
+-component.name = <Configured threshold monitor component variable>
+-component.evse.id = <Configured evseId>
+-variable.name = <Configured threshold monitor component variable>
+-component = <Configured threshold monitor component variable with maxLimit>
+-variable = <Configured threshold monitor component variable with maxLimit>
+-statusInfo is absent or statusInfoReasonCode = "ValueOfRange"}</td></tr><tr><td>Post scenario validations:
+N/A</td></tr></table>
+
+# 6.2.89. Page 463 - (2025-02) TC_N_20_CS - Updating test case for using more specific configuration variables
+
+# TC_N_20_CS: Alert Event - Threshold value exceeded
+
+<table><tr><td>Test case name</td><td>Alert Event - Threshold value exceeded</td></tr><tr><td>Test case Id</td><td>TC_N_20_CS</td></tr><tr><td>Use case Id(s)</td><td>N07</td></tr><tr><td>Requirement(s)</td><td>N07.FR.06, N07.FR.07, N07.FR.16, N07.FR.17</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>A monitored variable exceeds a threshold monitor and causes a NotifyEventRequest message to be sent.</td></tr><tr><td>Purpose</td><td>To test that Charging Station supports threshold monitors</td></tr><tr><td>Prerequisite(s)</td><td>Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr></table>
+
+# Before (Preparations)
+
+Configuration State: N/a
+
+# Memory State:
+
+This test requires the Monitoring Base to be set to All.
+
+- SetMonitoringBaseRequest with monitoringBase = All.
+ Furthermore this test requires the existence of a LowerThreshold and UpperThreshold monitor on a (numerical) variable. Since it is not mandated which variables are required to be monitored, this test used the variable "Power" of component "EVSE".
+ -setMonitoringData[0].value--<Configured threshold monitor value>
+- setMonitoringData[0].value = <Configured threshold monitor component variable UpperThreshold trigger value>
+- setMonitoringData[0].type = UpperThreshold
+ -setMonitoringData[0].severity = <Configured severity>
+ -setMonitoringData[0].component.name -<Configured threshold monitor component variable>
+ -setMonitoringData[0].component.evse.id = <ConfiguredEvseId>
+ -setMonitoringData[0].variable.name--<Configured threshold monitor component variable>
+- setMonitoringData[0].severity = 5
+- setMonitoringData[0].component = <Configured threshold monitor component variable>
+- setMonitoringData[0].variable = <Configured threshold monitor component variable>
+
+Set MonitoringLevel to 8
+
+# Notes:
+
+- If componentVariable is set to "Power" or "Current", the value is set to the configured maxLimit 100.0
+- Take a threshold that can easily be exceeded.
+
+Reusable State(s): N/a
+
+Main (Test scenario)
+
+<table><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EnergyTransferStarted or manually trigger the monitor.
+Notes: If componentVariable is set to "Power" or "Current" EnergyTransferStarted will trigger the monitor. If another componentvariable is chosen a manual action is needed to trigger the monitor.</td></tr><tr><td>2. Charging Station sends a NotifyEventRequest with:
+- Power exceeding upper threshold</td><td>3. Test System responds with a NotifyEventResponse</td></tr><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>5. Charging Station responds with a SetVariableMonitoringResponse with: - status Accepted</td><td>4. Test System sends a SetVariableMonitoringRequest with: - type LowerThreshold -component.name<-Configured threshold monitor component variable> -component.evse.id<-configured evseid> -variable.name<-Configured threshold monitor component variable> -value<-Configured threshold monitor2 value> - component<-Configured threshold monitor component variable> - variable<-Configured threshold monitor component variable> - value<-Configured threshold monitor component variable> - LowerThreshold trigger value> Notes: -If componentVariable is set to "Power" or "Current", the value is set to the configured maxLimit 10.0 - Take a threshold that won't be exceeded.</td></tr><tr><td colspan="2">6. Execute Reusable State StopAuthorized or manually trigger the second monitor. Notes: If componentVariable is set to "Power" or "Current" EnergyTransferStarted will trigger the monitor. If another componentvariable is chosen a manual action is needed to trigger the monitor.</td></tr><tr><td>7. Charging Station sends: NotifyEventRequest for 2 events: - Returning below upper threshold (cleared) - Dropping below lower threshold</td><td>8. Test System responds: NotifyEventResponse</td></tr><tr><td colspan="2">Notes: Steps 2, 3, 7, and 8 may be repeated if the data is sent using two requests instead of one. Depending on the configuration the Charging Station may also send other notifications during step 4 and 9.</td></tr><tr><td colspan="2">Tool validations</td></tr><tr><td colspan="2">* Step 2: Message: NotifyEventRequest with: - generatedAt = <time of generation at Charging Station> - seqNo = 0 and an eventData element with: - eventId = <id1> - timestamp = <time of event at Charging Station> - trigger = Alerting - actualValue = <current power> (must be ><Configured threshold monitor value>) - cleared is absent or cleared = false - transactionld = <transaction id> (delivery of power is always in transaction) - variableMonitoringId = <monitor id1> -component.name = <Configured threshold monitor component variable> -component.evse.id = <Configured evseid> -variable.name = <Configured threshold monitor component variable> - component = <Configured threshold monitor component variable> - variable.name = <Configured threshold monitor component variable> Other eventData elements can be ignored.</td></tr></table>
+
+# Tool validations
+
+- Step 7: Message: NotifyEventRequest with:
+
+* generatedAt = <time of generation at Charging Station>
+ -seqNo $= 0$
+
+and an eventData element with:
+
+-eventId $=$ <id2>
+
+- timestamp = <time of event at Charging Station>
+
+- trigger = Alerting
+
+-actualValue \(=\) <current power \(\rightharpoondown\) (must be \(= = < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < <
+
+- cleared is true
+
+- transactionld = <transaction id> (delivery of power is always in transaction)
+
+-variableMonitoringld $=$ <monitor id1>
+
+-eventNotificationType $=$ CustomMonitor
+
+-component.name = <Configured threshold monitor component variable>
+
+-component.evse.id = <ConfiguredEvseId>
+
+-variable.name = <Configured threshold monitor component variable>
+
+- component = <Configured threshold monitor component variable>
+
+- variable.name = <Configured threshold monitor component variable>
+
+and an eventData element with:
+
+-eventId $=$ <id3>
+
+- timestamp = <time of event at Charging Station>
+
+- trigger = Alerting
+
+-actualValue = <current power> (must be <<Configured threshold monitor2 value>)
+
+- cleared is absent or cleared is false
+
+- transactionld = <transaction id> (delivery of power is always in transaction)
+
+-variableMonitoringld $=$ <monitor id2>
+
+-eventNotificationType $=$ CustomMonitor
+
+-component.name = <Configured threshold monitor component variable>
+
+-component.evse.id = <ConfiguredEvseId>
+
+-variable.name $=$ <Configured threshold monitor component variable>
+
+- component = <Configured threshold monitor component variable>
+
+- variable.name = <Configured threshold monitor component variable>
+
+Other eventData elements can be ignored. This can also be sent in two NotifyEventRequests, instead of one.
+
+Post scenario validations: N/A
+
+# 6.2.90. Page 468 - (2024-06) TC_N_23_CS Offline Notification - OfflineMonitoringEventQueuingSeverity set higher than severityLevel of the monitor [772]
+
+<table><tr><td>Test case name</td><td colspan="2">Offline Notification - OfflineMonitoringEventQueuingSeverity set higher than severityLevel of the monitor</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_23_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N07.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">Charging Station does not queue event notifications when offline.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station does not queue event notifications with a severity higher than OfflineMonitoringEventQueuingSeverity.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station is online at start of test for configuration. CS has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: SetConfiguration with: - component.name = "MonitoringCtrl" - variable.name = "OfflineQueuingSeverity" - attributeValue = <Configured Severity></td></tr><tr><td colspan="2">Memory State: Charging Station has custom or predefined monitors on variable AvailabilityState of Configured EVSE and Configured ConnectorId with severity = <Configured severity> + 1</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="13">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td>1. The Charging Station notifies the CSMS about the status change of the connector.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td colspan="2">Note(s): Step 3, 4, 5, 6, 7, and 8 need to be executed when TxStartPoint contains EVConnected OR ParkingBayOccupancy</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td colspan="2">Manual Action: Take Charging Station offline.</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE.</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td colspan="2">Note(s): The tool will now wait for <Configured Transaction Duration> seconds</td></tr><tr><td colspan="2">Manual Action: Bring Charging Station back online.</td></tr><tr><td>5. The Charging Station sends a TransactionEventRequest</td><td>6. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>7. The Charging Station sends a TransactionEventRequest</td><td>8. The OCTT responds with a TransactionEventResponse</td></tr><tr><td colspan="2">Note(s): The CS shall not send a NotifyEventRequest for AvailabilityState of EVSE and Connector. A StatusNotification may still be received.</td></tr><tr><td>Test case name</td><td>Offline Notification - OfflineMonitoringEventQueuingSeverity set higher than severityLevel of the monitor</td></tr><tr><td rowspan="5">Tool validations</td><td>* Step 1: (Optional):Message: StatusNotificationRequest- evseld <configured evseld> - connectorId <configured connectorId> - connectorStatus must be Occupied(Required, but can be combined into one NotifyEventRequest:)Message: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Occupied-eventData[0].component.name must be Connector-eventData[0].component.evse.id must be Configured EVSE-eventData[0].component.evseconnectorId must be Configured ConnectorId-eventData[0].variable.name must be AvailabilityStateMessage: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Occupied-eventData[0].component.name must be EVSE-eventData[0].component.evse.id must be Configured EVSE-eventData[0].variable.name must be AvailabilityState</td></tr><tr><td>* Step 3:Message: TransactionEventRequest- triggerReason must be CablePluggedIn- transactionInfo.chargingState must be EVConnected</td></tr><tr><td>* Step 5:Message: TransactionEventRequest- triggerReason must be EVCommunicationLost- transactionInfo.chargingState must be Idle</td></tr><tr><td>* Step 7:Message: TransactionEventRequest- triggerReason must be CablePluggedIn- transactionInfo.chargingState must be EVConnected</td></tr><tr><td>Post scenario validations:N/A</td></tr></table>
+
+# 6.2.91. Page 470 - (2024-09) - TC_N_24_CS - Referring to incorrect use case and requirements [O20-4793]
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Periodic event</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_24_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04, N08</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.01, N04.FR.08, N08.FR.05 and N08.FR.06</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">...</td></tr><tr><td colspan="2">Post scenario validations:
+N/A</td></tr></table>
+
+# 6.2.92. Page 492 - (2025-02) - TC_N_39_CS - Test case now searches suitable variables to do test with
+
+# TC_N_39_CS: Set Variable Monitoring - Component/Variable combination does NOT correspond
+
+<table><tr><td>Test case name</td><td>Set Variable Monitoring - Component/Variable combination does NOT correspond</td></tr><tr><td>Test case Id</td><td>TC_N_39_CS</td></tr><tr><td colspan="2">...</td></tr><tr><td>Prerequisite(s)</td><td>Charging Station supports MonitoringThis test case assumes the Charging Station has a non-numeric Component Variable <Configured non-numeric delta component variable> and numeric Component Variable <Configured threshold monitorcomponent variable>.</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>...</td></tr><tr><td>Memory State:
+Variable monitor is already set with component.name = EVSE, variable.name = AvailabilityState, type = Delta
+N/a</td></tr><tr><td>Reusable State:
+N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetVariableMonitoringResponse</td><td>1. The Test System sends a SetVariableMonitoringRequest with setMonitoringData[0].type Delta
+setMonitoringData[0].value 1
+setMonitoringData[0].component = <Configured non-numeric delta component variable>
+setMonitoringData[0].variable = <Configured non-numeric delta component variable></td></tr><tr><td>2. The Charging Station responds with a SetVariableMonitoringResponse</td><td>1. The Test System sends a SetVariableMonitoringRequest with setMonitoringData.type UpperThreshold
+setMonitoringData(variable.name Power
+setMonitoringData_component.name ChargingStation-</td></tr><tr><td>4. The Charging Station responds with a SetVariableMonitoringResponse</td><td>3. The Test System sends a SetVariableMonitoringRequest with setMonitoringData[0].id
+<SetVariableMonitoringResponse.setMonitoringResult[0].id of step 2>
+setMonitoringData[0].type Delta
+setMonitoringData[0].value 1
+setMonitoringData[0].component = <Configured numeric delta component variable>
+setMonitoringData[0].variable = <Configured numeric delta component variable></td></tr><tr><td rowspan="2">4. The Charging Station responds with a GetMonitoringReportResponse</td><td>3. The Test System sends a GetMonitoringReportRequest with -requestId <Generated requestId></td></tr><tr><td>5. The Test System sends a GetMonitoringReportRequest with - requestId <Generated requestId></td></tr><tr><td>6. The Charging Station responds with a GetMonitoringReportResponse</td><td></td></tr><tr><td>5. The Charging Station sends a NotifyMonitoringReportRequest</td><td>6. The Test System responds with a NotifyMonitoringReportResponse--</td></tr><tr><td>7. The Charging Station sends a NotifyMonitoringReportRequest</td><td>8. The Test System responds with a NotifyMonitoringReportResponse .</td></tr><tr><td>Note(s):
+- If tbc is True at Step 3 then step 3 and 4 will be repeated-
+- If tbc is True at Step 7 then step 7 and 8 will be repeated</td><td></td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:</td></tr><tr><td>Message-SetVariableMonitoringResponse</td></tr><tr><td>-setMonitoringResult[0].status Rejected</td></tr><tr><td>-setMonitoringResult[0].type UpperThreshold</td></tr><tr><td>-setMonitoringResult[0].severity <Configured severity></td></tr><tr><td>-setMonitoringResult[0].component.name ChargingStation</td></tr><tr><td>-setMonitoringResult[0].variable.name Power</td></tr><tr><td>* Step 4:</td></tr><tr><td>Message-GetMonitoringReportResponse</td></tr><tr><td>-status Accepted</td></tr><tr><td>* Step 5:</td></tr><tr><td>Message-NotifyMonitoringReportRequest</td></tr><tr><td>-monitor_component-EVSE</td></tr><tr><td>-monitor-variable-AvailabilityState</td></tr><tr><td>* Step 2:</td></tr><tr><td>Message SetVariableMonitoringResponse</td></tr><tr><td>-setMonitoringResult[0].id <not omitted></td></tr><tr><td>-setMonitoringResult[0].status Accepted</td></tr><tr><td>-setMonitoringResult[0].type Delta</td></tr><tr><td>-setMonitoringResult[0].component = <Configured non-numeric delta component variable></td></tr><tr><td>-setMonitoringResult[0].variable = <Configured non-numeric delta component variable></td></tr><tr><td>* Step 4:</td></tr><tr><td>Message SetVariableMonitoringResponse</td></tr><tr><td>-setMonitoringResult[0].status Rejected</td></tr><tr><td>-setMonitoringResult[0].type Delta</td></tr><tr><td>-setMonitoringResult[0].component = <Configured numeric delta component variable></td></tr><tr><td>-setMonitoringResult[0].variable = <Configured numeric delta component variable></td></tr><tr><td>* Step 6:</td></tr><tr><td>Message GetMonitoringReportResponse</td></tr><tr><td>-status Accepted</td></tr><tr><td>* Step 7:</td></tr><tr><td>Message NotifyMonitoringReportRequest</td></tr><tr><td>Must contain a monitor with</td></tr><tr><td>-monitor[0].component = <Configured non-numeric delta component variable></td></tr><tr><td>-monitor[0].variable = <Configured non-numeric delta component variable></td></tr><tr><td>-monitor[0].variableMonitoring[0].id = <SetVariableMonitoringResponse.setMonitoringResult[0].id of step 2></td></tr><tr><td>-monitor[0].variableMonitoring[0].value = 1</td></tr><tr><td>-monitor[0].variableMonitoring[0].type = Delta</td></tr><tr><td>Post scenario validations:</td></tr><tr><td>- All report parts have been received</td></tr></table>
+
+# 6.2.93. Page 472 - (2024-12) - TC_N_26_CS - Made test case more explicit and more time before ending
+
+Note: This erratum was released in tag 2025-01, not the mentioned 2024-12.
+
+# TC_N_26_CS: Retrieve Log Information - Diagnostics Log - Upload failed
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetLogResponse</td><td>1. The Test System sends a GetLogRequest with - logType DiagnosticsLog - retries 3 - retryInterval <Configured retryInterval> - log_remoteLocation <Configured log location with non-existing path></td></tr><tr><td colspan="2">...</td></tr><tr><td colspan="2">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.
+- Step 3-4, 5-6 and 3-6 may repeat multiple times depending on Charging Station's implementation.
+- The Test System waits at least (3 * <Configured retryInterval>), before ending the testcase.</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>...</td></tr><tr><td>* Step 3:</td></tr><tr><td>Must be sent exactly 1 or 4 times</td></tr><tr><td>Message LogStatusNotificationRequest</td></tr><tr><td>- status Uploading</td></tr><tr><td>- requestId Same Id as the GetLogRequest</td></tr><tr><td>* Step 5:</td></tr><tr><td>Must be sent exactly 1 or 4 times</td></tr><tr><td>Message LogStatusNotificationRequest</td></tr><tr><td>...</td></tr><tr><td>Post scenario validations:</td></tr><tr><td>- N/a</td></tr></table>
+
+# 6.2.94. Page 470 - (2024-12) - TC_N_24_CS - Test case now searches suitable variable to do test with
+
+Note: This erratum has been superseded by erratum: Page 470 - (2025-02) - TC_N_24_CS - Updating test case for using more specific configuration variables
+
+TC_N_24_CS: Set Variable Monitoring - Periodic event
+
+<table><tr><td>Test case name</td><td>Set Variable Monitoring - Periodic event</td></tr><tr><td>Test case Id</td><td>TC_N_24_CS</td></tr><tr><td colspan="2">...</td></tr><tr><td>Prerequisite(s)</td><td>Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.
+This test case assumes the device model exposes at least one component(variable which can be monitored.</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>...</td></tr><tr><td>Reusable State(s):
+N/a-
+State is [csCommunicatedBaseReport]</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Search [csCommunicatedBaseReport].baseReportData to get a baseReportData.reportDataWHERE reportData variableCharacteristicssupportsMonitoring is trueAND reportData_component.instance is <omitted>AND reportData.instance.instance.is <omitted>AS <componentVariable></td></tr><tr><td colspan="2">Set the monitor to generate a periodic event notification</td></tr><tr><td>2. Charging Station responds with SetVariableMonitoringResponse</td><td>1. Test System sends SetVariableMonitoringRequest with:-setMonitoringData[0].value = <Configured Clock-AlignedMeterValues Interval> - setMonitoringData[0].value = 2 - setMonitoringData[0].type = Periodic -setMonitoringData[0].component.name = "EVSE"-setMonitoringData[0].component.evse.id = <ConfiguredevseId>-setMonitoringData[0].variable.name = "AvailabilityState"-setMonitoringData[0].component.name = <componentVariablecomponent.name> - setMonitoringData[0].component.evse.id = <componentVariablecomponent.evse.id>- setMonitoringData[0].variable.name = <componentVariable(variable.name></td></tr><tr><td>3. Charging Station generates NotifyEventRequest for EVSE#1::AvailabilityState_every<Configured Clock-AlignedMeterValues Interval>seconds.3. Charging Station sends a NotifyEventRequest</td><td>4. Test System responds with a NotifyEventResponse</td></tr><tr><td colspan="2">Note(s): Step 3 and 4 will repeat every 2 seconds</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:Message: SetVariableMonitoringResponse with:setMonitoringResult[0].status = AcceptedsetMonitoringResult[0].component.name = "EVSE"setMonitoringResult[0].component.evse.id = <Configured evseld>setMonitoringResult[0].variable.name = "AvailabilityState"setMonitoringResult[0].component.name = <componentVariablecomponent.name>setMonitoringResult[0].component.evse.id = <componentVariablecomponent.evse.id>setMonitoringResult[0].variable.name = <componentVariable(variable.name>setMonitoringResult[0].attributeStatusInfo is absent or attributeStatusInforeasonCode = "NoError"</td></tr><tr><td>* Step 3:Message: a NotifyEventRequest message every<Configured Clock Aligned MeterValues Interval>seconds with:Message: NotifyEventRequest every 2 seconds with:with an eventData element with:- trigger = Periodic-component.name = "EVSE"-component.evse.id = -1-variable.name = "AvailabilityState"- component.name = <componentVariablecomponent.name>- component.evse.id = <componentVariablecomponent.evse.id>- variable.name = <componentVariable(variable.name></td></tr><tr><td>Post scenario validations:N/A</td></tr></table>
+
+# 6.2.95. Page 470 - (2025-02) - TC_N_24_CS - Updating test case for using more specific configuration variables
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a
+Set MonitoringLevel to 8</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+<table><tr><td colspan="3">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td colspan="2">CSMS</td></tr><tr><td colspan="3">Set the monitor to generate a periodic event notification</td></tr><tr><td>2. Charging Station responds with SetVariableMonitoringResponse</td><td colspan="2">1. Test System sends SetVariableMonitoringRequest with: - setMonitoringData[0].value = <Configured Clock Aligned MeterValues Interval> - setMonitoringData[0].type = Periodic - setMonitoringData[0].component.name = "EVSE" - setMonitoringData[0].component.evse.id = <Configured evseId> - setMonitoringData[0].variable.name = "AvailabilityState" - setMonitoringData[0].severity = 5 - setMonitoringData[0].component = <Configured threshold monitor component variable> - setMonitoringData[0].variable = <Configured threshold monitor component variable></td></tr><tr><td>3. Charging Station generates NotifyEventRequest for EVSE #1::AvailabilityState_every<Configured Clock-Aligned MeterValues Interval>seconds.</td><td colspan="2">4. Test System responds with a NotifyEventResponse</td></tr><tr><td>3. Charging Station sends a NotifyEventRequest</td><td></td><td></td></tr><tr><td colspan="3">Note(s): Step 3 and 4 will repeat every <Configured Clock Aligned MeterValues Interval> seconds</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:</td></tr><tr><td>Message: SetVariableMonitoringResponse with:</td></tr><tr><td>setMonitoringResult[0].status = Accepted</td></tr><tr><td>setMonitoringResult[0].component.name = "EVSE"</td></tr><tr><td>setMonitoringResult[0].component.evse.id = <Configured evseld></td></tr><tr><td>setMonitoringResult[0].variable.name = "AvailabilityState"</td></tr><tr><td>setMonitoringResult[0].type = Periodic</td></tr><tr><td>setMonitoringResult[0].severity = 5</td></tr><tr><td>setMonitoringResult[0].component = <Configured threshold monitor component variable></td></tr><tr><td>setMonitoringResult[0].attribute = <Configured threshold monitor component variable></td></tr><tr><td>setMonitoringResult[0].attributeStatusInfo is absent or attributeStatusInforeasonCode = "NoError"</td></tr><tr><td>* Step 3:Message: a NotifyEventRequest message every <Configured Clock Aligned MeterValues Interval> seconds with:Message: NotifyEventRequest every <Configured Clock Aligned MeterValues Interval> seconds with:with an eventData element with:- trigger = Periodic-component.name = "EVSE"-component.evse.id = 1-variable.name = "AvailabilityState"- component = <Configured threshold monitor component variable>- variable = <Configured threshold monitor component variable></td></tr><tr><td>Post scenario validations:N/A</td></tr></table>
+
+# 6.2.96. Page 482 - (2025-02) - TC_N_63_CS - Clear Customer Information - add manual action to stop session
+
+Note: This erratum is extended by erratum: Page 482 - (2025-04) - TC_N_63_CS - Added missing reusable state EnergyTransferStarted at before steps
+
+<table><tr><td>Test case name</td><td>Clear Customer Information - Clear and report - customerCertificate</td></tr><tr><td>Test case Id</td><td>TC_N_63_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State: -AuthCtrl.Enabled is true -AuthCtrlDISABLERemoteAuthorization is false -ISO15118Ctrl.CentralContractValidationAllowed is false -ISO15118Ctrl.V2GCertificateInstallationEnabled is true -ISO15118Ctrl Contract Certificate Installation Enabled is true -ISO15118Ctrl.PnCEnabled is true -ISO15118Ctrl.Seecd is AL- ISO15118Ctrl.CountryName is seecd -ISO15118Ctrl.OrganizationName is OCA</td></tr><tr><td>Memory State: RenewV2GChargingStationCertificate (If none are present, when checking with GetInstalledCertificatescertificateType = V2GCertificateChain)</td></tr><tr><td>Reusable State: Execute Reusable State EVConnectedPreSession Execute Reusable State Authorized15118 (PnC)</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual action: EV ends the charging session.
+Note: The Charging Station receives a SessionStopReq(Terminate) message from the EV to finish the transaction.</td></tr><tr><td>2. The Charging Station responds with a CustomerInformationResponse</td><td>1. The Test System sends a CustomerInformationRequest with - report true AND - clear true AND - customerCertificate certificate hash data of contract certificate</td></tr><tr><td>3. The Charging Station sends a NotifyCustomerInformationRequest</td><td>4. The Test System responds with a NotifyCustomerInformationResponse</td></tr><tr><td>Note(s):
+- If tbc is True at Step 3 then step 3 and 4 will be repeated</td><td></td></tr><tr><td>6. The Charging Station responds with a CustomerInformationResponse</td><td>5. The Test System sends a CustomerInformationRequest with - report true AND
+- clear false AND
+- customerCertificate certificate hash data of contract certificate</td></tr><tr><td>7. The Charging Station sends a NotifyCustomerInformationRequest</td><td>8. The Test System responds with a NotifyCustomerInformationResponse</td></tr><tr><td>Note(s):
+- If tbc is True at Step 7 then step 7 and 8 will be repeated</td><td></td></tr><tr><td colspan="2">Tool validations</td></tr><tr><td colspan="2">...</td></tr><tr><td colspan="2">Post scenario validations:
+- All report parts have been received</td></tr></table>
+
+# 6.2.97. Page 487 - (2025-04) - TC_N_36_CS -
+
+# LogStatusNotification(AcceptedCanceled) allowed before GetLogResponse
+
+It is allowed that the LogStatusNotification(AcceptedCanceled) for the canceled GetLog is sent before the new GetLogRequest is responded to by a GetLogResponse.
+
+<table><tr><td>Test case name</td><td>Retrieve Log Information - Second Request</td></tr><tr><td>Test case Id</td><td>TC_N_36_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>…</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetLogResponse</td><td>1. The Test System sends a GetLogRequest with logType <Configured logType> and requestId <#1></td></tr><tr><td>Note(s):
+- Charging Station is uploading log file</td><td></td></tr><tr><td>3. The Charging Station sends a LogStatusNotificationRequest</td><td>4. The Test System responds with a LogStatusNotificationResponse .</td></tr><tr><td>Note(s):
+- Charging Station cancels uploading the first log file</td><td></td></tr><tr><td>6. The Charging Station responds with a GetLogResponse</td><td>5. The Test System sends a GetLogRequest with logType <Configured logType> and requestId <#2></td></tr><tr><td>Step 7 is allowed to occur before step 6</td><td></td></tr><tr><td>7. The Charging Station sends a LogStatusNotificationRequest</td><td>8. The Test System responds with a LogStatusNotificationResponse .</td></tr><tr><td>Note(s):
+- Charging Station is uploading log file</td><td></td></tr><tr><td>9. The Charging Station sends a LogStatusNotificationRequest</td><td>10. The Test System responds with a LogStatusNotificationResponse .</td></tr><tr><td>Note(s):
+- Log file is uploaded</td><td></td></tr><tr><td>11. The Charging Station sends a LogStatusNotificationRequest</td><td>12. The Test System responds with a LogStatusNotificationResponse .</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+Message GetLogResponse
+- status Accepted
+* Step 3:
+Message LogStatusNotificationRequest
+- status Uploading
+- requestId <#1></td></tr><tr><td>Step 7 is allowed to occur before step 6
+* Step 6:
+Message GetLogResponse
+- status AcceptedCanceled
+* Step 7:
+Message LogStatusNotificationRequest
+- status AcceptedCanceled
+- requestId <#1></td></tr><tr><td>* Step 9:
+Message LogStatusNotificationRequest
+- status Uploading
+- requestId <#2>
+* Step 11:
+Message LogStatusNotificationRequest
+- status Uploaded
+- requestId <#2></td></tr><tr><td>Post scenario validations:
+-N/a</td></tr></table>
+
+# 6.2.98. Page 482 - (2025-04) - TC_N_63_CS - Added missing reusable state EnergyTransferStarted at before steps
+
+Note: This erratum extends erratum: Page 482 - (2025-02) - TC_N_63_CS - Clear Customer Information - add manual action to stop session
+
+<table><tr><td>Test case name</td><td>Clear Customer Information - Clear and report - customerCertificate</td></tr><tr><td>Test case Id</td><td>TC_N_63_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>...</td></tr><tr><td>Memory State:</td></tr><tr><td>RenewV2GChargingStationCertificate (If none are present, when checking with GetInstalledCertificatescertificateType = V2GCertificateChain)</td></tr><tr><td>Reusable State:</td></tr><tr><td>Execute Reusable State EVConnectedPreSession</td></tr><tr><td>Execute Reusable State Authorized15118 (PnC)</td></tr><tr><td>Execute Reusable State EnergyTransferStarted</td></tr></table>
+
+# 6.2.99. Page 493 - (2024-09) - TC_N_41_CS - Set Variable Monitoring - Return to FactoryDefault
+
+Moved preconfigured monitor to Prerequisite.
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Return to FactoryDefault</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_41_CS</td></tr><tr><td colspan="3">...</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station supports Monitoring and a preconfigured monitor exists with id <Preconfigured monitor id> for component EVSE and variable AvailabilityState and type = Delta and severity = <Preconfigured severity></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration state: N/a</td></tr><tr><td colspan="2">Memory state: a preconfigured monitor exists with id <Preconfigured monitor id> for component EVSE and variable AvailabilityState and type = Delta and severity = <Preconfigured severity></td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+# 6.2.100. Page 482 - (2024-09) - TC_N_63_CS - Clear Customer Information - Clear and report - customerCertificate
+
+Test case design top stop transaction was not correct for an ISO 15118 session.
+
+<table><tr><td>Test case name</td><td>Clear Customer Information - Clear and report - customerCertificate</td></tr><tr><td>Test case Id</td><td>TC_N_63_CS</td></tr><tr><td colspan="2">...</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Charging State:
+Execute Reusable State EVConnectedPreSession
+Execute Reusable State Authorized15118
+Execute Reusable State ParkingBayUnoccupied</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Clear and report - customerCertificate</td></tr><tr><td rowspan="8">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note: The Charging Station receives a SessionStopReq(Terminate) message from the EV to finish the transaction.</td></tr><tr><td>2. The Charging Station responds with a CustomerInformationResponse</td><td>1. The OCTT sends a CustomerInformationRequest with - report true AND - clear true AND - customerCertificate customer information used in the transaction</td></tr><tr><td>3. The Charging Station sends a NotifyCustomerInformationRequest</td><td>4. The OCTT responds with a NotifyCustomerInformationResponse</td></tr><tr><td>Note(s): - If tbc is True at Step 3 then step 3 and 4 will be repeated</td><td></td></tr><tr><td>6. The Charging Station responds with a CustomerInformationResponse</td><td>5. The OCTT sends a CustomerInformationRequest with - report true AND - clear false AND - customerCertificate customer information used in the transaction</td></tr><tr><td>7. The Charging Station sends a NotifyCustomerInformationRequest</td><td>8. The OCTT responds with a NotifyCustomerInformationResponse</td></tr><tr><td>Note(s): - If tbc is True at Step 7 then step 7 and 8 will be repeated</td><td></td></tr><tr><td>Tool validations</td><td colspan="2">...</td></tr></table>
+
+# 6.2.101. Page 482 - (2025-02) - TC_N_63_CS - Added missing configuration state and authorize explicit using Plug and Charge (PnC)
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>- AuthCtrl.Enabled is true</td></tr><tr><td>- AuthCtrl_DISABLERemoteAuthorization is false</td></tr><tr><td>- ISO15118Ctrl.CentralContractValidationAllowed is false</td></tr><tr><td>- ISO15118Ctrl.V2G CertificateInstallationEnabled is true</td></tr><tr><td>- ISO15118Ctrl ContractCertificateInstallationEnabled is true</td></tr><tr><td>- ISO15118Ctrl.PnCEnabled is true</td></tr><tr><td>- ISO15118Ctrl.Secld is NL</td></tr><tr><td>- ISO15118Ctrl.CountryName is secld</td></tr><tr><td>- ISO15118Ctrl.OrganizationName is OCA</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State:
+Execute Reusable State EVConnectedPreSession</td></tr><tr><td>Execute Reusable State Authorized15118 (PnC)</td></tr></table>
+
+# 6.2.102. Page 493 - (2024-09) - TC_N_41_CS - Set Variable Monitoring - Return to FactoryDefault
+
+Moved preconfigured monitor to Prerequisite.
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Return to FactoryDefault</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_41_CS</td></tr><tr><td colspan="3">...</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station supports Monitoring and a preconfigured monitor exists with id <Preconfigured monitor id> for component EVSE and variable AvailabilityState and type = Delta and severity = <Preconfigured severity></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration state: N/a</td></tr><tr><td colspan="2">Memory state: a preconfigured monitor exists with id <Preconfigured monitor id> for component EVSE and variable AvailabilityState and type = Delta and severity = <Preconfigured severity></td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+# 6.2.103. Page 493 - (2025-02) - TC_N_41_CS - Made less dependent on test case configuration variables, enables predefines monitors
+
+TC_N_41_CS: Set Variable Monitoring - Return to FactoryDefault
+
+<table><tr><td>Test case name</td><td>Set Variable Monitoring - Return to FactoryDefault</td></tr><tr><td>Test case Id</td><td>TC_N_41_CS</td></tr><tr><td>Use case Id(s)</td><td>N03</td></tr><tr><td>Requirement(s)</td><td>N03.FR.04, N04.FR.15</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>This test case describes how the CSMS requests the Charging Station to overrule a preconfigured monitor by a custom monitor. When monitoringBase is set to FactoryDefault the preconfigured monitor must return.</td></tr><tr><td>Purpose</td><td>To verify if the Charging station is able to correctly restore monitors to FactoryDefault.</td></tr><tr><td>Prerequisite(s)</td><td>Charging Station supports Monitoring and a preconfigured monitor exists with id <Preconfigured monitor id> for component EVSE and variable AvailabilityState and type = Delta and severity = <Preconfigured severity>
+- Charging Station supports Monitoring
+- A preconfigured monitor exists with id <Configured preconfigured monitor id>.</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a
+MonitoringBase has been set to FactoryDefault</td></tr><tr><td>Reusable State:
+N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds withGetMonitoringReportResponse</td><td>1. The Test System sends GetMonitoringReportRequest withrequestId = <Generated requestId></td></tr><tr><td>3. The Charging Station sends NotifyMonitoringReportRequest</td><td>4. The Test System responds withNotifyMonitoringReportResponse</td></tr><tr><td colspan="2">Note(s):- If NotifyMonitoringReportRequest.tbc is True in Step 3 then step 3 and 4 will be repeated</td></tr><tr><td colspan="2">Search NotifyMonitoringReportRequest.monitoringReportData of step 3 to get a monitoringReportData.monitorWHERE monitor_variableMonitoring.id is <Configured preconfigured monitor id>AS <preconfiguredMonitor></td></tr><tr><td>6. The Charging Station responds with aSetVariableMonitoringResponse</td><td>5. The Test System sends a SetVariableMonitoringRequest withsetMonitoringData.id <Preconfigured monitor id> ANDsetMonitoringData.type-DeltasetMonitoringData.severity <Preconfigured severity> + 1setMonitoringData.id<preconfiguredMonitor variableMonitoring.id>setMonitoringData transaction<preconfiguredMonitor variableMonitoring transaction>setMonitoringData.value<preconfiguredMonitor variableMonitoring.value>setMonitoringData.type<preconfiguredMonitor variableMonitoring.type>setMonitoringData.severity IF<preconfiguredMonitor variableMonitoring.severity> < 9 THEN<preconfiguredMonitor variableMonitoring.severity> + 1ELSE5END IFsetMonitoringData_component<preconfiguredMonitor component>setMonitoringData(variable < preconfiguredMonitor variable></td></tr><tr><td>8. The Charging Station responds with aGetMonitoringReportResponse</td><td>7. The Test System sends a GetMonitoringReportRequest with- requestId <Generated requestId>-id <Preconfigured monitor id>-componentVariablecomponent name-EVSE>-componentVariablecomponent evse id-evseId>-componentVariablevariablename-AvailabilityState-monitoringCriteria DeltaMonitoring- - id<preconfiguredMonitor variableMonitoring.id>- componentVariablecomponent<preconfiguredMonitor component>- componentVariable variable < preconfiguredMonitor variable></td></tr><tr><td>9. The Charging Station sends aNotifyMonitoringReportRequest</td><td>10. The Test System responds with aNotifyMonitoringReportResponse .</td></tr><tr><td>12. The Charging Station responds with aSetMonitoringBaseResponse withstatus Accepted</td><td>11. The Test System sends a SetMonitoringBaseRequest with- monitoringBase FactoryDefault</td></tr><tr><td>14. The Charging Station responds with a GetMonitoringReportResponse</td><td>13. The Test System sends a GetMonitoringReportRequest with - requestId <Generated requestId> -id <Preconfigured monitor id> -componentVariable.parent.name\_EVSE -componentVariable.parent.evse.id-evseld -componentVariable.parent.name-AvailabilityState -monitoringCriteria-DeltaMonitoring- -id <preconfiguredMonitor.parentMonitoring.id> -componentVariable.parent -preconfiguredMonitor.parent -componentVariable.parent <preconfiguredMonitor(variable></td></tr><tr><td>15. The Charging Station sends a NotifyMonitoringReportRequest</td><td>16. The Test System responds with a NotifyMonitoringReportResponse .</td></tr></table>
+
+# Tool validations
+
+\* Step 2:
+
+Message GetMonitoringReportResponse
+
+status Accepted
+
+\* Step 6:
+
+Message SetVariableMonitoringResponse
+
+- setMonitoringResult[0].status Accepted
+
+- setMonitoringResult[0].type Delta
+
+-setMonitoringResult[0].component.name-EVSE
+
+-setMonitoringResult[0].variable.name AvailabilityState
+
+- setMonitoringResult[0].component <preconfiguredMonitor_component>
+
+- setMonitoringResult[0].variable <preconfiguredMonitor(variable>
+
+* Step 8:
+
+Message GetMonitoringReportResponse
+
+status Accepted
+
+- Step 9:
+
+Message NotifyMonitoringReportRequest
+
+-monitor_component.name-EVSE
+
+-monitor(variable.name AvailabilityState
+
+-monitor_variableMonitoring.id<Preconfigured id>
+
+-monitor_variableMonitoring.severity <Preconfigured_severity> + 1
+
+Should contain monitor:
+
+- monitor_component <preconfiguredMonitor_component>
+
+- monitor(variable <preconfiguredMonitor(variable>
+
+- monitor variable Monitoring.id <preconfiguredMonitor variable Monitoring.id>
+
+- monitor_variableMonitoring.severity IF <preconfiguredMonitor_variableMonitoring.severity> < 9 THEN
+
+<preconfiguredMonitor variable Monitoring.severity> + 1
+
+ELSE
+
+5
+
+# END IF
+
+\* Step 15:
+
+Message NotifyMonitoringReportRequest
+
+-monitor_component.name-EVSE
+
+-monitor(variable.name AvailabilityState
+
+-monitor_variableMonitoring.severity <Preconfigured_severity> + 1
+
+-monitor_variableMonitoring.id<Preconfigured id>
+
+-monitor_variableMonitoring.severity<Preconfigured_severity> +1
+
+Should contain monitor:
+
+- monitor_component <preconfiguredMonitor_component>
+
+- monitor(variable <preconfiguredMonitor(variable>
+
+- monitor variable Monitoring.id <preconfiguredMonitor variable Monitoring.id>
+
+- monitor_variableMonitoring.severity <preconfiguredMonitor_variableMonitoring.severity>
+
+Post scenario validations:
+
+- All report parts have been received
+
+# 6.2.104. Page 495 - (2024-11) - TC_N_43_CS - Remove incorrect tool validation StatusInfo
+
+<table><tr><td>Test case name</td><td>Set Variable Monitoring - First SetMonitoringData and third SetMonitoringData are valid, but the second contains an out of range value</td></tr><tr><td>Test case Id</td><td>TC_N_43_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+Tool validations
+
+```txt
+\* Step 2:
+Message: SetVariableMonitoringResponse with (in arbitrary order):
+setMonitoringResult[1] $=$ {
+- status $=$ Accepted
+-type $=$ UpperThreshold
+-statusInfo is absent or statusInforeasonCode $=$ "NoError"
+}
+setMonitoringResult[2] $=$ {
+- status $=$ Rejected
+-type $=$ Delta
+-statusInfo is absent or statusInforeasonCode $=$ "NoError" (Removed)
+}
+setMonitoringResult[3] $=$ {
+- status $=$ Accepted
+-type $=$ LowerThreshold
+-statusInfo is absent or statusInforeasonCode $=$ "NoError"
+}
+```
+
+```txt
+Post scenario validations: - N/a
+```
+
+# 6.2.105. Page 495 - (2025-02) - TC_N_43_CS - Updating test case for using more specific configuration variables
+
+TC_N_43_CS: Set Variable Monitoring - First SetMonitoringData and third SetMonitoringData are valid, but the second contains an out of range value
+
+<table><tr><td>Test case name</td><td>Set Variable Monitoring - First SetMonitoringData and third SetMonitoringData are valid, but the second contains an out of range value</td></tr><tr><td>Test case Id</td><td>TC_N_43_CS</td></tr><tr><td>Use case Id(s)</td><td>N04</td></tr><tr><td>Requirement(s)</td><td>N/a</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>This test case describes how the CSMS requests the Charging Station to set monitoring triggers on Variables. Multiple triggers can be set for upper or lower thresholds, delta changes or periodic reporting.</td></tr><tr><td>Purpose</td><td>To verify if the Charging station is able to correctly respond when one of requested variable monitor data is out of range replace as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td>Charging Station supports MonitoringThis test case assumes the Charging Station has a numeric Component Variable <Configured numeric delta component variable> and numeric Component Variable <Configured threshold monitor component variable></td></tr></table>
+
+Before (Preparations)
+
+```txt
+Configuration State: N/a
+```
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State:
+N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td rowspan="3">2. The Charging Station responds with a SetVariableMonitoringResponse</td><td>1. The Test System sends a SetVariableMonitoringRequest with -setMonitoringData.element_name = <Configured threshold monitor-component-variable> -setMonitoringData_variable_name = <Configured threshold monitor-component-variable> -setMonitoringData_variable_name = <Configured threshold monitor-component-variable> -setMonitoringData[0].value = <Configured threshold monitor value> - setMonitoringData[0].component = <Configured threshold monitor component variable> - setMonitoringData[0].value = <Configured threshold monitor component variable> - setMonitoringData[0].value = <Configured threshold monitor component variable> - setMonitoringData[0].type = UpperThreshold trigger value> - setMonitoringData[0].type = UpperThreshold</td></tr><tr><td>- setMonitoringData[1].component = <Configured numeric delta component variable> - setMonitoringData[1].variable = <Configured numeric delta component variable> - setMonitoringData[1].value = -1.0 - setMonitoringData[1].type = Delta</td></tr><tr><td>- setMonitoringData[2].value = <Configured threshold monitor2 value> - setMonitoringData[2].component = <Configured threshold monitor component variable> - setMonitoringData[2].variable = <Configured threshold monitor component variable> - setMonitoringData[2].value = <Configured threshold monitor component variable LowerThreshold trigger value> - setMonitoringData[2].type = LowerThreshold</td></tr><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+Message: SetVariableMonitoringResponse with (in arbitrary order):
+setMonitoringResult[1] = {
+- status = Accepted
+- type = UpperThreshold
+- statusInfo is absent or statusInfo_reasonCode = "NoError"
+}
+setMonitoringResult[2] = {
+- status = Rejected
+- type = Delta
+}
+setMonitoringResult[3] = {
+- status = Accepted
+- type = LowerThreshold
+- statusInfo is absent or statusInfo_reasonCode = "NoError"
+}</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.2.106. Page 497 - (2025-02) - TC_N_45_CS - Updating test case for using more specific configuration variables
+
+TC_N_45_CS: Alert Event - Delta value exceeded
+
+<table><tr><td>Test case name</td><td>Alert Event - Delta value exceeded</td></tr><tr><td>Test case Id</td><td>TC_N_45_CS</td></tr><tr><td>Use case Id(s)</td><td>N07</td></tr><tr><td>Requirement(s)</td><td>N07.FR.06, N07.FR.07, N07.FR.18, N07.FR.19</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td>To verify if the Charging station is correctly communicating when a delta value has exceeded as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td>n/a</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+Variable monitor is configured with:
+-setMonitoringData.element.name = <Configured threshold monitor component variable>
+-setMonitoringData_element.evse.id = <Configured EVSEId>
+-setMonitoringData_value = <Configured threshold monitor value>
+-setMonitoringData_type = Delta
+-setMonitoringData_variable.name = <Configured delta monitor component variable>
+- setMonitoringData_component = <Configured numeric delta component variable>
+- setMonitoringData_variable = <Configured numeric delta component variable Delta numeric trigger value>
+- setMonitoringData_value = <Configured numeric delta component variable>
+- setMonitoringData_type = Delta
+- setMonitoringData_severity = 5</td></tr><tr><td>Set MonitoringLevel to 8</td></tr><tr><td>Notes: If componentVariable is set to "Power" or "Current", the value is set to 100.0</td></tr><tr><td>Reusable State:
+N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: If componentVariable is set to "Power" or "Current" EnergyTransferStarted will trigger the monitor. If another componentvariable is chosen a manual action is needed to trigger the monitor.</td></tr><tr><td colspan="2">1. Execute Reusable State EnergyTransferStarted or manually trigger the monitor.</td></tr><tr><td>2. The Charging Station sends a NotifyEventRequest</td><td>3. The Test System responds with a NotifyEventResponse .</td></tr><tr><td colspan="2">Note(s):
+- If tbc is True at Step 2 then step 1 and 3 will be repeated</td></tr><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+Message NotifyEventRequest
+- eventData[0].trigger Delta
+-eventData[0].component.name<Configured threshold monitor component variable>
+-eventData[0].variable.name<Configured threshold monitor component variable>
+-eventData[0].variableMonitoringld<Configured variableMonitoringld>
+-eventData[0].component <Configured numeric delta component variable>
+-eventData[0].variable <Configured numeric delta component variable>
+-eventData[0].variableMonitoringld <SetVariableMonitoringResponse.setMonitoringResult.id in preparation phase></td></tr><tr><td>Post scenario validations:
+-N/a</td></tr></table>
+
+# 6.2.107. Page 501 - (2025-02) - TC_N_51_CS - Updating test case for using more specific configuration variables
+
+# TC_N_51_CS: Set Variable Monitoring - Replace-Variable-Monitor Modifying a VariableMonitor and trigger
+
+<table><tr><td>Test case name</td><td>Set Variable Monitoring - Replace Variable Monitor
+Set Variable Monitoring - Modifying a VariableMonitor and trigger</td></tr><tr><td>Test case Id</td><td>TC_N_51_CS</td></tr><tr><td>Use case Id(s)</td><td>N07</td></tr><tr><td>Requirement(s)</td><td>N07.FR.11</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td>To verify if the Charging station is able to correctly check if the current value exceeds the new threshold as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td>Charging Station supports Monitoring</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+Variable monitor is already set with:
+setMonitoringData_component.name <Configured threshold monitor component variable> AND
+setMonitoringData_component.evse.id <Configured EVSEId> AND
+setMonitoringData_value <Configured threshold monitor value> AND
+setMonitoringData_type UpperThreshold AND
+setMonitoringData_variable.name <Configured threshold monitor component variable>
+setMonitoringData_component <Configured threshold monitor component variable>
+setMonitoringData_variable <Configured threshold monitor component variable>
+setMonitoringData_value <Configured threshold monitor component variable UpperThreshold non-trigger value>
+setMonitoringData_type UpperThreshold
+setMonitoringData_severity 5
+Set MonitoringLevel to 8
+Notes: If componentVariable is set to "Power" or "Current", the value is set to the configured maxLimit -1</td></tr><tr><td>Reusable State:
+N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Notes: If componentVariable is set to "Power" or "Current" EnergyTransferStarted will trigger the monitor. If another componentvariable is chosen a manual action is needed to trigger the monitor.</td></tr><tr><td colspan="2">1. Execute Reusable State EnergyTransferStarted or manually trigger the monitor.</td></tr><tr><td>3. The Charging Station responds with a SetVariableMonitoringResponse</td><td>2. The Test System sends a SetVariableMonitoringRequest with setMonitoringData.element.name<Configured threshold monitor_element_variable> AND setMonitoringData_element.evse_id<Configured EVSEId> AND setMonitoringData_id<Configured variableMonitoringId> AND setMonitoringData_value<Configured threshold monitor value2> AND setMonitoringData_type_UpperThreshold setMonitoringData_variable.name<Configured threshold monitor element_variable> setMonitoringData_component<Configured threshold monitor component variable> setMonitoringData_variable<Configured threshold monitor component variable> setMonitoringData_id<SetVariableMonitoringResponse.setMonitoringResult.id in preparation phase> setMonitoringData_value<Configured threshold monitor component variable UpperThreshold trigger value> setMonitoringData_type_UpperThreshold Notes: If componentVariable is set to "Power" or "Current", the value is set to 0.0</td></tr><tr><td>4. The Charging station sends a NotifyEventRequest</td><td>5. The Test System responds with a NotifyEventResponse.</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 3:Message SetVariableMonitoringResponse-setMonitoringResult[0].status Accepted-setMonitoringResult[0].type UpperThreshold-setMonitoringResult[0].severity<Configured severity>-- setMonitoringResult[0].component.name<Configured threshold monitor component variable>-- setMonitoringResult[0].variable.name<Configured threshold monitor component variable>-- setMonitoringResult[0].severity 5-- setMonitoringResult[0].component<Configured threshold monitor component variable>-- setMonitoringResult[0].variable<Configured threshold monitor component variable>* Step 4:Message NotifyEventRequest-eventData[0].trigger Alerting-eventData[0].actualValue><Configured threshold monitor value>- eventData[0].actualValue><Configured threshold monitor component variable UpperThreshold non-trigger value></td></tr><tr><td>Post scenario validations:- All report parts have been received</td></tr></table>
+
+# 6.2.108. Page 503 - (2025-02) - TC_N_52_CS - Updating test case for using more specific configuration variables
+
+# TC_N_52_CS: Set Variable Monitoring - Removing a VariableMonitor
+
+<table><tr><td>Test case name</td><td>Set Variable Monitoring - Removing a VariableMonitor</td></tr><tr><td>Test case Id</td><td>TC_N_52_CS</td></tr><tr><td>Use case Id(s)</td><td>N07</td></tr><tr><td>Requirement(s)</td><td>N07.FR.12</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td>To verify if the Charging station is able to correctly communicate when a threshold has been exceeded and the applicable monitor is removed as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td>Charging Station supports Monitoring</td></tr></table>
+
+# Before (Preparations)
+
+Configuration State: N/a
+
+# Memory State:
+
+Variable monitor is already set with:
+
+setMonitoringData_component.name<Configured threshold monitor component variable> AND
+
+setMonitoringData:Evse.id<Configured-EVSEId>AND
+
+setMonitoringData.value<Configured threshold monitor value>AND
+
+setMonitoringData.type UpperThreshold-AND
+
+setMonitoringData variable.name<Configured threshold monitor component variable>
+
+setMonitoringData_component <Configured threshold monitor component variable>
+
+setMonitoringData(variable <Configured threshold monitor component variable>
+
+setMonitoringData.value <Configured threshold monitor component variable UpperThreshold trigger value>
+
+setMonitoringData.type UpperThreshold
+
+setMonitoringData.severity $= 5$
+
+# Set MonitoringLevel to 8
+
+Notes: If componentVariable is set to "Power" or "Current", the value is set to 0.0
+
+# Reusable State:
+
+Execute Reusable State EnergyTransferStarted or manually trigger the monitor.
+
+Notes: If componentVariable is set to "Power" or "Current" EnergyTransferStarted will trigger the monitor. If another
+
+componentvariable is chosen a manual action is needed to trigger the monitor.
+
+# Main (Test scenario)
+
+<table><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ClearVariableMonitoringResponse</td><td>1. The Test System sends a ClearVariableMonitoringRequest with id<Configured variableMonitoringId> id<SetVariableMonitoringResponse.setMonitoringResult.id in preparation phase></td></tr><tr><td>4. The Charging Station responds with a GetMonitoringReportResponse</td><td>3. The Test System sends a GetMonitoringReportRequest with componentVariable.element<Configured threshold monitor component variable>componentVariable_variable<Configured threshold monitor component variable>monitoringCriteria ThresholdMonitoring</td></tr><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td colspan="2">5. Execute Reusable State StopAuthorized or manually trigger the monitor.
+Notes: If componentVariable is set to "Power" or "Current" EnergyTransferStarted will trigger the monitor. If another componentvariable is chosen a manual action is needed to trigger the monitor.</td></tr><tr><td>6. The Charging Station should not send a request for the cleared monitor</td><td></td></tr><tr><td colspan="2">Tool validations</td></tr><tr><td colspan="2">* Step 2:
+Message ClearVariableMonitoringResponse
+- clearMonitoringResult[0].status Accepted AND
+- clearMonitoringResult[0].id<Configured variableMonitoringId> - clearMonitoringResult[0].id<SetVariableMonitoringResponse.setMonitoringResult.id in preparation phase></td></tr><tr><td colspan="2">* Step 4:
+Message GetMonitoringReportResponse
+- getMonitoringResult[0].status EmptyResultSet</td></tr><tr><td colspan="2">* Step 6:
+-No NotifyEventRequest with variableMonitoringId<Configured variableMonitoringId> is send- No NotifyEventRequest with variableMonitoringId <SetVariableMonitoringResponse.setMonitoringResult.id in preparation phase> is send</td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+# 6.2.109. Page 504 - (2025-02) - TC_N_53_CS - Updating test case for using more specific configuration variables
+
+# TC_N_53_CS: Alert Event - Persistent over reboot
+
+<table><tr><td>Test case name</td><td>Alert Event - Persistent over reboot</td></tr><tr><td>Test case Id</td><td>TC_N_53_CS</td></tr><tr><td>Use case Id(s)</td><td>N07</td></tr><tr><td>Requirement(s)</td><td>N07.FR.13</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td>To verify if the Charging station is able to save the variableMonitor data persistent across reboot as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td>n/a</td></tr></table>
+
+# Before (Preparations)
+
+Configuration State: N/a
+
+# Memory State:
+
+Variable monitor is already set with:
+
+setMonitoringData_component.name<Configured threshold monitor component variable> AND
+
+setMonitoringData:Evse.id<Configured-EVSEId>AND
+
+setMonitoringData.value<Configured threshold monitor value>AND
+
+setMonitoringData.type UpperThreshold-AND
+
+setMonitoringData variable.name<Configured threshold monitor component variable>
+
+setMonitoringData_component <Configured threshold monitor component variable>
+
+setMonitoringData(variable <Configured threshold monitor component variable>
+
+setMonitoringData.value <Configured threshold monitor component variable UpperThreshold trigger value>
+
+setMonitoringData.type UpperThreshold
+
+Reusable State:
+
+Execute Reusable State Booted
+
+Main (Test scenario)
+
+<table><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetMonitoringReportResponse</td><td>1. The Test System sends a GetMonitoringReportRequest with monitoringCriteria ThresholdMonitoring</td></tr><tr><td>3. The Charging Station sends a NotifyMonitoringReportRequest</td><td>4. The Test System responds with a NotifyMonitoringReportResponse .</td></tr><tr><td colspan="2">Note(s):
+- If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr></table>
+
+# Tool validations
+
+\* Step 3:
+
+Message NotifyMonitoringReportRequest
+
+- requestId <The Id of the request> AND
+
+-monitorvariableMonitoring.id<Received monitorld from set monitor> - monitor variable Monitoring.id
+
+<SetVariableMonitoringResponse.setMonitoringResult.id in preparation phase> - monitor variable Monitoring.type UpperThreshold
+
+Post scenario validations:
+
+- All reports have been received
+
+# 6.2.110. Page 505 - (2025-02) - TC_N_56_CS - Made test case configurable using configuration variables
+
+```txt
+Before (Preparations)
+Configuration State:
+N/a
+Memory State:
+Variable monitor is configured with:
+component.evse.id<Configured-EVSEId>
+component.name-EVSE
+severity<Configured-severity>
+type-Delta
+value-1.0
+variable-name-AvailabilityState
+Variable monitor is configured with:
+setMonitoringData[O].value $= 1$
+setMonitoringData[O].type $=$ Delta
+setMonitoringData[O].severity $= 5$
+setMonitoringData[O].component $=$ <Configured non-numeric delta component variable>
+setMonitoringData[O].variable $=$ <Configured non-numeric delta component variable>
+Set MonitoringLevel to 8
+Notes :
+Take a non-numeric component variable which can easily modified to trigger the alert.
+Reusable State:
+N/a
+```
+
+```txt
+Tool validations
+\* Step 1:
+Message NotifyEventRequest
+-eventData[0].trigger Delta
+-eventData[O].component.name EVSE
+-eventData[O].variable.name AvailabilityState
+-eventData[O].component <Configured non-numeric delta component variable>
+-eventData[O].variable <Configured non-numeric delta component variable>
+-eventData[O].variableMonitoringld monitoringld of monitor set in Memory State
+Post scenario validations:
+-N/a
+```
+
+# 6.2.111. Page 506 - (2025-06) - TC_O_XX_CS - Updated configurations
+
+Some generic changes regarding the configuration of the display message testcases were needed:
+
+- Identifying which display to use has been made configurable.
+- The Start / End date time configurations have been changed to offset configurations, so the current time can be used as a base.
+
+<table><tr><td>Test case Id</td><td>TC_O_01_CS, TC_O_06_CS, TC_O_10_CS, TC_O_13_CS, TC_O_14_CS, TC_O_17_CS, TC_O_18_CS, TC_O_19_CS, TC_O_20_CS, TC_O_22_CS, TC_O_28_CS, TC_O_30_CS, TC_O_32_CS, TC_O_36_CS, TC_O_37_CS, TC_O_38_CS, TC_O_39_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>n. The Charging Station responds with a SetDisplayMessageResponse</td><td>n. The Test System sends a SetDisplayMessageRequest with message.display <Configured display component variable>
+(Omitted when left empty)</td></tr></table>
+
+<table><tr><td>Test case Id</td><td>TC_O_02_CS, TC_O_04_CS, TC_O_07_CS, TC_O_08_CS, TC_O_09_CS, TC_O_11_CS, TC_O_12_CS, TC_O_34_CS, TC_O_35_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>...</td></tr><tr><td>Memory State:</td></tr><tr><td>SetDisplayMessage</td></tr><tr><td>Reusable State:</td></tr><tr><td>...</td></tr></table>
+
+New Memory state:
+
+Table 7. SetDisplayMessage
+
+<table><tr><td>State</td><td>SetDisplayMessage</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>This will set a display message at the Charging Station.</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The Test System sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>messagepriority <Configured priority>message.state <Omitted, unless specifically described at the testcase>message.display <Configured display component variable>(Omitted when left empty)message.message.format <Configured Message Format>message.message(content <Configured Message></td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+(Message: SetDisplayMessageResponse)
+status is Accepted</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+# Specific O testcase changes:
+
+<table><tr><td>Test case name</td><td>Set Display Message - Replace DisplayMessage</td></tr><tr><td>Test case Id</td><td>TC_O_12_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The Test System sends a SetDisplayMessageRequest with message.id <Generated displayMessageId from before (preparation) steps>
+message.message.content <Different message to indicate the message was replaced></td></tr><tr><td colspan="2">Note(s):
+- The display message is replaced by a new one.</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Set Display Message - State Faulted</td></tr><tr><td>Test case Id</td><td>TC_O_39_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The Test System sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>message.priority <Configured Priority>message.state Faultedmessage.message.content <Message indicating the Charging Station is in a Faulted state>message.display <Configured display component variable>(Omitted when left empty)</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Set Display Message - Display message atStartTime</td></tr><tr><td>Test case Id</td><td>TC_O_13_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The Test System sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>messagepriority <Configured Priority>message.startDateTime <Current dateTime + Configured Start Date Time Offset>message.display <Configured display component variable>(Omitted when left empty)</td></tr><tr><td>4. The Charging Station responds with a GetDisplayMessagesResponse</td><td>3. The Test System sends a GetDisplayMessagesRequest with id <Generated displayMessageId></td></tr><tr><td>5. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>6. The Test System responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 5 then step 5 and 6 will be repeated- Wait till <Configured Start Date Time Offset> seconds have passed- The display message should be displayed after <Configured Start Date Time Offset> seconds.</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Set Display Message - Remove message after EndTime</td></tr><tr><td>Test case Id</td><td>TC_O_14_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The Test System sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>messagepriority <Configured Priority>messageEndTimeTime <CurrentDateTime + Configured End Date Time Offset>message.display <Configured display component variable>(Omitted when left empty)</td></tr><tr><td>4. The Charging Station responds with a GetDisplayMessagesResponse</td><td>3. The Test System sends a GetDisplayMessagesRequest with id <Generated displayMessageId></td></tr><tr><td>5. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>6. The Test System responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 5 then step 5 and 6 will be repeated-Wait till <Configured End Date Time Offset> seconds have passed-The display message is displayed and removed after <Configured End Date Time Offset> seconds.</td></tr><tr><td>8. The Charging Station responds with a GetDisplayMessagesResponse</td><td>7. The Test System sends a GetDisplayMessagesRequest with id <Generated displayMessageId>requestId <Generated requestId></td></tr></table>
+
+<table><tr><td>Test case name</td><td>Set Display Message - Specific transaction - Remove message after EndTime</td></tr><tr><td>Test case Id</td><td>TC_O_28_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The Test System sends a SetDisplayMessageRequest with message.id <Generated displayMessageId> message_transactionId <Generated transactionId> message.priority <Configured Priority message.endDateTime <CurrentDateTime + Configured End Date Time Offset> message.display <Configured display component variable>(Omitted when left empty)</td></tr><tr><td colspan="2">Note(s):
+- The display message should be displayed.
+- Waiting <Configured End Date Time Offset> seconds.
+- The display message is not being displayed anymore after <Configured End Date Time Offset> seconds.</td></tr><tr><td>4. The Charging Station responds with a GetDisplayMessagesResponse</td><td>3. The Test System sends a GetDisplayMessagesRequest with id <Generated displayMessageId></td></tr></table>
+
+<table><tr><td>Test case name</td><td>Set Display Message - NotSupportedMessageFormat</td></tr><tr><td>Test case Id</td><td>TC_O_19_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The Test System sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>
+message(message.format <ConfiguredUnsupported Message Format>
+message.display <Configured display component variable>
+(Omitted when left empty)</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Set Display Message - Second Alwaysfront priority</td></tr><tr><td>Test case Id</td><td>TC_O_24_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The Test System sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>message.priority AlwaysFront</td></tr><tr><td>4. The Charging Station responds with a SetDisplayMessageResponse</td><td>3. The Test System sends a SetDisplayMessageRequest with message.id <Configured displayMessage2Id>message.priority AlwaysFront</td></tr><tr><td>6. The Charging Station responds with a GetDisplayMessagesResponse</td><td>5. The Test System sends a GetDisplayMessagesRequest with id <Configured displayMessageId></td></tr><tr><td>6. The Charging Station responds with a GetDisplayMessagesResponse</td><td>5. The Test System sends a GetDisplayMessagesRequest with id <Configured displayMessage2Id></td></tr><tr><td>7. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>8. The Test System responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s):
+- If tbc is True at Step 7 then step 7 and 8 will be repeated
+- The message from step 1 is NOT displayed anymore and is replaced by the message from step 5.</td></tr><tr><td>Tool validations</td></tr><tr><td>* Step 2:
+Message SetDisplayMessageResponse
+- status Accepted
+* Step 4:
+Message SetDisplayMessageResponse
+- status Accepted
+* Step 6:
+Message GetDisplayMessagesResponse
+- status Unknown
+* Step 6:
+Message GetDisplayMessagesResponse
+- status Accepted
+* Step 7:
+Message NotifyDisplayMessagesRequest
+- requestId <Generated requestId></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.2.112. Page 520 - (2025-02) - TC_O_15_CS - Test case removed
+
+This test case has been removed.
+
+<table><tr><td>Test case name</td><td>Set Display Message - Language preference of the EV Driver</td></tr><tr><td>Test case Id</td><td>TC_O_15_CS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+# 6.2.113. Page 530 - (2025-02) - TC_O_28_CS - Transaction id should be specified for DisplayMessage
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The Test System sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>
+message_transactionId <Generated transactionId>
+message.priority <Configured Priority
+message.endDateTime <Current dateTime + 60 seconds></td></tr><tr><td colspan="2">[...]</td></tr></table>
+
+# 6.2.114. Page 533 - (2025-02) - TC_O_32_CS - Made notes about display behaviour more explicit
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The Test System sends a SetDisplayMessageRequest with message.id <Generated displayMessageId> message_transactionId <Received transactionId> AND message.priority AlwaysFront</td></tr><tr><td colspan="2">Note(s):
+- Display message <Generated displayMessageId> is shown</td></tr><tr><td>4. The Charging Station responds with a SetDisplayMessageResponse</td><td>3. The Test System sends a SetDisplayMessageRequest with message.id <Configured displayMessage2Id> message_transactionId <Received transactionId> AND messagepriority AlwaysFront</td></tr><tr><td colspan="2">Note(s):
+- Display message <Generated displayMessage1Id> is not displayed anymore
+- Display message <Generated displayMessage2Id> is shown</td></tr><tr><td>6. The Charging Station responds with a GetDisplayMessagesResponse</td><td>5. The Test System sends a GetDisplayMessagesRequest with id <Generated displayMessageId></td></tr><tr><td>8. The Charging Station responds with a GetDisplayMessagesResponse</td><td>7. The Test System sends a GetDisplayMessagesRequest with id <Generated displayMessageId> requestId <Generated requestId></td></tr><tr><td>9. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>10. The Test System responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">11. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">12. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">13. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">14. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">Note(s):
+- The display message is not displayed anymore
+- Display message <Generated displayMessage2Id> is not displayed anymore</td></tr><tr><td>16. The Charging Station responds with a GetDisplayMessagesResponse</td><td>15. The Test System sends a GetDisplayMessagesRequest with id <Generated displayMessageId></td></tr></table>
+
+# 6.2.115. Page 544 - (2025-02) - TC_O_39_CS - Wait for StatusNotificationRequest or NotifyEventRequest
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The Test System sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>messagepriority <Configured Prioritymessage.state <Configured State>message.message Faulted</td></tr><tr><td colspan="2">Note(s): The display message should NOT be displayed.</td></tr><tr><td colspan="2">Manual Action: Set the Charging Station to state Faulted.</td></tr><tr><td>3. The Charging Station notifies the CSMS about the status change of the Charging Station.</td><td>4. The Test System responds accordingly.</td></tr><tr><td colspan="2">Note(s):The display message should be displayed now.- Step 3/4 are used to detect if the Charging Station status has changed.- The display message should be displayed now.</td></tr><tr><td colspan="2">Manual Action: Set the Charging Station back to state Available.</td></tr><tr><td>5. The Charging Station notifies the CSMS about the status change of the Charging Station.</td><td>6. The Test System responds accordingly.</td></tr><tr><td colspan="2">Note(s):
+The display message should NOT be displayed anymore.
+- Step 5/6 are used to detect if the Charging Station status has changed.
+- The display message should NOT be displayed anymore.</td></tr><tr><td>8. The Charging Station responds with a GetDisplayMessagesResponse</td><td>7. The Test System sends a GetDisplayMessagesRequest with id <Generated displayMessageId>
+requestId <Generated requestId></td></tr><tr><td>9. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>10. The Test System responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s): If tbc is True at Step 9 then step 9 and 10 will be repeated</td></tr></table>
+
+# Tool validations
+
+\* Step 2:
+
+Message SetDisplayMessageResponse
+
+status Accepted
+
+\* Step 3:
+
+At least one of te following messages must be sent:
+
+Message: StatusNotificationRequest
+
+- connectorStatus Faulted or Unavailable
+
+Message: NotifyEventRequest
+
+-eventData[0].trigger must be Delta
+
+-eventData[0].actualValue must be Faulted or Unavailable
+
+-eventData[0].component.name must be Connector
+
+-eventData[0].variable.name must be AvailabilityState
+
+- evse.id <not omitted>
+
+- connector.id <not omitted>
+
+Message: NotifyRequest
+
+-eventData[0].trigger must be Delta
+
+-eventData[0].actualValue must be Faulted
+
+-eventData[0].component.name must be ChargingStation
+
+-eventData[0].variable.name must be AvailabilityState
+
+- evse.id <omitted>
+
+- connector.id <omitted>
+
+* Step 5:
+
+At least one of te following messages must be sent:
+
+Message: StatusNotificationRequest
+
+- connectorStatus Available
+
+Message: NotifyRequest
+
+-eventData[0].trigger must be Delta
+
+-eventData[0].actualValue must be Available
+
+-eventData[0].component.name must be Connector
+
+-eventData[0].variable.name must be AvailabilityState
+
+- evse.id <not omitted>
+
+- connector.id <not omitted>
+
+Message: NotifyRequest
+
+-eventData[0].trigger must be Delta
+
+-eventData[0].actualValue must be Available
+
+-eventData[0].component.name must be ChargingStation
+
+-eventData[0].variable.name must be AvailabilityState $^+$ \* Step 8:
+
+Message GetDisplayMessagesResponse
+
+status Accepted
+
+- Step 9:
+
+Message NotifyDisplayMessagesRequest
+
+- requestId <Generated requestId>
+
+-state Faulted
+
+Post scenario validations:
+
+-N/a
+
+# 6.2.116. Page 555 - (2024-11) - Remove StatusNotificationRequest from Authorized reusable state Main B steps
+
+<table><tr><td colspan="2">Main B (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aRequestStartTransactionResponse</td><td>1. The OCTT sends a RequestStartTransactionRequestwith idToken.idToken<Configured valid_idtoken_idtoken>_idToken.type<Configured valid_idtoken_type>_evseld<Configured evseld></td></tr><tr><td>3. The Charging Station sends anauthorizeRequestNote(s):- This step needs to be executed whenAuthCtrl AUTHRemoteStart is true, unless (AuthEnabled isimplemented with mutability ReadOnly AND the value is set tofalse) ORthe idToken is cached.In case the idToken is used for a reservation, sending theAuthorizationRequest message is optional.</td><td>4. The OCTT responds with an AuthorizationResponsewith idTokenInfo.status Accepted</td></tr><tr><td colspan="2"></td></tr><tr><td>5. The Charging Station sends a TransactionEventRequestNote(s):- This step needs to be executed when TxStartPoint containsAuthorized OR the transaction already started. So in the caseTxStartPoint contains ParkingBayOccupancy or (EVConnected, inthe case this testcase was initiated from stateEVConnectedPreSession.)</td><td>6. The OCTT responds with a TransactionEventResponseNote(s):- The first TransactionEventRequest sent after authorizationcontains the idToken field. The TransactionEventResponse of thisrequest message contains idTokenInfowith status Accepted</td></tr></table>
+
+# 6.2.117. Page 560 - (2025-04) - Reusable states StopAuthorized & Deauthorized
+
+Based on TWG and CWG discussions the transaction validations of the Test system have been made more flexible and validate accordingly based on the different TxStartPoint and TxStopPoint combinations. However, the reusable states described at part 6 did not reflect this yet.
+
+<table><tr><td>State</td><td>StopAuthorized</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>This state will prepare the Charging Station, so that it is in a state where the charging session is authorized to stop. This can be done in two ways (Configurable at Test System):
+A. Using local authorization
+B. Using a RequestStopTransactionRequest</td></tr></table>
+
+<table><tr><td colspan="2">Main A (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Notes(s): The tool will wait for <Configured Transaction Duration> seconds</td></tr><tr><td colspan="2">Manual Action: Present the same idToken as used to start the transaction.</td></tr><tr><td>1. The Charging Station sends a TransactionEventRequest</td><td>2. The Test System responds with a TransactionResponse With idTokenInfo.status is Accepted</td></tr><tr><td colspan="2">Note(s): This step is optional</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The Test System responds with a TransactionResponse With idTokenInfo.status is Accepted</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:</td></tr><tr><td>Message: TransactionRequest</td></tr><tr><td>- triggerReason must be StopAuthorized</td></tr><tr><td>- idToken omit OR</td></tr><tr><td>- idToken.idToken <Configured valid_idtoken_idtoken> AND</td></tr><tr><td>- idToken.type <Configured valid_idtoken_type></td></tr><tr><td>* Step 3:</td></tr><tr><td>Message: TransactionRequest</td></tr><tr><td>- triggerReason must be ChargingStateChanged</td></tr><tr><td>- transactionInfo.chargingState must be EVConnected</td></tr><tr><td>If TxStopPoint contains Authorized or PowerPathClosed or EnergyTransfer</td></tr><tr><td>Then the last of the two TransactionRequest messages from step 1 and 3 needs to contain:</td></tr><tr><td>- eventType must be Ended</td></tr><tr><td>- transactionInfo.stoppedReason must be Local or omitted</td></tr><tr><td>Else</td></tr><tr><td>Then both TransactionRequest messages need to contain:</td></tr><tr><td>- eventType must be Updated</td></tr></table>
+
+<table><tr><td colspan="2">Main B (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a RequestStopTransactionResponse</td><td>1. The Test System sends a RequestStopTransactionRequest with transactionId <transactionId provided by the Charging Station in TransactionRequest></td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The Test System responds with a TransactionEventResponse</td></tr><tr><td colspan="2">Note(s): This step is optional</td></tr><tr><td>5. The Charging Station sends a TransactionEventRequest</td><td>6. The Test System responds with a TransactionEventResponse With idTokenInfo.status is Accepted</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:</td></tr><tr><td>Message: RequestStopTransactionResponse</td></tr><tr><td>- status must be Accepted</td></tr><tr><td>* Step 3:</td></tr><tr><td>Message: TransactionRequest</td></tr><tr><td>- triggerReason must be RemoteStop</td></tr><tr><td>* Step 5:</td></tr><tr><td>Message: TransactionRequest</td></tr><tr><td>- triggerReason must be ChargingStateChanged</td></tr><tr><td>- transactionInfo.chargingState must be EVConnected</td></tr><tr><td>If TxStopPoint contains Authorized or PowerPathClosed or EnergyTransfer</td></tr><tr><td>Then the last of the two TransactionRequest messages from step 3 and 5 needs to contain:</td></tr><tr><td>- eventType must be Ended</td></tr><tr><td>- transactionInfo.stoppedReason must be Remote</td></tr><tr><td>Else</td></tr><tr><td>Then both TransactionRequest messages need to contain:</td></tr><tr><td>- eventType must be Updated</td></tr><tr><td>Post scenario validations:</td></tr><tr><td>State is StopAuthorized</td></tr></table>
+
+New reusable state Deauthorized. This is not a change to the testcases It already existed on the background, but is now formally defined at part 6.
+
+# 6.2.118. Deauthorized
+
+<table><tr><td>State</td><td>Deauthorized</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>This reusable state will set the Charging Station to a state in which the transaction will be deauthorized.</td></tr><tr><td>Prerequisite</td><td>Reusable State Authorized is executed.</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+Continues executing transaction reusable states in order until the first TransactionRequest is received based on the configured TxStartPoint.</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends a TransactionEventRequest</td><td>2. The Test System responds with a TransactionResponse With idTokenInfo.status is Invalid</td></tr><tr><td>3. The Charging Station sends a TransactionRequest Note(s): - Step 3 and 4 are relevant when AuthCtrl_STOPTxOnInvalidld is true</td><td>4. The Test System responds with a TransactionResponse</td></tr><tr><td>6. The Charging Station sends a UnlockConnectorResponse</td><td>5. The Test System sends a UnlockConnectorRequest Note(s): - Step 5 and 6 are executed when the connector is locked and the transaction gets deauthorized.</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:</td></tr><tr><td>Message: TransactionRequest</td></tr><tr><td>-idToken.idToken <Configured valid_idtoken_idtoken> AND</td></tr><tr><td>-idToken.type <Configured valid_idtoken_type></td></tr><tr><td>* Step 3:</td></tr><tr><td>Message: TransactionRequest</td></tr><tr><td>-triggerReason must be Deauthorized</td></tr><tr><td>- transactionInfo.chargingState must be EVConnected or SuspendedEVSE</td></tr><tr><td>If TxStopPoint contains Authorized or PowerPathClosed or EnergyTransfer</td></tr><tr><td>Then :</td></tr><tr><td>-eventType must be Ended</td></tr><tr><td>- stoppedReason must be DeAuthorized</td></tr><tr><td>Else:</td></tr><tr><td>-eventType must be Updated</td></tr></table>
+
+# 6.2.119. Page 566 - (2025-02) - Reusable state RenegotiateChargingLimits
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">[...]</td></tr><tr><td>7. The Charging Station sends a TransactionEventRequest</td><td>8. The Test System responds with a TransactionEventResponse</td></tr><tr><td colspan="2">Note: Steps 7 and 8 are optional, but can also repeat until chargingState is Charging.</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>[...]</td></tr><tr><td>* Step 5:</td></tr><tr><td>Message: NotifyEVChargingScheduleRequest)</td></tr><tr><td>- evseld <Configured evseld></td></tr><tr><td>* Step 7:</td></tr><tr><td>Message: TransactionEventRequest</td></tr><tr><td>-triggerReason must be ChargingStateChanged</td></tr><tr><td>-transactionInfo.chargingState must be Charging -evseld <Configured evseld></td></tr><tr><td>Post scenario validations:</td></tr><tr><td>N/a</td></tr></table>
+
+# 6.2.120. Page 573/151 - (2025-04) - Removed Main steps B from IdTokenCached reusable state and added IdTokenCached15118
+
+The described steps at step B were incorrect and the originally intended split does not exist in any of the currently existing testcases.
+
+In addition, a separate IdTokenCached15118 reusable state has been added for ISO 15118 sessions. The affected testcases are TC_C_54_CS and TC_C_55_CS.
+
+IdTokenCached
+
+<table><tr><td>State</td><td>IdTokenCached</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>An idToken is stored in the Authorization Cache of the Charging Station.</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State ParkingBayoccupied</td></tr><tr><td colspan="2">2. Execute Reusable State Authorized</td></tr><tr><td colspan="2">Note(s): Step 3 and onwards are executed in case the idToken at step 2 was Accepted.</td></tr><tr><td colspan="2">3. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">4. Execute Reusable State EnergyTransferStarted</td></tr><tr><td colspan="2">5. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">6. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">7. Execute Reusable State ParkingBayUnoccupied</td></tr></table>
+
+# Tool validations
+
+N/a
+
+# IdTokenCached15118
+
+<table><tr><td>State</td><td>IdTokenCached15118</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>A 15118-idToken is stored in the Authorization Cache of the Charging Station.</td></tr></table>
+
+# Before (Preparations)
+
+Configuration State:
+
+N/a
+
+Memory State:
+
+N/a
+
+Reusable State(s):
+
+N/a
+
+# Main (Test scenario)
+
+Charging Station CSMS
+
+1. Execute Reusable State ParkingBayoccupied
+2. Execute Reusable State EVConnectedPreSession
+3. Execute Reusable State Authorized15118
+4. Execute Reusable State EnergyTransferStarted
+5. Execute Reusable State StopAuthorized (Remote)
+6. Execute Reusable State EVDisconnected
+7. Execute Reusable State ParkingBayUnoccupied
+
+# Tool validations
+
+N/a
+
+<table><tr><td>Test case name</td><td>Authorization using Contract Certificates 15118 - Offline - ContractValidationOffline is true</td></tr><tr><td>Test case Id</td><td>TC_C_54_CS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+# Before (Preparations)
+
+Configuration State:
+
+···
+
+Memory State:
+
+CertificateInstalled for certificateType V2GRootCertificate
+
+CertificateInstalled for certificateType MORootCertificate
+
+RenewV2GChargingStationCertificate (If none are present, when checking with GetInstalledCertificates.certificateType =
+
+V2GCertificateChain)
+
+IdTokenCached15118 for <Configured valid ISO 15118 IdToken> (If implemented)
+
+IdTokenLocalAuthList for <Configured valid ISO 15118 IdToken> (If implemented)
+
+Reusable State(s):
+
+N/a
+
+<table><tr><td>Test case name</td><td>Authorization using Contract Certificates 15118 - Offline - ContractValidationOffline is false</td></tr><tr><td>Test case Id</td><td>TC_C_55_CS</td></tr><tr><td colspan="2">...</td></tr><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:</td></tr><tr><td>...</td></tr><tr><td>Memory State:</td></tr><tr><td>CertificateInstalled for certificateType V2GRootCertificate</td></tr><tr><td>CertificateInstalled for certificateType MORootCertificate</td></tr><tr><td>RenewV2GChargingStationCertificate (If none are present, when checking with GetInstalledCertificatesCertificateType = V2GCertificateChain)</td></tr><tr><td>IdTokenCached15118 for <Configured valid ISO 15118 IdToken> (If implemented)</td></tr><tr><td>IdTokenLocalAuthList for <Configured valid ISO 15118 IdToken> (If implemented)</td></tr><tr><td>Reusable State(s):</td></tr><tr><td>N/a</td></tr></table>
+
+# 6.2.121. Page 574 - (2025-04) - IdTokenLocalAuthList memory state - set Enable to true if implemented
+
+<table><tr><td>State</td><td>IdTokenLocalAuthList</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>An valid idToken is stored in the Local Authorization List of the Charging Station.</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+LocalAuthListCtrl.Enabled is true (If implemented)</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+# 6.2.122. Page 575 - (2024-09) - Reusable state RenewChargingStationCertificate expects a reconnection [784]
+
+If a valid certificate is installed, then charging station must use it. This involves reconnecting to set up a new TLS with the new certificate. If the charging station does not do so automatically, then OCTT will force it by sending a Reset command.
+
+<table><tr><td>State</td><td>RenewChargingStationCertificate</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>The ChargingStationCertificate is renewed using A02/A03</td></tr><tr><td colspan="2">…</td></tr></table>
+
+<table><tr><td>State</td><td colspan="2">RenewChargingStationCertificate</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequest With requestedMessageSignChargingStationCertificate</td></tr><tr><td>3 The Charging Station sends a SignCertificateRequest</td><td>4. The OCTT responds with a SignCertificateResponseWith status Accepted</td></tr><tr><td>6. The Charging Station responds with a CertificateSignedResponse</td><td>5. The OCTT sends a CertificateSignedRequest With certificateChain <Certificate generated from the received CSR from step 3 and signed by the provided CSMS Root certificate> certificateType ChargingStationCertificate</td></tr><tr><td colspan="2">If the certificate is valid, then Charging Station should reconnect with the new certificate. OCTT waits some time for a reconnection, and if that does not occur, will send a Reset command to Charging Station to force a reconnection.</td></tr><tr><td>7. The Charging Station reconnects.</td><td></td></tr><tr><td>8. If the reconnect was forced by a Reset: The Charging Station sends a BootNotificationRequest</td><td>9. OCTT responds with a BootNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: TriggerMessageResponse
+- status must be Accepted
+* Step 3:
+Message: SignCertificateRequest
+-csr must contain <An CSR that meets the following requirements: When using RSA or DSA the key must be at least 2048 bits long. and when using elliptic curve cryptography the key must be at least 224 bits long. The received CSR must be transmitted as described in RFC 2986 and then encoded in Privacy-Enhanced Mail (PEM) format.>
+* Step 6:
+Message: CertificateSignedResponse
+- status must be Accepted
+* Step 7:
+Charging Station must reconnect with new certificate.</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+# 6.2.123. Page 575 - (2025-02) - Reusable state RenewChargingStationCertificate must not do a Reset [5281]
+
+This memory state was sending a Reset when Charging Station was dropping the connection in time, but according to A02.FR.08 a Reset is not needed. It is enough to just close the websocket connection.
+
+<table><tr><td>State</td><td>RenewChargingStationCertificate</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>The ChargingStationCertificate is renewed using A02/A03</td></tr><tr><td colspan="2">…</td></tr></table>
+
+<table><tr><td>State</td><td colspan="2">RenewChargingStationCertificate</td></tr><tr><td rowspan="6">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>6. The Charging Station responds with a CertificateSignedResponse</td><td>5. The OCTT sends a CertificateSignedRequest With certificateChain <Certificate generated from the received CSR from step 3 and signed by the provided CSMS Root certificate> certificateType ChargingStationCertificate</td></tr><tr><td colspan="2">If the certificate is valid, then Charging Station should reconnect with the new certificate. Test System waits some time for a reconnection, and if that does not occur, will drop the connection to force a reconnection.</td></tr><tr><td>7. The Charging Station reconnects.</td><td></td></tr><tr><td>8. If Charging Station rebooted: The Charging Station sends a BootNotificationRequest</td><td>9. Test System responds with a BootNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">...</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+# 6.3. CSMS
+
+# 6.3.1. Page 593 - (2025-04) - TC_A_11_CSMS - Added post scenario validation for clarification
+
+Note: This erratum extends erratum: Page 593 - (2024-09) - TC_A_11_CSMS - Reconnect using new client certificate
+
+<table><tr><td>Test case name</td><td>Update Charging Station Certificate by request of CSMS - Success - Charging Station Certificate</td></tr><tr><td>Test case Id</td><td>TC_A_11_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>N/a</td></tr><tr><td>Post scenario validations:
+The Test System and the CSMS are connected.</td></tr></table>
+
+# 6.3.2. Page 593 - (2024-09) - TC_A_11_CSMS - Reconnect using new client certificate
+
+Note: This erratum is extended by erratum: Page 593 - (2025-04) - TC_A_11_CSMS - Added post scenario validation for clarification
+
+The testcase is missing steps to reconnect using the new client certificate.
+
+<table><tr><td>Test case name</td><td>Update Charging Station Certificate by request of CSMS - Success - Charging Station Certificate</td></tr><tr><td>Test case Id</td><td>TC_A_11_CSMS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State RenewChargingStationCertificate</td></tr><tr><td>2. The OCTT disconnects its current connection and reconnects to the CSMS with the new certificate.</td><td>3. The CSMS accepts the incoming connection request using the new certificate.</td></tr></table>
+
+# 6.3.3. Page 596 - (2024-09) - TC_A_14_CSMS - Update Charging Station Certificate by request of CSMS - Invalid certificate
+
+SecurityEventNotification(InvalidChargingStationCertificate) has been added.
+
+<table><tr><td>Test case name</td><td>Update Charging Station Certificate by request of CSMS - Invalid certificate</td></tr><tr><td>Test case Id</td><td>TC_A_14_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Certificate by request of CSMS - Invalid certificate</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a TriggerMessageResponse With status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>3 The OCTT sends a SignCertificateRequest With csv <Configured CSR> certificateType ChargingStationCertificate</td><td>4. The CSMS responds with a SignCertificateResponse</td></tr><tr><td>6. The OCTT responds with a CertificateSignedResponse With status Rejected</td><td>5. The CSMS sends a CertificateSignedRequest</td></tr><tr><td>7. The OCTT sends a SecurityEventNotificationRequest with type = InvalidChargingStationCertificate</td><td>8. The CSMS responds with a SecurityEventNotificationResponse</td></tr><tr><td>Tool validations</td><td colspan="2">...</td></tr></table>
+
+# 6.3.4. Page 597 - (2025-04) - TC_A_19_CSMS - Added main steps and clarified tool validations
+
+Clarified the validation steps regarding how the CSMS rejects the connection and added reconnect at the end of the testcase, so it does not end without a connection.
+
+<table><tr><td>Test case name</td><td>Upgrade Charging Station Security Profile - Accepted</td></tr><tr><td>Test case Id</td><td>TC_A_19_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to set a new NetworkConnectionProfile with a security profile level one higher than currently configured</td></tr><tr><td>2. The Test System responds with a SetNetworkProfileResponse With status Accepted</td><td>1. The CSMS sends a SetNetworkProfileRequest</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to change the NetworkConfigurationPriority to one that contains the configurationSlot of the new NetworkConnectionProfile from step 1</td></tr><tr><td>4. The Test System responds with a SetVariablesResponse with status Accepted</td><td>3. The CSMS sends a SetVariablesRequest</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to reboot the Charging Station</td></tr><tr><td>6. The Test System responds with a ResetResponse with status Accepted</td><td>5. The CSMS sends a ResetRequest</td></tr><tr><td>7. The Test System reconnects to the CSMS using the new NetworkProfile, containing the upgraded security profile <Configured securityProfile + 1>.</td><td>8. The CSMS accepts the connection attempt.</td></tr><tr><td colspan="2">9. Execute Reusable State Booted</td></tr><tr><td>10. The Test System reconnects to the CSMS using the original NetworkProfile, containing the lower security profile. Note(s): - This is done to ensure that the CSMS does not accept a connection using the lower security profile anymore.</td><td>11. The CSMS shall not accept the connection attempt.</td></tr><tr><td>12. The Test System reconnects to the CSMS using the new NetworkProfile, containing the upgraded security profile</td><td></td></tr><tr><td><Configured securityProfile + 1>.</td><td></td></tr><tr><td>Note(s):</td><td></td></tr><tr><td>- This is done to restore the connection before ending the testcase.</td><td></td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:</td></tr><tr><td>Message SetNetworkProfileRequest</td></tr><tr><td>- connectionData.messageTimeout <Configured messageTimeout></td></tr><tr><td>- connectionData.ocpptInterface <Configured ocpptInterface></td></tr><tr><td>- connectionData.ocppTransport JSON</td></tr><tr><td>- connectionData.ocppVersion OCPP20</td></tr><tr><td>- connectionData.securityProfile <Configured securityProfile + 1></td></tr><tr><td>* Step 3:</td></tr><tr><td>Message SetVariablesRequest</td></tr><tr><td>setVariableData:</td></tr><tr><td>- variable.name = "NetworkConfigurationPriority"</td></tr><tr><td>- component.name = "OCPPCommCtrl"</td></tr><tr><td>- attributeValue = <contains configurationSlot provided at step 1></td></tr><tr><td>* Step 11:</td></tr><tr><td>When upgrading a Charging Station to a higher security profile, a CSMS has several options regarding which endpoint to use. This affects the way the CSMS is able to detect it needs to reject the incoming connection attempt.</td></tr><tr><td>In case of having upgraded from security profile 2 to 3, but there is an incoming connection attempt using security profile 2:</td></tr><tr><td>When the same endpoint is used, then it depends on the CSMS endpoint configuration.</td></tr><tr><td>- When the CSMS does a full switch and only allows TLS handshakes when a client certificate is provided, then the TLS handshake is rejected.</td></tr><tr><td>- When the CSMS only requires this Charging Station to use a client certificate, then it accepts the TLS handshake (because it will be unable to detect which Charging Station is connecting) and it rejects the HTTP request to establish the WebSocket connection.</td></tr><tr><td>When a different port or a whole different endpoint is used for the upgrade, then on the original endpoint the CSMS accepts the TLS handshake and it rejects the HTTP request to establish the WebSocket connection (because this Charging Station is not allowed to connect with security profile 2 anymore).</td></tr><tr><td>In case of security profile 1, the case is always the same. The CSMS shall always reject the HTTP request to establish the WebSocket connection, because TLS is required for this Charging Station.</td></tr><tr><td>Post scenario validations:</td></tr><tr><td>The Test System and the CSMS are connected.</td></tr></table>
+
+# 6.3.5. Page 597 - (2024-09) - TC_A_19_CSMS - Added additional information regarding the use of the client certificates
+
+Added additional information regarding the use of the client certificates.
+
+<table><tr><td>Test case name</td><td>Upgrade Charging Station Security Profile - Accepted</td></tr><tr><td>Test case Id</td><td>TC_A_19_CSMS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+If configured <Security profile> is 2, then RenewChargingStationCertificate
+The OCTT uses this certificate during the TLS handshake when connecting with security profile 3.</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+# 6.3.6. Page 597 - (2024-09) - TC_A_19_CSMS - Removed validation of OcppCsmsUrl [O20-4355]
+
+Validation of OcppCsmsUrl has been removed, because in some implementations the URL changes with the security profile.
+
+<table><tr><td>Test case name</td><td colspan="2">Upgrade Charging Station Security Profile - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_19_CSMS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message SetNetworkProfileRequest
+- connectionData.messageTimeout <Configured messageTimeout>
+- connectionData.ocppCsmsUrl <Configured ocppCsmsUrl>
+- connectionData.ocpptInterface <Configured ocpptInterface>
+- connectionData.ocppTransport JSON
+- connectionData.ocppVersion OCPP20
+- connectionData.securityProfile <Configured securityProfile + 1>
+* Step 3:
+Message SetVariablesRequest
+setVariableData:
+- variable.name = "NetworkConfigurationPriority"
+- component.name = "OCPPCommCtrlr"
+- attributeValue = <contains configurationSlot provided at step 1></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.3.7. Page 637 - (2024-11) - TC_C_50_CSMS - Changed reference to configured valid idToken to a specific eMAID idToken
+
+For ISO 15118 plug & charge the Charging Station always needs to use an eMAID idToken, which equals the CN of the configured contract certificate.
+
+<table><tr><td>Test case name</td><td>Authorization using Contract Certificates 15118 - Online - Local contract certificate validation - Accepted</td></tr><tr><td>Test case Id</td><td>TC_C_50_CSMS</td></tr><tr><td>Use case Id(s)</td><td>C07</td></tr><tr><td>Requirement(s)</td><td>C07.FR.04</td></tr><tr><td>System under test</td><td>CSMS</td></tr><tr><td>Description</td><td>The Charging Station is able to authorize with contract certificates when it supports ISO 15118.</td></tr><tr><td>Purpose</td><td>To verify if the CSMS is able to validate the certificate hash data and the provided eMAID.</td></tr><tr><td>Prerequisite(s)</td><td>- The configured eMAID is known by the CSMS as valid.
+- The configured contract certificate is valid.
+- The CN of the configured contract certificate equals the configured eMAID.
+- iso15118CertificateHashData has a responder URL that points to an OCSP service for OCTT.
+- CSMS does not have a cached OCSP response for the contract certificate.</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+State is EVConnectedPreSession</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends anauthorizeRequest With idToken.idToken <Configured eMAID> idToken.type eMAID iso15118CertificateHashData contains <hashes from configured (V2G) certificate chain</td><td>...</td></tr><tr><td colspan="2">...</td></tr></table>
+
+# 6.3.8. Page 639 - (2024-09) - TC_C_52_CSMS - TC does not use <Configured contract_certificate>
+
+OCTT already has a keystore that contains the certificate. The pdf should not mention the <Configured contract_certificate> as the testcase does not use it
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization using Contract Certificates 15118 - Online - Central contract certificate validation - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_52_CSMS</td></tr><tr><td colspan="3">...</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The configured eMAID is known by the CSMS as valid.
+- The configured contract certificate is signed by the configured V2GRoot or MORoot certificate at the CSMS.
+- Contract certificate has a responder URL that points to an OCSP service for OCTT. - CSMS does not have a cached OCSP response for the contract certificate.</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest With idToken.idToken <Configured valid_idtoken_idtoken>
+idToken.type <Configured valid_idtoken_type>
+iso15118CertificateHashData is absent certificate from keystore</td><td>2. The CSMS sends an OCSP request to responder URL of certificate to check validity</td></tr><tr><td colspan="3">...</td></tr></table>
+
+# 6.3.9. Page 639 - (2025-02) - TC_C_52_CSMS - Certificate needs at least one subCA
+
+<table><tr><td>Test case name</td><td>Authorization using Contract Certificates 15118 - Online - Central contract certificate validation - Accepted</td></tr><tr><td>Test case Id</td><td>TC_C_52_CSMS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>…</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 2:CSMS sends an OCSP request for certificate* Step 3:Test System checks that received request for certificate is valid AND key type = ECDSA AND certificate chain contains at least one subCA* Step 4: Message:authorizeResponse-idTokenInfo.status Accepted-certificateStatus Accepted* Step 6:Message:TransactionEventResponse-idTokenInfo.status Accepted</td></tr><tr><td>Post scenario validations:N/a</td></tr></table>
+
+# 6.3.10. Page 640 - (2025-04) - TC_D_01_CSMS - Missing tool validation that the idTokenInfo must be provided for all list entries
+
+<table><tr><td>Test case name</td><td>Send Local Authorization List - Full</td></tr><tr><td>Test case Id</td><td>TC_D_01_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message SendLocalListRequest
+- upgradeType Full
+- versionNumber <Bigger than 0>
+- localAuthorizationList <Not empty>
+- localAuthorizationList[n].idTokenInfo <Not empty></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.3.11. Page 712 - (2024-09) - TC_I_01_CSMS - Show EV Driver running total cost
+
+<table><tr><td>Test case name</td><td>Show EV Driver running total cost during charging - costUpdatedRequest</td></tr><tr><td>Test case Id</td><td>TC_I_01_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Show EV Driver running total cost during charging - costUpdatedRequest</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td>7. The OCTT sends a TransactionEventRequest With triggerReason is MeterValuePeriodic eventType is Updated timestamp <The intervals between the timestamps of the received Meter Value messages equals the configured sampled Meter Values interval>.sampledValue.context is Sample.PeriodicNote(s):-- This step will be executed every_<Configured sampled Meter Values interval> - The OCTT will end the testcase after two MeterValues.</td><td>8. The CSMS responds with a TransactionEventResponse</td></tr><tr><td colspan="2">...</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">...</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+# 6.3.12. Page 715 - (2025-02) - TC_I_02_CSMS - Added explicit information about CSMS tariff configuration and sending in needed metervalues
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a - CSMS is configured with a tariff which is based on energy consumed.</td></tr><tr><td>Reusable State(s):
+state is EVConnectedPostSession- N/a</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">- The TransactionEventRequest contains the MeterValue field.</td></tr><tr><td colspan="2">- sampledValue[0].value 1000</td></tr><tr><td colspan="2">- sampledValue[0].context Transaction.Begin</td></tr><tr><td colspan="2">2. Execute Reusable State Authorized</td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr><tr><td colspan="2">4. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">5. Execute Reusable State EVConnectedPostSession</td></tr><tr><td>6. The Test System notifies the CSMS about the current state of the configured connector.</td><td rowspan="2">7. The CSMS responds accordingly.</td></tr><tr><td>Message: StatusNotificationRequest
+- connectorStatus Available
+Message: NotifyEventRequest
+- trigger Delta
+-actualValue "Available"
+- component.name "Connector"
+- variable.name "AvailabilityState"</td></tr><tr><td>8. The Test System sends a TransactionEventRequest with
+- triggerReason EVCommunicationLost
+- eventType Ended
+- transactionInfo.chargingState Idle
+- transactionInfo.stoppedReason EVDisconnected
+- meterValue[0].sampledValue[0].value 6000
+- meterValue[0].sampledValue[0].context Transaction.End</td><td>9. The CSMS responds with a TransactionResponse</td></tr></table>
+
+# 6.3.13. Page 726-760 - (2025-04) - TC_K_XX_CSMS - Improved tool validations to be sure valid Charging Profiles are used
+
+<table><tr><td>Test case name</td><td>Set Charging Profile - TxDefaultProfile - Specific EVSE</td></tr><tr><td>Test case Id</td><td>TC_K_01_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message SetChargingProfileRequest
+evseld <Configured evseld> AND
+chargingProfile.stackLevel <Configured stackLevel> AND
+chargingProfile.chargingProfilePurpose TxDefaultProfile AND
+chargingProfile.chargingProfileKind Absolute AND
+chargingProfile.validFrom now AND
+chargingProfile.validTo now + <Configured Charging Schedule Duration> AND
+chargingProfile.chargingSchedule.startSchedule now AND
+chargingProfile.chargingSchedule.chargingRateUnit <Configured chargingRateUnit> AND
+chargingProfile.chargingSchedule.duration <Configured duration> AND
+chargingProfile.chargingSchedule.chargingSchedulePeriod.startPeriod 0 AND
+chargingProfile.chargingSchedule.chargingSchedulePeriod limit 6.0 or 6000.0 AND
+chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases> where <Configured
+numberPhases> not 3 OR
+chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases> or <omit> where
+<Configured numberPhases> 3</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Set Charging Profile - TxProfile without ongoing transaction on the specified EVSE</td></tr><tr><td>Test case Id</td><td>TC_K_02_CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message SetChargingProfileRequest
+- evseld <Configured evseld> AND
+- chargingProfile.chargingProfilePurpose TxProfile AND
+- chargingProfile.stackLevel <Configured stackLevel> AND
+- chargingProfile.chargingProfileKind Relative AND
+- chargingProfile.chargingSchedule.startSchedule must be omitted AND
+- chargingProfile.chargingSchedule.chargingRateUnit <Configured chargingRateUnit> AND
+- chargingProfile.chargingSchedule.chargingSchedulePeriod.startPeriod 0 AND
+- chargingProfile.chargingSchedule.chargingSchedulePeriodlimit 7.0 or 7000.0 AND
+- chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases> where <Configured
+numberPhases> not 3 OR
+- chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases> or <omit> where
+<Configured numberPhases> 3</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Replace charging profile - With chargingProfileld</td></tr><tr><td>Test case Id</td><td>TC_K_04_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:</td></tr><tr><td>Message SetChargingProfileRequest</td></tr><tr><td>chargingProfile.chargingSchedule.chargingSchedulePeriod.startPeriod 0 AND</td></tr><tr><td>chargingProfile.chargingSchedule.chargingSchedulePeriodlimit 8.0 (A) or 8000.0 (W)</td></tr><tr><td>The chargingSchedule contains only one chargingSchedulePeriod</td></tr><tr><td>* Step 3:</td></tr><tr><td>Message SetChargingProfileRequest</td></tr><tr><td>chargingProfile.chargingSchedule.chargingSchedulePeriod.startPeriod 0 AND</td></tr><tr><td>chargingProfile.chargingSchedule.chargingSchedulePeriodlimit 6.0 (A) or 6000.0 (W)</td></tr><tr><td>The chargingSchedule contains only one chargingSchedulePeriod</td></tr><tr><td>* Step 1/3:</td></tr><tr><td>Message SetChargingProfileRequest</td></tr><tr><td>chargingProfile.id <Same id for both chargingProfiles></td></tr><tr><td>chargingProfile.chargingSchedule.startSchedule must NOT be omitted.</td></tr><tr><td>chargingProfile.stackLevel <Configured stackLevel> AND</td></tr><tr><td>chargingProfile.chargingProfilePurpose <Equal value for both profiles> AND (TxDefaultProfile OR ChargingStationMaxProfile)</td></tr><tr><td>chargingProfile.chargingProfileKind <Equal value for both profiles> AND</td></tr><tr><td>If chargingProfile.chargingProfilePurpose is TxDefaultProfile then chargingProfile.chargingProfileKind must be Absolute OR</td></tr><tr><td>Recurring</td></tr><tr><td>If chargingProfile.chargingProfilePurpose is ChargingStationMaxProfile then chargingProfile.chargingProfileKind must be</td></tr><tr><td>Absolute</td></tr><tr><td>If chargingProfile.chargingProfileKind is Recurring then chargingProfile.recurrencyKind must NOT be omitted, else omitted</td></tr><tr><td>The received Charging Profiles must comply with the requirements defined at part 2 specification.</td></tr><tr><td>Post scenario validations: - N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Clear Charging Profile - With chargingProfileId</td></tr><tr><td>Test case Id</td><td>TC_K_05_CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message ClearChargingProfileRequest
+chargingProfileId <Generated chargingProfileId> AND
+chargingProfileCriteria omit</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Clear Charging Profile - With stackLevel/purpose combination for one profile</td></tr><tr><td>Test case Id</td><td>TC_K_06_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message ClearChargingProfileRequest
+chargingProfileCriteria.chargingProfilePurpose TxDefaultProfile AND
+chargingProfileCriteria.stackLevel <Configured stackLevel> AND
+chargingProfileCriteria.evseld <Configured evseld> AND
+chargingProfileId must be omitted.</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Clear Charging Profile - Without previous charging profile</td></tr><tr><td>Test case Id</td><td>TC_K_08_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message ClearChargingProfileRequest
+chargingProfileCriteria. chargingProfilePurpose TxDefaultProfile AND
+chargingProfileCriteria. stackLevel <Configured stackLevel> AND
+chargingProfileCriteria. evseld <Configured evseld> AND
+chargingProfileId must be omitted.</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Set Charging Profile - Not Supported</td></tr><tr><td>Test case Id</td><td>TC_K_15_CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td>Tool validations</td></tr><tr><td>* Step 1:</td></tr><tr><td>Message SetChargingProfileRequest</td></tr><tr><td>evseld <Configured evseld> AND</td></tr><tr><td>chargingProfile.stackLevel <Configured stackLevel> AND</td></tr><tr><td>chargingProfile.chargingProfilePurpose TxDefaultProfile AND</td></tr><tr><td>chargingProfile.chargingProfileKind Absolute AND</td></tr><tr><td>chargingProfile.chargingSchedule.startSchedule <Not omitted> AND</td></tr><tr><td>chargingProfile.chargingSchedule.chargingRateUnit <Configured ChargingRateUnit> AND</td></tr><tr><td>chargingProfile.chargingSchedule.chargingSchedulePeriod.startPeriod 0 AND</td></tr><tr><td>chargingProfile.chargingSchedule.duration <Configured duration></td></tr><tr><td>chargingProfile.chargingSchedule.chargingSchedulePeriod limit 6.0 or 6000.0 AND</td></tr><tr><td>chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases> where <Configured</td></tr><tr><td>numberPhases> not 3 OR</td></tr><tr><td>chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases> or <omit> where</td></tr><tr><td><Configured numberPhases> 3 +</td></tr><tr><td>Post scenario validations:</td></tr><tr><td>- N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Get Charging Profile - Evseld 0</td></tr><tr><td>Test case Id</td><td>TC_K_29_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message GetChargingProfilesRequest
+- evseld 0 AND
+- chargingProfile.chargingProfilePurpose <Configured chargingProfilePurpose> AND
+Note : chargingProfilePurpose is included, because the chargingProfile field is required and may not be left empty.
+- chargingProfile.stackLevel must be omitted AND
+- chargingProfile.chargingLimitSource must be omitted AND
+- chargingProfile.chargingProfileId must be omitted</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Get Charging Profile - Evseld > 0</td></tr><tr><td>Test case Id</td><td>TC_K_30_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message GetChargingProfilesRequest
+- evseld <Configured evseld> AND
+- chargingProfile.chargingProfilePurpose <Configured chargingProfilePurpose> AND
+Note : chargingProfilePurpose is included, because the chargingProfile field is required and may not be left empty.
+- chargingProfile.stackLevel must be omitted AND
+- chargingProfile.chargingLimitSource must be omitted AND
+- chargingProfile.chargingProfileId must be omitted</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Get Charging Profile - No Evseld</td></tr><tr><td>Test case Id</td><td>TC_K_31_CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message GetChargingProfilesRequest
+- evseld must be omitted AND
+- chargingProfile.chargingProfilePurpose <Configured chargingProfilePurpose> AND
+Note : chargingProfilePurpose is included, because the chargingProfile field is required and may not be left empty.
+- chargingProfile.stackLevel must be omitted AND
+- chargingProfile.chargingLimitSource must be omitted AND
+- chargingProfile.chargingProfileld must be omitted</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Get Charging Profile - chargingProfileId</td></tr><tr><td>Test case Id</td><td>TC_K_32_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message GetChargingProfilesRequest
+- evseld must be omitted AND
+- chargingProfile.chargingProfilePurpose must be omitted AND
+- chargingProfile.stackLevel must be omitted AND
+- chargingProfile.chargingLimitSource must be omitted AND
+- chargingProfile.chargingProfileId <received chargingProfileId></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Get Charging Profile - Evseld > 0 + stackLevel</td></tr><tr><td>Test case Id</td><td>TC_K_33_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message GetChargingProfilesRequest
+- evseld <Configured evseld> AND
+- chargingProfile.stackLevel <Configured stackLevel> AND
+- chargingProfile.chargingProfilePurpose must be omitted AND
+- chargingProfile.chargingLimitSource must be omitted AND
+- chargingProfile.chargingProfileld must be omitted</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Get Charging Profile - Evseld > 0 + chargingLimitSource</td></tr><tr><td>Test case Id</td><td>TC_K_34_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message GetChargingProfilesRequest
+- evseld <Configured evseld> AND
+- chargingProfile.chargingLimitSource <Configured chargingLimitSource> AND
+- chargingProfile.stackLevel must be omitted AND
+- chargingProfile.chargingProfilePurpose must be omitted AND
+- chargingProfile.chargingProfileId must be omitted</td></tr></table>
+
+# Tool validations
+
+# Post scenario validations:
+
+-N/a
+
+<table><tr><td>Test case name</td><td>Get Charging Profile - Evseld > 0 + chargingProfilePurpose</td></tr><tr><td>Test case Id</td><td>TC_K_35_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+# Tool validations
+
+- Step 1:
+ Message GetChargingProfilesRequest
+
+* evseld<Configured evseld> AND
+* chargingProfile.chargingProfilePurpose <Configured chargingProfilePurpose> AND
+* chargingProfile.stackLevel must be omitted AND
+* chargingProfile.chargingLimitSource must be omitted AND
+* chargingProfile.chargingProfileId must be omitted
+
+Post scenario validations:
+
+-N/a
+
+<table><tr><td>Test case name</td><td>Get Charging Profile - Evseld > 0 + chargingProfilePurpose + stackLevel</td></tr><tr><td>Test case Id</td><td>TC_K_36_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+# Tool validations
+
+- Step 1:
+ Message GetChargingProfilesRequest
+
+* evseld<Configured evseld> AND
+ -chargingProfile.chargingProfilePurpose <Configured chargingProfilePurpose> AND
+* chargingProfile.chargingLimitSource must be omitted AND
+* chargingProfile.stackLevel <Configured stackLevel> AND
+* chargingProfile.chargingProfileId must be omitted
+
+Post scenario validations:
+
+-N/a
+
+<table><tr><td>Test case name</td><td>Set Charging Profile - TxProfile with ongoing transaction on the specified EVSE</td></tr><tr><td>Test case Id</td><td>TC_K_60_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+# Tool validations
+
+- Step 1:
+
+(Message: SetChargingProfileRequest)
+
+chargingProfile.chargingProfilePurpose is TxProfile AND
+
+chargingProfile.evseld is <Configured evseld> AND
+
+chargingProfile transactionld <Generated transactionId> AND
+
+chargingProfile.chargingProfileKind is Relative OR Absolute
+
+If chargingProfileKind is Relative then chargingSchedule.startSchedule must be omitted.
+
+If chargingProfileKind is Absolute then chargingSchedule.startSchedule must NOT be omitted.
+
+The received Charging Profile must comply with the requirements defined at part 2 specification.
+
+Post scenario validations:
+
+N/a
+
+<table><tr><td>Test case name</td><td>Remote start transaction with charging profile - Success</td></tr><tr><td>Test case Id</td><td>TC_K_37_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:</td></tr><tr><td>Message: RequestStartTransactionRequest</td></tr><tr><td>idToken.idToken <Configured valid idToken></td></tr><tr><td>idToken.type <Configured valid idToken type></td></tr><tr><td>evseld <Configured evseld></td></tr><tr><td>chargingProfile contains:</td></tr><tr><td>chargingProfile.chargingProfilePurpose is TxProfile</td></tr><tr><td>chargingProfile transactionId is omitted</td></tr><tr><td>chargingProfile.chargingProfileKind is Relative OR Absolute</td></tr><tr><td>If chargingProfileKind is Relative then chargingSchedule.startSchedule must be omitted.</td></tr><tr><td>If chargingProfileKind is Absolute then chargingSchedule.startSchedule must NOT be omitted.</td></tr><tr><td>The received Charging Profile must comply with the requirements defined at part 2 specification.</td></tr><tr><td>Post scenario validations:</td></tr><tr><td>N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Set Charging Profile - Multiple Profiles</td></tr><tr><td>Test case Id</td><td>TC_K_70_CSMS</td></tr><tr><td>Use case Id(s)</td><td>n/a</td></tr><tr><td>Requirement(s)</td><td>n/a</td></tr><tr><td>System under test</td><td>CSMS</td></tr><tr><td>Description</td><td>To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td>To verify if the CSMS is able to set multiple Charging Profiles.</td></tr><tr><td>Prerequisite(s)</td><td>n/a</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:</td></tr><tr><td>Message SetChargingProfileRequest</td></tr><tr><td>chargingProfile.chargingProfilePurpose TxDefaultProfile</td></tr><tr><td>chargingProfile.chargingProfileKind is Absolute OR Recurring</td></tr><tr><td>chargingProfile.chargingSchedule.startSchedule must NOT be omitted.</td></tr><tr><td>If chargingProfile.chargingProfileKind is Recurring then chargingProfile.recurrencyKind must NOT be omitted.</td></tr><tr><td>* Step 3:</td></tr><tr><td>Message SetChargingProfileRequest</td></tr><tr><td>chargingProfile.id <different id from chargingProfile at step 1></td></tr><tr><td>chargingProfile.chargingProfilePurpose ChargingStationMaxProfile</td></tr><tr><td>chargingProfile.chargingProfileKind is Absolute</td></tr><tr><td>chargingProfile.chargingSchedule.startSchedule must NOT be omitted.</td></tr><tr><td>The received Charging Profiles must comply with the requirements defined at part 2 specification.</td></tr><tr><td>Post scenario validations:</td></tr><tr><td>- N/a</td></tr></table>
+
+# 6.3.14. Page 728 - (2024-09) - TC_K_03_CSMS - Not requiring validFrom/To fields in charging profile [O20-4592] and chargingProfileKind must be Absolute [O20-4591]
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - ChargingStationMaxProfile</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_03_CSMS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message SetChargingProfileRequest
+evseld 0 AND
+chargingProfile.stackLevel <Configured stackLevel> AND
+chargingProfile.chargingProfilePurpose ChargingStationMaxProfile_ AND
+chargingProfile.chargingProfileKind Absolute OR Relative
+chargingProfile.chargingSchedule.chargingRateUnit <Configured ChargingRateUnit>
+chargingProfile.chargingSchedule.duration <Configured duration>
+chargingProfile.chargingSchedule.chargingSchedulePeriod.startPeriod 0
+chargingProfile.chargingSchedule.chargingSchedulePeriod limit 8.0 or 8000.0
+chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases>
+where <Configured numberPhases> not 3 OR
+chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases>
+or <omit> where <Configured numberPhases> 3
+chargingProfile.validFrom <Not omitted>
+chargingProfile.validTo <Not omitted>
+chargingProfile.chargingSchedule.startSchedule <Not omitted></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.3.15. Page 733 - (2024-09) - TC_K_10_CSMS - Not requiring validFrom/To fields in charging profile [O20-4592]
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - TxDefaultProfile - All EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_10_CSMS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td>Test case name</td><td>Set Charging Profile - TxDefaultProfile - All EVSE</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message SetChargingProfileRequest
+evseld 0 AND
+chargingProfile.stackLevel <Configured stackLevel> AND
+chargingProfile.chargingProfilePurpose TxDefaultProfile AND
+chargingProfile.chargingProfileKind Absolute AND
+chargingProfile.validFrom <Not omitted> AND
+chargingProfile.validTo <Not omitted> AND
+chargingProfile.chargingSchedule.startSchedule <Not omitted> AND
+chargingProfile.chargingSchedule.chargingRateUnit <Configured ChargingRateUnit> AND
+chargingProfile.chargingSchedule.chargingSchedulePeriod.startPeriod 0 AND
+chargingProfile.chargingSchedule.duration <Configured duration>
+chargingProfile.chargingSchedule.chargingSchedulePeriod limit 6.0 or 6000.0 AND
+chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases>
+where <Configured numberPhases> not 3 OR
+chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases>
+or <omit> where <Configured numberPhases> 3</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.3.16. Page 734 - (2024-09) - TC_K_15_CSMS - Not requiring validFrom/To fields in charging profile [O20-4592]
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - Not Supported</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_15_CSMS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with RPC Framework:
+CALLERROR: NotSupported.</td><td>1. The CSMS sends a SetChargingProfileRequest with:
+evseld <Configured evseld> AND
+chargingProfile.stackLevel <Configured stackLevel>
+AND
+chargingProfile.chargingProfilePurpose
+TxDefaultProfile AND
+chargingProfile.chargingProfileKind Absolute AND
+chargingProfile.validFrom <Not omitted> AND
+chargingProfile.validTo <Not omitted> AND
+chargingProfile.chargingSchedule.startSchedule
+<Not omitted> AND
+chargingProfile.chargingSchedule.chargingRateUnit
+<Configured ChargingRateUnit> AND
+chargingProfile.chargingSchedule.chargingSchedul ePeriod.startPeriod 0 AND
+chargingProfile.chargingSchedule.duration
+<Configured duration>
+chargingProfile.chargingSchedule.chargingSchedul ePeriod limit 6.0 or 6000.0 AND
+chargingProfile.chargingSchedule.chargingSchedul ePeriod.numberPhases <Configured numberPhases></td></tr><tr><td>Tool validations</td><td colspan="2">...</td></tr></table>
+
+# 6.3.17. Page 752 - (2025-06) - TC_K_53_CSMS - Validate that the CSMS let's the Charging Station charging, according to the negotiated limits
+
+<table><tr><td>Test case name</td><td>Charging with load leveling based on High Level Communication - Success</td></tr><tr><td>Test case Id</td><td>TC_K_53_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute reusable state ISO15118SmartCharging</td></tr><tr><td colspan="2">2. The CSMS does NOT send a SetChargingProfileRequest
+Note(s):
+- The CSMS must NOT initiate a renegotiate after starting the transaction, without cause. For example; a smart charging algorithm or an external trigger, etc.</td></tr></table>
+
+# 6.3.18. Page 753 - (2024-09) - TC_K_55_CSMS, TC_K_57_CSMS, TC_K_58_CSMS, TC_K_59_CSMS Removed triggerReason = ChargingRateChanged [776]
+
+A trigger reason ChargingStateChange must only be sent, when an external actor (not CSMS) changes the charging rate. Therefore, removed the sending of a triggerReason=ChargingStateChanged by OCTT. This does not affect tool validations, but it was incorrect behavior of OCTT.
+
+The step that sends a TransactionEventRequest with triggerReason=ChargingRateChanged has been removed from:
+
+- TC_K_55_CSMS
+- TC_K_57_CSMS
+- TC_K_58_CSMS
+- TC_K_59_CSMS
+
+# 6.3.19. Page 760 - (2024-11) - TC_K_70_CSMS - Updated tool validation chargingProfiles and added preparation step.
+
+We require a CSMS to install multiple ChargingProfiles with the same purpose and for the same connectorld with a different stackLevel. However there are CSMSs that do the stacking themselves and are unable to do this. Therefore it was decided to use different purposes instead.
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - Multiple Profiles</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_70_CSMS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="2">Before
+(Preparations)</td><td colspan="2">...</td></tr><tr><td colspan="2">Charging State:
+State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+SetChargingProfileResponse with
+status Accepted</td><td>1. The CSMS sends a SetChargingProfileRequest
+with
+chargingProfilePurpose TxDefaultProfile</td></tr><tr><td>4. The OCTT responds with a
+SetChargingProfileResponse with
+status Accepted</td><td>3. The CSMS sends a SetChargingProfileRequest
+with
+chargingProfilePurpose ChargingStationMaxProfile</td></tr><tr><td>Test case name</td><td>Set Charging Profile - Multiple Profiles</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message SetChargingProfileRequest
+chargingProfile.chargingProfilePurpose TxDefaultProfile
+* Step 3:
+Message SetChargingProfileRequest
+chargingProfile.id <different id for both chargingProfiles>
+chargingProfile.chargingProfilePurpose ChargingStationMaxProfile</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.3.20. Page 805/806 - (2025-06) - TC_N_01_CSMS & TC_N_02_CSMS - omit filter fields that are not tested
+
+These testcases specifically test the use of the different uses of the fields that are used to filter the result. monitoringCriteria in case of TC_N_01_CSMS and componentVariable in case of TC_N_02_CSMS. The fields that are not part of the testcase need to be omitted.
+
+<table><tr><td>Test case name</td><td>Get Monitoring Report - with monitoringCriteria</td></tr><tr><td>Test case Id</td><td>TC_N_01_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message: GetMonitoringReportRequest
+- monitoringCriteria = DeltaMonitoring
+- componentVariable is omitted.</td></tr><tr><td>* Step 3:
+Message: GetMonitoringReportRequest
+- monitoringCriteria = ThresholdMonitoring
+- componentVariable is omitted.</td></tr><tr><td>Post scenario validations:
+Check that CSMS shows the Threshold monitors.</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Get Monitoring Report - with component/variable</td></tr><tr><td>Test case Id</td><td>TC_N_02_CSMS</td></tr><tr><td colspan="2">...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message: GetMonitoringReportRequest
+- componentVariable[0].component.name = "ChargingStation"
+- componentVariable[0].variable.name = "Power"
+- monitoringCriteria is omitted.</td></tr><tr><td>* Step 3:
+Message: GetMonitoringReportRequest
+- componentVariable[1].component.name = "EVSE"
+- componentVariable[1].component.evse.id = 1
+- componentVariable[1].variable.name = "AvailabilityState"
+- monitoringCriteria is omitted.</td></tr><tr><td>Post scenario validations:
+Check that CSMS shows the monitor for AvailabilityState for EVSE #1.</td></tr></table>
+
+# 6.3.21. Page 806 - (2025-06) - TC_N_02_CSMS - component and variable instance need to be omitted
+
+The testcase specifically requests two component variables that do not have an instance.
+
+<table><tr><td>Test case name</td><td>Get Monitoring Report - with component/variable</td></tr><tr><td>Test case Id</td><td>TC_N_02_CSMS</td></tr><tr><td colspan="2">...</td></tr><tr><td colspan="2">Tool validations</td></tr><tr><td colspan="2">* Step 1:
+Message: GetMonitoringReportRequest
+- componentVariable[0].component.name = "ChargingStation"
+- componentVariable[0].component.instance is omitted.
+- componentVariable[0].variable.name = "Power"
+- componentVariable[0].variable.instance is omitted.
+- monitoringCriteria is omitted.</td></tr><tr><td colspan="2">* Step 3:
+Message: GetMonitoringReportRequest
+- componentVariable[1].component.name = "EVSE"
+- componentVariable[1].component.instance is omitted.
+- componentVariable[1].component.evse.id = 1
+- componentVariable[1].component.name = "AvailabilityState"
+- componentVariable[1].variable.instance is omitted.
+- monitoringCriteria is omitted.</td></tr><tr><td colspan="2">Post scenario validations:
+Check that CSMS shows the monitor for AvailabilityState for EVSE #1.</td></tr></table>
+
+# 6.3.22. Page 824 - (2025-04) - TC_N_62_CSMS - Check only single identifier is provided
+
+Added validation that Token and customerCertificate are omitted.
+
+TC_N_62_CSMS: Clear Customer Information - Clear and report - customerIdentifier
+
+<table><tr><td>Test case name</td><td>Clear Customer Information - Clear and report - customerIdentifier</td></tr><tr><td>Test case Id</td><td>TC_N_62_CSMS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>..</td></tr></table>
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message CustomerInformationRequest
+- report true
+- clear true
+- customerIdentifier "OpenChargeAlliance"
+- idToken is omitted
+- customerCertificate is omitted</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.3.23. Page 830 - (2024-11) - TC_N_46_CSMS - Updated tool validation sendLocalListRequest
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Update Local Authorization List</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_46_CSMS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">...</td></tr><tr><td colspan="2">Memory State:A local authorization list with <Configured valid_idtoken_idtoken> is configured.</td></tr><tr><td colspan="2">...</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>...</td><td>...</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message CustomerInformationRequest- report true AND- clear true AND-idToken.idToken <Configured valid_idtoken_idtoken>- idToken.type <Configured valid_idtoken_type>* Step 5:Message SendLocalListRequest-updateType Differential-versionNumber <Bigger than currently configured in OCTT>- localAuthorizationList <Contains only the configured valid_idtoken_idtoken, without idTokenInfo>OR:updateType Full- localAuthorizationList <Does NOT contain configured valid_idtoken_idtoken></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+# 6.3.24. Page 830 - (2025-02) - TC_N_46_CSMS - Aligning configuration variable usage
+
+<table><tr><td colspan="2">Main (Test scenario)</td></tr><tr><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual action: Trigger CSMS to CustomerInformationRequest to both report and clear token <Configured valid_idtoken_idtoken> and <Configured valid_idtoken_type></td></tr><tr><td>2. The Test System responds with a CustomerInformationResponse with status Accepted</td><td>1. The CSMS sends a CustomerInformationRequest</td></tr><tr><td>3. The Test System sends a NotifyCustomerInformationRequest</td><td>4. The CSMS responds with a NotifyCustomerInformationResponse .</td></tr><tr><td colspan="2">Manual action: If not triggered automatically, trigger CSMS to send SendLocalListRequest with version = <configured local list version> + 1 and updateType = Differential and localAuthorizationList = {{idToken = {<Configured valid_idtoken>, <Configured valid_idtoken_type>} }}</td></tr><tr><td>6 The Test System responds with a SendLocalListResponse with status Accepted</td><td>5. The CSMS sends a SendLocalListRequest</td></tr><tr><td colspan="2">Note(s): If the Local Authorization List is too big for one message, step 5 and 6 will be repeated</td></tr></table>
+
+# Tool validations
+
+- Step 1:
+
+Message CustomerInformationRequest
+
+-report true AND
+
+- clear true AND
+ -idToken.idToken<Configuredvalid_idtoken_idtoken>
+ -idToken.type<Configured valid_idtoken_type>
+ \* Step 5:
+
+Message SendLocalListRequest
+
+-updateType Differential
+-versionNumber<configured local list version> + 1
+
+- localAuthorizationList <Contains only the configured valid_idtoken_idtoken, without idTokenInfo>
+
+- localAuthorizationList[0].idToken contains <configured_valid_idtoken_idtoken> and <configured valid_idtoken_type>
+
+- localAuthorizationList[0].idTokenInfo <omitted>
+
+Post scenario validations:
+
+- All messages have been received
+
+# 6.3.25. Page 854 - (2025-02) - TC_O_27_CSMS - Fixing validations to be more specific for test case
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:
+Message SetDisplayMessageRequest
+- message.id <GeneratedId>
+- message.startDateTime <Configured startDateTime>
+- message_transactionld is present
+- message.state is <omitted>
+- message.startDateTime is <Configured startDateTime>
+- message.endDateTime is <omitted>
+- message.transactionld is <Generated transactionld from Before></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+# 6.3.26. Page 855 - (2025-02) - TC_O_28_CSMS - Fixing validations to be more specific for test case
+
+A test case needs to start in Preparations phase:
+
+<table><tr><td>Before (Preparations)</td></tr><tr><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State:
+State is EnergyTransferStarted</td></tr></table>
+
+<table><tr><td>Tool validations</td></tr><tr><td>* Step 1:</td></tr><tr><td>Message SetDisplayMessageRequest</td></tr><tr><td>-message.id <GeneratedId></td></tr><tr><td>-messagepriority <ConfiguredPriority></td></tr><tr><td>-message.endDateTime <Configured endDateTime></td></tr><tr><td>-message.state <Configured State></td></tr><tr><td>-message_transactionld is present</td></tr><tr><td>- message.state is <omitted></td></tr><tr><td>- message.startDateTime is <omitted></td></tr><tr><td>- message.endDateTime is <Configured endDateTime></td></tr><tr><td>- message.transactionld is <Generated transactionld from Before></td></tr><tr><td>Post scenario validations:</td></tr><tr><td>- N/a</td></tr></table>
--- /dev/null
+# OCPP
+
+# Table of Contents
+
+Disclaimer 1
+
+Version History 2
+
+1. Introduction. 3
+
+1.1. OCPP version 2.0.1. 3
+1.2. Terms and abbreviations 3
+1.3. References 4
+
+2. New functionalities in OCPP2.0.1 5
+
+2.1. Device Management 5
+2.2. Improvements for better handling of large amounts of transactions 5
+2.3. Improvements regarding cyber security 5
+2.4. Extended Smart Charging 5
+2.5. Support for ISO 15118 6
+2.6. Improvements for customer experience 6
+2.7. Transport Protocols: OCPP-J Improvements 6
+2.8. Minor changes/extensions 7
+
+3. OCPP2.0.1DocumentationStructure 8
+
+3.1. Overview of Specification Parts 8
+3.2. Functional Blocks 9
+3.3. All Functional Blocks and use cases 10
+
+4. Basic implementation of OCPP 2.0.1 13
+
+# 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
+
+<table><tr><td>Version</td><td>Date</td><td>Description</td></tr><tr><td>2.0.1 Edition 3</td><td>2024-05-06</td><td>OCPP 2.0.1 Edition 3. All errata from OCPP 2.0.1 Part 0 until and including Errata 2024-04 have been merged into this version of the specification.</td></tr><tr><td>2.0.1</td><td>2020-03-31</td><td>Final version of OCPP 2.0.1</td></tr><tr><td>2.0</td><td>2018-04-11</td><td>OCPP 2.0 April 2018
+First release of this Introduction document</td></tr></table>
+
+# 1. Introduction
+
+Electric Vehicles (EVs) are becoming the new standard for mobility all over the world. This development is only possible with a good coverage of Charging Stations. To advance the roll out of charging infrastructure, open communication standards play a key role: to enable switching from charging network without necessarily replacing all the Charging Stations, to encourage innovation and cost effectiveness and to allow many and diverse players participate in this new industry.
+
+Additionally, the EV charging infrastructure is part of the Smart Grid, a larger and still evolving ecosystem of actors, devices and protocols. In this Smart Grid ecosystem, open communications standards are key enablers for two-way power flows, real time information exchange, demand control and eMobility services.
+
+The Open Charge Point Protocol (OCPP) is the industry-supported de facto standard for communication between a Charging Station and a Charging Station Management System (CSMS) and is designed to accommodate any type of charging technique. OCPP is an open standard with no cost or licensing barriers for adoption.
+
+# 1.1. OCPP version 2.0.1
+
+This specification defines version 2.0.1 of OCPP.
+
+After the release of OCPP 2.0, some issues were found in OCPP 2.0. Some of these issues could not be fixed issuing errata to the specification text only, as has been done with OCPP 1.6, but required changes to the protocol's machine-readable schema definition files that cannot be backward compatible.
+
+To prevent confusion in the market and possible interoperability issues in the field, OCA has decided to name this version: 2.0.1. OCPP 2.0.1 contains fixes for all the known issues, to date, not only the fixes to the messages.
+
+This version replaces OCPP 2.0. OCA advises implementers of OCPP to no longer implement OCPP 2.0 and only use version 2.0.1 going forward.
+
+Any mentions of "OCPP 2.0" refers to revision 2.0.1 unless specifically stated otherwise.
+
+# 1.2. Terms and abbreviations
+
+This section contains the terminology and abbreviations that are used throughout this document.
+
+# 1.2.1. Terms
+
+<table><tr><td>Term</td><td>Meaning</td></tr><tr><td>Charging Station</td><td>The Charging Station is the physical system where an EV can be charged. A Charging Station has one or more EVSEs.</td></tr><tr><td>Charging Station Management System (CSMS)</td><td>Charging Station Management System: manages Charging Stations and has the information for authorizing Users for using its Charging Stations.</td></tr><tr><td>Electric Vehicle Supply Equipment (EVSE)</td><td>An EVSE is considered as an independently operated and managed part of the Charging Station that can deliver energy to one EV at a time.</td></tr><tr><td>Energy Management System (EMS)</td><td>In this document this is defined as a device that manages the local loads (consumption and production) based on local and/or contractual constraints and/or contractual incentives. It has additional inputs, such as sensors and controls from e.g. PV, battery storage.</td></tr></table>
+
+# 1.2.2. Abbreviations
+
+<table><tr><td>Term</td><td>Meaning</td></tr><tr><td>CSO</td><td>Charging Station Operator</td></tr><tr><td>CSMS</td><td>Charging Station Management System</td></tr><tr><td>EMS</td><td>Energy Management System.</td></tr><tr><td>EV</td><td>Electric Vehicle</td></tr><tr><td>EVSE</td><td>Electric Vehicle Supply Equipment</td></tr><tr><td>RFID</td><td>Radio-Frequency Identification</td></tr></table>
+
+# 1.3. References
+
+Table 1. References
+
+<table><tr><td>Reference</td><td>Description</td></tr><tr><td>[IEC61851-1]</td><td>IEC 61851-1 2017: EV conductive charging system - Part 1: General requirements. https://webstore.iec.ch/publication/33644</td></tr><tr><td>[IEC62559-2:2015]</td><td>Definition of the templates for use cases, actor list and requirements list. https://webstore.iec.ch/publication/22349</td></tr><tr><td>[ISO15118-1]</td><td>ISO 15118-1 specifies terms and definitions, general requirements and use cases as the basis for the other parts of ISO 15118. It provides a general overview and a common understanding of aspects influencing the charge process, payment and load leveling. https://webstore.iec.ch/publication/9272</td></tr><tr><td>[OCPP1.5]</td><td>http://www.openchargealliance.org/downloads/</td></tr><tr><td>[OCPP1.6]</td><td>http://www.openchargealliance.org/downloads/</td></tr></table>
+
+# 2. New functionalities in OCPP2.0.1
+
+OCPP 2.0.1 introduces new functionalities compared to OCPP 1.6 [OCPP1.6].
+
+Due to improvements and new features, OCPP 2.0.1 is not backward compatible with OCPP 1.6 [OCPP1.6] or OCPP 1.5 [OCPP1.5].
+
+# 2.1. Device Management
+
+Device Management (also known as Device Model) is a long awaited feature especially welcomed by CSOs who manage a network of (complex) charging stations (from different vendors).
+
+It provides the following functionality:
+
+- Inventory reporting
+- Improved error and state reporting
+- Improved configuration
+- Customizable Monitoring
+
+This all should help CSOs to reduce the costs of operating a Charging Station network.
+
+Charging Station Manufacturers are free to decide themselves how much details about a Charging Station they want to publish via Device Management: for example, they can decide what can be monitored, and what not.
+
+# 2.2. Improvements for better handling of large amounts of transactions
+
+# 2.2.1. One message for all transaction related functionalities
+
+With the growing of the EV charging market, the number of Charging Stations and transactions that the CSMS needs to manage also grows. The structure and method for reporting transaction is unified in OCPP 2.0. In OCPP 1.x, the reporting of transaction data is split over the messages StartTransaction, StopTransaction, MeterValue and StatusNotification. With the market progressing towards more enhanced scheduling, a need is born for more sophisticated handling of transaction data. All the StartTransaction, StopTransaction, and transaction related MeterValue and StatusNotification messages are replaced by 'TransactionEvent'. The StatusNotification message still exists, but only for non-transaction related status notifications about connector availability.
+
+# 2.2.2. Data reduction
+
+With the introduction of JSON over Web sockets in OCPP 1.6 [OCPP1.6] a great reduction of mobile data cost can be achieved. With OCPP 2.0, support for WebSocket Compression is introduced, which reduces the amount of data even more.
+
+# 2.3. Improvements regarding cyber security
+
+The following improvements have been added to harden OCPP against cyber attacks:
+
+Security profiles (3 levels) for Charging Station and/or CSMS authentication and Communication Security
+Key management for Client-Side certificates
+
+- Secure firmware updates
+ Security event log
+
+# 2.4. Extended Smart Charging
+
+In OCPP 2.0.1 Smart Charging functionality has been extended (compared to OCPP 1.6 [OCPP1.6]) to support:
+
+- Direct Smart Charging inputs from an Energy Management System (EMS) to a Charging Station
+- Improved Smart Charging with a local controller
+- Support for integrated smart charging of the CSMS, Charging Station and EV ([ISO15118-1]).
+
+# 2.5. Support for ISO 15118
+
+The ISO 15118 standard [ISO15118-1] is a newer protocol for EVSE to EV communication, compared to IEC 61851 [IEC61851-1]. ISO 15118 allows a lot of new features and more secure communication between EVSE and EV. OCPP 2.0.1 supports the ISO 15118 standard, the newly added features are:
+
+Plug & Charge
+
+- Smart Charging including input from the EV
+
+# 2.6. Improvements for customer experience
+
+# 2.6.1. More authorization options
+
+OCPP 1.x was designed (mainly) for Charging Stations that authorize an EV driver via an RFID card-token. If other authorization systems or a mix of systems are used, the CSMS needs to know what system is used for which authorization. OCPP 2.0.1 has been extended to support things like: 15118 Plug & Charge [ISO15118-1], Payment Terminals, local mechanical key, Smart-phones, etc.
+
+# 2.6.2. Display Messages
+
+This provides Charging Station Operators with the possibility to configure - from the CSMS - a message on a Charging Station to be displayed to EV drivers. Messages can be transaction related or global.
+
+# 2.6.3. EV Driver preferred languages
+
+To be able to show messages to an EV driver in a language the driver understands best, OCPP 2.0.1 provides the possibility to send the language preference of a driver to a Charging Station.
+
+# 2.6.4. Tariff and Costs
+
+OCPP 2.0.1 allows Charging Stations to show the applicable tariff/price before an EV driver starts charging, to show the running total cost during a charging transaction and/or to show the final total cost after the transaction is finished.
+
+# 2.7. Transport Protocols: OCPP-J Improvements
+
+# 2.7.1. Simple Message routing
+
+A description has been added on how to create a simple solution for OCPP message routing in, for example, a Local Controller. This is defined in Part 4, Section 6: OCPP Routing.
+
+# 2.7.2. No SOAP Support
+
+OCPP 2.0.1 no longer supports SOAP as a transport protocol. This decision was taken by the OCA members, who believe that the protocol does no longer lend itself for constrained computing resources that many Charging Stations operate under. The verbosity of the protocol could lead to slower performance and requires a higher bandwidth, which, in many cases, leads to higher cellular costs. SOAP is also difficult to support when communication is via local site networking.
+
+Edition 3 FINAL, 2024-05-06
+
+# 2.8. Minor changes/extensions
+
+# 2.8.1. Renamed messages
+
+In the OCPP 1.x series, the names of all messages were kept unchanged for backward compatibility, even though some message names were found to be confusing or misleading in practice. In OCPP 2.0.1 message names have been changed, where appropriate, to improve clarity and understanding.
+
+Example: RemoteStartTransaction.req: a lot of implementers though it meant the Charging Station should start the transaction, but in fact it is a request to try to start a transaction. However, for example, if no cable is plugged in, no transaction can be started. Since the message was always intended to be a request, it has been changed to a more logical name: RequestStartTransactionRequest.
+
+# 2.8.2. TransactionId Identification & Message Sequencing
+
+In OCPP 2.0, transaction identifiers are generated by the Charging Station, to facilitate offline charging sessions, in contrast to OCPP 1.x, where transaction identifiers were generated at the CSMS and sent to the Charging Station. In addition, all messages relating to a transaction are assigned incremental sequence numbering, to facilitate transaction data completeness checking at the CSMS.
+
+# 2.8.3. Extended enumerations
+
+Many enumerations have been extended to support more use cases, provide more options etc.
+
+# 2.8.4. Offline Transaction Event Indication
+
+Charging Stations can optionally indicate in transaction messages that a transaction event occurred while the Charging Station was Offline. This can assist a CSMS with the processing of transactions.
+
+# 2.8.5. Personal message
+
+Message that can be shown to the EV Driver and can be used for tariff information, user greetings and for indicating why a driver is not authorized to charge. When a driver uses an authorization method (RFID for example) and the CSMS does not authorize the driver to start charging, this field can thus contain additional reasons to provide the driver with a meaningful explanation why (s)he is not allowed to charge.
+
+# 3. OCPP 2.0.1 Documentation Structure
+
+# 3.1. Overview of Specification Parts
+
+The overall structure of the standard has been improved, making the new specification easier to read, implement and test.
+
+For readability and implementation purposes, OCPP 2.0.1 is divided in seven parts.
+
+Table 2. Parts
+
+<table><tr><td>Part 0</td><td>Introduction (this document)</td></tr><tr><td>Part 1</td><td>Architecture & Topology</td></tr><tr><td>Part 2</td><td>Specification:
+Use Cases and Requirements, Messages, Data Types and Referenced Components and Variables
+Appendices:
+Security Events, Standardized Units of Measure, Components and Variables</td></tr><tr><td>Part 3</td><td>Schemas</td></tr><tr><td>Part 4</td><td>Implementation Guide JSON</td></tr><tr><td>Part 5</td><td>Certification Profiles</td></tr><tr><td>Part 6</td><td>Test Cases</td></tr></table>
+
+In contrast to OCPP 1.6 [OCPP1.6], the OCPP 2.0.1 specification is written in a different structure, based on [IEC62559-2:2015]: "Use case methodology - Part 2: Definition of the template for use cases, actor list and requirements list".
+
+Part 2, the specification, is divided into 'Functional Blocks'. These Functional Blocks contain use cases and requirements.
+
+Messages, Data Types and Referenced Components and Variables are described at the end of the document. The Appendices can be found in the separate document: Part 2 - Appendices.
+
+Messages and Data Types are structured in almost the same way as the previous OCPP specification [OCPP1.6].
+
+# 3.2. Functional Blocks
+
+OCPP 2.0.1 consists of the following Functional Blocks.
+
+Table 3. Functional Blocks
+
+<table><tr><td>Clause</td><td>Functional Block Title</td><td>Description</td></tr><tr><td>A.</td><td>Security</td><td>This Functional Block describes a security specification for the OCPP protocol.</td></tr><tr><td>B.</td><td>Provisioning</td><td>This Functional Block describes all the functionalities that help a CSO provision their Charging Stations, allowing them to be registered and accepted on their network and retrieving basic configuration information from these Charging Stations.</td></tr><tr><td>C.</td><td>Authorization</td><td>This Functional Block describes all the authorization related functionality:authorizeRequest message handling/behavior and Authorization Cache functionality.</td></tr><tr><td>D.</td><td>Local Authorization List Management</td><td>This Functional Block describes functionality for managing the Local Authorization List.</td></tr><tr><td>E.</td><td>Transactions</td><td>This Functional Block describes the basic OCPP Transaction related functionality for transactions that are started/stopped on the Charging Station.</td></tr><tr><td>F.</td><td>Remote Control</td><td>This Functional Block describes three types of use cases for remote control management from the CSMS: Remote Transaction Control, Unlocking a Connector and Remote Trigger.</td></tr><tr><td>G.</td><td>Availability</td><td>This functional Block describes the functionality of sending status notification messages.</td></tr><tr><td>H.</td><td>Reservation</td><td>This Functional Block describes the reservation functionality of a Charging Station.</td></tr><tr><td>I.</td><td>Tariff and Cost</td><td>This Functional Block provides tariff and cost information to an EV Driver, when a Charging Station is capable of showing this on a display. Before a driver starts charging tariff information needs to be given, detailed prices for all the components that make up the tariff plan applicable to this driver at this Charging Station. During charging the EV Driver needs to be shown the running total cost, updated at a regular, fitting interval. When the EV Driver stops charging the total cost of this transaction needs to be shown.</td></tr><tr><td>J.</td><td>Metering</td><td>This Functional Block describes the functionality for sending meter values, on a periodic sampling and/or clock-aligned timing basis.</td></tr><tr><td>K.</td><td>Smart Charging</td><td>This Functional Block describes all the functionality that enables the CSO (or indirectly a third party) to influence the charging current/power of a charging session, or set limits to the amount of power/current a Charging Station can offer to an EV.</td></tr><tr><td>L.</td><td>Firmware Management</td><td>This Functional Block describes the functionality that enables a CSO to update the firmware of a Charging Station.</td></tr><tr><td>M.</td><td>ISO 15118 Certificate Management</td><td>This Functional Block provides the installation and update of ISO 15118 certificates.</td></tr><tr><td>N.</td><td>Diagnostics</td><td>This Functional Block describes the functionality that enables a CSO to request and track the upload of a diagnostics file from a Charging Station, and to manage the monitoring of Charging Station data.</td></tr><tr><td>O.</td><td>Display Message</td><td>With the DisplayMessage feature OCPP enables a CSO to display a message on a Charging Station, that is not part of the firmware of the Charging Station. The CSO gets control over these messages: the CSO can set, retrieve (get), replace and clear messages.</td></tr><tr><td>P.</td><td>Data Transfer</td><td>This Functional Block describes the functionality that enables a party to add custom commands to OCPP, enabling custom extension to OCPP.</td></tr></table>
+
+# 3.3. All Functional Blocks and use cases
+
+The following table shows the full list of use cases supported by OCPP 2.0.1 and which use cases were already supported by OCPP 1.6 [OCPP1.6].
+
+<table><tr><td>Clause</td><td>Functional Block</td><td>UC ID</td><td>Use case name</td><td>OCPP 1.6</td><td>New in OCPP 2.0.1</td></tr><tr><td>A</td><td>Security</td><td>A01</td><td>Update Charging Station Password for HTTP Basic Authentication</td><td></td><td>o</td></tr><tr><td></td><td></td><td>A02</td><td>Update Charging Station Certificate by request of CSMS</td><td></td><td>o</td></tr><tr><td></td><td></td><td>A03</td><td>Update Charging Station Certificate initiated by the Charging Station</td><td></td><td>o</td></tr><tr><td></td><td></td><td>A04</td><td>Security Event Notification</td><td></td><td>o</td></tr><tr><td>B</td><td>Provisioning</td><td>B01</td><td>Cold Boot Charging Station</td><td>o</td><td></td></tr><tr><td></td><td></td><td>B02</td><td>Cold Boot Charging Station - Pending</td><td>o</td><td></td></tr><tr><td></td><td></td><td>B03</td><td>Cold Boot Charging Station - Rejected</td><td>o</td><td></td></tr><tr><td></td><td></td><td>B04</td><td>Offline Behavior Idle Charging Station</td><td>o</td><td></td></tr><tr><td></td><td></td><td>B05</td><td>Set Variables</td><td></td><td>o</td></tr><tr><td></td><td></td><td>B06</td><td>Get Variables</td><td></td><td>o</td></tr><tr><td></td><td></td><td>B07</td><td>Get Base Report</td><td></td><td>o</td></tr><tr><td></td><td></td><td>B08</td><td>Get Custom Report</td><td></td><td>o</td></tr><tr><td></td><td></td><td>B09</td><td>Setting a new NetworkConnectionProfile</td><td></td><td>o</td></tr><tr><td></td><td></td><td>B10</td><td>Migrate to new CSMS</td><td></td><td>o</td></tr><tr><td></td><td></td><td>B11</td><td>Reset - Without Ongoing Transaction</td><td>o</td><td></td></tr><tr><td></td><td></td><td>B12</td><td>Reset - With Ongoing Transaction</td><td>o</td><td></td></tr><tr><td>C</td><td>Authorization</td><td>C01</td><td>EV Driver Authorization using RFID</td><td>o</td><td></td></tr><tr><td></td><td></td><td>C02</td><td>Authorization using a start button</td><td></td><td>o</td></tr><tr><td></td><td></td><td>C03</td><td>Authorization using credit/debit card</td><td></td><td>o</td></tr><tr><td></td><td></td><td>C04</td><td>Authorization using PIN-code</td><td></td><td>o</td></tr><tr><td></td><td></td><td>C05</td><td>Authorization for CSMS initiated transactions</td><td></td><td>o</td></tr><tr><td></td><td></td><td>C06</td><td>Authorization using local id type</td><td></td><td>o</td></tr><tr><td></td><td></td><td>C07</td><td>Authorization using Contract Certificates</td><td></td><td>o</td></tr><tr><td></td><td></td><td>C08</td><td>Authorization at EVSE using ISO 15118 External Identification Means (EIM)</td><td></td><td>o</td></tr><tr><td></td><td></td><td>C09</td><td>Authorization by GroupId</td><td>o</td><td></td></tr><tr><td></td><td></td><td>C10</td><td>Store Authorization Data in the Authorization Cache</td><td>o</td><td></td></tr><tr><td></td><td></td><td>C11</td><td>Clear Authorization Data in Authorization Cache</td><td>o</td><td></td></tr><tr><td></td><td></td><td>C12</td><td>Start Transaction - Cached Id</td><td>o</td><td></td></tr><tr><td></td><td></td><td>C13</td><td>Offline Authorization through Local Authorization List</td><td>o</td><td></td></tr><tr><td></td><td></td><td>C14</td><td>Online Authorization through Local Authorization List</td><td>o</td><td></td></tr><tr><td></td><td></td><td>C15</td><td>Offline Authorization of unknown Id</td><td>o</td><td></td></tr><tr><td></td><td></td><td>C16</td><td>Stop Transaction with a Master Pass</td><td></td><td>o</td></tr><tr><td>D</td><td>LocalAuthorizationList</td><td>D01</td><td>Send Local Authorization List</td><td>o</td><td></td></tr><tr><td></td><td></td><td>D02</td><td>Get Local List Version</td><td>o</td><td></td></tr><tr><td>E</td><td>Transactions</td><td>E01</td><td>Start Transaction Options</td><td></td><td>o</td></tr><tr><td></td><td></td><td>E02</td><td>Start Transaction - Cable Plugin First</td><td>o</td><td></td></tr><tr><td></td><td></td><td>E03</td><td>Start Transaction - IdToken First</td><td>o</td><td></td></tr><tr><td></td><td></td><td>E04</td><td>Transaction started while Charging Station is offline</td><td>o</td><td></td></tr><tr><td></td><td></td><td>E05</td><td>Start Transaction - Id not Accepted</td><td>o</td><td></td></tr><tr><td></td><td></td><td>E06</td><td>Stop Transaction Options</td><td></td><td>o</td></tr><tr><td></td><td></td><td>E07</td><td>Transaction locally stopped by IdToken</td><td>o</td><td></td></tr><tr><td></td><td></td><td>E08</td><td>Transaction stopped while Charging Station is offline</td><td>o</td><td></td></tr><tr><td></td><td></td><td>E09</td><td>When cable disconnected on EV-side: Stop Transaction</td><td>o</td><td></td></tr><tr><td></td><td></td><td>E10</td><td>When cable disconnected on EV-side: Suspend Transaction</td><td>o</td><td></td></tr><tr><td></td><td></td><td>E11</td><td>Connection Loss During Transaction</td><td>o</td><td></td></tr><tr><td></td><td></td><td>E12</td><td>Inform CSMS of an Offline Occurred Transaction</td><td>o</td><td></td></tr><tr><td></td><td></td><td>E13</td><td>Transaction related message not accepted by CSMS</td><td>o</td><td></td></tr><tr><td></td><td></td><td>E14</td><td>Check transaction status</td><td></td><td>o</td></tr><tr><td></td><td></td><td>E15</td><td>End of charging process</td><td>o</td><td></td></tr><tr><td>F</td><td>RemoteControl</td><td>F01</td><td>Remote Start Transaction - Cable Plugin First</td><td>o</td><td></td></tr><tr><td></td><td></td><td>F02</td><td>Remote Start Transaction - Remote Start First</td><td>o</td><td></td></tr><tr><td></td><td></td><td>F03</td><td>Remote Stop Transaction</td><td>o</td><td></td></tr><tr><td></td><td></td><td>F04</td><td>Remote Stop ISO 15118 charging from CSMS</td><td></td><td>o</td></tr><tr><td></td><td></td><td>F05</td><td>Remotely Unlock Connector</td><td>o</td><td></td></tr><tr><td></td><td></td><td>F06</td><td>Trigger Message</td><td>o</td><td></td></tr><tr><td>G</td><td>Availability</td><td>G01</td><td>Status Notification</td><td>o</td><td></td></tr><tr><td></td><td></td><td>G02</td><td>Heartbeat</td><td>o</td><td></td></tr><tr><td></td><td></td><td>G03</td><td>Change Availability EVSE</td><td>o</td><td></td></tr><tr><td></td><td></td><td>G04</td><td>Change Availability Charging Station</td><td>o</td><td></td></tr><tr><td></td><td></td><td>G05</td><td>Lock Failure</td><td>o</td><td></td></tr><tr><td>H</td><td>Reservation</td><td>H01</td><td>Reservation</td><td>o</td><td></td></tr><tr><td></td><td></td><td>H02</td><td>Cancel Reservation</td><td>o</td><td></td></tr><tr><td></td><td></td><td>H03</td><td>Use a reserved EVSE</td><td>o</td><td></td></tr><tr><td></td><td></td><td>H04</td><td>Reservation Ended, not used</td><td>o</td><td></td></tr><tr><td>I</td><td>Tariff and Costs</td><td>I01</td><td>Show EV Driver-specific tariff information</td><td></td><td>o</td></tr><tr><td></td><td></td><td>I02</td><td>Show EV Driver running total cost during charging</td><td></td><td>o</td></tr><tr><td></td><td></td><td>I03</td><td>Show EV Driver final total cost after charging</td><td></td><td>o</td></tr><tr><td></td><td></td><td>I04</td><td>Show fallback tariff information</td><td></td><td>o</td></tr><tr><td></td><td></td><td>I05</td><td>Show fallback total cost message</td><td></td><td>o</td></tr><tr><td></td><td></td><td>I06</td><td>Update Tariff Information During Transaction</td><td></td><td>o</td></tr><tr><td>J</td><td>Metering</td><td>J01</td><td>Sending Meter Values not related to a transaction</td><td>o</td><td></td></tr><tr><td></td><td></td><td>J02</td><td>Sending transaction related Meter Values</td><td>o</td><td></td></tr><tr><td></td><td></td><td>J03</td><td>Charging Loop with metering information exchange</td><td></td><td>o</td></tr><tr><td>K</td><td>SmartCharging</td><td>K01</td><td>SetChargingProfile</td><td>o</td><td></td></tr><tr><td></td><td></td><td>K02</td><td>Central Smart Charging</td><td>o</td><td></td></tr><tr><td></td><td></td><td>K03</td><td>Local Smart Charging</td><td>o</td><td></td></tr><tr><td></td><td></td><td>K04</td><td>Internal Load Balancing</td><td>o</td><td></td></tr><tr><td></td><td></td><td>K05</td><td>Remote Start Transaction with Charging Profile</td><td>o</td><td></td></tr><tr><td></td><td></td><td>K06</td><td>Offline Behavior Smart Charging During Transaction</td><td>o</td><td></td></tr><tr><td></td><td></td><td>K07</td><td>Offline Behavior Smart Charging at Start of Transaction</td><td>o</td><td></td></tr><tr><td></td><td></td><td>K08</td><td>Get Composite Schedule</td><td>o</td><td></td></tr><tr><td></td><td></td><td>K09</td><td>Get Charging Profiles</td><td></td><td>o</td></tr><tr><td></td><td></td><td>K10</td><td>Clear Charging Profile</td><td>o</td><td></td></tr><tr><td></td><td></td><td>K11</td><td>Set / Update External Charging Limit With Ongoing Transaction</td><td></td><td>o</td></tr><tr><td></td><td></td><td>K12</td><td>Set / Update External Charging Limit Without Ongoing Transaction</td><td></td><td>o</td></tr><tr><td></td><td></td><td>K13</td><td>Reset / release external charging limit</td><td></td><td>o</td></tr><tr><td></td><td></td><td>K14</td><td>External Charging Limit with Local Controller</td><td></td><td>o</td></tr><tr><td></td><td></td><td>K15</td><td>Charging with load leveling based on High Level Communication</td><td></td><td>o</td></tr><tr><td></td><td></td><td>K16</td><td>Optimized charging with scheduling to the CSMS</td><td></td><td>o</td></tr><tr><td></td><td></td><td>K17</td><td>Renegotiating a Charging Schedule</td><td></td><td>o</td></tr><tr><td>L</td><td>Firmware Management</td><td>L01</td><td>Secure Firmware Update</td><td></td><td>o</td></tr><tr><td></td><td></td><td>L02</td><td>Non-Secure Firmware Update</td><td>o</td><td></td></tr><tr><td></td><td></td><td>L03</td><td>Publish Firmware file on Local Controller</td><td></td><td>o</td></tr><tr><td></td><td></td><td>L04</td><td>Unpublish Firmware file on Local Controller</td><td></td><td>o</td></tr><tr><td>M</td><td>ISO 15118 Certificate Management</td><td>M01</td><td>Certificate Installation EV</td><td></td><td>o</td></tr><tr><td></td><td></td><td>M02</td><td>Certificate Update EV</td><td></td><td>o</td></tr><tr><td></td><td></td><td>M03</td><td>Retrieve list of available certificates from a Charging Station</td><td></td><td>o</td></tr><tr><td></td><td></td><td>M04</td><td>Delete a specific certificate from a Charging Station</td><td></td><td>o</td></tr><tr><td></td><td></td><td>M05</td><td>Install CA certificate in a Charging Station</td><td></td><td>o</td></tr><tr><td></td><td></td><td>M06</td><td>Get Charging Station Certificate status</td><td></td><td>o</td></tr><tr><td>N</td><td>Diagnostics</td><td>N01</td><td>Retrieve Log Information</td><td>o</td><td></td></tr><tr><td></td><td></td><td>N02</td><td>Get Monitoring report</td><td></td><td>o</td></tr><tr><td></td><td></td><td>N03</td><td>Set Monitoring Base</td><td></td><td>o</td></tr><tr><td></td><td></td><td>N04</td><td>Set Variable Monitoring</td><td></td><td>o</td></tr><tr><td></td><td></td><td>N05</td><td>Set Monitoring Level</td><td></td><td>o</td></tr><tr><td></td><td></td><td>N06</td><td>Clear / Remove Monitoring</td><td></td><td>o</td></tr><tr><td></td><td></td><td>N07</td><td>Alert Event</td><td></td><td>o</td></tr><tr><td></td><td></td><td>N08</td><td>Periodic Event</td><td></td><td>o</td></tr><tr><td></td><td></td><td>N09</td><td>Get Customer Information</td><td></td><td>o</td></tr><tr><td></td><td></td><td>N10</td><td>Clear Customer Information</td><td></td><td>o</td></tr><tr><td>O</td><td>Display Message</td><td>001</td><td>Set DisplayMessage</td><td></td><td>o</td></tr><tr><td></td><td></td><td>002</td><td>Set DisplayMessage for Transaction</td><td></td><td>o</td></tr><tr><td></td><td></td><td>003</td><td>Get All DisplayMessages</td><td></td><td>o</td></tr><tr><td></td><td></td><td>004</td><td>Get Specific DisplayMessages</td><td></td><td>o</td></tr><tr><td></td><td></td><td>005</td><td>Clear a DisplayMessage</td><td></td><td>o</td></tr><tr><td></td><td></td><td>006</td><td>Replace DisplayMessage</td><td></td><td>o</td></tr><tr><td>P</td><td>DataTransfer</td><td>P01</td><td>Data Transfer to the Charging Station</td><td>o</td><td></td></tr><tr><td></td><td></td><td>P02</td><td>Data Transfer to the CSMS</td><td>o</td><td></td></tr></table>
+
+# NOTE
+
+OCPP is used in many different regions and for many different charging solutions. Not all functionalities offered by OCPP 2.0.1 will be applicable to all implementations. Implementers can decide what specific functionalities apply to their charging solution.
+
+For interoperability purposes, the Open Charge Alliance introduces Certification Profiles in Part 5 of the specification.
+
+# 4. Basic implementation of OCPP 2.0.1
+
+This section is informative.
+
+The OCPP protocol describes a large number of use cases and messages, which are not all needed to implement a basic Charging Station or CSMS. The table below lists messages that are typically implemented to deliver basic functionality for an OCPP managed Charging Station. The purpose of this list is to guide developers that are new to OCPP.
+
+Please note: this table does not define what needs to be done to become OCPP 2.0.1 "certified". The functionality that is to be implemented to become OCPP 2.0.1 certified is described in Part 5 of the specification, "Certification Profiles".
+
+Table 4. OCPP 2.0.1 Basic Implementation
+
+<table><tr><td>Functionality</td><td>Use cases</td><td>Messages</td></tr><tr><td>Booting a Charging Station</td><td>B01-B04</td><td>BootNotification</td></tr><tr><td>Configuring a Charging Station</td><td>B05-B07</td><td>SetVariables, GetVariables and GetReportBase (respond correctly to requests with reportBase = ConfigurationInventory, FullInventory and SummaryInventory).</td></tr><tr><td>Resetting a Charging Station</td><td>B11-B12</td><td>Reset</td></tr><tr><td>Authorization options</td><td>One of C01, C02 and C04</td><td>authorize</td></tr><tr><td>Transaction mechanism</td><td>E01 (one of S1-S6), E02-E03, E05, E06 (one of S1-S6), E07-E08, One of E09-E10, E11-E13</td><td>TransactionEvent</td></tr><tr><td>Availability</td><td>G01, G03-G04</td><td>Only ChangeAvailability and StatusNotification.</td></tr><tr><td>Monitoring Events</td><td>G05, N07</td><td>A basic implementation of the NotifyEvent message to be used to report operational state changes and problem/error conditions of the Charging Station, e.g. for Lock Failure. Also used for reporting built-in monitoring events.</td></tr><tr><td>Sending transaction related Meter values</td><td>J02</td><td>TransactionEvent</td></tr><tr><td>DataTransfer</td><td>P01-P02</td><td>Any OCPP implementations should at least be able to reject any request for DataTransfer if no (special) functionality is implemented.</td></tr></table>
+
+NOTE Please also refer to the section on Minimum Device Model in part 1.
--- /dev/null
+# OCPP
+
+# Table of Contents
+
+Disclaimer 1
+
+Version History 2
+
+1. Introduction. 3
+
+1.1. Goal of this document 3
+1.2. Terms and abbreviations 3
+
+2. 3-tier model 4
+
+3. Information Model 5
+
+4. Device Model: Addressing Components and Variables 6
+
+4.1. Components 6
+4.2. Variables 7
+4.3. Characteristics and Attributes 7
+4.4. Monitoring 9
+4.5. Standardized lists of Components and Variables 10
+4.6. Minimum Device Model 10
+
+5. Information Model vs. Device Model 12
+
+6. Using OCPP for other purposes than EV charging 13
+
+7. Numbering 14
+
+7.1. EVSE numbering. 14
+7.2. Connector numbering 14
+7.3. Transaction IDs. 14
+
+8. Topologies supported by OCPP 15
+
+8.1. Charging Station(s) directly connected to CSMS 15
+8.2. Multiple Charging Stations connected to CSMS via Local Proxy 15
+8.3. Multiple Charging Stations connected to CSMS via Local Controller 16
+8.4. Non-OCPP Charging Stations connected to CSMS via OCPP Local Controller 16
+8.5. DSO control signals to CSMS 16
+8.6. Parallel control by CSMS and EMS. 17
+
+9. Part 1 Appendix: OCPP Information Model. 18
+
+9.1. Explanation of UML representation and message generation 18
+9.2. Visual Representation of OCPP Information Model 19
+
+# 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
+
+<table><tr><td>Version</td><td>Date</td><td>Description</td></tr><tr><td>2.0.1 Edition 3</td><td>2024-05-06</td><td>OCPP 2.0.1 Edition 3. All errata from OCPP 2.0.1 Part 1 until and including Errata 2024-04 have been merged into this version of the specification.</td></tr><tr><td>2.0.1</td><td>2020-03-31</td><td>Final version of OCPP 2.0.1</td></tr><tr><td>2.0</td><td>2018-04-11</td><td>OCPP 2.0 April 2018
+First release of this Architecture & Topology document</td></tr></table>
+
+# 1. Introduction
+
+# 1.1. Goal of this document
+
+The goal of this document is to describe a number of architecture related topics for OCPP 2.0.1.
+
+OCPP was originally intended for two way communication between a backoffice, in OCPP the Charging Station Management System (in this document: CSMS) and a Charging Station. The protocol has become more advanced and with every new revision new functionalities and options are added. It has evolved into a protocol that can be used in different architectures for different types of Charging Stations.
+
+This document describes, in addition to the original "simple" setup CSMS <> Charging Station, a number of topologies as an additional explanation for using OCPP. Furthermore, the Device Management concept to configure and monitor any type of Charging Station, the OCPP Information Model and the 3-tier model are explained.
+
+This document is partially informative and partially normative and is not intended to limit the use of OCPP. However, it does add an explanation what kind of use of OCPP the creators of OCPP had in mind when creating this version of the specification. This document is therefore also intended to support the reader of the protocol specification in Part 2 of OCPP to understand how it can be used.
+
+# 1.2. Terms and abbreviations
+
+This section contains the terminology and abbreviations that are used throughout this document.
+
+# 1.2.1. Terms
+
+<table><tr><td>Term</td><td>Meaning</td></tr><tr><td>Charging Station</td><td>The Charging Station is the physical system where EVs can be charged. A Charging Station has one or more EVSEs.</td></tr><tr><td>Connector</td><td>The term Connector, as used in this specification, refers to an independently operated and managed electrical outlet on a Charging Station. In other words, this corresponds to a single physical Connector. In some cases an EVSE may have multiple physical socket types and/or tethered cable/Connector arrangements (i.e. Connectors) to facilitate different vehicle types (e.g. four-wheeled EVs and electric scooters).</td></tr><tr><td>EVSE</td><td>An EVSE is considered as an independently operated and managed part of the Charging Station that can deliver energy to one EV at a time.</td></tr><tr><td>Local port Smart Meter</td><td>The Local port on a Smart Meter is a port (for example serial) on a digital electricity meter that provides access to information about meter readings and usage.</td></tr></table>
+
+# 1.2.2. Abbreviations
+
+<table><tr><td>Abbreviation</td><td>Meaning</td></tr><tr><td>DSO</td><td>Distribution System Operator</td></tr><tr><td>CSO</td><td>Charging Station Operator</td></tr><tr><td>CSMS</td><td>Charging Station Management System</td></tr><tr><td>EMS</td><td>Energy Management System. In this document this is defined as a device that manages the local loads (consumption and production) based on local and/or contractual constraints and/or contractual incentives. It has additional inputs, such as sensors and controls from e.g. PV, battery storage.</td></tr><tr><td>EVSE</td><td>Electric Vehicle Supply Equipment</td></tr><tr><td>LC</td><td>Local Controller. In this document this is defined as a device that can send messages to its Charging Stations, independently of the CSMS. A typical usage for this is the local smart charging case described in the Smart Charging chapter of Part 2 of OCPP, where a Local Controller can impose charge limits on its Charging Stations.</td></tr><tr><td>LP</td><td>Local Proxy. Acts as a message router.</td></tr></table>
+
+# 2. 3-tier model
+
+This section is informative.
+
+To understand the terminology in the OCPP specification, it is important to understand the starting point of this specification. The OCPP specification uses the term Charging Station as the physical system where EVs can be charged. A Charging Station can have one or more EVSEs (Electric Vehicle Supply Equipment). An EVSE is considered as a part of the Charging Station that can deliver energy to one EV at a time. The term Connector, as used in this specification, refers to an independently operated and managed electrical outlet on a Charging Station, in other words, this corresponds to a single physical Connector. In some cases an EVSE may have multiple physical socket types and/or tethered cable/connector arrangements to facilitate different vehicle types (e.g. four-wheeled EVs and electric scooters). This setup is referred to as the 3-tier model and visualized in the figure below.
+
+
+Figure 1. 3-tier model as used in OCPP
+
+NOTE
+
+This section describes the charging infrastructure on a logical level for communication purposes. We do not wish to impose a mapping onto physical hardware. This is a manufacturer's choice. For example, the EVSE might be integrated into a Charging Station and to look as just a part of that device, but it might just as well have its own casing and live outside of the physical entity Charging Station, for example a charging plaza with 20 EVSEs and Connectors which communicates via 1 modem as 1 Charging Station to the CSMS is seen by OCPP as 1 Charging Station.
+
+# 3. Information Model
+
+This section is informative.
+
+Given the growing complexity of the messages of OCPP, OCPP 2.0.1 is based on an Information Model as a blueprint for the messages and inherent schemas of OCPP. With an information model, we mean a logical object set, describing real objects with all their properties. This provides an informative representation of information structure in the protocol. Furthermore, it enables making objects within OCPP reusable and enables consistent definition of messages and automatically generated message schemas (Part 3).
+
+The Information Model is a model, also called Domain Model or Core Model, based on which the OCPP messages and datatypes are generated. These datatypes are extracted from the the OCPP 1.6 specification and are named Core DataTypes and Qualified DataTypes. The figure below illustrates how the DataTypes in the information model are built up.
+
+In part 2 - Specification, chapter Datatypes, some DataTypes have the Common: prefix. This originates from the Information Model. It means that the DataType is able to be shared among other DataTypes and Messages. This has no impact on the OCPP implementation of a device.
+
+
+Figure 2. Example datatypes
+
+The Information Model is divided into a number of "functions" to have a better overview of the model (thus for readability):
+
+Transactions
+
+- SmartCharging
+- Metering
+- Security (Profiles/Authorization)
+- Communication
+ SecondaryActorSchedule
+
+For more details about the actual model per function, please refer to the appendix.
+
+# 4. Device Model: Addressing Components and Variables
+
+The Device Model refers to a generalized mechanism within OCPP to enable any model of Charging Station to report how it is build up, so it can be managed from any CSMS. To manage a Charging Station with the Device Model (i.e. "to manage a device") a number of messages and use cases is defined to configure and monitor a Charging Station in detail, without defining the structure of the Charging Station in advance. To be able do do this, OCPP provides a generalized mechanism to allow the exchange of a wide range of information about Charging Station. This version of the Device Model has the 3-tier model (Charging Station, EVSE, Connector) as its starting point, which means that any description created with the Device Model follows these three tiers. The remainder of this chapter describes how the data (and associated meta-data) looks like that can be exchanged between a Charging Station and a CSMS. The use cases and messages that are used to manage a device are not described here, but in Part 2 of the specification. This chapter only focuses on the data model.
+
+# 4.1. Components
+
+In OCPP 2.0.1, a Charging Station is modelled as a set of "Components", typically representing physical devices (including any external equipment to which it is connected for data gathering and/or control), logical functionality, or logical data entities. Components of different types are primarily identified by a ComponentName, that is either the name of a standardized component (see OCPP part 2c), or a custom/non-standardized component name, for new, pre-standardized equipment, vendor specific extensions, etc.
+
+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. 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 "evseld = 1". In the same manner, Connector 1 on EVSE 1 is represented by the component named "Connector" (no instance name) with "evseld = 1, connectorld = 1".
+
+By default, all components are located at the ChargingStation tier, but individual instances of any component can be associated with a specific EVSE, or a specific Connector (on a specific EVSE) by including EVSE or EVSE and Connector identification numbers as part of a component addressing reference.
+
+Additionally, there can be more than one instance of a component (in the functional dimension), representing multi-occurrence physical or logical components (e.g. power converter modules, fan banks, resident firmware images, etc.).
+
+Each distinct component instance is uniquely identified by an (optional) componentInstance addressing key. When no
+
+componentInstance is provided, then the default or only instance of a component is referenced.
+
+Components do not in themselves hold data: all externally accessible data associated with each component instance is represented by a set of variables that can be read, set, and/or monitored for changes. The relationship of a Component with one or more Variables is illustrated in below.
+
+
+Figure 3. Component and variables
+
+The table below illustrates some common components (by their standardized component-names), and examples of the hierarchical location levels at which they typically occur for a basic home charger and a typical public Charging Station.
+
+Basic home charger example configuration
+
+<table><tr><td>ChargingStation tier</td><td>EVSE tier</td><td>Connector tier</td></tr><tr><td>ChargingStation (itself, as a whole)</td><td>EVSE (itself, as a whole)</td><td>Connector (itself, as a whole)</td></tr><tr><td>RadioLink</td><td>ControlMetering</td><td>PlugRetentionLock</td></tr><tr><td>TokenReader</td><td>OverCurrentBreaker</td><td></td></tr><tr><td>Controller</td><td>RCD</td><td></td></tr><tr><td colspan="3">Basic home charger example configuration</td></tr><tr><td></td><td>ChargingStatusIndicator</td><td></td></tr></table>
+
+<table><tr><td colspan="3">Public Charging Station example configuration</td></tr><tr><td>ChargingStation tier</td><td>EVSE tier</td><td>Connector tier</td></tr><tr><td>ChargingStation (itself, as a whole)</td><td>EVSE (itself, as a whole)</td><td>Connector (itself, as a whole)</td></tr><tr><td>ElectricalFeed</td><td>ElectricalFeed</td><td>AccessProtection</td></tr><tr><td>TokenReader</td><td>TokenReader</td><td>PlugRetentionLock</td></tr><tr><td>Display</td><td>Display</td><td></td></tr><tr><td>FiscalMetering</td><td>FiscalMetering</td><td></td></tr><tr><td>Clock</td><td>ControlMetering</td><td></td></tr><tr><td>Controller</td><td>OverCurrentBreaker</td><td></td></tr><tr><td></td><td>RCD</td><td></td></tr><tr><td></td><td>ChargingStatusIndicator</td><td></td></tr></table>
+
+# 4.2. Variables
+
+Every component has a number of variables, that can, as appropriate, be used to hold, set, read, and/or report on all (externally visible) data applicable to that component, including configuration parameters, measured values (e.g. a current or a temperature) and/or monitored changes to variable values.
+
+Although many components can have associated variables that are, by their nature, specific to the component type (e.g.
+
+ConnectorType for a Connector component), there are a minimal set of standardized variables that are used to provide standardized high level event notification and state/status reporting (e.g. Problem, Active) on a global and/or selective basis, and also to report component presence, availability, etc. during the inventorying/discovery process (e.g. Available, Enabled). A Charging Station is not required to report the base variables: Present, Available and Enabled when they are readily and set to true. When a Charging
+
+Station does not report: Present, Available and/or Enabled the Central System SHALL assume them to be readily and set to true Variables can be any of a range of common general-purpose data types (boolean, integer, decimal, date-time, string), but also can have their allowable values constrained to particular ranges, enumeration lists, sets, or ordered lists.
+
+To support complex components, there can be more than one instance of any given variable name associated with any components (e.g. power converter modules reporting temperature, current, or voltage at multiple points).
+
+Each distinct variable instance is uniquely identified by an (optional) variableInstance addressing key string value. When no variableInstance is provided, then the default or only instance of a variable is referenced.
+
+# 4.3. Characteristics and Attributes
+
+Each variable, in addition to its primary ("Actual") value, can have a set of associated secondary data that is linked to the same primary variable name and variableInstance.
+
+This greatly avoids cluttering the variables namespace with confusing clusters of ancillary variable names (e.g. FanSpeed,
+
+FanSpeedUnits, MinimumFanSpeed, BaseFanSpeed) that lack consistence and discoverability.
+
+The ancillary variable data includes:
+
+- Variable characteristics meta-data (read-only)
+
+。Unit of measure (V,W,kW,kWh,etc.)
+。Data type (Integer, Decimal, String, Date, OptionList, etc.)
+。Lower limit
+。Upper limit
+。List of allowed values for enumerated variables
+
+- Variable attributes (read-write):
+
+。Actual value
+。Target value
+。Configured lower limit
+。Configured upper limit
+。Mutability (whether the value can be altered or not, e.g. ReadOnly orReadWrite)
+. Persistence (whether the value is preserved in case of a reboot or power loss)
+
+The relationship of a Variable with one or more VariableAttributes is illustrated in the figure below.
+
+
+Figure 4. Variable attributes and characteristics
+
+There is a difference between how to implement (physical) devices and (virtual) controller components, using the DeviceModel. A (virtual) controller component has to be implementing as described in part 2 chapter the "Referenced Components and Variables". These kind of components/variables are only using the variableAttribute type 'Actual'. Depending on if this variableAttribute is wrritable, the CSMS can use this to set a new value.
+
+(Physical) devices are a bit more complex to implement. For example, there is a fan with a fan speed, that has a (physical) limit with a range of 0 - 1000. But it should not be allowed to set the value below 200, because the fan can stop functioning. And it should not be set above 500, because that would be bad for the fan on the long run. When implementing this device using the DeviceModel, it can be defined as follows:
+
+<table><tr><td>Component</td><td>name</td><td colspan="2">Fan</td></tr><tr><td rowspan="13">Variable</td><td>name</td><td colspan="2">FanSpeed</td></tr><tr><td rowspan="3">variableAttribute 1</td><td>type</td><td>Actual</td></tr><tr><td>value</td><td><The current fan speed value of the fan.></td></tr><tr><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="3">variableAttribute 2</td><td>type</td><td>Target</td></tr><tr><td>value</td><td><The CSMS can use this value to adjust the fan speed. The Charging Station SHALL try to keep the actual value at the target value.></td></tr><tr><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableAttribute 3</td><td>type</td><td>MaxSet</td></tr><tr><td>value</td><td><The value '500' from the example. The target may not be set above this value.></td></tr><tr><td rowspan="2">variableAttribute 4</td><td>type</td><td>MinSet</td></tr><tr><td>value</td><td><The value '200' from the example. The target may not be set below this value.></td></tr><tr><td rowspan="2">variableCharacteristics</td><td>maxLimit</td><td><The value '1000' from the example. This could be the physical max limit of the fan.></td></tr><tr><td>minLimit</td><td><The value '0' from the example. This could be the physical min limit of the fan. This could also be -1000, if the fan is also able to rotate in the other direction.></td></tr><tr><td>Description</td><td colspan="3">This is an example of how a fan could be defined using the DeviceModel.</td></tr></table>
+
+When trying to set the target with value 600, the Charging Station will first check the allowed min and max values/limits and reject
+
+the set. If the target value is set to 500, the value is within range and the Charging Station will allow the set and start to adjust the actual fan speed. If the actual fan speed is measured to be 502, it's out of range. But it should be reported to the CSMS, so the actual value of a physical component should be updated without checking the min and max values/limits.
+
+# 4.4. Monitoring
+
+Optional monitoring settings can be associated with a variable, that allow changes to variable (Actual) values are to be reported to the CSMS as event notifications.
+
+These include:
+
+Monitoring value
+Monitoring type: upper threshold, lower threshold, delta, periodic
+
+- Severity level when reporting the event
+
+The following table show which MonitorType/dataType combinations are possible.
+
+<table><tr><td></td><td>string</td><td>decimal</td><td>integer</td><td>dateTime</td><td>boolean</td><td>OptionList</td><td>SequenceList</td><td>MemberList</td></tr><tr><td>UpperThresh old</td><td></td><td>X</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>LowerThresh old</td><td></td><td>X</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Delta</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td></tr><tr><td>Periodic</td><td>X</td><td>X</td><td>X</td><td></td><td>X</td><td>X</td><td>X</td><td>X</td></tr><tr><td>PeriodicCloc kAligned</td><td>X</td><td>X</td><td>X</td><td></td><td>X</td><td>X</td><td>X</td><td>X</td></tr></table>
+
+- For UpperThreshold and LowerThreshold the value represents the to be exceeded value by the actual value of the variable.
+ For Delta this value represents the change in value comparing with the actual value from the moment the monitor was set.
+
+When the dataType of the variable is integer or decimal, this value represents the difference to be reached to trigger the monitor.
+。When thedataType of the variable is DateTime the unit of measure will be in seconds.
+When the dataType of the variable is string, boolean, OptionList, SequenceList or MemberList, this value is ignored. The monitor will be triggered by every change in the actual value.
+
+- When a delta monitor is triggered OR when the Charging Station has rebooted, the Charging Station shall set a new momentary value.
+- For Periodic and PeriodicClockAligned the value represents the interval in seconds.
+
+The relationship between a Variable and one or more VariableMonitoring elements is illustrated in the figure below.
+
+
+Figure 5. Variables and monitoring
+
+# 4.5. Standardized lists of Components and Variables
+
+To provide some level of interoperability between different Charging Stations and CSMSs, besides the above defined model of Components and Variables, part 2 - appendices of the OCPP specification provides a list of standardized names for Components and Variables. The idea of this lists is to make sure that if a Charging Station and CSMS want to exchange information about a component, they both use the same name and description if it is listed in the OCPP specification. For names of a Components or Variables that are not listed in the specification, bilateral appointments between Charging Station manufacturer and CSMS are to be made. In these cases it is advised to provide feedback to the Open Charge Alliance to be able to include new/additional Components and Variables in new versions of OCPP.
+
+# 4.6. Minimum Device Model
+
+Since the Device Model is a generalized mechanism which can be applied to any model of Charging Station, the complexity of different implementations can vary. It consists of a number of use cases and messages that are not all required. This section describes the minimum part of the Device Model that needs to be implemented to create a working implementation of OCPP 2.0.1.
+
+The Device Model introduces Components and Variables that can be used for configuring and monitoring a Charging Station. A number of these Components and Variables are included in the list of Referenced Components and Variables (grouped by Functional Block) in Part 2 of the specification. When implementing a Functional Block, ALL required Configuration Variables that belong to a Functional Block SHALL be implemented. The required Configuration Variables from the General section SHALL also be implemented for all implementations of OCPP 2.0.1.
+
+The following table describes which messages are required or optional to implement for all use cases that are part of the Device Model implementation.
+
+<table><tr><td colspan="2">Use cases / messages that are part of a minimum Device Model implementation</td></tr><tr><td>Use case</td><td>Messages</td></tr><tr><td>B05 Set Variables</td><td>SetVariables message MUST be implemented</td></tr><tr><td>B06 Get Variables</td><td>GetVariables message MUST be implemented.</td></tr><tr><td>B07 Get Base Report</td><td>GetBaseReport message MUST be implemented and MUST support ConfigurationInventory and FullInventory. The content of these reports depends on the implementation of the Charging Station. It is up to the implementer to decide which components and variables exist in the implementation.</td></tr><tr><td colspan="2">Additional use cases / messages that are not part of a minimum Device Model implementation</td></tr><tr><td>Use case</td><td>Messages</td></tr><tr><td>B08 Get Custom Report</td><td>GetCustomReport message is optional.</td></tr><tr><td>N02 Get Monitoring Report</td><td>GetMonitoringReportRequest message is optional.</td></tr><tr><td>N03 Set Monitoring Base</td><td>SetMonitoringBaseRequest message is optional.</td></tr><tr><td>N04 Set Variable Monitoring</td><td>SetVariableMonitoringRequest message is optional.</td></tr><tr><td>N05 Set Monitoring Level</td><td>SetMonitoringLevelRequest message is optional.</td></tr><tr><td>N06 Clear/Remove Monitoring</td><td>ClearVariableMonitoringRequest message is optional.</td></tr><tr><td>N07 Alert Event</td><td>it is RECOMMENDED that NotifyEventRequest is implemented in the Charging Station even when monitoring is not implemented, so that this can be used to report built-in monitoring events.</td></tr><tr><td>N08 Periodic Event</td><td>see N07.</td></tr></table>
+
+# 5. Information Model vs. Device Model
+
+As described above, the terms Information Model and Device Model refer to different concepts. The Information Model refers to a model of the information structure upon which the messages and datatypes in OCPP are based, whereas the Device Model refers to a generalized mechanism within OCPP to enable any model of Charging Station to report how it is build up so, it can be managed from any CSMS without defining the structure of the Charging Station in advance.
+
+The messages that are used for Device Management are therefore part of the Information Model and the objects that are used for modelling a device ('Component' and 'Variable') are also part of the Information Model.
+
+# 6. Using OCPP for other purposes than EV charging
+
+As indicated in the introduction of this document, OCPP is primarily intended for two way communication between a CSMS and a Charging Station. However, with the addition of the Device Model as described in the chapter Device Model, OCPP can additionally be used for other purposes. For example, the reporting of Events or Status changes in transformers or stand-alone battery packs might also be useful for companies that are rolling out EV charging infrastructure. In this example, a BootNotification could be used to connect these devices to a management system. In the device model a device that is not a Charging Station, can be recognized by the fact that the component Charging Station is not present at the top level. At the moment the OCPP specification does not provide use cases for non Charging Station devices. However, they may be added in a future version of OCPP.
+
+# 7. Numbering
+
+This section is normative.
+
+# 7.1. EVSE numbering
+
+To enable the CSMS to address all the EVSEs of a Charging Station, EVSEs MUST always be numbered in the same way.
+
+EVSEs numbering (evselds) MUST be as follows:
+
+- The EVSEs MUST be sequentially numbered, starting from 1 at every Charging Station (no numbers may be skipped).
+- evselds MUST never be higher than the total number of EVSEs of a Charging Station
+- For operations initiated by the CSMS, evseld 0 is reserved for addressing the entire Charging Station.
+- For operations initiated by the Charging Station (when reporting), evseld 0 is reserved for the Charging Station main controller.
+
+Example: A Charging Station with 3 EVSEs: All EVSEs MUST be numbered with the IDs: 1, 2 and 3. It is advisable to number the EVSEs of a Charging Station in a logical way: from left to right, top to bottom incrementing.
+
+# 7.2. Connector numbering
+
+To enable the CSMS to address all the Connectors of a Charging Station, Connectors MUST always be numbered in the same way.
+
+Connector numbering (connectorlds) MUST be as follows:
+
+- The connectors are numbered (increasing) starting at connectorld 1 on every EVSE
+- Every connector per EVSE has a unique number
+- ID of the first Connector of an EVSE MUST be 1
+ Additional Connectors of the same EVSE MUST be sequentially numbered (no numbers may be skipped)
+- connectorlds MUST never be higher than the total number of connectors on that EVSE
+
+Example: A Charging Station with 3 EVSEs that each have 2 connectors, is numbered as follows:
+
+- EVSE 1 has connectors with connectorld 1 and 2
+- EVSE 2 has connectors with connectorld 1 and 2
+- EVSE 3 has connectors with connectorld 1 and 2
+
+# 7.3. Transaction IDs
+
+TransactionIds are now generated by the Charging Station and MUST be unique on this Charging Station for every started transaction.
+
+In OCPP 1.x this was done by the CSMS.
+
+The format of the transaction ID is left to implementation. This MAY for example be an incremental number or an UUID.
+
+# 8. Topologies supported by OCPP
+
+This chapter shows a number of topologies for using OCPP. As indicated in the introduction, OCPP was originally used for a setup where each Charging Station communicates directly with the CSMS. It is important to keep in mind that OCPP has no knowledge of the topology of the Charging Station network. The following figure shows the possible components in a setup using OCPP and the relations between these components:
+
+
+Figure 6. Possible components in a setup using OCPP
+
+# 8.1. Charging Station(s) directly connected to CSMS
+
+# Description
+
+This is the basic setup for using OCPP.
+
+
+Figure 7. Charging Station directly connected to CSMS
+
+# 8.2. Multiple Charging Stations connected to CSMS via Local Proxy
+
+# Description
+
+In some situations it is desirable to route all communications for a group of Charging Stations through a single network node (i.e. modem, router, etc.). A typical example is the situation where a number of a Charging Stations are located in an underground parking garage with little or no access to the mobile network. In order to provide access to mobile data the Charging Stations are linked to a central data communications unit over a LAN. This central unit connects to the mobile network and acts as a proxy between CSMS and Charging Stations. Such a unit is called a "local proxy" (LP) in OCPP. A local proxy acts as a message router. Neither the CSMS nor the Charging Stations are aware of the topology of the network. For the Charging Stations in the group the local proxy "is" the CSMS. Similarly, for the CSMS the local proxy "is" the Charging Station. The diagram below illustrates this configuration.
+
+
+Figure 8. Multiple Charging Stations connected to CSMS via Local Proxy
+
+# 8.3. Multiple Charging Stations connected to CSMS via Local Controller
+
+# Description
+
+Whereas a local proxy does little more than route OCPP messages, a Local Controller can send messages to its Charging Stations, independently of the CSMS. A typical usage for this is the local smart charging case described in the Smart Charging chapter of Part 2 of OCPP, where a Local Controller can impose charge limits on its Charging Stations. In order for a Local Controller to be addressed by the CSMS, it needs to have its own Charging Station identity. From the point of view from OCPP, the Local Controller will just be a Charging Station (without any EVSEs/Connectors). The CSMS will possess the logic to deal with the Local Controller in order to support, for example, local smart charging. It is up to the implementation of the CSMS, whether the group topology is manually configured or deduced from the network based on IP addresses and information in BootNotifications. The diagram below illustrates this configuration.
+
+
+Figure 9. Multiple Charging Stations connected to CSMS via Local Controller
+
+# NOTE
+
+Technically this topology can be realized in multiple ways. When using this setup with web sockets, this implies that when a Charging Station connects to the Local Controller, it should open a socket connection with the same address to the CSMS. The advantages of this approach is that the Local Controller can see all the messages and act on it, messages don't have to wait, firmware updates etc. on the Charging Stations are possible and the CSMS does not need special software. It could (in big installations) lead to a lot of socket connections between CSMS and LC needed. For further information, please refer to OCPP implementation guide in Part 4.
+
+# 8.4. Non-OCPP Charging Stations connected to CSMS via OCPP Local Controller
+
+# Description
+
+This setup has multiple non-OCPP Charging Stations that are abstracted away using a OCPP enabled Local Controller. When applying OCPP in this situation, the LC should be considered as a Charging Station with many EVSEs or the LC should act as multiple OCPP Charging Stations (having their own Charging Station Identity).
+
+
+Figure 10. Multiple non-OCPP Charging Stations connected to CSMS via Local Controller
+
+# 8.5. DSO control signals to CSMS
+
+# Description
+
+This is a set up in which the CSMS is the only application sending signals to a its Charging Stations, but the CSMS receives smart charging signals from a DSO based on (most likely) grid constraints. This means that a non-OCPP signal such as OpenADR or OSCP is received and based on this signal, the CSMS limits charging on its Charging Stations. CSOs that want full control over their Charging Station use this architecture, this way they are in control of the amount of energy being used by their Charging Stations. This can be done by sending charging profiles / charging schedules to Charging Stations.
+
+
+Figure 11. Smart Charging - DSO control signals to CSMS
+
+# 8.6. Parallel control by CSMS and EMS
+
+# Description
+
+In a (semi-)private situation where a Charging Station is not only connected to the CSMS, but also to an Energy Management System, some form of parallel control should be supported. OCPP should at least be used for Charging Station maintenance, but OCPP 2.0.1 also supports reporting external smart charging control limits. So if the Energy Management System decides that charging at a later time is "better", the Energy Management System can impose an external limit (e.g. 0) to a Charging Station, which the Charging Station in turn can report to the CSMS via OCPP. The Energy Management System might get input from e.g. Local port of Smart Meter to prevent overloading connection but can also have other reasons for not charging (e.g. weather conditions).
+
+
+Figure 12. Parallel control by CSMS and EMS
+
+# 9. Part 1 Appendix: OCPP Information Model
+
+# 9.1. Explanation of UML representation and message generation
+
+In the next paragraph, the UML schemes of the OCPP Information Model are shown. The model is based on the Common Information Model (CIM) and to some extent to the CEFACT naming standards (only part of the standard). The objects in the model are named BusinessComponents and inherit properties from the CIM IdentifiedObject, such as MRID and Name. In the UML diagrams the attributes that are inherited from IdentifiedObject are shown under the IdentifiedObject stereotype (between $< < >$ ).
+
+Other attributes are listed under the stereotype $< <$ Content $>$
+
+The messages in OCPP are derived from the model represented in the next paragraph, in a 3 step process:
+
+
+Figure 13. Process from information Model to Messages / schemes
+
+After creating the Information Model, the messages are created based on the Information Model. However, in this transition (first arrow), some rules are (manually) applied for modelling messages. The most important rule that is applied, is that messages containing a reference to a <class> with only one <field>, are replaced by a field with the name <class><field>. For example, if a message contains a Transaction, with only an Id, this is replaced by a transactionId.
+
+In the next step, when generating the messages and datatypes section of Part 2 of the specification, for readability, all Core DataTypes such as CounterType, are replaced by the Primitive DataType they refer to (except for enumerations) in this example integer.
+
+# 9.2. Visual Representation of OCPP Information Model
+
+
+Figure 14. OCPP Information Model: Transactions
+
+
+Figure 15. OCPP Information Model: SmartCharging
+
+
+Figure 16. OCPP Information Model: Metering
+
+
+Figure 17. OCPP Information Model: Device Model
+
+
+Figure 18. OCPP Information Model: Security-Profiles
+
+
+Figure 19. OCPP Information Model: Security-Authorization
+
+
+Figure 20. OCPP Information Model: Communication
+
+
+Figure 21. OCPP Information Model: SecondaryActorSchedule
--- /dev/null
+# OCPP
+
+# Table of Contents
+
+Disclaimer 1
+
+Version History 2
+
+1. Security Events 3
+
+2. Standardized Units of Measure 4
+
+3. Standardized Components 5
+
+3.1. Controller Components 5
+3.2. Physical Components 13
+3.3. Summary List of Standardized Components 29
+
+4. Standardized Variables 32
+
+5. Reason Codes 36
+
+# 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
+
+<table><tr><td>Appendix version</td><td>Date</td><td>OCPP Version</td><td>Description</td></tr><tr><td>1.4</td><td>2024-05-06</td><td>OCPP 2.0.1 Edition 3</td><td>Appendix version for Edition 3 Updated parts are marked with " (Updated in v1.4)"</td></tr><tr><td>1.3</td><td>2022-12-15</td><td>OCPP 2.0.1</td><td>Appendix version for Errata 2 (2022)
+Updated parts are marked with " (Updated in v1.3)".</td></tr><tr><td>1.2</td><td>2021-10-01</td><td>OCPP 2.0.1</td><td>Appendix version for Errata 1 (2021)
+Appendix 3: Updated components are marked with " (Updated in v1.2)".
+Appendix 3: Added ConnectedEV component for info from ISO15118 and CHAdeMO.
+Appendix 5: Added reason MissingDeviceModellinfo</td></tr><tr><td>1.1</td><td>2020-03-23</td><td>OCPP 2.0.1</td><td>Update for OCPP 2.0.1</td></tr><tr><td>1.0</td><td>2018-04-11</td><td>OCPP 2.0</td><td>First release of this Appendix for OCPP 2.0</td></tr></table>
+
+# Appendix 1. Security Events
+
+The table below provides a list of security events. Security events that are implemented SHALL be stored at the security log and security events that are implemented and marked as critical SHALL also be pushed to the CSMS.
+
+This is a non-exhaustive list of security events, when a security event matches the description of one of the Security Events in this section, for interoperability reasons, the Security Event from this section SHALL be used, instead of adding a new (proprietary) Security Event. Some security events like; InvalidCsmsCertificate, InvalidChargingStationCertificate, etc. are mandatory to be implemented. Please refer to Part 2 - Specification for which security events are mandatory to be implemented.
+
+(Updated in v1.3)
+
+<table><tr><td>Security Event</td><td>Description</td><td>Critical</td></tr><tr><td>FirmwareUpdated</td><td>The Charging Station firmware is updated</td><td>Yes</td></tr><tr><td>FailedToAuthenticationAtCsms</td><td>The authentication credentials provided by the Charging Station were rejected by the CSMS</td><td>No</td></tr><tr><td>CsmsFailedToAuthentication</td><td>The authentication credentials provided by the CSMS were rejected by the Charging Station</td><td>No</td></tr><tr><td>SettingSystemTime</td><td>The system time on the Charging Station was changed more than ClockCtrlr.TimeAdjustmentReportingThreshold seconds</td><td>Yes</td></tr><tr><td>StartupOfTheDevice</td><td>The Charging Station has booted</td><td>Yes</td></tr><tr><td>ResetOrReboot</td><td>The Charging Station was rebooted or reset</td><td>Yes</td></tr><tr><td>SecurityLogWasCleared</td><td>The security log was cleared</td><td>Yes</td></tr><tr><td>ReconfigurationOfSecurityParameters</td><td>Security parameters, such as keys or the security profile used, were changed</td><td>No</td></tr><tr><td>MemoryExhaustion</td><td>The Flash or RAM memory of the Charging Station is getting full</td><td>Yes</td></tr><tr><td>InvalidMessages</td><td>The Charging Station has received messages that are not valid OCPP messages, if signed messages, signage invalid/incorrect</td><td>No</td></tr><tr><td>AttemptedReplayAttacks</td><td>The Charging Station has received a replayed message (other than the CSMS trying to resend a message because it there was for example a network problem)</td><td>No</td></tr><tr><td>TamperDetectionActivated</td><td>The physical tamper detection sensor was triggered</td><td>Yes</td></tr><tr><td>InvalidFirmwareSignature</td><td>The firmware signature is not valid</td><td>Yes</td></tr><tr><td>InvalidFirmwareSigningCertificate</td><td>The certificate used to verify the firmware signature is not valid</td><td>Yes</td></tr><tr><td>InvalidCsmsCertificate</td><td>The certificate that the CSMS uses was not valid or could not be verified</td><td>Yes</td></tr><tr><td>InvalidChargingStationCertificate</td><td>The certificate sent to the Charging Station using the CertificateSignedRequest message is not a valid certificate</td><td>Yes</td></tr><tr><td>InvalidTLSVersion</td><td>The TLS version used by the CSMS is lower than 1.2 and is not allowed by the security specification</td><td>Yes</td></tr><tr><td>InvalidTLSCipherSuite</td><td>The CSMS did only allow connections using TLS cipher suites that are not allowed by the security specification</td><td>Yes</td></tr><tr><td>MaintenanceLoginAccepted</td><td>Successful login to the local maintenance interface. It is recommended to include information like the user identification and the origin of the login attempt, which can be an ip-address or a touch screen for example, to the techInfo field. For this the following format is strongly recommended: '\user':'\...',\origin':'\...'\}</td><td>Yes</td></tr><tr><td>MaintenanceLoginFailed</td><td>Failed login attempt to the local maintenance interface. It is recommended to include information like the user identification and the origin of the login attempt, which can be an ip-address or a touch screen for example, to the techInfo field. For this the following format is strongly recommended: '\user':'\...',\origin':'\...'\}</td><td>Yes</td></tr></table>
+
+# Appendix 2. Standardized Units of Measure
+
+The standardized values for Unit of Measure. Default value of "unit" is always "Wh".
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>A</td><td>Amperes (current)</td></tr><tr><td>ASU</td><td>Arbitrary Strength Unit (Signal Strength)</td></tr><tr><td>B</td><td>Bytes</td></tr><tr><td>Celsius</td><td>Degrees (temperature)</td></tr><tr><td>dB</td><td>Decibel (for example Signal Strength)</td></tr><tr><td>dBm</td><td>Power relative to 1mW (\( ^{10} \)log(P/1mW))</td></tr><tr><td>Deg</td><td>Degrees (angle/rotation)</td></tr><tr><td>Fahrenheit</td><td>Degrees (temperature)</td></tr><tr><td>Hz</td><td>Hertz (frequency)</td></tr><tr><td>K</td><td>Degrees Kelvin (temperature)</td></tr><tr><td>lx</td><td>Lux (Light Intensity)</td></tr><tr><td>m</td><td>Meter (length)</td></tr><tr><td>ms2</td><td>m/s2 (Acceleration)</td></tr><tr><td>N</td><td>Newtons (Force)</td></tr><tr><td>Ohm</td><td>Ohm (Impedance)</td></tr><tr><td>kPa</td><td>kiloPascal (Pressure)</td></tr><tr><td>Percent</td><td>Percentage</td></tr><tr><td>RH</td><td>Relative Humidity%</td></tr><tr><td>RPM</td><td>Revolutions per Minute</td></tr><tr><td>s</td><td>Seconds (Time)</td></tr><tr><td>V</td><td>Voltage (DC or r.m.s. AC)</td></tr><tr><td>VA</td><td>Volt-Ampere (apparent power)</td></tr><tr><td>kVA</td><td>kiloVolt-Ampere (apparent power)</td></tr><tr><td>VAh</td><td>Volt-Ampere-hours (apparent energy)</td></tr><tr><td>kVAh</td><td>kiloVolt-Ampere-hours (apparent energy)</td></tr><tr><td>var</td><td>vars (reactive power)</td></tr><tr><td>kvar</td><td>kilovars (reactive power)</td></tr><tr><td>varh</td><td>var-hours (reactive energy)</td></tr><tr><td>kvarh</td><td>kilovar-hours (reactive energy)</td></tr><tr><td>W</td><td>Watts (power)</td></tr><tr><td>kW</td><td>kilowatts (power)</td></tr><tr><td>Wh</td><td>Watt-hours (energy). Default</td></tr><tr><td>kWh</td><td>kilowatt-hours (energy)</td></tr></table>
+
+# Appendix 3. Standardized Components
+
+This appendix provides a list of all standardized component names for OCPP 2.0.1 for controller components and for physical components. A summary table listing just all components without variables is provided at the end of this appendix in Summary List of Standardized Components.
+
+# 3.1. Controller Components
+
+This is the list of Standardized Controller Components for OCPP 2.0.1. and typical Variables that might be associated with them.
+
+# IMPORTANT
+
+This list does not imply that these Components are required, nor does it imply that the listed Variables are required for a Component or no other Variables are allowed to be associated with a Component.
+
+# 3.1.1.AlignedDataCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the reporting of clock-aligned meter data.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>If this variable reports a value of true, Aligned Data is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>If this variable reports a value of true, Aligned Data is supported.</td></tr><tr><td>Interval</td><td>integer</td><td>Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the MeterValuesRequest message.</td></tr><tr><td>Measurands</td><td>MemberList</td><td>Clock-aligned measurand(s) to be included in MeterValuesRequest, every AlignedDataInterval seconds.</td></tr><tr><td>SendDuringIdle</td><td>boolean</td><td>If set to true, the Charging Station SHALL not send clock aligned meter values when a transaction is ongoing.</td></tr><tr><td>SignReadings</td><td>boolean</td><td>If set to true, the Charging Station SHALL include signed meter values in the TransactionEventRequest to the CSMS.</td></tr><tr><td>TxEndedInterval</td><td>integer</td><td>Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the TransactionEventRequest (eventType = Ended) message.</td></tr><tr><td>TxEndedMeasurands</td><td>MemberList</td><td>Clock-aligned periodic measurand(s) to be included in the meterValues element of TransactionEventRequest (eventType = Ended) for every TxEndedAlignedDataInterval of the transaction.</td></tr></table>
+
+# 3.1.2. AuthCtrl (Updated in v1.2)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the use of authorization for Charging Station use.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>If set to false, then no authorization is done before starting a transaction or when reading an idToken. If an idToken was provided, then it will be put in the idToken field of the TransactionRequest. If no idToken was provided, then idToken in TransactionRequest will be left empty and type is set to NoAuthorization.</td></tr><tr><td>AdditionalInfoItemsPerMessage</td><td>integer</td><td>Maximum number of AdditionalInfo items that can be sent in one message.</td></tr><tr><td>authorizeRemoteStart</td><td>boolean</td><td>Whether a remote request to start a transaction in the form of RequestStartTransactionRequest message should be authorized beforehand like a local action to start a transaction.</td></tr><tr><td>DisableRemoteAuthorization</td><td>boolean</td><td>When set to true this instructs the Charging Station to not issue any AuthorizationRequests, but only use Authorization Cache and Local Authorization List to determine validity of idTokens.</td></tr><tr><td>LocalAuthorizationOffline</td><td>boolean</td><td>Whether the Charging Station, when Offline, will start a transaction for locally-authorized identifiers.</td></tr><tr><td>LocalPreAuthorization</td><td>boolean</td><td>Whether the Charging Station, when online, will start a transaction for locally-authorized identifiers without waiting for or requesting an AuthorizationResponse from the CSMS.</td></tr><tr><td>MasterPassGroupId</td><td>string</td><td>IdTokens that have this id as groupId belong to the Master Pass Group.</td></tr><tr><td>OfflineTxForUnknownIdEnabled</td><td>boolean</td><td>If this key exists, the Charging Station supports Unknown Offline Authorization.</td></tr></table>
+
+# 3.1.3. AuthCacheCtrl (Updated in v1.2)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the use of a local cache for authorization for Charging Station use.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>If this variable exists, the Charging Station supports an Authorization Cache.</td></tr><tr><td>Available</td><td>boolean</td><td>If this variable reports a value of true, Authorization Cache is supported.</td></tr><tr><td>LifeTime</td><td>integer</td><td>Indicates in seconds how long it takes until a token expires in the authorization cache since it is last used.</td></tr><tr><td>Policy</td><td>OptionList</td><td>Cache Entry Replacement Policy: (LRU,LFU) LeastRecentlyUsed or LeastFrequentlyUsed. Allowed values: LRU, LFU.</td></tr><tr><td>DisablePostAuthorize</td><td>boolean</td><td>When set to true this variable disables the behavior to request authorization for an idToken that is stored in the cache with a status other than Accepted, as stated in C10.FR.03 and C12.FR.05.</td></tr></table>
+
+# 3.1.4. CHAdeMOCtrl (Updated in v1.2)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">A CHAdeMO Controller component communicates with an EV using the wired CANbus protocol to exchange information and control charging using the CHAdeMO protocol</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>CHAdeMO controller enabled</td></tr><tr><td>Active</td><td>boolean</td><td>Connected</td></tr><tr><td>Complete</td><td>boolean</td><td>Protocol session ended normally</td></tr><tr><td>Tripped</td><td>boolean</td><td>CHAdeMO protocol terminated abnormally</td></tr><tr><td>Problem</td><td>boolean</td><td>CHAdeMO controller fault</td></tr><tr><td>SelftestActive(Set)</td><td>boolean</td><td>Start self-test by setting to true</td></tr><tr><td>SelftestActive</td><td>boolean</td><td>Self-test running when reported as true</td></tr><tr><td colspan="3">Specific CHAdeMO interface data from vehicle:</td></tr><tr><td>CHAdeMOProtocolNumber</td><td>integer</td><td>CHAdeMO protocol number (H'102.0)</td></tr><tr><td>VehicleStatus</td><td>boolean</td><td>Vehicle status (H'102.5.3)</td></tr><tr><td>DynamicControl</td><td>boolean</td><td>Vehicle is compatible with dynamic control (H'110.0.0)</td></tr><tr><td>HighCurrentControl</td><td>boolean</td><td>Vehicle is compatible with high current control (H'110.0.1)</td></tr><tr><td>HighVoltageControl</td><td>boolean</td><td>Vehicle is compatible with high voltage control (H'110.1.2)</td></tr><tr><td>AutoManufacturerCode</td><td>integer</td><td>Auto manufacturer code (H'700.0)
+A single byte manufacturer code assigned by CHAdeMO association</td></tr></table>
+
+# 3.1.5. ClockCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Provides a means to configure management of time tracking by Charging Station.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>DateTime</td><td>dateTime</td><td>Contains the current date and time.</td></tr><tr><td>NtpServerUri</td><td>string</td><td>This contains the address of the NTP server. Multiple NTP servers can be configured as backups, etc. If the NTP client supports it, it can also connect to multiple NTP servers simultaneous to get a more reliable time source. Variable instance value is single digit NTP priority (1=highest).</td></tr><tr><td>NtpSource</td><td>string</td><td>When an NTP client is implemented, this variable can be used to configure the client: Use the NTP server provided via DHCP, or use the manually configured NTP server.</td></tr><tr><td>TimeOffset</td><td>string</td><td>Configured local time offset in the format: "+01:00", "-02:00" etc.</td></tr><tr><td>NextTimeOffsetTransitionDateTime</td><td>dateTime</td><td>Date time of the next time offset transition.</td></tr><tr><td>TimeSource</td><td>string</td><td>Via this variable, the Charging Station provides the CSMS with the option to configure a clock source, if more than 1 are implemented.</td></tr><tr><td>TimeZone</td><td>string</td><td>Configured current local time zone in the format: "Europe/Oslo", "Asia/Singapore" etc.</td></tr><tr><td>TimeAdjustmentReportingThreshold</td><td>integer</td><td>If set, then time adjustments with an absolute value in seconds larger than this need to be reported as a security event SettingSystemTime.</td></tr></table>
+
+# 3.1.6.CustomizationCtrlr (New in v1.2)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to custom vendor-specific implementations, using the DataTransfer message and CustomData extensions.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>CustomImplementationEnabled</td><td>boolean</td><td>This standard configuration variable can be used to enable/disable custom implementations that the Charging Station supports. The instance name of the variable matches the vendorId of the customization in CustomData or DataTransfer messages.</td></tr></table>
+
+# 3.1.7. DeviceDataCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the exchange and storage of Charging Station Device Model data.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>BytesPerMessage</td><td>integer</td><td>Message Size (in bytes) - maxLimit used to report constraint on message size. Which message is specified in the instance.</td></tr><tr><td>ItemsPerMessage</td><td>integer</td><td>Maximum number of entries that can be sent in one message. Which entries in which message is specified in the instance.</td></tr><tr><td>ValueSize</td><td>integer</td><td>Can be used to limit the following fields: SetVariableData(attributeValue, GetVariableResult(attributeValue, VariableAttribute.value, VariableCharacteristics.valueList and EventData的实际Value.</td></tr></table>
+
+# 3.1.8. DisplayMessageCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the display of messages to Charging Station users.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>Whether Display Message is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>Whether Display Message is supported.</td></tr><tr><td>DisplayMessages</td><td>integer</td><td>Amount of different messages that are currently configured in this Charging Station, via SetDisplayMessageRequest.</td></tr><tr><td>PersonalMessageSize</td><td>integer</td><td>Max size (in characters) of the personal message element of the IdTokenInfo data (0 specifies no personal data may be stored).</td></tr><tr><td>SupportedFormats</td><td>MemberList</td><td>List of message formats supported by this Charging Station. Possible values: See MessageFormatEnumType.</td></tr></table>
+
+# 3.1.9. ISO15118Ctrl (Updated in v1.3)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Communicates with an EV to exchange information and control charging using the ISO 15118 protocol.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>ISO15118 controller enabled</td></tr><tr><td>Active</td><td>boolean</td><td>Connected</td></tr><tr><td>Tripped</td><td>boolean</td><td>ISO15118 communication session aborted</td></tr><tr><td>Complete</td><td>boolean</td><td>ISO15118 communication session ended</td></tr><tr><td>Problem</td><td>boolean</td><td>ISO15118 controller fault</td></tr><tr><td>Seccd</td><td>string</td><td>The name of the SECC in the string format as required by ISO 15118.</td></tr><tr><td>SelftestActive(Set)</td><td>boolean</td><td>Start self-test by setting to true</td></tr><tr><td>SelftestActive</td><td>boolean</td><td>Self-test running when reported as true</td></tr><tr><td>ContractValidationOffline</td><td>boolean</td><td>Supports validation of a contract certificate when offline</td></tr><tr><td>CentralContractValidationAllow ed</td><td>boolean</td><td>Contract certificates can be validated by the CSMS</td></tr><tr><td>PnCEnabled</td><td>boolean</td><td>If this variable is true, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is enabled. If this variable is false, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is disabled.</td></tr><tr><td>V2GCertificatesInstallationEnabl ed</td><td>boolean</td><td>If this variable is true, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station is enabled. If this variable is false, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station is disabled.</td></tr><tr><td>ContractCertificatesInstallationE nabled</td><td>boolean</td><td>If this variable is true, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is enabled. If this variable is false, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is disabled.</td></tr><tr><td>RequestMeteringReceipt</td><td>boolean</td><td>If this variable is true, then Charging Station shall request a metering receipt from EV before sending a fiscal meter value to CSMS.</td></tr><tr><td>OrganizationName</td><td>string</td><td>The organizationName of the CSO operating the charging station. It is used as the organizationName (O) of the SECC leaf certificate. Example: "John Doe Charging Services Ltd" Note: This value will usually be identical to SecurityCtrlr.OrganizationName, but it does not have to be.</td></tr><tr><td>CountryName</td><td>string</td><td>The countryName of the SECC in the ISO 3166-1 format. It is used as the countryName (C) of the SECC leaf certificate. Example: "DE"</td></tr><tr><td colspan="3">Specific ISO15118 interface data from vehicle:</td></tr><tr><td>MaxScheduleEntries</td><td>integer</td><td>MaxEntriesSAScheduleType (15118-2) or MaximumSupportingPoints (15118-20) Number of allowed schedule periods</td></tr><tr><td>RequestedEnergyTransferMode</td><td>OptionList</td><td>RequestedEnergyTransferMode "AC_single_phase_core", "AC_three_phase_core", "DC_core", "DC_EXTENDED", "DC combo_core", "DC_unique"</td></tr></table>
+
+# 3.1.10. LocalAuthListCtrlr (Updated in v1.2)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the use of Local Authorization Lists for Charging Station use.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>Whether Local Authorization List is enabled.</td></tr><tr><td>Entries</td><td>integer</td><td>Amount of IdTokens currently in the Local Authorization List. The maxLimit of this variable SHALL be provided to report the maximum number of IdTokens that can be stored in the Local Authorization List.</td></tr><tr><td>Available</td><td>boolean</td><td>Whether Local Authorization List is supported.</td></tr><tr><td>ItemsPerMessage</td><td>integer</td><td>Maximum number of identifications that can be sent in a single SendLocalListRequest.</td></tr><tr><td>BytesPerMessage</td><td>integer</td><td>Message Size (in bytes) - puts a constraint on SendLocalListRequest message size.</td></tr><tr><td>Storage</td><td>integer</td><td>Indicates the number of bytes currently used by the Local Authorization List. MaxLimit indicates the maximum number of bytes that can be used by the Local Authorization List.</td></tr><tr><td>DisablePostAuthorize</td><td>boolean</td><td>When set to true this variable disables the behavior to request authorization for an idToken that is stored in the local authorization list with a status other than Accepted, as stated in C14.FR.03.</td></tr></table>
+
+# 3.1.11. MonitoringCtrl (Updated in v1.3)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the exchange of monitoring event data.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>Whether Monitoring is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>Whether Monitoring is supported.</td></tr><tr><td>ItemsPerMessage</td><td>integer</td><td>Maximum number of items.</td></tr><tr><td>BytesPerMessage</td><td>integer</td><td>Message Size (in bytes) - puts constraint on message size.</td></tr><tr><td>MonitoringBase</td><td>optionList</td><td>Currently used MonitoringBase. (readonly)</td></tr><tr><td>MonitoringLevel</td><td>integer</td><td>Currently use MonitoringLevel (readonly)</td></tr><tr><td>OfflineQueuingSeverity</td><td>integer</td><td>When set and the Charging Station is offline, the Charging Station shall queue any notifyEventRequest messages triggered by a monitor with a severity number equal to or lower than the severity configured here. Value ranging from 0 (Emergency) to 9 (Debug).</td></tr><tr><td>ActiveMonitoringBase</td><td>OptionList</td><td>Shows the currently used MonitoringBase. Valid values according MonitoringBaseEnumType: All, FactoryDefault, HardwiredOnly. (readonly)</td></tr><tr><td>ActiveMonitoringLevel</td><td>integer</td><td>Shows the currently used MonitoringLevel. Valid values are severity levels of SetMonitoringLevelRequest: 0-9. (readonly)</td></tr></table>
+
+# 3.1.12. OCPPCommCtrl (Updated in v1.4)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to information exchange between Charging Station and CSMS.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>ActiveNetworkProfile</td><td>integer</td><td>Indicates the configuration profile the station uses at that moment to connect to the network.</td></tr><tr><td>FileTransferProtocols</td><td>MemberList</td><td>List of supported file transfer protocols.</td></tr><tr><td>HeartbeatInterval</td><td>integer</td><td>Interval in seconds of inactivity (no OCPP exchanges) with CSMS after which the Charging Station should send HeartbeatRequest.</td></tr><tr><td>MessageAttempts</td><td>integer</td><td>How often the Charging Station should try to submit a TransactionEventRequest message when the CSMS fails to process it.</td></tr><tr><td>MessageAttemptInterval</td><td>integer</td><td>How long in seconds the Charging Station should wait before resubmitting a TransactionEventRequest message that the CSMS failed to process.</td></tr><tr><td>MessageTimeout</td><td>integer</td><td>Message timeout in seconds. The message timeout setting in a Charging Station can be configured in the messageTimeout field in the NetworkConnectionProfile.</td></tr><tr><td>MinimumStatusDuration</td><td>integer</td><td>Minimum duration that a Charging Station or EVSE status is stable before StatusNotificationRequest is sent to the CSMS.</td></tr><tr><td>NetworkConfigurationPriority</td><td>string</td><td>A comma separated ordered list of the priority of the possible Network Connection Profiles.</td></tr><tr><td>NetworkProfileConnectionAttempts</td><td>integer</td><td>Specifies the number of connection attempts the Charging Station executes before switching to a different profile.</td></tr><tr><td>OfflineThreshold</td><td>integer</td><td>When the offline period in seconds of a Charging Station exceeds the OfflineThreshold it is recommended to send a StatusNotificationRequest for all its Connectors when the Charging Station is back online.</td></tr><tr><td>PublicKeyWithSignedMeterValue</td><td>boolean</td><td>This Configuration Variable can be used to configure whether a public key needs to be sent with a signed meter value.</td></tr><tr><td>QueueAllMessages</td><td>boolean</td><td>When this variable is set to true, the Charging Station will queue all message until they are delivered to the CSMS.</td></tr><tr><td>RetryBackOffRepeatTimes</td><td>integer</td><td>When the Charging Station is reconnecting, after a connection loss, it will use this variable for the amount of times it will double the previous back-off time.</td></tr><tr><td>RetryBackOffRandomRange</td><td>integer</td><td>When the Charging Station is reconnecting, after a connection loss, it will use this variable as the maximum value for the random part of the back-off time.</td></tr><tr><td>RetryBackOffWaitMinimum</td><td>integer</td><td>When the Charging Station is reconnecting, after a connection loss, it will use this variable as the minimum back-off time, the first time it tries to reconnect.</td></tr><tr><td>UnlockOnEVSideDisconnect</td><td>boolean</td><td>When set to true, the Charging Station SHALL unlock the cable on the Charging Station side when the cable is unplugged at the EV. For an EVSE with only fixed cables, the mutability SHALL be ReadOnly and the actual value SHALL be false. For a charging station with fixed cables and sockets, the variable is only applicable to the sockets.</td></tr><tr><td>WebSocketPingInterval</td><td>integer</td><td>Number of seconds between pings.</td></tr><tr><td>FieldLength</td><td>integer</td><td>This variable is used to report the length of <field> in <message> when it is larger than the length that is defined in the standard OCPP message schema.</td></tr></table>
+
+# 3.1.13. ReservationCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to reservations.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>Whether Reservation is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>Whether Reservation is supported.</td></tr><tr><td>NonEvseSpecific</td><td>boolean</td><td>If this configuration variable is present and set to true: Charging Station supports Reservation without specifying an EVSE.</td></tr></table>
+
+# 3.1.14. SampleDataCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the reporting of sampled meter data.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>If this variable reports a value of true, Sampled Data is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>If this variable reports a value of true, Sampled Data is supported.</td></tr><tr><td>SignReadings</td><td>boolean</td><td>If set to true, the Charging Station includes signed meter values in the MeterValuesRequest to the CSMS.</td></tr><tr><td>TxEndedMeasurands</td><td>MemberList</td><td>Sampled measurands to be included in the meterValues element of TransactionEventRequest (eventType = Ended), every TxEndedSampleInterval seconds from the start of the transaction.</td></tr><tr><td>TxEndedInterval</td><td>integer</td><td>Interval in seconds between sampling of metering (or other) data, intended to be transmitted in the TransactionEventRequest (eventType = Ended) message.</td></tr><tr><td>TxStartedMeasurands</td><td>MemberList</td><td>Sampled measurand(s) to be taken at the start of any transaction to be included in the meterValues field of the first TransactionEventRequest message send at the start of a transaction (eventType = Started).</td></tr><tr><td>TxUpdatedMeasurands</td><td>MemberList</td><td>Sampled measurands to be included in the meterValues element of every TransactionEventRequest (eventType = Updated), every SampledDataTxUpdatedInterval seconds from the start of the transaction.</td></tr><tr><td>TxUpdatedInterval</td><td>integer</td><td>Interval in seconds between sampling of metering (or other) data, intended to be transmitted via TransactionEventRequest (eventType = Updated) messages.</td></tr><tr><td>RegisterValuesWithoutPhases</td><td>boolean</td><td>If this variable reports a value of true, then meter values of measurand Energy.Active.Import.Register will only report the total energy over all phases without reporting the individual phase values. If this variable is absent or false, then the value for each phase is reported, possibly also with a total value (depending on the meter).</td></tr></table>
+
+# 3.1.15. SecurityCtrl (Updated in v1.4)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to security of communications between Charging Station and CSMS.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>BasicAuthPassword</td><td>string</td><td>The basic authentication password that is used for HTTP Basic Authentication. The string is a passwordString (see Part 2: 2.1.4) consisting of minimum 16 and maximum 40 characters (alpha-numeric 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.</td></tr><tr><td>Identity</td><td>string</td><td>The Charging Station identity. The string is an identifierString string (see Part 2: 2.1.4), so it SHALL only contain characters that are allowed for identifierString. Maximum length was chosen to ensure compatibility with EVSE ID from [EMI3] "Part 2: business objects".</td></tr><tr><td>OrganizationName</td><td>string</td><td>This configuration variable is used to set the organization name of the CSO or an organization trusted by the CSO. It is used to set the O (organizationName) RDN in the subject field of the client certificate.</td></tr><tr><td>CertSigningWaitMinimum</td><td>integer</td><td>Seconds to wait before generating another CSR in case CSMS does not return a signed certificate.</td></tr><tr><td>CertSigningRepeatTimes</td><td>integer</td><td>Number of times to resend a SignCertificateRequest when CSMS does nor return a signed certificate.</td></tr></table>
+
+# 3.1.16. SmartChargingCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to smart charging.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>Whether Smart Charging is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>Whether Smart Charging is supported.</td></tr><tr><td>ACPhaseSwitchingSupported</td><td>boolean</td><td>If defined and true, this EVSE supports the selection of which phase to use for 1 phase AC charging.</td></tr><tr><td>ProfileStackLevel</td><td>integer</td><td>Maximum acceptable value for stackLevel in a ChargingProfile. Since the lowest stackLevel is 0, this means that if SmartChargingCtrl.ProfileStackLevel = 1, there can be at most 2 valid charging profiles per Charging Profile Purpose per EVSE.</td></tr><tr><td>RateUnit</td><td>MemberList</td><td>A list of supported quantities for use in a ChargingSchedule. Allowed values: 'A' and 'W'.</td></tr><tr><td>PeriodsPerSchedule</td><td>integer</td><td>Maximum number of periods that may be defined per ChargingSchedule.</td></tr><tr><td>ExternalControlSignalsEnabled</td><td>boolean</td><td>Indicates whether a Charging Station should respond to external control signals that influence charging.</td></tr><tr><td>NotifyChargingLimitWithSched ules</td><td>boolean</td><td>Indicates if the Charging Station should include the externally set charging limit/schedule in the message when it sends a NotifyChargingLimitRequest message. This might increase the data usage significantly, especially when an external system sends new profiles/limits with a short interval. Default is false when omitted.</td></tr><tr><td>Phases3to1</td><td>boolean</td><td>If defined and true, this Charging Station supports switching from 3 to 1 phase during a transaction.</td></tr><tr><td>Entries</td><td>integer</td><td>Amount of Charging profiles currently installed on the Charging Station. MaxLimit used to limit number of Charging profiles installed at any time.</td></tr><tr><td>LimitChangeSignificance</td><td>integer</td><td>If at the Charging Station side a change in the limit in a ChargingProfile is lower than this percentage, the Charging Station MAY skip sending a NotifyChargingLimitRequest or a TransactionEventRequest message to the CSMS. It is RECOMMENDED to set this key to a low value. See Smart Charging signals to a Charging Station from multiple actors.</td></tr></table>
+
+# 3.1.17. TariffCostCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to tariff and cost display.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>Whether Tariff/cost is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>Whether Tariff/cost is supported.</td></tr><tr><td>TariffFallbackMessage</td><td>string</td><td>Message (and/or tariff information) to be shown to an EV Driver when there is no driver specific tariff information available.</td></tr><tr><td>TotalCostFallbackMessage</td><td>string</td><td>Message to be shown to an EV Driver when the Charging Station cannot retrieve the cost for a transaction at the end of the transaction.</td></tr><tr><td>Currency</td><td>string</td><td>Currency used by this Charging Station in a ISO 4217 formatted currency code.</td></tr></table>
+
+# 3.1.18. TxCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to transaction characteristics and behaviour.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>EVConnectionTimeOut</td><td>integer</td><td>Interval in seconds from between "starting" of a transaction until incipient transaction is automatically canceled, due to failure of EV driver to (correctly) insert the charging cable connector(s) into the appropriate socket(s). The Charging Station SHALL go back to the original state, probably: 'Available'. "Starting" might be the swiping of the RFID, pressing a start button, a RequestStartTransactionRequest being received etc.</td></tr><tr><td>TxBeforeAcceptedEnabled</td><td>boolean</td><td>With this configuration variable the Charging Station can be configured to allow charging before having received a BootNotificationResponse with RegistrationStatus: Accepted. See: Transactions before being accepted by a CSMS.</td></tr><tr><td>TxStartPoint</td><td>MemberList</td><td>Defines when the Charging Station starts a new transaction: first transactioneventRequest: eventType = Started. When any event in the given list occurs, the Charging Station SHALL start a transaction The Charging Station SHALL only send the Started event once for every transaction. It is advised to put all events that should be part of a transaction in the list, in case the start event never occurs. Because the possible events don't always have to come in the same order it is possible to provide a list of events. Which ever comes first will then cause a transaction to be started. For example: EVConnected, Authorized would mean that a transaction is started when an EV is detected (Cable is connected), or when an EV Driver swipes his RFID card en the CSMS successfully authorizes the ID for charging.</td></tr><tr><td>TxStopPoint</td><td>MemberList</td><td>Defines when the Charging Station ends a transaction: last transactioneventRequest: eventType = Ended. When any event in the given list is no longer valid, the Charging Station SHALL end the transaction. The Charging Station SHALL only send the Ended event once for every transaction.</td></tr><tr><td>MaxEnergyOnInvalidId</td><td>integer</td><td>Maximum amount of energy in Wh delivered when an identifier is deauthorized by the CSMS after start of a transaction.</td></tr><tr><td>StopTxOnInvalidId</td><td>boolean</td><td>whether the Charging Station will stop an ongoing transaction when it receives a non- Accepted authorization status in TransactionEventResponse for this transaction.</td></tr><tr><td>StopTxOnEVSideDisconnect</td><td>boolean</td><td>When set to true, the Charging Station SHALL administratively stop the transaction when the cable is unplugged from the EV.</td></tr></table>
+
+# 3.2. Physical Components
+
+This is a non-exhaustive list of Standardized Physical Components that SHALL be used when mapping a real Charging Station to the Device Model (for monitoring purposes).
+
+When the physical component that is to be mapped, matches the description of one of the Standardized Components in this section, for interoperability reasons, the Standardized Component from this section SHALL be used, instead of adding a new (proprietary) component.
+
+The list of typically used variables that is given for each Component is also non-exhaustive and all variables are optional. See also Part 1, paragraph 4.5. If a description of a variable is empty, please refer to the description in Standardized Variables.
+
+# 3.2.1. AccessBarrier
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Allows physical access of vehicles to a charging site to be controlled.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Open</td></tr><tr><td>Problem</td><td></td></tr></table>
+
+# 3.2.2. AcDcConverter
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Provides a variable DC current source to force energy directly into an EV battery stack, under tight control of the EV's battery management system.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>(not commanded Out of Service)</td></tr><tr><td>Problem</td><td>some problem/fault exists</td></tr><tr><td>Tripped</td><td>A problem requiring intervention has occurred</td></tr><tr><td>Overload</td><td>Excessive current/power consumption</td></tr><tr><td>DCVoltage</td><td>measured DC voltage</td></tr><tr><td>DCCurrent</td><td>measured DC current</td></tr><tr><td>Power</td><td>measured power</td></tr><tr><td>Temperature</td><td>temperature of converter</td></tr><tr><td>FanSpeed</td><td>Speed of cooling fan(s)</td></tr></table>
+
+# 3.2.3. AcPhaseSelector
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Allows a specific AC phase to be selected (typically at EVSE tier) for single phase vehicle charging in order to lower overall (e.g. site) phase imbalance.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Changing</td></tr><tr><td>Problem</td><td></td></tr><tr><td>PhaseRotation</td><td></td></tr></table>
+
+# 3.2.4. Actuator
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A general purpose electro-mechanical output system, with optional completion tracking sensing. Each output should use a Variable instance key indicating the nature of the output.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Non-Default</td></tr><tr><td>Problem</td><td></td></tr><tr><td>State</td><td></td></tr></table>
+
+# 3.2.5. AirCoolingSystem
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Fans (or equivalent devices) used to provide cooling.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Cooling system enabled to run</td></tr><tr><td>Active</td><td>Cooling</td></tr><tr><td>Problem</td><td>fault: e.g. fan stalled/slow</td></tr><tr><td>FanSpeed</td><td>Speed of cooling fan(s)</td></tr></table>
+
+# 3.2.6. AreaVentilation
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Fans (or equivalent devices) used to ensure that EVs that require ventilation during charging</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Area ventilation enabled</td></tr><tr><td>Active</td><td>Ventilating</td></tr><tr><td>Problem</td><td>fault: e.g. fan stalled/slow</td></tr><tr><td>FanSpeed</td><td>Speed of cooling fan(s)</td></tr></table>
+
+# 3.2.7. BayOccupancySensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Sensor (optical, ground loop, ultrasonic, etc.) to detect whether the associated parking/charging bay is physically vacant, or is occupied by a vehicle or other obstruction</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Sensor is sensing for occupancy</td></tr><tr><td>Active</td><td>Occupied</td></tr><tr><td>Percent</td><td>percentage obstruction (for analogue sensors).</td></tr></table>
+
+# 3.2.8. BeaconLighting
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Beacon Lighting to help EV drivers to locate nearby charging places, and/or to determine charging availability state, usually by color variation.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Beacon Lighting operational</td></tr><tr><td>Enabled(Set)=0</td><td>Disable beacon lighting</td></tr><tr><td>Active</td><td>On</td></tr><tr><td>Problem</td><td>Beacon lighting fault</td></tr><tr><td>Percent</td><td>Lighting Level (% of maximum)</td></tr><tr><td>Percent(Set)=x%</td><td>Lighting Level (% of maximum)</td></tr><tr><td>Power</td><td>Lighting Wattage</td></tr><tr><td>Color</td><td>Displayed color/intensity</td></tr></table>
+
+# 3.2.9. CableBreakawaySensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A sensor that detects when a charging cable (captive or removable) has been forcibly pulled from the Charging Station.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Breakaway sensor operational</td></tr><tr><td>Active</td><td>Tripped</td></tr><tr><td>Tripped</td><td>Breakaway detected: manual check/fix required</td></tr></table>
+
+# 3.2.10. CaseAccessSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Reports when an access door/panel is open</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Access sensor is enabled to detect/report opening/closing of access door/panel</td></tr><tr><td>Enabled(Set)=0</td><td>Disable reporting of access</td></tr><tr><td>Active</td><td>Open</td></tr><tr><td>Tripped</td><td>An access door/panel that needs manual reset action has been activated</td></tr><tr><td>Problem</td><td>A fault exists in the Sensor mechanism itself</td></tr></table>
+
+# 3.2.11. ChargingStation
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">The entire Charging Station as a logical entity</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Available for use (not commanded Out of Service)</td></tr><tr><td>Problem</td><td>Some problem/fault exists</td></tr><tr><td>Tripped</td><td>A problem requiring local/manual intervention has occurred.</td></tr><tr><td>Overload</td><td>Excessive current/power consumption</td></tr><tr><td>SupplyPhases</td><td>Number of AC supply phases connected</td></tr><tr><td>SupplyPhases(MaxLimit)</td><td>Number of AC supply phases supported</td></tr><tr><td>PhaseRotation</td><td>AC wiring phase rotation</td></tr><tr><td>ACVoltage</td><td>Measured incoming AC voltage [per phase]</td></tr><tr><td>ACVoltage(MaxLimit)</td><td>Designed maximum operating AC voltage</td></tr><tr><td>ACCurrent</td><td>Measured total AC current [per phase]</td></tr><tr><td>Power</td><td>Measured/calculated total power being consumed, including standby/ancillary loads</td></tr><tr><td>Power(MaxLimit)</td><td>Designed total operating load power, including standby/ancillary loads</td></tr><tr><td>Voltagelmbalance</td><td>voltage imbalance in three phase supply</td></tr><tr><td>CurrentImbalance</td><td>current imbalance in three phase supply</td></tr><tr><td>VendorName</td><td>Charging Station vendor name (as reported in BootNotification)</td></tr><tr><td>Model</td><td>Charging Station model (as reported in BootNotification)</td></tr><tr><td>ECVariant</td><td>Engineering Change Variant</td></tr><tr><td>SerialNumber</td><td>Charging Station serial number</td></tr><tr><td>OperatingTimes</td><td>recurring operating times</td></tr><tr><td>ChargeProtocol</td><td>Charging Control Protocol applicable to the Charging Station</td></tr><tr><td>AvailabilityState</td><td>Indicates if the Charging Station is available or not (replaces the Charging Station Status values reported by the StatusNotification)</td></tr><tr><td>AllowNewSessionsPendingFirmware Update</td><td>Indicates whether new sessions can be started on EVSEs, while Charging Station is waiting for all EVSEs to become Available in order to start a pending firmware update.</td></tr></table>
+
+# 3.2.12. ChargingStatusIndicator
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">The Charging Status Indicator, provides visible feedback to the user about the connection and charging status of an EVSE/Connector. This is commonly in the form of multi-colored lighting.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>Lighted</td></tr><tr><td>Color</td><td>Displayed color</td></tr></table>
+
+# 3.2.13. ConnectedEV (updated in v1.3)
+
+<table><tr><td>Description</td></tr><tr><td>ConnectedEV is a component that represents a connected vehicle for which data is received via an ISO 15118 or CHAdeMO interface. The generic information that is received, is represented as variables of ConnectedEV. Any protocol-specific information is represented in variables of the ISO15118Ctrl or CHAdeMOCtrl component.</td></tr></table>
+
+<table><tr><td>Variable</td><td>Unit</td><td>ISO 15118-2 value</td><td>CHAdeMO value</td></tr><tr><td>Available</td><td>boolean</td><td colspan="2">Is true when an EV is connected</td></tr><tr><td colspan="4">Vehicle:</td></tr><tr><td>Vehiceld</td><td>string</td><td>EVCCID (from SessionSetupReq)Six bytes, represented as hexbinary encoded string, e.g. "010203040A0B"</td><td>Vehicle ID (H'710 + H'711 + H'712)Three times 8 bytes, represented as hexbinary encoded string, e.g."010203040A0B0C0D111213141A1B1C1D212223242A2B2C2D". A concatenation of H'710 + H'711 + H'712.</td></tr><tr><td>ProtocolAgreed</td><td>string</td><td>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"</td><td>Lowest of Chademo protocol number from EV (H'102.0) and charger (H'109.0)</td></tr><tr><td>ProtocolSupportedByEV</td><td>string</td><td>A string with the following comma-separated items:"<uri>,<major>,<minor>".This is information from the supportedAppProtocolReq message from ISO 15118.Variable has multiple instances, one for each priority.Example:"urn:iso:15118:2:2013:MsgDef,2,0"</td><td>Chademo protocol number (H'102.0)</td></tr><tr><td colspan="4">Voltage and current values:</td></tr><tr><td>ACCurrent.minSet</td><td>A</td><td>EVMinCurrent</td><td>-</td></tr><tr><td>ACCurrent.maxSet</td><td>A</td><td>EVMaxCurrent</td><td>-</td></tr><tr><td>ACVoltage.maxSet</td><td>V</td><td>EVMaxVoltage</td><td>-</td></tr><tr><td>DCCurrent.minSet</td><td>A</td><td>-</td><td>Minimum charge current (H'100.0)</td></tr><tr><td>DCCurrent.maxSet</td><td>A</td><td>EVMaximumCurrentLimit</td><td>-</td></tr><tr><td>DCCurrent.target</td><td>A</td><td>EVTargetCurrent</td><td>Charging current request (H'102.3)If HighCurrentControl is true, use the value from Charging current request (extended) (H'110.1,2).</td></tr><tr><td>DCVoltage.minSet</td><td>V</td><td>-</td><td>Minimum battery voltage (H'100.2,3)</td></tr><tr><td>DCVoltage.maxSet</td><td>V</td><td>EVMaximumVoltageLimit</td><td>Maximum battery voltage (H'100.4,5)</td></tr><tr><td>DCVoltage.target</td><td>V</td><td>EVTTargetVoltage</td><td>Target battery voltage (H'102.1,2)</td></tr><tr><td colspan="4">Power, energy and time values:</td></tr><tr><td>Power.maxSet</td><td>W</td><td>EVMaximumPowerLimit</td><td>-</td></tr><tr><td>EnergyCapacity</td><td>Wh</td><td>EVEnergyCapacity</td><td>Total capacity of traction battery * 100 (H'101.5,6)</td></tr><tr><td>EnergyImport.target</td><td>Wh</td><td>EVEnergyRequest (DC) EAmount (AC)</td><td>-</td></tr><tr><td>DepartureTime</td><td>dateTime</td><td>DepartureTime Provided as seconds since message receipt. Convert to absolute time.</td><td>-</td></tr><tr><td>RemainingTimeBulk</td><td>s</td><td>RemainingTimeToBulkSoC</td><td>-</td></tr><tr><td>RemainingTimeFull.maxSet</td><td>s</td><td>-</td><td>Maximum charging time * 60 (H'101.2)</td></tr><tr><td>RemainingTimeFullactual</td><td>s</td><td>RemainingTimeToFullSoc</td><td>Estimated charging time * 60 (H'101.3)</td></tr><tr><td>StateOfChargeBulk</td><td>%</td><td>BulkSoC</td><td>-</td></tr><tr><td>StateOfCharge.maxSet</td><td>%</td><td>FullSoC</td><td>Charged rate reference constant (H'100.6)</td></tr><tr><td>StateOfChargeactual</td><td>%</td><td>DC_EVStatus.EVRESSSOC</td><td>State of charge (H'102.6)</td></tr><tr><td>ChargingCompleteBulk</td><td>boolean</td><td>BulkChargingComplete</td><td>-</td></tr><tr><td>ChargingCompleteFull</td><td>boolean</td><td>ChargingComplete</td><td>-</td></tr><tr><td colspan="4">Status values:</td></tr><tr><td colspan="4">ChargingState with a memberlist consisting of the following values:</td></tr><tr><td colspan="2">* BatteryOvervoltage</td><td>-</td><td>Battery overvoltage (H'102.4.0)</td></tr><tr><td colspan="2">* BatteryUndervoltage</td><td>-</td><td>Battery undervoltage (H'102.4.1)</td></tr><tr><td colspan="2">* ChargingCurrentDeviation</td><td>FAILED_ChargingCurrentDifferential</td><td>Battery current deviation (H'102.4.2)</td></tr><tr><td colspan="2">* BatteryTemperature</td><td>FAILED_RESSTemperatureInhibit</td><td>High battery temperature (H'102.4.3)</td></tr><tr><td colspan="2">* VoltageDeviation</td><td>FAILED_ChargingVoltageOutOfRange</td><td>Battery voltage deviation (H'102.4.4)</td></tr><tr><td colspan="2">* ChargingSystemError</td><td>FAILEDEVRESSMalfunction</td><td>Charging system error (H'102.5.2)</td></tr><tr><td colspan="2">* VehicleShiftPosition</td><td>FAILED_EVShiftPosition</td><td>Vehicle shift position (H'102.5.1)</td></tr><tr><td colspan="2">* VehicleChargingEnabled</td><td>-</td><td>Vehicle charging enabled (H'102.5.0)</td></tr><tr><td colspan="2">* ChargingSystemIncompatibility</td><td>FAILED_ChargingSystemIncompatibility</td><td>-</td></tr><tr><td colspan="2">* ChargerConnectorLockFault</td><td>FAILED_ChargerConnectorLockFault</td><td>-</td></tr></table>
+
+# 3.2.14. Connector
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A means to connect an EV to a Charging Station with either a socket, an attached cable & inline connector, or any wireless power transfer device.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Connector available for use (not commanded Out of Service)</td></tr><tr><td>Problem</td><td>problem/fault exists (e.g. over-temperature)</td></tr><tr><td>Tripped</td><td>A problem requiring intervention has occurred.</td></tr><tr><td>ConnectorType</td><td>Type of connector as defined by ConnectorEnumType in "Part 2 - Specification" plus additionally: cGBT, cChaoJi, OppCharge.</td></tr><tr><td>SupplyPhases</td><td>AC phases connected</td></tr><tr><td>SupplyPhases(MaxLimit)</td><td>AC phases Max</td></tr><tr><td>PhaseRotation</td><td>AC wiring phase rotation</td></tr><tr><td>ChargeProtocol</td><td>Charging Control Protocol applicable to the Connector</td></tr><tr><td>AvailabilityState</td><td>Indicates if the Connector is available or not (replaces the Status values reported by the StatusNotification)</td></tr></table>
+
+# 3.2.15. ConnectorHolsterRelease
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A mechanism present in a connector holster to prevent the connector from being removed inappropriately: typically unlocks connector after authorization.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Unlocked for removal/return</td></tr><tr><td>Problem</td><td></td></tr><tr><td>State</td><td></td></tr></table>
+
+# 3.2.16. ConnectorHolsterSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A mechanism to report when a tethered cable connector has been removed from its normal stowage position. May be used for detection of connectors left un-holstered, and possible penalty billing.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Un-Holstered</td></tr><tr><td>Problem</td><td></td></tr></table>
+
+# 3.2.17. ConnectorPlugRetentionLock
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Locking mechanism to retain an inserted plug, both to prevent on-load disconnection, and to prevent theft of charging cables</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Retention mechanism enabled</td></tr><tr><td>Active</td><td>Locked</td></tr><tr><td>Problem</td><td>Locking Failed</td></tr><tr><td>Tripped</td><td>Stall protection fuse blown, etc.</td></tr><tr><td>Tries</td><td>(Re)tries taken on last attempt</td></tr><tr><td>Tries(SetLimit)</td><td>Configured auto retry count</td></tr><tr><td>Tries(MaxLimit)</td><td>Maximum auto retry count</td></tr></table>
+
+# 3.2.18. ConnectorProtectionRelease
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">External protective mechanism (e.g. an external shutter or a connector holster lock mechanism) to prevent contact with conductors that may become "live" under other failure modes</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Protection in effect (locked except when in use)</td></tr><tr><td>Active</td><td>Unlocked</td></tr><tr><td>Problem</td><td>Lock/Unlock mechanism fault</td></tr><tr><td>Tripped</td><td>protective mechanism triggered (fuse)</td></tr></table>
+
+# 3.2.19. Controller
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">An embedded logic controller</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>Running</td></tr><tr><td>Problem</td><td>Controller fault</td></tr><tr><td>Interval[Heartbeat]</td><td>Heartbeat interval</td></tr><tr><td>Manufacturer</td><td>Controller manufacturer name</td></tr><tr><td>Model</td><td>Controller model number</td></tr><tr><td>ECVariant</td><td>Engineering Change variant</td></tr><tr><td>SerialNumber</td><td>Controller hardware serial number</td></tr><tr><td>VersionNumber</td><td>Hardware version number</td></tr><tr><td>VersionDate</td><td>Hardware version date</td></tr><tr><td>FirmwareVersion</td><td>Firmware version number (as reported in BootNotification)</td></tr><tr><td>MaxMsgElements</td><td>Array of implementation-defined limits to the number of elements of specific type that the Charging Station can accept in one message.</td></tr><tr><td>SelftestActive(Set)</td><td>Start self-test</td></tr><tr><td>SelftestActive</td><td>Self-test running</td></tr></table>
+
+# 3.2.20. ControlMetering
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Energy, Power, Electricity meter, used to measure energy, current, voltages etc.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Power</td><td>Measured power</td></tr><tr><td>ACCurrent</td><td>Measured AC current [per phase]</td></tr><tr><td>DCCurrent</td><td>Measured DC current</td></tr><tr><td>DCVoltage</td><td>Measured DC voltage</td></tr></table>
+
+# 3.2.21. CPPWMController
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Control Pilot PWM Controller: provides and senses the IEC 61851-1 / SAE J1772 low voltage DC and PWM signalling between an EVSE and EV over a control pilot line.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Connected</td></tr><tr><td>Problem</td><td>CP PWM controller fault</td></tr><tr><td>DCVoltage</td><td>Control Pilot wire DC Voltage (0-12V)</td></tr><tr><td>State</td><td>IEC 61851-1 states ("A" to "E")</td></tr><tr><td>Percentage</td><td>1kHz Duty Cycle</td></tr><tr><td>SelftestActive(Set)</td><td>Start self-test</td></tr><tr><td>SelftestActive</td><td>Self-test running</td></tr></table>
+
+# 3.2.22. DataLink
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Provides a communications link from a Charging Station to a CSMS. It may use fixed infrastructure, mobile telephony data services, WiFi, or other connectivity channels.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Data link enabled</td></tr><tr><td>Active</td><td>Connected</td></tr><tr><td>Fallback</td><td>Using Backup SIM/Network Preference</td></tr><tr><td>Complete</td><td>Link connection terminated</td></tr><tr><td>Problem</td><td>Communications module or link connection fault</td></tr><tr><td>IMSI</td><td>International Mobile Subscriber Identity number of mobile data SIM card</td></tr><tr><td>ICCID</td><td>Integrated Circuit Card IDentifier of mobile data SIM card.</td></tr><tr><td>NetworkAddress</td><td>Current network address</td></tr><tr><td>SignalStrength</td><td>Data signal strength/quality</td></tr></table>
+
+# 3.2.23. Display
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Provides information and feedback to the user.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Display configured to show information</td></tr><tr><td>Problem</td><td>Display fault</td></tr><tr><td>Color</td><td>Display color (monochrome/backlighting)</td></tr><tr><td>Count[HeightInChars]</td><td>Display height (characters)</td></tr><tr><td>Count[WidthInChars]</td><td>Display width (characters)</td></tr><tr><td>DataText[Visible]</td><td>Current Display Contents</td></tr><tr><td>State</td><td>Alphanumeric code indicating current message purpose</td></tr></table>
+
+# 3.2.24. DistributionPanel
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Defines the Distribution Panel, with it's fuses and connections to both Charging Stations and other Distribution Panel's.</td></tr><tr><td>Common Variables</td><td>Description</td></tr><tr><td>InstanceName</td><td>Name of the distribution box</td></tr><tr><td>Fuse</td><td>Fuse (index n) is the fuse for phase Ln in Ampere.</td></tr><tr><td>ChargingStation</td><td>The Identity of Charging Station (index n) which is connected to this DistributionPanel.
+Note: this is an indexed list of Charging Station Identities, not to be confused by the Charging Station component.</td></tr><tr><td>ChargingStation</td><td>List of Charging Stations Identities connected to this LocalController. (not to be confused with the ChargingStation Component)</td></tr><tr><td>DistributionPanel</td><td>List of Distribution Panels InstanceNames connected to this LocalController. (not to be confused with the DistributionPanel Component)
+See the LocalController component for an example.</td></tr></table>
+
+# 3.2.25. ElectricalFeed
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Represents an incoming electrical connection to a Charging Station, that may be a grid/distribution network connection, of a connection to local power generation and/or storage. Each electrical feed can record the electrical and other characteristics of that feed, including power rating, fusing, upstream metering, etc. When a Charging Station has more than one electrical feed, it must represent which feed supplies each EVSE, and which feed supplies the house load of the Charging Station itself. Simple Charging Stations with only a single electrical feed may omit all electrical feed information, in which case it is inferred that all power is supplied from a single feed, and what would otherwise be ElectricalFeed data (Variables) may be reported as being associated with the ChargingStation component.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Connected</td></tr><tr><td>Problem</td><td></td></tr><tr><td>PowerType</td><td></td></tr><tr><td>Power</td><td></td></tr><tr><td>Energy</td><td></td></tr><tr><td>DCVoltage</td><td></td></tr><tr><td>SupplyPhases</td><td></td></tr><tr><td>PhaseRotation</td><td></td></tr><tr><td>ACVoltage</td><td></td></tr></table>
+
+# 3.2.26. ELVSupply
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Represents the low voltage power supply (typically 12V DC and often other ELV voltages) that provides operating power for controllers, relays, and other electrical components.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>EnergyImportRegister</td><td>Standby/house energy meter register reading</td></tr><tr><td>Power</td><td>instantaneous standby power consumption</td></tr><tr><td>Power(MaxLimit)</td><td>Design maximum standby power consumption</td></tr><tr><td>Fallback</td><td>Running on backup energy;</td></tr><tr><td>Fallback(MaxLimit): =1</td><td>has backup</td></tr><tr><td>StateOfCharge</td><td>backup battery SOC</td></tr><tr><td>Time</td><td>(estimated) operating time on backup energy</td></tr></table>
+
+# 3.2.27. EmergencyStopSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">An "Emergency Stop" button that should be pressed by the user or other nearby persons if serious faulty behavior is observed (e.g. smoke/flames from EV or Charging Station).</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Emergency Stop action armed</td></tr><tr><td>Active</td><td>Pressed/Latched</td></tr><tr><td>Tripped</td><td>Needs manual reset</td></tr></table>
+
+# 3.2.28. EnvironmentalLighting
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Provides reporting/control of general illumination lighting in use at Charging Station.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Environmental Lighting operational</td></tr><tr><td>Enabled(Set)=0</td><td>Disable Environmental lighting</td></tr><tr><td>Active</td><td>On</td></tr><tr><td>Problem</td><td>Environmental lighting fault</td></tr><tr><td>Percent</td><td>Lighting Level (% of maximum)</td></tr><tr><td>Percent(Set)=x%</td><td>Lighting Level (% of maximum)</td></tr><tr><td>Power</td><td>Lighting Wattage</td></tr><tr><td>Color</td><td>Displayed color/intensity</td></tr></table>
+
+# 3.2.29. EVRetentionLock
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A locking mechanism on the EV side as a safety measure to prevent it being disconnected while high currents are flowing.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Retention locking detection in effect</td></tr><tr><td>Active</td><td>Locked to EV</td></tr><tr><td>Complete</td><td>Has unlocked</td></tr><tr><td>Problem</td><td>Lock Problem (e.g. failed to lock/unlock)</td></tr></table>
+
+# 3.2.30. EVSE
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">The entire chain of components responsible for transporting energy from the incoming supply to the electric vehicle (or vice versa)</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Ready for use (not commanded Out of Service)</td></tr><tr><td>Problem</td><td>some problem/fault exists</td></tr><tr><td>Tripped</td><td>A problem requiring intervention has occurred</td></tr><tr><td>Overload</td><td>Excessive current/power consumption</td></tr><tr><td>SupplyPhases</td><td>AC phases connected</td></tr><tr><td>PhaseRotation</td><td>AC wiring phase rotation</td></tr><tr><td>AllowReset</td><td>When true: EVSE can be reset individually</td></tr><tr><td>ACVoltage</td><td>Measured total AC voltage [per phase]</td></tr><tr><td>ACCurrent</td><td>Measured total AC current [per phase]</td></tr><tr><td>DCVoltage</td><td>Measured total DC voltage [per phase]</td></tr><tr><td>DCCurrent</td><td>Measured total DC current [per phase]</td></tr><tr><td>Power</td><td>Measured Power</td></tr><tr><td>VoltageImbalance</td><td>voltage imbalance in three phase supply</td></tr><tr><td>CurrentImbalance</td><td>current imbalance in three phase supply</td></tr><tr><td>ChargeProtocol</td><td>Charging Control Protocol applicable to the EVSE</td></tr><tr><td>ChargingTime</td><td>Total time duration that EV is taking energy from an EVSE. Short pauses in charging (e.g. battery pre-, post-conditioning) are included</td></tr><tr><td>PostChargingTime</td><td>Total time since EV has taken energy from EVSE</td></tr><tr><td>Count[ChargingProfiles]</td><td>Charging Profiles present</td></tr><tr><td>Count[ChargingProfiles](MaxLimit)</td><td>Maximum Charging Profiles supported</td></tr><tr><td>ISO15118Evseld</td><td>The name of the EVSE in the string format as required by ISO 15118 and IEC 63119-2. Example: "DE*ICE*E*1234567890*1"</td></tr></table>
+
+# 3.2.31. ExternalTemperatureSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Reports ambient air temperature</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>Temperature above MaxSet or MinSet</td></tr><tr><td>Problem</td><td>Temperature sensor fault</td></tr><tr><td>Temperature</td><td>Ambient temperature</td></tr></table>
+
+# 3.2.32. FiscalMetering
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Provides energy transfer readings that are the basis for billing.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Problem</td><td>Metering Fault (e.g. read error)</td></tr><tr><td>EnergyImport</td><td>Energy transferred to EV during session</td></tr><tr><td>EnergyImportRegister</td><td>Cumulative import reading</td></tr><tr><td>EnergyExport</td><td>Energy transferred from EV during session</td></tr><tr><td>EnergyExportRegister</td><td>Cumulative export reading</td></tr><tr><td>Manufacturer[Meter]</td><td>Meter manufacturer name</td></tr><tr><td>Manufacturer[CT]</td><td>Current transformer manufacturer name</td></tr><tr><td>Model[Meter]</td><td>Meter model number</td></tr><tr><td>Model[CT]</td><td>CT model number</td></tr><tr><td>ECVariant</td><td>Meter engineering change variant</td></tr><tr><td>SerialNumber[Meter]</td><td>Meter serial number</td></tr><tr><td>SerialNumber[CT]</td><td>CT serial number(s)</td></tr><tr><td>Certificate</td><td></td></tr><tr><td>OptionsSet [MeterValueAlignedData]</td><td>Set of measurands to read and report at clock-aligned time intervals while charging.</td></tr><tr><td>OptionsSet[TxnStoppedAlignedData]</td><td>Set of measurands to be read at clock-aligned time intervals while charging and reported in TransactionStopped</td></tr></table>
+
+# 3.2.33. FloodSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A sensor reporting whether the Charging Station is experiencing water ingress/pooling.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Water presence/level sensing in effect</td></tr><tr><td>Active</td><td>Flooding</td></tr><tr><td>Tripped</td><td>Water level safety sensor tripped</td></tr><tr><td>Height</td><td>Absolute water height above reference (ground) level.</td></tr><tr><td>Percent</td><td>Height as percentage between reference minimum (0%) and maximum allowable (100%). Values below 0% and above 100% are possible.</td></tr></table>
+
+# 3.2.34. GroundIsolationProtection
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">An Isolation Tester as part of their own self-test mechanisms, to confirm the isolation of floating circuitry when no Evs are connected</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Electrical isolation testing enabled</td></tr><tr><td>Active</td><td>Leakage</td></tr><tr><td>Complete</td><td>Isolation test completed</td></tr><tr><td>Problem</td><td>Isolation fault</td></tr><tr><td>Impedance</td><td>Isolation resistance/impedance</td></tr></table>
+
+# 3.2.35. Heater
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Heater to ensure reliable operation in cold environments</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Heater hardware operation enabled</td></tr><tr><td>Active</td><td>Heating</td></tr><tr><td>Problem</td><td>Heater fault</td></tr><tr><td>Tripped</td><td>Heater equipment permanent fault</td></tr><tr><td>Power</td><td>Instantaneous heater power level</td></tr><tr><td>Power(MaxLimit)</td><td>Maximum heater power</td></tr><tr><td>Power(MaxSet)</td><td>Configured heater power</td></tr><tr><td>Temperature(MinSet)</td><td>Cut-in temperature</td></tr><tr><td>Temperature(MaxSet)</td><td>Cut-out temperature</td></tr></table>
+
+# 3.2.36. HumiditySensor
+
+3.2.37. LightSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Reports relative air humidity</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Problem</td><td>Humidity sensor fault</td></tr><tr><td>Humidity</td><td>RH(%)</td></tr></table>
+
+3.2.38. LiquidCoolingSystem
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Reports ambient light levels.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Problem</td><td>Lighting sensor fault</td></tr><tr><td>Light</td><td>The ambient light level</td></tr></table>
+
+3.2.39. LocalAvailabilitySensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A liquid based cooling system, typically used to cool the connector cables of very high power Charging Stations.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Cooling system enabled to run</td></tr><tr><td>Active</td><td>Liquid circulating</td></tr><tr><td>Problem</td><td></td></tr><tr><td>Temperature</td><td></td></tr></table>
+
+3.2.40. LocalController
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Accepts local signal inputs controlling whether new Charging Sessions can start and/or whether ongoing sessions should continue. Typically connected to a site/building power supply, to automatically report unavailability when closed.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Local Availability input sensing in operation</td></tr><tr><td>Active</td><td>Out of Service</td></tr><tr><td>Problem</td><td>Local Availability sensing circuit error</td></tr></table>
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">The entire Local Controller as a logical entity</td></tr><tr><td>Common Variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Available for use (not commanded Out of Service)</td></tr><tr><td>Problem</td><td>Some problem/fault exists</td></tr><tr><td>Identity</td><td>Local Controller identity</td></tr><tr><td>Tripped</td><td>A problem requiring local/manual intervention has occurred.</td></tr><tr><td>Manufacturer</td><td>Local Controller manufacturer name</td></tr><tr><td>Model</td><td>Local Controller manufacturer model</td></tr><tr><td>ECVariant</td><td>Engineering Change Variant</td></tr><tr><td>SerialNumber</td><td>Local Controller serial number</td></tr><tr><td>ChargingStation</td><td>List of Charging Stations Identities connected to this LocalController. (not to be confused with the ChargingStation Component)</td></tr><tr><td>DistributionPanel</td><td>List of Distribution Panels InstanceNames connected to this LocalController. (not to be confused with the DistributionPanel Component)This can be used to describes the electrical connections in the site controlled by the Local Controller.An example. The incoming fuses are all 120A. Each floor has a set of 80A fuses. On the first floor, there's also a group of Charging Stations that are behind a set of 32A fuses.DistributionPanel.Fuse[1] = 120DistributionPanel.Fuse[2] = 120DistributionPanel.Fuse[3] = 120DistributionPanel.DistributionPanel[0] = "Level-1"DistributionPanel.DistributionPanel[1] = "Level-2"DistributionPanel["Level-1"].Fuse[1] = 80DistributionPanel["Level-1"].Fuse[2] = 80DistributionPanel["Level-1"].Fuse[3] = 80DistributionPanel["Level-1"].ChargingStation[0] = "NLCP013"DistributionPanel["Level-1"].ChargingStation[1] = "NLCP014"DistributionPanel["Level-1"].ChargingStation[2] = "NLCP015"DistributionPanel["Level-1"].DistributionPanel[0] = "Level-1a"DistributionPanel["Level-1a"].Fuse[1] = 32DistributionPanel["Level-1a"].Fuse[2] = 32DistributionPanel["Level-1a"].Fuse[3] = 32DistributionPanel["Level-1a"].ChargingStation[0] = "NLCP130"DistributionPanel["Level-1a"].ChargingStation[1] = "NLCP136"DistributionPanel["Level-1a"].ChargingStation[2] = "NLCP132"DistributionPanel["Level-2"].Fuse[1] = 80DistributionPanel["Level-2"].Fuse[2] = 80DistributionPanel["Level-2"].Fuse[3] = 80DistributionPanel["Level-2"].ChargingStation[0] = "NLCP023"DistributionPanel["Level-2"].ChargingStation[1] = "NLCP024"</td></tr></table>
+
+# 3.2.41. LocalEnergyStorage (updated in v1.3)
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Local energy storage device</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>EnergyCapacity</td><td>Maximum storage capacity</td></tr><tr><td>Identity</td><td>Local Energy Storage identity</td></tr></table>
+
+# 3.2.42. OverCurrentProtection
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Protects equipment by disconnecting the electrical supply when the current drawn (on any phase) exceeds the rated value to a substantial degree.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>Tripped. Trip when over MaxSet/MaxLimit.</td></tr><tr><td>Operated</td><td>Breaker opened and auto-reclosed</td></tr><tr><td>ACCurrent</td><td>Measured total AC current [per phase]</td></tr></table>
+
+# 3.2.43. OverCurrentProtectionRecloser
+
+<table><tr><td>Description</td></tr><tr><td>Recloser mechanism of an OverCurrentProtection to perform re-arm retries after a trip, or may be set for remotely controlled re-arming on command.</td></tr><tr><td colspan="2">Description</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Auto reclosing enabled</td></tr><tr><td>Active</td><td>Reclosing</td></tr><tr><td>Active(Set)</td><td>Initiate manual reclose</td></tr><tr><td>Complete</td><td>Reclose cycle completed</td></tr><tr><td>Problem</td><td>Recloser Fault</td></tr><tr><td>Mode</td><td>Reclose Mode (None, Auto, Commanded)</td></tr><tr><td>Tries</td><td>(Re)tries taken on last attempt</td></tr><tr><td>Tries(SetLimit)</td><td>Configured auto retry count</td></tr><tr><td>Tries(MaxLimit)</td><td>Maximum auto retry count</td></tr></table>
+
+# 3.2.44. PowerContactor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Switches on and off the power to the EV after all authorization and safety requirements have been met. May have secondary contacts to report closure state.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>Closed</td></tr><tr><td>Tripped</td><td>Mirror contact protection tripped</td></tr><tr><td>Problem</td><td>Close/Open failed</td></tr></table>
+
+# 3.2.45.RCD
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A Residual Current Device (US: ground fault breaker) protects human life and/or downstream equipment by quickly detecting abnormal current flows (usually indicative in earth faults) in the Charging Station, cable, or EV during charging.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Tripped</td><td>Breaker opened (manual reset required)</td></tr><tr><td>Operated</td><td>Breaker opened and auto-reclosed</td></tr></table>
+
+# 3.2.46. RCDRecloser
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A motorized recloser mechanism of an RCD that may be configured to perform re-arm retries after a trip, or may be set for remotely controlled re-arming on command.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Auto reclosing enabled</td></tr><tr><td>Active</td><td>Reclosing in progress</td></tr><tr><td>Active(Set)</td><td>Initiate manual reclose</td></tr><tr><td>Complete</td><td>Reclose cycle completed</td></tr><tr><td>Problem</td><td>Recloser Fault</td></tr><tr><td>Tries</td><td>(Re)tries taken on last attempt</td></tr><tr><td>Tries(SetLimit)</td><td>Configured auto (re)try count</td></tr><tr><td>Tries(MaxLimit)</td><td>Maximum auto (re)try count</td></tr></table>
+
+# 3.2.47. RealTimeClock
+
+<table><tr><td>Description</td></tr><tr><td>Represents realtime clock hardware that can maintain accurate date & time information in a Charging Station, even in the case of simultaneous CSMS uncontactability and power outages or resets.</td></tr><tr><td colspan="2">Description</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>RTC running OK</td></tr><tr><td>DCVoltage</td><td>Battery voltage</td></tr><tr><td>Fallback</td><td>Battery failing</td></tr><tr><td>Fallback(MaxLimit)</td><td>RTC has backup-power. MaxLimit = 1</td></tr><tr><td>Problem</td><td>RTC fault</td></tr></table>
+
+# 3.2.48. ShockSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Measures impact forces/accelerations experienced, indicative of possible damage.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Shock sensing enabled</td></tr><tr><td>Active</td><td>Shock</td></tr><tr><td>Force</td><td>detected force (vector)</td></tr></table>
+
+# 3.2.49. SpacesCountSignage
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Electronic signage allowing a charging controller for a large charging facility to advertise counts of available spaces to passing traffic.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Spaces count signage enabled</td></tr><tr><td>Active</td><td>Not Blank</td></tr><tr><td>Count</td><td></td></tr></table>
+
+# 3.2.50. Switch
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A general purpose electromechanical input device, with optional remote defaulting/resetting of values. Each input should use a Variable instance key indicating the nature of the input.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Non-Default</td></tr><tr><td>State</td><td></td></tr></table>
+
+# 3.2.51. TemperatureSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Temperature sensor at a point inside the Charging Station; multiple sensing points for a single sensing controller. Multiple sensing points for a single sensing controller may be reported using distinct Variable instance keys.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>High temperature (over MaxSet)</td></tr><tr><td>Problem</td><td>Internal temperature sensor fault</td></tr><tr><td>Temperature</td><td>Enclosure temperature</td></tr></table>
+
+# 3.2.52. TiltSensor
+
+<table><tr><td>Description</td></tr><tr><td>Measures Tilt angle from normal reference position (normally 90 degree vertical).</td></tr><tr><td colspan="2">Description</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Tilt sensing enabled</td></tr><tr><td>Active</td><td>Tilted</td></tr><tr><td>Angle</td><td>Measured tilt (vector) from vertical</td></tr></table>
+
+# 3.2.53. TokenReader
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">An authorization token reader (e.g. RFID)</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Token reader enabled</td></tr><tr><td>Enabled(Set)=0</td><td>Token reader disabled: allow charging without token authentication/authorization</td></tr><tr><td>Operated</td><td>token data read event</td></tr><tr><td>Problem</td><td>token reader fault</td></tr><tr><td>Token</td><td>String read by TokenReader</td></tr><tr><td>TokenType</td><td>Type of token as IdTokenEnumType</td></tr></table>
+
+# 3.2.54.UpstreamProtectionTrigger
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Circuitry designed to trigger the disconnection of power to the structure by an upstream protection device after a severe problem has been detected</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Upstream protection enabled</td></tr><tr><td>Active(Set)</td><td>Force triggering of upstream protection</td></tr><tr><td>Tripped</td><td>Upstream protection triggered</td></tr><tr><td>Problem</td><td>Upstream protection fault</td></tr></table>
+
+# 3.2.55. Ullnput
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A logical input mechanism (e.g. set of buttons) that is part of a UI whose use may be communicated to the CSMS (in near real time). May support momentary inputs ("Operated") or modal state ("Active"). Multiple input sources should use explicit Variable instance keys (where the input function is key name).</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>UI input enabled</td></tr><tr><td>Operated</td><td></td></tr><tr><td>Active</td><td></td></tr></table>
+
+# 3.2.56. VehicleIdSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Reports an identifier associated with a vehicle occupying a charging bay. The identifier may be a vehicle registration number via ANPR hardware, a VIN, or other local identifier of the vehicle based on medium range/active RFID, or any other relevant technology and result.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>VehicleIdSensor enabled</td></tr><tr><td>Active</td><td>Processing</td></tr></table>
+
+# 3.3. Summary List of Standardized Components
+
+Following is a list that sums up all above-mentioned standardized component names.
+
+<table><tr><td>Component</td><td>Description</td></tr><tr><td>AlignedDataCtrlr</td><td>Logical Component responsible for configuration relating to the reporting of clock-aligned meter data.</td></tr><tr><td>AuthCtrlr</td><td>Logical Component responsible for configuration relating to the use of authorization for Charging Station use.</td></tr><tr><td>AuthCacheCtrlr</td><td>Logical Component responsible for configuration relating to the use of a local cache for authorization for Charging Station use.</td></tr><tr><td>CHAdeMOCtrlr</td><td>A CHAdeMO Controller component communicates with an EV using the wired CANbus protocol to exchange information and control charging using the CHAdeMO protocol</td></tr><tr><td>ClockCtrlr</td><td>Provides a means to configure management of time tracking by Charging Station.</td></tr><tr><td>DeviceDataCtrlr</td><td>Logical Component responsible for configuration relating to the exchange and storage of Charging Station Device Model data.</td></tr><tr><td>DisplayMessageCtrlr</td><td>Logical Component responsible for configuration relating to the display of messages to Charging Station users.</td></tr><tr><td>ISO15118Ctrlr</td><td>Communicates with an EV to exchange information and control charging using the ISO 15118 protocol.</td></tr><tr><td>LocalAuthListCtrlr</td><td>Logical Component responsible for configuration relating to the use of Local Authorization Lists for Charging Station use.</td></tr><tr><td>MonitoringCtrlr</td><td>Logical Component responsible for configuration relating to the exchange of monitoring event data.</td></tr><tr><td>OCPPCommCtrlr</td><td>Logical Component responsible for configuration relating to information exchange between Charging Station and CSMS.</td></tr><tr><td>ReservationCtrlr</td><td>Logical Component responsible for configuration relating to reservations.</td></tr><tr><td>SampledDataCtrlr</td><td>Logical Component responsible for configuration relating to the reporting of sampled meter data.</td></tr><tr><td>SecurityCtrlr</td><td>Logical Component responsible for configuration relating to security of communications between Charging Station and CSMS.</td></tr><tr><td>SmartChargingCtrlr</td><td>Logical Component responsible for configuration relating to smart charging.</td></tr><tr><td>TariffCostCtrlr</td><td>Logical Component responsible for configuration relating to tariff and cost display.</td></tr><tr><td>TxCtrlr</td><td>Logical Component responsible for configuration relating to transaction characteristics and behaviour.</td></tr><tr><td>AccessBarrier</td><td>Allows physical access of vehicles to a charging site to be controlled.</td></tr><tr><td>AcDcConverter</td><td>Provides a variable DC current source to force energy directly into an EV battery stack, under tight control of the EV's battery management system.</td></tr><tr><td>AcPhaseSelector</td><td>Allows a specific AC phase to be selected (typically at EVSE tier) for single phase vehicle charging in order to lower overall (e.g. site) phase imbalance.</td></tr><tr><td>Actuator</td><td>A general purpose electro-mechanical output system, with optional completion tracking sensing. Each output should use a Variable instance key indicating the nature of the output.</td></tr><tr><td>AirCoolingSystem</td><td>Fans (or equivalent devices) used to provide cooling.</td></tr><tr><td>AreaVentilation</td><td>Fans (or equivalent devices) used to ensure that EVs that require ventilation during charging</td></tr><tr><td>BayOccupancySe nsor</td><td>Sensor (optical, ground loop, ultrasonic, etc.) to detect whether the associated parking/charging bay is physically vacant, or is occupied by a vehicle or other obstruction</td></tr><tr><td>BeaconLighting</td><td>Beacon Lighting to help EV drivers to locate nearby charging places, and/or to determine charging availability state, usually by color variation.</td></tr><tr><td>CableBreakawayS ensor</td><td>A sensor that detects when a charging cable (captive or removable) has been forcibly pulled from the Charging Station.</td></tr><tr><td>CaseAccessSens or</td><td>Reports when an access door/panel is open</td></tr><tr><td>ChargingStation</td><td>The entire Charging Station as a logical entity</td></tr><tr><td>ChargingStatusIn dicator</td><td>The Charging Status Indicator, provides visible feedback to the user about the connection and charging status of an EVSE/Connector. This is commonly in the form of multi-colored lighting.</td></tr><tr><td>ConnectedEV</td><td>ConnectedEV is a component that represents a connected vehicle for which data is received via an ISO 15118 or CHAdeMO interface. The generic information that is received, is represented as variables of ConnectedEV. Any protocol-specific information is represented in variables of the ISO15118Ctrlr or CHAdeMOCtrlr component.</td></tr><tr><td>Connector</td><td>A means to connect an EV to a Charging Station with either a socket, an attached cable & inline connector, or any wireless power transfer device.</td></tr><tr><td>ConnectorHolster Release</td><td>A mechanism present in a connector holster to prevent the connector from being removed inappropriately: typically unlocks connector after authorization.</td></tr><tr><td>ConnectorHolster Sensor</td><td>A mechanism to report when a tethered cable connector has been removed from its normal stowage position. May be used for detection of connectors left un-holstered, and possible penalty billing.</td></tr><tr><td>ConnectorPlugRetentionLock</td><td>Locking mechanism to retain an inserted plug, both to prevent on-load disconnection, and to prevent theft of charging cables</td></tr><tr><td>ConnectorProtectionRelease</td><td>External protective mechanism (e.g. an external shutter or a connector holster lock mechanism) to prevent contact with conductors that may become 'live' under other failure modes</td></tr><tr><td>Controller</td><td>An embedded logic controller</td></tr><tr><td>ControlMetering</td><td>Energy, Power, Electricity meter, used to measure energy, current, voltages etc.</td></tr><tr><td>CPPWMController</td><td>Control Pilot PWM Controller: provides and senses the IEC 61851-1 / SAE J1772 low voltage DC and PWM signalling between an EVSE and EV over a control pilot line.</td></tr><tr><td>DataLink</td><td>Provides a communications link from a Charging Station to a CSMS. It may use fixed infrastructure, mobile telephony data services, WiFi, or other connectivity channels.</td></tr><tr><td>Display</td><td>Provides information and feedback to the user.</td></tr><tr><td>DistributionPanel</td><td>Defines the Distribution Panel, with it's fuses and connections to both Charging Stations and other Distribution Panel's.</td></tr><tr><td>ElectricalFeed</td><td>Represents an incoming electrical connection to a Charging Station, that may be a grid/distribution network connection, of a connection to local power generation and/or storage. Each electrical feed can record the electrical and other characteristics of that feed, including power rating, fusing, upstream metering, etc. When a Charging Station has more than one electrical feed, it must represent which feed supplies each EVSE, and which feed supplies the house load of the Charging Station itself. Simple Charging Stations with only a single electrical feed may omit all electrical feed information, in which case it is inferred that all power is supplied from a single feed, and what would otherwise be ElectricalFeed data (Variables) may be reported as being associated with the ChargingStation component.</td></tr><tr><td>ELVSupply</td><td>Represents the low voltage power supply (typically 12V DC and often other ELV voltages) that provides operating power for controllers, relays, and other electrical components.</td></tr><tr><td>EmergencyStopSensor</td><td>An 'Emergency Stop' button that should be pressed by the user or other nearby persons if serious faulty behavior is observed (e.g. smoke/flames from EV or Charging Station).</td></tr><tr><td>EnvironmentalLigHting</td><td>Provides reporting/control of general illumination lighting in use at Charging Station.</td></tr><tr><td>EVRetentionLock</td><td>A locking mechanism on the EV side as a safety measure to prevent it being disconnected while high currents are flowing.</td></tr><tr><td>EVSE</td><td>The entire chain of components responsible for transporting energy from the incoming supply to the electric vehicle (or vice versa)</td></tr><tr><td>ExternalTemperatureSensor</td><td>Reports ambient air temperature</td></tr><tr><td>FiscalMetering</td><td>Provides energy transfer readings that are the basis for billing.</td></tr><tr><td>FloodSensor</td><td>A sensor reporting whether the Charging Station is experiencing water ingress/pooling.</td></tr><tr><td>GroundIsolationProtection</td><td>An Isolation Tester as part of their own self-test mechanisms, to confirm the isolation of floating circuitry when no Evs are connected</td></tr><tr><td>Heater</td><td>Heater to ensure reliable operation in cold environments</td></tr><tr><td>HumiditySensor</td><td>Reports relative air humidity</td></tr><tr><td>LightSensor</td><td>Reports ambient light levels.</td></tr><tr><td>LiquidCoolingSystem</td><td>A liquid based cooling system, typically used to cool the connector cables of very high power Charging Stations.</td></tr><tr><td>LocalAvailabilitySensor</td><td>Accepts local signal inputs controlling whether new Charging Sessions can start and/or whether ongoing sessions should continue. Typically connected to a site/building power supply, to automatically report unavailability when closed.</td></tr><tr><td>LocalController</td><td>The entire Local Controller as a logical entity</td></tr><tr><td>LocalEnergyStora ge</td><td>Energy storage</td></tr><tr><td>OverCurrentProtection</td><td>Protects equipment by disconnecting the electrical supply when the current drawn (on any phase) exceeds the rated value to a substantial degree.</td></tr><tr><td>OverCurrentProtectionRecloser</td><td>Recloser mechanism of an OverCurrentProtection to perform re-arm retries after a trip, or may be set for remotely controlled re-armring on command.</td></tr><tr><td>PowerContactor</td><td>Switches on and off the power to the EV after all authorization and safety requirements have been met. May have secondary contacts to report closure state.</td></tr><tr><td>RCD</td><td>A Residual Current Device (US: ground fault breaker) protects human life and/or downstream equipment by quickly detecting abnormal current flows (usually indicative in earth faults) in the Charging Station, cable, or EV during charging.</td></tr><tr><td>RCDRecloser</td><td>A motorized recloser mechanism of an RCD that may be configured to perform re-arm retries after a trip, or may be set for remotely controlled re-arming on command.</td></tr><tr><td>RealTimeClock</td><td>Represents realtime clock hardware that can maintain accurate date & time information in a Charging Station, even in the case of simultaneous CSMS uncontactability and power outages or resets.</td></tr><tr><td>ShockSensor</td><td>Measures impact forces/accelerations experienced, indicative of possible damage.</td></tr><tr><td>SpacesCountSignage</td><td>Electronic signage allowing a charging controller for a large charging facility to advertise counts of available spaces to passing traffic.</td></tr><tr><td>Switch</td><td>A general purpose electromechanical input device, with optional remote defaulting/resetting of values. Each input should use a Variable instance key indicating the nature of the input.</td></tr><tr><td>TemperatureSensor</td><td>Temperature sensor at a point inside the Charging Station, multiple sensing points for a single sensing controller. Multiple sensing points for a single sensing controller may be reported using distinct Variable instance keys.</td></tr><tr><td>TiltSensor</td><td>Measures Tilt angle from normal reference position (normally 90 degree vertical).</td></tr><tr><td>TokenReader</td><td>An authorization token reader (e.g. RFID)</td></tr><tr><td>UpstreamProtectiOnTrigger</td><td>Circuitry designed to trigger the disconnection of power to the structure by an upstream protection device after a severe problem has been detected</td></tr><tr><td>UllInput</td><td>A logical input mechanism (e.g. set of buttons) that is part of a UI whose use may be communicated to the CSMS (in near real time). May support momentary inputs ('Operated') or modal state ('Active'). Multiple input sources should use explicit Variable instance keys (where the input function is key name).</td></tr><tr><td>VehicleIdSensor</td><td>Reports an identifier associated with a vehicle occupying a charging bay. The identifier may be a vehicle registration number via ANPR hardware, a VIN, or other local identifier of the vehicle based on medium range/active RFID, or any other relevant technology and result.</td></tr></table>
+
+# Appendix 4. Standardized Variables
+
+This is a non-exhaustive list of Standardized Variables that SHALL be used when the Charging Station and CSMS want to exchange information about a Variable. See also Part 1, paragraph 4.5.
+
+Variables that are specific to a Controller Component are not included in this list, but are part of section 3.1 Controller Components.
+
+<table><tr><td>Name</td><td>DataType</td><td>Unit</td><td>Description</td></tr><tr><td>ACCurrent</td><td>decimal</td><td>A</td><td>RMS AC Current (in amperes). For 3-phase circuits, each phase (and optional neutral) is represented by a Variable instance equal to a value of the PhaseEnumType (e.g. L1,N). Unkeyed values reported for a Component declared to be multi-phase are assumed to be an average of all per-phase readings and written values are common per-phase settings. Example(s): ChargingStation: Total AC current consumption (all EVSE's, ancillaries), EVSE: Total current consumed by EVSE: includes losses (ACDC) and EVSE specific ancillaries (e.g. fans), ElectricalFeed: Inflow AC current on feed</td></tr><tr><td>Active</td><td>boolean</td><td></td><td>Component is in its non-resting / active state: e.g: On, Engaged, Locked. Some Components may have secondary functions that have corresponding Active Variables with an explicit Variable instance., Note: Monitoring of changes in the Active state of any Component can be specified by setting Delta monitoring on the boolean value with a delta values of 1. Setting/clearing an Active Variable activates/stops the associated functionality, where remotely controllable. Only components that are Available and Enabled can be in the Active state.</td></tr><tr><td>ACVoltage</td><td>decimal</td><td>V</td><td>RMS AC Voltage (in volts). For 3-phase circuits, each phase (and optional neutral) is represented by a Variable instance equal to a value of the PhaseEnumType (e.g. L1,N). Unkeyed values reported for a Component declared to be multi-phase are assumed to be an average of all per-phase readings and written values are common per-phase settings. Example(s): ElectricalFeed: Input Voltage</td></tr><tr><td>AllowReset</td><td>boolean</td><td></td><td>Component can be reset. Can be used to announce that an EVSE can be reset individually.</td></tr><tr><td>Angle</td><td>decimal</td><td>Deg</td><td>Angle(s) relative to normal/design idle position. Multiple Variable instance values may be used to indicate angular position in multiple axes (e.g. Left-Right, Forward-Back).</td></tr><tr><td>Attempts</td><td>integer</td><td></td><td>Number of attempts (INCLUDING the original attempt) in the last successful or attempted, cycle of operation. Applies typically to self-monitoring motorized electro-mechanical equipment, etc. (Null): Unknown, 0: Not Attempted/Not allowed, 1: Single attempt/No retries [allowed], 2-N: [up to] N tries [allowed]</td></tr><tr><td>AvailabilityState</td><td>OptionList</td><td></td><td>A value of ConnectorStatusEnumType (See part 2): replicates ConnectorStatus values reported in StatusNotification messages.</td></tr><tr><td>Available</td><td>boolean</td><td></td><td>The Component exists and is locally configured/wired for use, but might not be (remotely) Enabled.</td></tr><tr><td>Certificate</td><td>string</td><td></td><td>Digital Certificate (in Base64 encoding)</td></tr><tr><td>ChargeProtocol</td><td></td><td></td><td>The Charging Control Protocol applicable to a Connector. CHAdemo: CHAdemo protocol, ISO15118: ISO15118 V2G protocol (wired or wireless) as used with CCS, CPPWM: IEC61851-1 / SAE J1772 protocol (ELV DC & PWM signalling via Control Pilot wire), Uncontrolled: No charging power management applies (e.g. Schuko socket), Undetermined: Yet to be determined (e.g. before plugged in), Unknown: Not determinable, NOTE: ChargeProtocol is distinct from and orthogonal to connectorType.</td></tr><tr><td>ChargingCompleteBulk</td><td>boolean</td><td></td><td>Charging up to StateOfChargeBulk has completed.</td></tr><tr><td>ChargingCompleteFull</td><td>boolean</td><td></td><td>Charging up to StateOfCharge.maxSet has completed.</td></tr><tr><td>ChargingTime</td><td>decimal</td><td>s</td><td>Time from earliest to latest substantive energy transfer</td></tr><tr><td>Color</td><td>string</td><td></td><td>Standard 24 bit hexadecimal RGB values. Reg Green Blue color intensity, expressed as standard 24 bit hexadecimal RGB values: 3 00-FF (0-255), in order RRGGBB). E.g. 000000: Black, FF0000: Red, 00FF00: Green, 0000FF: Blue, FFFF00: Yellow, FFFFFFF: White, 008000: Medium intensity green.</td></tr><tr><td>Complete</td><td>boolean</td><td></td><td>Component's operation cycle has completed. Used only in event notifications, where it is always true.</td></tr><tr><td>ConnectedTime</td><td>decimal</td><td>s</td><td>Time since logical connection established</td></tr><tr><td>ConnectorType</td><td>OptionList</td><td></td><td>A value of ConnectorEnumType (See part 2) plus additionally: cGBT, cChaoJi, OppCharge. Specific type of connector, including sub-variant information. Note: Distinct and orthogonal to Charging Protocol, Power Type, Phases.</td></tr><tr><td>Count</td><td>integer</td><td></td><td>General purpose integer count variable for Component state reporting</td></tr><tr><td>Currency</td><td>string</td><td></td><td>Currency in a ISO 4217 formatted currency code.</td></tr><tr><td>CurrentImbalance</td><td>decimal</td><td>Percent</td><td>Percentage current imbalance in an AC three phase supply.</td></tr><tr><td>DataText</td><td>string</td><td></td><td>Text associated with a Component, e.g. a Display.</td></tr><tr><td>DateTime</td><td>dateTime</td><td></td><td>Point in time value, in [RFC3339] datetime format. Time zone optional.</td></tr><tr><td>DCCurrent</td><td>decimal</td><td>A</td><td>DC Current (in amperes). May be an instantaneous measurement, or a period average, depending on context/equipment.</td></tr><tr><td>DCVoltage</td><td>decimal</td><td>V</td><td>DC Voltage (volts). May be an instantaneous measurement, or a period average, depending on context/equipment.</td></tr><tr><td>DepartureTime</td><td>dateTime</td><td></td><td>Time in [RFC3339] datetime format, when an EV intends to leave the charging station.</td></tr><tr><td>ECVariant</td><td>string</td><td></td><td>Production series variants reflecting internal design changes or sub-component substitutions not affecting external functionality.</td></tr><tr><td>Enabled</td><td>boolean</td><td></td><td>The Component is Enabled for operation. For Available components that cannot be selectively (remotely) enabled / disabled, this value is always true. Note: Available cannot be false of Enabled is true, so during inventory reporting, Enabled=1 also logically states Available=true</td></tr><tr><td>Energy</td><td>decimal</td><td>Wh</td><td>Energy quantity (in Wh) for reporting/configuring values related to stored energy (i.e. not transferred energy).</td></tr><tr><td>EnergyCapacity</td><td>decimal</td><td>Wh</td><td>Energy capacity in Wh of an energy storage device.</td></tr><tr><td>EnergyExport</td><td>decimal</td><td>Wh</td><td>Total energy transferred: e.g. from EV during (ongoing or terminated) charging session (in wH by default)</td></tr><tr><td>EnergyExportRegister</td><td>decimal</td><td>Wh</td><td>Cumulative export kWh register value, such as from a (certified) fiscal energy meter.</td></tr><tr><td>Energylimport</td><td>decimal</td><td>Wh</td><td>Total energy transferred.</td></tr><tr><td>EnergylimportRegister</td><td>decimal</td><td>Wh</td><td>Cumulative export kWh register value, such as from a (certified) fiscal energy meter.</td></tr><tr><td>Entries</td><td>integer</td><td></td><td>General purpose variable for reporting/managing numbers of entries in repetitive data structures. maxLimit characteristic reports maximum possible entries.</td></tr><tr><td>Fallback</td><td>boolean</td><td></td><td>Component is operating in a fallback, or backup mode. In inventory reports, a Value of 1 for the maxLimit characteristic indicates that the component can enter a fallback state (i.e. a fallback mode is present).</td></tr><tr><td>FanSpeed</td><td>decimal</td><td>RPM</td><td>Fan Speed (in RPM). A value of 0 represents stopped/stalled. An empty value indicates that fan speed cannot be read.</td></tr><tr><td>FirmwareVersion</td><td>string</td><td></td><td>Version number of firmware.</td></tr><tr><td>Force</td><td>decimal</td><td>N</td><td>Reports (impact) force/ acceleration values (estimates) in one or more directions, in units of Newtons or "g". Multiple force readings in different (orthogonal) dimensions may be reported using Variable instance values, such as Down, Right, Forward.</td></tr><tr><td>Formats</td><td>MemberLi st</td><td></td><td>List of message formats supported by this Charging Station. Possible values: ASCII, HTML, URI, UTF-8.</td></tr><tr><td>Frequency</td><td>decimal</td><td>Hz</td><td>Frequency of AC power, signal, or component operation.</td></tr><tr><td>FuseRating</td><td>decimal</td><td>A</td><td>Current rating of a fuse/breaker. Variable instances keyed by phase identifier (L1/L2/L3/N).</td></tr><tr><td>Height</td><td>decimal</td><td>m</td><td>Height above(+)/below(-) reference level (ground level unless context demands otherwise).</td></tr><tr><td>Humidity</td><td>decimal</td><td>RH</td><td>The relative humidity in %.</td></tr><tr><td>Hysteresis</td><td>decimal</td><td>Percent</td><td>Specifies the width of a 'dead band' (as a percentage of the threshold) around the central value of a threshold setting (e.g. MinSet, MaxSet, monitor thresholds) to avoid repeated triggering when the measured quantity lies close to the threshold and is subject to small variations.</td></tr><tr><td>ICCID</td><td>string</td><td></td><td>ICCID (Integrated Circuit Card IDentifier) of mobile data SIM card.</td></tr><tr><td>Impedance</td><td>decimal</td><td>Ohm</td><td>Impedance: Primary value is real (resistive only) impedance. Where a complex impedance is to be reported, the imaginary part (reactance) must be represented with a separate Variable instance value of 'reactance'. Reactance values are expressed at the (nominal) relevant operating frequency of the Component (e.g. 50/60Hz for mains electricity feed).</td></tr><tr><td>IMSI</td><td>string</td><td></td><td>IMSI (International Mobile Subscriber Identity) number of mobile data SIM card</td></tr><tr><td>Interval</td><td>integer</td><td>s</td><td>Minimum Interval (in seconds) between (attempted) operations.</td></tr><tr><td>ISO15118Evseld</td><td>string</td><td></td><td>EVSE ID in string format as used in ISO 15118 and IEC 63119-2</td></tr><tr><td>Length</td><td>decimal</td><td>m</td><td>General Purpose linear distance measure.</td></tr><tr><td>Light</td><td>decimal</td><td>lx</td><td>(Ambient) light level. The value is in Lux.</td></tr><tr><td>Manufacturer</td><td>string</td><td></td><td>Component Manufacturer name</td></tr><tr><td>Message</td><td>string</td><td></td><td>Specific stored message for display.</td></tr><tr><td>MinimumStatusDuration</td><td>integer</td><td>s</td><td>Minimum duration that a Charging Station or EVSE status is stable before StatusNotificationRequest is sent to the CSMS.</td></tr><tr><td>Mode</td><td>string</td><td></td><td>Operating mode string from among valid options (communicated by OptionList, etc. during capability/configuration discovery).</td></tr><tr><td>Model</td><td>string</td><td></td><td>Manufacturer's Model code/number of Component, including suffixes etc. to identify functional, regional or linguistic variation, but NOT engineering change level internal variation not affecting external behaviour, etc.</td></tr><tr><td>NetworkAddress</td><td>string</td><td></td><td>Current network address of a Component.</td></tr><tr><td>Operated</td><td>boolean</td><td></td><td>The Component operated in an instantaneous, transient, or immediately self-resetting pattern. Used only in event notifications, where it is always true.</td></tr><tr><td>OperatingTimes</td><td>string</td><td></td><td>Recurring operating times in Calendar RRULE format.</td></tr><tr><td>Overload</td><td>boolean</td><td></td><td>Component is in Overload state.</td></tr><tr><td>Percent</td><td>decimal</td><td>Percent</td><td>Generic dimensionless value reporting/setting value.</td></tr><tr><td>PhaseRotation</td><td>OptionList</td><td></td><td>The phase wiring of Component, relative to its upstream feed Component/device. This variable describes the phase rotation of a Component relative to its parent Component, using a three letter string consisting of the letters: R, S, T and x. The letter 'R' can be identified as phase 1 (L1), 'S' as phase 2 (L2), 'T' as phase 3 (L3). The lower case 'x' is used to designate a phase that is not connected. An empty string means that phase rotation is not applicable or not known.</td></tr><tr><td>PostChargingTime</td><td>decimal</td><td>s</td><td>Elapsed time in seconds since last substantive energy transfer</td></tr><tr><td>Power</td><td>decimal</td><td>W,kW</td><td>Instantaneous (real) Power (measured/calculated, including power factor for AC). Where a component (e.g. AC to DC Power Converter) has multiple power measurements, the default (unkeyed) instance is "input" power.</td></tr><tr><td>Problem</td><td>boolean</td><td></td><td>Component itself has a 'Problem' condition that impacts in any significant way on its normal operation. By definition, 'Problem' state includes (logical OR)'Fault' state.'Problem' specifically INCLUDES inability to operate that is propagated (up/down/sideways) from any other associated/connected/containing/contained Component.</td></tr><tr><td>Protecting</td><td>boolean</td><td></td><td>Applies to 'sensor' type Components that have an associated protection capability, whereby they can disconnect power (e.g. using the main PowerContactor) if the sensed quantity is outside preset/configured limits. If Protecting is true, the Component is actively preventing/interrupting charging.</td></tr><tr><td>RemainingTimeBulk</td><td>integer</td><td>s</td><td>Number of seconds remaining to charge to bulk state of charge, given by StateOfChargeBulk.</td></tr><tr><td>RemainingTimeFull</td><td>integer</td><td>s</td><td>Number of seconds remaining to charge to 100% state of charge.</td></tr><tr><td>Seccld</td><td>string</td><td></td><td>The name of the SECC in the string format as required by ISO 15118.</td></tr><tr><td>SerialNumber</td><td>string</td><td></td><td>Serial number of Component.</td></tr><tr><td>SignalStrength</td><td>decimal</td><td>dBm</td><td>(Radio/Wired/Optical) data signal strength, in ASU (typically 0-31 or 99 for unknown). Or dbmW (typically -140 to -50).</td></tr><tr><td>State</td><td>string</td><td></td><td>A state code or name identifier string, to allow the internal state of components to be reported and/or controlled</td></tr><tr><td>StateOfCharge</td><td>decimal</td><td>Percent</td><td>Energy Storage Device (e.g. battery) state of charge, expressed as a percentage of nominal design 0-100% operating range. The value of StateOfCharge.maxSet represents the maximum state of charge for a full battery and is usually at or near 100%.</td></tr><tr><td>StateOfChargeBulk</td><td>decimal</td><td>Percent</td><td>Energy Storage Device (e.g. battery) state of charge up to which fast charging is possible. Above this percentage charging speed will drop significantly.</td></tr><tr><td>Storage</td><td>integer</td><td>B</td><td>In bytes. Amount of storage occupied. Storage(maxLimit) specifies absolute limit Storage(MaxSet) restricts usage to specified Max, if supported.</td></tr><tr><td>SupplyPhases</td><td>integer</td><td></td><td>Number of alternating current phases connected/available. 1 or 3 for AC, 0 means DC (no alternating phases). Null value indicates that the number of phases (e.g. in use) is unknown.</td></tr><tr><td>SUSpending</td><td>boolean</td><td></td><td>If Suspending is true, the Component can is currently suspending charging.</td></tr><tr><td>Suspension</td><td>boolean</td><td></td><td>Applies to 'sensor' type Components that have a charging suspension capability, typically for safety or equipment protection reasons. If Suspension is true, the component can suspend charging when the sensed quantity is outside preset/configured limits.</td></tr><tr><td>Temperature</td><td>decimal</td><td>Celsius, Fahrenheit</td><td>Temperature(s) of component (in Celsius, by default). Components may have multiple indexed temperature sensors.</td></tr><tr><td>Time</td><td>dateTime</td><td></td><td>Point in time value, in ISO 8601 datetime format. Time zone optional.</td></tr><tr><td>TimeOffset</td><td>string</td><td></td><td>A Time Offset with respect to Coordinated Universal Time (aka UTC or Greenwich Mean Time) in the form of an [RFC3339] time (zone) offset suffix, including the mandatory "+" or "-" prefix.</td></tr><tr><td>Timeout</td><td>decimal</td><td>s</td><td>Generic timeout value for Component operation (in seconds).</td></tr><tr><td>Token</td><td>string</td><td></td><td>String of bytes representing an ID token.</td></tr><tr><td>TokenType</td><td>OptionList</td><td></td><td>Type of Token. Value is one of IdTokenEnumType.</td></tr><tr><td>Tries</td><td>integer</td><td></td><td>Number of attempts done by a Component.</td></tr><tr><td>Tripped</td><td>boolean</td><td></td><td>Single-shot device requires explicit intervention to re-prime/activate to normal.</td></tr><tr><td>VehicleId</td><td>string</td><td></td><td>ID that EV provides to charging station. Encoded as a hexbinary string. In ISO 15118 the EVCCID is 6 bytes (MAC address), in CHAdeMO the vehicle id can be 24 bytes.</td></tr><tr><td>VersionDate</td><td>dateTime</td><td></td><td>[RFC3339]</td></tr><tr><td>VersionNumber</td><td>string</td><td></td><td>Version number of hardware</td></tr><tr><td>VoltageImbalance</td><td>decimal</td><td>Percent</td><td>Percentage voltage imbalance in three phase supply.</td></tr></table>
+
+# Appendix 5. Reason Codes
+
+The table below provides a list of standardized reason codes that can be used in the optional StatusInfo element of a response.
+
+For each reason code, some messages that might typically return them are shown. This is not an exhaustive list and only indicative.
+
+StatusInfo is optional. Any implementation should be able to function properly without StatusBar, because every message has the response code values that are essential to perform the function. The reasonCode and additionalInfo in StatusBar are meant to provide more insight on what is happening and maybe allow for some automatic recovery.
+
+# IMPORTANT
+
+The existence of a reason code in this table does not imply a requirement to use it nor does it imply a requirement to any of the mentioned messages.
+
+<table><tr><td>Reason Code</td><td>Description</td><td>Typically used for</td></tr><tr><td>CSNotAccepted</td><td>BootNotification of Charging Station has not (yet) been accepted by CSMS.</td><td>RequestStartTransaction, RequestStopTransaction</td></tr><tr><td>DuplicateProfile</td><td>A charging profile with same stackLevel - chargingProfilePurpose combination already exists on the Charging Station and has an overlapping validity period.</td><td>SetChargingProfile</td></tr><tr><td>DuplicateRequestId</td><td>A requestId is provided, that has already been used for this type of request.</td><td>UpdateFirmware, PublishFirmware and requests for reports.</td></tr><tr><td>FixedCable</td><td>The connector has its own fixed cable that cannot be unlocked.</td><td>UnlockConnector</td></tr><tr><td>FwUpdateInProgress</td><td>Operation is not possible, because a firmware update is in progress.</td><td>Reset</td></tr><tr><td>InternalError</td><td>Operation cannot be completed due to an internal error.</td><td>(generic)</td></tr><tr><td>InvalidCertificate</td><td>Provided certificate is invalid.</td><td>CertificateSigned, InstallCertificate</td></tr><tr><td>InvalidCSR</td><td>Provided CSR is invalid</td><td>SignCertificate</td></tr><tr><td>InvalidIdToken</td><td>Provided idToken is not valid.</td><td>RequestStartTransaction</td></tr><tr><td>InvalidMessageSeq</td><td>Message should not be sent at this moment in current scenario.</td><td>(generic), SetChargingProfile with ISO15118</td></tr><tr><td>InvalidProfile</td><td>Provided chargingProfile contains invalid elements.</td><td>SetChargingProfile, RequestStartTransaction</td></tr><tr><td>InvalidSchedule</td><td>Provided chargingSchedule contains invalid elements.</td><td>SetChargingProfile, RequestStartTransaction</td></tr><tr><td>InvalidStackLevel</td><td>Provided value for stackLevel is invalid.</td><td>SetChargingProfile</td></tr><tr><td>InvalidURL</td><td>Provided URL is invalid.</td><td>UpdateFirmware, PublishFirmware</td></tr><tr><td>InvalidValue</td><td>An invalid value has been provided.</td><td>(generic)</td></tr><tr><td>MissingDevModellinfo</td><td>Information needed for operation is missing from Device Model</td><td>(generic)</td></tr><tr><td>MissingParam</td><td>A parameter that is required for the request is missing.</td><td>(generic)</td></tr><tr><td>NoCable</td><td>No cable is connected at this time.</td><td>UnlockConnector</td></tr><tr><td>NoError</td><td>No error has occurred, but some extra information is in additionalInfo.</td><td>(generic)</td></tr><tr><td>NotEnabled</td><td>Feature is not enabled.</td><td>ClearCache</td></tr><tr><td>NotFound</td><td>No object(s) found that match a provided ID or criteria.</td><td>ClearVariableMonitoring, CustomerInformation, GetChargingProfiles, GetDisplayMessages, GetInstalledCertificates, GetReport</td></tr><tr><td>OutOfMemory</td><td>Operation not possible, because system does not have enough memory.</td><td>(generic)</td></tr><tr><td>OutOfStorage</td><td>Operation not possible, because system does not have enough storage.</td><td>(generic)</td></tr><tr><td>ReadOnly</td><td>Targeted variable is read-only and cannot be set.</td><td>SetVariables</td></tr><tr><td>TooLargeElement</td><td>Provided element is too large to handle.</td><td>CertificateSigned, InstallCertificate</td></tr><tr><td>TooManyElements</td><td>Too many elements have been provided.</td><td>SetChargingProfile, SetVariables, SendLocalList</td></tr><tr><td>TxInProgress</td><td>A transaction is in progress.</td><td>ChangeAvailability, Reset, RequestStartTransaction</td></tr><tr><td>TxNotFound</td><td>There is no such transaction.</td><td>RequestStopTransaction, SetChargingProfile</td></tr><tr><td>TxStarted</td><td>A transaction had already started (e.g. due to cable being plugged in).</td><td>RequestStartTransaction</td></tr><tr><td>UnknownConnectorId</td><td>Connector Id is not known on EVSE</td><td>ChangeAvailability, UnlockConnector</td></tr><tr><td>UnknownConnectorType</td><td>Connector type is not known on EVSE</td><td>ReserveNow</td></tr><tr><td>UnknownEvse</td><td>EVSE is not known on Charging Stations</td><td>ChangeAvailability, ReserveNow, RequestStartTransaction</td></tr><tr><td>UnknownTxId</td><td>Provided transactionId is not known.</td><td>RequestStopTransaction</td></tr><tr><td>Unspecified</td><td>No reason is specified, but some extra information is in additionalInfo</td><td>(generic)</td></tr><tr><td>UnsupportedParam</td><td>A parameter was provided that is not supported.</td><td>(generic)</td></tr><tr><td>UnsupportedRateUnit</td><td>A chargingRateUnit is provided that is not supported.</td><td>SetChargingProfile</td></tr><tr><td>UnsupportedRequest</td><td>This request is not supported.</td><td>(generic)</td></tr><tr><td>ValueOutOfRange</td><td>Provided value is out of range.</td><td>SetVariables, SetVariableMonitoring</td></tr><tr><td>ValuePositiveOnly</td><td>Provided value is not greater than zero.</td><td>(generic)</td></tr><tr><td>ValueTooHigh</td><td>Provided value is too high.</td><td>(generic)</td></tr><tr><td>ValueTooLow</td><td>Provided value is too low.</td><td>(generic)</td></tr><tr><td>ValueZeroNotAllowed</td><td>Provided value cannot be zero.</td><td>(generic)</td></tr><tr><td>WriteOnly</td><td>Targeted variable is write-only and cannot be read.</td><td>GetVariables</td></tr></table>
--- /dev/null
+# OCPP
+
+# Table of Contents
+
+Disclaimer 1
+
+Generic. 2
+
+Version History. 3
+
+1. Scope 4
+
+1.1. OCPP 2.0.1 4
+1.2. OCPP 2.0.1 Edition 3 4
+
+2. Conventions, Terminology and Abbreviations 5
+
+2.1. Conventions 5
+2.2. Terminology 6
+2.3. Abbreviations 8
+2.4. Actors 10
+2.5. References 11
+2.6. Definition of Transaction 12
+2.7. ISO15118 support. 14
+
+3. Generic Requirements. 15
+
+3.1. Time Format Requirements 15
+3.2. Message Timouts 16
+3.3. Language support 16
+
+A. Security 17
+
+1. OCPP Security 18
+
+1.1. Security Objectives 18
+1.2. Design Considerations 18
+1.3. Security Profiles 19
+1.4. Keys used in OCPP 26
+1.5. Certificate Revocation 28
+1.6. Installation 29
+
+2. Use cases & Requirements. 30
+
+A01 - Update Charging Station Password for HTTP Basic Authentication 30
+A02 - Update Charging Station Certificate by request of CSMS 31
+A03 - Update Charging Station Certificate initiated by the Charging Station 35
+A04 - Security Event Notification 39
+A05 - Upgrade Charging Station Security Profile 40
+
+B. Provisioning 42
+
+1. Introduction 43
+
+1.1. Transactions before being accepted by a CSMS 43
+
+2. Use cases & Requirements. 44
+
+2.1. Booting a Charging Station 44
+B01 - Cold Boot Charging Station 44
+B02 - Cold Boot Charging Station-Pending 47
+B03 - Cold Boot Charging Station-Rejected 50
+B04 - Offline Behavior Idle Charging Station 52
+2.2. Configuring a Charging Station 53
+B05 - Set Variables 53
+B06 - Get Variables 55
+B07 - Get Base Report. 57
+B08 - Get Custom Report 60
+B09 - Setting a new NetworkConnectionProfile. 63
+B10 - Migrate to new CSMS 65
+2.3. Resetting a Charging Station 66
+B11 - Reset - WithoutOngoingTransaction 66
+B12 - Reset - With Ongoing Transaction. 70
+
+C. Authorization 74
+
+1. Introduction 75
+
+1.1. ID Tokens 75
+1.2. Group ID Tokens 75
+1.3. Authorization Cache 76
+1.4. Local Authorization List 76
+1.5. Unknown Offline Authorization 76
+
+2. Use cases & Requirements. 77
+
+2.1. Authorization options 77
+C01 - EV Driver Authorization using RFID 77
+C02 - Authorization using a start button. 81
+C03 - Authorization using credit/debit card 83
+C04 - Authorization using PIN-code 86
+C05 - Authorization for CSMS initiated transactions 88
+C06 - Authorization using local id type 90
+2.2. ISO15118Authorization. 93
+C07 - Authorization using Contract Certificates 93
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM) 96
+2.3. GroupId 98
+C09 - Authorization by Groupld 98
+2.4. Authorization Cache 100
+C10 - Store Authorization Data in the Authorization Cache 100
+C11 - Clear Authorization Data in Authorization Cache 102
+C12 - Start Transaction-Cached Id 103
+2.5. Local Authorization list 105
+C13 - Offline Authorization through Local Authorization List 105
+C14 - Online Authorization through Local Authorization List. 107
+2.6. Offline Authorization 109
+C15 - Offline Authorization of unknown Id 109
+2.7. Master Pass 111
+C16 - Stop Transaction with a Master Pass. 111
+
+D. LocalAuthorizationList Management 114
+
+1. Introduction 115
+
+2. Use cases & Requirements 116
+
+D01 - Send Local Authorization List 116
+D02 - Get Local List Version. 119
+
+E. Transactions 120
+
+1. Introduction 121
+
+1.1. Flexible transaction start/stop. 121
+1.2. TransactionId generation 122
+1.3. Delivering transaction-related messages 122
+1.4. Authorization 123
+1.5. Clarification for optional fields in TransactionRequest 123
+
+2. Use cases & Requirements 125
+
+2.1. OCPP transaction mechanism 125
+E01 - Start Transaction options. 125
+E02 - Start Transaction-Cable Plugin First 131
+E03 - Start Transaction-IdTokenFirst. 136
+E04 - Transaction started while Charging Station is offline 140
+E05 - Start Transaction-Id not Accepted 144
+E06 - Stop Transaction options 147
+E07 - Transaction locally stopped by IdToken 152
+E08 - Transaction stopped while Charging Station is offline 157
+E09 - When cable disconnected on EV-side: Stop Transaction 160
+E10 - When cable disconnected on EV-side: Suspend Transaction 163
+E11 - Connection Loss During Transaction 166
+E12 - Inform CSMS of an Offline Occurred Transaction. 168
+E13 - Transaction-related message not accepted by CSMS 170
+E14 - Check transaction status 172
+2.2. Interrupting and Stopping ISO 15118 Charging 173
+E15 - End of charging process 173
+
+F. RemoteControl 175
+
+1. Introduction 176
+
+2. Use cases & Requirements 177
+
+2.1. Remote Transaction Control 177
+F01 - Remote Start Transaction - Cable Plugin First. 177
+F02 - Remote Start Transaction - Remote Start First 181
+F03 - Remote Stop Transaction 186
+F04 - Remote Stop ISO 15118 Charging from CSMS 188
+2.2. Unlock Connector 190
+F05 - Remotely Unlock Connector 190
+2.3. Remote Trigger 192
+F06 - Trigger Message 192
+
+G. Availability 195
+
+1. Introduction 196
+
+2. Use cases & Requirements 197
+
+G01 - Status Notification 197
+G02 - Heartbeat 199
+G03 - Change Availability EVSE/Connector 201
+G04 - Change Availability Charging Station 203
+G05 - Lock Failure 205
+
+H. Reservation 207
+
+1. Introduction 208
+
+2. Use cases & Requirements 209
+
+H01 - Reservation 209
+H02 - Cancel Reservation 213
+H03 - Use a reserved EVSE 214
+H04 - Reservation Ended, not used 217
+
+I. TariffAndCost 218
+
+1. Introduction 219
+
+1.1. Why no structured tariff information? 219
+
+2. Use cases & Requirements 220
+
+I01 - Show EV Driver-specific Tariff Information 220
+102 - Show EV Driver Running Total Cost During Charging 221
+103 - Show EV Driver Final Total Cost After Charging 222
+104 - Show Fallback Tariff Information 223
+I05 - Show Fallback Total Cost Message 225
+I06 - Update Tariff Information During Transaction 226
+
+J. MeterValues 228
+
+1. Introduction 229
+
+2. Configuration 230
+
+2.1. Transaction Meter Values 230
+2.2. Clock-Aligned Meter Values 230
+2.3. Multiple Locations/Phases 231
+2.4. Signed Meter Values 231
+2.5. Configuration Examples 231
+
+3. Use cases & Requirements 233
+
+3.1. MeterValues 233
+J01 - Sending Meter Values not related to a transaction 233
+J02 - Sending transaction related Meter Values 236
+3.2. ISO15118MeterValuesigning. 238
+J03 - Charging Loop with metering information exchange 238
+
+K. SmartCharging 240
+
+1. Introduction 241
+2. Types of Smart Charging 242
+
+2.1. Internal Load Balancing 242
+2.2. Central Smart Charging 242
+2.3. Local Smart Charging 243
+2.4. External Smart Charging Control Signals 243
+
+3. Charging profiles 245
+
+3.1. Introduction 245
+3.2. Charging profile purposes 245
+3.3. Charging profile recurrence 245
+3.4. Stacking charging profiles 246
+3.5. Combining Charging Profile Purposes 246
+3.6. Example Charging Profile 247
+
+4. Smart Charging Signals to a Charging Station from Multiple Actors 249
+
+5. Use cases & Requirements 250
+
+5.1. General Smart Charging 250
+K01 - SetChargingProfile 250
+K02 - Central Smart Charging 255
+K03 - Local Smart Charging 259
+K04 - Internal Load Balancing 262
+K05 - Remote Start Transaction with Charging Profile 263
+K06 - Offline Behavior Smart Charging During Transaction 265
+K07 - Offline Behavior Smart Charging at Start of Transaction. 266
+K08 - Get Composite Schedule 268
+K09 - Get Charging Profiles 270
+K10 - Clear Charging Profile 271
+5.2. External Charging Limit based Smart Charging 274
+K11 - Set / Update External Charging Limit With Ongoing Transaction 274
+K12 - Set / Update External Charging Limit Without Ongoing Transaction 276
+K13 - Reset / Release External Charging Limit 277
+K14 - External Charging Limit with Local Controller 279
+5.3. ISO 15118 based Smart Charging 281
+K15 - Charging with load leveling based on High Level Communication 281
+K16 - Renegotiation initiated by CSMS 284
+K17 - Renegotiation initiated by EV 286
+
+L. FirmwareManagement 290
+
+1. Introduction 291
+
+2. Use cases & Requirements 292
+
+L01 - Secure Firmware Update 292
+L02 - Non-Secure Firmware Update 297
+L03 - Publish Firmware file on Local Controller 302
+L04 - Unpublish Firmware file on Local Controller 304
+
+M. ISO15118 CertificateManagement 306
+
+1. Introduction 307
+
+2. ISO 15118 Certificates 310
+
+2.1. ISO 15118 Certificate structure 310
+2.2. Using ISO 15118 Certificates in OCPP 311
+2.3. 15118 communication set-up 312
+2.4. Certificate - Use Case mapping 312
+
+3. Use cases from ISO 15118 relevant for OCPP. 314
+
+4. Use cases & Requirements 315
+
+M01 - Certificate installation EV 315
+M02 - Certificate Update EV. 316
+M03 - Retrieve list of available certificates from a Charging Station 317
+M04 - Delete a specific certificate from a Charging Station 318
+M05 - Install CA certificate in a Charging Station 319
+M06 - Get V2G Charging Station Certificate status. 321
+
+N. Diagnostics 323
+
+1. Introduction 324
+
+2. Use cases & Requirements 325
+
+2.1. Logging 325
+N01 - Retrieve Log Information 325
+2.2. Configure Monitoring 327
+N02 - Get Monitoring report 327
+N03 - Set Monitoring Base 329
+N04 - Set Variable Monitoring 331
+N05 - Set Monitoring Level 333
+N06 - Clear/RemoveMonitoring 334
+2.3. Monitoring Events 335
+N07 - Alert Event 335
+N08 - Periodic Event 338
+2.4. Customer Information 340
+N09 - Get Customer Information 340
+N10 - Clear Customer Information 341
+
+O. DisplayMessage 344
+
+1. Introduction 345
+
+2. Use cases & Requirements 346
+
+001 - Set DisplayMessage 346
+002 - Set DisplayMessage for Transaction 348
+003 - Get All DisplayMessages 350
+004 - Get Specific DisplayMessages 352
+005 - Clear a DisplayMessage. 354
+006 - Replace DisplayMessage 355
+
+P. DataTransfer 356
+
+1. Introduction 357
+
+2. Use cases & Requirements 358
+
+P01 - Data Transfer to the Charging Station 358
+P02 - Data Transfer to the CSMS 360
+
+Messages, Datatypes & Enumerations 362
+
+1. Messages 363
+
+1.1. Authorization 363
+1.2. BootNotification 363
+1.3. CancelReservation. 364
+1.4. CertificateSigned 364
+1.5. ChangeAvailability 365
+1.6. ClearCache 365
+1.7. ClearChargingProfile 366
+1.8. ClearDisplayMessage 366
+1.9. ClearedChargingLimit 367
+1.10. ClearVariableMonitoring 367
+1.11. CostUpdated 367
+1.12. CustomerInformation 368
+1.13. DataTransfer 368
+1.14. DeleteCertificate 369
+1.15. FirmwareStatusNotification 369
+1.16. Get15118EVCertificate 370
+1.17. GetBaseReport. 371
+1.18. GetCertificateStatus 371
+1.19. GetChargingProfiles 371
+1.20. GetCompositeSchedule 372
+1.21. GetDisplayMessages 373
+1.22. GetInstalledCertificates 373
+1.23. GetLocalListVersion 373
+1.24. GetLog 374
+1.25. GetMonitoringReport 374
+1.26. GetReport 375
+1.27. GetTransactionStatus 375
+1.28. GetVariables 376
+1.29. Heartbeat 376
+1.30. InstallCertificate 377
+1.31. LogStatusNotification 377
+1.32. MeterValues 377
+1.33. NotifyChargingLimit 378
+1.34. NotifyCustomerInformation 378
+1.35. NotifyDisplayMessages 379
+1.36. NotifyEVChargingNeeds 379
+1.37. NotifyEVChargingSchedule 380
+1.38. NotifyEvent 380
+1.39. NotifyMonitoringReport 381
+1.40. NotifyReport 381
+1.41. PublishFirmware 381
+1.42. PublishFirmwareStatusNotification 382
+1.43. ReportChargingProfiles 382
+1.44. RequestStartTransaction 383
+1.45. RequestStopTransaction 384
+1.46. ReservationStatusUpdate 384
+1.47. ReserveNow 384
+1.48. Reset 385
+1.49. SecurityEventNotification 385
+1.50. SendLocalList 386
+1.51. SetChargingProfile 386
+1.52. SetDisplayMessage 387
+1.53. SetMonitoringBase 387
+1.54. SetMonitoringLevel 388
+1.55. SetNetworkProfile 389
+1.56. SetVariableMonitoring 390
+1.57. SetVariables 390
+1.58. SignCertificate 391
+1.59. StatusNotification 391
+1.60. TransactionEvent 392
+1.61. TriggerMessage. 393
+1.62. UnlockConnector 393
+1.63. UnpublishFirmware 394
+1.64. UpdateFirmware 394
+
+2. Datatypes 396
+
+2.1. ACChargingParametersType 396
+2.2. AdditionalInfoType 396
+2.3. APNType 396
+2.4. AuthorizationData 397
+2.5. CertificateHashDataChainType 397
+2.6. CertificateDataType 397
+2.7. ChargingLimitType 397
+2.8. ChargingNeedsType 398
+2.9. ChargingProfileCriterionType 398
+2.10. ChargingProfileType 398
+2.11. ChargingSchedulePeriodType 399
+2.12. ChargingScheduleType 399
+2.13. ChargingStationType 400
+2.14. ClearChargingProfileType 400
+2.15. ClearMonitoringResultType 401
+2.16. ComponentType 401
+2.17. ComponentVariableType 401
+2.18. CompositeScheduleType 401
+2.19. ConsumptionCostType 402
+2.20. CostType 402
+2.21. DCChargingParametersType 402
+2.22. EventDataType 403
+2.23. EVSEType 403
+2.24. FirmwareType 404
+2.25. GetVariableDataType 404
+2.26. GetVariableResultType 404
+2.27. IdTokenInfoType 405
+2.28. IdTokenizerType 405
+2.29. LogParametersType 406
+2.30. MessageContentType. 406
+2.31. MessageInfoType 406
+2.32. MeterValueType 407
+2.33. ModemType 407
+2.34. MonitoringDataType 407
+2.35. NetworkConnectionProfileType 408
+2.36. OCSPRequestDataType 408
+2.37. RelativeTimeIntervalType 409
+2.38. ReportDataType 409
+2.39. SalesTariffEntryType 409
+2.40. SalesTariffType 409
+2.41. SampledValueType 410
+2.42. SetMonitoringDataType 410
+2.43. SetMonitoringResultType 411
+2.44. SetVariableDataType 412
+2.45. SetVariableResultSet 413
+2.46. SignedMeterValueType 413
+2.47. StatusInfoType 413
+2.48. TransactionType 414
+2.49. UnitOfMeasureType 414
+2.50. Variable AttributeType 414
+2.51. VariableCharacteristicsType 415
+2.52. VariableMonitoringType 416
+2.53. VariableType 416
+2.54. VPNType 417
+
+3. Enumerations 418
+
+3.1. APNAAuthenticationEnumType 418
+3.2. AttributeEnumType 418
+3.3. AuthorizationStatusEnumType 418
+3.4. AuthorizationCertificateStatusEnumType 418
+3.5. BootReasonEnumType 419
+3.6. CancelReservationStatusEnumType 419
+3.7. CertificateActionEnumType 419
+3.8. CertificateSignedStatusEnumType 420
+3.9. CertificateSigningUseEnumType 420
+3.10. ChangeAvailabilityStatusEnumType 420
+3.11. ChargingLimitSourceEnumType 420
+3.12. ChargingProfileKindEnumType 420
+3.13. ChargingProfilePurposeEnumType 421
+3.14. ChargingProfileStatusEnumType 421
+3.15. ChargingRateUnitEnumType 421
+3.16. ChargingStateEnumType 422
+3.17. ClearCacheStatusEnumType 422
+3.18. ClearChargingProfileStatusEnumType 422
+3.19. ClearMessageStatusEnumType 422
+3.20. ClearMonitoringStatusEnumType 423
+3.21. ComponentCriterionEnumType 423
+3.22. ConnectorEnumType 423
+3.23. ConnectorStatusEnumType 424
+3.24. CostKindEnumType 424
+3.25. CustomerInformationStatusEnumType 424
+3.26. DataEnumType 425
+3.27. DataTransferStatusEnumType 425
+3.28. DeleteCertificateStatusEnumType 425
+3.29. DisplayMessageStatusEnumType 425
+3.30. EnergyTransferModeEnumType 426
+3.31. EventNotificationEnumType 426
+3.32. EventTriggerEnumType 426
+3.33. FirmwareStatusEnumType 427
+3.34. GenericDeviceModelStatusEnumType 427
+3.35. GenericStatusEnumType 427
+3.36. GetCertificatesldUseEnumType 428
+3.37. GetCertificateStatusEnumType 428
+3.38. GetChargingProfileStatusEnumType 428
+3.39. GetDisplayMessagesStatusEnumType 428
+3.40. GetInstalledCertificateStatusEnumType 429
+3.41. GetVariableStatusEnumType 429
+3.42. HashAlgorithmEnumType 429
+3.43. IdTokenEnumType 429
+3.44. InstallCertificateStatusEnumType 430
+3.45. InstallCertificateUseEnumType 430
+3.46. Iso15118EVCertificateStatusEnumType 430
+3.47. LocationEnumType 430
+3.48. LogEnumType 431
+3.49. LogStatusEnumType 431
+3.50. MeasurandEnumType 431
+3.51. MessageFormatEnumType 432
+3.52. MessagePriorityEnumType 433
+3.53. MessageStateEnumType 433
+3.54. MessageTriggerEnumType 433
+3.55. MonitorEnumType 434
+3.56. MonitoringBaseEnumType 434
+3.57. MonitoringCriterionEnumType 434
+3.58. MutabilityEnumType 434
+3.59. NotifyEVChargingNeedsStatusEnumType 435
+3.60. OCPPInterfaceEnumType 435
+3.61. OCPPTransportEnumType 435
+3.62. OCPPVersionEnumType 435
+3.63. OperationalStatusEnumType 436
+3.64. PhaseEnumType 436
+3.65. PublishFirmwareStatusEnumType 436
+3.66. ReadingContextEnumType 437
+3.67. ReasonEnumType 437
+3.68. RecurrencyKindEnumType 438
+3.69. RegistrationStatusEnumType 438
+3.70. ReportBaseEnumType 438
+3.71. RequestStopStatusEnumType 439
+3.72. ReservationUpdateStatusEnumType 439
+3.73. ReserveNowStatusEnumType 439
+3.74. ResetEnumType 439
+3.75. ResetStatusEnumType 439
+3.76. SendLocalListStatusEnumType 440
+3.77. SetMonitoringStatusEnumType 440
+3.78. SetNetworkProfileStatusEnumType 440
+3.79. SetVariableStatusEnumType 440
+3.80. TransactionEventEnumType 441
+3.81. TriggerMessageStatusEnumType 441
+3.82. TriggerReasonEnumType 441
+3.83. UnlockStatusEnumType 442
+3.84. UnpublishFirmwareStatusEnumType 442
+3.85. UpdateEnumType 442
+3.86. UpdateFirmwareStatusEnumType. 443
+3.87. UploadLogStatusEnumType 443
+3.88. VPENUMType 443
+
+# Referenced Components and Variables 444
+
+1. Controller Components 445
+
+2. Referenced Components and Variables 446
+
+2.1. General 446
+2.2. Security related 454
+2.3. Authorization related 456
+2.4. Authorization Cache related 458
+2.5. Local Authorization List Management related 459
+2.6. Transaction related 461
+2.7. Metering related. 464
+2.8. Reservation related 468
+2.9. Smart Charging related 469
+2.10. Tariff & Cost related 471
+2.11. Diagnostics related 473
+2.12. Display Message related 475
+2.13. Charging Infrastructure related 476
+2.14. ISO 15118 Related. 479
+
+# 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).
+
+# Generic
+
+Version History
+
+<table><tr><td>Version</td><td>Date</td><td>Description</td></tr><tr><td>2.0.1 Edition 3</td><td>2024-05-06</td><td>OCPP 2.0.1 Edition 3. All errata from OCPP 2.0.1 Part 2 until and including Errata 2024-04 have been merged into this version of the specification.</td></tr><tr><td>2.0.1 Edition 2</td><td>2022-12-15</td><td>OCPP 2.0.1 Edition 2. All errata from OCPP 2.0.1 Part 2 - Errata v2.0 have been merged into this version of the specification.</td></tr><tr><td>2.0.1</td><td>2020-03-31</td><td>Final version of OCPP 2.0.1</td></tr><tr><td>2.0</td><td>2018-04-11</td><td>OCPP 2.0 April 2018
+First major release since 1.0.
+Lots of new/improved/revised functionality
+Revised documentation</td></tr></table>
+
+# 1. Scope
+
+This document defines the protocol used between a Charging Station and a Charging Station Management System in an EV charging infrastructure in the form of use cases. If the protocol requires a certain action or response from one side or the other, then this will be stated in this document.
+
+This part of the specification does not define the communication technology. In order to ensure widespread compatibility OCPP 2.0.1 is limited to JSON. The specifications for the JSON implementation are in "Part 4 - JSON over WebSockets implementation guide".
+
+# 1.1. OCPP 2.0.1
+
+This specification defines version 2.0.1 of OCPP.
+
+After the release of OCPP 2.0, some issues were found in OCPP 2.0. Some of these issues could not be fixed issuing errata to the specification text only, as has been done with OCPP 1.6, but required changes to the protocol's machine-readable schema definition files that cannot be backward compatible.
+
+To prevent confusion in the market and possible interoperability issues in the field, OCA has decided to name this version: 2.0.1. OCPP 2.0.1 contains fixes for all the known issues, to date, not only the fixes to the messages.
+
+This version replaces OCPP 2.0. OCA advises implementers of OCPP to no longer implement OCPP 2.0 and only use version 2.0.1 going forward.
+
+As a rule, existing numbered requirements are only updated or removed, previously used requirements numbers are never reused for a totally different requirement.
+
+Any mentions of "OCPP 2.0" refers to revision 2.0.1 unless specifically stated otherwise.
+
+# 1.2. OCPP 2.0.1 Edition 3
+
+A number of errata documents have been released for OCPP 2.0.1 Edition 2 that was released in 2022. These errata until and including Errata 2024-04 have been incorporated in this document, "OCPP-2.0.1edition3_part2_specification", such that it is no longer necessary to read these errata in addition to the specification. The incorporation of the errata in edition 3 does not affect any schemas of OCPP messages. Certain errata did 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 as described. New requirements were 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 2.0.1 part 2 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.
+
+# 2. Conventions, Terminology and Abbreviations
+
+# 2.1. Conventions
+
+# 2.1.1. Normative
+
+All sections and appendices are normative, unless they are explicitly indicated to be informative.
+
+# 2.1.2. Requirements take precedence over text
+
+Whenever there is any (apparent) conflict between narrative text and requirements in the specification document, the requirements have precedence.
+
+# 2.1.3. Requirement Keywords
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119], subject to the following additional clarification clause:
+
+The phrase "valid reasons in particular circumstances" relating to the usage of the terms "SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" is to be taken to mean technically valid reasons, such as the absence of necessary hardware to support a function from a Charging Station design: for the purposes of this specification it specifically excludes decisions made on commercial, or other non-technical grounds, such as cost of implementation, or likelihood of use.
+
+# 2.1.4. Primitive Datatypes
+
+The specification mentions the following primitive datatypes:
+
+Table 1. Primitive Datatypes
+
+<table><tr><td>Datatype</td><td>Description</td></tr><tr><td>string</td><td>The characters defined in the UTF-8 character set are allowed to be used.</td></tr><tr><td>integer</td><td>32 bit (31 bit resolution, 1 sign bit)No leading 0'sNo plus signAllowed value examples: 1234, -1234Not Allowed: 01234, +1234</td></tr><tr><td>decimal</td><td>For data being reported by the Charging Station, the full resolution of the source data must be preserved. The decimal sent towards the Charging Station SHALL NOT have more than six decimal places.</td></tr><tr><td>identifierString</td><td>This is a case-insensitivedataType and can only contain characters from the following character set: a-z, A-Z, 0-9, *', -, _, ' =', ', ', ', ', '@', ''</td></tr><tr><td>dateTime</td><td>All time values exchanged between CSMS and Charging Station SHALL be formatted as defined in [RFC3339]. Additionally fractional seconds have been given an extra limit. The number of decimal places SHALL NOT exceed the maximum of 3.Example 1: 2019-04-12T23:20:50.52Z represents 20 minutes and 50.52 seconds after the 23rd hour of April 12th, 2019 in UTC.Example 2: 2019-12-19T16:39:57+01:00 represents 39 minutes and 57 seconds after the 16th hour of December 19th, 2019 with an offset of +01:00 from UTC (Central European Time).</td></tr><tr><td>passwordString</td><td>This is a UTF-8 encoded case-sensitive string that can only contain characters from the following character set: "a-z", "A-Z", "0-9"or any of the following limited set of symbols: * - _ = : + | @ .</td></tr><tr><td>AnyType</td><td>Data without specified length or format.</td></tr><tr><td>boolean</td><td>Only allowed values: "false" and "true".</td></tr></table>
+
+# 2.1.5. Normal communication
+
+Unless otherwise specified, all use cases and requirements assume normal communication between Charging Station and CSMS (Online).
+
+# 2.1.6. Field description
+
+In many cases, further explanation about how or when to use certain fields in messages and datatypes is given in the field description. See Chapter Messages.
+
+# 2.2. Terminology
+
+# 2.2.1. General Terminology
+
+This section contains the terminology that is used throughout this document.
+
+Table 2. Terminology
+
+<table><tr><td>Terminology</td><td>Description</td></tr><tr><td>Application layer</td><td>OSI-Layer 5-7.</td></tr><tr><td>Authentication</td><td>Authentication is the process of confirming an identity or attribute. When speaking about authentication one should distinguish between user authentication (e.g. sender/receiver) and message authentication.</td></tr><tr><td>Block cipher</td><td>Cryptographic primitive to encrypt/ decrypt messages of fixed block length. Example: AES encrypts blocks of 128 bits (16 bytes) at a time.</td></tr><tr><td>Cable Plugged in</td><td>In this document this can mean the following:- Cable fixed on Charging Station side, cable plugged in to EV-Cable plugged into the Charging Station and EV-Wireless Charger detects an EV</td></tr><tr><td>Certificate</td><td>A digital certificate authenticates a public key or entity. See also Public-Key Infrastructure.</td></tr><tr><td>Certificate Management Protocol</td><td>An internet protocol used to manage X.509 digital certificates within a PKI. It is described in RFC 4210 and uses the certificate request message format (CRMF) described in RFC 4211.</td></tr><tr><td>Charging Cable</td><td>Cable assembly equipped with a, by the EV accepted, plug, intended to be used for the connection between an EV and an EVSE. One side may be permanently attached to the EVSE, or also be equipped with a plug that is accepted by the EVSE.</td></tr><tr><td>Charging Loop</td><td>In this specification the ISO 15118-2 definition of the charging loop is used: the V2G messaging phase for controlling the charging process by ISO 15118.</td></tr><tr><td>Charging Profile</td><td>Generic Charging Profile, used for different types of Profiles. Contains information about the Profile and holds the ChargingSchedule.</td></tr><tr><td>Charging Schedule</td><td>Part of a Charging Profile. Defines a block of charging Power or Current limits. Can contain a start time and length.</td></tr><tr><td>Charging Station</td><td>The Charging Station is the physical system where EVs can be charged. A Charging Station has one or more EVSEs.</td></tr><tr><td>Composite Charging Schedule</td><td>The charging schedule as calculated by the Charging Station. It is the result of the calculation of all active schedules and possible local limits present in the Charging Station. Local Limits might be taken into account.</td></tr><tr><td>Confidentiality</td><td>Only authorized entities may access confidential data. To protect data from unauthorized access it can be encrypted. Then only entities with access to the secret keys can access the data after decrypting it.</td></tr><tr><td>Connector</td><td>The term Connector, as used in this specification, refers to an independently operated and managed electrical outlet on a Charging Station. In other words, this corresponds to a single physical Connector. In some cases an EVSE may have multiple physical socket types and/or tethered cable/Connector arrangements(i.e. Connectors) to facilitate different vehicle types (e.g. four-wheeled EVs and electric scooters).</td></tr><tr><td>Contactor</td><td>An electrically controlled switching device, typically used by Charging Stations to switch charging power on/off.</td></tr><tr><td>Contract Certificate</td><td>A valid certificate for a charging contract in an EV for 15118 communication.</td></tr><tr><td>Control Pilot signal</td><td>A signal used by a Charging Station to inform an EV of a maximum current limit, as defined by IEC61851-1.</td></tr><tr><td>Cost</td><td>Cost to be paid by an EV Driver for consumed energy/time etc. Including taxes.</td></tr><tr><td>Cryptographic hash function</td><td>Cryptographic hash functions should behave as one-way functions. They must be preimage resistant, 2nd preimage resistant, and collision-resistant. Changes in the input must produce explicitly different results in the output. Example: SHA-256. See also ENISA OCPP Security [1].</td></tr><tr><td>Cryptography</td><td>The ENISA Algorithms, Key Sizes and Parameters Report [1] provides an overview of the current state of the art.</td></tr><tr><td>CSMS</td><td>Charging Station Management System. The system that manages Charging Stations and has the information for authorizing Users for using its Charging Stations.</td></tr><tr><td>Data Integrity</td><td>See Integrity and Message authentication.</td></tr><tr><td>Digital Signature</td><td>Authenticates the sender. In practice digital signatures are implemented using elliptic curves (EC).</td></tr><tr><td>Encryption</td><td>Using a cryptographic scheme, the message is mapped to a random-looking undecipherable string ( ciphertext). Decryption reverses the encryption process and can only be performed with the corresponding decryption key. This decryption key is either the same as the encryption key (symmetric cryptography) or the private key in a public-key cryptosystem. The confidentiality of the message can be guaranteed only while the keys are kept secret.</td></tr><tr><td>Energy Management System</td><td>A device that manages the local loads (consumption an production) based on local and/or contractual constraints and/or contractual incentives. It has additional inputs, such as sensors and controls from e.g. PV, battery storage.</td></tr><tr><td>Energy Offer Period</td><td>Time during which a Charging Station is ready and willing to offer energy to an EV.</td></tr><tr><td>Energy Transfer Period</td><td>Time during which an EV chooses to take offered energy, or return it.</td></tr><tr><td>EVSE</td><td>An EVSE is considered as an independently operated and managed part of the Charging Station that can deliver energy to one EV at a time.</td></tr><tr><td>Hash function</td><td>Function that maps a message to a bit string of fixed length (hash value). See also cryptographic hash function.</td></tr><tr><td>Hash value</td><td>Output of a (cryptographic) hash function. The length is fixed in the specs of the hash function.</td></tr><tr><td>High level communication</td><td>bi-directional digital communication using protocol and messages and physical and data link layers specified in ISO 15118 series [ISO15118-1]</td></tr><tr><td>Idle State</td><td>In both use cases and sequence diagrams, Idle status is referred as the state in which a Charging Station is not performing any use case related tasks. Condition during which the equipment can promptly provide a primary function but is not doing so.</td></tr><tr><td>Integrity</td><td>Data cannot be altered without authorization. See also Message authentication.</td></tr><tr><td>Local Controller</td><td>A logical entity between a CSMS and one or more Charging Stations that has the ability to control charging of a group of Charging Stations based on the input from the CSMS, and can send messages to its Charging Stations, independently of the CSMS.</td></tr><tr><td>Master Pass</td><td>IdToken that can be used to stop any (or all) ongoing transactions. This can be used by for example law enforcement personal to stop a transaction.</td></tr><tr><td>Master Pass UI</td><td>Master Pass User Interface, this might be a full color touchscreen, but might also be just a couple of buttons and LEDs and/or sounds that enable a user to select transactions to be stopped.</td></tr><tr><td>Message authentication</td><td>Messages should be protected against unauthorized modifications. The message should always be sent together with an authentication tag providing its authenticity. Such an authentication tag can be the second output of an authenticated cipher such as AES-CCM or AES-GCM or a message authentication code.</td></tr><tr><td>Mode of Operation</td><td>A mode of operation specifies how the message blocks are processed by the block cipher. Using a block cipher in CBC or CTR mode provides encryption only, whereas using a block cipher in CCM or GCM mode encrypts the plaintext and produces a message authentication tag for the ciphertext.</td></tr><tr><td>OCPP-J</td><td>OCPP via JSON over WebSocket.</td></tr><tr><td>Offline</td><td>There is no communication possible between the Charging Station and CSMS. For an OCPP-J connection this means the WebSocket connection is not open.</td></tr><tr><td>Password authentication</td><td>The user proves his/her identity using a password or PIN.</td></tr><tr><td>Phase Rotation</td><td>Defines the wiring order of the phases between the electrical meter (or if absent, the grid connection), and the Charging Station Connector.</td></tr><tr><td>Price</td><td>Specific price tag of a single tariff entry, for example: 0.35 per kWh incl. 18% VAT.</td></tr><tr><td>Public-key cryptography</td><td>"Cryptographic scheme where a public key is published and henceforth can be used for encryption of messages or verification of digital signatures. Each public key has a counterpart, the corresponding private key. This key must be kept secret and is used for decryption or digital signing of messages. Public-key primitives have a high computational complexity for encryption and therefore are mostly used as part of a hybrid encryption scheme where the public key is used to communicate a common symmetric session key under which all further communication is encrypted. Certificates administered by a public-key infrastructure are used to establish the authenticity of the public key. See also ENISA OCPP Security [12]. The most popular public-key encryption scheme is RSA. Digital signatures can be generated most efficiently with elliptic-curve based (EC) mechanisms."</td></tr><tr><td>Public-key infrastructure</td><td>System to generate, administer, and revoke certificates.</td></tr><tr><td>Resume regular transaction</td><td>Used in sequence diagrams to indicate that this use case/sequence diagram has ended, but the transaction has not ended and will continue, but that is outside of scope of that specific use case.</td></tr><tr><td>Requirement</td><td>Provision that conveys criteria to be fulfilled. ISO/IEC Guide 2:2004, 7.5.</td></tr><tr><td>Security Event</td><td>Any event relevant to the secure operation of the device.</td></tr><tr><td>Security Function</td><td>Any function on the device that is needed for it to be operated securely, including access control, authentication, and encryption.</td></tr><tr><td>Session</td><td>A Session in OCPP is a general term that refers to the charging process of an EV, that might include a Transaction.</td></tr><tr><td>Session key</td><td>Symmetric key with a limited lifetime.</td></tr><tr><td>Symmetric cryptography</td><td>Sender and receiver hold the same key. Examples for symmetric primitives are block ciphers or MACs.</td></tr><tr><td>Transaction</td><td>A transaction in OCPP is a part of the complete process of charging an EV that starts and stops based on configurable parameters. These configurable parameters refer to moments in the charging process, such as the EV being connected or the EV driver being authorized.</td></tr><tr><td>Tariff</td><td>Collection of prices depending on charging time, power usage and other price affecting parameters.</td></tr><tr><td>Use case</td><td>A use case is a structured way of describing the (inter)actions necessary to achieve a certain objective. In this document, a use case consists of an actor list, a scenario description, postconditions and a sequence diagram and is always followed by a list of numbered requirements.</td></tr><tr><td>User Authentication</td><td>Verification of the identity of the communication partners (e.g., user on the device). Moreover, verification that the communication partners are still alive throughout a session.</td></tr></table>
+
+# 2.2.2. ISO 15118 and OCPP terminology mapping
+
+This section is informative.
+
+The ISO 15118 terminology is more comprehensive when referring to specific components within EVs and Charging Stations. The following table shows a "mapping" of these terms.
+
+Table 3. ISO 15118 and OCPP terminology mapping
+
+<table><tr><td>ISO 15118</td><td>OCPP</td></tr><tr><td>ChargingProfile (contains the power over time the EV is planned to consume)</td><td>Loosely corresponds to ChargingSchedule in NotifyEVChargingSchedule message.</td></tr><tr><td>SASchedule (the power limits from a secondary actor for charging an EV for a specific time)</td><td>Loosely corresponds to ChargingProfile in SetChargingProfile message.</td></tr><tr><td>EVCC (i.e. Electric Vehicle Communication Controller)</td><td>Controller in the EV that is used for ISO 15118 communication.</td></tr><tr><td>Outlet</td><td>Connector</td></tr><tr><td>SECC (i.e. Supply Equipment Communication Controller)</td><td>Controller in the EVSE of the Charging Station that is used for ISO 15118 communication.</td></tr><tr><td>SA (i.e. Secondary Actor)</td><td>CSMS (or other backend systems)</td></tr></table>
+
+# 2.3. Abbreviations
+
+# 2.3.1. General Abbreviations
+
+This section contains the abbreviations that are used throughout this document.
+
+Table 4. Abbreviations
+
+<table><tr><td>Abbreviation</td><td>Description</td></tr><tr><td>AES</td><td>Advanced Encryption Standard. Original name for this block cipher was Rijndael named after its designers Vincent Rijmen and Joan Daemen.</td></tr><tr><td>BEV</td><td>Battery Electric Vehicle</td></tr><tr><td>CMP</td><td>Certificate Management Protocol</td></tr><tr><td>CS</td><td>Charging Station</td></tr><tr><td>CSL</td><td>Comma Separated List</td></tr><tr><td>CSMS</td><td>Charging Station Management System</td></tr><tr><td>CSO</td><td>Charging Station Operator</td></tr><tr><td>DHCP</td><td>Dynamic Host Configuration Protocol</td></tr><tr><td>DNS</td><td>Domain Name System</td></tr><tr><td>DSO</td><td>Distribution System Operator</td></tr><tr><td>DST</td><td>Daylight Saving Time</td></tr><tr><td>EC</td><td>Elliptic Curve. See also ENISA OCPP Security [1]</td></tr><tr><td>ECDSA</td><td>Elliptic Curve Digital Signature Algorithm.</td></tr><tr><td>EMS</td><td>Energy Management System</td></tr><tr><td>ENISA</td><td>European Union Agency for Network and Information Security.</td></tr><tr><td>EV</td><td>Electric Vehicle</td></tr><tr><td>EVSE</td><td>EV Supply Equipment IEC61851-1</td></tr><tr><td>FQDN</td><td>Fully Qualified Domain Name</td></tr><tr><td>FTP(S)</td><td>File Transport Protocol (Secure)</td></tr><tr><td>HTTP(S)</td><td>HyperText Transport Protocol (Secure)</td></tr><tr><td>ICCID</td><td>Integrated Circuit Card Identifier</td></tr><tr><td>IMSI</td><td>International Mobile Subscription Identity</td></tr><tr><td>JSON</td><td>JavaScript Simple Object Notation</td></tr><tr><td>MAC</td><td>Message authentication code. Provides data integrity. Examples: CMAC, GMAC. See also ENISA OCPP Security [1].</td></tr><tr><td>NAT</td><td>Network Address Translation</td></tr><tr><td>NIST</td><td>National Institute of Standards and Technology.</td></tr><tr><td>NTP</td><td>Network Time Protocol</td></tr><tr><td>PDU</td><td>Protocol Data Unit</td></tr><tr><td>PHEV</td><td>Plugin Hybrid Electric Vehicle</td></tr><tr><td>RDN</td><td>Relative Distinguished Name</td></tr><tr><td>RSA</td><td>Public-key cryptosystem named after its inventors Rivest, Shamir, and Adleman.</td></tr><tr><td>RSA-PSS</td><td>RSA-PSS is a new signature scheme that is based on the RSA cryptosystem and provides increased security assurance. It was added in version 2.1 of PKCS #1, following OCPP Security [23]</td></tr><tr><td>RST</td><td>3 phase power connection, Standard Reference Phasing</td></tr><tr><td>RTS</td><td>3 phase power connection, Reversed Reference Phasing</td></tr><tr><td>SRT</td><td>3 phase power connection, Reversed 240 degree rotation</td></tr><tr><td>STR</td><td>3 phase power connection, Standard 120 degree rotation</td></tr><tr><td>TRS</td><td>3 phase power connection, Standard 240 degree rotation</td></tr><tr><td>TSR</td><td>3 phase power connection, Reversed 120 degree rotation</td></tr><tr><td>SC</td><td>Smart Charging</td></tr><tr><td>TLS</td><td>Transport Layer Security</td></tr><tr><td>TSO</td><td>Transmission System Operator</td></tr><tr><td>URI</td><td>Uniform Resource Identifier RFC-3986 [RFC3986]</td></tr><tr><td>URL</td><td>Uniform Resource Locator - refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location").</td></tr><tr><td>UTC</td><td>Coordinated Universal Time</td></tr><tr><td>WAN</td><td>Wide Area Network.</td></tr></table>
+
+# 2.3.2. ISO 15118 Abbreviations
+
+This section contains the abbreviations from ISO 15118 that are used in this document.
+
+Table 5. ISO 15118 Abbreviations
+
+<table><tr><td>EIM</td><td>External Identification Means</td></tr><tr><td>EMAID</td><td>E-Mobility Account Identifier</td></tr><tr><td>EVCC</td><td>EV Communication Controller</td></tr><tr><td>HLC</td><td>High Level Communication</td></tr><tr><td>HMI</td><td>Human Machine Interface</td></tr><tr><td>LAN</td><td>Local Area Network</td></tr><tr><td>MO</td><td>Mobility Operator</td></tr><tr><td>OEM</td><td>Original Equipment Manufacturer</td></tr><tr><td>OCSP</td><td>Online Certificate Status Protocol</td></tr><tr><td>PWM</td><td>Pulse Width Modulation</td></tr><tr><td>SA</td><td>Secondary Actor</td></tr><tr><td>SECC</td><td>Supply Equipment Communication Controller</td></tr><tr><td>V2G</td><td>Vehicle to Grid</td></tr></table>
+
+# 2.4. Actors
+
+This section is informative.
+
+In OCPP, system actors are covering functions or devices.
+
+Table 6. Actors
+
+<table><tr><td>Actor name</td><td>Actor type</td><td>Actor description</td></tr><tr><td>EV Driver</td><td>Actor</td><td>The Driver of an EV who wants to charge the EV at a Charging Station.</td></tr><tr><td>Connector</td><td>Device</td><td>The term "Connector", as used in this specification, refers to an independently operated and managed electrical outlet on a Charging Station. In other words, this corresponds to a single physical Connector. In some cases an EVSE may have multiple Connectors: multiple physical socket types and/or types (e.g. four-wheeled EVs and electric scooters).</td></tr><tr><td>CSMS</td><td>System</td><td>Charging Station Management System: manages Charging Stations and has the information for authorizing Users for using its Charging Stations.</td></tr><tr><td>Charging Station</td><td>Device</td><td>The Charging Station is the physical system where an EV can be charged. A Charging Station has one or more EVSEs.</td></tr><tr><td>Charging Station Operator</td><td>Actor</td><td>A party that manages a CSMS.</td></tr><tr><td>Electric Vehicle</td><td>Device</td><td>Electric Vehicle, distributed energy resource with a remote battery and socket.</td></tr><tr><td>Local Controller</td><td>Device</td><td>A logical entity between a CSMS and one or more Charging Stations that has the ability to control charging of a group of Charging Stations based on the input from the CSMS.</td></tr><tr><td>External Control System</td><td>Actor</td><td>An external system that may impose charging limits/constraints on the Charging Station or CSMS, for example a DSO or EMS.</td></tr></table>
+
+# 2.5. References
+
+# 2.5.1. Generic references
+
+Table 7.References
+
+<table><tr><td>Reference</td><td>Description</td></tr><tr><td>[DNP3]</td><td>Distributed Network Protocol. https://www.dnp.org/About/Overview-of-DNP3-Protocol</td></tr><tr><td>[EMI3-BO]</td><td>"eMI3 standard version V1.0" http://emi3group.com/documents-links/</td></tr><tr><td>[IEC60870-5-104]</td><td>Set of standards which define systems used for telecontrol (supervisory control and data acquisition) in electrical engineering and power system automation applications. https://webstore.iec.ch/publication/3755</td></tr><tr><td>[IEC61850-7-420]</td><td>Communications standard for distributed energy resources (DER). https://webstore.iec.ch/publication/6019</td></tr><tr><td>[IEC61851-1]</td><td>"IEC 61851-1 2017: EV conductive charging system - Part 1: General requirements" https://webstore.iec.ch/publication/33644</td></tr><tr><td>[IEC62196]</td><td>IEC 62196: Plugs, socket-outlets, vehicle couplers and vehicle inlets - Conductive charging of electric vehicles. https://webstore.iec.ch/publication/6582</td></tr><tr><td>[ISO15118-1]</td><td>ISO 15118-1 specifies terms and definitions, general requirements and use cases as the basis for the other parts of ISO 15118. It provides a general overview and a common understanding of aspects influencing the charge process, payment and load leveling. https://webstore.iec.ch/publication/9272</td></tr><tr><td>[ISO15118-2]</td><td>Road vehicles – Vehicle to grid communication interface – Part 2: Technical protocol description and Open Systems Interconnection (OSI) layer requirements, Document Identifier: 69/216/CDV. https://webstore.iec.ch/publication/9273</td></tr><tr><td>[ISO4217]</td><td>"ISO 4217: Currency codes" http://www.iso.org/iso/home/standards/currency_codes.htm</td></tr><tr><td>[OCPP2.0-PART4]</td><td>"OCPP 2.0.1: Part 4 - JSON over WebSockets implementation guide". http://www.openchargealliance.org/downloads/</td></tr><tr><td>[OpenADR]</td><td>"Open Automated Demand Response" http://www.openadr.org/</td></tr><tr><td>[RFC1321]</td><td>"The MD5 Message-Digest Algorithm" https://tools.ietf.org/html/rfc1321</td></tr><tr><td>[RFC2119]</td><td>"Key words for use in RFCs to Indicate Requirement Levels". S. Bradner. March 1997. http://www.ietf.org/rfc/rfc2119.txt</td></tr><tr><td>[RFC3339]</td><td>"Date and Time on the Internet: Timestamps" https://tools.ietf.org/html/rfc3339</td></tr><tr><td>[RFC3986]</td><td>"Uniform Resource Identifier (URI): Generic Syntax" https://tools.ietf.org/html/rfc3986</td></tr><tr><td>[RFC5646]</td><td>"Tags for Identifying Languages" https://tools.ietf.org/html/rfc5646</td></tr></table>
+
+# 2.5.2. Security related references
+
+Table 8. Security related references
+
+<table><tr><td>Reference</td><td>Description</td></tr><tr><td>[1]</td><td>ENISA European Network and Information Security Agency, Algorithms, key size and parameters report 2014, 2014. (last accessed on 17 January 2016) https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014</td></tr><tr><td>[2]</td><td>National Institute of Standards and Technology. FIPS PUB 140-2, Security Requirements for Cryptographic Modules, May 2001. http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf</td></tr><tr><td>[3]</td><td>Cooper, D., et al., Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Internet Engineering Task Force, Request for Comments 5280, May 2008, http://www.ietf.org/rfc/rfc5280.txt</td></tr><tr><td>[4]</td><td>Dierks, T. and Rescorla, E., The Transport Layer Security (TLS) Protocol Version 1.2, Internet Engineering Task Force, Request for Comments 5246, August 2008, http://www.ietf.org/rfc/rfc5246.txt</td></tr><tr><td>[5]</td><td>Eastlake, D., Transport Layer Security (TLS) Extensions: Extension Definitions, Internet Engineering Task Force, Request for Comments 6066, January 2011, http://www.ietf.org/rfc/rfc6066.txt</td></tr><tr><td>[6]</td><td>McGrew, D. and Bailey, D., AES-CCM Cipher Suites for Transport Layer Security (TLS), Internet Engineering Task Force, Request for Comments 6655, July 2012, http://www.ietf.org/rfc/rfc6655.txt</td></tr><tr><td>[7]</td><td>Rescorla E. et al., Transport Layer Security (TLS) Renegotiation Indication Extension, Internet Engineering Task Force, Request for Comments 5746, February 2010, http://www.ietf.org/rfc/rfc5746.txt</td></tr><tr><td>[8]</td><td>"Russel Housley, Tim Polk, Warwick Ford, and David Solo. Internet Public Key Infrastructure: X.509 Certificate and Certificate Revocation List (CRL) Profile, RFC 3280, April 2002." https://www.ietf.org/rfc/rfc3280.txt</td></tr><tr><td>[9]</td><td>Pettersen. "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension." RFC 6961, June 2013. https://tools.ietf.org/html/rfc6961.</td></tr><tr><td>[10]</td><td>Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004. https://www.ietf.org/rfc/rfc3749.txt</td></tr><tr><td>[11]</td><td>National Institute of Standards and Technology. Annex C: Approved Random Number Generators for FIPS PUB 140-2 [25], February 2012. https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexc.pdf</td></tr><tr><td>[12]</td><td>Bundesamt für Sicherheit in der Informationstechnik: Anwendungshinweise und Interpretationen zum Schema, AIS 20, Funktionalitätsklassen und Evaluationsmethodologie für deterministicische Zufallszahlengeneratoren, Version 3.0, Bonn, Germany, May 2013. (in German) https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_20.pdf.html</td></tr><tr><td>[13]</td><td>Bundesamt für Sicherheit in der Informationstechnik: Anwendungshinweisige und Interpretationen zum Schema, AIS 31, Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren, Version 3.0, Bonn, Germany, May 2013. (in German) https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31.pdf.html</td></tr><tr><td>[14]</td><td>"OWASP - Transport Layer Protection Cheat Sheet. https://www.owasp.org/index.php/Transport LayerProtection_Cheat_Sheet#Extended_Observation_Certificates"</td></tr><tr><td>[15]</td><td>P. Hoffman and W.C.A. Wijngaards, Elliptic Curve Digital Signature Algorithm (DSA) for DNNSEC, Internet Engineering Task Force (IETF) RFC 6605, April 2012. http://www.ietf.org/rfc/rfc6605.txt</td></tr><tr><td>[16]</td><td>Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005. https://www.ietf.org/rfc/rfc4210.txt</td></tr><tr><td>[17]</td><td>National Institute of Standards and Technology. Special Publication 800-57 Part 1 Rev. 4, Recommendation for Key Management. January 2016. https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-4/final</td></tr><tr><td>[18]</td><td>RFC 2617. HTTP Authentication: Basic and Digest Access Authentication. https://www.ietf.org/rfc/rfc2617.txt</td></tr><tr><td>[19]</td><td>RFC 5280. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. https://www.ietf.org/rfc/rfc5280.txt</td></tr><tr><td>[20]</td><td>OCPP 1.6. Interface description between Charging Station and CSMS. October 2015. http://www.openchargealliance.org/downloads/</td></tr><tr><td>[21]</td><td>Eekelen, M. van, Poll, E., Hubbers, E., Vieira, B., Broek, F. van den: An end-to-end security design for smart EV-charging for Enexis and ElaadNL by LaQuSo1. December 2, 2014. https://www.elaad.nl/smart-charging-end2end-security-design/</td></tr><tr><td>[22]</td><td>RFC 2986. PKCS #10: Certification Request Syntax Specification, Version 1.7. https://www.ietf.org/rfc/rfc2986.txt</td></tr><tr><td>[23]</td><td>RSA-PSS. https://tools.ietf.org/html/rfc8017</td></tr><tr><td>[24]</td><td>Santesson, et al. "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP" RFC 6960. June 2013. https://tools.ietf.org/html/rfc6960</td></tr><tr><td>[25]</td><td>RFC 2818. HTTP Over TLS. https://tools.ietf.org/html/rfc2818</td></tr></table>
+
+# 2.6. Definition of Transaction
+
+This section is informative.
+
+To support as many business cases as possible, and to prevent too many messages being sent when not needed for certain business cases, OCPP 2.0.1 supports flexible configuration of the start and stop of a transaction. This makes it possible to define the start and stop of a transaction depending on market demands.
+
+See: Flexible transaction start/stop for more information.
+
+# 2.6.1. Transaction in relation to Energy Transfer Period
+
+The Energy Transfer Period is a period of time during which energy is transferred between the EV and the EVSE. There MAY be multiple Energy Transfer Periods during a Transaction.
+
+Multiple Energy Transfer Periods can be separated by either:
+
+- an EVSE-initiated suspense of transfer during which the EVSE does not offer energy transfer, or;
+- an EV-initiated suspense of transfer during which the EV remains electrically connected to the EVSE, or;
+- an EV-initiated suspense of transfer during which the EV is not electrically connected to the EVSE.
+
+
+Figure 1. OCPP Charging Transaction definition
+
+# 2.7. ISO 15118 support
+
+This section is informative.
+
+This version of OCPP supports ISO 15118 authorization (also called "Plug and Charge") and ISO 15118 based Smart Charging. (See [ISO15118-2]) Furthermore it describes how to install and update ISO 15118 certificates. These 3 functionalities are not included as one functional block, but are included in multiple chapters throughout the specification. ISO 15118 authorization is included in the functional block Authorization and the Smart Charging use cases for ISO 15118 are included in the chapter Smart Charging. Certificate handling is described in a separate functional block.
+
+Implementors of 15118 need to be aware of timeout constraints enforced by 15118, see [ISO15118-1] (Page: 127, Table: 109) For reference, the current timing constrains for 15118 edition 1 are:
+
+Table 9.ISO 15118 Timing constrains
+
+<table><tr><td>Timeout</td><td>Default</td></tr><tr><td>Sequence Timeouts</td><td>60 seconds</td></tr><tr><td>Sequence Performance Timeouts</td><td>40 seconds</td></tr><tr><td>PaymentDetailsReq/Res</td><td>5 seconds</td></tr><tr><td>CertificateUpdateReq/Res</td><td>5 seconds</td></tr><tr><td>CertificateInstallationReq/Res</td><td>5 seconds</td></tr></table>
+
+# 3. Generic Requirements
+
+This section is normative.
+
+The generic requirements build the basis for defining the use case elements described in the Functional Blocks.
+
+Table 10. Generic requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>FR.01</td><td></td><td>The sender of a <message>Request SHALL wait for a <message>Response or a timeout, before sending another request message.</td><td></td></tr><tr><td>FR.02</td><td>When the Charging Station receives a valid OCPP request message according to the JSON schemas / RPC Framework AND the other system is not causing a security violation</td><td>The Charging Station SHALL respond with a RPC Framework: CALLRESULT.</td><td>If the Charging Station/CSMS needs to provide additional information, this can be done in the statusInfo element of the response message.</td></tr><tr><td>FR.03</td><td>When the Charging Station/CSMS receives an invalid OCPP message according to the JSON schemas / RPC Framework OR the other system causes a security violation</td><td>The Charging Station/CSMS SHALL respond with a RPC Framework: CALLERROR.</td><td></td></tr><tr><td>FR.04</td><td>When the CSMS did not accept the BootNotificationRequest from the Charging Station AND The Charging Station sends a message other than BootNotificationRequest</td><td>The CSMS SHALL respond with a RPC Framework: CALLERROR: SecurityError.</td><td></td></tr><tr><td>FR.05</td><td>There are a few messages that do not provide their result in the response message, but send one or more messages that contain the result. When one of the following messages is received; GetReport, GetBaseReport, GetMonitoringReport, GetDisplayMessages, CustomerInformation, GetChargingProfiles, GetLog, UpdateFirmware, PublishFirmware, TriggerMessage(<message>)</td><td>The Charging Station SHALL acknowledge the requests in the list below with a response message (shown after the arrow "→") with the same requestId as the request: GetReport → NotifyReport GetBaseReport → NotifyReport GetMonitoringReport → NotifyMonitoringReport GetDisplayMessages → NotifyDisplayMessage CustomerInformation → NotifyCustomerInformation GetChargingProfiles → ReportChargingProfiles GetLog → LogStatusNotification UpdateFirmware → FirmwareStatusNotification PublishFirmware → PublishFirmwareStatusNotification TriggerMessage(<message>) → <requested message></td><td>The CSMS needs to know that a request for requestId = X was accepted, so that it can expect result messages for this requestId. TriggerMessage does not have a requestId, but the requirement still applies in the sense that a TriggerMessageResponse must be sent before the sending the requested message.</td></tr></table>
+
+# 3.1. Time Format Requirements
+
+This section is normative.
+
+All time values exchanged between CSMS and Charging Station SHALL be formatted as defined in RFC-3339 [RFC3339]. Additionally fractional seconds have been given an extra limit. The number of decimal places SHALL NOT exceed the maximum of
+
+3. However, it is RECOMMENDED to omit fractional seconds entirely, because it is of limited use and omitting it reduces data usages.
+
+It is strongly RECOMMENDED to exchange all time values between CSMS and Charging Station as UTC, with the time zone designator 'Z', as specified by RFC-3339 [RFC3339]. This will improve interoperability between CSMS and Charging Station.
+
+# 3.1.1. Displaying local time
+
+When a Charging Station wants to give detailed control of configuring the internal clock to a CSO, it can implement one or more of the following Configuration Variables: TimeSource, TimeZone, TimeOffset, NtpSource, NtpServerUri.
+
+# 3.1.1.1. Daylight Saving Time
+
+There are 2 ways a Charging Station can support punctual automated bi-annual changeover between "standard time" and "daylight saving time" periods.
+
+- The transition dates and offsets are known in the Charging Station, based on the configured TimeZone.
+- The transition date and offset is manually configured for every transition via: NextTimeOffsetTransitionDateTime and TimeOffsetNextTransition.
+
+Daylight saving time is used for displaying the current time to the EV driver.
+
+# 3.2. Message timeouts
+
+This section is normative.
+
+OCPP does not specify timing requirements for messages. Timing of messages is greatly influenced by the underlying network used. A GPRS network has different timing characteristics compared to a land-line. As OCPP does not require a certain type of network, but leaves this open for the CSO to select, OCPP cannot require timing constrains.
+
+If you are looking for some guidance, start with a 30 second timeout on message requests, and tune it for the network used.
+
+The message timeout setting in a Charging Station can be configured in the messageTimeout field in the NetworkConnectionProfile. The purpose of the message timeout is to be able to consider a request message as not sent and continue with other tasks when the message did not arrive due to communication errors or software failure. For transaction related events, use case E13 - Transaction-related message not accepted by CSMS describes the retry procedure when this happens. See also the section Delivering transaction-related messages in Functional Block E.
+
+A charging station may discover that the connection to CSMS is not functioning correctly when it gets a timeout to a request or when the websocket ping is not answered. In such a situation it is advised that the charging station drops the connection and then reconnects to CSMS. This will create a fresh session and will possibly connect to a different endpoint of a multi-instance CSMS, which may resolve the error.
+
+# 3.3. Language support
+
+This section is informative.
+
+A CSMS can provide the Charging Station with preferred languages for an EV Driver, enabling the Charging Station to communicate with the EV Driver in a language according to his/her preferences.
+
+For any Charging Station that shows messages on a display it is RECOMMENDED to at least also implement these in "English". When the preferred languages for an EV-driver (provided by the CSMS) are not "English" and don't match any of the other languages implemented in the Charging Station, it is RECOMMENDED to use "English" as fall-back.
+
+# A. Security
+
+# 1. OCPP Security
+
+This Functional Block describes the security requirements for the OCPP protocol. The security part was developed to strengthen and mature the future development and standardization of OCPP. It is based amongst others on the end-to-end security design by LaQuSo [21]. Security requirements are included on security measures at Charging Station and CSMS, to support users of the OCPP.
+
+# 1.1. Security Objectives
+
+This section is informative.
+
+OCPP security has been designed to meet the following security objectives:
+
+1. To allow the creation of a secure communication channel between the CSMS and Charging Station. The integrity and confidentiality of messages on this channel should be protected with strong cryptographic measures.
+2. To provide mutual authentication between the Charging Station and the CSMS. Both parties should be able to identify who they are communicating with.
+3. To provide a secure firmware update process by allowing the Charging Station to check the source and the integrity of firmware images, and by allowing non-repudiation of these images.
+4. To allow logging of security events to facilitate monitoring the security of the smart charging system. A list of security related events and their 'criticality' is provided in the appendices.
+
+# 1.2. Design Considerations
+
+This section is informative.
+
+The security Functional Block was designed to fit into the approach taken in OCPP. Standard web technologies are used whenever possible to allow cost-effective implementations using available web libraries and software. No application layer security measures are included. Based on these considerations, OCPP security is based on TLS and public key cryptography using X.509 certificates. Because the CSMS usually acts as the server, different users or role-based access control on the Charging Station are not implemented in this standard. To mitigate this, it is recommended to implement access control on the CSMS. To make sure the mechanisms implemented there cannot be bypassed, OCPP should not be used by qualified personnel performing maintenance to Charging Stations locally at the Charging Station, as other protocols may be used for local maintenance purposes.
+
+# 1.3. Security Profiles
+
+This section defines the different OCPP security profiles and their requirement. OCPP 2.0.1 supports three security profiles: The table below shows which security measures are used by which profile.
+
+Table 11. Overview of OCPP security profiles
+
+<table><tr><td>Profile</td><td>Charging Station Authentication</td><td>CSMS Authentication</td><td>Communication Security</td></tr><tr><td>1. Unsecured Transport with Basic Authentication</td><td>HTTP Basic Authentication</td><td>-</td><td>-</td></tr><tr><td>2. TLS with Basic Authentication</td><td>HTTP Basic Authentication</td><td>TLS authentication using certificate</td><td>Transport Layer Security (TLS)</td></tr><tr><td>3. TLS with Client Side Certificates</td><td>TLS authentication using certificate</td><td>TLS authentication using certificate</td><td>Transport Layer Security (TLS)</td></tr></table>
+
+- 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.
+- When the Charging Station does not have the correct date and time set, it cannot validate the server certificate. A solution for this might be to either use NTP, mobile network to set time automatically, or have an installer tool that sets the time before the first connection.
+
+# 1.3.1. Generic Security Profile requirements
+
+Table 12. Generic Security Profile requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.001</td><td></td><td>The Charging Station and CSMS SHALL only use one security profile at a time</td></tr><tr><td>A00.FR.002</td><td>If the Charging Station tries to connect with a different profile than the CSMS is using</td><td>The CSMS SHALL terminate the connection.</td></tr><tr><td>A00.FR.003</td><td>If the CSMS tries to connect with a different profile than the Charging Station is using</td><td>The Charging Station SHALL terminate the connection.</td></tr><tr><td>A00.FR.004</td><td></td><td>The security profile SHALL be configured before OCPP communication is possible.</td></tr><tr><td>A00.FR.005</td><td></td><td>Lowering the security profile that is used, to a less secure profile, is for security reasons, not part of the OCPP specification, and MUST be done through another method, not via OCPP. OCPP messages SHALL NOT be used for this (e.g. SetVariablesRequest or DataTransferRequest).</td></tr><tr><td>A00.FR.006</td><td>When a CSMS communicates with Charging Stations with different security profiles or different versions of OCPP.</td><td>The CSMS MAY operate the Charging Stations via different addresses or ports of the CSMS.For instance, the CSMS server may have one TCP port for TLS with Basic Authentication, and another port for TLS with Client Side Certificates.In this case there is only one security profile in use per port of the CSMS, which is allowed.</td></tr></table>
+
+# 1.3.2. Unsecured Transport with Basic Authentication Profile - 1
+
+Table 13. Security Profile 1 - Unsecured Transport with Basic Authentication
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Unsecured Transport with Basic Authentication</td></tr><tr><td>2</td><td>Profile No.</td><td>1</td></tr><tr><td>3</td><td>Description</td><td>The Unsecured Transport with Basic Authentication profile provides a low level of security. Charging Station authentication is done through a username and password. No measures are included to secure the communication channel.</td></tr><tr><td>4</td><td>Charging Station Authentication</td><td>For Charging Station authentication HTTP Basic authentication is used.</td></tr><tr><td>5</td><td>CSMS Authentication</td><td>In this profile, the CSMS does not authenticate itself to the Charging Station. The Charging Station has to trust that the server it connects to is indeed the CSMS.</td></tr><tr><td>6</td><td>Communication Security</td><td>No communication security measures are included in the profile.</td></tr></table>
+
+
+Figure 2. Sequence Diagram: HTTP Basic Authentication sequence diagram
+
+<table><tr><td>7</td><td>Remark(s)</td><td>Please note, that the encoding of the basic authentication password in OCPP 2.0.1 (A00.FR.205) differs from how this was done in OCPP 1.6.</td></tr></table>
+
+# 1.3.3. Unsecured Transport with Basic Authentication Profile - Requirements
+
+Table 14. Security Profile 1 - Unsecured Transport with Basic Authentication - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.201</td><td></td><td>The Unsecured Transport with Basic Authentication Profile SHOULD only be used in trusted networks.</td></tr><tr><td>A00.FR.202</td><td></td><td>The Charging Station SHALL authenticate itself to the CSMS using HTTP Basic authentication [18]</td></tr><tr><td>A00.FR.203</td><td>A00.FR.202</td><td>The client, i.e. the Charging Station, SHALL provide a username and password with every connection request.</td></tr><tr><td>A00.FR.204</td><td>A00.FR.203</td><td>The username SHALL be equal to the Charging Station identity, which is the identifying string of the Charging Station as it uses it in the OCPP-J connection URL. When using Basic Authentication, the Charging Station identity may not contain the character"." Otherwise the CSMS may be unable to separate the username from the password.</td></tr><tr><td>A00.FR.205</td><td></td><td>The password SHALL be stored in the BasicAuthPassword Configuration Variable. It SHALL be a randomly chosen passwordString with a sufficiently high entropy, consisting of minimum 16 and maximum 40 characters (alpha-numeric 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).</td></tr><tr><td>A00.FR.206</td><td>A00.FR.203</td><td>With HTTP Basic, the username and password are transmitted in clear text, encoded in base64 only. Hence, it is RECOMMENDED that this mechanism will only be used over connections that are already secured with other means, such as VPNs.</td></tr><tr><td>A00.FR.207</td><td>A00.FR.202</td><td>The CSMS SHALL validate that Charging Station identity and the Basic Authentication password match with username and password in the authorization header of the connection request.</td></tr></table>
+
+# 1.3.4. TLS with Basic Authentication Profile - 2
+
+Table 15. Security Profile 2 - TLS with Basic Authentication
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>TLS with Basic Authentication</td></tr><tr><td>2</td><td>Profile No.</td><td>2</td></tr><tr><td>3</td><td>Description</td><td>In the TLS with Basic Authentication profile, the communication channel is secured using Transport Layer Security (TLS). The CSMS authenticates itself using a TLS server certificate. The Charging Stations authenticate themselves using HTTP Basic Authentication.</td></tr><tr><td>4</td><td>Charging Station Authentication</td><td>For Charging Station authentication HTTP Basic authentication is used.Because TLS is used in this profile, the password will be sent encrypted, reducing the risks of using this authentication method.</td></tr><tr><td>5</td><td>CSMS Authentication</td><td>The Charging Station authenticates the CSMS via the TLS server certificate.</td></tr><tr><td>6</td><td>Communication Security</td><td>The communication between Charging Station and CSMS is secured using TLS.</td></tr></table>
+
+
+Figure 3. Sequence Diagram: TLS with Basic Authentication sequence diagram
+
+<table><tr><td>7</td><td>Remark(s)</td><td>TLS allows a number of configurations, not all of which provide sufficient security. The requirements below describe the configurations allowed for OCPP.
+The Charging Station should include the same header as used in Basic Auth RFC 2617, while requesting to upgrade the http connection to a websocket connection as described in RFC 6455. The server first needs to validate the Authorization header before upgrading the connection.
+Example:
+GET /ws HTTP/1.1
+Remote-Addr: 127.0.0.1
+UPGRADE: websocket
+CONNECTION: Upgrade
+HOST: 127.0.0.1:9999
+ORIGIN: http://127.0.0.1:9999
+SEC-WEBSOCKET-KEY: Pb4obWo2214EfaPQuazMjA==
+SEC-WEBSOCKET-VERSION: 13
+AUTHORIZATION: Basic <Base64 encoded(<ChargePointId>;<AuthorizationKey>)</td></tr><tr><td></td><td></td><td>Please note, that the encoding of the basic authentication password in OCPP 2.0.1 (A00.FR.304) differs from how this was done in OCPP 1.6.</td></tr></table>
+
+# 1.3.5. TLS with Basic Authentication Profile - Requirements
+
+Table 16. Security Profile 2 - TLS with Basic Authentication - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.301</td><td></td><td>The Charging Station SHALL authenticate itself to the CSMS using HTTP Basic authentication [18]</td></tr><tr><td>A00.FR.302</td><td>A00.FR.301</td><td>The client, i.e. the Charging Station, SHALL provide a username and password with every connection request.</td></tr><tr><td>A00.FR.303</td><td>A00.FR.302</td><td>The username SHALL be equal to the Charging Station identity, which is the identifying string of the Charging Station as it uses it in the OCPP-J connection URL. When using Basic Authentication, the Charging Station identity may not contain the character"." Otherwise the CSMS may be unable to separate the username from the password.</td></tr><tr><td>A00.FR.304</td><td>A00.FR.302</td><td>The password SHALL be stored in the BasicAuthPassword Configuration Variable. It SHALL be a randomly chosen passwordString with a sufficiently high entropy, consisting of minimum 16 and maximum 40 characters (alpha-numeric 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).</td></tr><tr><td>A00.FR.306</td><td></td><td>The CSMS SHALL act as the TLS server.</td></tr><tr><td>A00.FR.307</td><td></td><td>The CSMS SHALL authenticate itself by using the CSMS certificate as server side certificate.</td></tr><tr><td>A00.FR.308</td><td></td><td>The Charging Station SHALL verify the certification path of the CSMS's certificate according to the path validation rules established in Section 6 of [3].</td></tr><tr><td>A00.FR.309</td><td></td><td>The Charging Station SHALL verify that the commonName includes the CSMS's FQDN.</td></tr><tr><td>A00.FR.310</td><td>If the CSMS does not own a valid certificate, or if the certification path is invalid</td><td>The Charging Station SHALL trigger an InvalidCsmsCertificate security event (See part 2 appendices for the full list of security events).</td></tr><tr><td>A00.FR.311</td><td>A00.FR.310</td><td>The Charging Station SHALL terminate the connection.</td></tr><tr><td>A00.FR.312</td><td></td><td>The communication channel SHALL be secured using Transport Layer Security (TLS) [4].</td></tr><tr><td>A00.FR.313</td><td></td><td>The Charging Station and CSMS SHALL only use TLS v1.2 or above.</td></tr><tr><td>A00.FR.314</td><td></td><td>Both of these endpoints SHALL check the version of TLS used.</td></tr><tr><td>A00.FR.315</td><td>A00.FR.314 AND The CSMS detects that the Charging Station only allows connections using an older version of TLS, or only allows SSL</td><td>The CSMS SHALL terminate the connection.</td></tr><tr><td>A00.FR.316</td><td>A00.FR.314 AND The Charging Station detects that the CSMS only allows connections using an older version of TLS, or only allows SSL</td><td>The Charging Station SHALL trigger an InvalidTLSVersion security event AND terminate the connection (See part 2 appendices for the full list of security events).NOTE: This is a critical security event that will need to be queued and sent to CSMS once a successful connection has 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.</td></tr><tr><td>A00.FR.317</td><td></td><td>TLS SHALL be implemented as in [4] or its successor standards without any modifications.</td></tr><tr><td>A00.FR.318</td><td></td><td>The CSMS SHALL support at least the following four cipher suites:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_GCM_SHA384Note: The CSMS will have to provide 2 different certificates to support both cipher suites. Also when using security profile 3, the CSMS should be capable of generating client side certificates for both cipher suites.</td></tr><tr><td>A00.FR.319</td><td></td><td>The Charging Station SHALL support at least the cipher suites:(TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256ANDTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384)OR(TLS_RSA_WITH_AES_128_GCM_SHA256ANDTLS_RSA_WITH_AES_256_GCM_SHA384)Note 1: TLS_RSA does not support forward secrecy, therefore TLS_ECDHE is RECOMMENDED. Furthermore, if the Charging Station detects an algorithm used that is not secure, it SHOULD trigger anInvalidTLSCipherSuite security event (See part 2 appendices for the full list of security events).Note 2: Please note that ISO15118-2 prescribes to implement the following cipher suites for the communication between EV and Charging Station:TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256</td></tr><tr><td>A00.FR.320</td><td></td><td>The Charging Station and CSMS SHALL NOT use cipher suites that use cryptographic primitives marked as unsuitable for legacy use in [1]. This will mean that when one (or more) of the cipher suites described in this specification becomes marked as unsuitable for legacy use, it SHALL NOT be used anymore.</td></tr><tr><td>A00.FR.321</td><td></td><td>The TLS Server and Client SHALL NOT use TLS compression methods to avoid compression side-channel attacks and to ensure interoperability as described in Section 6 of [10].</td></tr><tr><td>A00.FR.322</td><td>A00.FR.320 AND The CSMS detects that the Charging Station only allows connections using one of these suites</td><td>The CSMS SHALL terminate the connection.</td></tr><tr><td>A00.FR.323</td><td>A00.FR.320 AND The Charging Station detects that the CSMS only allows connections using one of these suites</td><td>The Charging Station SHALL trigger an InvalidTLSCipherSuite security event AND terminate the connection (See part 2 appendices for the full list of security events).</td></tr><tr><td>A00.FR.324</td><td>A00.FR.302</td><td>The CSMS SHALL validate that Charging Station identity and the Basic Authentication password match with username and password in the authorization header of the connection request.</td></tr></table>
+
+# 1.3.6. TLS with Client Side Certificates Profile - 3
+
+Table 17. Security Profile 3 - TLS with Client Side Certificates
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>TLS with Client Side Certificates</td></tr><tr><td>2</td><td>Profile No.</td><td>3</td></tr><tr><td>3</td><td>Description</td><td>In the TLS with Client Side Certificates profile, the communication channel is secured using Transport Layer Security (TLS). Both the Charging Station and CSMS authenticate themselves using certificates.</td></tr><tr><td>4</td><td>Charging Station Authentication</td><td>The CSMS authenticates the Charging Station via the TLS client certificate.</td></tr><tr><td>5</td><td>CSMS Authentication</td><td>The Charging Station authenticates the CSMS via the TLS server certificate.</td></tr><tr><td>6</td><td>Communication Security</td><td>The communication between Charging Station and CSMS is secured using TLS.</td></tr></table>
+
+
+Figure 4. Sequence Diagram: TLS with Client Side Certificates
+
+<table><tr><td>7</td><td>Remark(s)</td><td>N/a</td></tr></table>
+
+# 1.3.7. TLS with Client Side Certificates Profile - Requirements
+
+Table 18. Security Profile 3 - TLS with Client Side Certificates - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.401</td><td></td><td>The Charging Station SHALL authenticate itself to the CSMS using the Charging Station certificate.</td></tr><tr><td>A00.FR.402</td><td></td><td>The Charging Station certificate SHALL be used as a TLS client side certificate</td></tr><tr><td>A00.FR.403</td><td></td><td>The CSMS SHALL verify the certification path of the Charging Station's certificate according to the path validation rules established in Section 6 of [3]</td></tr><tr><td>A00.FR.404</td><td></td><td>The CSMS SHALL verify that the certificate is owned by the CSO (or an organization trusted by the CSO) by checking that the O(organizationName) RDN in the subject field of the certificate contains the CSO name.</td></tr><tr><td>A00.FR.405</td><td></td><td>The CSMS SHALL verify that the certificate belongs to this Charging Station by checking that the CN (commonName) RDN in the subject field of the certificate contains the unique serial number of the Charging Station (see Certificate Properties).</td></tr><tr><td>A00.FR.406</td><td>If the Charging Station certificate is not owned by the CSO, for instance immediately after installation</td><td>it is RECOMMENDED to update the certificate before continuing communication with the Charging Station (also see Installation)</td></tr><tr><td>A00.FR.407</td><td>NOT A00.FR.429 AND If the Charging Station does not own a valid certificate, or if the certification path is invalid</td><td>The CSMS SHALL terminate the connection.</td></tr><tr><td>A00.FR.408</td><td>A00.FR.407 OR A00.FR.429</td><td>It is RECOMMENDED to log a security eventInvalidChargingStationCertificate in the CSMS.</td></tr><tr><td>A00.FR.409</td><td></td><td>The CSMS SHALL act as the TLS server.</td></tr><tr><td>A00.FR.410</td><td></td><td>The CSMS SHALL authenticate itself by using the CSMS certificate as server side certificate.</td></tr><tr><td>A00.FR.411</td><td></td><td>The Charging Station SHALL verify the certification path of the CSMS's certificate according to the path validation rules established in Section 6 of [3].</td></tr><tr><td>A00.FR.412</td><td></td><td>The Charging Station SHALL verify that the commonName matches the CSMS's FQDN.</td></tr><tr><td>A00.FR.413</td><td>If the CSMS does not own a valid certificate, or if the certification path is invalid</td><td>The Charging Station SHALL trigger an InvalidCsmsCertificate security event (See part 2 appendices for the full list of security events).</td></tr><tr><td>A00.FR.414</td><td>A00.FR.413</td><td>The Charging Station SHALL terminate the connection.</td></tr><tr><td>A00.FR.415</td><td></td><td>The communication channel SHALL be secured using Transport Layer Security (TLS) [4].</td></tr><tr><td>A00.FR.416</td><td></td><td>The Charging Station and CSMS SHALL only use TLS v1.2 or above.</td></tr><tr><td>A00.FR.417</td><td></td><td>Both of these endpoints SHALL check the version of TLS used.</td></tr><tr><td>A00.FR.418</td><td>A00.FR.417ANDThe CSMS detects that the Charging Station only allows connections using an older version of TLS, or only allows SSL</td><td>The CSMS SHALL terminate the connection.</td></tr><tr><td>A00.FR.419</td><td>A00.FR.417ANDThe Charging Station detects that the CSMS only allows connections using an older version of TLS, or only allows SSL</td><td>The Charging Station SHALL trigger an InvalidTLSVersion security event AND terminate the connection (See part 2 appendices for the full list of security events).NOTE: This is a critical security event that will need to be queued and sent to CSMS once a connection has 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.</td></tr><tr><td>A00.FR.420</td><td></td><td>TLS SHALL be implemented as in [4] or its successor standards without any modifications.</td></tr><tr><td>A00.FR.421</td><td></td><td>The CSMS SHALL support at least the following four cipher suites:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_GCM_SHA384Note: The CSMS will have to provide 2 different certificates to support both cipher suites. Also when using security profile 3, the CSMS should be capable of generating client side certificates for both cipher suites.</td></tr><tr><td>A00.FR.422</td><td></td><td>The Charging Station SHALL support at least the cipher suites:(TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 AND TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384) OR (TLS_RSA_WITH_AES_128_GCM_SHA256 AND TLS_RSA_WITH_AES_256_GCM_SHA384)Note 1: TLS_RSA does not support forward secrecy, therefore TLS_ECDEHIES RECOMMENDED. Furthermore, if the Charging Station detects an algorithm used that is not secure, it SHOULD trigger an InvalidTLSCipherSuite security event (See part 2 appendices for the full list of security events).Note 2: Please note that ISO15118-2 prescribes to implement the following cipher suites for the communication between EV and Charging Station:TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256</td></tr><tr><td>A00.FR.423</td><td></td><td>The Charging Station and CSMS SHALL NOT use cipher suites that use cryptographic primitives marked as unsuitable for legacy use in [1]. This will mean that when one (or more) of the cipher suites described in this specification becomes marked as unsuitable for legacy use, it SHALL NOT be used anymore.</td></tr><tr><td>A00.FR.424</td><td></td><td>The TLS Server and Client SHALL NOT use TLS compression methods to avoid compression side-channel attacks and to ensure interoperability as described in Section 6 of [10].</td></tr><tr><td>A00.FR.425</td><td>A00.FR.424ANDIf the CSMS detects that the Charging Station only allows connections using one of these suites</td><td>The CSMS SHALL terminate the connection.</td></tr><tr><td>A00.FR.426</td><td>A00.FR.424ANDThe Charging Station detects that the CSMS only allows connections using one of these suites</td><td>The Charging Station SHALL trigger an InvalidTLSCipherSuite security event AND terminate the connection (See part 2 appendices for the full list of security events).</td></tr><tr><td>A00.FR.427</td><td></td><td>A unique Charging Station certificate SHALL be used for each Charging Station.</td></tr><tr><td>A00.FR.428</td><td></td><td>The Charging Station Certificate MAY be the same certificate as the SECC Certificate in ISO15118-2, used to set up a TLS connection between the Charging Station and an Electric Vehicle.</td></tr><tr><td>A00.FR.429</td><td>If Charging Station certificate has been expired ANDCSMS has been explicitly configured to accept a connection by this specific Charging Station with an expired certificate.</td><td>CSMS MAY accept this Charging Station in a BootNotification - Pending state (use case B02) after which it SHALL immediately execute A02 - Update Charging Station Certificate by request of CSMS to renew the certificate.</td></tr></table>
+
+# 1.4. Keys used in OCPP
+
+This section is normative.
+
+OCPP uses a number of public private key pairs for its security, see below Table. To manage the keys on the Charging Station, messages have been added to OCPP. Updating keys on the CSMS or at the manufacturer is out of scope for OCPP. If TLS with Client Side certificates is used, the Charging Station requires a "Charging Station certificate" for authentication against the CSMS.
+
+Table 19. Certificates used in the OCPP security specification
+
+<table><tr><td>Certificate</td><td>Private Key Stored At</td><td>Description</td></tr><tr><td>CSMS Certificate</td><td>CSMS</td><td>Key used to authenticate the CSMS.</td></tr><tr><td>Charging Station Certificate</td><td>Charging Station</td><td>Key used to authenticate the Charging Station.</td></tr><tr><td>Firmware Signing Certificate</td><td>Manufacturer</td><td>Key used to verify the firmware signature.</td></tr><tr><td>SECC Certificate</td><td>Charging Station</td><td>Certificate used by ISO15118-2 to set up a TLS connection between the Charging Station and an Electric Vehicle.</td></tr></table>
+
+# 1.4.1. Certificate Properties
+
+This section is normative.
+
+Table 20. Certificate Properties requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.501</td><td></td><td>All certificates SHALL use a private key that provides security equivalent to a symmetric key of at least 112 bits according to Section 5.6.1 of [17]. This is the key size that NIST recommends for the period 2011-2030.</td></tr><tr><td>A00.FR.502</td><td>A00.FR.501ANDRSA or DSA</td><td>This translates into a key that SHALL be at least 2048 bits long.</td></tr><tr><td>A00.FR.503</td><td>A00.FR.501ANDelliptic curve cryptography</td><td>This translates into a key that SHALL be at least 224 bits long.</td></tr><tr><td>A00.FR.504</td><td></td><td>For all cryptographic operations, only the algorithms recommended by BSI in [12], which are suitable for use in future systems, SHALL be used. This restriction includes the signing of certificates in the certificate hierarchy</td></tr><tr><td>A00.FR.505</td><td></td><td>For signing by the certificate authority RSA-PSS, or ECDSA SHOULD be used.</td></tr><tr><td>A00.FR.506</td><td></td><td>For computing hash values the SHA256 algorithm SHOULD be used.</td></tr><tr><td>A00.FR.507</td><td></td><td>The certificates SHALL be stored and transmitted in the X.509 format encoded in Privacy-Enhanced Mail (PEM) format.</td></tr><tr><td>A00.FR.508</td><td></td><td>All certificates SHALL include a serial number.</td></tr><tr><td>A00.FR.509</td><td></td><td>The subject field of the certificate SHALL contain the organization name of the certificate owner in the O (organizationName) RDN.</td></tr><tr><td>A00.FR.510</td><td></td><td>For the CSMS certificate, the subject field SHALL contain the FQDN of the endpoint of the server in the CN (commonName) RDN.</td></tr><tr><td>A00.FR.511</td><td></td><td>For the Charging Station certificate, the subject field SHALL contain a CN (commonName) RDN which consists of the unique serial number of the Charging Station. This serial number SHALL NOT be in the format of a URL or an IP address so that Charging Station certificates can be differentiated from CSMS certificates.Note: According to RFC 2818, if a subjectAltName extension of type dnsName is present, that must be used as the identity. This would be incompliant with OCPP and ISO 15118. Therefore it SHOULD NOT be used in Charging Station and CSMS certificates.It is allowed to use the subjectAltName extension of type dnsName for a CSMS, when the CSMS has multiple network paths to reach it (for example, via a private APN + VPN using its IP address in the VPN and via public Internet using a named URL).</td></tr><tr><td>A00.FR.512</td><td></td><td>For all certificates the X.509 Key Usage extension [19] SHOULD be used to restrict the usage of the certificate to the operations for which it will be used.</td></tr><tr><td>A00.FR.513</td><td></td><td>If the Charging Station Certificate is also used as SECC Certificate in the ISO 15118 protocol, the certificate SHOULD also meet the requirements in ISO15118-2.</td></tr><tr><td>A00.FR.514</td><td></td><td>For all certificates it is strongly RECOMMENDED NOT to use the X.509 Extended Key Usage extension, to be compatible with the ISO 15118 standard. There are alternative mechanisms available.</td></tr></table>
+
+# 1.4.2. Certificate Hierarchy
+
+This section is normative.
+
+The OCPP protocol supports the use of two separate certificate hierarchies:
+
+1. The Charging Station Operator hierarchy which contains the CSMS, and Charging Station certificates.
+2. The Manufacturer hierarchy which contains the Firmware Signing certificate.
+
+The CSMS can update the CSO root certificates stored on the Charging Station using the InstallCertificateRequest message.
+
+Table 21. Certificate Hierarchy requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.601</td><td></td><td>The Charging Station Operator MAY act as a certificate authority for the Charging Station Operator hierarchy</td></tr><tr><td>A00.FR.602</td><td>A00.FR.601</td><td>The Charging Station Operator MAY for instance follow the certificate hierarchy described in Appendices E and F of ISO15118-2 and use the CSO Sub-CA 2 certificate to sign the CSMS and Charging Station certificates. This could give the advantage that the online verification of Charging Station client side certificates can be done within the Charging Station Operator's networks, simplifying the network architecture.</td></tr><tr><td>A00.FR.603</td><td></td><td>The private keys belonging to the CSO root certificates MUST be well protected.</td></tr><tr><td>A00.FR.604</td><td></td><td>As the Manufacturer is usually a separate organization from the Charging Station Operator, a trusted third party SHOULD be used as a certificate authority. This is essential to have non-repudiation of firmware images.</td></tr></table>
+
+# 1.5. Certificate Revocation
+
+This section is normative.
+
+In some cases a certificate may become invalid prior to the expiration of the validity period. Such cases include changes of the organization name, or the compromise or suspected compromise of the certificate's private key. In such cases, the certificate needs to be revoked or indicate it is no longer valid. The revocation of the certificate does not mean that the connection needs to be closed as the the connection can stay open longer than 24 hours.
+
+Different methods are recommended for certificate revocation, see below Table.
+
+Table 22. Recommended revocation methods for the different certificates.
+
+<table><tr><td>Certificate</td><td>Revocation</td></tr><tr><td>CSMS certificate</td><td>Fast expiration</td></tr><tr><td>Charging Station certificate</td><td>Online verification</td></tr><tr><td>Firmware Signing certificate</td><td>Online verification</td></tr></table>
+
+Table 23. Certificate Revocation requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.701</td><td></td><td>Fast expiration SHOULD be used to revoke the CSMS certificate. (See Note 1)</td></tr><tr><td>A00.FR.702</td><td></td><td>The CSMS SHOULD use online certificate verification to verify the validity of the Charging Station certificates.</td></tr><tr><td>A00.FR.703</td><td></td><td>It is RECOMMENDED that a separate certificate authority server is used to manage the certificates.</td></tr><tr><td>A00.FR.704</td><td>A00.FR.703</td><td>This server SHOULD also keep track of which certificates have been revoked.</td></tr><tr><td>A00.FR.705</td><td></td><td>The CSMS SHALL verify the validity of the certificate with the certificate authority server. (See Note 2)</td></tr><tr><td>A00.FR.707</td><td></td><td>Prior to providing the certificate for firmware validation to the Charging Station, the CSMS SHOULD validate both, the certificate and the signed firmware update.</td></tr></table>
+
+Note 1: With fast expiration, the certificate is only valid for a short period, less than 24 hours. After that the server needs to request a new certificate from the Certificate Authority, which may be the CSO itself (see section Certificate Hierarchy). This prevents the Charging Stations from needing to implement revocation lists or online certificate verification. This simplifies the implementation of certificate management at the Charging Station and reduces communication costs at the Charging Station side. By requiring fast expiration, if the certificate is compromised, the impact is reduced to only a short period.
+
+When the certificate chain should become compromised, attackers could used forged certificates to trick a Charging Station to connect to a "fake" CSMS. By using fast expiration, the time a Charging Station is vulnerable is greatly reduced.
+
+The Charging Station always communicates with the Certificate Authority through the CSMS, this way, if the Charging Station is compromised, the Charging Station cannot attack the CA directly.
+
+Note 2: This allows for immediate revocation of Charging Station certificates. Revocation of Charging Station certificates will happen for instance when a Charging Station is removed. This is more common than revoking the CSMS certificate, which is normally only done when it is compromised.
+
+# 1.6. Installation
+
+This section is normative.
+
+Unique credentials should be used to authenticate each Charging Station to the CSMS, whether they are the password used for HTTP Basic Authentication (see Charging Station Authentication) or the Charging Station certificate. These unique credentials have to be put on the Charging Station at some point during manufacturing or installation.
+
+Table 24. Certificate Installation requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.801</td><td></td><td>It is RECOMMENDED that the manufacturer initializes the Charging Station with unique credentials during manufacturing.</td></tr><tr><td>A00.FR.802</td><td>A00.FR.801</td><td>The credentials SHOULD be generated using a cryptographic random number generator, and installed in a secure environment.</td></tr><tr><td>A00.FR.803</td><td>A00.FR.801</td><td>They SHOULD be sent to the CSO over a secure channel, so that the CSO can import them in the CSMS</td></tr><tr><td>A00.FR.804</td><td>If Charging Station certificates are used.</td><td>The manufacturer MAY sign these using their own certificate.</td></tr><tr><td>A00.FR.805</td><td>A00.FR.804</td><td>It is RECOMMENDED that the CSO immediately updates the credentials after installation using the methods described in Section A01 - Update Charging Station Password for HTTP Basic Authentication or A02 - Update Charging Station Certificate by request of CSMS.</td></tr><tr><td>A00.FR.806</td><td>Before the 'factory credentials' have been updated</td><td>The CSMS MAY restrict the functionality that the Charging Station can use. The CSMS can use the BootNotification state: Pending for this. During the Pending state, the CSMS can update the credentials.</td></tr><tr><td>A00.FR.807</td><td>A00.FR.804 AND Charging Station manufacturer certificate has expired</td><td>The CSMS MAY accept a connection by Charging Station in a Pending state after the BootNotification and immediately execute use case A02 - Update Charging Station Certificate by request of CSMS to install a new valid CSO certificate.</td></tr></table>
+
+# 2. Use cases & Requirements
+
+# A01 - Update Charging Station Password for HTTP Basic Authentication
+
+Table 25. A01 - Password Management
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Update Charging Station Password for HTTP Basic Authentication</td></tr><tr><td>2</td><td>ID</td><td>A01</td></tr><tr><td></td><td>Functional block</td><td>A. Security</td></tr><tr><td>3</td><td>Objective(s)</td><td>This use case defines how to use the BasicAuthPassword, the password used to authenticate Charging Stations in the Basic and TLS with Basic Authentication security profiles.</td></tr><tr><td>4</td><td>Description</td><td>To enable the CSMS to configure a new password for HTTP Basic Authentication, the CSMS can send a new value for the BasicAuthPassword Configuration Variable.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a SetVariablesRequest( ComponentName=SecurityCtrlr, VariableName=BasicAuthPassword) to the Charging Station.
+2. The Charging Station responds with SetVariablesResponse and the status Accepted.
+3. The Charging Station disconnects its current connection. (Storing any queued messages)
+4. The Charging Station connects to the CSMS with the new password.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Security Profile: Basic Security Profile or TLS with Basic Authentication in use.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station has reconnected to the CSMS with the new password.
+Failure postcondition:
+If the Charging Station responds to the SetVariablesRequest with a SetVariablesResponse with a status other than Accepted, the Charging Station will keep using the old credentials. The CSMS might treat the Charging Station differently, e.g. by not accepting the Charging Station's boot notifications.</td></tr></table>
+
+
+Figure 5. Update Charging Station Password for HTTP Basic Authentication (happy flow)
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# A01 - Update Charging Station Password for HTTP Basic Authentication - Requirements
+
+Table 26. A01 - Update Charging Station Password for HTTP Basic Authentication - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A01.FR.01</td><td></td><td>The password SHALL be stored in the configuration variable BasicAuthPassword.</td></tr><tr><td>A01.FR.02</td><td></td><td>To set a Charging Station's basic authorization password via OCPP, the CSMS SHALL send the Charging Station a SetVariablesRequest message with the BasicAuthPassword Configuration Variable.</td></tr><tr><td>A01.FR.03</td><td>A01.FR.02ANDThe Charging Station responds to this SetVariablesRequest with a SetVariablesResponse with status Accepted.</td><td>The CSMS SHALL assume that the authorization key change was successful, and no longer accept the credentials previously used by the Charging Station.</td></tr><tr><td>A01.FR.04</td><td>A01.FR.02ANDThe Charging Station responds to this SetVariablesRequest with a SetVariablesResponse with status other than Accepted</td><td>The CSMS SHALL assume that the Charging Station has NOT changed the password. Therefore the CSMS SHALL keep accepting the old credentials.</td></tr><tr><td>A01.FR.05</td><td>A01.FR.04</td><td>While the CSMS SHALL still accepts a connection from the Charging Station, it MAY restrict the functionality that the Charging Station can use. The CSMS can use the BootNotification state: Pending for this. During the Pending state, the CSMS can for example retry to update the credentials.</td></tr><tr><td>A01.FR.06</td><td></td><td>Different passwords SHOULD be used for different Charging Stations.</td></tr><tr><td>A01.FR.07</td><td></td><td>Passwords SHOULD be generated randomly to ensure that the passwords have sufficient entropy.</td></tr><tr><td>A01.FR.08</td><td></td><td>the CSMS SHOULD only store salted password hashes, not the passwords themselves.</td></tr><tr><td>A01.FR.09</td><td></td><td>the CSMS SHOULD NOT put the passwords in clear-text in log files or debug information. In this way, if the CSMS is compromised not all Charging Station password will be immediately compromised.</td></tr><tr><td>A01.FR.10</td><td></td><td>On the Charging Station the password needs to be stored in clear-text. Extra care SHOULD be taken into storing it securely. Definitions of mechanisms how to securely store the credentials are however not in scope of the OCPP Security Profiles.</td></tr><tr><td>A01.FR.11</td><td>A01.FR.02</td><td>The Charging Station SHALL log the change of an BasicAuthPassword in the Security log.</td></tr><tr><td>A01.FR.12</td><td>A01.FR.11</td><td>The Charging Station SHALL NOT disclose the content of the BasicAuthPassword in its logging. This is to prevent exposure of key material to persons that may have access to a diagnostics file.</td></tr></table>
+
+# A02 - Update Charging Station Certificate by request of CSMS
+
+Table 27. A02 - Update Charging Station Certificate by request of CSMS
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Update Charging Station Certificate by request of CSMS</td></tr><tr><td>2</td><td>ID</td><td>A02</td></tr><tr><td></td><td>Functional block</td><td>A. Security</td></tr><tr><td>3</td><td>Objective(s)</td><td>To facilitate the management of the Charging Station client side certificate, a certificate update procedure is provided.</td></tr><tr><td>4</td><td>Description</td><td>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 "Seccld".</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, Certificate Authority Server</td></tr><tr><td></td><td>Scenario description</td><td>SignChargingStationCertificate</td></tr><tr><td></td><td></td><td>1. The CSMS requests the Charging Station to update its certificate using the TriggerMessageRequest with the requestedMessage field set to SignChargingStationCertificate.</td></tr><tr><td></td><td></td><td>2. The Charging Station responds with TriggerMessageResponse</td></tr><tr><td></td><td></td><td>3. The Charging Station generates a new public / private key pair.</td></tr><tr><td></td><td></td><td>4. The Charging Station sends a SignCertificateRequest to the CSMS containing the certificateType = ChargingStationCertificate.</td></tr><tr><td></td><td></td><td>5. The CSMS responds with SignCertificateResponse, with status Accepted.</td></tr><tr><td></td><td></td><td>6. The CSMS forwards the CSR to the Certificate Authority Server.</td></tr><tr><td></td><td></td><td>7. Certificate Authority Server signs the certificate.</td></tr><tr><td></td><td></td><td>8. The Certificate Authority Server returns the Signed Certificate to the CSMS.</td></tr><tr><td></td><td></td><td>9. The CSMS sends CertificateSignedRequest to the Charging Station.</td></tr><tr><td></td><td></td><td>10. The Charging Station verifies the Signed Certificate.</td></tr><tr><td></td><td></td><td>11. The Charging Station responds with CertificateSignedResponse to the CSMS with the status Accepted or Rejected.</td></tr><tr><td></td><td>Alternative scenario</td><td>SignV2GCertificate</td></tr><tr><td></td><td></td><td>1. CSMS requests information about component ISO15118Ctrl by sending a GetReportRequest for componentVariablecomponent = "ISO15118Ctrl" and componentVariable variable = "Seccd".</td></tr><tr><td></td><td></td><td>2. For each unique Seccd that is returned:</td></tr><tr><td></td><td></td><td>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 eveset to the EVSE of the ISO15118Ctrl. (If ISO15118Ctrl only exists as one component at toplevel, then evese can be omitted.)</td></tr><tr><td></td><td></td><td>2.2. The Charging Station responds with TriggerMessageResponse</td></tr><tr><td></td><td></td><td>2.3. The Charging Station generates a new public / private key pair.</td></tr><tr><td></td><td></td><td>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 Seccd.</td></tr><tr><td></td><td></td><td>2.5. CSMS responds with SignCertificateResponse, with status Accepted.</td></tr><tr><td></td><td></td><td>2.6. The CSMS forwards the CSR to the Certificate Authority Server.</td></tr><tr><td></td><td></td><td>2.7. Certificate Authority Server signs the certificate.</td></tr><tr><td></td><td></td><td>2.8. The Certificate Authority Server returns the Signed Certificate to the CSMS.</td></tr><tr><td></td><td></td><td>2.9. The CSMS sends CertificateSignedRequest to the Charging Station.</td></tr><tr><td></td><td></td><td>2.10. The Charging Station verifies the Signed Certificate.</td></tr><tr><td></td><td></td><td>2.11. The Charging Station responds with CertificateSignedResponse to the CSMS with the status Accepted or Rejected.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The standard configuration variable "OrganizationName" MUST be set. For SignV2GCertificate the variable ISO15118Ctrl.Seccd must be set.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:</td></tr><tr><td></td><td></td><td>New Client Side certificate installed in the Charging Station.</td></tr><tr><td></td><td></td><td>Failure postcondition:</td></tr><tr><td></td><td></td><td>New Client Side certificate is rejected and discarded.</td></tr></table>
+
+
+Figure 6. Update Charging Station Certificate
+
+<table><tr><td>7</td><td>Error handling</td><td>The CSMS accepts the CSR request from the Charging Station, before forwarding it to the CA. But when the CA cannot be reached, or rejects the CSR, the Charging Station will never known. The CSMS may do some checks on the CSR, but cannot do all the checks that a CA does, and it does not prevent connection timeout to the CA. When something like this goes wrong, either the CA is offline or the CSR send by the Charging Station is not correct, according to the CA. In both cases this is something an operator at the CSO needs to be notified of. The operator then needs to investigate the issue. When resolved, the operator can re-run A02. It is NOT RECOMMENDED to let the Charging Station retry when the certificate is not send within X minutes or hours. When the CSR is incorrect, that will not be resolved automatically. It is possible that only a new firmware will fix this.</td></tr><tr><td>8</td><td>Remark(s)</td><td>The Charging Station Operator may act as a certificate authority for the Charging Station Operator hierarchy.
+The applicable Certification Authority SHALL check the information in the CSR.
+If it is correct, the Certificate Authority SHALL sign the CSR, send it to the CSO, the CSO sends it back to the Charging Station in the CertificateSignedRequest message.
+The certificate authority SHOULD implement strong measures to keep the certificate signing private keys secure.
+Even though the messages CertificateSignedRequest (see use cases A02 and A03) and InstallCertificateRequest (use case M05 - Install CA Certificate in a Charging Station) are both used to send certificates, their purposes are different. CertificateSignedRequest is used to return the Charging Stations own public certificate and V2G certificate(s) signed by a Certificate Authority. InstallCertificateRequest is used to install Root certificates.
+For V2G certificate handling see use cases M03 - Retrieve list of available certificates from a Charging Station, M04 - Delete a specific certificate from a Charging Station and M06 - Get Charging Station Certificate status.</td></tr></table>
+
+# A02 - Update Charging Station Certificate by request of CSMS - Requirements
+
+Table 28. A02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A02.FR.01</td><td></td><td>A key update SHOULD be performed after installation of the Charging Station, to change the key from the one initially provisioned by the manufacturer (possibly a default key).</td></tr><tr><td>A02.FR.02</td><td>After sending a TriggerMessageResponse.</td><td>The Charging Station SHALL generate a new public / private key pair using one of the key generation functions described in Section 4.2.1.3 of [16].</td></tr><tr><td>A02.FR.03</td><td>A02.FR.02</td><td>The Charging Station SHALL send the public key in form of a Certificate Signing Request (CSR) as described in RFC 2986 [22] and then PEM encoded, using the SignCertificateRequest message.</td></tr><tr><td>A02.FR.04</td><td></td><td>The CSMS SHOULD NOT sign the certificate itself, but instead forwards the CSR to a dedicated certificate authority server managing the certificates for the Charging Station infrastructure. The dedicated authority server MAY be operated by the CSO.</td></tr><tr><td>A02.FR.05</td><td></td><td>The private key generated by the Charging Station during the key update process SHALL NOT leave the Charging Station at any time, and SHALL NOT be readable via OCPP or any other (remote) communication connection.</td></tr><tr><td>A02.FR.06</td><td></td><td>The Charging Station SHALL verify the validity of the signed certificate in the CertificateSignedRequest message, checking at least the period when the certificate is valid, the properties in Certificate Properties, and that it is part of the Charging Station Operator certificate hierarchy as described in Certificate Hierarchy.</td></tr><tr><td>A02.FR.07</td><td>If the certificate is not valid.</td><td>The Charging Station SHALL respond to the CertificateSignedRequest with status Rejected AND discard the certificate AND trigger an InvalidChargingStationCertificate security event (See part 2 appendices for the full list of security events).</td></tr><tr><td>A02.FR.08</td><td></td><td>The Charging Station SHALL switch to the new certificate as soon as the current date and time is after the 'Not valid before' field in the certificate (e.g. by closing the websocket and TLS connection and reconnecting with the new certificate).</td></tr><tr><td>A02.FR.09</td><td>If the Charging Station contains more than one valid certificate of the ChargingStationCertificate type.</td><td>The Charging Station SHALL use the newest certificate, as measured by the start of the validity period.</td></tr><tr><td>A02.FR.10</td><td>A02.FR.09 AND When the Charging Station has validated that the new certificate works</td><td>The Charging Station MAY discard the old certificate. It is RECOMMENDED to store old certificates for one month, as fallback.</td></tr><tr><td>A02.FR.11</td><td>Upon receipt of a SignCertificateRequest AND It is able to process the request</td><td>The CSMS SHALL set status to Accepted in the SignCertificateResponse.</td></tr><tr><td>A02.FR.12</td><td>Upon receipt of a SignCertificateRequest AND It is NOT able to process the request</td><td>The CSMS SHALL set status to Rejected in the SignCertificateResponse.</td></tr><tr><td>A02.FR.13</td><td>When using different certificates for 15118 connections and the Charging Station to CSMS connection</td><td>The Charging Station SHALL set the certificateType field in the SignCertificateRequest to the certificate for which the update was triggered.</td></tr><tr><td>A02.FR.14</td><td>When receiving a SignCertificateRequest with certificateType included</td><td>It is RECOMMENDED for the CSMS to set the certificateType field in the CertificateSignedRequest to the type of certificate in the SignCertificateRequest.</td></tr><tr><td>A02.FR.15</td><td>If the Charging Station contains more than one valid V2G certificate, derived from the same root certificate.</td><td>The Charging Station SHALL use the newest certificate, as measured by the start of the validity period.</td></tr><tr><td>A02.FR.16</td><td>If the configuration variable MaxCertificateChainSize is implemented AND The Charging Station receives a CertificateSignedRequest message with a certificate (chain) with a size that exceeds the set value configured at MaxCertificateChainSize</td><td>The Charging Station SHALL respond with a CertificateSignedResponse message with status Rejected.</td></tr><tr><td>A02.FR.17</td><td>When the CSMS accepted the SignCertificateRequest for a CSR AND the Charging Station did not yet receive a CertificateSignedRequest for this CSR AND the number of seconds configured at CertSigningWaitMinimum has expired</td><td>The Charging Station SHALL send a new SignCertificateRequest for the CSR. Optionally, this CSR MAY be for a newly generated key pair.</td></tr><tr><td>A02.FR.18</td><td>A02.FR.17</td><td>The Charging Station SHALL double the previous back-off time, starting with the number of seconds configured at CertSigningWaitMinimum, every time the back-off time expires without having received the CertificateSignedRequest for this CSR.</td></tr><tr><td>A02.FR.19</td><td>A02.FR.18 AND The maximum number of increments is reached</td><td>The Charging Station SHALL stop resending the SignCertificateRequest, until it is requested by the CSMS via a TriggerMessageRequest for SignChargingStationCertificate, SignV2GCertificate or SignCombinedCertificate.</td></tr><tr><td>A02.FR.20</td><td>A02.FR.07</td><td>The Charging Station SHALL NOT initiate the back-off mechanism and send the SignCertificateRequest, until this is requested by the CSMS via a TriggerMessageRequest for SignChargingStationCertificate, SignV2GCertificate or SignCombinedCertificate.</td></tr><tr><td>A02.FR.21</td><td>When the Charging Station receives a SignCertificateResponse with status Rejected, in response to a SignCertificateRequest with certificateType V2GCertificate</td><td>It is RECOMMENDED to turn off ISO15118PnCEnabled until the Charging Station has been rebooted.</td></tr></table>
+
+# A03 - Update Charging Station Certificate initiated by the Charging Station
+
+Table 29. A03 - Update Charging Station Certificate initiated by the Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Update Charging Station Certificate initiated by the Charging Station</td></tr><tr><td>2</td><td>ID</td><td>A03</td></tr><tr><td></td><td>Functional block</td><td>A. Security</td></tr><tr><td>3</td><td>Objective(s)</td><td>To facilitate the management of the Charging Station client side certificate, a certificate update procedure is provided.</td></tr><tr><td>4</td><td>Description</td><td>The Charging Station detects that the certificate (ChargingStationCertificate or V2GCertificate for 15118) it is using will expire in one month. The Charging Station initiates the process to update its key using SignCertificateRequest, indicating the requested certificate in the CertificateSigningUse field.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, Certificate Authority Server</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station detects that the Charging Station certificate is due to expire.
+2. The Charging Station generates a new public / private key pair.
+3. The Charging Station sends a SignCertificateRequest to the CSMS containing the applicable CertificateSigningUse.
+4. The CSMS responds with a SignCertificateResponse, with status Accepted.
+5. The CSMS forwards the CSR to the Certificate Authority Server.
+6. Certificate Authority Server signs the certificate.
+7. The Certificate Authority Server returns the Signed Certificate to the CSMS.
+8. The CSMS sends a CertificateSignedRequest to the Charging Station.
+9. The Charging Station verifies the Signed Certificate.
+10. The Charging Station responds with a CertificateSignedResponse to the CSMS with the status Accepted or Rejected.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The standard configuration variable OrganizationName MUST be set.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+New Client Side certificate installed in the Charging Station.
+Failure postcondition:
+New Client Side certificate is rejected and discarded.</td></tr></table>
+
+
+Figure 7. Update Charging Station Certificate initiated by Charging Station
+
+<table><tr><td>7</td><td>Error handling</td><td>The CSMS accepts the CSR request from the Charging Station, before forwarding it to the CA. But when the CA cannot be reached, or rejects the CSR, the Charging Station will never known. The CSMS may do some checks on the CSR, but cannot do all the checks that a CA does, and it does not prevent connection timeout to the CA. When something like this goes wrong, either the CA is offline or the CSR send by the Charging Station is not correct, according to the CA. In both cases this is something an operator at the CSO needs to be notified of. The operator then needs to investigate the issue. When resolved, the operator can re-run A02.
+It is NOT RECOMMENDED to let the Charging Station retry when the certificate is not send within X minutes or hours. When the CSR is incorrect, that will not be resolved automatically. It is possible that only a new firmware will fix this.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Same remarks as in A02 - Update Charging Station Certificate by request of CSMS apply.</td></tr></table>
+
+# A03 - Update Charging Station Certificate initiated by the Charging Station - Requirements
+
+Table 30. A03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A03.FR.01</td><td></td><td>A key update MAY be performed after installation of the Charging Station, to change the key from the one initially provisioned by the manufacturer (possibly a default key).</td></tr><tr><td>A03.FR.02</td><td>When the Charging Station detects that the current Charging Station certificate will expire in one month.</td><td>The Charging Station SHALL generate a new public / private key pair using one of the key generation functions described in Section 4.2.1.3 of [16].</td></tr><tr><td>A03.FR.03</td><td>A03.FR.02</td><td>The Charging Station SHALL send the public key in form of a Certificate Signing Request (CSR) as described in RFC 2986 [22] and then PEM encoded, using the SignCertificateRequest message.</td></tr><tr><td>A03.FR.04</td><td></td><td>The CSMS SHOULD NOT sign the certificate itself, but instead forwards the CSR to a dedicated certificate authority server managing the certificates for the Charging Station infrastructure. The dedicated authority server MAY be operated by the CSO.</td></tr><tr><td>A03.FR.05</td><td></td><td>The private key generated by the Charging Station during the key update process SHALL NOT leave the Charging Station at any time, and SHALL NOT be readable via OCPP or any other (remote) communication connection.</td></tr><tr><td>A03.FR.06</td><td></td><td>The Charging Station SHALL verify the validity of the signed certificate in the CertificateSignedRequest message, checking at least the period when the certificate is valid, the properties in Certificate Properties, and that it is part of the Charging Station Operator certificate hierarchy as described in Certificate Hierarchy.</td></tr><tr><td>A03.FR.07</td><td>If the certificate is not valid.</td><td>The Charging Station SHALL respond to the CertificateSignedRequest with status Rejected AND discard the certificate AND trigger an InvalidChargingStationCertificate security event (See part 2 appendices for the full list of security events).</td></tr><tr><td>A03.FR.08</td><td></td><td>The Charging Station SHALL switch to the new certificate as soon as the current date and time is after the 'Not valid before' field in the certificate (e.g. by closing the websocket and TLS connection and reconnecting with the new certificate).</td></tr><tr><td>A03.FR.09</td><td>If the Charging Station contains more than one valid certificate of the ChargingStationCertificate type.</td><td>The Charging Station SHALL use the newest certificate, as measured by the start of the validity period.</td></tr><tr><td>A03.FR.10</td><td>A03.FR09 AND When the Charging Station has validated that the new certificate works</td><td>The Charging Station MAY discard the old certificate. It is RECOMMENDED to store old certificates for one month, as fallback.</td></tr><tr><td>A03.FR.11</td><td>Upon receipt of a SignCertificateRequest AND It is able to process the request</td><td>The CSMS SHALL set status to Accepted in the SignCertificateResponse.</td></tr><tr><td>A03.FR.12</td><td>Upon receipt of a SignCertificateRequest AND It is NOT able to process the request</td><td>The CSMS SHALL set status to Rejected in the SignCertificateResponse.</td></tr><tr><td>A03.FR.13</td><td>When using different certificates for 15118 connections and the Charging Station to CSMS connection</td><td>The Charging Station SHALL include the certificateType field in the SignCertificateRequest to specify which certificate it wants to update.</td></tr><tr><td>A03.FR.14</td><td>When receiving a SignCertificateRequest with certificateType included</td><td>It is RECOMMENDED for the CSMS to set the certificateType field in the CertificateSignedRequest to the type of certificate in the SignCertificateRequest.</td></tr><tr><td>A03.FR.15</td><td>If the Charging Station contains more than one valid V2G certificate, derived from the same root certificate.</td><td>The Charging Station SHALL use the newest certificate, as measured by the start of the validity period.</td></tr><tr><td>A03.FR.16</td><td>If the configuration variable MaxCertificateChainSize is implemented AND The Charging Station receives a CertificateSignedRequest message with a certificate (chain) with with a size that exceeds the set value configured at MaxCertificateChainSize</td><td>The Charging Station SHALL respond with a CertificateSignedResponse message with status Rejected .</td></tr><tr><td>A03.FR.17</td><td>When the CSMS accepted the SignCertificateRequest for a CSR AND the Charging Station did not yet receive a CertificateSignedRequest for this CSR AND the number of seconds configured at CertSigningWaitMinimum has expired</td><td>The Charging Station SHALL send a new SignCertificateRequest for the CSR. Optionally, this CSR MAY be for a newly generated key pair.</td></tr><tr><td>A03.FR.18</td><td>A03.FR.17</td><td>The Charging Station SHALL double the previous back-off time, starting with the number of seconds configured at CertSigningWaitMinimum, every time the back-off time expires without having received the CertificateSignedRequest for this CSR.</td></tr><tr><td>A03.FR.19</td><td>A03.FR.18 AND The maximum number of increments is reached</td><td>The Charging Station SHALL stop resending the SignCertificateRequest, until it is requested by the CSMS via a TriggerMessageRequest for SignChargingStationCertificate, SignV2GCertificate or SignCombinedCertificate.</td></tr></table>
+
+# A04 - Security Event Notification
+
+Table 31. A04 - Security Event Notification
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Security Event Notification</td></tr><tr><td>2</td><td>ID</td><td>A04</td></tr><tr><td></td><td>Functional block</td><td>A. Security</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS of critical security events.</td></tr><tr><td>4</td><td>Description</td><td>This use case allows the Charging Station to immediately inform the CSMS of changes in the system security.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. A critical security event happens.
+2. The Charging Station sends a SecurityEventNotificationRequest to the CSMS.
+3. The CSMS responds with SecurityEventNotificationResponse to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station successfully informs the CSMS of critical security events by sending a SecurityEventNotificationRequest to the CSMS.</td></tr></table>
+
+
+Figure 8. Security Event Notification
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>A list of security related events and their 'criticality' is provided in the Appendices (Appendix 1. Security Events)</td></tr></table>
+
+# A04 - Security Event Notification - Requirements
+
+Table 32. A04 - Security Event Notification - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>A04.FR.01</td><td>When a critical security event happens</td><td>The Charging Station SHALL inform the CSMS of the security events by sending a SecurityEventNotificationRequest to the CSMS.</td><td></td></tr><tr><td>A04.FR.02</td><td>A04.FR.01 AND the Charging Station is disconnected.</td><td>Security event notifications MUST be queued with a guaranteed delivery at the CSMS.</td><td></td></tr><tr><td>A04.FR.03</td><td>A04.FR.01</td><td>The CSMS SHALL confirm the receipt of the notification using the SecurityEventNotificationResponse message.</td><td></td></tr><tr><td>A04.FR.04</td><td>When a security event happens (also non-critical)</td><td>The Charging Station SHALL store the security event in a security log.</td><td>It is recommended to implement this log in a rolling format.</td></tr></table>
+
+# A05 - Upgrade Charging Station Security Profile
+
+Table 33. A05 - Upgrade Charging Station Security Profile
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Upgrade Charging Station Security Profile</td></tr><tr><td>2</td><td>ID</td><td>A05</td></tr><tr><td></td><td>Functional block</td><td>A. Security</td></tr><tr><td>3</td><td>Objective(s)</td><td>The CSO wants to increase the security of the OCPP connection between CSMS and a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>Use case when migrating from OCPP 1.6 without security profiles to OCPP 1.6 with security profiles or OCPP 2.0.1 Before migrating to a security profile the prerequisites, like installed certificates or password need to be configured.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sets a new value for the NetworkConfigurationPriority Configuration Variable via SetVariablesRequest, such that the NetworkConnectionProfile for the new (higher) security profile becomes first in the list and the existing connection profile becomes second in the list.
+2. The Charging Station responds with a SetVariablesResponse with status Accepted
+3. The CSMS sends a ResetRequest(OnIdle)
+4. The Charging Station reboots and connects via the new primary NetworkConnectionProfile</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The CSO ensures that a NetworkConnectionProfile has been set using (higher) security profile AND that the prerequisite(s) for going to a higher security profile are met before sending the command to change to a higher security profile.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station was successfully upgraded to a higher security profile.</td></tr></table>
+
+
+Figure 9. Upgrade Charging Station Security Profile
+
+Table 34. A05 - Upgrade Charging Station Security Profile
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>For security reasons it is not allowed to revert to a lower Security Profile using OCPP.</td></tr></table>
+
+# A05 - Upgrade Charging Station Security Profile - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A05.FR.02</td><td>The Charging Station receives SetVariablesRequest for NetworkConfigurationPriority containing a profile slot for a NetworkConnectionProfile with a 'securityProfile' value higher than the current value AND new value is 2 or 3 AND No valid CSMSRootCertificate installed</td><td>The Charging Station SHALL respond with SetVariablesResponse(Rejected), and not update the value for SecurityProfile and/or reconnect to the CSMS.</td></tr><tr><td>A05.FR.03</td><td>The Charging Station receives SetVariablesRequest for NetworkConfigurationPriority containing a profile slot for a NetworkConnectionProfile with a 'securityProfile' value higher than the current value AND new value is 3 AND No valid ChargingStationCertificate installed</td><td>The Charging Station SHALL respond with SetVariablesResponse(Rejected), and not update the value for SecurityProfile and/or reconnect to the CSMS.</td></tr><tr><td>A05.FR.04</td><td>The Charging Station receives SetVariablesRequest for NetworkConfigurationPriority containing profile slots for NetworkConnectionProfiles with a 'securityProfile' value equal to or higher than the current value AND all prerequisites are met</td><td>The Charging Station SHALL respond with SetVariablesResponse(Accepted)</td></tr><tr><td>A05.FR.05</td><td>A05.FR.04 AND After a reboot</td><td>The Charging Station SHALL begin connecting to the first entry of NetworkConfigurationPriority</td></tr><tr><td>A05.FR.06</td><td>A05.FR.05 AND The Charging Station successfully connected to the CSMS using the (new) NetworkConnectionProfile</td><td>The Charging Station SHALL update the value of the configuration variable SecurityProfile AND it SHALL remove all NetworkConnectionProfiles with a lower securityProfile than stored at SecurityProfile AND update NetworkConfigurationPriority accordingly.</td></tr><tr><td>A05.FR.07</td><td>A05.FR.06</td><td>The CSMS SHALL NOT allow the Charging Station to connect with a lower security profile anymore.</td></tr></table>
+
+# B. Provisioning
+
+# 1. Introduction
+
+This Functional Block describes all the functionalities that help a CSO provision their Charging Stations, allowing them on their network and retrieving configuration information from these Charging Stations. Additionally, it consists of the ability to retrieve information about the configuration of Charging Stations, make changes to the configuration etc. This chapter also covers resetting a Charging Station and migrating to a new NetworkConnectionProfile.
+
+# 1.1. Transactions before being accepted by a CSMS
+
+A Charging Station Operator MAY choose to configure a Charging Station to accept transactions before the Charging Station is accepted by a CSMS. Parties who want to implement this such behavior should realize that it is uncertain if those transactions can ever be delivered to the CSMS.
+
+After a restart (for instance due to a remote reset command, power outage, firmware update, software error etc.) the Charging Station MUST again contact the CSMS and SHALL send a BootNotification request. If the Charging Station fails to receive a BootNotificationResponse from the CSMS, and has no in-built non-volatile real-time clock hardware that has been correctly preset, the Charging Station may not have a valid date and time setting, making it difficult or even impossible to later determine the date and time of transactions.
+
+It might also be the case (e.g. due to configuration error) that the CSMS indicates a status other than Accepted for an extended period of time, or indefinitely.
+
+It is usually advisable to deny all charging services at a Charging Station if the Charging Station has never before been Accepted by the CSMS (using the current connection settings, URL, etc.) since users cannot be authenticated and running transactions could conflict with provisioning processes.
+
+If this is supported, this behaviour can be configured via the Configuration Variable: TxBeforeAcceptedEnabled.
+
+# 2. Use cases & Requirements
+
+# 2.1. Booting a Charging Station
+
+# B01 - Cold Boot Charging Station
+
+Table 35. B01 - Cold Boot Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Cold Boot Charging Station</td></tr><tr><td>2</td><td>ID</td><td>B01</td></tr><tr><td></td><td>Functional block</td><td>B. Provisioning</td></tr><tr><td>3</td><td>Objective(s)</td><td>The objective of this use case is to enable a Charging Station that is powering up to register itself at a CSMS and provide the right state information.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS can control which Charging Stations access it. To be able to control Charging Stations connecting to a CSMS, Charging Stations are required to send BootNotificationRequest. This request contains some general information about the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station is powered up.
+2. The Charging Station sends BootNotificationRequest to the CSMS.
+3. The CSMS returns with BootNotificationResponse with the status Accepted.
+4. Optional: The Charging Station sends StatusNotificationRequest with status Unavailable to the CSMS for each Connector.
+5. The Charging Station sends StatusNotificationRequest to the CSMS for each Connector. If the status was set to Unavailable or Reserved from the CSMS prior to the (re)boot, the Connector should return to this status, otherwise the status should be Available or, when it resumes a transaction that was ongoing, the status should be Occupied.
+6. Normal operational is resumed.
+7. The Charging Station sends HeartbeatRequest to the CSMS.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>B02 - Cold Boot Charging Station - Pending
+B03 - Cold Boot Charging Station - Rejected</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station is powered down.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station is in Idle status, and Accepted.
+Failure postcondition:
+The Charging Station received the status Rejected, B03 - Cold Boot Charging Station -Rejected applies.
+The Charging Station received the status Pending, B02 - Cold Boot Charging Station - Pending applies.</td></tr></table>
+
+
+Figure 10. Sequence Diagram: Cold Boot Charging Station
+
+<table><tr><td>7</td><td>Error handling</td><td>1. No initial establishment of connection of communication between the CSMS and Charging Station: Retry Connection with the CSMS.
+2. No response / time-out from the CSMS: The Charging Station resends BootNotificationRequest after a waiting interval. The Charging Station chooses this interval on its own (since it dit not get a BootNotificationResponse containing this interval), in a way that avoids flooding the CSMS with requests.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Multiple options for a self check are possible: some Charging Stations boot and send status notifications with Unavailable, then perform a check of all the hardware and send new StatusNotifications with status Available when the Charging Station is up and running. However, there is no required order for a self check and sending a BootNotificationRequest. A Charging Stations can also do the self check before sending a BootNotificationRequest and determine the status before a (mobile) network connection is established and a BootNotificationRequest is sent.
+When something is wrong with the Charging Station or EVSE, the status SHALL be set to Faulted. Reserved and Unavailable states persist after a reboot.</td></tr></table>
+
+# B01 - Cold Boot Charging Station - Requirements
+
+Table 36. B01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B01.FR.01</td><td>After start-up.</td><td>The Charging Station SHALL send BootNotificationRequest to the CSMS with information about its configuration.</td><td>Information: e.g. version, vendor, etc.</td></tr><tr><td>B01.FR.02</td><td>B01.FR.01 The CSMS has received BootNotificationRequest from the Charging Station.</td><td>The CSMS SHALL respond to indicate whether it will accept the Charging Station.</td><td></td></tr><tr><td>B01.FR.03</td><td>After a reboot (for instance due to a remote reset command, power outage, firmware update, software error etc.)</td><td>The Charging Station SHALL again connect to the CSMS and SHALL send a BootNotificationRequest each time it boots or reboots.</td><td></td></tr><tr><td>B01.FR.04</td><td>When the CSMS responds with BootNotificationResponse with the status Accepted AND interval > 0</td><td>The Charging Station SHALL adjust the heartbeat interval in accordance with the interval from the response message.</td><td></td></tr><tr><td>B01.FR.05</td><td>When the CSMS responds with BootNotificationResponse with the status Accepted.</td><td>The Charging Station SHALL send a StatusNotificationRequest for each Connector with its current state.</td><td></td></tr><tr><td>B01.FR.06</td><td>The Charging Station has received BootNotificationResponse. AND Charging Station is configured to use Heartbeats for time synchronization TimeSource</td><td>The Charging Station SHALL synchronize the Charging Station's internal clock with the supplied CSMS's current time.</td><td></td></tr><tr><td>B01.FR.07</td><td>When a Charging Station or an EVSE is set to status Unavailable by a Change Availability command.</td><td>The Unavailable status MUST be persistent across reboots.</td><td></td></tr><tr><td>B01.FR.08</td><td>Between the physical power-on/reboot and the successful completion of a BootNotification, where the CSMS returns Accepted or Pending.</td><td>The Charging Station SHALL NOT send any other OCPP requests to the CSMS (Except BootNotificationRequest). This includes cached OCPP messages that are still present in the Charging Station from prior sessions.</td><td>Refer to B02 - Cold Boot Charging Station - Pending (for example B02.FR.02) for more details on sending messages on the Pending status.</td></tr><tr><td>B01.FR.09</td><td>B01.FR.01</td><td>The Charging Station SHALL indicate the reason for sending the BootNotificationRequest message in the reason field.</td><td>For which reason to use, see BootReasonEnumType.</td></tr><tr><td>B01.FR.10</td><td>The Charging Station has received a BootNotificationResponse in which status is not Accepted AND the Charging Station sends a RPC Framework: CALL message that is NOT a BootNotificationRequest or a message triggered by one of the following messages: TriggerMessageRequest, GetBaseReportRequest, GetReportRequest.</td><td>The CSMS SHALL respond with RPC Framework: CALLERROR: SecurityError.</td><td>The Charging Station is not allowed to initiate sending other messages before being accepted.</td></tr><tr><td>B01.FR.11</td><td>B01.FR.01 AND Security profile 3 is used</td><td>The CSMS SHALL check the SerialNumber in the BootNotificationRequest against the Serial Number in the Certificate Common Name.</td><td></td></tr><tr><td>B01.FR.12</td><td>B01.FR.11 AND the SerialNumber in the BootNotificationRequest does NOT equal the Serial Number in the Certificate Common Name</td><td>The CSMS SHALL close WebSocket connection.</td><td></td></tr><tr><td>B01.FR.13</td><td>When an EVSE has been reserved</td><td>The Reserved state MUST be persistent across reboots.</td><td></td></tr></table>
+
+# B02 - Cold Boot Charging Station - Pending
+
+Table 37. B02 - Cold Boot Charging Station - Pending
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Cold Boot Charging Station - Pending</td></tr><tr><td>2</td><td>ID</td><td>B02</td></tr><tr><td></td><td>Functional block</td><td>B. Provisioning</td></tr><tr><td></td><td>Parent use case</td><td>B01 - Cold Boot Charging Station</td></tr><tr><td>3</td><td>Objective(s)</td><td>1. To inform the Charging Station that it is not yet accepted by the CSMS: Pending status.
+2. To give the CSMS a way to retrieve or set certain configuration information.
+3. To give the CSMS a way of limiting the load on the CSMS after e.g. a reboot of the CSMS.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes the behavior of the CSMS and a Charging Station when the Charging Station is informed by the CSMS that it is not yet accepted using the Pending status.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station is powered up.
+2. The Charging Station sends BootNotificationRequest to the CSMS.
+3. The CSMS responds with BootNotificationResponse with the status Pending.
+4. The CSMS then, is able to send messages to the Charging Station in order to change the configuration of the Charging Station.
+5. The Charging Station resends BootNotificationRequest after the number of seconds indicated by the interval field. (Interval from BootNotificationResponse)</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>1. The CSMS requires to set the Charging Station in Pending status.
+2. The Charging Station is starting up (i.e. powering up after being powered down).</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station is in Pending status.
+Failure postcondition:
+The Charging Station received the status Rejected, B03 - Cold Boot Charging Station -Rejected applies.</td></tr></table>
+
+
+Figure 11. Sequence Diagram: Cold Boot Charging Station - Pending
+
+<table><tr><td>7</td><td>Error handling</td><td>1. When no initial connection established between CSMS and Charging Station: Retry Connection to the CSMS and resend BootNotificationRequest.
+2. No response / time-out from the CSMS: The Charging Station resends BootNotificationRequest after a waiting interval. This waiting interval can be based on the interval from a previous BootNotificationResponse or chosen by the Charging Station itself. In the latter case, the Charging Station chooses this interval in a way that avoids flooding the CSMS with requests.</td></tr><tr><td>8</td><td>Remark(s)</td><td>When the CSMS returns with BootNotificationResponse with the status Accepted, B01 - Cold Boot Charging Station applies.</td></tr></table>
+
+# B02 - Cold Boot Charging Station - Pending - Requirements
+
+Table 38. B02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B02.FR.01</td><td>After the Charging Station received the Pending status.</td><td>The CSMS MAY send messages to retrieve information from the Charging Station (as described in use cases B06, B07, B08) or change its configuration by SetVariablesRequest (as described in use case B05). The Charging Station SHALL respond to these messages.</td><td>The Pending status can thus indicate that the CSMS wants to retrieve or set certain information on the Charging Station before it will accept the Charging Station.</td></tr><tr><td>B02.FR.02</td><td>While the CSMS has not yet responded to a BootNotificationRequest with an Accepted status in the BootNotificationResponse.</td><td>The Charging Station SHALL NOT send RPC Framework: CALL messages (Except BootNotificationRequest) to the CSMS, unless it has been instructed by the CSMS to do so, using one of the following messages: TriggerMessageRequest, GetBaseReportRequest, GetReportRequest.</td><td></td></tr><tr><td>B02.FR.03</td><td>While the CSMS has not yet responded to a BootNotificationRequest with an Accepted status in the BootNotificationResponse.</td><td>A Charging Station Operator MAY choose to configure a Charging Station to accept transactions and queue TransactionEventRequest messages to be sent to the CSMS</td><td>Parties who want to implement this behavior must realize that it is uncertain if those transactions can ever be delivered to the CSMS.</td></tr><tr><td>B02.FR.04</td><td>While the CSMS has not yet responded to a BootNotificationRequest with an Accepted status in the BootNotificationResponse.</td><td>A Charging Station SHALL NOT send BootNotificationRequest earlier than the value of the Interval field in BootNotificationResponse, unless requested to do so with TriggerMessageRequest.</td><td></td></tr><tr><td>B02.FR.05</td><td>While in Pending status AND receiving a RequestStartTransactionRequest or RequestStopTransactionRequest</td><td>The Charging Station SHALL respond with a RequestStartTransactionResponse or RequestStopTransactionResponse with status Rejected. (Even if the Charging Station is allowed to start transaction, see B02.FR.03. If the CSMS wants to use RequestStartTransaction etc. it SHALL first accept the Charging Station)</td><td></td></tr><tr><td>B02.FR.06</td><td>When the CSMS returns the Pending status</td><td>The communication channel SHALL NOT be closed by either the Charging Station or the CSMS.</td><td></td></tr><tr><td>B02.FR.07</td><td>If the interval in the BootNotificationResponse equals 0, and the status is other than Accepted,</td><td>The Charging Station SHALL choose a waiting interval on its own, in a way that avoids flooding the CSMS with requests.</td><td></td></tr><tr><td>B02.FR.08</td><td>If the interval in the BootNotificationResponse > 0, and the status is other than Accepted,</td><td>The Charging Station SHALL send a BootNotificationRequest after the set interval has past.</td><td></td></tr><tr><td>B02.FR.09</td><td>The Charging Station has received a BootNotificationResponse with status Pending AND the Charging Station sends a RPC Framework: CALL message that is NOT a BootNotificationRequest or a message triggered by one of the following messages: TriggerMessageRequest, GetBaseReportRequest, GetReportRequest.</td><td>The CSMS SHALL respond with RPC Framework:CALLERROR: SecurityError.</td><td>The Charging Station is not allowed to initiate sending other messages before being accepted.</td></tr></table>
+
+# B03 - Cold Boot Charging Station - Rejected
+
+Table 39. B03 - Cold Boot Charging Station - Rejected
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Cold Boot Charging Station - Rejected</td></tr><tr><td>2</td><td>ID</td><td>B03</td></tr><tr><td></td><td>Functional block</td><td>B. Provisioning</td></tr><tr><td></td><td>Parent use case</td><td>B01 - Cold Boot Charging Station</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the Charging Station that its not (yet) accepted by the CSMS: Rejected status.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes the behavior of the CSMS and a Charging Station, when the Charging Station is informed by the CSMS that it is not (yet) accepted using the Rejected status.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station is powered up.
+2. The Charging Station sends BootNotificationRequest to the CSMS.
+3 The CSMS responds with BootNotificationResponse with the status Rejected to the Charging Station.
+4. The Charging Station will resend BootNotificationRequest after the number of seconds indicated by the interval field. (Interval from BootNotificationResponse).</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>1. The CSMS requires to set the Charging Station in the Rejected status.
+2. The Charging Station is powered down.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station remains in the Rejected status.</td></tr></table>
+
+
+
+Figure 12. Sequence Diagram: Cold Boot Charging Station - Rejected
+Table 40. B03 - Requirements
+
+<table><tr><td>7</td><td>Error handling</td><td>When there is no response or a time-out from the CSMS: The Charging Station resends BootNotificationRequest after a waiting interval. This waiting interval can be based on the interval from a previous BootNotificationResponse or chosen by the Charging Station itself. In the latter case, the Charging Station chooses this interval in a way that avoids flooding the CSMS with requests.</td></tr><tr><td>8</td><td>Remark(s)</td><td>During the status Rejected, the Charging Station may no longer be reachable from the CSMS. The Charging Station MAY e.g. close its communication channel or shut down its communication hardware. Additionally, the CSMS MAY close the communication channel, for instance to free up system resources. It is advised not to accept any transactions until the BootNotification of the Charging Station has been accepted by the CSMS. See: Transactions before being accepted by a CSMS When the CSMS returns with BootNotificationResponse with the status Accepted, B01 - Cold Boot Charging Station applies.</td></tr></table>
+
+# B03 - Cold Boot Charging Station - Rejected - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B03.FR.01</td><td>If the Charging Station is configured to accept Transactions before being accepted by a CSMS</td><td>The Charging Station MAY allow locally authorized transactions.</td></tr><tr><td>B03.FR.02</td><td>If the CSMS returns the status Rejected. For example when a Charging Station is blacklisted.</td><td>The Charging Station SHALL NOT send any OCPP message to the CSMS until the retry interval has expired.</td></tr><tr><td>B03.FR.03</td><td>When the CSMS has Rejected the BootNotificationRequest from the Charging Station.</td><td>The CSMS SHALL NOT initiate any messages.</td></tr><tr><td>B03.FR.04</td><td>B03.FR.03</td><td>The Charging Station MAY close the connection until it needs to send the next BootNotificationRequest.</td></tr><tr><td>B03.FR.05</td><td>If the interval in the BootNotificationResponse equals 0, and the status is other than Accepted</td><td>The Charging Station SHALL choose a waiting interval on its own, in a way that avoids flooding the CSMS with requests.</td></tr><tr><td>B03.FR.06</td><td>If the interval in the BootNotificationResponse is greater than 0, and the status is other than Accepted</td><td>The Charging Station SHALL send a BootNotificationRequest after the set interval has passed.</td></tr><tr><td>B03.FR.07</td><td>B03.FR.03 AND Charging Station sends a message that is not a BootNotificationRequest</td><td>CSMS SHALL respond with RPC Framework: CALLERROR:SecurityError.</td></tr><tr><td>B03.FR.08</td><td>B03.FR.03 AND CSMS sends a message that is not a response to a BootNotificationRequest from Charging Station</td><td>Charging Station SHALL respond with RPC Framework:CALLERROR:SecurityError.</td></tr></table>
+
+# B04 - Offline Behavior Idle Charging Station
+
+Table 41. B04 - Offline Behavior Idle Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Offline Behavior Idle Charging Station</td></tr><tr><td>2</td><td>ID</td><td>B04</td></tr><tr><td></td><td>Functional block</td><td>B. Provisioning</td></tr><tr><td>3</td><td>Objective(s)</td><td>To attain stand-alone operation of the Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes that, in the event of unavailability of the communication, the Charging Station is designed to operate stand-alone. In that situation, the Charging Station is said to be Offline.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS or communication is unavailable.
+2. The Charging Station operates stand-alone.
+3. The connection is restored.
+4. If the Offline period exceeds the value of the OfflineThreshold Configuration Variable: the Charging Station sends a StatusNotificationRequest to the CSMS for each connector. Otherwise it only sends a StatusNotificationRequest for Connectors with a status change during the offline period.
+5. The Charging Station sends HeartbeatRequest to the CSMS.
+6. The CSMS responds with HeartbeatResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The BootNotification was previously accepted and the Charging Station is able to operate stand-alone.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>When connection is restored after a period of Offline behavior, the CSMS knows the Charging Stations' and EVSEs' state.</td></tr></table>
+
+
+Figure 13. Sequence Diagram: Offline Behavior Idle Charging Station
+
+<table><tr><td>7</td><td>Error handling</td><td>The offline situation is an non preferred mode of operation that needs to be handled by the Charging Station by trying to re-establish the connection.</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# B04 - Offline Behavior Idle Charging Station - Requirements
+
+Table 42. B04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B04.FR.01</td><td>After having been Offline AND the Offline period exceeds the value of the OfflineThreshold Configuration Variable.</td><td>The Charging Station SHALL send StatusNotificationRequest to report the current status of all its Connectors.</td></tr><tr><td>B04.FR.02</td><td>After having been Offline AND the Offline period does NOT exceed the value of the OfflineThreshold Configuration Variable.</td><td>The Charging Station SHALL send StatusNotificationRequest to report the current status of only the Connectors for which a state change occurred.</td></tr></table>
+
+# 2.2. Configuring a Charging Station
+
+NOTE
+
+For managing the configuration of a Charging Station a basic understanding of Device Model concepts is essential. These concepts are explained in "OCPP 2.0.1: Part 1 - Architecture & Topology", chapter 4.
+
+# B05 - Set Variables
+
+Table 43. B05 - Set Variables
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set Variables</td></tr><tr><td>2</td><td>ID</td><td>B05</td></tr><tr><td></td><td>Functional block</td><td>B. Provisioning</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to make changes to variables in the Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>A Charging Station can have a lot of variables that can be configured/changed by the CSMS. A CSMS can use these variables to for example influence the behavior of a Charging Station. This use case describes how the CSMS requests a Charging Station to set the value of variables of a component. The CSMS can request to set more than one value per request.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request setting one or more variables in a Charging Station.
+2. The CSMS sends a SetVariablesRequest to the Charging Station.
+3. The Charging Station responds with a SetVariablesResponse indicating whether it was able to executed the change(s).</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postconditions:
+1. The change was executed Successfully.
+Failure postconditions:
+1. The variable is supported, but setting could not be changed, the Charging Station responds with the status Rejected.
+2. The variable is not supported, the Charging Station responds with the status UnknownVariable.</td></tr></table>
+
+
+Figure 14. Sequence Diagram: Set Variables
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The attributeType Actual corresponds with the actual value of the Variable, whereas the attributeTypes Target, MinSet and MaxSet correspond to the target, minimum and maximum values that have been set for this variable.
+This is best explained by an example: the cooling system is configured to operate with a fan speed between 1000 and 5000 rpm. These boundaries are represented by the MinSet and MaxSet attributes. The current fan speed is represented by the Actual attribute. The desired fan speed is represented by the Target attribute.</td></tr></table>
+
+# B05 - Set Variables - Requirements
+
+Table 44. B05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B05.FR.01</td><td>When the Charging Station receives a SetVariableRequest with an X number of SetVariableData elements</td><td>The Charging Station SHALL respond with an SetVariableResponse with an equal (X) number of SetVariableResult elements, one for every SetVariableData element in the SetVariablesRequest.</td></tr><tr><td>B05.FR.02</td><td>B05.FR.01</td><td>Every SetVariableResult element in the SetVariableResponse SHALL contain the same component and variable combination as one of the SetVariableData elements in the SetVariablesRequest.</td></tr><tr><td>B05.FR.03</td><td>B05.FR.02 AND If the SetVariablesRequest contains an attributeType</td><td>The corresponding SetVariableResult element in the SetVariablesResponse SHALL also contain the same attributeType</td></tr><tr><td>B05.FR.04</td><td>When the Charging Station receives a SetVariableRequest with an unknown Component in the SetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: UnknownComponent.</td></tr><tr><td>B05.FR.05</td><td>When the Charging Station receives a SetVariableRequest with a Variable that is unknown for the given Component in the SetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: UnknownVariable.</td></tr><tr><td>B05.FR.06</td><td>When the Charging Station receives a SetVariableRequest with an attributeType that is unknown for the given Variable in the SetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: NotSupportedAttributeType.</td></tr><tr><td>B05.FR.07</td><td>When the Charging Station receives a SetVariableRequest with a value that is incorrectly formatted for the given Variable in the SetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: Rejected. (More information can be provided in the optional statusInfo element.)</td></tr><tr><td>B05.FR.08</td><td>When the Charging Station receives a SetVariableRequest with a value that is lower or higher than the range of the given Variable in the SetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: Rejected. (More information can be provided in the optional statusInfo element.)</td></tr><tr><td>B05.FR.09</td><td>NOT (B05.FR.04 to B05.FR.08) AND When the Charging Station receives a SetVariableRequest for a Variable in the SetVariableData, but is not able to set it</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: Rejected. (This happens if the variable is ReadOnly, but may also occur when setting the variable fails because of technical problems.)</td></tr><tr><td>B05.FR.10</td><td>When the Charging Station was able to set the given value from the SetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: Accepted.</td></tr><tr><td>B05.FR.11</td><td></td><td>The CSMS SHALL NOT send more SetVariableData elements in a SetVariablesRequest than reported by the Charging Station via ItemsPerMessageSetVariables.</td></tr><tr><td>B05.FR.12</td><td>When the Charging Station receives a SetVariablesRequest without an attributeType.</td><td>The corresponding SetVariableResult element in the SetVariablesResponse SHALL contain the attributeType Actual.</td></tr><tr><td>B05.FR.13</td><td></td><td>The CSMS SHALL NOT include multiple SetVariableData elements, in a single SetVariablesRequest, with the same Component, Variable and AttributeType combination. Note that an omitted AttributeType counts as the value Actual.</td></tr></table>
+
+# B06 - Get Variables
+
+Table 45. B06 - Get Variables
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Variables</td></tr><tr><td>2</td><td>ID</td><td>B06</td></tr><tr><td></td><td>Functional block</td><td>B. Provisioning</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to retrieve the value of an attribute for one or more Variables of one or more Components.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests a Charging Station to send the value of an attribute for one or more variables of one or more components. It is not possible to get all attributes of all variables in one call.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request for a number of variables in a Charging Station.
+2. The CSMS request the Charging Station for a number of variables with GetVariablesRequest with a list of requested variables.
+3. The Charging Station responds with a GetVariablesResponse with the requested variables.
+4. The CSMS sends an optional notification to the CSO.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station was able to send all the requested variables.
+Failure postcondition:
+The Charging Station was not able to send all requested variables.</td></tr></table>
+
+
+Figure 15. Sequence Diagram: Get Variables
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# B06 - Get Variables - Requirements
+
+Table 46. B06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B06.FR.01</td><td>When the Charging Station receives a GetVariablesRequest with an X number of GetVariableData elements</td><td>The Charging Station SHALL respond with an GetVariablesResponse with an equal (X) number of GetVariableResult elements, one for every GetVariableData element in the GetVariablesRequest.</td></tr><tr><td>B06.FR.02</td><td>B06.FR.01</td><td>Every GetVariableResult element in the GetVariablesResponse SHALL contain the same component and variable combination as one of the GetVariableData elements in the GetVariablesRequest.</td></tr><tr><td>B06.FR.03</td><td>B06.FR.02ANDIf the GetVariablesRequest contains an attributeType</td><td>The corresponding GetVariableResult element in the GetVariablesResponse SHALL also contain the same attributeType</td></tr><tr><td>B06.FR.04</td><td>B06.FR.01</td><td>Every GetVariableResult element in the GetVariablesResponse SHALL contain an attributeValue with the value of an attribute from the requested attributeType in the GetVariablesRequest.</td></tr><tr><td>B06.FR.05</td><td></td><td>The CSMS SHALL NOT send more GetVariableData elements in a GetVariablesRequest than reported by the Charging Station via ItemsPerMessageGetVariables.</td></tr><tr><td>B06.FR.06</td><td>When the Charging Station receives a GetVariablesRequest with an unknown Component in the GetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding GetVariableResult to: UnknownComponent AND SHALL omit the attributeValue.</td></tr><tr><td>B06.FR.07</td><td>When the Charging Station receives a GetVariablesRequest with a Variable that is unknown for the given Component in the GetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding GetVariableResult to: UnknownVariable AND SHALL omit the attributeValue.</td></tr><tr><td>B06.FR.08</td><td>When the Charging Station receives a GetVariablesRequest with an attributeType that is unknown for the given Variable in the GetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding GetVariableResult to: NotSupportedAttributeType AND SHALL omit the attributeValue.</td></tr><tr><td>B06.FR.09</td><td>When the Charging Station receives a GetVariablesRequest for a Variable in the GetVariableData that is WriteOnly</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding GetVariableResult to: Rejected.</td></tr><tr><td>B06.FR.10</td><td>When the Charging Station was able to get the value requested from a GetVariablesRequest</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding GetVariableResult to: Accepted and set the attributeValue to the found value.</td></tr><tr><td>B06.FR.11</td><td>When the Charging Station receives a GetVariablesRequest without an attributeType.</td><td>The corresponding GetVariableResult element in the GetVariablesResponse SHALL contain the attributeType Actual.</td></tr><tr><td>B06.FR.13</td><td>NOT B06.FR.08ANDthe Charging Station has no attributeValue for the requested attributeType of the componentvariable</td><td>Charging Station SHALL return an empty string as attributeValue.Note: this can happen, for example, when the attributeType Target has not yet been set, even though it is supported.</td></tr><tr><td>B06.FR.14</td><td>B06.FR.01 ANDa value for instance is provided in the component and/or variable in GetVariableData</td><td>Charging Station SHALL return the specified instance of that component and/or variable in GetVariableResult.</td></tr><tr><td>B06.FR.15</td><td>B06.FR.01 ANDno value or an empty string is provided for instance in the component and/or variable in GetVariableData ANDa component and/or variable without an instance does not exist</td><td>Charging Station SHALL return the attributeStatusUnknownComponent or UnknownVariable in the GetVariableResult entry for GetVariableData.</td></tr><tr><td>B06.FR.16</td><td>Charging Station receives a GetVariablesRequest with more GetVariableData elements than allowed by ItemsPerMessageGetVariables</td><td>The Charging Station MAY respond with aCALLERROR(OccurrenceConstraintViolation)</td></tr><tr><td>B06.FR.17</td><td>Charging Station receives a GetVariablesRequest with a length of more bytes than allowed by BytesPerMessageGetVariables</td><td>The Charging Station MAY respond with aCALLERROR(FormatViolation)</td></tr></table>
+
+# B07 - Get Base Report
+
+Table 47. B07 - Get Base Report
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Base Report</td></tr><tr><td>2</td><td>ID</td><td>B07</td></tr><tr><td></td><td>Functional block</td><td>B. Provisioning</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to request a predefined report as defined in ReportBase.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests a Charging Station to send a predefined report as defined in ReportBase. The result will be returned asynchronously in one or more NotifyReportRequest messages.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request a report from a Charging Station.
+2. The CSMS requests the Charging Station for a report with GetBaseReportRequest.
+3. The Charging Station responds with GetBaseReportResponse.
+4. The Charging Station asynchronously sends the results in one or more NotifyReportRequest messages.
+5. The CSMS responds with NotifyReportResponse for each NotifyReportRequest.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station was able to send the requested report.
+Failure postcondition:
+The Charging Station was not able to send the requested report.</td></tr></table>
+
+
+Figure 16. Sequence Diagram: Get Base Report
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# B07 - Get Base Report - Requirements
+
+Table 48. B07 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B07.FR.01</td><td>When the Charging Station receives a getBaseReportRequest for a supported reportBase AND NOT B07.FR.13</td><td>The Charging Station SHALL send a getBaseReportResponse with Accepted.</td><td></td></tr><tr><td>B07.FR.02</td><td>When the Charging Station receives a getBaseReportRequest for a reportBase that is not supported</td><td>The Charging Station SHALL send a getBaseReportResponse with NotSupported.</td><td></td></tr><tr><td>B07.FR.03</td><td>B07.FR.01</td><td>The Charging Station SHALL send the requested information via one or more NotifyReportRequest messages to the CSMS.</td><td></td></tr><tr><td>B07.FR.04</td><td>B07.FR.01 AND The getBaseReportRequest contained a requestId</td><td>Every NotifyReportRequest send for this getBaseReportRequest SHALL contain the same requestId.</td><td></td></tr><tr><td>B07.FR.05</td><td>B07.FR.02</td><td>The Charging Station SHALL NOT send a NotifyReportRequest to the CSMS.</td><td></td></tr><tr><td>B07.FR.07</td><td>B07.FR.01 AND When reportBase is ConfigurationInventory</td><td>Then the Charging Station SHALL respond with a NotifyReportRequest to report on all component-variables that can be set by the operator including their VariableCharacteristics.</td><td></td></tr><tr><td>B07.FR.08</td><td>B07.FR.01 AND When reportBase is FullInventory</td><td>Then the Charging Station SHALL respond with a NotifyReportRequest to report on all component-variables including their VariableCharacteristics.</td><td>As a minimum the required variables mentioned in Charging Infrastructure related shall be reported as well as the required variables in Section 1 Controller Components that are relevant to each functional block that has been implemented.</td></tr><tr><td>B07.FR.09</td><td>B07.FR.01 AND When reportBase is SummaryInventory</td><td>Then the Charging Station SHALL respond with a NotifyReportRequest to report on components and variables related to the availability and condition of the Charging Station, notably operationalStatus of the Charging Station, EVSE and Connectors and any error condition.</td><td>A (summary) report that lists Components/Variables relating to the Charging Station's current charging availability, and to any existing problem conditions.For the Charging Station Component:- AvailabilityState.For each EVSE Component:- AvailabilityState.For each Connector Component:- AvailabilityState (if known and different from EVSE).For all Components in an abnormal State:- Active (Problem, Tripped, Overload, Fallback) variables.- Any other diagnostically relevant Variables of the Components.</td></tr><tr><td>B07.FR.10</td><td></td><td>The sequence number contained in the seqNo field of the NotifyReportRequest is incremental per report. So the NotifyReportRequest message which contains the first report part, SHALL have a seqNo with value 0.</td><td></td></tr><tr><td>B07.FR.11</td><td>B07.FR.08</td><td>All attribute types of a variable, that are supported by the Charging Station, SHALL be reported, even if they have no value (are unset).</td><td>This allows a CSMS to know which attribute types are supported by the Charging Station.</td></tr><tr><td>B07.FR.12</td><td></td><td>The Charging Station SHALL support at least the base reports:ConfigurationInventory and FullInventory.</td><td></td></tr><tr><td>B07.FR.13</td><td>When the Charging Station is temporarily unable to execute a report request</td><td>The Charging Station SHALL send a getBaseReportResponse with Rejected.</td><td></td></tr><tr><td>B07.FR.14</td><td>When a Charging Station connects to CSMS for the first time OR whenever CSMS suspects that the device model of the Charging Station has changed (e.g. after a firmware update or hardware change)</td><td>CSMS SHOULD request a GetBaseReportRequest with reportBase = FullInventory to retrieve a complete list of all its device model components and variables.</td><td>It is not mandated, because implementations may exist that are based on a known set of charging stations with fixed device models that will not change.</td></tr></table>
+
+# B08 - Get Custom Report
+
+Table 49. B08 - Get Custom Report
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Custom Report</td></tr><tr><td>2</td><td>ID</td><td>B08</td></tr><tr><td></td><td>Functional block</td><td>B. Provisioning</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to request a report of all Components and Variables limited to those that match ComponentCriteria and/or the list of ComponentVariables.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests a Charging Station to send a report of all Components and Variables limited to those that match ComponentCriteria and/or the list of ComponentVariables. The result will be returned asynchronously in one or more NotifyReportRequest messages.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request a report from a Charging Station.
+2. The CSMS requests the Charging Station for a report with a GetReportRequest.
+3. The Charging Station responds with a GetReportResponse.
+4. The Charging Station asynchronously sends the results in one or more NotifyReportRequest messages.
+5. The CSMS responds with a NotifyReportResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station was able to send the requested report.
+Failure postcondition:
+The Charging Station was not able to send the requested report.</td></tr></table>
+
+
+Figure 17. Sequence Diagram: Get Custom Report
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# B08 - Get Custom Report - Requirements
+
+Table 50. B08 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B08.FR.01</td><td>NOT B08.FR.15 AND When the Charging Station receives a getReportRequest for supported criteria</td><td>The Charging Station SHALL send a getReportResponse with Accepted</td></tr><tr><td>B08.FR.02</td><td>When the Charging Station receives a getReportRequest for not supported criteria</td><td>The Charging Station SHALL send a getReportResponse with NotSupported</td></tr><tr><td>B08.FR.03</td><td>B08.FR.01</td><td>The Charging Station SHALL send the requested information via one or more NotifyReportRequest messages to the CSMS.</td></tr><tr><td>B08.FR.04</td><td>B08.FR.01 AND The getReportRequest contained a requestId</td><td>Every NotifyReportRequest sent for this getReportRequest SHALL contain the same requestId.</td></tr><tr><td>B08.FR.05</td><td>B08.FR.01 AND componentCriteria and componentVariables are NOT both empty.</td><td>Every NotifyReportRequest sent for this getReportRequest SHALL be limited to the set componentCriteria and componentVariables.</td></tr><tr><td>B08.FR.06</td><td></td><td>The maximum number of componentVariables in one getReportRequest message is given by the ItemsPerMessageGetReport Configuration Variable</td></tr><tr><td>B08.FR.07</td><td>B08.FR.01 AND ComponentCriteria contains: Active</td><td>The Charging Station SHALL report every component that has the variable Active set to true, or does not have the Active variable in a NotifyReportRequest.</td></tr><tr><td>B08.FR.08</td><td>B08.FR.01 AND ComponentCriteria contains: Available</td><td>The Charging Station SHALL report every component that has the variable Available set to true, or does not have the Available variable, in a NotifyReportRequest.</td></tr><tr><td>B08.FR.09</td><td>B08.FR.01 AND ComponentCriteria contains: Enabled</td><td>The Charging Station SHALL report every component that has the variable Enabled set to true, or does not have the Enabled variable, in a NotifyReportRequest.</td></tr><tr><td>B08.FR.10</td><td>B08.FR.01 AND ComponentCriteria contains: Problem</td><td>The Charging Station SHALL report every component that has the variable Problem set to true in a NotifyReportRequest.</td></tr><tr><td>B08.FR.11</td><td>B08.FR.01 AND componentCriteria is absent AND componentVariables is NOT empty.</td><td>Every NotifyReportRequest sent for this getReportRequest is limited to the set in componentVariables.</td></tr><tr><td>B08.FR.12</td><td>B08.FR.01</td><td>The reported variables in NotifyReportRequest SHALL contain variableCharacteristics.</td></tr><tr><td>B08.FR.13</td><td>B08.FR.01 AND More than one componentCriteria is given.</td><td>The Charging Station SHALL report all components that have at least one of the given criteria (logical OR).</td></tr><tr><td>B08.FR.14</td><td></td><td>The sequence number contained in the seqNo field of the NotifyReportRequest is incremental per report. So the NotifyReportRequest message which contains the first report part, SHALL have a seqNo with value 0.</td></tr><tr><td>B08.FR.15</td><td>When the Charging Station receives a GetReportRequest with a combination of criteria which results in an empty result set.</td><td>The Charging Station SHALL respond with a GetReportResponse(status=EmptyResultSet).</td></tr><tr><td>B08.FR.16</td><td>When the Charging Station is temporarily unable to execute a report request</td><td>The Charging Station SHALL send a getBaseReportResponse with Rejected.</td></tr><tr><td>B08.FR.17</td><td>Charging Station receives a GetReportRequest with more ComponentVariableType elements than allowed by ItemsPerMessageGetReport</td><td>The Charging Station MAY respond with a CALLERROR(OccurrenceConstraintViolation)</td></tr><tr><td>B08.FR.18</td><td>Charging Station receives a GetReportRequest with a length of more bytes than allowed by BytesPerMessageGetReport</td><td>The Charging Station MAY respond with a CALLERROR(FormatViolation)</td></tr><tr><td>B08.FR.20</td><td>When Charging Station receives a GetReportRequest with componentVariable elements in which variable is missing</td><td>The Charging Station SHALL report for every variable of the component in componentVariable.</td></tr><tr><td>B08.FR.21</td><td>When Charging Station receives a GetReportRequest with componentVariable elements in which variable is present, but instance is missing</td><td>The Charging Station SHALL report for every instance of the variable of the component in componentVariable.</td></tr><tr><td>B08.FR.22</td><td>B08.FR.11 AND When Charging Station receives a GetReportRequest with a component in a componentVariable element that has a component.evse.id, but component.evseconnector is missing</td><td>The Charging Station SHALL report the component(s) with this component.name, component.instance and component.evse.id for every component.evseconnector, whilst taking into account B08.FR.24.</td></tr><tr><td>B08.FR.23</td><td>B08.FR.11 AND When Charging Station receives a GetReportRequest with a component in a componentVariable element that has no component.evse.id</td><td>The Charging Station SHALL report the component(s) with this component.name, component.instance for every component.evse field (including top level component without component.evse), whilst taking into account B08.FR.24.</td></tr><tr><td>B08.FR.24</td><td>B08.FR.11 AND When Charging Station receives a GetReportRequest with a component in a componentVariable element that has a value for component.instance</td><td>The Charging Station SHALL report the component(s) with this component.name for every component.instance field, whilst taking into account B08.FR.22, B08.FR.23.</td></tr><tr><td>B08.FR.25</td><td>B08.FR.11 AND When Charging Station receives a GetReportRequest with a component in a componentVariable element that has no component.instance field</td><td>The Charging Station SHALL report the component(s) with this component.name for every component.instance field or the component(s) without component.instance field, whichever is the case, whilst taking into account B08.FR.22, B08.FR.23.</td></tr></table>
+
+# B09 - Setting a new NetworkConnectionProfile
+
+Table 51. B09 - Setting a new NetworkConnectionProfile
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Setting a new NetworkConnectionProfile.</td></tr><tr><td>2</td><td>ID</td><td>B09</td></tr><tr><td></td><td>Functional block</td><td>B. Provisioning</td></tr><tr><td>3</td><td>Objectives</td><td>To enable the CSMS to update the connection details on the Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>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.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>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 OCPPCommCtrlActiveNetworkProfile.
+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</td></tr><tr><td>5</td><td>Prerequisites</td><td>The data supplied by the CSMS matches the Charging Station's capabilities</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station was able to store the new connection data</td></tr></table>
+
+
+
+Figure 18. Sequence Diagram: Set Network Connection Profile
+
+<table><tr><td>8</td><td>Error Handling</td><td>Activation of a new NetworkConnectionProfile is described in B10 - Migrate to new CSMS. Errors during this use-case are not destructive to the current data connection. Error handling is further described in B10 - Migrate to new CSMS</td></tr><tr><td>9</td><td>Remarks</td><td>Even when changes are made to the currently active NetworkConnectionProfile, these will not activated until a reboot has occurred, as described in B10 - Migrate to new CSMS.</td></tr></table>
+
+# B09 - Setting a new NetworkConnectionProfile - Requirements
+
+Table 52. B09 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B09.FR.01</td><td>On receipt of the SetNetworkProfileRequest</td><td>The Charging Station SHALL validate the content, store the new data and if successful, respond by sending a SetNetworkProfileResponse message, with status Accepted</td></tr><tr><td>B09.FR.02</td><td>On receipt of the SetNetworkProfileRequest</td><td>The Charging Station SHALL validate the content. If the content is invalid, the Charging Station SHALL respond by sending a SetNetworkProfileResponse message, with status Rejected</td></tr><tr><td>B09.FR.03</td><td>If setting the new networkprofile fails.</td><td>The Charging Station SHALL respond by sending a SetNetworkProfileResponse message, with status Failed</td></tr><tr><td>B09.FR.04</td><td>On receipt of the SetNetworkProfileRequest AND the NetworkConnectionProfile contains a lower securityProfile than stored at the configuration variable SecurityProfile</td><td>The Charging Station SHALL respond by sending a SetNetworkProfileResponse message, with status Rejected</td></tr><tr><td>B09.FR.05</td><td>When the value of configurationSlot in SetNetworkProfileRequest does not match an entry in valuesList of NetworkConfigurationPriority</td><td>The Charging Station SHALL respond by sending a SetNetworkProfileResponse message with status Rejected</td></tr><tr><td>B09.FR.06</td><td></td><td>A Charging Station SHALL support at least two configuration slots for network connection profiles.</td></tr></table>
+
+# B10 - Migrate to new CSMS
+
+Table 53. B10 - Migrate to new CSMS
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Migrate to new CSMS, using a different NetworkConnectionProfile.</td></tr><tr><td>2</td><td>ID</td><td>B10</td></tr><tr><td></td><td>Functional block</td><td>B. Provisioning</td></tr><tr><td>3</td><td>Objectives</td><td>After completion of this use case, the Charging Station connects to a new CSMS.</td></tr><tr><td>4</td><td>Description</td><td>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.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS 1, CSMS 2</td></tr><tr><td></td><td>Scenario description</td><td>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.</td></tr><tr><td>5</td><td>Prerequisites</td><td>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</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station is connected via a different NetworkConnectionProfile.</td></tr></table>
+
+
+Figure 19. Sequence Diagram: Migrate to new ConnectionProfile
+
+<table><tr><td>8</td><td>Error Handling</td><td>n/a</td></tr><tr><td>9</td><td>Remarks</td><td>As in line with B12 - Reset - With Ongoing Transaction, when there are ongoing transactions, the Charging Station waits for these to be finished before performing the Reset and then connecting to a different CSMS. When an operator wants to perform an immediate switch, he should stop the transactions first.</td></tr></table>
+
+# B10 - Migrate to new NetworkConnectionProfile - Requirements
+
+Table 54. B10 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B10.FR.01</td><td>On receipt of a SetVariablesRequest, containing Configuration Variable NetworkConfigurationPriority AND the NetworkProfile slots in the message all contain valid configurations</td><td>The Charging Station SHALL send SetVariablesResponse with status Accepted, or RebootRequired.</td><td></td></tr><tr><td>B10.FR.02</td><td>On receipt of a SetVariablesRequest, containing Configuration Variable NetworkConfigurationPriority AND any of the NetworkProfile slots in the message does not contain a valid configuration</td><td>The Charging Station SHALL send SetVariablesResponse with status Rejected.</td><td>The optional element statusInfo can be used to provide more information.</td></tr><tr><td>B10.FR.03</td><td>B10.FR.04 AND When connecting fails</td><td>The Charging Station SHALL make the number of attempts as configured in NetworkProfileConnectionAttempts per entry of NetworkConfigurationPriority.</td><td></td></tr><tr><td>B10.FR.04</td><td>B10.FR.01 OR B09.FR.01 AND After a reboot</td><td>The Charging Station SHALL begin connecting to the first entry of NetworkConfigurationPriority</td><td></td></tr><tr><td>B10.FR.05</td><td></td><td>It is RECOMMENDED to set the Charging Station to Inoperative (via ChangeAvailabilityRequest) to ensure that no new transactions can be started and wait until the transaction message queue in the Charging Station is empty before sending the ResetRequest. Otherwise the Charging Station might send transaction related messages to the new CSMS that has not received the start of the Transaction, and the old system will miss the ended messages. To determine if there are still transaction for an ongoing transaction in the queue, the getTransactionStatusRequest message can be used.</td><td></td></tr><tr><td>B10.FR.06</td><td></td><td>The Charging Station SHALL disconnect from the old CSMS, before trying to connect to the new CSMS.</td><td></td></tr><tr><td>B10.FR.07</td><td>B10.FR.03 AND All NetworkProfileConnectionAttempts for every entry of NetworkConfigurationPriority failed.</td><td>The Charging Station SHOULD fallback and start 'reconnecting' to the NetworkConnectionProfile for which the last successful connection was made.</td><td>'reconnecting' in this requirement, refers to the reconnection mechanism described at section 5.3. Reconnecting from "Part 4 - JSON over WebSockets implementation guide".</td></tr></table>
+
+# 2.3. Resetting a Charging Station
+
+# B11 - Reset - Without Ongoing Transaction
+
+Table 55. B11 - Reset - Without Ongoing Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reset - Without Ongoing Transaction</td></tr><tr><td>2</td><td>ID</td><td>B11</td></tr><tr><td></td><td>Functional block</td><td>B. Provisioning</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to request a Charging Station to reset itself or an EVSE, while there is no ongoing transaction.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS can request the Charging Station to reset itself or an EVSE by sending ResetRequest. (If ResetRequest contains an optional paramater evseld, then only a reset of the specific EVSE is requested.) This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO requests the CSMS to reset the Charging Station or EVSE.
+2. The CSMS sends ResetRequest requesting the Charging Station to reset itself or EVSE.
+3. The CSMS requests for an OnIdle or Immediate reset.
+4. The Charging Station responds with ResetResponse, indicating whether the Charging Station is able to reset itself or EVSE.
+5. The CSMS sends an optional notification to the CSO.
+6. Only if no evseld was supplied, then after the reset, the Charging Station will proceed as in use case B01.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>B12 - Reset With Ongoing Transaction</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>No transaction is ongoing.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station was able to reset itself or EVSE.
+Failure postcondition:
+The Charging Station not was able to reset itself or EVSE.</td></tr></table>
+
+
+Figure 20. Sequence Diagram: Reset Without Transaction
+
+<table><tr><td>7</td><td>Error handling</td><td>n.a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Persistent states: for example, EVSE set to Unavailable SHALL persist.
+The Charging Station responds with ResetResponse.</td></tr></table>
+
+# B11 - Reset - Without Ongoing Transaction - Requirements
+
+Table 56. B11 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B11.FR.01</td><td>When the Charging Station receives a ResetRequest.</td><td>The Charging Station SHALL respond with a ResetResponse.</td></tr><tr><td>B11.FR.02</td><td>If the status was set to Inoperative by the CSMS.</td><td>After a reboot of the Charging Station, the EVSEs SHALL return to the state Unavailable as prior to the reboot.</td></tr><tr><td>B11.FR.03</td><td>B11.FR.01 AND no evseld parameter is supplied AND ResetResponse was Accepted.</td><td>The Charging Station MAY send a StatusNotification(Unavailable) and SHALL start a reboot.</td></tr><tr><td>B11.FR.04</td><td>B11.FR.03</td><td>The Charging Station SHALL proceed as described in use case B01 - Cold Boot Charging Station.</td></tr><tr><td>B11.FR.05</td><td>If the status of an EVSE was Reserved.</td><td>After a reboot of the Charging Station or resetting of EVSE, the EVSE(s) SHALL return to the state Reserved.</td></tr><tr><td>B11.FR.06</td><td>B11.FR.01ANDFor example there is a firmware update ongoing that cannot be interrupted.</td><td>The Charging Station SHALL respond with a status Rejected.</td></tr><tr><td>B11.FR.07</td><td>B11.FR.01ANDCharging Station cannot perform the reset now, but has scheduled the reset for later</td><td>The Charging Station SHALL respond with a status Scheduled.</td></tr><tr><td>B11.FR.08</td><td>B11.FR.01AND an evseld parameter is suppliedANDResetResponse was Accepted.</td><td>The Charging Station MAY send aStatusNotification(Unavailable) for the EVSE and SHALL start areset of EVSE that is referred to by evseld parameter.</td></tr><tr><td>B11.FR.09</td><td>B11.FR.01AND an evseld parameter is suppliedANDCharging Station does not support resetting an individual EVSE</td><td>The Charging Station SHALL return a ResetResponse Rejected</td></tr><tr><td>B11.FR.10</td><td>When the Charging Station supports resetting of an individual EVSE</td><td>The Charging Station SHOULD set the device model variableAllowReset to true for the EVSE.</td></tr></table>
+
+# B12 - Reset - With Ongoing Transaction
+
+Table 57. B12 - Reset - With Ongoing Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reset - With Ongoing Transaction</td></tr><tr><td>2</td><td>ID</td><td>B12</td></tr><tr><td></td><td>Functional block</td><td>B. Provisioning</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to request a Charging Station to reset itself or EVSE, while there is an ongoing transaction.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS can request the Charging Station to reset itself or an EVSE by sending ResetRequest. (If ResetRequest contains an optional paramater evseld, then only a reset of the specific EVSE is requested.) This could for example be necessary if the Charging Station is not functioning correctly. The CSMS has the possibility to let the Charging Station end all transactions itself and reboot or wait until all ongoing transactions are ended normally (by an EV user) and then reboot.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO requests the CSMS to reset the Charging Station or EVSE.
+2. The CSMS sends ResetRequest requesting the Charging Station to reset itself or EVSE.
+3a. On receipt of an OnIdle reset, the Charging Station responds with ResetResponse(Scheduled), indicating the Charging Station will try to reset itself or EVSE after all ongoing transactions have ended. The Charging Station continues charging and sets all EVSEs (or only the one provided in the request, if evseld was supplied) that are Available to status Unavailable, waits until all transactions are finished and all TransactionEventRequest (eventType = Ended) messages are sent.
+3b. On receipt of an Immediate reset, the Charging Station responds with ResetResponse(Accepted), indicating the Charging Station will try to reset itself or EVSE. The Charging Station attempts to terminate any transaction (or only those running on the EVSE provided in the request, if evseld was supplied) in progress, and sending a TransactionEventRequest (eventType = Ended) message.
+4. Only if no evseld was supplied the Charging Station reboots and returns to a state as just having been booted, B01 - Cold Boot Charging Station applies.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>B11 - Reset Without Ongoing Transaction</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A transaction is ongoing.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station was able to reset itself or EVSE.
+Failure postcondition:
+The Charging Station not was able to reset itself or EVSE.</td></tr></table>
+
+
+Figure 21a: Sequence Diagram: Reset OnIdle With Ongoing Transaction
+
+
+Figure 21b: Sequence Diagram: Reset Immediate With Ongoing Transaction
+
+<table><tr><td>7</td><td>Error handling</td><td>After having accepted the ResetRequest, TransactionEventRequest messages that cannot be delivered to the CSMS MUST be queued.</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# B12 - Reset - With Ongoing Transaction - Requirements
+
+Table 58. B12 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B12.FR.01</td><td>When the Charging Station receives a ResetRequest(OnIdle) AND a transaction is ongoing</td><td>The Charging Station SHALL respond with a ResetResponse(Scheduled), to indicate whether the Charging Station will attempt to reset itself or EVSE after all transactions on Charging Station or EVSE have ended.</td></tr><tr><td>B12.FR.02</td><td>When the Charging Station receives a ResetRequest(Immediate) AND a transaction is ongoing</td><td>The Charging Station SHALL respond with a ResetResponse(Accepted), to indicate whether the Charging Station will attempt to reset itself or EVSE.</td></tr><tr><td>B12.FR.03</td><td>If no evsEd is supplied AND If any transaction is in progress and an OnIdle reset is received.</td><td>The transaction of the Charging Station SHALL be terminated normally, before the reboot, as in E06 - Stop Transaction.</td></tr><tr><td>B12.FR.04</td><td>If no evseld is supplied AND If any transaction is in progress and an Immediate Reset is received.</td><td>The Charging Station SHALL attempt to terminate any transaction in progress and send a TransactionRequest (eventType = Ended) message before performing a reboot.</td></tr><tr><td>B12.FR.05</td><td>If an Immediate Reset without evseld is received and the TransactionResponse is not received within timeout.</td><td>The Charging Station SHALL queue the TransactionRequest, reboot and resend the TransactionRequest after the reboot.</td></tr><tr><td>B12.FR.06</td><td>If the status was set to Inoperative by the CSMS.</td><td>After a reboot of the Charging Station or resetting of EVSE, the EVSE(s) SHALL return to the state Unavailable as prior to the reboot of Charging Station or reset of EVSE.</td></tr><tr><td>B12.FR.07</td><td>If an evseld is supplied AND If a transaction is in progress on the EVSE and an OnIdle reset is received.</td><td>The transaction on the EVSE SHALL be terminated normally, before the reset, as in E06 - Stop Transaction.</td></tr><tr><td>B12.FR.08</td><td>If an evseld is supplied AND If a transaction is in progress on the EVSE and an Immediate Reset is received.</td><td>The Charging Station SHALL attempt to terminate the transaction in progress on the EVSE and send a TransactionRequest (eventType = Ended) message before performing a reset.</td></tr><tr><td>B12.FR.09</td><td>B12.FR.01 AND an evseld parameter is supplied AND Charging Station does not support resetting an individual EVSE</td><td>The Charging Station SHALL return a ResetResponse Rejected</td></tr></table>
+
+# C. Authorization
+
+# 1. Introduction
+
+This Functional Block describes all the authorization-related functionalities, it contains different ways of authorizing a user, online and/or offline and the AuthorizationRequest message handling/behavior, Authorization Cache functionality, etc.
+
+When a user wishes to unplug the electric vehicle from the Charging Station, the Charging Station needs to verify that the user is either the one that initiated the charging or that the user is in the same group and thus allowed to terminate the charging. Once authorized, the Charging Station informs the CSMS that the charging has been stopped.
+
+To improve the experience for users, a Charging Station MAY support local authorization of identifiers, using an Authorization Cache.
+
+- The LocalAuthorizationOffline Configuration Variable controls whether a Charging Station will authorize a user when offline using the Authorization Cache.
+- The LocalPreAuthorization Configuration Variable controls whether a Charging Station will use the Authorization Cache to start a transaction without performing an authorization with the CSMS.
+
+# 1.1.ID Tokens
+
+This section is normative
+
+OCPP now makes it possible to use many different types of authorization. Where OCPP 1.x only supported RFID, OCPP now also supports things like: credit card, PIN-code, a simple start button etc.
+
+An IDTokenType contains the identifier to use for authorization. It is defined as a combination of a case insensitive string and a type. Message data elements of the IDTokenType class (including GroupId) MAY contain any data, that is meaningful to a CSMS (e.g. for the purpose of identifying the initiator of charging activity), and Charging Stations MUST NOT make any presumptions as to the format or content of such data, other than is provided in the description of the IdTokenType (e.g. by assuming that it is a UID-like value that must be hex characters only and/or an even number of digits). IdToken data acquired via local token reader hardware is usually a (4, 7 or 10 bytes) UID value of a physical IdToken, typically represented as 8, 14 or 20 hexadecimal digit characters.
+
+# NOTE
+
+To promote interoperability, based on common practice to date in the case of Id-TokenType data has type: ISO14443, it is RECOMMENDED that such UIDs be represented as hex representations of the UID bytes. According to ISO 14443-3, byte 0 should come first in the hex string. (Most significant nibble of byte 0 first)
+
+# 1.1.1. Additional Info
+
+AdditionalInfo can be used to send extra information which can be validated by the CSMS in addition to the regular authorization with IdToken.
+
+AdditionalInfo contains one or more custom types, which need to be agreed upon by all parties involved. When AdditionalInfo is implemented the Charging Station SHALL also cache and include AdditionalInfo during regular operations and set the Configuration Variable AdditionalInfoItemsPerMessage. When AdditionalInfo is NOT implemented or a not supported AdditionalInfo.type is used, the CSMS/Charging Station MAY ignore the AdditionalInfo.
+
+# 1.2. Group ID Tokens
+
+This section is normative
+
+A CSMS has the ability to treat a set of identity tokens as a "group", thereby allowing any one token in the group to start a transaction and for the same token, or another token in the same group, to stop the transaction. This supports the common usecases of families or businesses with multiple drivers using one or more shared electric vehicles on a single recharging contract account. IDTokenTypes used as "GroupId" may often use a shared central account identifier for the GroupId, instead of a UID of the first/master RFID card of an account.
+
+Tokens (idTags) are grouped for authorization purposes by specifying a common group identifier in the optional groupIdToken element in IdTokenInfo: two IdTokens are considered to be in the same group if their GroupIdTokens match (and they are not empty).
+
+# NOTE
+
+Even though the GroupId has the same nominal data type (IdTokenType) as an idToken, the value of this element may not be in the common format of IdTokenTypes and/or may not represent an actual valid IdTokenType (e.g. it may be a common shared "account number"): therefore, the GroupId value SHOULD NOT be used for comparison against a presented Token value (unless it also occurs as an idToken value).
+
+# 1.3. Authorization Cache
+
+A Charging Station MAY implement an Authorization Cache that autonomously maintains a record of previously presented identifiers that have been successfully authorized by the CSMS. The Authorization Cache can be used to speed up the authorization process at the Charging Station, since using a locally stored cache means that the user does not have to wait for the Charging Station to check the authorization at the CSMS. Operation of the Authorization Cache, when present, is reported (and controlled, where possible) by the AuthCacheEnabled Configuration Variable. The optional expiration time of general Authorization Cache entries can be set in the Configuration Variable AuthCacheLifeTime. If a different expiration time is desired for a specific entry, this can be set in the cacheExpiryDateTime that is returned in iDTokensInfo of, for example, the ActivateResponse.
+
+Please refer to the use cases C10 - Store Authorization Data in the Authorization Cache and C12 - Start Transaction - Cached Id for more information on how to implement / use the Authorization Cache functionality.
+
+When a Charging Station supports both the Authorization Cache and Tariff information (see: Tariff & Cost), it should not store the tariff information in the Authorization Cache, since this information could become outdated.
+
+A Charging Station MAY support the authorization of any presented identifier when offline, to avoid refusal of charging to bona fide users that cannot be explicitly authorized by Authorization Cache entries. This functionality is explained in more detail in Unknown Offline Authorization.
+
+It is RECOMMENDED to store personal information in the Authorization Cache securely, e.g. by only storing hashed Tokens in the cache.
+
+# 1.4. Local Authorization List
+
+The Local Authorization List is a list of identifiers that can be synchronized with the CSMS. It allows authorization of a user when offline and faster (apparent) authorization response time when communication between Charging Station and CSMS is slow. The CSMS can synchronize the list by either sending a complete list of identifiers to replace the Local Authorization List or by sending a list of changes (add, update, delete) to apply to the Local Authorization List. The operations to support this are GetLocalListVersion and SendLocalList.
+
+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.
+
+Please refer to the use cases D01 - Send Local Authorization List, C13 - Offline Authorization through Local Authorization List and C14 - Online Authorization through Local Authorization List for more information on how to implement / use the Local Authorization List functionality.
+
+# NOTE
+
+Please note the difference between the Authorization Cache and Local Authorization List mechanisms: the Authorization Cache is an autonomous mechanism at the Charging Station, whereas the Local Authorization List is a list that is synchronized between CSMS and Charging Station (originating from the CSMS).
+
+# NOTE
+
+The Authorization Cache and Local Authorization List are distinct logical data structures. When both Authorization Cache as well as Local Authorization List are supported, a Charging Station SHALL treat Local Authorization List entries as having priority over Authorization Cache entries for the same identifiers.
+
+The following Configuration Variables are used by the Charging Station to give information about the Local Authorization List
+
+- LocalAuthListEntries (Also reports the maximum amount of IdTokens in the Local Authorization List)
+- LocalAuthListEnabled
+- LocalAuthListAvailable
+- ItemsPerMessageSendLocalList
+- BytesPerMessageSendLocalList
+
+# 1.5. Unknown Offline Authorization
+
+When offline, a Charging Station MAY allow automatic authorization of any "unknown" identifiers that are not found in the Local Authorization List and/or Authorization Cache. Operation of the Unknown Offline Authorization capability, when supported, is reported (and controlled, where possible) by the OfflineTxForUnknownIdEnabled Configuration Variable. When connection to the CSMS is restored, the Charging Station has to send the queued TransactionRequest messages. These may contain transactions that were authorized offline, as explained in transaction-related message handling. Please refer to C15 - Unknown Offline Authorization for the options that the Charging Station has to continue / stop the transaction in this situation.
+
+# 2. Use cases & Requirements
+
+# 2.1. Authorization options
+
+# C01 - EV Driver Authorization using RFID
+
+Table 59. C01 - EV Driver Authorization using RFID
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>EV Driver Authorization using RFID</td></tr><tr><td>2</td><td>ID</td><td>C01</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Charging Station to request the CSMS to authorize an EV Driver to start or stop charging.</td></tr><tr><td>4</td><td>Description</td><td>When a Charging Station needs to charge an EV, it needs to authorize the EV Driver first before the charging can be started or stopped.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver wants to start or stop charging the EV and presents an RFID card.
+2. The Charging Station sends AuthorizationRequest to the CSMS to request authorization.
+3. Upon receipt of AuthorizationRequest, the CSMS responds with AuthorizationResponse. This response message indicates whether or not the IdToken is accepted by the CSMS.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C02 - Authorization using a start button
+C03 - Authorization using credit/debit card
+C04 - Authorization using PIN-code
+C05 - Authorization for CSMS initiated transactions
+C06 - Authorization using local id type
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The EV Driver is authorized and can start or stop charging.
+Failure postcondition:
+If the authorize message is Invalid, Blocked, Expired or Unknown, the EV Driver can not start or stop charging, except in the case where the EV Driver presents the same token used to start the transaction.</td></tr></table>
+
+
+Figure 21. Sequence Diagram: EV Driver Authorization
+
+<table><tr><td>7</td><td>Error handling</td><td>When the Authorization is not 'Accepted', theauthorizeResponse contains an authorization status value indicating the reason for rejection.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Assuming idToken is valid for charging and the Charging Station has 3 EVSEs, what is the content of idTokenInfo, when idToken is allowed to charge: . at all EVES: idTokenInfo.status = Accepted. . at EVSE 1: idTokenInfo.status = Accepted, idTokenInfo.evseld = [1]. . at EVSE 1 + 2: idTokenInfo.status = Accepted, idTokenInfo.evseld = [1, 2]. . at none of the EVSEs: _idTokenInfo.status=NotAtThisLocation.</td></tr></table>
+
+# C01 - EV Driver Authorization using RFID - Requirements
+
+Table 60. C01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C01.FR.01</td><td>Configuration setting AuthEnabled is true.</td><td>The Charging Station SHALL only offer energy after authorization.</td><td></td></tr><tr><td>C01.FR.02</td><td>If an idToken presented by the EV Driver is not present in the Local Authorization List or Authorization Cache</td><td>The Charging Station SHALL send AuthorizationRequest to the CSMS to request authorization.</td><td></td></tr><tr><td>C01.FR.03</td><td>When an idToken is presented during a transaction that has been authorized AND (a) the presented idToken is the same as the idToken that started the authorization OR (b) when the presented idToken is in the Local Authorization List or Authorization Cache AND is valid AND has the same GroupIdToken as the IdToken that started the authorization.</td><td>The Charging Station SHALL end the authorization of the transaction, without first sending an AuthorizationRequest</td><td>The idToken that started the authorization can always be used to end the authorization. Ending authorization will end delivery of energy. Depending on the TxStopPoint ending of the authorization may also end the transaction.</td></tr><tr><td>C01.FR.04</td><td></td><td>AuthorizationRequest SHALL only be used for the authorization of an identifier.</td><td></td></tr><tr><td>C01.FR.05</td><td>If an IdToken is present in the Local Authorization List or Authorization Cache.</td><td>The Charging Station MAY send AuthorizationRequest to the CSMS.</td><td></td></tr><tr><td>C01.FR.06</td><td>When CSMS receives an AuthorizationRequest for an idToken AND the idToken has an associated groupIdToken.</td><td>AuthorizationResponse sent by the CSMS to a Charging Station SHALL include the associated groupIdToken.</td><td></td></tr><tr><td>C01.FR.07</td><td></td><td>AuthorizationResponse SHALL include an authorization status value indicating acceptance or a reason for rejection.</td><td>See AuthorizationStatusEnu mType for the possible reasons of rejection.</td></tr><tr><td>C01.FR.08</td><td>If the field: language1 is set AND the Charging Station contains messages in that language.</td><td>The Charging Station SHALL show messages to the user in language1.</td><td></td></tr><tr><td>C01.FR.09</td><td>If the field: language1 is set AND the Charging Station does not contain messages in that language AND if the field: language2 is set AND the Charging Station contains messages in that language</td><td>The Charging Station SHALL show messages to the user in language2.</td><td></td></tr><tr><td>C01.FR.10</td><td>If the field: language1 is not set</td><td>The field: language2 SHALL NOT be set.</td><td></td></tr><tr><td>C01.FR.11</td><td></td><td>Field: language1 SHALL be different from field language2.</td><td></td></tr><tr><td>C01.FR.12</td><td></td><td>It is RECOMMENDED to implement messages in English as fall-back.</td><td></td></tr><tr><td>C01.FR.13</td><td>If both language1 AND language2 don't match installed languages in the Charging Station</td><td>It is RECOMMENDED to show messages to the EV Driver in English.</td><td></td></tr><tr><td>C01.FR.17</td><td></td><td>Language SHALL be specified as RFC-4646 tags, see: [RFC5646], example: US English is: "en-US".</td><td></td></tr><tr><td>C01.FR.18</td><td>If the IdToken is valid AND the EV driver is NOT allowed to charge at the type of EVSE(s) this Charging Station provides.</td><td>The CSMS SHALL send an AuthorizationResponse with idTokenInfo.status NotAllowedTypeEVSE.</td><td></td></tr><tr><td>C01.FR.19</td><td>idToken is allowed for any EVSE of the Charging Station</td><td>The CSMS SHALL send an AuthorizationResponse in which idTokenInfo has an empty (or absent) evseld list.</td><td>This will be the most common case. Even though the idToken might be allowed on any EVSE, the idTokenInfo.status still needs to be Accepted before charging is allowed.</td></tr><tr><td>C01.FR.20</td><td>idToken is allowed for a subset of EVSEs of the Charging Station</td><td>The CSMS SHALL send an AuthorizationResponse in which IdTokenInfo has an evseld list with the allowed EVSEs.</td><td>Note the difference between validity of an idToken and the fact whether this (type of) token is allowed on an EVSE. The idTokenInfo.status still needs to be Accepted before charging is allowed.</td></tr><tr><td>C01.FR.21</td><td>C01.FR.20</td><td>The Charging Station SHALL only allow charging on the EVSEs mentioned in the AuthorizationResponse.</td><td></td></tr><tr><td>C01.FR.22</td><td>idToken is not allowed for any EVSE of the Charging Station</td><td>The CSMS SHALL send an AuthorizationResponse in which idTokenInfo.status is NotAtThisLocation and evseld list is empty (or absent).</td><td>Status NotAtThisLocation needed in order to differentiate with the situation in which idToken is allowed on all EVSEs.</td></tr><tr><td>C01.FR.23</td><td>When a transaction is still active, that had been authorized earlier by an idToken, but which is now no longer authorized for charging AND a new idToken is presented to the Charging Station for authorization, that differs from the initial idToken</td><td>The Charging Station SHOULD not allow the authorization of a different idToken.</td><td>Multiple idTokens for a transaction are most likely not supported by a CSMS.</td></tr><tr><td>C01.FR.24</td><td>When a transaction is still active, that had been authorized earlier by an idToken, but which is now no longer authorized for charging AND Charging Stations sends an AuthorizationRequest for a new idToken, that differs from the initial idToken of the transaction</td><td>The CSMS IS RECOMMENDED to respond with an AuthorizationResponse with idTokenInfo.status = NotAtThisTime for this idToken.</td><td>If a second authorization is done by Charging Station then CSMS can reject the idToken.</td></tr></table>
+
+# C02 - Authorization using a start button
+
+Table 61. C02 - Authorization using a start button
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization using a start button</td></tr><tr><td>2</td><td>ID</td><td>C02</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objectives</td><td>Make it possible for a Charging Station that has a start button to start charging.</td></tr><tr><td>4</td><td>Description</td><td>For some chargers authorization of a user might not be a requirement. A simple charger might have a button instead of a more expensive RFID reader to start charging. When such a Charging Station start charging, it is not needed to send anauthorizeRequest. In the TransactionEventRequest (eventType = Started), IdTokenType information needs to be given, which the CSMS then cannot reject.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver plugs in the charging cable between EV and Charging Station.
+2. The Charging Station sends a StatusNotificationRequest and TransactionEventRequest (eventType = Started) to notify the CSMS about the cable being plugged in.
+3. The EV Driver presses the start button to start Charging.
+4. The Charging Station starts Charging of the EV.
+5. The Charging Station sends a TransactionEventRequest (eventType = Updated) message with IdTokenEnumType: NoAuthorization to the CSMS to notify the CSMS of the charging that has started.
+6. Upon receipt of TransactionEventRequest (eventType = Updated), the CSMS responds with TransactionEventResponse with: IdTokenInfo.status set to Accepted</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFID
+C03 - Authorization using credit/debit card
+C04 - Authorization using PIN-code
+C05 - Authorization for CSMS initiated transactions
+C06 - Authorization using local id type
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station has a start button, instead of an RFID reader to start charging of an EV.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Transaction ongoing on Charging Station, CSMS is aware of transaction.</td></tr></table>
+
+
+Figure 22. Sequence Diagram: Authorization using a start button
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The start button might also be a mechanical key or something similar.
+Note that the start button can even be omitted if the Charging Station is configured to start charging upon cable connection.
+The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:
+TxStartPoint: EVConnected, Authorized, DataSigned, PowerPathClosed, EnergyTransfer This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use case: E01 - Start Transaction options.</td></tr></table>
+
+# C02 - Authorization using a start button - Requirements
+
+Table 62. C02 - Authorization using a start button - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C02.FR.01</td><td>When a transaction is started with a button.</td><td>The Charging Station SHALL send TransactionRequest with an IdTokenType of type: NoAuthorization and the field: idToken left empty (empty string).</td></tr><tr><td>C02.FR.02</td><td>CSMS receives a TransactionRequest with an IdTokenType of type: NoAuthorization</td><td>The CSMS SHALL respond with a TransactionResponse with IdTokenInfo.status set Accepted.</td></tr><tr><td>C02.FR.03</td><td>If the Charging Station has implemented an Authorization Cache AND the Charging Station receives IdTokenInfo for an IdTokenType of type NoAuthorization in any message</td><td>The Charging Station SHALL NOT store the information in its Authorization Cache.</td></tr></table>
+
+# C03 - Authorization using credit/debit card
+
+Table 63. C03 - Authorization using credit/debit card
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization using credit card</td></tr><tr><td>2</td><td>ID</td><td>C03</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objectives</td><td>Make it possible to start a transaction using a credit card.</td></tr><tr><td>4</td><td>Description</td><td>A Charging Station with a credit/debit card terminal built inside the housing, or belonging to a group of Charging Stations that has a central payment terminal/kiosk. An EV Driver uses his card to pay for charging. The transaction is authorized by the payment company, the CSMS receives a message from the Payment System, and send a RequestStartTransactionRequest to the Charging Station to start the transaction.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Payment System, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver plugs in the Charging Cable
+2. The Charging Station sends an StatusNotificationRequest and TransactionEventRequest (eventType = Started) to notify the CSMS about the cable being plugged in.
+3. The Driver uses the credit/debit card terminal to authorize/pay for charging.
+4. The terminal communicates with its own server/back-office.
+5. The Payment System sends a message to the CSMS authorizing the user.
+6. The CSMS generates a unique id to be used as IdToken for this transaction.
+7. The CSMS sends a RequestStartTransactionRequest with the generated IdToken to the Charging Station.
+8. The Charging Station accepts the RequestStartTransactionRequest by sending a RequestStartTransactionResponse with Accepted.
+9. The Charging Station start Charging of the EV.
+10. The Charging Station send an TransactionEventRequest (eventType = Updated) to notify the CSMS about the charging having started.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFID
+C02 - Authorization using a start button
+C04 - Authorization using PIN-code
+C05 - Authorization for CSMS initiated transactions
+C06 - Authorization using local id type
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station has a credit/debit card terminal, or belongs to a group of Charging Stations that has a central payment terminal, to start charging of an EV.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Transaction ongoing on Charging Station</td></tr></table>
+
+
+Figure 23. Sequence Diagram: Authorization using credit/debit card
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>This use case is an example of how the existing OCPP messages can be used to handle a transaction that is started with a credit/debit card, it is not required to implement a credit/debit card payment solution in this way.A Payment System may consist of multiple components handling the authorization of the user. The interface of these components and the communication between the Payment System and CSMS are not in scope of this document.Stopping a transaction started with a credit/debit card is not defined, this is left to the implementer, this could for example be: Unplugging the cable on the EV side and/or a stop button etc.The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:TxStartPoint: EVConnected, Authorized, DataSigned, PowerPathClosed, EnergyTransfer This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use case: E01 - Start Transaction options.</td></tr></table>
+
+# C03 - Authorization using credit/debit card - Requirements
+
+Table 64. C03 - Authorization using credit/debit card - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C03.FR.01</td><td>If the Charging Station receives a RequestStartTransactionRequest with an IdTokenType of type Central</td><td>The Charging Station SHALL NOT send anauthorizeRequest for the received IdTokenType.</td></tr><tr><td>C03.FR.02</td><td>If the Charging Station has implemented an Authorization Cache AND the Charging Station receives IdTokenInfo for an IdTokenType of type Central in any message</td><td>The Charging Station SHALL NOT store the information in its Authorization Cache.</td></tr></table>
+
+# C04 - Authorization using PIN-code
+
+This is an informative use case, its purpose is to demonstrate the use of the KeyCode id type. An other use of KeyCode is for example a licence plate number.
+
+Table 65. C04 - Authorization using PIN-code
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization using PIN-code</td></tr><tr><td>2</td><td>ID</td><td>C04</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objectives</td><td>To make it possible for a Charging Station that has a key entry terminal to authorize the PIN-code.</td></tr><tr><td>4</td><td>Description</td><td>When a Charging Station has a PIN-code entry terminal, an EV driver enters his/her PIN-code. This PIN-code is sent to the CSMS for validation using an AuthorizationRequest.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver wants to start or stop charging the EV and enters his/her PIN-code into the terminal.
+2. The Charging Station sends an AuthorizationRequest message, with the field: IdTokenEnumType set to KeyCode, to the CSMS to request authorization.
+3. Upon receipt of the AuthorizationRequest, the CSMS responds with an AuthorizationResponse. This response indicates whether or not the KeyCode is accepted by the CSMS.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFID
+C02 - Authorization using a start button
+C03 - Authorization using credit/debit card
+C05 - Authorization for CSMS initiated transactions
+C06 - Authorization using local id type
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station has a PIN-code entry terminal to start charging of an EV.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Transaction ongoing on Charging Station, CSMS is aware of transaction.</td></tr></table>
+
+
+Figure 24. Sequence Diagram: Authorization using PIN-code
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>When the PIN-code is validated in the Charging Station, instead of the CSMS, use case C02 - Authorization Using a Start button applies.</td></tr></table>
+
+# C04 - Authorization using PIN-code - Requirements
+
+Table 66. C04 - Authorization using PIN-code - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C04.FR.01</td><td>When the CSMS receives an AuthorizationRequest with a keyCode that is not valid at this Charging Station</td><td>The CSMS SHALL respond with an AuthorizationResponse message with status = Invalid.</td></tr><tr><td>C04.FR.02</td><td>When the CSMS receives an AuthorizationRequest with a keyCode that is valid and the EV Driver is allowed to charge at this Charging Station</td><td>The CSMS SHALL respond with an AuthorizationResponse message with status = Accepted.</td></tr><tr><td>C04.FR.03</td><td></td><td>A Charging Station MAY store keyCodes in the Authorization Cache.</td></tr><tr><td>C04.FR.04</td><td>If an idToken of type keyCode is used</td><td>The Charging Station or CSMS SHALL NOT show the IdToken in any logging. key codes should never appear in logs.</td></tr><tr><td>C04.FR.05</td><td></td><td>Language SHALL be specified as RFC-5646 tags, see: [RFC5646], for example: US English is: "en-US".</td></tr><tr><td>C04.FR.06</td><td>If an idToken of type keyCode is used</td><td>It is RECOMMENDED to take measures to prevent brute force attacks, for example by increasing backoff times after attempts to enter an incorrect keyCode.</td></tr></table>
+
+# C05 - Authorization for CSMS initiated transactions
+
+Table 67. C05 - Authorization for CSMS initiated transactions
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization for CSMS initiated transactions</td></tr><tr><td>2</td><td>ID</td><td>C05</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objectives</td><td>Enable the CSMS to start a transaction on a Charging Station with a server generated IdToken.</td></tr><tr><td>4</td><td>Description</td><td>When a CSMS needs to start a Transaction on a Charging Station for a Driver that has no RFID, or the RFID is not known. For Example, the EV Driver uses an App to start a transaction. The CSMS needs to determine an IdToken and tell the Charging Station this is not an RFID, so it should not be cached and an authorization is also not needed.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver uses his app to start a charging.
+2. The app sends a start request to the CSMS.
+3. The CSMS determines an IdToken. It can generate a unique id to be used as IdToken for this transaction or can use a token that is provided by the app (for example the ID of the contract of the user).
+4. The CSMS sends a RequestStartTransactionRequest with the IdToken from the previous step to the Charging Station.
+5. The Charging Station accepts the RequestStartTransactionRequest by sending a RequestStartTransactionResponse with Accepted.
+6. The Charging Station starts charging and sends a TransactionEventRequest (eventType = Updated) to notify the CSMS that chargingState has changed.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFID
+C02 - Authorization using a start button
+C03 - Authorization using credit/debit card
+C04 - Authorization using PIN-code
+C06 - Authorization using local id type
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Cable is plugged in.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Transaction ongoing on Charging Station</td></tr></table>
+
+
+Figure 25. Sequence Diagram: Authorization for CSMS initiated transactions
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>IdTokens MAY be (single use) virtual transaction authorization codes or virtual RFID tokens that deliberately use a non-standard UID format to avoid possible conflict with real UID values. These virtual single use IdTokens are sent with type Central and it is pointless to either cache or authorize these tokens.
+This use case uses an App as example, but this is not a requirement. This use case is valid for any RequestStartTransactionRequest with a server generated IdToken.
+The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:
+TxStartPoint: EVConnected, Authorized, DataSigned, PowerPathClosed, EnergyTransfer
+This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use case: E01 - Start Transaction options.
+This use case assumes that the configuration variable AuthorizationRemoteStart is false. See use cases F01 and F02 for requirements with AuthorizationRemoteStart.
+Other idTokenTypes can also be used to remote start charging, such an eMAID of the user that is provided by the app.</td></tr></table>
+
+# C05 - Authorization for CSMS initiated transactions Requirements
+
+Table 68. C05 - Authorization for CSMS initiated transactions Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C05.FR.01</td><td>If the Charging Station receives a RequestStartTransactionRequest with an IdTokenType of type Central.</td><td>The Charging Station SHALL NOT send anauthorizeRequest for the received IdTokenType.</td></tr><tr><td>C05.FR.02</td><td>If the Charging Station has implemented an Authorization Cache AND the Charging Station receives IdTokenInfo for an IdTokenType of type Central in any message</td><td>The Charging Station SHALL NOT store the information in its Authorization Cache.</td></tr><tr><td>C05.FR.03</td><td></td><td>The RemoteStartId SHALL be provided at least once in a TransactionEventRequest.</td></tr><tr><td>C05.FR.04</td><td></td><td>Language SHALL be specified as RFC-4646 tags, see: [RFC5646], example: US English is: "en-US".</td></tr><tr><td>C05.FR.05</td><td></td><td>idToken SHALL also be provided once in the first TransactionEventRequest after a RequestStartTransactionRequest.</td></tr></table>
+
+# C06 - Authorization using local id type
+
+This is an informative use case, its purpose is to demonstrate the use of the Local id type.
+
+Table 69. C06 - Authorization using local id type
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization using local id type</td></tr><tr><td>2</td><td>ID</td><td>C06</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objectives</td><td>Enable the Charging Station to start charging with a locally generated IdToken.</td></tr><tr><td>4</td><td>Description</td><td>When a Charging Station needs to start a Transaction for a Driver that has no RFID, or the RFID is not known. For Example, the EV Driver uses a parking ticket to start charging.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Payment Terminal, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. An EV driver drives into a garage, takes a parking ticket at the barrier at the entrance.
+2. Parks his EV at a Charging Station.
+3. Plugs in the charging cable.
+4. Scans/inserts his parking ticket on the Charging Station to start Charging
+5. EV is charging, driver leaves.
+6. EV driver returns, inserts parking ticket into a payment kiosk
+7. Pays for parking and charging
+8. The Payment terminal/kiosk sends a stop command via the CSMS to the Charging Station.
+9. EV driver unplugs the charging cable and drives away.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFID
+C02 - Authorization using a start button
+C03 - Authorization using credit/debit card
+C04 - Authorization using PIN-code
+C05 - Authorization for CSMS initiated transactions
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Integrated parking & charging payment system</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The transaction has completed at the Charging Station and Transaction information is available at the CSMS.</td></tr></table>
+
+
+Figure 26. Sequence Diagram: Authorization using local id type
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>This use case uses an Parking Ticket as example, but this is not a requirement.The communication between the Payment Terminal and the CSMS is outside of scope of OCPP.The scenario description and sequence diagram above are based on the Configuration Variable for start & stop transaction being configured as follows:TxStartPoint: Authorized, DataSigned, PowerPathClosed, EnergyTransferTxStopPoint: ParkingBayOccupancy, EVConnectedThis use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use cases: E01 - Start Transaction options and E06 - Stop Transaction options.</td></tr></table>
+
+# C06 - Authorization using local id type - Requirements
+
+Table 70. C06 - Authorization using local id type - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C06.FR.01</td><td></td><td>The Charging Station SHALL only offer energy after authorization.</td></tr><tr><td>C06.FR.02</td><td>If an IdTokenType with type Local is presented by the EV Driver.</td><td>The Charging Station SHALL send AuthorizationRequest to the CSMS to request authorization.</td></tr><tr><td>C06.FR.03</td><td></td><td>AuthorizationRequest SHOULD only be used for the authorization of an identifier for charging.</td></tr><tr><td>C06.FR.04</td><td>If the CSMS receives an AuthorizationRequest.</td><td>it SHALL respond with an AuthorizationResponse and SHALL include an authorization status value indicating acceptance or a reason for rejection.</td></tr></table>
+
+# 2.2. ISO 15118 Authorization
+
+This authorization section originates from ISO15118-1 for the use of Plug & Charge functionalities.
+
+# C07 - Authorization using Contract Certificates
+
+Table 71. C07 - Authorization using Contract Certificates
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization using Contract Certificates</td></tr><tr><td>2</td><td>ID</td><td>C07</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 D2</td></tr><tr><td>3</td><td>Objectives</td><td>See ISO15118-1, use case Objective D2, page 26.</td></tr><tr><td>4</td><td>Description</td><td>See ISO15118-1, use case Description D2 (first bullet), page 26.</td></tr><tr><td></td><td>Actors</td><td>Actors: EV, Charging Station, CSMS, OCSP</td></tr><tr><td></td><td>Scenario description</td><td>15118:See ISO15118-1, use case Description D2, Scenario Description, first 2 bullets, page 26.OCPP:3. The Charging Station sends an AuthorizationRequest message to the CSMS containing the eMAID and data needed for an OCSP request with regards to the contract certificate and certificate chain.4. The CSMS replies with an agreement or non-agreement, and the certificate status.5. Service starts after successful authorization of the IDs.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFIDC02 - Authorization using a start buttonC03 - Authorization using credit/debit cardC04 - Authorization using PIN-codeC05 - Authorization for CSMS initiated transactionsC06 - Authorization using local id typeC08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>A contract Certificate is installed in the EV.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The validity of the Contract Certificate is determined.</td></tr></table>
+
+
+Figure 27. Authorization using Contract Certificates
+
+<table><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>In edition 1 of 15118, the message timeout of the PaymentDetailsReq/Res message is 5 seconds. In case certificate verification cannot be completed in that time it is possible to complete this during the AuthorizationReq/Res, which can be extended up to 60 seconds.When the Charging Station is offline, it is recommended to omit the payment option for ISO 15118 contract certificates from the ServiceDiscoveryRes and revert to External Identification Means (use case C08), because certificate status cannot be checked.</td></tr></table>
+
+# C07 - Authorization using Contract Certificates - Requirements
+
+Table 72. C07 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C07.FR.01</td><td>When Charging Station is online</td><td>The Charging Station SHALL send an AuthorizationRequest to the CSMS for validation.</td><td></td></tr><tr><td>C07.FR.02</td><td>C07.FR.01</td><td>The AuthorizationRequest SHALL contain the eMAID and data needed for an OCSP request with regards to the contract certificate and certificate chain.</td><td></td></tr><tr><td>C07.FR.04</td><td>If the CSMS receives an AuthorizationRequest.</td><td>It SHALL respond with an AuthorizationResponse and SHALL include an authorization status value indicating acceptance or a reason for rejection.</td><td></td></tr><tr><td>C07.FR.05</td><td>C07.FR.02</td><td>The CSMS SHALL verify validity of the certificate and certificate chain via real-time orcached OCSP data.</td><td></td></tr><tr><td>C07.FR.06</td><td>C07.FR.01 AND If Charging Station is not able to validate a contract certificate, because it does not have the associated root certificate AND CentralContractValidationAllowed is true</td><td>The Charging Station SHALL pass the contract certificate chain to the CSMS in certificate attribute (in PEM format) of AuthorizationRequest for validation by CSMS.</td><td></td></tr><tr><td>C07.FR.07</td><td>When Charging Station is offline AND ContractValidationOffline is false</td><td>The Charging Station SHALL NOT allow charging.</td><td></td></tr><tr><td>C07.FR.08</td><td>When Charging Station is offline AND ContractValidationOffline is true</td><td>The Charging Station SHALL try to validate the contract certificate locally.</td><td></td></tr><tr><td>C07.FR.09</td><td>C07.FR.08 AND Contract certificate is valid AND LocalauthorizeOffline is true</td><td>The Charging Station SHALL lookup the eMAID in Local Authorization List or Authorization Cache.</td><td></td></tr><tr><td>C07.FR.10</td><td>C07.FR.09 AND eMAID found in Local Authorization List</td><td>The Charging Station SHALL behave according to use case C13 - Offline Authorization through Local Authorization List.</td><td></td></tr><tr><td>C07.FR.11</td><td>C07.FR.09 AND eMAID found in Authorization Cache</td><td>The Charging Station SHALL behave according to use case C12 - Start Transaction - Cached Id.</td><td></td></tr><tr><td>C07.FR.12</td><td>C07.FR.09 AND eMAID is not found AND OfflineTxForUnknownIdEnabled = true</td><td>The Charging Station SHALL allow charging according to use case C15 - Offline Authorization of unknown Id.</td><td></td></tr><tr><td>C07.FR.13</td><td>C07.FR.04 AND the certificate chain (provided in certificate or iso15118CertificateHashData) is valid AND authorization status of idToken is one of blocked, Expired, Invalid, Unknown</td><td>CSMS SHALL return an AuthorizationResponse containing a certificateStatus = ContractCancelled and the authorization status in idTokenInfo.status.</td><td>Certificate is valid, but EMAID is not accepted.</td></tr><tr><td>C07.FR.14</td><td>C07.FR.04 AND the certificate chain (provided in certificate or iso15118CertificateHashData) is valid AND authorization status of idToken is NOT one of blocked, Expired, Invalid, Unknown</td><td>CSMS SHALL return an AuthorizationResponse containing a certificateStatus = Accepted and the authorization status in idTokenInfo.status.</td><td>Charging can still not be allowed if idTokenInfo.status is other than Accepted (e.g. ConcurrentTx or NotAtThisLocation).</td></tr><tr><td>C07.FR.15</td><td>C07.FR.04 AND the certificate chain (provided in certificate or iso15118CertificateHashData) has expired</td><td>CSMS SHALL return an AuthorizationResponse containing a certificateStatus = CertificateExpired and an idTokenInfo.status = Expired</td><td>If certificate is expired, then status of idToken is also reported expired.</td></tr><tr><td>C07.FR.16</td><td>C07.FR.04 AND the certificate chain (provided in certificate or iso15118CertificateHashData) has been revoked</td><td>CSMS SHALL return an AuthorizationResponse containing a certificateStatus = CertificateRevoked and an idTokenInfo.status = Invalid</td><td>If certificate is revoked, then status of idToken is reported as invalid.</td></tr><tr><td>C07.FR.17</td><td>C07.FR.04 AND the certificate chain (provided in certificate or iso15118CertificateHashData) cannot be verified or is invalid</td><td>CSMS SHALL return an AuthorizationResponse containing a certificateStatus = CertChainError and an idTokenInfo.status = Invalid</td><td>If certificate is cannot be verified, then status of idToken is reported as invalid.</td></tr></table>
+
+# C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+
+Table 73. C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization at EVSE using ISO 15118 External Identification Means (EIM)</td></tr><tr><td>2</td><td>ID</td><td>C08 / 15118-1 D4</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 D4</td></tr><tr><td>3</td><td>Objectives</td><td>To authorize the EV via the Charging Station, with help of the CSMS. Also see ISO15118-1, use case Objective D4, page 28.</td></tr><tr><td>4</td><td>Description</td><td>The Charging Station sends an AuthorizationRequest message based on information provided by the EV. Also see ISO15118-1, use case Description D4 up to and including "NOTE", page 28.</td></tr><tr><td></td><td>Actors</td><td>Actors: EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>15118See ISO15118-1, use case Description (Scenarios Description) D4, page 28.OCPP1. The Charging Station sends an AuthorizationRequest with an idToken containing the External Identification Means (EIM).2. The CSMS responds with an AuthorizationResponse.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFIDC02 - Authorization using a start buttonC03 - Authorization using credit/debit cardC04 - Authorization using PIN-codeC05 - Authorization for CSMS initiated transactionsC06 - Authorization using local id typeC07 - Authorization using Contract CertificatesC15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Communication between EV and EVSE SHALL be established successfully.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Authorization is successful. Also see ISO15118-1, use case End conditions D4, page 28.</td></tr></table>
+
+
+Figure 28. Sequence Diagram: Authorization at EVSE using external credentials performed with help of SA.
+
+<table><tr><td>7</td><td>Remark(s)</td><td>Please note that all identification means mentioned in the previous section can be applied to this use case. The only difference is the availability of 15118 communication.</td></tr></table>
+
+Source: ISO15118-1
+
+# C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM) - Requirements
+
+Table 74. C08 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C08.FR.01</td><td></td><td>The Charging Station SHALL send the identification to the CSMS for validation.</td></tr><tr><td>C08.FR.02</td><td></td><td>EV Driver SHALL activate the authorization within a specific time after connecting the EV to the EVSE or the EVSE SHALL have an HMI to authorize the restart of the identification process.</td></tr></table>
+
+# 2.3. Groupld
+
+# C09 - Authorization by Groupld
+
+Table 75. C09 - Authorization by Groupld
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization by GroupId</td></tr><tr><td>2</td><td>ID</td><td>C09</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable 2 EV drivers with different IdTokens to be authorized using the same GroupId.</td></tr><tr><td>4</td><td>Description</td><td>This use cases covers how a Charging Station can authorize an action for an EV Driver based on GroupId information. This could for example be used if 2 people regularly use the same EV: they can use their own IdToken (e.g. RFID card), and can deauthorize transactions that were started with the other idToken (with the same GroupId).</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver1, EV Driver2</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver 1 presents an IdToken.
+2. The Charging Station sends AuthorizationRequest to the CSMS to request authorization.
+3. Upon receipt of AuthorizationRequest, the CSMS responds with AuthorizationResponse. This response message includes the GroupId.
+4. The Charging Station stores the GroupIdToken with the authorization information of EV Driver 1.
+5. EV Driver 2 presents an IdToken.
+6. The Charging Station sends AuthorizationRequest to the CSMS to request authorization.
+7. Upon receipt of AuthorizationRequest, the CSMS responds with AuthorizationResponse. This response message includes the GroupId.
+8. Based on the matching GroupId information in both responses, the Charging Station authorizes the action.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>EV Driver 1 and EV Driver 2 have the same GroupId.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>GroupId is known by the Charging Station.</td></tr></table>
+
+
+Figure 29. Sequence Diagram: Authorization by Groupld
+
+Table 76. C09 - Requirements
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Id-TokenType data used as groupld may often use a shared central account identifier for the Groupld, instead of using one of the Tokens belonging to an account.
+The groupld mechanism as described in this use case also works when using the Authorization Cache, as the groupld is stored in the cache.</td></tr></table>
+
+# C09 - Authorization by Groupld - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C09.FR.02</td><td></td><td>IdTokens that are part of the same group for authorization purposes SHALL have a common group identifier in the optional groupldToken element in IdTokenInfo</td></tr><tr><td>C09.FR.03</td><td>When a transaction has been authorized/started with a certain IdToken.</td><td>An EV Driver with a different, valid IdToken, but with the same groupldToken SHALL be authorized to stop the transaction.</td></tr><tr><td>C09.FR.04</td><td>C09.FR.03 AND If both IdTokens with their corresponding GroupldTokens are present in either the Local Authorization List or Authorization Cache.</td><td>The Charging Station MAY send an InvalidateRequest to the CSMS.</td></tr><tr><td>C09.FR.05</td><td>C09.FR.03 AND (NOT C09.FR.07) AND If the newly presented IdToken with its corresponding GroupldToken is not present in either the Local Authorization List or Authorization Cache.</td><td>The Charging Station SHALL send an InvalidateRequest to the CSMS.</td></tr><tr><td>C09.FR.07</td><td>When an idToken is presented during a transaction that has been authorized AND (a) the presented idToken is the same as the idToken that started the authorization OR (b) when the presented idToken is in the Local Authorization List or Authorization Cache AND is valid AND has the same GroupldToken as the IdToken that started the authorization.</td><td>The Charging Station SHALL end the authorization of the transaction, without first sending an InvalidateRequest</td></tr><tr><td>C09.FR.09</td><td>If the IdToken in InvalidateRequest has an associated groupldToken</td><td>AuthorizationResponse from CSMS SHALL include groupldToken.</td></tr><tr><td>C09.FR.10</td><td></td><td>AuthorizationResponse SHALL include an authorization status value indicating acceptance or a reason for rejection.</td></tr><tr><td>C09.FR.11</td><td>C09.FR.03 AND A different IdToken is presented for stopping, which has the same GroupldToken, but does not have status = Accepted</td><td>The Charging Station SHALL NOT stop the transaction.</td></tr><tr><td>C09.FR.12</td><td>If a TransactionEventRequest contains an IdToken and idToken has an associated groupldToken</td><td>TransactionEventResponse from CSMS SHALL include groupldToken.</td></tr></table>
+
+# 2.4. Authorization Cache
+
+# C10 - Store Authorization Data in the Authorization Cache
+
+Table 77. C10 - Store Authorization Data in Authorization Cache
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Store Authorization Data in the Authorization Cache</td></tr><tr><td>2</td><td>ID</td><td>C10</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objective(s)</td><td>To store all the latest received IdTokens in the Authorization Cache.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the Charging Station autonomously stores a record of previously presented identifiers that have been successfully authorized by the CSMS in the Authorization Cache. (Successfully meaning: a response received on a message containing an IdToken)</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station receives a AuthorizationResponse, ReserveNowRequest or TransactionEventResponse response message from the CSMS.
+2. The Cache is updated by the Charging Station using all received IdTokenInfo from the response message from the CSMS.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>n/a</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>An Authorization Cache is implemented and and the value of the AuthCacheEnabled Configuration Variable is set to 'true'.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station stored the newly received IdTokenInfo data in the Authorization Cache.
+Failure postcondition:
+The Charging Station was not able to store the Authorization Cache.</td></tr></table>
+
+
+Figure 30. Sequence Diagram: Store Authorization Data in the Authorization Cache
+
+Table 78. C10 - Requirements
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# C10 - Store Authorization Data in the Authorization Cache - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C10.FR.01</td><td></td><td>The Authorization Cache SHALL contain all the latest received identifiers (regardless of their status).</td><td></td></tr><tr><td>C10.FR.02</td><td></td><td>Cache values SHOULD be persistent across reboots and power outages.</td><td>Hence cache values SHOULD be stored in non-volatile memory.</td></tr><tr><td>C10.FR.03</td><td>When an IdToken is presented that is stored in the Authorization Cache with status other than Accepted, and the Charging Station is online.</td><td>AuthorizationRequest SHALL be sent to the CSMS to check the current state of the IdToken.</td><td>To check the current state of the identifier.</td></tr><tr><td>C10.FR.04</td><td>Upon receipt of AuthorizationResponse.</td><td>The Charging Station SHALL update the Authorisation Cache entry.</td><td>The update is to be done with the IdTokenInfo value from the response as described under Authorization Cache.</td></tr><tr><td>C10.FR.05</td><td>Upon receipt of TransactionEventResponse.</td><td>The Charging Station SHALL update the Authorisation Cache entry.</td><td>The update is to be done with the IdTokenInfo value from the response as described under Authorization Cache.</td></tr><tr><td>C10.FR.07</td><td></td><td>The Charging Station SHALL have a mechanism to accept new cache entries even when it is full, by deleting older entries.</td><td>It is suggested to remove any entries with status other than Accepted first, and then the oldest valid entries to make space for the new entry.</td></tr><tr><td>C10.FR.08</td><td>When IdTokenInfoType does not contain a value for cacheExpiryDateTime</td><td>The time a token is considered to be present in the cache is determined by the Configuration Variable AuthCacheLifeTime. This variable indicates how long it takes until a token expires in the Authorization Cache since it is last used.</td><td>This expiry of the cache is not the same as the expiration date that is set for the IdToken (e.g. RFID card expiry date).</td></tr><tr><td>C10.FR.09</td><td>The Charging Station supports Tariff & Cost</td><td>The Charging Station SHALL NOT store the tariff information in the Cache.</td><td></td></tr><tr><td>C10.FR.10</td><td>When the validity of an Authorization Cache entry expires.</td><td>The Authorization Cache entry SHALL be removed from the cache or changed to Expired.</td><td></td></tr><tr><td>C10.FR.11</td><td></td><td>Whether the Authorization Cache is enabled or disabled SHALL be controlled by the AuthCacheEnabled Configuration Variable.</td><td></td></tr><tr><td>C10.FR.12</td><td></td><td>It is RECOMMENDED to store personal information in the Authorization Cache securely</td><td>E.g. by only storing hashed idTokens in the cache.</td></tr><tr><td>C10.FR.13</td><td>When IdTokenInfoType contains a value for cacheExpiryDateTime</td><td>The time a token is considered to be present in the cache is determined by cacheExpiryDateTime. This variable indicates the date and time after which a token expires in the Authorization Cache.</td><td>This expiry of the cache is not the same as the expiration date that is set for the IdToken (e.g. RFID card expiry date).</td></tr></table>
+
+# C11 - Clear Authorization Data in Authorization Cache
+
+Table 79. C11 - Clear Authorization Data in Authorization Cache
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Clear Authorization Data in Authorization Cache</td></tr><tr><td>2</td><td>ID</td><td>C11</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objective(s)</td><td>To clear all IdTokens in the Authorization Cache.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS can request a Charging Station to clear its Authorization Cache.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS requests the Charging Station to clear its Authorization Cache by sending ClearCacheRequest.
+2. The Charging Station responds with the status Accepted.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Authorization Cache is supported and enabled by the AuthCacheEnabled Configuration Variable.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station Successfully cleared the Authorization Cache.
+Failure postcondition:
+The Charging Station was not able to clear the Authorization Cache.</td></tr></table>
+
+
+Figure 31. Sequence Diagram: Clear Authorization Data in Authorization Cache
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# C11 - Clear Authorization Data in Authorization Cache - Requirements
+
+Table 80. C11 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C11.FR.01</td><td>If the CSMS sends a ClearCacheRequest.</td><td>The Charging Station SHALL attempt to clear its Authorization Cache.</td></tr><tr><td>C11.FR.02</td><td>C11.FR.01</td><td>The Charging Station SHALL send ClearCacheResponse message indicating whether it was able to clear its Authorization Cache.</td></tr><tr><td>C11.FR.03</td><td>C11.FR.02 AND Charging Station successfully cleared its Authorization Cache.</td><td>The Charging Station SHALL send ClearCacheResponse message with the status Accepted.</td></tr><tr><td>C11.FR.04</td><td>C11.FR.02 AND Configuration variable AuthCacheEnabled is false</td><td>The Charging Station SHALL send ClearCacheResponse message with the status Rejected.</td></tr><tr><td>C11.FR.05</td><td>C11.FR.02 AND Charging Station failed to clear its Authorization Cache.</td><td>The Charging Station SHALL send ClearCacheResponse message with the status Rejected.</td></tr></table>
+
+# C12 - Start Transaction - Cached Id
+
+Table 81. C12 - Start Transaction - Cached Id
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Start Transaction - Cached Id</td></tr><tr><td>2</td><td>ID</td><td>C12</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the EV Driver to Online start a transaction by using the Authorization Cache. So the Charging Station can respond faster, as no AuthorizationRequest is being sent.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver plugs in the cable.
+2. The Charging Station starts the transaction.
+3. The EV Driver presents an IdToken.
+4. The Charging Station verifies the IdToken with the Authorization Cache.
+5. The Charging Station updates the transaction.
+6. The Charging Station starts charging.
+7. E02 - Start Transaction - Cable Plugin First applies.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>AuthCacheEnabled = true
+LocalPreAuthorization = true
+The Id of the EV Driver is Cached in the Authorization Cache
+Id is valid</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The EV Driver is authorized to start a transaction by using the Authorization Cache.
+Failure postcondition:
+The UserId was not found in the Authorization Cache and:
+* Online Charging Station: the Charging Station issues an AuthorizationRequest and that fails too.
+* In an offline situation, behaviour of the Charging Station is defined by Configuration Variable OfflineTxForUnknownIdEnabled.</td></tr></table>
+
+
+Figure 32. Sequence Diagram: Start Transaction - Cached Id
+
+<table><tr><td>7</td><td>Error handling</td><td>When the Charging Station has an IdToken in the Authorization Cache, which is valid in the Authorization Cache, but is no longer valid in the CSMS: The Charging Station will receive the IdTokenInfo in the TransactionEventResponse which contains the newer invalid status. What happens in such a cases depends on the Configuration Variables: MaxEnergyOnInvalidId and StopTxOnInvalidId.</td></tr><tr><td>8</td><td>Remark(s)</td><td>If the Charging Station has implemented an Authorization Cache, then upon receipt of a AuthorizationResponse message the Charging Station updates the Cache entry.For a Cached valid IdToken it is not logical to send AuthorizationRequest. The TransactioneventResponse message also contains the IdToken information. If the IdToken has become no longer valid, the Charging Station will learn this from this TransactioneventResponse. So if the IdToken is no longer valid, the Charging Station might decide to stop the energy offering, and depending on the configuration even stop the transaction.The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:TxStartPoint: EVConnected, Authorized, DataSigned, PowerPathClosed, EnergyTransfer This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use case: E01 - Start Transaction options.</td></tr></table>
+
+# C12 - Start Transaction - Cached Id - Requirements
+
+Table 82. C12 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C12.FR.02</td><td>When an identifier is presented that is stored in the Authorization Cache as Accepted.</td><td>The Charging Station SHALL send a TransactionRequest with idToken to the CSMS.</td><td></td></tr><tr><td>C12.FR.03</td><td>C12.FR.02</td><td>The CSMS SHALL check the authorization status of the IdToken when processing this TransactionRequest.</td><td></td></tr><tr><td>C12.FR.04</td><td>C12.FR.02 AND The cable is plugged in.</td><td>The Charging Station SHALL start the energy offer.</td><td></td></tr><tr><td>C12.FR.05</td><td>When an identifier is presented that is stored in the Authorization Cache with status other than Accepted, and the Charging Station is online.</td><td>The Charging Station SHALL send anauthorizeRequest to the CSMS.</td><td>To check the current state of the identifier.</td></tr><tr><td>C12.FR.06</td><td>When IdTokenInfo is received for an identifier in the Cache.</td><td>The Authorization Cache SHALL be updated using the received IdTokenInfo.</td><td></td></tr><tr><td>C12.FR.09</td><td>IdTokens that have a groupId equal to MasterPassGroupId</td><td>SHALL NOT be allowed to start a transaction.</td><td></td></tr></table>
+
+# 2.5. Local Authorization list
+
+# C13 - Offline Authorization through Local Authorization List
+
+Table 83. C13 - Offline Authorization through Local Authorization List
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Offline Authorization through Local Authorization List</td></tr><tr><td>2</td><td>ID</td><td>C13</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objective(s)</td><td>To authorize an idToken by using the Local Authorization List while Offline.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how to authorize an IdToken, when communication with the CSMS is not possible.The Local Authorization List is a list of idTokens that can be synchronized with the CSMS. The list contains the authorization status of a selected set of idTokens as managed by the CSMS.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station is Offline2. The EV Driver presents IdToken.3. The Charging Station checks if the IdToken is known and has status Accepted in the Local Authorization List.4. The Charging Station start charging.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Local Authorization List is availableLocal Authorization List is enabled via LocalAuthListEnabledCharging Station is OfflineThe Id of the EV Driver is in the Local Authorization ListId is valid</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The Charging Station accepts tokens on the Local Authorization List when it is offline.Failure postcondition:The Charging Station does not accept tokens on the Local Authorization List when it is offline.</td></tr></table>
+
+
+Figure 33. Sequence Diagram: Offline Authorization through Local Authorization List
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# C13 - Offline Authorization through Local Authorization List - Requirements
+
+Table 84. C13 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C13.FR.01</td><td></td><td>Where both Authorization Cache and Local Authorization List are supported, a Charging Station SHALL treat Local Authorization List entries as having priority over Authorization Cache entries for the same identifiers.</td><td></td></tr><tr><td>C13.FR.02</td><td>If configuration variable OfflineTxForUnknownIdEnabled is false AND The Charging Station is offline AND LocalAuthListSupportsExpiryDateTime does not exist or is false</td><td>Only identifiers that are present in a Local Authorization List that have a status Accepted SHALL be allowed to authorize a transaction.</td><td>This means that Charging Station does not check for cacheExpiryDateTime.</td></tr><tr><td>C13.FR.03</td><td></td><td>The Charging Station MAY authorize the IdToken locally without involving the CSMS.</td><td>As described in Local Authorization List.</td></tr><tr><td>C13.FR.04</td><td>If configuration variable OfflineTxForUnknownIdEnabled is true AND The Charging Station is offline AND LocalAuthListSupportsExpiryDateTime does not exist or is false</td><td>Any identifier that is present in neither the Authorization Cache nor the Local Authorization List SHALL be allowed to authorize a transaction AND any identifiers that are present in a Local Authorization List that have a status Accepted SHALL be allowed to authorize a transaction.</td><td>This means that Charging Station does not check for cacheExpiryDateTime. See also C15.FR.08</td></tr><tr><td>C13.FR.05</td><td>If configuration variable OfflineTxForUnknownIdEnabled is false AND The Charging Station is offline AND LocalAuthListSupportsExpiryDateTime = true</td><td>Only identifiers that are present in a Local Authorization List that have a status Accepted and for which cacheExpiryDateTime has not passed SHALL be allowed to authorize a transaction.</td><td>When cacheExpiryDateTime is absent, the idToken will not expire in Local Authorization List.</td></tr><tr><td>C13.FR.06</td><td>If configuration variable OfflineTxForUnknownIdEnabled is true AND The Charging Station is offline AND LocalAuthListSupportsExpiryDateTime = true</td><td>Any identifier that is present in neither the Authorization Cache nor the Local Authorization List SHALL be allowed to authorize a transaction AND any identifiers that are present in a Local Authorization List that have a status Accepted and for which cacheExpiryDateTime has not passed SHALL be allowed to authorize a transaction.</td><td>This means that an expired token in the Local Authorization List is not authorized, because it is not an "unknown id".</td></tr></table>
+
+# C14 - Online Authorization through Local Authorization List
+
+Table 85. C14 - Online Authorization through Local Authorization List
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Online Authorization through Local Authorization List</td></tr><tr><td>2</td><td>ID</td><td>C14</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objective(s)</td><td>To authorize an idToken by using the Local Authorization List while Online.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. When online the Charging Station can then locally authorize the IdToken, and is not required to send an AuthorizationRequest for a known IdToken.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver presents IdToken
+2. The Charging Station checks if the IdToken is known and has status Accepted in the Local Authorization List.
+3. If the IdToken is not known, or the IdToken is not Accepted the Charging Station sends an AuthorizationRequest
+4. The Charging Station starts charging.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Local Authorization List is available
+Local Authorization List is enabled via LocalAuthListEnabled
+The Id of the EV Driver is in the Local Authorization List
+Id is valid LocalPreAuthorization is set to true</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station accepts tokens on the Local Authorization List.
+Failure postcondition:
+The Charging Station does not accept tokens on the Local Authorization List.</td></tr></table>
+
+
+Figure 34. Sequence Diagram: Online Authorization through Local Authorization List
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# C14 - Online Authorization through Local Authorization List - Requirements
+
+Table 86. C14 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C14.FR.01</td><td></td><td>Where both Authorization Cache and Local Authorization List are supported, a Charging Station SHALL treat Local Authorization List entries as having priority over Authorization Cache entries for the same identifiers.</td><td></td></tr><tr><td>C14.FR.02</td><td>Identifier presented is in the Local Authorization List with a status Accepted AND LocalAuthListSupportsExpiryDateTime does not exist or is false</td><td>The Charging Station SHALL start charging without sending an InvalidateRequest.</td><td>This means that Charging Station d_cacheExpiryDateTime_oes not check for .</td></tr><tr><td>C14.FR.03</td><td>Identifiers presented is in the Local Authorization List with a status OTHER than Accepted</td><td>The Charging Station SHALL send an InvalidateRequest to try to authorize this IdToken.</td><td></td></tr><tr><td>C14.FR.04</td><td>Identifier presented is in the Local Authorization List with a status Accepted AND LocalAuthListSupportsExpiryDateTime = true AND the cacheExpiryDateTime has not passed</td><td>The Charging Station SHALL start charging without sending an InvalidateRequest.</td><td>When cacheExpiryDateTime is absent, the idToken will not expire in Local Authorization List.</td></tr><tr><td>C14.FR.05</td><td>Identifier presented is in the Local Authorization List with a status Accepted AND LocalAuthListSupportsExpiryDateTime = true AND the cacheExpiryDateTime has passed</td><td>The Charging Station SHALL send an InvalidateRequest to try to authorize this IdToken.</td><td>IdToken will be disregarded, as if not present in Local Authorization List, when cacheExpiryDateTime has passed.</td></tr></table>
+
+# 2.6. Offline Authorization
+
+# C15 - Offline Authorization of unknown Id
+
+Table 87. C15 - Offline Authorization of unknown Id
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Offline Authorization of unknown Id</td></tr><tr><td>2</td><td>ID</td><td>C15</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td></td><td>Parent use case</td><td>C12 - Start Transaction - Cached Id</td></tr><tr><td>3</td><td>Objective(s)</td><td>To allow automatic authorization of any "unknown" identifiers that cannot be explicitly authorized by Authorization Cache entries.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes the scenario of presented "unknown" identifiers, other than are present in an Authorization Cache or Local Cache entry using OfflineTxForUnknownIdEnabled.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver wants to start charging the EV and presents the IdToken.
+2. The Charging Station checks the Authorization Cache, the IdToken is not present in the Authorization Cache.
+3. The Charging Station checks the Local Authorization List, the IdToken is not present in the Local Authorization List.
+4. The Charging Station accepts the unknown IdToken if OfflineTxForUnknownIdEnabled is set True
+5. The Charging Station rejects the unknown IdToken if OfflineTxForUnknownIdEnabled is set False</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFID
+C02 - Authorization using a start button
+C03 - Authorization using credit/debit card
+C04 - Authorization using PIN-code
+C05 - Authorization for CSMS initiated transactions
+C06 - Authorization using local id type
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station is Offline.
+Unknown IdToken presented (Not in the Authorization Cache and/or Local Authorization List).</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The authorization status in TransactionResponse is Accepted.
+Failure postcondition:
+The authorization status in TransactionEventResponse is not Accepted when OfflineTxForUnknownIdEnabled is True.</td></tr></table>
+
+
+Figure 35. Sequence Diagram: Start Transaction - Unknown Offline Authorization
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>This applies to all types of identifiers, including an eMAID that is presented as part of an ISO 15118 contract certificate.</td></tr></table>
+
+# C15 - Offline Authorization of unknown Id - Requirements
+
+Table 88. C15 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C15.FR.01</td><td>If the identifier is authorized via OfflineTxForUnknownIdEnabled</td><td>The Charging Station SHALL NOT add the token to Authorization Cache</td><td></td></tr><tr><td>C15.FR.02</td><td>When connection to the CSMS is restored</td><td>The Charging Station SHALL send a TransactionEventRequest for any transaction that was authorized offline.</td><td>As explained in transaction-related message handling</td></tr><tr><td>C15.FR.03</td><td>C15.FR.02 AND The authorization status in TransactionEventResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is true AND TxStopPoint does NOT contain: (Authorized OR PowerPathClosed OR EnergyTransfer)</td><td>The Charging Station SHALL stop the energy transfer and send TransactionRequest (eventType = Updated) with triggerReason set to Deauthorized and chargingState set to SuspendedEVSE or preferably to EVConnected.</td><td>Since the effect of setting chargingState to SuspendedEVSE or EVConnected both have the same effect of not delivering any energy, the use of SuspendedEVSE is still allowed in this situation in order to avoid breaking existing implementations that adhere to the original requirement.Use of SuspendedEVSE in this situation will become deprecated in the next OCPP release.</td></tr><tr><td>C15.FR.04</td><td>C15.FR.02 AND The authorization status in TransactionEventResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is true AND TxStopPoint does contain: (Authorized OR PowerPathClosed OR EnergyTransfer)</td><td>The Charging Station SHALL stop the transaction and send TransactionRequest (eventType = Ended) with triggerReason set to Deauthorized and stoppedReason set to DeAuthorized.</td><td></td></tr><tr><td>C15.FR.05</td><td>C15.FR.04 AND If the Charging Station has the possibility to lock the Charging Cable</td><td>The Charging Station SHOULD keep the Charging Cable locked until the owner presents his identifier.</td><td></td></tr><tr><td>C15.FR.06</td><td>C15.FR.02 AND The authorization status in TransactionEventResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is set to false AND MaxEnergyOnInvalidId is not implemented or has been exceeded. TxStopPoint does NOT contain: EnergyTransfer</td><td>The Charging Station SHALL stop the energy delivery to the EV immediately and send TransactionRequest (eventType = Updated) with triggerReason set to ChargingStateChanged and chargingState set to SuspendedEVSE</td><td></td></tr><tr><td>C15.FR.07</td><td>C15.FR.02 AND The authorization status in TransactionEventResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is set to false AND MaxEnergyOnInvalidId is set and has NOT been exceeded.</td><td>Energy delivery to the EV SHALL be allowed until the amount of energy specified in MaxEnergyOnInvalidId has been reached.</td><td></td></tr><tr><td>C15.FR.08</td><td>When an unknown identifier is presented AND OfflineTxForUnknownIdEnabled is set to true</td><td>The Charging Station SHALL accept the presented IdToken.</td><td></td></tr></table>
+
+# 2.7. Master Pass
+
+# C16 - Stop Transaction with a Master Pass
+
+Table 89. C16 - Stop Transaction with a Master Pass
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Stop Transaction with a Master Pass</td></tr><tr><td>2</td><td>ID</td><td>C16</td></tr><tr><td></td><td>Functional block</td><td>C. Authorization</td></tr><tr><td>3</td><td>Objectives</td><td>Enable stopping of transactions by use of a Master Pass (for example for: Law Enforcement officials).</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how somebody with a Master Pass (User) can stop (selected) ongoing transactions, so the cable becomes unlocked. This Master Pass can be configured in: MasterPassGroupId.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, User</td></tr><tr><td></td><td>Scenario description</td><td>1. The User (Law Enforcement official) presents his IdToken at the Charging Station.
+2. The Charging Station sends AuthorizationRequest to the CSMS to request authorization.
+3. Upon receipt of AuthorizationRequest, the CSMS responds with AuthorizationResponse. This response message contains a GroupId that equals the value of the Configuration Variable MasterPassGroupId and the idToken is valid.
+4a. If the Charging Station has a UI, then the Charging Station "Shows" the Master Pass UI.
+5a. The user selects which transactions to stop.
+6a. The Charging Station stops the selected transaction(s) AND sends a TransactionEventRequest (eventType = Ended, stopReason = MasterPass) to the CSMS for every stopped transaction.
+7a. Upon receipt of TransactionEventRequest the CSMS responds with TransactionEventResponse.
+4b. If the Charging Station does NOT have a UI, then the Charging Station stops all transactions AND sends a TransactionEventRequest (eventType = Ended, stopReason = MasterPass) to the CSMS for every stopped transaction.
+5b. Upon receipt of TransactionEventRequest the CSMS responds with TransactionEventResponse.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Ongoing Transaction(s)
+Configuration Variable: MasterPassGroupId set.
+Users IdToken has groupId equal to the configured MasterPassGroupId.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>(Selected) transaction(s) stopped.</td></tr></table>
+
+
+Figure 36. Sequence Diagram: Stop Transaction with a Master Pass
+
+<table><tr><td>7</td><td>Error Handling</td><td>When the user does not make a selection before an acceptable timeout, the Charging Station SHALL go back to normal operation.</td></tr><tr><td>8</td><td>Remarks</td><td>The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.
+TxStopPoint: Authorized, DataSigned, PowerPathClosed, EnergyTransfer
+This use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are send. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+# C16 - Stop Transaction with a Master Pass - Requirements
+
+Table 90. C16 - Stop Transaction with a Master Pass - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C16.FR.01</td><td>User presents an IdToken that has a groupId equal to MasterPassGroupId AND The Charging Station has a UI.</td><td>The Charging Station SHALL "show" the Master Pass UI.</td></tr><tr><td>C16.FR.02</td><td>User presents an IdToken that has a groupId equal to MasterPassGroupId AND the Charging Station does NOT have a UI.</td><td>The Charging Station SHALL stop all ongoing transactions.</td></tr><tr><td>C16.FR.03</td><td>IdTokens that have a groupId equal to MasterPassGroupId</td><td>SHALL NOT be allowed to start a transaction.</td></tr><tr><td>C16.FR.04</td><td>IdTokens that have a groupId equal to MasterPassGroupId present in the Authorization Cache.</td><td>The Charging Station MAY also allow authorization of "Master Pass" tokens based on information in the Authorization Cache.</td></tr><tr><td>C16.FR.05</td><td>IdTokens that have a groupId equal to MasterPassGroupId present in the Local Authorization List.</td><td>The Charging Station MAY also allow authorization of "Master Pass" tokens based on information in the Local Authorization List.</td></tr></table>
+
+# D. LocalAuthorizationList Management
+
+# 1. Introduction
+
+As explained in C1.4 - Local Authorization List, the Local Authorization List is a list of identifiers that can be synchronized with the CSMS. It allows authorization of a user when offline and when online it can be used to reduce authorization response time. This Functional Block is for enabling the CSMS to synchronize the list by either sending a complete list of identifiers to replace the Local Authorization List or by sending a list of changes (add, update, delete) to apply to the Local Authorization List. The operations to support this are GetLocalListVersion and SendLocalList.
+
+The 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.
+
+# 2. Use cases & Requirements
+
+# D01 - Send Local Authorization List
+
+Table 91. D01 - Send Local Authorization List
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Send Local Authorization List</td></tr><tr><td>2</td><td>ID</td><td>D01</td></tr><tr><td></td><td>Functional block</td><td>D. Local Authorization List</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to send a Local Authorization List which a Charging Station can use for the authorization of idTokens.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS sends a Local Authorization List which a Charging Station can use for the authorization of idTokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a SendLocalListRequest to install or update the Local Authorization List.
+2. Upon receipt of the SendLocalListRequest the Charging Station responds with a SendLocalListResponse with its status.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Local Authorization List is enabled with Configuration Variable LocalAuthListEnabled.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+- A new Local Authorization List is installed on the Charging Station.
+Failure postcondition:
+- The Local Authorization List on the Charging Station stays as it was.
+- If the status is Failed or VersionMismatch.</td></tr></table>
+
+
+
+Figure 37. Sequence Diagram: Send Local Authorization List
+
+<table><tr><td>7</td><td>Error handling</td><td>If the status is Failed or VersionMismatch and the updateType was Differential, the CSMS will transmit the full Local Authorization List. When this list is too large for one message, it will start by sending an initial list with updateType Full and adding identifiers using updateType Differential until the list is completely sent (the amount of identifiers that can be sent in a single SendLocalListRequest is limited as described in requirement D01.FR.11).</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# D01 - Send Local Authorization List - Requirements
+
+Table 92. D01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>D01.FR.01</td><td></td><td>SendLocalListRequest SHALL contain the type of update (updateType) and a version number (versionNumber) that the Charging Station MUST associate with the Local Authorization List after it has been updated.</td><td></td></tr><tr><td>D01.FR.02</td><td></td><td>SendLocalListResponse SHALL indicate whether the Charging Station has accepted the update of the Local Authorization List</td><td></td></tr><tr><td>D01.FR.03</td><td>If the status in SendLocalListResponse is Failed or VersionMismatch and the updateType was Differential</td><td>It is RECOMMENDED that the CSMS sends the full Local Authorization List.</td><td>When this list is too large for one message (see D01.FR.11), it shall start by sending an initial list with updateType Full and adding identifiers using updateType Differential until the list is completely sent.</td></tr><tr><td>D01.FR.04</td><td>If no localAuthorizationList is given and the updateType is Full.</td><td>The Charging Station SHALL remove all IdTokens from the list.</td><td>Note, that the version number of the list is still updated to value of versionNumber in the request.</td></tr><tr><td>D01.FR.05</td><td></td><td>Requesting a Differential update without or with empty localAuthorizationList SHALL have no effect on the list.</td><td>Note, that the version number of the list is still updated to value of versionNumber in the request.</td></tr><tr><td>D01.FR.06</td><td></td><td>All IdTokens in the Local Authorization List SHALL be unique.</td><td>No duplicate values are allowed.</td></tr><tr><td>D01.FR.09</td><td></td><td>The Charging Station SHALL NOT modify the contents of the Authorization List by any other means than upon a the receipt of a SendLocalList message from the CSMS.</td><td></td></tr><tr><td>D01.FR.10</td><td></td><td>The Local Authorization List SHOULD be maintained by the Charging Station in non-volatile memory, and SHOULD be persisted across reboots and power outages.</td><td></td></tr><tr><td>D01.FR.11</td><td></td><td>The size of a single SendLocalListRequest is limited by the Configuration Variables ItemsPerMessageSendLocalList and BytesPerMessageSendLocalList.</td><td></td></tr><tr><td>D01.FR.12</td><td></td><td>A Charging Station that supports Local Authorization List SHALL implement the Configuration Variable: LocalAuthListEntries.</td><td>This gives the CSMS a way to know the current amount and maximum possible number of Local Authorization List elements in a Charging Station.</td></tr><tr><td>D01.FR.13</td><td></td><td>The Charging Station indicates whether the Local Authorization List is enabled. This is reported and controlled by the LocalAuthListEnabled Configuration Variable.</td><td></td></tr><tr><td>D01.FR.15</td><td>If the Charging Station receives a SendLocalListRequest with updateType is Full AND localAuthorizationList is non-empty</td><td>The Charging Station SHALL replace its current Local Authorization List with the one in the SendLocalListRequest and set the version number to the value specified in the message</td><td>Otherwise, there is no way to sync the initial Charging Station and CSMS lists. When this list is too large for one message (see D01.FR.11), it shall start by sending an initial list with_updateType_Full and adding identifiers using updateType Differential until the list is completely sent.</td></tr><tr><td>D01.FR.16</td><td>If the Charging Station receives a SendLocalListRequest with updateType is Differential AND localAuthorizationList contains AuthorizationData elements with idTokenInfo</td><td>The Charging Station SHALL update its Local Authorization List with these elements and set the version number to the value specified in the message.</td><td>Add them if not yet present, update with new information when already present in the Local Authorization List.</td></tr><tr><td>D01.FR.17</td><td>If the Charging Station receives a SendLocalListRequest with upgradeType is Differential AND localAuthorizationList contains AuthorizationData elements without idTokenInfo</td><td>The Charging Station SHALL remove these elements from its Local Authorization List and set the version number to the value specified in the message.</td><td></td></tr><tr><td>D01.FR.18</td><td></td><td>versionNumber in a SendLocalListRequest SHALL be greater than 0.</td><td>In GetLocalListVersionResponse the versionNumber = 0 has a special meaning: No Local List installed. So the value 0 should never be used.</td></tr><tr><td>D01.FR.19</td><td>If the Charging Station receives a SendLocalListRequest with upgradeType = Differential AND versionNumber is less or equal to the version number of its Local Authorization List</td><td>The Charging Station SHALL refuse to update its Local Authorization List and SHALL return a SendLocalListResponse with status set to VersionMismatch.</td><td></td></tr></table>
+
+# D02 - Get Local List Version
+
+Table 93. D02 - Get Local List Version
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Local List Version</td></tr><tr><td>2</td><td>ID</td><td>D02</td></tr><tr><td></td><td>Functional block</td><td>D. Local Authorization List</td></tr><tr><td></td><td>Parent use case</td><td>D01 - Send Local Authorization List</td></tr><tr><td>3</td><td>Objective(s)</td><td>To support synchronization of Local Authorization List.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS can request a Charging Station for the version number of the Local Authorization List by sending a GetLocalListVersionRequest.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a GetLocalListVersionRequest to request this value.
+2. Upon receipt of the GetLocalListVersionRequest Charging Station responds with a GetLocalListVersionResponse containing the version number of its Local Authorization List.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td></td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS received the GetLocalListVersionResponse with the Local Authorization List version.</td></tr></table>
+
+
+Figure 38. Sequence Diagram: Get Local List Version
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>A versionNumber of 0 (zero) is reserved to indicate that no local authorization list exists, either because it is not enabled or because it has not yet received any update from CSMS and thus does not have a version number to return.
+In contrast, a local authorization list that was emptied, because CSMS sent a SendLocalListRequest with an empty localAuthorizationList, does have a versionNumber > 0.</td></tr></table>
+
+# D02 - Get Local List Version - Requirements
+
+Table 94. D02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>D02.FR.01</td><td>LocalAuthListEnabled is true</td><td>When Charging Station receives GetLocalListVersionRequest then Charging Station SHALL respond with a GetLocalListVersionResponse containing the version number of its Local Authorization List.</td></tr><tr><td>D02.FR.02</td><td>LocalAuthListEnabled is true AND the CSMS has not yet sent any update to the Charging Station for Local Authorization List (via SendLocalListRequest)</td><td>When Charging Station receives GetLocalListVersionRequest then Charging Station SHALL respond with a GetLocalListVersionResponse with versionNumber is 0 (zero) to indicate that there is no Local Authorization List.</td></tr><tr><td>D02.FR.03</td><td>LocalAuthListEnabled is not true</td><td>When Charging Station receives GetLocalListVersionRequest then Charging Station SHALL respond with a GetLocalListVersionResponse with versionNumber is 0 (zero) to indicate that there is no Local Authorization List.</td></tr></table>
+
+# E. Transactions
+
+# 1. Introduction
+
+This Functional Block describes the OCPP Transaction related functionalities. Transactions are started/stopped on the Charging Station. Note that at most one transaction can be active on an EVSE at any point in time.
+
+# 1.1. Flexible transaction start/stop
+
+To support as many business cases as possible, and to prevent sending too many messages when not needed for certain business cases, OCPP 2.0.1 supports flexible configuration of the start and stop of a transaction.
+
+For this the following Configuration Variables are defined:
+
+- TxStartPoint
+ -TxStopPoint
+
+These 2 Configuration Variables make it possible to define when a transaction should start: TransactionRequest (eventType = Started) and when a transaction should stop: TransactionRequest (eventType = Ended)
+
+With the introduction in OCPP 2.0.1 of flexible start/stop points of a transaction, it is important to provide a definition of a transaction.
+
+A transaction is the portion of a charging session that is recorded by CSMS. It is a single time frame with a start and stop time. This information can be used by the operator for billing.
+
+It is up to the Charging Station Operator to define the values for TxStartPoint and TxStopPoint (unless these are preset as read-only values in the charging station), but not all combinations make sense.
+
+The following three variants are most common:
+
+- If connection time is billed, then start and stop points should be EVConnected.
+- If time of use is billed, then the start points should be EVConnected, Authorized and the stop point EVConnected. (Such that upon authorization first, the charger is already seen as 'in use').
+- If charging time is billed, then start and stop points should be PowerPathClosed. (This starts as soon as charger is ready to provide power and stops when authorization is revoked or vehicle disconnected.) Pauses in between (i.e. SuspendedEV(SE)) do not end the transaction. Billing on the amount of energy or power can be done based on the meter values that are collected during the transaction.
+
+# WARNING
+
+Certain combinations of start and stop points can lead to a situation where a started transaction is never stopped. For example: when the start point is ParkingBayOccupancy and the stop point is EVConnected, then a transaction starts when an EV occupies the parking bay, but when the user never connects the EV, but simply drives away, then the transaction will remain open, because ParkingBayOccupancy is not configured as a stop point.
+
+# 1.1.1. Readonly or Read/Write
+
+OCPP 2.0.1 supports 2 options for the transaction start/stop Configuration Variables. They can either be: RW (read-write) or R (read-only).
+
+When a Charging Station supports RW, the CSO can configure the settings. To support all possible settings, the software in the Charging Station has to be more flexible.
+
+With only R, the settings are fixed in firmware, the CSO can read the settings to learn how a Charging Station will behave, but cannot configure it. This makes for a simpler implementation. When the needs of the target market are well known there might be no need to implement the flexible model.
+
+# 1.1.2. OCPP 1.6 Transaction compatibility
+
+If transactions similar to OCPP 1.6 are wanted, this section describes how the transaction start and stop point should be configured.
+
+In OCPP 1.x the moment a Charging Station should send StartTransaction.req was not defined very precise, generally this was done when the Charging Station was ready to deliver energy: cable is connected and user is authorized.
+
+To support similar transaction start behaviour, the value: PowerPathClosed is to be used. (and for completeness, also add: EnergyTransfer
+
+Table 95. The settings for an OCPP 1.6 compatible transaction
+
+<table><tr><td>Configuration Variable</td><td>Values</td></tr><tr><td>TxStartPoint</td><td>PowerPathClosed</td></tr><tr><td>TxStopPoint</td><td>EVConnected, Authorized</td></tr></table>
+
+For stop behavior the ParkingBayOccupancy should not be added, OCPP 1.6 did not support this, and in case of a dual socket charging station where somebody is using the 'opposite' connector, the transaction would then be stopped, while the EV could still be charging.
+
+# 1.2. TransactionId generation
+
+New in OCPP 2.0.1: Transaction IDs are now generated by the Charging Station.
+
+In OCPP 1.x this was done by the CSMS. This had some drawbacks. When a Charging Station was offline it had a transaction which did not have a transactionId.
+
+The TransactionId generated by a Charging Station has to be unique for this Charging Station. During the lifetime of a Charging Station it should never use the same TransactionId twice. Also when the Charging Station is rebooted, power cycled, firmware updated, repaired etc.
+
+OCPP does not specify an algorithm to use, but it is RECOMMENDED to use UUIDs.
+
+# 1.3. Delivering transaction-related messages
+
+The primary purpose of TransactionEventRequest messages is to give the CSMS the information that it will later use to bill the transaction. To be sure that the CSMS receives all the necessary information for billing a transaction, OCPP uses two mechanisms: retrying and sequence numbers.
+
+# 1.3.1. Retrying
+
+The Charging Station sends TransactionEventRequest messages to the CSMS System as soon as possible after the events they report on have occurred.
+
+If the Charging Station is offline, or if an error occurs processing the message in transport, the CSMS will be missing billing information. In order to repair the missing information in the CSMS, the Charging Station should retry to deliver this information. When the Charging Station fails to receive a TransactionResponse for a TransactionRequest message within the message timeout period, the Charging Station should follow the retry procedure described in use case E13 - Transaction-related message not accepted by CSMS.
+
+# 1.3.2. Sequence numbers
+
+When delivery of TransactionEventRequest messages fails and will be retried later, the result is that TransactionEventRequest messages may arrive in the CSMS in a different order from the one in which the transaction events occurred at the Charging Station. This in turn would make it difficult for the CSMS to know if it received all TransactionEventRequest messages about a transaction, which the CSMS may want to know before it starts billing the transaction.
+
+In order to make it possible to know that all TransactionEventRequest messages about a transaction were received, OCPP uses sequence numbers in TransactionEventRequest messages. For every EVSE, the Charging Station maintains a counter of the number of TransactionEventRequest messages generated about that EVSE. When generating a new TransactionEventRequest message, the Charging Station includes the current value of the EVSE's counter in the seqNo field of the request, and then increments the counter. With this mechanism, a CSMS can check if it has full information about a transaction by checking that:
+
+- It received a TransactionEventRequest about the start of the transaction, with a seqNo a
+- It received a TransactionEventRequest about the stop of the transaction, with a seqNo o greater than a.
+- It received a TransactionEventRequest about the transaction with seqNo $n$ for every integer $n$ between $a$ and $o$
+
+# 1.3.2.1. Sequence number generation
+
+This section is normative.
+
+When a transaction starts, the Charging Station SHOULD set the seqNo field for the TransactionRequest message to 0. (Implementations with a continuously increasing seqNo are still allowed.)
+
+After each TransactionEventRequest Charging Station SHALL increase the seqNo by 1.
+
+# 1.4. Authorization
+
+To simplify the use cases in this functional block, the way an EV Driver is authorized is not part of these use cases. It will simply be called something like: "User authorization successful" or "The EV Driver is authorized by the Charging Station and/or CSMS." This may be any way of authorizing an EV Driver. See functional block: C Authorization for all the options and requirements for authorization.
+
+# 1.5. Clarification for optional fields in TransactionRequest
+
+This section is informative.
+
+The TransactionEventRequest contains several optional fields. Some of these fields should only be sent once and should not be repeated in every TransactionEventRequest. The following summary points to the requirements related to these optional fields.
+
+# evse
+
+(E01.FR.16) The field evse is only provided in the first TransactionEventRequest that occurs after the EV has connected. It is not repeated in all future TransactionEventRequests.
+
+# idToken
+
+(E03.FR.01) The field idToken is provided once in the first TransactionEventRequest that occurs after the transaction has been authorized.
+(E07.FR.02) The field idToken is provided once in the TransactionEventRequest that occurs when the authorization of the transaction has been ended.
+(C12.FR.02) The above is also the case when authorization was granted because the idToken is present in the authorization cache with a Accepted status.
+(F02.FR.05): The above is also the case when the idToken is provided by a RequestStartTransactionRequest.
+
+# reservationId
+
+(E03.FR.03/H01.FR.15) The field reservationId is only provided in the first TransactionEventRequest that occurs when the transaction has been authorized by the idToken for which a reservation existed in the charging station.
+(F02.FR.06) The above is also the case when the idToken is provided by a RequestStartTransactionRequest.
+
+# meterValue
+
+(E02.FR.09) The TransactionRequest(eventType=Started) must contain the meter values that have been configured in SampledDataCtrl.TxStartedMeasurands.
+
+(E02.FR.10) A TransactionEventRequest(eventType=Updated) must be sent at every interval configured in SampledDataCtrl.TxUpdatedInterval and contain the meter values that have been configured in
+
+SampledDataCtrl.TxUpdatedMeasurands. If TxUpdatedMeasurands == 0, then no meter values are sent.
+
+(E06.FR.11) The TransactionEventRequest(eventType=Ended) must contain the meter values that have been configured in SampledDataCtrl.TxEndedMeasurands. If SampledDataCtrl.TxEndedInterval == 0, then only the values taken at start and end of the transaction are included.
+
+# transactionInfo.chargingState
+
+(E02.FR.13) Whenever the charging state changes, the Charging Station must send a TransactionRequest containing chargingState. This implies that a TransactionRequest(eventType = Started) always has a chargingState, because 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.
+
+# transactionInfo.stoppedReason
+
+(C15.FR.04, E05.FR.10, E05.FR.08/09, E07.FR.06) The stoppedReason must be provided in the TransactionEventRequest(eventType=Ended), unless the value is Local, in which case it may be omitted. (F03.FR.03, F03.FR.10, F04.FR.03) The above also applies to transactions that are stopped by a RequestStopTransactionRequest, however in this case the stoppedReason value must be Remote.
+
+# transactionInforemoteStartId
+
+(C05.FR.03, F01.FR.25, F02.FR.01) The remoteStartId must be sent in the next TransactionEventRequest after the RequestStartTransactionRequest with the same remoteStartId.
+
+# 2. Use cases & Requirements
+
+# 2.1. OCPP transaction mechanism
+
+# E01 - Start Transaction options
+
+Table 96. E01 - Start Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Start Transaction options</td></tr><tr><td>2</td><td>ID</td><td>E01</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS that a transaction at the Charging Station has started.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes the different moments a Charging Station can start a transaction (send TransactionRequest with eventType = Started), depending on the configuration of the Charging Station.</td></tr><tr><td>5</td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td>S1</td><td>Scenario objective</td><td>To start a transaction when a parking bay occupancy detector detects an "EV".</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver parks his "EV" at a Charging Station with a parking bay occupancy detector, which triggers the detector.
+2. The Charging Station sends a TransactionRequest (eventType = Started) notifying the CSMS about a transaction that has started (even when the driver is not yet known.
+3. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>No transaction is ongoing on the EVSE.
+Configuration Variable: TxStartPoint contains: ParkingBayOccupancy</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing, or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 39. Sequence Diagram: Start Transaction options - ParkingBayOccupancy
+
+<table><tr><td>S2</td><td>Scenario objective</td><td>To start a transaction when communication is set up between the Charging Station and an EV (for example: cable plugged in correctly on both sides)</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sets up a connection with the EV.
+2. The Charging Station sends a TransactionRequest (eventType = Started) notifying the CSMS about a transaction that has started (even when the driver is not yet known).
+3. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>No transaction is ongoing on the EVSE.
+Configuration Variable: TxStartPoint contains: EVConnected (Not: ParkingBayOccupancy)</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing, or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 40. Sequence Diagram: Start Transaction options - EVConnected
+
+<table><tr><td>S3</td><td>Scenario objective</td><td>To start a transaction when the EV Driver is authorised to charge.</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver provides his identification
+2. The Charging Station validates the provided identification (for example via the Authorization Cache or an InvalidateRequest).
+3. The Charging Station sends a TransactionRequest (eventType = Started) notifying the CSMS about a transaction that has started.
+4. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>No transaction is ongoing on the EVSE.
+Configuration Variable: TxStartPoint contains: Authorized (Not: ParkingBayOccupancy).</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing, or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 41. Sequence Diagram: Start Transaction options - Authorized
+
+<table><tr><td>S4</td><td>Scenario objective</td><td>To start a transaction when the meter has provided the first signed meter values before starting with charging.</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver plugs in the cable at the Charging Station and the EV.
+2. The Charging Station request the Meter for a signed value.
+3. The Meter provides a signed value (this might take some time).
+4. The Charging Station sends a TransactionRequest (eventType = Started) notifying the CSMS about a transaction that has started.
+5. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>No transaction is ongoing on the EVSE.
+Configuration Variable: TxStartPoint contains: DataSigned (Not: ParkingBayOccupancy, EVConnected or Authorized).
+The Charging Station has a meter that can sign measured values
+Configuration Variable: SampledDataSignReadings set to true.</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing, or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 42. Sequence Diagram: Start Transaction options - DataSigned
+
+<table><tr><td>S5</td><td>Scenario objective</td><td>To start a transaction when all preconditions have been met to start charging (authorized and connected), but energy does not yet have to be transferred.</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver is authorized by the Charging Station and/or CSMS.
+2. The Charging Station is connected to the EV.
+3. The Charging Station sends a TransactionRequest (eventType = Started) notifying the CSMS about a transaction that has started.
+4. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>No transaction is ongoing on the EVSE.
+Configuration Variable: TxStartPoint contains: PowerPathClosed (Not: ParkingBayOccupancy, EVConnected, Authorized or DataSigned).
+Charging Cable plugged in.</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing, or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 43. Sequence Diagram: Start Transaction options - PowerPathClosed
+
+<table><tr><td>S6</td><td>Scenario objective</td><td>To start a transaction when the energy flow starts.</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver is authorized by the Charging Station and/or CSMS.
+2. The Charging Station closes the power relay.
+3. The EV starts charging, energy flow starts.
+4. The Charging Station sends a TransactionRequest (eventType = Started) notifying the CSMS about a transaction that has started.
+5. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>Configuration Variable: TxStartPoint contains: EnergyTransfer (Not: ParkingBayOccupancy, EVConnected, Authorized, DataSigned or PowerPathClosed).</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing, or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 44. Sequence Diagram: Start Transaction options - EnergyTransfer
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# E01 - Start Transaction options - Requirements
+
+Table 97. E01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E01.FR.01</td><td>TxStartPoint contains: ParkingBayOccupancy AND Parking Bay Detector detects an "EV" AND No transaction has started yet</td><td>The Charging Station SHALL start a transaction and send a TransactionRequest (eventType = Started) to the CSMS.</td></tr><tr><td>E01.FR.02</td><td>TxStartPoint contains: EVConnected AND The Charging Station has a connection with the EV AND No transaction has started yet on this EVSE</td><td>The Charging Station SHALL start a transaction and send a TransactionRequest (eventType = Started) to the CSMS.</td></tr><tr><td>E01.FR.03</td><td>TxStartPoint contains: Authorized AND The EV Driver is authorized AND No transaction has started yet</td><td>The Charging Station SHALL start a transaction and send a TransactionRequest (eventType = Started) to the CSMS.</td></tr><tr><td>E01.FR.04</td><td>TxStartPoint contains: DataSigned AND The Charging Station has a meter that can sign measured values AND Configuration Variable: SampledDataSignReadings set to true. AND The Charging Station has retrieved a signed meter value AND No transaction has started yet</td><td>The Charging Station SHALL start a transaction and send a TransactionRequest (eventType = Started) to the CSMS.</td></tr><tr><td>E01.FR.05</td><td>TxStartPoint contains: PowerPathClosed AND The EV Driver is authorized AND The Charging Station has connection with the EV AND No transaction has started yet on this EVSE</td><td>The Charging Station SHALL start a transaction and send a TransactionRequest (eventType = Started) to the CSMS.</td></tr><tr><td>E01.FR.06</td><td>TxStartPoint contains: EnergyTransfer AND Energy flow starts AND No transaction has started yet on this EVSE</td><td>The Charging Station SHALL start a transaction and send a TransactionRequest (eventType = Started) to the CSMS.</td></tr><tr><td>E01.FR.07</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td></tr><tr><td>E01.FR.08</td><td></td><td>The transactionId generated by the Charging Station MUST be unique for each transaction started by that Charging Station, even when the Charging Station is rebooted, repaired, firmware is updated etc, it SHALL ensure that it never generates the same TransactionId twice.</td></tr><tr><td>E01.FR.09</td><td>When configured to send meter data in the TransactionRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is known at start of transaction</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td></tr><tr><td>E01.FR.10</td><td>After the EV Driver is authorized for this transaction</td><td>The Charging Station SHALL send a TransactionRequest that contains IdTokenType information.</td></tr><tr><td>E01.FR.11</td><td>E01.FR.10</td><td>The CSMS SHALL verify the validity of the identifier in TransactionRequest.</td></tr><tr><td>E01.FR.12</td><td>E01.FR.11</td><td>The CSMS SHALL send a TransactionResponse that includes in idTokenInfo an authorization status value and the groupldToken if one exists for the idToken.</td></tr><tr><td>E01.FR.13</td><td>This transaction ends a reservation</td><td>The next TransactionRequest SHALL contain the reservationId.</td></tr><tr><td>E01.FR.14</td><td>After TransactionRequest(eventType = Started) has been sent for a specific EVSE and Connector</td><td>The Charging Station SHALL NOT start another transaction on a different Connector of the same EVSE until this transaction has ended.</td></tr><tr><td>E01.FR.15</td><td>When sending a TransactionRequest</td><td>The Charging Station SHALL set the triggerReason to inform the CSMS about what triggered the event. What reason to use is described in the description of TriggerReasonEnumType.</td></tr><tr><td>E01.FR.16</td><td>After the EV is connected with the Charging Station.</td><td>The next TransactionRequest SHALL contain evse.id AND evseconnectorId.</td></tr><tr><td>E01.FR.17</td><td>When configured to send meter data in the TransactionRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is not known at start of transaction</td><td>The Charging Station SHALL add the measurands for eventType = Started to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Updated) that occurs when charging starts.</td></tr><tr><td>E01.FR.18</td><td>If the charging state changes</td><td>The Charging Station SHALL send a TransactionRequest including the chargingState element.</td></tr><tr><td>E01.FR.19</td><td>When EV temporarily suspends the energy transfer</td><td>The Charging Station SHOULD send a TransactionRequest with chargingState = SuspendedEV</td></tr><tr><td>E01.FR.20</td><td>E01.FR.19 AND The Charging Station is not able to handle temporary suspension of energy transfer</td><td>The Charging Station SHOULD send a TransactionRequest with chargingState = EVConnected.</td></tr></table>
+
+# E02 - Start Transaction - Cable Plugin First
+
+Table 98. E02 - Start Transaction - Cable Plugin First
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Start Transaction - Cable Plugin First</td></tr><tr><td>2</td><td>ID</td><td>E02</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS that a transaction at the Charging Station has started.</td></tr><tr><td>4</td><td>Description</td><td>The EV Driver begins the interaction with the Charging Station by plugging in the charging cable first. The CSMS is notified about this. Then, when the communication between EV and EVSE is established, the transaction is started and the CSMS is notified of this. The EV starts charging.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver plugs in the cable at the Charging Station.
+2. The Charging Station sends a StatusNotificationRequest to the CSMS to inform it about a Connector that became Occupied.
+3. The Charging Station sends a TransactionEventRequest (eventType = Started) notifying the CSMS about a transaction that has started (even when the driver is not yet known.)
+4. The CSMS responds with a TransactionResponse, confirming that the TransactionEventRequest was received.
+5. The EV Driver is authorized by the Charging Station and/or CSMS.
+6. The energy offer starts.
+7. The Charging Station sends a TransactionEventRequest (eventType = Updated) with the authorized idToken information to the CSMS to inform about the charging status and which idToken belongs to the transaction.
+8. The CSMS responds with a TransactionResponse to the Charging Station with the IdTokenInfo.status Accepted.
+9. During the charging process, the Charging Stations continue to send TransactionEventRequest (Updated) messages for transaction-related notifications.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>E02 - Start Transaction - IdToken First
+E04 - Offline Start Transaction
+E05 - Start Transaction - Id not Accepted</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Cable is plugged in first.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing. or
+The CSMS is not informed. or
+Start Transaction - Id not accepted.</td></tr></table>
+
+
+Figure 45. Sequence Diagram: Start Transaction - Cable Plugin First
+
+<table><tr><td>7</td><td>Error handling</td><td>Failing to respond with TransactionEventResponse will only cause the Charging Station to try the same message again as specified in E12 - Transaction-related message not accepted by CSMS.</td></tr><tr><td>8</td><td>Remark(s)</td><td>If the Charging Station has implemented an Authorization Cache, then upon receipt of TransactionEventResponse, the Charging Station updates the cache entry.The scenario description and sequence diagram above are based on the Configuration Variable for start & stop transaction being configured as follows:TxStartPoint: EVConnected, Authorized, DataSigned, PowerPathClosed, EnergyTransferThis use-case is also valid for other configurations, but then the transaction might start at another moment, which might change the sequence in which message are sent. For more details see the use cases: E01 - Start Transaction options and E06 - Stop Transaction options.</td></tr></table>
+
+# E02 - Start Transaction - Cable Plugin First - Requirements
+
+Table 99. E02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E02.FR.01</td><td>After the EV Driver is authorized for this transaction.</td><td>The next TransactionRequest SHALL contain triggerReason: Authorized AND IdTokenType information.</td><td></td></tr><tr><td>E02.FR.02</td><td>E02.FR.01</td><td>The CSMS SHALL send a TransactionResponse that includes an authorization status value.</td><td></td></tr><tr><td>E02.FR.03</td><td>This transaction ends a reservation.</td><td>The next TransactionRequest SHALL contain the reservationId.</td><td>See H. Reservation.</td></tr><tr><td>E02.FR.04</td><td></td><td>The CSMS SHALL verify the validity of the identifier in TransactionRequest.</td><td>Because the identifier might have been authorized locally by the Charging Station using outdated information.</td></tr><tr><td>E02.FR.05</td><td>When a cable is plugged in</td><td>The Charging Station SHALL send a StatusNotificationRequest with status: Occupied</td><td>Alternatively, a NotifyEventRequest message for component( name = 'Connector', evse.id = <x>, evseconnectorId = <y>), variable( name = 'AvailabilityState'), andactualValue = 'Occupied' MAY be sent to signal that Connector <y> of EVSE <x> is now occupied.</td></tr><tr><td>E02.FR.06</td><td>When a cable is plugged in AND TxStartPoint contains EVConnected</td><td>The Charging Station SHALL send a TransactionRequest.</td><td></td></tr><tr><td>E02.FR.07</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information.</td></tr><tr><td>E02.FR.08</td><td></td><td>The transactionId generated by the Charging Station MUST be unique for each transaction started by that Charging Station, even when the Charging Station is rebooted, repaired, firmware is updated etc, it SHALL ensure that it never generates the same TransactionId twice.</td><td></td></tr><tr><td>E02.FR.09</td><td>When configured to send meter data in the TransactionRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is known at start of transaction</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td><td></td></tr><tr><td>E02.FR.10</td><td>When configured to send meter data in the TransactionRequest (eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction.</td><td></td></tr><tr><td>E02.FR.11</td><td>E02.FR.10 AND Amount of meter data is too much for 1 TransactionRequest (eventType = Updated)</td><td>The Charging Station MAY split meter data over multiple TransactionRequest(eventType = Updated) messages with the same timestamp.</td><td></td></tr><tr><td>E02.FR.13</td><td>If the charging state changes</td><td>The Charging Station SHALL send a TransactionRequest including the chargingState element.</td><td></td></tr><tr><td>E02.FR.14</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td></td></tr><tr><td>E02.FR.15</td><td>When sending a TransactionRequest</td><td>The Charging Station SHALL set the triggerReason to inform the CSMS about what triggered the event. What reason to use is described in the description of TriggerReasonEnumType.</td><td></td></tr><tr><td>E02.FR.16</td><td>After a transaction has been started</td><td>The Charging Station MAY send additional TransactionRequest(eventType = Updated) messages during the transaction when a trigger event occurs.</td><td></td></tr><tr><td>E02.FR.17</td><td>When a transaction-related trigger event occurs, listed in TriggerReasonEnumType AND the transaction is ongoing.</td><td>The Charging Station SHALL send a TransactionEventRequest with a triggerReason corresponding to the occurred event.</td><td>When two trigger reasons overlap, the more specific one 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 TransactionEventRequest messages for each trigger, though.</td></tr><tr><td>E02.FR.18</td><td>When the energy transfer starts AND If the Charging Station is able to report the number of phases used</td><td>The Charging Station SHALL provide the number of phases used, using the numberOfPhasesUsed field.</td><td></td></tr><tr><td>E02.FR.19</td><td>E02.FR.18 AND during the transaction the number of phases used changes</td><td>The Charging Station SHALL provide the adjusted number of phases used, using the numberOfPhasesUsed field.</td><td></td></tr><tr><td>E02.FR.20</td><td>When a transaction has not been authorized before AND the Charging Station authorizes an idToken to start charging</td><td>The next TransactionEventRequest from Charging Station SHALL contain the idToken and have triggerReason = Authorized.</td><td>If authorization is not successful, then no TransactionEventRequest is sent, because this event has no effect on the running transaction. (For authorization to stop charging, see E07).</td></tr><tr><td>E02.FR.21</td><td>When configured to send meter data in the TransactionEventRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is not known at start of transaction</td><td>The Charging Station SHALL add the measurands for eventType = Started to the optional meterValue field with context = Transaction.Begin in the TransactionEventRequest(eventType = Updated) that occurs when charging starts.</td><td></td></tr></table>
+
+# E03 - Start Transaction - IdToken First
+
+Table 100. E03 - Start Transaction - IdToken First
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Start Transaction - IdToken First</td></tr><tr><td>2</td><td>ID</td><td>E03</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the EV Driver to start a transaction by first presenting an IdToken at the Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the EV Driver is first authorized by presenting an IdToken before the cable is plugged in and a transaction starts.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver is authorized by the Charging Station and/or CSMS.
+2. The Charging Station informs the CSMS that a transaction has started by sending a TransactionRequest (eventType = Started).
+3. The EV Driver plugs in the Charging Cable at the Charging Station.
+4. The Charging Station sends StatusNotificationRequest to, and receives StatusNotificationResponse from the CSMS.
+5. The Charging Station informs the CSMS that the EV started charging by sending a TransactionRequest (eventType = Updated, chargingState = Charging).
+6. The CSMS responds with TransactionResponse, accepting the transaction.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>IdToken is presented prior to plugin cable.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+A transaction is started and the ChargingState is Charging
+Failure postcondition:
+No transaction is started</td></tr></table>
+
+
+Figure 46. Sequence Diagram: Start Transaction - IdToken First
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>It is likely that the CSMS applies sanity checks to the data contained in TransactionEventRequest messages it received. The outcome of such sanity checks SHOULD NOT ever cause the CSMS to not respond with a TransactionEventResponse. Failing to do so will only cause the Charging Station to try the same message again as specified in E12 - Transaction-related message not accepted by CSMS.The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:TxStartPoint: Authorized, DataSigned, PowerPathClosed, EnergyTransferThis use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are sent. For more details see the use cases: E01 - Start Transaction options.</td></tr></table>
+
+# E03 - Start Transaction - IdToken First - Requirements
+
+Table 101. E03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E03.FR.01</td><td>When the IdToken information is known.</td><td>The next TransactionEventRequest SHALL contain IdTokenType information.</td><td></td></tr><tr><td>E03.FR.02</td><td>E03.FR.01</td><td>The CSMS SHALL send a TransactionEventResponse that includes an authorization status.</td><td></td></tr><tr><td>E03.FR.03</td><td>This transaction ends a reservation for the specific IdToken.</td><td>The next TransactionEventRequest SHALL contain the reservationId.</td><td>See H. Reservation.</td></tr><tr><td>E03.FR.05</td><td>When the EV Driver does not plug-in the charging cable before the timeout set by the Configuration Variable: EVConnectionTimeOut AND TxStopPoint does not contain ParkingBayOccupancy</td><td>The Charging Station SHOULD end the transaction and send a TransactionRequest (eventType = Ended, stoppedReason = Timeout, triggerReason = EVConnectionTimeout) to the CSMS.</td><td>This requirement is an additional safety measure to make sure the transaction is ended when the EVConnectionTimeOut is triggered. However it is up to the CSMS to make sure that sensible TxStartPoint / TxStopPoint combinations are configured. E.g. if Authorized is used as TxStartPoint, it should also be used as TxStopPoint.</td></tr><tr><td>E03.FR.06</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information</td></tr><tr><td>E03.FR.07</td><td>When configured to send meter data in the TransactionRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is known at start of transaction</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td><td></td></tr><tr><td>E03.FR.08</td><td>When configured to send meter data in the TransactionRequest (eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction.</td><td></td></tr><tr><td>E03.FR.09</td><td>E03.FR.08 AND Amount of meter data is too much for 1 TransactionRequest (eventType = Updated)</td><td>The Charging Station MAY split meter data over multiple TransactionRequest(eventType = Updated) messages with the same timestamp.</td><td></td></tr><tr><td>E03.FR.10</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td></td></tr><tr><td>E03.FR.11</td><td>When configured to send meter data in the TransactionRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is not known at start of transaction</td><td>The Charging Station SHALL add the measurands for eventType = Started to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Updated) that occurs when charging starts.</td><td></td></tr><tr><td>E03.FR.12</td><td>When a transaction-related trigger event occurs, listed in TriggerReasonEnumType AND the transaction is ongoing.</td><td>The Charging Station SHALL send a TransactionEventRequest with a triggerReason corresponding to the occurred event.</td><td>When two trigger reasons overlap, the more specific one 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 TransactionEventRequest messages. This is to prevent information loss, when something goes wrong.</td></tr><tr><td>E03.FR.13</td><td>When the energy transfer starts AND If the Charging Station is able to report the number of phases used</td><td>The Charging Station SHALL provide the number of phases used, using the numberOfPhasesUsed field.</td><td></td></tr><tr><td>E03.FR.14</td><td>E03.FR.13 AND during the transaction the number of phases used changes</td><td>The Charging Station SHALL provide the adjusted number of phases used, using the numberOfPhasesUsed field.</td><td></td></tr><tr><td>E03.FR.15</td><td>When the EV Driver does not plug-in the charging cable before the timeout set by the Configuration Variable: EVConnectionTimeOut AND TxStopPoint contains ParkingBayOccupancy</td><td>The Charging Station SHALL deauthorize the transaction and send a TransactionEventRequest (triggerReason = EVConnectionTimeout) to the CSMS.</td><td>Transaction will be ended normally when driver leaves the parking bay.</td></tr></table>
+
+# E04 - Transaction started while Charging Station is offline
+
+Table 102. E04 - Transaction started while Charging Station is offline
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Transaction started while Charging Station is offline</td></tr><tr><td>2</td><td>ID</td><td>E04</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the EV Driver to start a transaction while the Charging Station is Offline.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the Charging Station, while Offline, is able to start a transaction using the Local Authorization List or the Authorization Cache.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The transaction starts.
+2. The TransactionRequest (eventType = Started) is stored/queued by the Charging Station.
+3. The connection between Charging Station and CSMS is restored.
+4. The Charging Station starts to send queued messages
+5. The stored TransactionRequest is sent, notifying the CSMS about the transaction that was started.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>E10 - Connection Loss During Transaction</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station is Offline.
+The EV Driver is offline/locally authorized by the Charging Station.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The TransactionRequest has been responded to by the CSMS AND has been removed from the queue of the Charging Station.
+Failure postcondition:
+The TransactionRequest was NOT responded to by the CSMS AND remains in the queue of the Charging Station.</td></tr></table>
+
+
+Figure 47. Sequence Diagram: Transaction started while Charging Station is offline
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:
+TxStartPoint: Authorized, DataSigned, PowerPathClosed, EnergyTransfer
+This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are sent. For more details see the use cases: E01 - Start Transaction options.</td></tr></table>
+
+# E04 - Transaction started while Charging Station is offline - Requirements
+
+Table 103. E04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E04.FR.01</td><td>When Offline.</td><td>The Charging Station MUST queue any TransactionRequest messages.</td><td></td></tr><tr><td>E04.FR.02</td><td>After the connection is restored.</td><td>The Charging Station MUST send queued TransactionRequest messages.</td><td></td></tr><tr><td>E04.FR.03</td><td>E04.FR.02</td><td>The flag: "offline" SHALL be set to TRUE for any TransactionRequest that occurred while the Charging Station was offline.</td><td></td></tr><tr><td>E04.FR.04</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information</td></tr><tr><td>E04.FR.05</td><td>When configured to send meter data in the TransactionRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is known at start of transaction</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td><td></td></tr><tr><td>E04.FR.06</td><td>When configured to send meter data in the TransactionRequest (eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction.</td><td></td></tr><tr><td>E04.FR.07</td><td>E04.FR.06 AND Offline AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop TransactionRequest(eventType = Updated) messages.</td><td></td></tr><tr><td>E04.FR.08</td><td>E04.FR.07</td><td>When dropping TransactionRequest (eventType = Updated) messages, the Charging Station SHALL drop intermediate messages first (1st message, 3th message, 5th message etc.), not start dropping messages from the start or stop adding messages to the queue.</td><td></td></tr><tr><td>E04.FR.09</td><td>E04.FR.06 AND Amount of meter data is too much for 1 TransactionRequest (eventType = Updated)</td><td>The Charging Station MAY split meter data over multiple TransactionRequest(eventType = Updated) messages with the same timestamp.</td><td></td></tr><tr><td>E04.FR.10</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td></td></tr><tr><td>E04.FR.11</td><td>When configured to send meter data in the TransactionEventRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is not known at start of transaction</td><td>The Charging Station SHALL add the measurands for eventType = Started to the optional meterValue field with context = Transaction.Begin in the TransactionEventRequest(eventType = Updated) that occurs when charging starts.</td><td></td></tr></table>
+
+# E05 - Start Transaction - ld not Accepted
+
+Table 104. E05 - Start Transaction - Id not Accepted
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Start Transaction - Id not Accepted</td></tr><tr><td>2</td><td>ID</td><td>E05</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Charging Station to suspend a transaction when the IdToken has an AuthorizationStatus that does not allow charging.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the Charging Station wants to start a transaction while the IdToken is not accepted by the CSMS Because the identifier might have been authorized locally by the Charging Station using outdated information, the CSMS has to validate the IdTokenType in every TransactionRequest message it receives that contains an IdTokenType. When receiving a TransactionResponse message with idTokenInfo field status is not Accepted, the Charging Station should stop the energy delivery to the EV.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends TransactionRequest (eventType = Started) that contains the IdToken provided by the EV Driver.
+2. The CSMS responds with TransactionResponse, with an AuthorizationStatus that does not allow charging.
+3. The Charging Station suspends the energy offer. (Taking into account: MaxEnergyOnInvalidId, if supported)
+4. The Charging Station sends TransactionRequest (eventType = Updated) with trigger Deauthorized and the chargingState SuspendedEVSE and receives TransactionEventResponse from the CSMS.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The EV Driver is offline/locally authorized by the Charging Station.
+The IdToken is not allowed to charge by the CSMS.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is kept ongoing, and the cable remains locked, but no energy is delivered.
+Failure postcondition:
+n/a</td></tr></table>
+
+
+Figure 48. Sequence Diagram: Start Transaction - Id not Accepted
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The scenario description and sequence diagram above are based on the Configuration Variable for start & stop transaction being configured as follows:
+TxStartPoint: Authorized, DataSigned, PowerPathClosed, EnergyTransfer
+TxStopPoint: ParkingBayOccupancy, EVConnected
+This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are sent. For more details see the use cases: E01 - Start Transaction options and E06 - Stop Transaction options.</td></tr></table>
+
+# E05 - Start Transaction - Id not Accepted - Requirements
+
+Table 105. E05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E05.FR.01</td><td></td><td>The CSMS MUST verify validity of the identifier in the TransactionRequest message.</td><td>The identifier might have been authorized locally by the Charging Station using outdated information. The identifier, for instance, may have been blocked since it was added to the Charging Station's Authorization Cache.</td></tr><tr><td>E05.FR.02</td><td>E05.FR.01 AND The authorization status in TransactionResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is set to false AND MaxEnergyOnInvalidId is not implemented or has been exceeded. TxStopPoint does NOT contain: EnergyTransfer</td><td>The Charging Station SHALL stop the energy delivery to the EV immediately and send TransactionRequest (eventType = Updated) with triggerReason set to ChargingStateChanged and chargingState set to SuspendedEVSE</td><td>The transaction is not deauthorized, but transfer of energy stops, since MaxEnergyOnInvalidId has been exceeded or is not set. If TxStopPoint contains EnergyTransfer then this would have ended the transaction.</td></tr><tr><td>E05.FR.03</td><td>E05.FR.01 AND The authorization status in TransactionResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is set to false AND MaxEnergyOnInvalidId is set and has NOT been exceeded.</td><td>Energy delivery to the EV SHALL be allowed until the amount of energy specified in MaxEnergyOnInvalidId has been reached.</td><td></td></tr><tr><td>E05.FR.04</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information.</td></tr><tr><td>E05.FR.05</td><td>When configured to send meter data in the TransactionRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is known at start of transaction</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td><td></td></tr><tr><td>E05.FR.06</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td></td></tr><tr><td>E05.FR.08</td><td>When configured to send meter data in the TransactionRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is not known at start of transaction</td><td>The Charging Station SHALL add the measurands for eventType = Started to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Updated) that occurs when charging starts.</td><td></td></tr><tr><td>E05.FR.09</td><td>E05.FR.01 AND The authorization status in TransactionEventResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is true AND TxStopPoint does NOT contain: (Authorized OR PowerPathClosed OR EnergyTransfer)</td><td>The Charging Station SHALL stop the energy transfer and send TransactionRequest (eventType = Updated) with triggerReason set to Deauthorized and in the same or next TransactionRequest report chargingState set preferably to EVConnected, or alternatively to SuspendedEVSE.</td><td>If the physical change of charging state in the Charging Station occurs a few seconds or milliseconds later than the trigger Deauthorized, then the chargingState change may be reported separately as a triggerReason = ChargingStateChanged. Use of charging state SuspendedEVSE that is not followed by EVConnected in this situation will become deprecated in the next OCPP release.</td></tr><tr><td>E05.FR.10</td><td>E05.FR.01 AND The authorization status in TransactionEventResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is true AND TxStopPoint does contain: (Authorized OR PowerPathClosed OR EnergyTransfer)</td><td>The Charging Station SHALL stop the transaction and send TransactionRequest (eventType = Ended) with triggerReason set to Deauthorized and stoppedReason set to DeAuthorized.</td><td></td></tr><tr><td>E05.FR.11</td><td>E05.FR.10 AND If the Charging Station has the possibility to lock the Charging Cable</td><td>The Charging Station SHOULD keep the Charging Cable locked until the owner presents his identifier.</td><td></td></tr></table>
+
+# E06 - Stop Transaction options
+
+Table 106. E06 - Stop Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Stop Transaction options</td></tr><tr><td>2</td><td>ID</td><td>E06</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS that a transaction at the Charging Station has stopped.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes the different moment a Charging Station can stop a transaction (send TransactionRequest (eventType = Ended), depending on the configuration of the Charging Station.</td></tr><tr><td>5</td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td>S1</td><td>Scenario objective</td><td>Stop a transaction when a parking bay occupancy no longer detector detects the EV.</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Stations parking bay occupancy detector stops detecting the EV.
+2. The Charging Station sends a TransactionRequest (eventType = Ended) notifying the CSMS about a transaction that has ended.
+3. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+Configuration Variable: TxStopPoint contains: ParkingBayOccupancy</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ended and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is still ongoing. or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 49. Sequence Diagram: Stop Transaction options - ParkingBayOccupancy
+
+<table><tr><td>S2</td><td>Scenario objective</td><td>Stop a transaction when communication between the Charging Station and the EV is lost. (for example: cable unplugged)</td></tr><tr><td></td><td>Scenario description</td><td>1. Communication between Charging Station and the EV is lost (Charging cable is unplugged).
+2. If charging cable unplugged on the Charging Station side: send StatusNotificationRequest to the CSMS to inform it about a Connector that became Available.
+3. The Charging Station sends a TransactionEventRequest (eventType = Ended) notifying the CSMS about a transaction that has ended.
+4. The CSMS responds with a TransactionEventResponse, confirming that the TransactionEventRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+Configuration Variable: TxStopPoint contains: EVConnected</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ended and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is still ongoing. or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 50. Sequence Diagram: Stop Transaction options - EVConnected
+
+<table><tr><td>S3</td><td>Scenario objective</td><td>Stop a transaction when the driver is no longer authorized.</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends a TransactionRequest to the CSMS. 2. An invalid IdToken is received in a TransactionResponse.
+3. The Charging Station sends a TransactionRequest (eventType = Ended) notifying the CSMS about a transaction that has ended.
+4. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+Configuration Variable: TxStopPoint contains: Authorized</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ended and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is still ongoing. or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 51. Sequence Diagram: Stop Transaction options - Deauthorized
+
+<table><tr><td>S5</td><td>Scenario objective</td><td>Stop a transaction when the EV driver is no longer authorized and/or the EV is disconnected.</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station is disconnected from EV and/or the EV driver is no longer authorized.
+2. The Charging Station sends a TransactionRequest (eventType = Ended) notifying the CSMS about a transaction that has ended.
+3. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+Configuration Variable: TxStopPoint contains: PowerPathClosed</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ended and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is still ongoing. or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 52. Sequence Diagram: Stop Transaction options - PowerPathClosed
+
+<table><tr><td>S6</td><td>Scenario objective</td><td>Stop a transaction when energy transfer stops. This will also mean the transaction stops when the EV stops taking energy, for example when the battery is to hot.</td></tr><tr><td></td><td>Scenario description</td><td>1. The energy transfer between EV and the Charging Station stops (for example: EV stops charging).
+2. The Charging Station sends a TransactionRequest (eventType = Ended) notifying the CSMS about a transaction that has ended.
+3. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+Configuration Variable: TxStopPoint contains: EnergyTransfer</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ended and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is still ongoing. or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 53. Sequence Diagram: Stop Transaction options - EnergyTransfer
+
+<table><tr><td>S7</td><td>Scenario objective</td><td>Stop a transaction when EV driver ends authorization</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV drivers presents an IdToken to end the charging.
+2. The Charging Station sends a TransactionRequest (eventType = Ended) notifying the CSMS about a transaction that has ended.
+3. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+Configuration Variable: TxStopPoint contains: Authorized (or PowerPathClosed).</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ended and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is still ongoing. or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 54. Sequence Diagram: Stop Transaction options - Authorized
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# E06 - Stop Transaction options - Requirements
+
+Table 107. E06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E06.FR.01</td><td>TxStopPoint contains: ParkingBayOccupancy AND Parking Bay Detector no longer detects the "EV"</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.02</td><td>TxStopPoint contains: EVConnected AND Connection between Charging Station and EV is lost.</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.03</td><td>TxStopPoint contains: Authorized AND EV Driver is authorized to stop a transaction.</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.04</td><td>TxStopPoint contains: Authorized AND CSMS returns a non-valid idTokenInfo in a TransactionResponse</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.05</td><td>TxStopPoint contains: DataSigned AND Charging Station can no longer retrieve signed meter values.</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.06</td><td>TxStopPoint contains: PowerPathClosed AND ( Connection between Charging Station and EV is lost OR Authorization has ended or idToken is deauthorized )</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.07</td><td>TxStopPoint contains: EnergyTransfer AND Energy transfer stops</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.08</td><td>If a transaction is not ended by the EV Driver at the Charging Station</td><td>The Charging Station SHALL include the stoppedReason element in the TransactionRequest(eventType = Ended). What reason to use is described in the description of reasonEnumType.</td></tr><tr><td>E06.FR.09</td><td>If a transaction is ended by the EV Driver at the Charging Station (e.g. EV Driver presented IdToken to stop the transaction)</td><td>The Charging Station MAY omit the stoppedReason element in the TransactionRequest(eventType = Ended) (hence the CSMS can interpret the reason as local when omitted).</td></tr><tr><td>E06.FR.10</td><td>As part of the normal transaction termination.</td><td>The Charging Station SHALL unlock the cable (if not permanently attached).</td></tr><tr><td>E06.FR.11</td><td>When configured to send meter data in the TransactionRequest(eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction. End in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td></tr><tr><td>E06.FR.12</td><td>E06.FR.11 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message.</td></tr><tr><td>E06.FR.13</td><td>E06.FR.12</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td></tr><tr><td>E06.FR.14</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td></tr><tr><td>E06.FR.15</td><td>When sending a TransactionRequest</td><td>The Charging Station SHALL set the triggerReason to inform the CSMS about what triggered the event. What reason to use is described in the description of TriggerReasonEnumType.</td></tr><tr><td>E06.FR.16</td><td>A transaction was stopped by an Abnormal Error or Fault Condition.</td><td>The Charging Station SHALL send TransactionRequest(eventType = Ended, triggerReason=AbnormalCondition)_to the CSMS.</td></tr></table>
+
+# E07 - Transaction locally stopped by IdToken
+
+Table 108. E07 - Transaction locally stopped by IdToken
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Transaction locally stopped by IdToken</td></tr><tr><td>2</td><td>ID</td><td>E07</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td>3</td><td>Objective(s)</td><td>The EV Driver wants to stop an ongoing transaction, by locally presenting his IdToken.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the EV Driver can stop a transaction when he wants to leave the charging station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description TxStopPoint = Authorized (or PowerPathClosed)</td><td>1. The EV Driver presents IdToken a second time to end charging.
+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 TransactionRequest (eventType = Ended) with triggerReason = StopAuthorized and stoppedReason = Local.
+4. The CSMS responds with a TransactionResponse.</td></tr><tr><td></td><td>Alternative scenario(s) TxStopPoint = Authorized (or PowerPathClosed)</td><td>Transaction ends with triggerReason=ChargingStateChanged when stopping charging:
+1. The EV Driver presents IdToken a second time to end charging.
+2. The Charging Station sends a TransactionRequest (eventType = Updated) with triggerReason = StopAuthorized
+3. The CSMS responds with a TransactionResponse.
+4. The Charging Station stops the energy transfer and if the cable is not permanently attached, the Charging Station unlocks the cable.
+5. The Charging Station sends a TransactionRequest (eventType = Ended) with triggerReason = ChargingStateChanged, transactionInfo.chargingState = EVConnected
+6. The CSMS responds with a TransactionResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A transaction is ongoing.</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td><td></td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The CSMS has received all relevant information about the transaction and the Charging Station is in Idle status.
+Failure postcondition:
+The transaction is still ongoing or the Charging Station is in Idle status and still holds information about the transaction that it has to deliver to the CSMS.</td><td></td></tr><tr><td>EV Driver</td><td>Charging Station</td><td>CSMS</td><td></td></tr><tr><td colspan="3">User authorization successful.</td><td></td></tr><tr><td>alt</td><td>[TxStopPoint = Authorized OR TxStopPoint = PowerPathClosed]TransactionEventRequest(eventType = Ended, transactionld = AB1234, seqNo = N + 1, timestamp, triggerReason = StopAuthorized, stoppedReason = Local, idToken.id = 1234, meterValues)TransactionEventResponse(idTokenInfo.status)</td><td></td><td></td></tr><tr><td>[TxStopPoint = EVConnected OR TxStopPoint = ParkingBayOccupancy OR TxStopPoint = EnergyTransfer]TransactionEventRequest(eventType = Updated, transactionld = AB1234, seqNo = N + 1, timestamp, triggerReason = StopAuthorized, idToken.id = 1234)TransactionEventResponse(idTokenInfo.status)</td><td>[TxStopPoint = EVConnected OR TxStopPoint = ParkingBayOccupancy OR TxStopPoint = EnergyTransfer]TransactionEventRequest(eventType = Updated, transactionld = AB1234, seqNo = N + 1, timestamp, triggerReason = ChargingStateChanged, chargingState = EVConnected, stoppedReason = Local, meterValues)TransactionEventResponse()</td><td>[TxStopPoint = EVConnected OR TxStopPoint = ParkingBayOccupancy]TransactionEventRequest(eventType = Updated, transactionld = AB1234, seqNo = N + 1, timestamp, triggerReason = ChargingStateChanged, chargingState = EVConnected)TransactionEventResponse()</td><td></td></tr><tr><td>[TxStopPoint = EVConnected OR TxStopPoint = ParkingBayOccupancy]Unplug cable</td><td>StatusNotificationRequest(Available)StatusNotificationResponse()</td><td>[TxStopPoint = EVConnected]TransactionEventRequest(eventType = Ended, transactionld = AB1234, seqNo = N + 3, timestamp, triggerReason = EVCommunicationLost, stoppedReason = Local)TransactionEventResponse()</td><td>[TxStopPoint = EVConnected OR TxStopPoint = ParkingBayOccupancy]TransactionEventRequest(eventType = Updated, transactionld = AB1234, seqNo = N + 3, timestamp, triggerReason = EVCommunicationLost)TransactionEventResponse()</td></tr><tr><td>Drive out of parking bay</td><td>[TxStopPoint = ParkingBayOccupancy]TransactionEventRequest(eventType = Ended, transactionld = AB1234, seqNo = N + 3, timestamp, triggerReason = EVDeparted, stoppedReason = Local)TransactionEventResponse()</td><td>[TxStopPoint = ParkingBayOccupancy]TransactionEventRequest(eventType = Ended, transactionld = AB1234, seqNo = N + 3, timestamp, triggerReason = EVDeparted, stoppedReason = Local)TransactionEventResponse()</td><td>[TxStopPoint = ParkingBayOccupancy]TransactionEventRequest(eventType = Ended, transactionld = AB1234, seqNo = N + 3, timestamp, triggerReason = EVDeparted, stopReason = Local)TransactionEventResponse()</td></tr></table>
+
+Figure 55. Sequence Diagram: Transaction locally stopped by IdToken with TransactionEventRequest reported strictly by TxStopPoint configuration
+
+
+Figure 56. Sequence Diagram: Transaction locally stopped by IdToken with delayed TransactionRequest/eventType = Ended for TxStopPoint = Authorized OR PowerPathClosed
+
+Table 109. E07 - Requirements
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The scenario descriptions are based on TxStopPoint containing Authorized or PowerPathClosed. The sequence diagrams also show behavior for other TxStopPoint values in the alt-blocks. The CSMS cannot prevent a transaction from stopping.</td></tr></table>
+
+# E07 - Transaction locally stopped by IdToken - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E07.FR.01</td><td>When an idToken is presented during a transaction that has been authorized AND (a) the presented idToken is the same as the idToken that started the authorization OR (b) when the presented idToken is in the Local Authorization List or Authorization Cache AND is valid AND has the same GroupIdToken as the IdToken that started the authorization.</td><td>The Charging Station SHALL end the authorization of the transaction, without first sending an InvalidateRequest</td><td>The idToken that started the authorization can always be used to end the authorization. Ending authorization will end delivery of energy. Depending on the TxStopPoint ending of the authorization may also end the transaction. (See C01.FR.03)</td></tr><tr><td>E07.FR.02</td><td>E07.FR.01</td><td>The Charging Station SHALL send a TransactionRequest with triggerReason = StopAuthorized and SHOULD include the idToken used to stop authorization.</td><td>The stopping idToken may differ from the starting idToken, when they share the same Groupld.</td></tr><tr><td>E07.FR.04</td><td>If a transaction is stopped on request of the EV driver at the Charging Station.</td><td>Charging Station MAY omit the stoppedReason element from the final TransactionRequest with eventType = Ended</td><td>e.g. EV-driver presented IdToken to stop the transaction or pressed a "stop" button (not the emergency stop). See use case F03 for remotely stopping.</td></tr><tr><td>E07.FR.05</td><td>If a transaction is stopped on request of the EV driver at the Charging Station.</td><td>Charging Station SHOULD use a stoppedReason = Local in the final TransactionRequest with eventType = Ended.</td><td>e.g. EV-driver presented IdToken to stop the transaction or pressed a "stop" button (not the emergency stop). See use case F03 for remotely stopping.</td></tr><tr><td>E07.FR.06</td><td>If a transaction is stopped, but not on request of the EV driver at the Charging Station.</td><td>Charging Station SHOULD use the most appropriate value from ReasonEnumType for stoppedReason in the final TransactionRequest with eventType = Ended.</td><td>Apart from remotely stopping (Remote), CSMS revoking authorization (DeAuthorized) or disconnecting the EV (EVDisconnected), most other reasons are related to technical faults or energy limitations.</td></tr><tr><td>E07.FR.07</td><td>As part of the normal transaction termination.</td><td>The Charging Station SHALL unlock the cable (if not permanently attached).</td><td></td></tr><tr><td>E07.FR.08</td><td>When configured to send meter data in the TransactionEventRequest (eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction.End in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td><td></td></tr><tr><td>E07.FR.09</td><td>E07.FR.08 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message.</td><td></td></tr><tr><td>E07.FR.10</td><td>E07.FR.09</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td><td></td></tr><tr><td>E07.FR.11</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information</td></tr><tr><td>E07.FR.12</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td></td></tr></table>
+
+# E08 - Transaction stopped while Charging Station is offline
+
+Table 110. E08 - Transaction stopped while Charging Station is offline
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Transaction stopped while Charging Station is offline</td></tr><tr><td>2</td><td>ID</td><td>E08</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td></td><td>Parent use case</td><td>E07 - Local Stop Transaction</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the EV Driver to stop a transaction while the Charging Station is Offline.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how an EV Driver can stop a transaction while the Charging Station is Offline. While a transaction is ongoing and the Charging Station is Offline, the EV Driver presents his IdToken, if the Charging Stations knows locally (without asking the CSMS) that this IdToken is allowed to stop the transaction, it will stop the ongoing transaction.
+When the Charging Station restores the connection with the CSMS, it needs to send the information about this Offline stop transaction to the CSMS.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver presents IdToken to stop the transaction.
+2. When this is the same IdToken as was used to start the transaction, or via the Local Authorization List and / or Authorization Cache the GroupId can be validated: the transaction is stopped.
+3. The Charging Station stops the energy offer.
+4. The TransactionRequest (eventType = Ended) is stored/queued by the Charging Station.
+5. The connection between Charging Station and CSMS is restored.
+6. The Charging Station starts to send queued messages
+7. The stored TransactionRequest is sent, notifying the CSMS about the transaction that was stopped.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Transaction ongoing and connection lost.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Charging Station is in Idle status.</td></tr></table>
+
+
+Figure 57. Sequence Diagram: Transaction stopped while Charging Station is offline
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>groupId check must be done on Local Authorization List and / or Authorization Cache if available.
+The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.
+TxStopPoint: ParkingBayOccupancy, EVConnected, Authorized
+This use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are sent. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+# E08 - Transaction stopped while Charging Station is offline - Requirements
+
+Table 111. E08 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E08.FR.01</td><td>If the IdToken presented is the same as the IdToken used to start the transaction.</td><td>The Charging Station SHALL stop the energy offering.</td><td></td></tr><tr><td>E08.FR.02</td><td>If the IdToken presented has the same GroupId as the IdToken used to start the transaction.</td><td>The Charging Station SHALL stop the energy offering.</td><td></td></tr><tr><td>E08.FR.03</td><td>(E08.FR.01 OR E08.FR.02) AND Cable not permanently attached</td><td>The Charging Station SHALL unlock the connector.</td><td></td></tr><tr><td>E08.FR.04</td><td>(E08.FR.01 OR E08.FR.02)</td><td>The Charging Station SHALL "generate" a TransactionRequest (eventType = Ended).</td><td></td></tr><tr><td>E08.FR.05</td><td>When Offline.</td><td>The Charging Station MUST queue any TransactionRequest messages.</td><td></td></tr><tr><td>E08.FR.06</td><td>After the connection is restored.</td><td>The Charging Station MUST send queued TransactionRequest messages.</td><td></td></tr><tr><td>E08.FR.07</td><td></td><td>The flag: offline SHALL be set to TRUE for any TransactionRequest that occurred while the Charging Station was offline.</td><td></td></tr><tr><td>E08.FR.08</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information.</td></tr><tr><td>E08.FR.09</td><td>When configured to send meter data in the TransactionRequest (eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td><td></td></tr><tr><td>E08.FR.10</td><td>E08.FR.09 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message.</td><td></td></tr><tr><td>E08.FR.11</td><td>E08.FR.10</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td><td></td></tr><tr><td>E08.FR.12</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td></td></tr></table>
+
+# E09 - When cable disconnected on EV-side: Stop Transaction
+
+Table 112. E09 - When cable disconnected on EV-side: Stop Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>When cable disconnected on EV-side: Stop Transaction</td></tr><tr><td>2</td><td>ID</td><td>E09</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td></td><td>Parent use case</td><td>E07 - Local Stop Transaction</td></tr><tr><td>3</td><td>Objective(s)</td><td>To stop an ongoing transaction when the Charging Cable is unplugged on the EV side.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how a transaction is stopped when the EV Driver unplugs the cable at the EV side. In this use case the Configuration Variable: StopTxOnEVSideDisconnect = true.The Charging Cable is unplugged at the EV side. This is detected by the Charging Station. The Charging Station stops the transaction and sends a TransactionRequest to the CSMS. The Charging Cable, if locked and UnlockOnEvSideDisconnect = false, will remain locked at the Charging Station until the EV Driver returns and presents his/hers IdToken. Otherwise it will unlock the cable.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The cable is unplugged at the EV.2. The energy offer is suspended.3. The Charging Station sends TransactionRequest (eventType = Ended, stoppedReason = EVDisconnected) to the CSMS.4. The CSMS responds with TransactionResponse.5. The EV Driver is authorized and unplants the cable.6. The Charging Station sends StatusNotificationRequest to the CSMS with the status Available.7. The CSMS responds with StatusNotificationResponse.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>E09 - When cable disconnected on EV-side: Suspend Transaction</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Configuration Variable: StopTxOnEVSideDisconnect = trueA transaction is ongoing</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The Charging Station is in Idle status.Failure postcondition:n/a</td></tr></table>
+
+
+Figure 58. Sequence Diagram: When cable disconnected on EV-side: Stop Transaction
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>When the Charging Cable is plugged back in, the charging will not resume/continue.
+The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.
+TxStopPoint: Authorized
+This use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are sent. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+# E09 - When cable disconnected on EV-side: Stop Transaction - Requirements
+
+Table 113. E09 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E09.FR.01</td><td>If StopTxOnEVSideDisconnect = true .</td><td>The transaction SHALL be deauthorized when the cable is disconnected from the EV. If the EV is reconnected, energy transfer is not allowed until the transaction is authorized once again.</td><td>Setting StopTxOnEVSideDisc onnect to true will prevent sabotage acts when unplugging not locked cables on EV side.</td></tr><tr><td>E09.FR.02</td><td>E09.FR.01 AND the cable is not permanently attached AND UnlockOnEvSideDisconnect = true.</td><td>The Charging Station SHALL unlock the Charging Cable.</td><td></td></tr><tr><td>E09.FR.03</td><td>E09.FR.01 AND the cable is not permanently attached AND UnlockOnEvSideDisconnect = false.</td><td>The Charging Station SHALL unlock the Charging Cable only after authorization by the EV Driver.</td><td></td></tr><tr><td>E09.FR.04</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information</td></tr><tr><td>E09.FR.05</td><td>When configured to send meter data in the TransactionRequest (eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td><td></td></tr><tr><td>E09.FR.06</td><td>E09.FR.05 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message.</td><td></td></tr><tr><td>E09.FR.07</td><td>E09.FR.06</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td><td></td></tr><tr><td>E09.FR.08</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td></td></tr></table>
+
+# E10 - When cable disconnected on EV-side: Suspend Transaction
+
+Table 114. E10 - When cable disconnected on EV-side: Suspend Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>When cable disconnected on EV-side: Suspend Transaction</td></tr><tr><td>2</td><td>ID</td><td>E10</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td></td><td>Parent use case</td><td>E07 - Local Stop Transaction</td></tr><tr><td>3</td><td>Objective(s)</td><td>To suspend an ongoing transaction when the Charging Cable is unplugged on the EV side.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how a transaction is suspended when the EV Driver unplays the cable at the EV side. In this use case the Configuration Variable: StopTxOnEVSideDisconnect = false.The Charging Cable is unplugged at the EV side. This is detected by the Charging Station. The Charging Station stops the energy offering (safety), but does not stop the transaction. The Charging Cable, if locked, will remain locked at the Charging Station until the EV Driver returns and presents his/hers IdToken.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver unplays the cable at the EV while a transaction is ongoing.2. The energy offer is suspended.If the EV Driver plugs the cable back in, the transaction is resumed.A1. The Charging Station sends a TransactionRequest (eventType = Updated, trigger = CablePluggedln)A2. The CSMS responds with a TransactionResponse.If cable not permanently attachedB1. The EV Driver is authorized by the Charging Station and/or CSMS to unlock the charging cable.B2. The Cable is unlocked.B3. The Charging Station sends a TransactionRequest (eventType = Ended, trigger = StopAuthorized).B4. The EV Driver removes the charging cable.B5. The Charging Station sends a StatusNotificationRequest to the CSMS with the status Available.B6. The CSMS responds with a StatusNotificationResponse.If cable permanently attachedC1. The Cable is not plugged in within timeout.C2. The Charging Station sends a TransactionRequest (eventType = Ended, trigger = EVCommunicationLost, stoppedReason = EVDisconnected).C3. The Charging Station sends a StatusNotificationRequest to the CSMS with the status Available.C4. The CSMS responds with a StatusNotificationResponse.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>E09 - When cable disconnected on EV-side: Stop Transaction</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Configuration Variable: StopTxOnEVSideDisconnect = falseA transaction is ongoing</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The Charging Station is in Idle status.The regular transaction is resumed.Failure postcondition:n/a</td></tr></table>
+
+
+Figure 59. Sequence Diagram: When cable disconnected on EV-side: Suspend Transaction
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>When the Charging Cable is plugged back in, the charging is resumed.
+When the cable is permanently attached and the cable is not plugged in within a certain timeout, the Charging Station stops the transaction. This timeout is not defined by OCPP, it is left to the implementor of the Charging Station.
+The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.
+TxStopPoint: ParkingBayOccupancy, Authorized
+This use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are sent. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+# E10 - When cable disconnected on EV-side: Suspend Transaction - Requirements
+
+Table 115. E10 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E10.FR.01</td><td>Cable not permanently attached</td><td>The Connector SHALL remain locked at the Charging Station until the EV Driver presents the IdToken.</td><td></td></tr><tr><td>E10.FR.02</td><td>Cable permanently attached AND Cable not plugged in within timeout</td><td>The Charging Station SHALL deauthorize the transaction.</td><td></td></tr><tr><td>E10.FR.03</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information</td></tr><tr><td>E10.FR.04</td><td>When configured to send meter data in the TransactionRequest (eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td><td></td></tr><tr><td>E10.FR.05</td><td>E10.FR.04 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message.</td><td></td></tr><tr><td>E10.FR.06</td><td>E10.FR.05</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td><td></td></tr><tr><td>E10.FR.07</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td></td></tr></table>
+
+# E11 - Connection Loss During Transaction
+
+Table 116. E11 - Connection Loss During Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Connection Loss During Transaction</td></tr><tr><td>2</td><td>ID</td><td>E11</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable a Charging Station to continue a transaction while the Charging Station loses its connection</td></tr><tr><td>4</td><td>Description</td><td>This use cases describes how a Charging Station can continue an ongoing transaction while losing and regaining the connection with the CSMS.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The connection of the Charging Station is lost, while a transaction is ongoing.
+2. The transaction events of the Charging Station are stored.
+3. The connection with the CSMS is restored.
+4. The Charging Station sends the stored transaction events to the CSMS using TransactionRequest (offline = TRUE).
+5. The Charging Station resumes regular communication.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>E04 - Offline Start Transaction</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Transaction ongoing and connection lost.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station resumes regular communication.
+Failure postcondition:
+n/a</td></tr></table>
+
+
+Figure 60. Sequence Diagram: Connection Loss During Transaction
+
+Table 117. E11 - Requirements
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# E11 - Connection Loss During Transaction - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E11.FR.01</td><td>When Offline</td><td>The Charging Station MUST queue all TransactionRequest messages, that it would have sent to the CSMS if the Charging Station had been online.</td></tr><tr><td>E11.FR.02</td><td>After the connection is restored.</td><td>The Charging Station MUST send queued TransactionRequest messages with the flag offline set to TRUE.</td></tr><tr><td>E11.FR.03</td><td>When configured to send meter data in the TransactionRequest(eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction.</td></tr><tr><td>E11.FR.04</td><td>E11.FR.03 AND Offline AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop TransactionRequest(eventType = Updated) messages.</td></tr><tr><td>E11.FR.05</td><td>E11.FR.04</td><td>When dropping TransactionRequest(eventType = Updated) messages, the Charging Station SHALL drop intermediate messages first (1st message, 3th message, 5th message etc.), not start dropping messages from the start or stop adding messages to the queue.</td></tr><tr><td>E11.FR.06</td><td>E11.FR.03 AND Amount of meter data is too much for 1 TransactionRequest(eventType = Updated)</td><td>The Charging Station MAY split the meter data over multiple TransactionRequest(eventType = Updated) messages with the same timestamp.</td></tr><tr><td>E11.FR.07</td><td></td><td>If the Charging Station goes offline, every message that is still in the queue SHALL be set Offline.</td></tr><tr><td>E11.FR.08</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td></tr></table>
+
+# E12 - Inform CSMS of an Offline Occurred Transaction
+
+Table 118. E12 - Inform CSMS of an Offline Occurred Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Inform CSMS of an Offline Occurred Transaction</td></tr><tr><td>2</td><td>ID</td><td>E12</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Charging Station to inform the CSMS that a transaction occurred while the Charging Station was Offline.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the Charging Station starts and stops a transaction since connection loss.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The connection with the CSMS is restored.
+2. The Charging Station sends a Heartbeat message to the CSMS.
+3. The Charging Station sends TransactionRequest (eventType = Started, offline = TRUE) to the CSMS.
+4. The CSMS responds with TransactionResponse, accepting the transaction.
+5. The Charging Station sends TransactionRequest (eventType = Updated, offline = TRUE)
+6. The CSMS responds with TransactionResponse.
+7. The Charging Station sends TransactionRequest (eventType = Ended, offline = TRUE)
+8. The CSMS responds with TransactionResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>At least one Offline transaction has taken place.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The CSMS has processed all transactions that occurred Offline.
+Failure postcondition:
+n/a</td></tr></table>
+
+
+Figure 61. Sequence Diagram: Inform CSMS of an Offline Occurred Transaction
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# E12 - Inform CSMS of an Offline Occurred Transaction - Requirements
+
+Table 119. E12 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E12.FR.01</td><td>When Offline</td><td>The Charging Station MUST queue all TransactionEventRequest messages, that it would have sent to the CSMS if the Charging Station had been online.</td></tr><tr><td>E12.FR.02</td><td>After the connection is restored.</td><td>The Charging Station MUST send queued TransactionRequest messages with the flag offline set to TRUE.</td></tr><tr><td>E12.FR.03</td><td>When configured to send meter data in the TransactionRequest(eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction.</td></tr><tr><td>E12.FR.04</td><td>E12.FR.03 AND Offline AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop TransactionRequest(eventType = Updated) messages.</td></tr><tr><td>E12.FR.05</td><td>E12.FR.04</td><td>When dropping TransactionRequest(eventType = Updated) messages, the Charging Station SHALL drop intermediate messages first (1st message, 3th message, 5th message etc.), not start dropping messages from the start or stop adding messages to the queue.</td></tr><tr><td>E12.FR.06</td><td>E12.FR.03 AND Amount of meter data is too much for 1 TransactionRequest(eventType = Updated)</td><td>The Charging Station MAY split the meter data over multiple TransactionRequest(eventType = Updated) messages with the same timestamp.</td></tr><tr><td>E12.FR.07</td><td>When configured to send meter data in the TransactionRequest(eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td></tr><tr><td>E12.FR.08</td><td>E12.FR.07 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message.</td></tr><tr><td>E12.FR.09</td><td>E12.FR.08</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td></tr><tr><td>E12.FR.10</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td></tr></table>
+
+# E13 - Transaction-related message not accepted by CSMS
+
+Table 120. E13 - Transaction-related message not accepted by CSMS
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Transaction-related message not accepted by CSMS</td></tr><tr><td>2</td><td>ID</td><td>E13</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td>3</td><td>Objective(s)</td><td>To define how a Charging Station shall handle not accepted messages.</td></tr><tr><td>4</td><td>Description</td><td>There are a situation/issues why a CSMS might not accept a transaction related message, or does not reply within the MessageTimeout. Most are error scenarios. When something like this happens, the Charging Station SHALL retry the messages a couple of times.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends a transaction-related message to the CSMS.
+2. The message is not accepted and MessageAttemptsTransactionEvent not reached.
+3. The Charging Station waits the number of preceding transmissions of this same message times MessageAttemptIntervalTransactionEvent seconds.
+4. The Charging Station resends the transaction-related message to the CSMS.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+MessageAttemptsTransactionEvent is not reached AND the transaction-related message is accepted. MessageAttemptsTransactionEvent is reached AND the transaction-related message is disposed.
+Failure postcondition:
+MessageAttemptsTransactionEvent is not reached AND the transaction-related message is disposed. MessageAttemptsTransactionEvent is reached AND the transaction-related message is accepted.</td></tr></table>
+
+
+Figure 62. Sequence Diagram: Transaction-related message not accepted by CSMS
+
+Table 121. E13 - Requirements
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>This use case describes the expect behaviour when the CSMS does not accept a message, or does not reply within the message timeout, this is different from a situation where the communication between Charging Station and CSMS is Offline.</td></tr></table>
+
+# E13 - Transaction-related message not accepted by CSMS - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E13.FR.01</td><td></td><td>The number of times and the interval with which the Charging Station should retry such failed transaction-related messages MAY be configured using the MessageAttemptsTransactionEvent and MessageAttemptIntervalTransactionEvent Configuration Variables.</td></tr><tr><td>E13.FR.02</td><td>When the Charging Station encounters a first failure to deliver a certain transaction-related message.</td><td>The Charging Station SHALL send this message again as long as it keeps resulting in a failure to process this message and it has not yet encountered as many failures to process this message for this message as specified in its MessageAttemptsTransactionEvent Configuration Variable.</td></tr><tr><td>E13.FR.03</td><td>The CSMS does not accept a transaction-related message.</td><td>The Charging Station SHALL wait as many seconds as specified in its MessageAttemptIntervalTransactionEvent key, multiplied by the number of preceding transmissions of this same message.</td></tr><tr><td>E13.FR.04</td><td>If the final attempt fails.</td><td>The Charging Station SHALL discard the message and continue with the next transaction-related message, if there is any.</td></tr></table>
+
+# E13 - Transaction-related message not accepted by CSMS - Example
+
+As an example, consider a Charging Station that has the value "3" for the MessageAttemptsTransactionEvent Configuration Variable and the value "60" for the MessageAttemptIntervalTransactionEvent Configuration Variable. It sends a TransactionEventRequest message and detects a failure to process the message in the CSMS. The Charging Station SHALL wait for 60 seconds, and resend the message. In the case when there is a second failure, the Charging Station SHALL wait for 120 seconds, before resending the message. If this final attempt fails, the Charging Station SHALL discard the message and continue with the next transaction-related message, if there is any.
+
+# E14 - Check transaction status
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Check transaction status</td></tr><tr><td>2</td><td>ID</td><td>E14</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td>3</td><td>Objectives</td><td>To enable the CSMS to request the status of a transaction and to find out whether there are queued transaction-related messages.</td></tr><tr><td>4</td><td>Description</td><td>There are scenarios where a CSMS needs to know whether there are still messages for a transaction that need to be delivered. For example: A CSMS receives a TransactionRequest (eventType = Ended), it wants to start the billing process for this transaction but detects it is still missing some intermediate messages (it can check this via the sequence number in the messages). It can ask if the Charging Station has still messages in the queue for this transaction with the GetTransactionStatusRequest specifying the transactionId. Depending on the result the CSMS might for example: wait for the messages to be delivered, or start the billing process without the information. It may also need to know whether a transaction is still ongoing. If the CSMS wants to know if there are transaction-related messages in the queue at all (not just for a specific transaction), it can send a GetTransactionStatusRequest without a transactionId.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a GetTransactionStatusRequest with or without a transactionId to the Charging Station.
+2. The Charging Station responds with a GetTransactionStatusResponse.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The CSMS knows the transactionId of a transaction it wants to know the status of.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The CSMS knows the status of the requested transaction.
+Failure postcondition:
+The CSMS does not know the status of the requested transaction.</td></tr></table>
+
+
+Figure 63. Sequence Diagram: Check transaction status
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>When the CSMS receives a GetTransactionStatusResponse with both fields (ongoingIndicator and messagesInQueue) set to false, this might mean that the transaction is finished and there are no more messages in the queue for this transaction, or the Charging Station doesn't know anything about this transaction (anymore).</td></tr></table>
+
+# E14 - Check transaction status - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td></tr><tr><td>E14.FR.01</td><td>The Charging Station receives a GetTransactionStatusRequest with a transactionId AND It did not do a transaction with that transactionId</td><td>The Charging Station SHALL respond with ongoingIndicator = false AND messagesInQueue = false.</td></tr><tr><td>E14.FR.02</td><td>The Charging Station receives a GetTransactionStatusRequest with a transactionId AND The transaction with that transactionId has not stopped yet</td><td>The Charging Station's response SHALL have ongoingIndicator = true.</td></tr><tr><td>E14.FR.03</td><td>The Charging Station receives a GetTransactionStatusRequest with a transactionId AND The transaction with that transactionId has stopped</td><td>The Charging Station's response SHALL have ongoingIndicator = false.</td></tr><tr><td>E14.FR.04</td><td>The Charging Station receives a GetTransactionStatusRequest with a transactionId AND It has transaction-related messages to be delivered about the transaction with that transactionId</td><td>The Charging Station's response SHALL have messagesInQueue = true.</td></tr><tr><td>E14.FR.05</td><td>The Charging Station receives a GetTransactionStatusRequest with a transactionId AND It has no transaction-related messages to be delivered about the transaction with that transactionId</td><td>The Charging Station's response SHALL have messagesInQueue = false.</td></tr><tr><td>E14.FR.06</td><td>The Charging Station receives a GetTransactionStatusRequest without a transactionId</td><td>The Charging Station's response SHALL NOT have ongoingIndicator set.</td></tr><tr><td>E14.FR.07</td><td>The Charging Station receives a GetTransactionStatusRequest without a transactionId AND It has transaction-related messages to be delivered</td><td>The Charging Station's response SHALL have messagesInQueue = true.</td></tr><tr><td>E14.FR.08</td><td>The Charging Station receives a GetTransactionStatusRequest without a transactionId AND It has no transaction-related messages to be delivered</td><td>The Charging Station's response SHALL have messagesInQueue = false.</td></tr></table>
+
+# 2.2. Interrupting and Stopping ISO 15118 Charging
+
+# E15 - End of charging process
+
+Table 122. E15 - End of charging process
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>End of charging process.</td></tr><tr><td>2</td><td>ID</td><td>E15</td></tr><tr><td></td><td>Functional block</td><td>E. Transactions</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 H1 - End of charging process</td></tr><tr><td>3</td><td>Objectives</td><td>See ISO15118-1, use case Objective H1, page 44.</td></tr><tr><td>4</td><td>Description</td><td>See ISO15118-1, use case Description H1, page 44.</td></tr><tr><td>5</td><td>Actors</td><td>EV, EVSE, EV Driver</td></tr><tr><td>6</td><td>Scenario Description</td><td>See ISO15118-1, use case Description H1, Basic elementary use case description, first 5 bullets and last 2 remarks, page 44.6. The EV driver unplugs the cable from the EV7. The Charging Station sends a TransactionRequest with eventType/eventType = Ended to the CSMS.</td></tr><tr><td>7</td><td>Prerequisites</td><td>See ISO15118-1, use case Prerequisites H1, page 44.</td></tr><tr><td>8</td><td>Postcondition(s)</td><td>The CSMS has received all relevant information about the transaction.See ISO15118-1, use case End Conditions H1, page 44.</td></tr></table>
+
+
+Figure 64. End of charging process
+
+<table><tr><td>9</td><td>Error handling</td><td>n/a</td></tr><tr><td>10</td><td>Remark(s)</td><td>See ISO15118-1, use case Requirements H1, page 44 for the trigger.
+The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.
+TxStopPoint: ParkingBayOccupancy, EVConnected, Authorized, DataSigned, PowerPathClosed This use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are sent. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+Source: ISO15118-1
+
+# E15 - End of charging process - Requirements
+
+Table 123. E15 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E15.FR.01</td><td>When configured to send meter data in the TransactionRequest (eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest (eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td></tr><tr><td>E15.FR.02</td><td>E15.FR.01 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message.</td></tr><tr><td>E15.FR.03</td><td>E15.FR.02</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td></tr><tr><td>E15.FR.04</td><td>When TxStopPoint contains "Authorized" or "PowerPathClosed" or "EnergyTransfer" AND Charging Station has not yet sent a TransactionRequest with triggerReason = StopAuthorized when it receives a ISO 15118 SessionStopReq(Terminate) message from the EV</td><td>Charging Station SHALL send a TransactionRequest message with eventType = Ended and triggerReason = StopAuthorized and stoppedReason = StoppedByEV to inform the CSMS that the charging transaction has been stopped (by the EV).</td></tr><tr><td>E15.FR.05</td><td>When TxStopPoint does not contain "Authorized" or "PowerPathClosed" or "EnergyTransfer" AND Charging Station has not yet sent a TransactionRequest with triggerReason = StopAuthorized when it receives a ISO 15118 SessionStopReq(Terminate) message from the EV</td><td>Charging Station SHALL send a TransactionRequest message with eventType = Updated and triggerReason = StopAuthorized to inform the CSMS that the authorization has ended.</td></tr></table>
+
+# F. RemoteControl
+
+# 1. Introduction
+
+This Functional Block describes three types of use cases for remote control management from the CSMS:
+
+1. Remote Transaction Control. These use cases describe the functionality which enable the CSO (or indirect a third party) to start/stop a transaction with a remote command.
+2. Unlocking a Connector. These use cases describe the functionality that enables the CSO (or indirect a third party) to unlock the Connector with a remote command. This can for example be used to assist customers when they have problems unplugging their cable.
+3. Remote Trigger. These use cases describe all the remote trigger functionality of OCPP. This functionality enables remote triggering of messages. For example, requesting messages to be send or request current status of some ongoing processes in the Charging Station.
+
+# 2. Use cases & Requirements
+
+# 2.1. Remote Transaction Control
+
+# F01 - Remote Start Transaction - Cable Plugin First
+
+Table 124. F01 - Remote Start Transaction - Cable Plugin First
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remote Start Transaction - Cable Plugin First</td></tr><tr><td>2</td><td>ID</td><td>F01</td></tr><tr><td></td><td>Functional block</td><td>F. Remote Control</td></tr><tr><td>3</td><td>Objective(s)</td><td>1. To remotely start a transaction by the CSMS.
+2. To enable a CSO to help an EV Driver that has problems starting a transaction.
+3. To enable third parties (e.g. mobile apps) to control charging transactions via the CSMS.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS remotely requests the Charging Station to start a transaction by sending RequestStartTransactionRequest. Upon receipt, the Charging Station responds with RequestStartTransactionResponse and a status indicating whether it is able to try to start a transaction or not.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver plugs in the cable at the Charging Station.
+2. The Charging Station sends a StatusNotificationRequest to the CSMS to inform it about a Connector that became Occupied.
+3. The CSMS responds with a StatusNotificationResponse, confirming that the StatusNotificationRequest was received.
+4. The Charging Station sends a TransactionEventRequest (eventType = Started) notifying the CSMS about a transaction that has started (even when the driver is not yet known.)
+5. The CSMS responds with a TransactionEventResponse, confirming that the TransactionEventRequest was received.
+6. An external trigger (as example in this use case: EV Driver) triggers the remote start.
+7. The CSMS sends a RequestStartTransactionRequest to the Charging Station.
+8. The Charging Station responds with a RequestStartTransactionResponse with the transactionId of the already started transaction to the CSMS.
+9. Optionally: the EV Driver is authorized by the CSMS.
+10. The Charging Station sends a TransactionEventRequest (eventType = Updated, chargingState = Charging) message to inform the CSMS that the charging has started.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>Remote Start Transaction - Remote Start First F02 - Remote Start Transaction - Remote Start First</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Cable plugged in first.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station offers energy. If the value of AuthorizeRemoteStart is true, the Charging Station will only offer energy when it successfully authorized the IdToken, using Local Authorization List, Authorization Cache and/or an AuthorizeRequest.</td></tr></table>
+
+
+Figure 65. Sequence Diagram: Remote Start Transaction - Cable Plugged in First
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>An external trigger can be e.g. a Charging Station Operator or an EV Driver app.The RequestStartTransactionResponse contains a status which indicates whether the Charging Station has accepted the request and will attempt to start a transaction.The CSMS is allowed to send a RequestStartTransactionRequest with IdTokenType of type: NoAuthorization. The operator should be aware that if the Charging Station supports local stop transaction, this transaction can be stopped by anyone.The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:TxStartPoint: EVConnected, Authorized, DataSigned, PowerPathClosed, EnergyTransferThis use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use cases: E01 - Start Transaction options.</td></tr></table>
+
+# F01 - Remote Start Transaction - Cable Plugin First - Requirements
+
+Table 125. F01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F01.FR.01</td><td>If the value of AuthorizedRemoteStart = true AND Charging Station receives a RequestStartTransactionRequest</td><td>The Charging Station SHALL behave as if in response to a local action at the Charging Station to allow energy transfer after successful authorization of the IdToken given in RequestStartTransactionRequest message.</td><td>Charging Station will first respond to the request and then try to authorize the IdToken, using the Local Authorization List, Authorization Cache and/or an AuthorizationRequest. Energy transfer is only allowed after authorization was obtained.</td></tr><tr><td>F01.FR.02</td><td>If the value of AuthorizedRemoteStart = false AND Charging Station receives a RequestStartTransactionRequest</td><td>The Charging Station SHALL allow energy transfer for the IdToken given in RequestStartTransactionRequest message without checking authorization.</td><td>Charging Station will first respond to the request, and send a TransactionEventRequest with the idToken to the CSMS, and the CSMS will check the authorization status of the IdToken when processing this TransactionEventRequest.</td></tr><tr><td>F01.FR.03</td><td>F01.FR.01 OR F01.FR.02</td><td>The Charging Station SHALL send a TransactionEventRequest to the CSMS, and the CSMS will check the authorization status of the IdToken when processing this TransactionEventRequest.</td><td>If CSMS returns an authorization status that is not Accepted, then Charging Station must stop energy transfer as per use case E05.</td></tr><tr><td>F01.FR.04</td><td></td><td>RequestStartTransactionRequest SHALL contain an IdToken, which Charging Station SHALL use, if it is able to start a transaction, in the TransactionEventRequest sent to the CSMS.</td><td></td></tr><tr><td>F01.FR.05</td><td></td><td>The transaction SHALL be started in the same way as described in E01 - Start Transaction - Cable Plugin First.</td><td></td></tr><tr><td>F01.FR.06</td><td></td><td>RequestStartTransactionRequest MAY contain an evseld if the transaction is to be started on a specific EVSE.</td><td>When no evseld is provided, the Charging Station is in control of the EVSE selection.</td></tr><tr><td>F01.FR.07</td><td>If the RequestStartTransactionRequest does not contain an evseld.</td><td>The Charging Station MAY reject the RequestStartTransactionRequest.</td><td></td></tr><tr><td>F01.FR.08</td><td></td><td>The CSMS MAY include a ChargingProfile in the RequestStartTransactionRequest.</td><td></td></tr><tr><td>F01.FR.09</td><td>F01.FR.08</td><td>The purpose of this ChargingProfile SHALL be set to TxProfile.</td><td></td></tr><tr><td>F01.FR.10</td><td>F01.FR.08</td><td>The Charging Station SHALL use this ChargingProfile for the transaction that is started by this RequestStartTransaction.</td><td></td></tr><tr><td>F01.FR.11</td><td>F01.FR.08</td><td>The transactionId in the ChargingProfile SHALL NOT be set.</td><td></td></tr><tr><td>F01.FR.12</td><td>If a Charging Station without support for Smart Charging receives a RequestStartTransactionRequest with a ChargingProfile.</td><td>The Charging Station SHALL ignore the specified ChargingProfile.</td><td>The device model variable SmartChargingCtrl.Enabling tells CSMS whether smart charging is supported.</td></tr><tr><td>F01.FR.13</td><td>When a transaction is created on the Charging Station, but has not been authorized. AND RequestStartTransactionRequest is received.</td><td>The Charging Station SHALL return the transactionId in the RequestStartTransactionResponse.</td><td></td></tr><tr><td>F01.FR.14</td><td>When configured to send meter data in the TransactionEventRequest (eventType = Started), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionEventRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td><td></td></tr><tr><td>F01.FR.15</td><td>When configured to send meter data in the TransactionEventRequest (eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionEventRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction.</td><td></td></tr><tr><td>F01.FR.16</td><td>F01.FR.15 AND Amount of meter data is too much for 1 TransactionEventRequest (eventType = Updated)</td><td>The Charging Station MAY split meter data over multiple TransactionEventRequest(eventType = Updated) messages with the same timestamp.</td><td></td></tr><tr><td>F01.FR.17</td><td>When sending a TransactionEventRequest</td><td>The Charging Station SHALL set the triggerReason to inform the CSMS about what triggered the event. What reason to use is described in the description of TriggerReasonEnumType.</td><td></td></tr><tr><td>F01.FR.18</td><td>After a transaction has been started</td><td>The Charging Station MAY send additional TransactionEventRequest(eventType = Updated) messages during the transaction when a trigger event occurs.</td><td></td></tr><tr><td>F01.FR.19</td><td>When a RequestStartTransactionRequest is received.</td><td>The next TransactionEventRequest SHALL contain triggerReason: RemoteStart.</td><td></td></tr><tr><td>F01.FR.20</td><td>If the RequestStartTransactionRequest does not contain an evseld AND the Charging Station is capable of selecting an EVSE</td><td>The Charging Station SHALL select an EVSE to be used as a value for evseld for the operation</td><td>See also F01.FR.07 if Charging Station does not support starting at an arbitrary EVSE.</td></tr><tr><td>F01.FR.21</td><td>When the evseld for RequestStartTransactionRequest is Reserved for an idToken that differs from idToken in the request AND has no reservation for a groupldToken</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td></td></tr><tr><td>F01.FR.22</td><td>When the evseld for RequestStartTransactionRequest is Reserved for an idToken that differs from idToken in the request AND is Reserved for a groupldToken that differs from groupldToken in the request</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td>EV is not allowed to use station if neither idToken nor idGroupToken match the reservation.</td></tr><tr><td>F01.FR.23</td><td>When the evse for RequestStartTransactionRequest is Unavailable or Faulted</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td></td></tr><tr><td>F01.FR.24</td><td>When the evseld for RequestStartTransactionRequest is Occupied AND this evseld has a transaction that has been authorized</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td>Only an EVSE with no transaction or with a transaction that has not yet been authorized can be matched with the RequestStartTransaction Request</td></tr><tr><td>F01.FR.25</td><td>F01.FR.13</td><td>The Charging Station SHALL put the remoteStartId in the next TransactionEventRequest it sends for the associated transaction.</td><td></td></tr><tr><td>F01.FR.26</td><td>If a Charging Station with support for Smart Charging receives a RequestStartTransactionRequest with an invalid ChargingProfile.</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected and optionally withreasonCode = "InvalidProfile" or "InvalidSchedule".</td><td>The device model variable SmartChargingCtrl.Enabl ed tells CSMS whether smart charging is supported.</td></tr></table>
+
+# F02 - Remote Start Transaction - Remote Start First
+
+Table 126. F02 - Remote Start Transaction - Remote Start First
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remote Start Transaction - Remote Start first</td></tr><tr><td>2</td><td>ID</td><td>F02</td></tr><tr><td></td><td>Functional block</td><td>F. Remote Control</td></tr><tr><td></td><td>Parent use case</td><td>F01 - Remote Start Transaction - Cable Plugin First</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to remotely start a transaction while the RequestStartTransactionRequest is sent first, before the connection between Charging Station and EV is established.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS is able to remotely start a transaction for the User.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, External Trigger</td></tr><tr><td></td><td>Scenario description</td><td>1. An External Trigger triggers the remote start.
+2. The CSMS sends RequestStartTransactionRequest to the Charging Station.
+3. The Charging Station responds with RequestStartTransactionResponse to the CSMS.
+4. The EV Driver is authorized by the CSMS, dependent on the Configuration Variable settings.
+5. The Charging Station sends a TransactionEventRequest (eventType = Started) notifying the CSMS about a transaction that has started
+6. The cable is plugged in.
+6a. Charging Station sends a StatusNotificationRequest with Occupied.
+6b. CSMS sends a StatusNotificationResponse to the Charging Station
+7. The energy offer is started.
+8. The Charging Station sends a TransactionEventRequest (eventType = Updated, chargingState = Charging) message to inform the CSMS that the charging has started.
+9. The CSMS sends TransactionEventResponse to the Charging Station</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Cable not plugged in.
+Remote start first.
+Enable mobile apps to control charging transactions via the CSMS.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction for which a start was request has started and the EV is charging.
+Failure postcondition:
+The transaction for which a start was request did not start or the EV is not charging.</td></tr></table>
+
+
+Figure 66. Sequence Diagram: Remote Start Transaction - Remote Start First with TxStartPoint=Authorized
+
+
+Figure 67. Sequence Diagram: Remote Start Transaction - Remote Start First with TxStartPoint=EVConnected
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>An external trigger can be e.g. a Charging Station Operator or an EV Driver app.
+It is advised not to start transactions remotely without evseld due to the uncertainty
+which EVSE is started. In case of a Logic Controller with many EVSEs, the EV Driver
+might not be in front of the activated EVSE.
+The CSMS is allowed to send a RequestStartTransactionRequest with IdTokenType of
+type: NoAuthorization. The operator should be aware that if the Charging Station
+supports local stop transaction, this transaction can be stopped by anyone.
+The scenario description and sequence diagram above are based on the Configuration
+Variable for start transaction being configured as follows:
+TxStartPoint: EVConnected, Authorized, DataSigned, PowerPathClosed,
+EnergyTransfer
+This use-case is also valid for other configurations, but then the transaction might
+start/stop at another moment, which might change the sequence in which message
+are send. For more details see the use cases: E01 - Start Transaction options.</td></tr></table>
+
+# F02 - Remote Start Transaction - Remote Start First - Requirements
+
+Table 127. F02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F02.FR.01</td><td>When a transaction is started as a result of a RequestStartTransactionRequest.</td><td>The Charging Station SHALL put the remoteStartId in the first TransactionEventRequest it sends for this new transaction.</td><td></td></tr><tr><td>F02.FR.02</td><td>When configured to send meter data in the TransactionEventRequest (eventType = Started), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionEventRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td><td></td></tr><tr><td>F02.FR.03</td><td>When configured to send meter data in the TransactionEventRequest (eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionEventRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction.</td><td></td></tr><tr><td>F02.FR.04</td><td>F02.FR.03 AND Amount of meter data is too much for 1 TransactionEventRequest (eventType = Updated)</td><td>The Charging Station MAY split meter data over multiple TransactionEventRequest(eventType = Updated) messages with the same timestamp.</td><td></td></tr><tr><td>F02.FR.05</td><td>When the IdToken information is known.</td><td>The next TransactionEventRequest SHALL contain IdTokenType information.</td><td></td></tr><tr><td>F02.FR.06</td><td>This transaction ends a reservation for the specific IdToken.</td><td>The next TransactionEventRequest SHALL contain the reservationId.</td><td>See H. Reservation.</td></tr><tr><td>F02.FR.07</td><td>When the EV Driver does not plug-in the charging cable before the timeout set by the Configuration Variable: EVConnectionTimeout AND TxStopPoint does not contain ParkingBayOccupancy</td><td>The Charging Station SHALL end the transaction and send a TransactionEventRequest (eventType = Ended, stoppedReason = Timeout, triggerReason = EVConnectionTimeout) to the CSMS.</td><td>Otherwise the transaction would not be ended in case the TxStopPoint does not contain Authorized.</td></tr><tr><td>F02.FR.08</td><td>When the EV Driver does not plug-in the charging cable before the timeout set by the Configuration Variable: EVConnectionTimeout AND TxStopPoint contains ParkingBayOccupancy</td><td>The Charging Station SHALL deauthorize the transaction and send a TransactionEventRequest (triggerReason = EVConnectionTimeout) to the CSMS.</td><td>Transaction will be ended normally when driver leaves the parking bay.</td></tr><tr><td>F02.FR.09</td><td>If the value of AuthorizationRemoteStart = true AND Charging Station receives a RequestStartTransactionRequest</td><td>The Charging Station SHALL behave as if in response to a local action at the Charging Station to start a transaction after successful authorization of the IdToken given in RequestStartTransactionRequest message.</td><td>Charging Station will first respond to the request and then try to authorize the IdToken, using the Local Authorization List, Authorization Cache and/or an AuthorizationRequest. A transaction is only started after authorization was obtained.</td></tr><tr><td>F02.FR.10</td><td>If the value of AuthorizationRemoteStart = false AND Charging Station receives a RequestStartTransactionRequest</td><td>The Charging Station SHALL start a transaction for the IdToken given in RequestStartTransactionRequest message without checking authorization.</td><td>Note that after the transaction has been started, the Charging Station will send a TransactionEventRequest with the IdToken to the CSMS, and the CSMS will check the authorization status of the IdToken when processing this TransactionEventRequest.</td></tr><tr><td>F02.FR.11</td><td>F02.FR.09 OR F02.FR.10</td><td>The Charging Station SHALL send a TransactionEventRequest to the CSMS, and the CSMS will check the authorization status of the IdToken when processing this TransactionEventRequest.</td><td></td></tr><tr><td>F02.FR.12</td><td></td><td>RequestStartTransactionRequest SHALL contain an IdToken, which Charging Station SHALL use, if it is able to start a transaction, in the TransactionRequest sent to the CSMS.</td><td></td></tr><tr><td>F02.FR.13</td><td></td><td>The transaction SHALL be started in the same way as described in E03 - Start Transaction - Id Token First.</td><td></td></tr><tr><td>F02.FR.14</td><td></td><td>RequestStartTransactionRequest MAY contain an evseld if the transaction is to be started on a specific EVSE.</td><td>When no evseld is provided, the Charging Station is in control of the EVSE selection.</td></tr><tr><td>F02.FR.15</td><td>If the RequestStartTransactionRequest does not contain an evseld.</td><td>The Charging Station MAY reject the RequestStartTransactionRequest.</td><td></td></tr><tr><td>F02.FR.16</td><td></td><td>The CSMS MAY include a ChargingProfile in the RequestStartTransactionRequest.</td><td></td></tr><tr><td>F02.FR.17</td><td>F02.FR.16</td><td>The purpose of this ChargingProfile SHALL be set to TxProfile.</td><td></td></tr><tr><td>F02.FR.18</td><td>F02.FR.16</td><td>The Charging Station SHALL use this ChargingProfile for the transaction that is started by this RequestStartTransaction.</td><td></td></tr><tr><td>F02.FR.19</td><td>F02.FR.16</td><td>The transactionId in the ChargingProfile SHALL NOT be set.</td><td></td></tr><tr><td>F02.FR.20</td><td>If a Charging Station without support for Smart Charging receives a RequestStartTransactionRequest with a ChargingProfile.</td><td>The Charging Station SHALL ignore the specified ChargingProfile.</td><td>The device model variable SmartChargingCtrl.Enabl ed tells CSMS whether smart charging is supported.</td></tr><tr><td>F02.FR.21</td><td>When a RequestStartTransactionRequest is received.</td><td>The next TransactionEventRequest SHALL contain triggerReason: RemoteStart and the remoteStartId from the RequestStartTransactionRequest.</td><td>This is to notify CSMS that this is the result of RequestStartTransaction . Note, that if TxStartPoint=EVCnnec ted the transaction will be started upon cable connection, but the triggerReason = RemoteStart must still be sent. The connection event is reported by the fact that chargingState = EVConnected.</td></tr><tr><td>F02.FR.22</td><td>If the RequestStartTransactionRequest does not contain an evseld AND the Charging Station is capable of selecting an EVSE</td><td>The Charging Station SHALL select an EVSE to be used as a value for evseld for the operation</td><td>See also F02.FR.15 if Charging Station does not support starting at an arbitrary EVSE.</td></tr><tr><td>F02.FR.23</td><td>When the evseld for RequestStartTransactionRequest is Reserved for an idToken that differs from idToken in the request AND has no reservation for a groupldToken</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td></td></tr><tr><td>F02.FR.24</td><td>When the evseld for RequestStartTransactionRequest is Reserved for an idToken that differs from idToken in the request AND is Reserved for a groupldToken that differs from groupldToken in the request</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td>EV is not allowed to use station if neither idToken nor idGroupToken match the reservation.</td></tr><tr><td>F02.FR.25</td><td>When the evseld for RequestStartTransactionRequest is Unavailable or Faulted</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td></td></tr><tr><td>F02.FR.26</td><td>When the evseld for RequestStartTransactionRequest is Occupied AND this evseld has a transaction that has been authorized</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td>Only an EVSE with no transaction or with a transaction that has not yet been authorized can be matched with the RequestStartTransaction Request</td></tr><tr><td>F02.FR.27</td><td>If a Charging Station with support for Smart Charging receives a RequestStartTransactionRequest with an invalid ChargingProfile.</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected and optionally with reasonCode = "InvalidProfile" or "InvalidSchedule".</td><td>The device model variable SmartChargingCtrl.Enabling tells CSMS whether smart charging is supported.</td></tr></table>
+
+# NOTE
+
+Requirements of previous use case: F01 - Remote Start Transaction - Cable Plugin First, are also considered relevant for F02 - Remote Start Transaction - Remote Start First
+
+# F03 - Remote Stop Transaction
+
+Table 128. F03 - Remote Stop Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remote Stop Transaction</td></tr><tr><td>2</td><td>ID</td><td>F03</td></tr><tr><td></td><td>Functional block</td><td>F. Remote Control</td></tr><tr><td>3</td><td>Objective(s)</td><td>1. To enable a CSO to help an EV Driver who has problems stopping a transaction. or
+2. Enable mobile apps to control transactions via the CSMS.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests the Charging Station to stop a transaction.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. An External Trigger triggers a remote stop.
+2. The CSMS requests a Charging Station to stop a transaction by sendingRequestStopTransactionRequest to the Charging Station with the transactionId of the transaction.
+3. The Charging Station responds with RequestStopTransactionResponse and a status indicating whether it has accepted the request and a transaction with the given transactionId is ongoing and will be stopped.
+4. Charging is stopped, the Charging Station sends TransactionEventRequest (eventType = Updated) and, if applicable, unlocks the Connector.
+5. After the EV Driver unplugs the cable, the Charging Station sends StatusNotificationRequest with status Available.
+6. The Charging Station ends the transaction and sends a TransactionEventRequest (eventType = Ended, stoppedReason = Remote) message to the CSMS.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A transaction is ongoing.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction for which a stop was request has ended.
+Failure postcondition:
+The transaction for which a stop was requested is still ongoing.</td></tr></table>
+
+
+Figure 68. Sequence Diagram: Remote Stop Transaction
+
+<table><tr><td>7</td><td>Remark(s)</td><td>This remote request to stop a transaction is equal to a local action to stop a transaction.
+The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.
+TxStopPoint: ParkingBayOccupancy, EVConnected
+This use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are send. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+# F03 - Remote Stop Transaction - Requirements
+
+Table 129. F03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F03.FR.01</td><td>When the CSMS receives a remote stop transaction trigger (For example when terminating using a smartphone app, exceeding a (non local) prepaid credit.)</td><td>The CSMS SHALL send a RequestStopTransactionRequest to the Charging Station with the transactionId of the transaction.</td><td></td></tr><tr><td>F03.FR.02</td><td>F03.FR.01 AND TxStopPoint configuration does not cause transaction to end (E.g. TxStopPoint is NOT Authorized or PowerPathClosed)</td><td>The Charging Station SHALL stop the energy offer and send a TransactionEventRequest (eventType = Updated, triggerReason = RemoteStop) to the CSMS.</td><td>For example when TxStopPoint = EVConnected the transaction will not be ended until EV is disconnected.</td></tr><tr><td>F03.FR.03</td><td>F03.FR.01 AND TxStopPoint configuration causes transaction to end (E.g. TxStopPoint is Authorized or PowerPathClosed)</td><td>The Charging Station SHALL send a TransactionEventRequest (eventType = Ended, triggerReason = RemoteStop, stoppedReason = Remote) to the CSMS.</td><td></td></tr><tr><td>F03.FR.04</td><td>When configured to send meter data in the TransactionRequest(eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td><td></td></tr><tr><td>F03.FR.05</td><td>F03.FR.04 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data.</td><td></td></tr><tr><td>F03.FR.06</td><td>F03.FR.05</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td><td></td></tr><tr><td>F03.FR.07</td><td>When the Charging Station receives a RequestStopTransactionRequest</td><td>And the TransactionId can be matched to an active transaction; the Charging Station SHALL respond with a RequestStopTransactionResponse with status set to Accepted.</td><td></td></tr><tr><td>F03.FR.08</td><td>When the Charging Station receives a RequestStopTransactionRequest</td><td>And the TransactionId cannot be matched to an active transaction; the Charging Station SHALL respond with a RequestStopTransactionResponse with status set to Rejected.</td><td></td></tr><tr><td>F03.FR.09</td><td>When sending a TransactionEventRequest</td><td>The Charging Station SHALL set the triggerReason to inform the CSMS about what triggered the event. What reason to use is described in the description of TriggerReasonEnumType.</td><td></td></tr></table>
+
+# F04 - Remote Stop ISO 15118 Charging from CSMS
+
+Table 130. F04 - Charging loop with interrupt from the CSMS
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remote Stop ISO 15118 Charging from CSMS</td></tr><tr><td>2</td><td>ID</td><td>F04</td></tr><tr><td></td><td>Functional block</td><td>F. Remote Control</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 F2 Charging loop with interrupt from the SECC.</td></tr><tr><td>3</td><td>Objectives</td><td>See ISO15118-1, use case Objective F2, page 38.</td></tr><tr><td>4</td><td>Description</td><td>See ISO15118-1, use case Description F2, page 38.</td></tr><tr><td>5</td><td>Actors</td><td>EV, EVSE, Charging Station</td></tr><tr><td>6</td><td>Prerequisites</td><td>- If authorization according use cases in Functional Block C is applied, it SHALL be finished successfully.
+See ISO15118-1, use case Prerequisites F2, page 38.</td></tr><tr><td>7</td><td>Combined scenario description</td><td>OCPP:
+1. The CSMS sends a RequestStopTransactionRequest to the Charging Station.
+2. The Charging Station responds with a RequestStopTransactionResponse.
+ISO 15118:
+3. The EV sends a ChargingStatus (in case of AC charging) or CurrentDemandReq (in case of DC Charging) PDU to the Charging Station.
+4. The Charging Station responds with an EVSENotification = StopCharging.</td></tr><tr><td>8</td><td>Postcondition(s)</td><td>See ISO15118-1, use case End conditions F2, page 38.</td></tr></table>
+
+
+Figure 69. Charging loop with interrupt from the Charging Station
+
+<table><tr><td>9</td><td>Error handling</td><td>n/a</td></tr><tr><td>10</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# F04 - Remote Stop ISO 15118 Charging from CSMS - Requirements
+
+These requirements are normative.
+
+Table 131. F04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F04.FR.01</td><td>When the CSMS receives a remote stop transaction trigger (For example when terminating using a smartphone app, exceeding a (non local) prepaid credit.)</td><td>The CSMS SHALL send a RequestStopTransactionRequest to the Charging Station with the transactionId of the transaction.</td><td></td></tr><tr><td>F04.FR.02</td><td>F04.FR.01</td><td>The Charging Station SHALL stop the energy offer, unlock the cable and send a TransactionRequest (eventType = Updated) to the CSMS.</td><td>Cable unlocked if not permanently attached.</td></tr><tr><td>F04.FR.03</td><td>F04.FR.02 AND When the EV Driver unplugs the cable.</td><td>The Charging Station SHALL send a TransactionRequest (eventType = Ended, stoppedReason = Remote) to the CSMS.</td><td></td></tr><tr><td>F04.FR.04</td><td>When configured to send meter data in the TransactionRequest (eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td><td></td></tr><tr><td>F04.FR.05</td><td>F04.FR.04 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data.</td><td></td></tr><tr><td>F04.FR.06</td><td>F04.FR.05</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td><td></td></tr></table>
+
+# 2.2. Unlock Connector
+
+# F05 - Remotely Unlock Connector
+
+Table 132. F05 - Remotely Unlock Connector
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remotely Unlock Connector</td></tr><tr><td>2</td><td>ID</td><td>F05</td></tr><tr><td></td><td>Functional block</td><td>F. RemoteControl</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSO to help an EV-driver that has problems unplugging his charging cable because the locked failed after the transaction has ended.</td></tr><tr><td>4</td><td>Description</td><td>It sometimes happens that a connector of a Charging Station socket does not unlock correctly. This happens most of the time when there is tension on the charging cable. This means the driver cannot unplug his charging cable from the Charging Station. To help a driver, the CSO can send a UnlockConnectorRequest to the Charging Station. The Charging Station will then try to unlock the connector again.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, External Trigger</td></tr><tr><td></td><td>Scenario description</td><td>1. An External Trigger (probably the CSO) request the unlocking of a specific connector of a Charging Station.
+2. The CSMS sends an UnlockConnectorRequest to the Charging Station.
+3. Upon receipt of UnlockConnectorRequest, the Charging Station responds with UnlockConnectorResponse.
+4. The response message indicates whether the Charging Station was able to unlock its Connector.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>No ongoing transaction on the specified connector
+The Charging Station has a connector lock.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station was able to unlock the Connector.</td></tr></table>
+
+
+
+Figure 70. Sequence Diagram: Unlock Connector
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>An external trigger, triggering the Unlock command, can be e.g. a Charging Station Operator or an EV Driver app.UnlockConnectorRequest is intended only for unlocking the cable retention lock on the Connector, not for unlocking a Connector access door.</td></tr></table>
+
+# F05 - Remotely Unlock Connector - Requirements
+
+Table 133. F05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>F05.FR.01</td><td>Upon receipt of an UnlockConnectorRequest.</td><td>The Charging Station SHALL respond with UnlockConnectorResponse.</td></tr><tr><td>F05.FR.02</td><td>F05.FR.01ANDThere is a authorized transaction ongoing on the specified connector.</td><td>The Charging Station SHALL NOT try to unlock the connector (or stop the transaction) but use the status: OngoingAuthorizedTransaction in the UnlockConnectorResponse.</td></tr><tr><td>F05.FR.03</td><td>F05.FR.01ANDSpecified connector unknown.</td><td>The Charging Station SHALL use the status: UnknownConnector in the UnlockConnectorResponse.</td></tr><tr><td>F05.FR.04</td><td>F05.FR.01ANDThe Charging Station was able to unlock the specified connector.</td><td>The Charging Station SHALL use the status: Unlocked in the UnlockConnectorResponse.</td></tr><tr><td>F05.FR.05</td><td>F05.FR.01ANDThe Charging Station was NOT able to unlock the specified connector.</td><td>The Charging Station SHALL use the status: UnlockFailed in the UnlockConnectorResponse.</td></tr><tr><td>F05.FR.06</td><td>F05.FR.01 ANDNo cable is connected to the connector.</td><td>The Charging Station SHALL attempt to unlock the connector, even if no cable is detected and SHALL return the result of the unlock attempt.</td></tr></table>
+
+# 2.3. Remote Trigger
+
+# F06 - Trigger Message
+
+Table 134. F06 - Trigger Message
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Trigger Message</td></tr><tr><td>2</td><td>ID</td><td>F06</td></tr><tr><td></td><td>Functional block</td><td>F. RemoteControl</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to request a Charging Station to send a Charging Station-initiated message.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes the use of the TriggerMessageRequest message: how a CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a TriggerMessageRequest to the Charging Station.
+2. The Charging Station responds with a TriggerMessageResponse, indicating whether it will send it or not, by returning Accepted, Rejected or NotImplemented.
+3. Message, requested by the CSMS, that the Charging Station marked as Accepted, is being sent.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Functional Block Remote Trigger is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postconditions:
+1. The CSMS has Successfully received a TriggerMessageResponse message.
+2. The CSMS has Successfully received a TriggerMessageResponse message with status Accepted AND has Successfully received the requested message.
+Failure postconditions:
+1. The CSMS has NOT received a TriggerMessageResponse message.
+2. The CSMS has Successfully received a TriggerMessageResponse message with status Accepted AND has NOT received the requested message.</td></tr></table>
+
+
+Figure 71. Sequence Diagram: Trigger Message
+
+
+Figure 72. Sequence Diagram: Trigger Message Example
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The TriggerMessage mechanism is not intended to retrieve historic data.</td></tr></table>
+
+# F06 - Trigger Message - Requirements
+
+Table 135. F06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F06.FR.01</td><td></td><td>In the TriggerMessageRequest message, the CSMS SHALL indicate which message(s) it wishes to receive.</td><td></td></tr><tr><td>F06.FR.02</td><td>F06.FR.01.For every such requested message.</td><td>The CSMS MAY indicate to which EVSE this request applies.</td><td></td></tr><tr><td>F06.FR.03</td><td>F06.FR.02</td><td>The requested message SHALL be leading. If the specified evseld is not relevant to the message, it SHALL be ignored. In such cases the requested message SHALL still be sent.</td><td></td></tr><tr><td>F06.FR.04</td><td>If a Charging Station receives a TriggerMessageRequest.</td><td>The Charging Station SHALL first send the TriggerMessage response, before sending the requested message.</td><td></td></tr><tr><td>F06.FR.05</td><td>F06.FR.04</td><td>In the TriggerMessageResponse the Charging Station SHALL indicate whether it will send the requested message or not, by returning Accepted or Rejected.</td><td>It is up to the Charging Station if it accepts or rejects the request to send.</td></tr><tr><td>F06.FR.06</td><td>If a Charging Station accepts a TriggerMessageRequest with requestedMessage set to: MeterValues</td><td>The Charging Station SHALL send a MeterValuesRequest to the CSMS with the most recent measurements for all measurands configured in Configuration Variable: AlignedDataMeasurands.</td><td></td></tr><tr><td>F06.FR.07</td><td>If a Charging Station accepts a TriggerMessageRequest with requestedMessage set to: TransactionEvent</td><td>The Charging Station SHALL send a TransactionRequest to the CSMS with triggerReason = Trigger, transactionInfo with at least the chargingState, and meterValue with the most recent measurements for all measurands configured in Configuration Variable: SampledDataTxUpdatedMeasurands.</td><td></td></tr><tr><td>F06.FR.08</td><td>When the Charging Station receives a TriggerMessageRequest with a requestedMessage that it has not implemented</td><td>The Charging Station SHALL respond with TriggerMessageResponse with status NotImplemented.</td><td></td></tr><tr><td>F06.FR.09</td><td></td><td>The messages it triggers SHALL only give current information.</td><td></td></tr><tr><td>F06.FR.10</td><td></td><td>Messages that the Charging Station marks as Accepted SHALL be sent.</td><td>E.g. the situation could occur that, between accepting the request and actually sending the requested message, that same message gets sent because of normal operations. In such cases the message just sent MAY be considered as complying with the request.</td></tr><tr><td>F06.FR.11</td><td>If the field evse is relevant but absent in the TriggerMessageRequest.</td><td>The Charging Station SHALL interpret this as "for all allowed evse values".</td><td>StatusNotifications can only be requested for a specific connector, see F06.FR.12/13</td></tr><tr><td>F06.FR.12</td><td>If a Charging Station receives a TriggerMessageRequest with requestedMessage set to: StatusNotification AND (evse is omitted OR evseconnectorId is omitted)</td><td>The Charging Station MAY respond with a TriggerMessageResponse with status Rejected.</td><td>StatusNotification messages can only be requested at connector level.</td></tr><tr><td>F06.FR.13</td><td>When sending a TriggerMessageRequest with requestedMessage set to: StatusNotification</td><td>The CSMS SHALL set the connectorld field</td><td>StatusNotification messages can only be sent at connector level.</td></tr><tr><td>F06.FR.14</td><td>If a Charging Station receives a TriggerMessageRequest with requestedMessage set to: LogStatusNotification AND The Charging Station is uploading a log file</td><td>The Charging Station SHALL send a LogStatusNotificationRequest to the CSMS with status Uploading.</td><td></td></tr><tr><td>F06.FR.15</td><td>If a Charging Station receives a TriggerMessageRequest with requestedMessage set to: LogStatusNotification AND The Charging Station is NOT uploading a log file</td><td>The Charging Station SHALL send a LogStatusNotificationRequest to the CSMS with status Idle.</td><td></td></tr><tr><td>F06.FR.16</td><td>If a Charging Station receives a TriggerMessageRequest with requestedMessage set to: FirmwareStatusNotification AND The Charging Station is not performing firmware update related tasks.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest to the CSMS with status Idle.</td><td></td></tr><tr><td>F06.FR.17</td><td>If Charging Station receives a TriggerMessageRequest with requestedMessage set to: BootNotification AND the response it received from CSMS to the last BootNotificationRequest was: Accepted</td><td>Charging Station SHALL respond with a TriggerMessageResponse with status Rejected.</td><td>A trigger to request a Charging Station to send a BootNotification is only meant to be used when the BootNotification has not yet been accepted.</td></tr></table>
+
+# G. Availability
+
+# 1. Introduction
+
+This Functional Block specifies how the Charging Station can inform the CSMS of its current availability for starting new transactions.
+
+For the CSO it is important to know if a Charging Station is available for new EVs to be charged. The CSO wants to know this information so they can tell EV Drivers whether the Charging Station is available. To know this, the Charging Station should send any status changes of itself or one of its EVSEs to the CSMS. See for an example: B04 - Offline Behavior Idle Charging Station.
+
+For the CSO it is very helpful to know the status of the transaction, therefore the Charging Station can send detailed statuses to the CSMS. This can be very useful when helping an EV Driver when he experiences problems during charging.
+
+When a fault is detected by the Charging Station it can send a message notifying the CSMS about the fault.
+
+When the CSO wants the Charging Station to no longer start new transactions, it can change the availability. For example: they need to do maintenance on the Charging Station, and for this reason they don't want the Charging Station to be in use.
+
+The CSO can also change the availability for one or more EVSEs. For example: A customer calls, complaining about a broken EVSE on the Charging Station. The CSO can then set the Connector to unavailable, making it impossible for an EV Driver to use that Connector.
+
+Obviously, it is also possible to make the Charging Station or a Connector available again with a command from the CSMS.
+
+NOTE An overview of the Connectors Statuses can be found in: ConnectorStatusEnumType.
+
+# 2. Use cases & Requirements
+
+# G01 - Status Notification
+
+Table 136. G01 - Status Notification
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Status Notification</td></tr><tr><td>2</td><td>ID</td><td>G01</td></tr><tr><td></td><td>Functional block</td><td>G. Availability</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS about a Connector status change.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers the functionality that a Charging Station sends a notification to the CSMS to inform the CSMS about a Connector status change.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. A connector status changed, the Charging Station sends a StatusNotificationRequest to the CSMS to inform the CSMS about the new status.
+2. The CSMS responds with StatusNotificationResponse to the Charging Station.</td></tr><tr><td></td><td>Alternative scenario</td><td>1. 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 evseconnectorId, and variable = "AvailabilityState" with the value of the new status to the CSMS.
+1a. Optionally, Charging Station can also include the state of component = "ChargingStation" and component = "EVSE" in the NotifyEventRequest.
+2. The CSMS responds with NotifyEventResponse to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postconditions:
+The CSMS is Successfully informed about the status change.
+Failure postconditions:
+n/a</td></tr></table>
+
+# Charging Station
+
+# CSMS
+
+StatusNotificationRequest(heveld, connectorId, connectorStatus, [timestamp])
+
+StatusNotificationResponse()
+
+Figure 73. Sequence Diagram: Status Notification
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The Charging Station MAY use the Unavailable status internally for other purposes (e.g. while updating firmware or waiting for an initial Accepted RegistrationStatus). When one of the connectors on an EVSE is Reserved/Occupy, the CSMS has to take care of the status of the other connectors when presenting availability information to another system or user. The CSMS knows which connectors belong to the same EVSE.Notifying a connector status from the Charging Station to the CSMS will be taken over by the new Device Management Monitoring feature, however this mechanism has not been proven in the field yet. So the old StatusNotificationRequest message remains available for use for now.</td></tr></table>
+
+# G01 - Status Notification - State transition overview for connecting/disconnecting
+
+<table><tr><td>Initial</td><td>Cable plugin</td><td>Cable unplug</td></tr><tr><td>Available</td><td>→ Occupied</td><td>-</td></tr><tr><td>Occupied</td><td>-</td><td>→ Available
+(→ Unavailable, if scheduled to become Unavailable)</td></tr><tr><td rowspan="2">Reserved</td><td>-</td><td rowspan="2">-</td></tr><tr><td>(→ Occupied, only if authorized for reserved IdToken )</td></tr><tr><td>Unavailable</td><td>-</td><td>-</td></tr><tr><td>Faulted</td><td>-</td><td>-</td></tr></table>
+
+# G01 - Status Notification - Requirements
+
+Table 137. G01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>G01.FR.01</td><td></td><td>A Charging Station Connector MUST have one of the valid statuses from the ConnectorStatus enumeration.</td></tr><tr><td>G01.FR.02</td><td>When an EVSE is set to status Unavailable by a ChangeAvailabilityRequest message.</td><td>The EVSE's Unavailable status SHALL be persistent across reboots.</td></tr><tr><td>G01.FR.03</td><td>The connector is Available when an EV is connecting</td><td>The Charging Station SHALL send a StatusNotificationRequest with connectorStatus = Occupied or a NotifyEventRequest for component = "Connector", variable = "AvailabilityState", actualValue = "Occupied" and trigger = "Delta".</td></tr><tr><td>G01.FR.04</td><td>The connector is Occupied when an EV is disconnecting AND connector is not scheduled to become Unavailable (G03.FR.05)</td><td>The Charging Station SHALL send a StatusNotificationRequest with connectorStatus = Available when an EV is disconnected or a NotifyEventRequest for component = "Connector", variable = "AvailabilityState", actualValue = "Available" and trigger = "Delta".</td></tr><tr><td>G01.FR.05</td><td>The connector is Occupied when an EV is disconnecting AND connector is scheduled to become Unavailable (G03.FR.05)</td><td>The Charging Station SHALL send a StatusNotificationRequest with connectorStatus = Unavailable when an EV is disconnected or a NotifyEventRequest for component = "Connector", variable = "AvailabilityState", actualValue = "Unavailable" and trigger = "Delta".</td></tr><tr><td>G01.FR.06</td><td>The connector is Reserved when an EV is connecting AND EV driver presents an IdToken matching the reservation</td><td>The Charging Station SHALL send a StatusNotificationRequest with connectorStatus = Occupied or a NotifyEventRequest for component = "Connector", variable = "AvailabilityState", actualValue = "Occupied" and trigger = "Delta".</td></tr><tr><td>G01.FR.07</td><td>When a ChangeAvailabilityRequest leads to a connector status change</td><td>The Charging Station SHALL send a StatusNotificationRequest with the corresponding connectorStatus or a NotifyEventRequest for component = "Connector", variable = "AvailabilityState", trigger = "Delta" and the corresponding actualValue of "AvailabilityState".</td></tr><tr><td>G01.FR.08</td><td>When a cable is plugged in to a connector of an EVSE AND The EVSE has multiple connectors</td><td>The Charging Station SHOULD NOT send a StatusNotificationRequest for the other connector(s), even though they are no longer usable.</td></tr></table>
+
+# G02 - Heartbeat
+
+Table 138. G02 - Heartbeat
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Heartbeat</td></tr><tr><td>2</td><td>ID</td><td>G02</td></tr><tr><td></td><td>Functional block</td><td>G. Availability</td></tr><tr><td>3</td><td>Objective(s)</td><td>To let the CSMS know that a Charging Station is still connected, optionally the Heartbeat can be used for time synchronisation.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes a way to let the CSMS know the Charging Station is still connected, a Charging Station sends a heartbeat after a configurable time interval. Depending on the configuration the Heartbeat can be used for time synchronisation.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. If there is no activity for a certain time, the Charging Station sends HeartbeatRequest for ensuring that the CSMS knows that a Charging Station is still alive.
+2. Upon receipt of HeartbeatRequest, the CSMS responds with HeartbeatResponse. The response message contains the current time of the CSMS, which the Charging Station MAY use to synchronize its internal clock.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The heartbeat interval is set.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postconditions::The CSMS knows the Charging Station is still connected.
+Failure postconditions:The CSMS concludes that the Charging Station is Offline.</td></tr></table>
+
+
+
+Figure 74. Sequence Diagram: Heartbeat
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>With JSON over WebSocket, sending heartbeats is not instrumental to keeping web sockets alive, since web sockets already provide a mechanism for this. However, if the Charging Station uses the heartbeat for time synchronization, it is advised to at least send one heartbeat per 24 hours.</td></tr></table>
+
+# G02 - Heartbeat - Requirements
+
+Table 139. G02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>G02.FR.01</td><td>When the CSMS responds with BootNotificationResponse with a status Accepted.</td><td>The Charging Station SHALL adjust the heartbeat interval in accordance with the interval from the response message.</td><td></td></tr><tr><td>G02.FR.02</td><td></td><td>The Charging Station SHALL send HeartbeatRequest after a configurable time interval.</td><td>To ensure that the CSMS knows that a Charging Station is still alive.</td></tr><tr><td>G02.FR.03</td><td></td><td>The HeartbeatResponse message SHALL contain the current time of the CSMS.</td><td></td></tr><tr><td>G02.FR.04</td><td>Whenever a message from a Charging Station has been received.</td><td>The CSMS SHALL assume availability of that Charging Station.</td><td></td></tr><tr><td>G02.FR.05</td><td></td><td>It is RECOMMENDED that the Charging Station resets its heartbeat interval timer when another message has been sent to the CSMS.</td><td></td></tr><tr><td>G02.FR.06</td><td>When the Charging Station receives a HeartbeatResponse.</td><td>It is RECOMMENDED that the Charging Station uses the current time to synchronize its internal clock.</td><td></td></tr><tr><td>G02.FR.07</td><td>When the heartbeat interval timer is continuously reset because of continuous sending of messages AND HeartbeatRequest is used for time synchronisation</td><td>It is RECOMMENDED that the Charging Station sends a HeartbeatRequest at least once every 24 hours to synchronize the clock.</td><td></td></tr></table>
+
+# G03 - Change Availability EVSE/Connector
+
+Table 140. G03 - Change Availability EVSE/Connector
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Change Availability EVSE/Connector</td></tr><tr><td>2</td><td>ID</td><td>G03</td></tr><tr><td></td><td>Functional block</td><td>G. Availability</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to change the availability of an EVSE or Connector to Operative or Inoperative.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs or Connectors to Operative or Inoperative. An EVSE/Connector is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends ChangeAvailabilityRequest requesting a Charging Station to change the availability of an EVSE or Connector.
+2. The Charging Station changes the availability to the EVSE/Connector to the requested operationalStatus from the ChangeAvailabilityRequest.
+3. Upon receipt of ChangeAvailabilityRequest, the Charging Station responds with ChangeAvailabilityResponse. In case that the status 'Scheduled' is reported in the ChangeAvailabilityResponse, a transaction was running and this will be finished first.
+4. The Charging Station reports the status of the EVSE/Connector using a StatusNotification.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>G04 - Change Availability Charging Station</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+When changing the availability of an EVSE/Connector to Operative, the status of the EVSE has changed to Available, Occupied or Reserved.
+When changing the availability of an EVSE/Connector to Inoperative, the status of the EVSE has changed to Unavailable.
+Failure postcondition:
+The status of the EVSE is as it was just before the Charging Station received ChangeAvailabilityRequest and not according to the requested Availability.</td></tr></table>
+
+
+Figure 75. Sequence Diagram: Change Availability
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Persistent states, for example:
+EVSE set to Available SHALL persist a reboot.</td></tr></table>
+
+# G03 - Change Availability EVSE - Requirements
+
+Table 141. G03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>G03.FR.01</td><td>Upon receipt of ChangeAvailabilityRequest.</td><td>The Charging Station SHALL respond with ChangeAvailabilityResponse.</td><td></td></tr><tr><td>G03.FR.02</td><td>G03.FR.01</td><td>This response message SHALL indicate whether the Charging Station is able to change to the requested availability.</td><td></td></tr><tr><td>G03.FR.03</td><td>In the event that CSMS requests the Charging Station to change an EVSE or Connector to the state it is already in.</td><td>The Charging Station SHALL respond with availability status Accepted.</td><td></td></tr><tr><td>G03.FR.04</td><td>When an availability change request with ChangeAvailabilityRequest has changed the state of a Connector.</td><td>The Charging Station SHALL inform the CSMS of its new Connector availability status with StatusNotificationRequest.</td><td>As described in ChangeAvailabilityStatus EnumType</td></tr><tr><td>G03.FR.05</td><td>When a transaction is in progress AND NOT G03.FR.03</td><td>The Charging Station SHALL respond with availability status Scheduled to indicate that it is scheduled to occur after the transaction has finished.</td><td></td></tr><tr><td>G03.FR.06</td><td>When the availability of an EVSE becomes Inoperative (Unavailable, Faulted)</td><td>All operative connectors (i.e. not Faulted) of that EVSE SHALL become Unavailable.</td><td></td></tr><tr><td>G03.FR.07</td><td>When the availability of an EVSE becomes Operative</td><td>The Charging Station SHALL revert the status of all connectors of that EVSE to their original status.</td><td>See Note 1.</td></tr><tr><td>G03.FR.08</td><td>When the availability of an EVSE or Connector has been set explicitly via ChangeAvailabilityRequest</td><td>The set availability state SHALL be persistent across reboot/power loss.</td><td></td></tr><tr><td>G03.FR.09</td><td>The connector is Reserved when an EV is connecting AND EV driver has not presented an IdToken matching the reservation</td><td>Connector status SHALL not change.</td><td>Connector stays reserved until IdToken matching reservation is presented or reservation expires.</td></tr></table>
+
+# NOTE
+
+1. The Charging Station, EVSEs and Connectors have separate / individual states. This means (for example) that when setting a connector to Inoperative, then setting the connected EVSE to Inoperative and thereafter change the EVSE back to operative, the connector will remain Inoperative.
+
+# NOTE
+
+2. It is only required to report a status change of a connector. StatusNotificationRequest only supports the reporting of connector statuses.
+
+# G04 - Change Availability Charging Station
+
+Table 142. G04 - Change Availability Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Change Availability Charging Station</td></tr><tr><td>2</td><td>ID</td><td>G04</td></tr><tr><td></td><td>Functional block</td><td>G. Availability</td></tr><tr><td></td><td>Parent use case</td><td>G03 - Change Availability EVSE/Connector</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to change the availability of a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests the Charging Station to change the availability.A Charging Station is considered Operative when it is charging or ready for charging.A Charging Station is considered Inoperative when it does not allow any charging.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a ChangeAvailabilityRequest for requesting a Charging Station to change its availability.2. Upon receipt of a ChangeAvailabilityRequest, the Charging Station responds with ChangeAvailabilityResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The CSMS was able to change the availability of the Charging Station.When changing the availability of a Charging Station to Operative, the status of the Charging Station has changed to Available.When changing the availability of a Charging Station to Inoperative, the status of the Charging Station has changed to Unavailable.Failure postcondition:The CSMS was not able to change the requested Charging Station's availability.</td></tr></table>
+
+
+Figure 76. Sequence Diagram: Change Availability Charging Station
+
+Table 143. G04 - Requirements
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Persistent states: for example, Charging Station set to Unavailable SHALL persist a reboot.</td></tr></table>
+
+# G04 - Change Availability Charging Station - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>G04.FR.01</td><td>In the case the evse field is omitted in ChangeAvailabilityRequest.</td><td>The Charging Station status change SHALL apply to the whole Charging Station.</td><td></td></tr><tr><td>G04.FR.02</td><td>Upon receipt of ChangeAvailabilityRequest.</td><td>The Charging Station SHALL respond with ChangeAvailabilityResponse.</td><td></td></tr><tr><td>G04.FR.03</td><td>G04.FR.02</td><td>This response message SHALL indicate whether the Charging Station is able to change to the requested availability.</td><td></td></tr><tr><td>G04.FR.04</td><td>In the event that CSMS requests the Charging Station to change to the state it is already in.</td><td>The Charging Station SHALL respond with availability status Accepted.</td><td></td></tr><tr><td>G04.FR.05</td><td>When an availability change request with ChangeAvailabilityRequest has happened.</td><td>The Charging Station SHALL inform the CSMS by sending the status of each of the changed connectors via a StatusNotificationRequest</td><td>As described in ConnectorStatusEnumType</td></tr><tr><td>G04.FR.06</td><td>When a transaction is in progress.</td><td>The Charging Station SHALL respond with availability status Scheduled to indicate that it is scheduled to occur after the transaction has finished.</td><td></td></tr><tr><td>G04.FR.07</td><td>When the availability of the Charging Station becomes Inoperative (Unavailable, Failed)</td><td>All operative EVSEs and connectors (i.e. not Faulted) SHALL become Unavailable.</td><td></td></tr><tr><td>G04.FR.08</td><td>When the availability of the Charging Station becomes Operative</td><td>The Charging Station SHALL revert the status of all EVSEs and connectors to their original status.</td><td>See Note 1.</td></tr><tr><td>G04.FR.09</td><td>When the availability of a Charging Station has been set explicitly via ChangeAvailabilityRequest</td><td>The set availability state SHALL be persistent across reboot/power loss.</td><td></td></tr></table>
+
+# NOTE
+
+1. The Charging Station, EVSEs and Connectors have separate / individual states. This means (for example) that when setting a connector to Inoperative, then setting the connected EVSE to Inoperative and thereafter change the EVSE back to operative, the connector will remain Inoperative.
+
+# NOTE
+
+2. It is only required to report a status change of a connector. StatusNotificationRequest only supports the reporting of connector statuses.
+
+# G05 - Lock Failure
+
+Table 144. G05 - Lock Failure
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Lock Failure</td></tr><tr><td>2</td><td>ID</td><td>G05</td></tr><tr><td></td><td>Functional block</td><td>G. Availability</td></tr><tr><td>3</td><td>Objective(s)</td><td>To prevent the EV Driver from charging while the Connector is not properly locked.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the EV Driver is prevented from starting a charge session at the Charging Station while the Connector is not locked properly.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver is authorized by the Charging Station and/or CSMS.
+2. The lock Connector attempt fails.
+3. A NotifyEventRequest for the ConnectorPlugRetentionLock component, variable = Problem, value = true.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Cable plugged in (status = Occupied)
+Charging Station has the ConnectorPlugRetentionLock component defined in its Device Model.
+MonitoringLevel is set to a level that a connector lock event failure will be reported.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Transaction is not started and connector lock event failure is reported.</td></tr></table>
+
+
+Figure 77. Sequence Diagram: Lock Failure
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>It is advisable to provide some sort of notification to the EV Driver ("cable cannot be locked").</td></tr></table>
+
+# G05 - Lock Failure - Requirements
+
+Table 145. G05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>G05.FR.01</td><td>If the locking of the connector retention lock fails.</td><td>The Charging Station SHALL NOT start charging.</td><td></td></tr><tr><td>G05.FR.02</td><td>G05.FR.01</td><td>The Charging Station SHALL send a NotifyEventRequest to the CSMS for the ConnectorPlugRetentionLock component with variable = Problem, Value = True.</td><td></td></tr><tr><td>G05.FR.03</td><td>G05.FR.02</td><td>The CSMS SHALL respond with a NotifyEventResponse.</td><td></td></tr><tr><td>G05.FR.04</td><td>G05.FR.01</td><td>The Charging Station MAY show an optional notification to the EV Driver.</td><td>To notify the EV driver of the lock failure.</td></tr></table>
+
+# H. Reservation
+
+# 1. Introduction
+
+This Functional Block describes the reservation functionality of OCPP. The reservation functionality enables an EV Driver to make a reservation of a Charging Station/EVSE, ensuring an available Connector at a Charging Station when he arrives.
+
+With Charging Stations not being abundantly available, and EVs having limited range, EV Drivers plan their trips from Charging Station to Charging Station. They need to know for sure they can use a Charging Station they plan to go to. They don't like it when another EV Driver has started using the Charging Station in the time they were traveling to the Charging Station.
+
+For the EV Driver it is useful to be able to reserve a specific Type of Connector, or, when the EV Driver has no preference, an unspecified EVSE at a Charging Station. So he knows for sure he can charge at the Charging Station when he arrives.
+
+# 2. Use cases & Requirements
+
+# H01 - Reservation
+
+Table 146. H01 - Reservation
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reservation</td></tr><tr><td>2</td><td>ID</td><td>H01</td></tr><tr><td></td><td>Functional block</td><td>H. Reservation</td></tr><tr><td>3</td><td>Objective(s)</td><td>To ensure the EV Driver can charge his EV at a Charging Station, the EV Driver can make a reservation until a certain expiry time.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a Charging Station can be reserved for a specific IdTokenType.</td></tr><tr><td>5</td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td>S1</td><td>Scenario objective</td><td>Reserve an unspecified EVSE at a Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver asks the CSMS to reserve an unspecified EVSE at the Charging Station.
+2. The CSMS sends ReserveNowRequest without evseld to a Charging Station.
+3. Upon receipt of ReserveNowRequest, the Charging Station responds with ReserveNowResponse with status Accepted.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>The Charging Station has at least one available EVSE</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station has accepted the ReserveNowRequest
+Failure postcondition:
+The Charging Station has rejected the ReserveNowRequest</td></tr></table>
+
+
+Figure 78. Sequence Diagram: S1 - Reserve a unspecified EVSE at a Charging Station
+
+<table><tr><td>S2</td><td>Scenario objective</td><td>Reserve a specific EVSE at a Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>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.</td></tr><tr><td></td><td>Alternative scenario description</td><td>Steps 1, 2 and 3 as above.
+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 evseconnectorId, 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".</td></tr><tr><td></td><td>Prerequisite(s)</td><td>The specified EVSE of the Charging Station has status Available</td></tr><tr><td></td><td>Postcondition(s)</td><td>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.</td></tr></table>
+
+
+Figure 79. Sequence Diagram: S2 - Reserve a specified EVSE at a Charging Station
+
+<table><tr><td>S3</td><td>Scenario objective</td><td>Reserve a connector type at a Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver asks the CSMS to reserve a connector type at the Charging Station.
+2. The CSMS sends ReserveNowRequest with a connector type to a Charging Station.
+3. Upon receipt of ReserveNowRequest, the Charging Station responds with ReserveNowResponse with status Accepted.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>The Charging Station has at least one available EVSE with the specified connector type</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station has accepted the ReserveNowRequest
+Failure postcondition:
+The Charging Station has rejected the ReserveNowRequest</td></tr></table>
+
+
+Figure 80. Sequence Diagram: S3 - Reserve a connector type at a Charging Station
+
+<table><tr><td>6</td><td>Error handling</td><td></td></tr><tr><td>7</td><td>Remark(s)</td><td>It is RECOMMENDED to validate the Identifier with anauthorizeRequest after reception of ReserveNowRequest and before the start of the transaction.</td></tr></table>
+
+# H01 - Reservation - Requirements
+
+Table 147. H01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>H01.FR.01</td><td>If the Charging Station is configured not to accept reservations.</td><td>The Charging Station SHALL return Rejected.</td><td></td></tr><tr><td>H01.FR.02</td><td>If the id in the ReserveNowRequest matches a reservation in the Charging Station.</td><td>The Charging Station SHALL replace that reservation with the new reservation in the request.</td><td></td></tr><tr><td>H01.FR.03</td><td>If the id in the ReserveNowRequest does not match any reservation in the Charging Station.</td><td>The Charging Station SHALL return the status value Accepted if it succeeds in reserving an EVSE.</td><td></td></tr><tr><td>H01.FR.04</td><td>If the Charging Station receives a ReserveNowRequest without evseld AND at least one EVSE is Available AND H01.FR.18</td><td>The Charging Station SHALL accept the reservation AND respond with a ReserveNowResponse with status Accepted.</td><td></td></tr><tr><td>H01.FR.06</td><td>If the Charging Station receives a ReserveNowRequest with a connector type AND at least one EVSE with the specified connector type is Available AND H01.FR.18</td><td>The Charging Station SHALL accept the reservation AND respond with a ReserveNowResponse with status Accepted.</td><td></td></tr><tr><td>H01.FR.07</td><td>When the Charging Station has Accepted a ReserveNowRequest without evseld</td><td>The Charging Station SHALL make sure that at any time during the validity of the reservation, one EVSE remains available for the reserved IdTokenType.</td><td></td></tr><tr><td>H01.FR.09</td><td>When the Charging Station has Accepted a ReserveNowRequest with a connector type</td><td>The Charging Station SHALL make sure that at any time during the validity of the reservation, one Connector with the specified type remains available for the reserved IdTokenType.</td><td></td></tr><tr><td>H01.FR.11</td><td>When receiving a ReserveNowRequest AND (all) targeted EVSEs have status Reserved or Occupied</td><td>The Charging Station SHALL return Occupied.</td><td></td></tr><tr><td>H01.FR.12</td><td>When receiving a ReserveNowRequest AND (all) targeted EVSEs have status Faulted</td><td>The Charging Station SHALL return Faulted.</td><td></td></tr><tr><td>H01.FR.14</td><td>When receiving a ReserveNowRequest AND (all) targeted EVSEs have status Unavailable</td><td>The Charging Station SHALL return Unavailable.</td><td></td></tr><tr><td>H01.FR.15</td><td>If a transaction for the reserved IdTokenType is started.</td><td>The Charging Station SHALL send the reservationId in a TransactionRequest.</td><td>To notify the CSMS that the reservation is terminated. See E. Transactions.</td></tr><tr><td>H01.FR.16</td><td>When the status of a targeted EVSE changes to Faulted</td><td>The Charging Stations SHALL cancel the reservation AND send a ReservationStatusUpdate with status Removed.</td><td></td></tr><tr><td>H01.FR.17</td><td>When the status of a targeted EVSE changes to Unavailable</td><td>The Charging Stations SHALL cancel the reservation AND send a ReservationStatusUpdate with status Removed.</td><td></td></tr><tr><td>H01.FR.18</td><td>If the Configuration Variable: ReservationNonEvseSpecific is set to true.</td><td>The Charging Station SHALL accept reservations on an unspecified EVSE.</td><td></td></tr><tr><td>H01.FR.19</td><td>If the Configuration Variable: ReservationNonEvseSpecific is not set or set to false.</td><td>The Charging Station SHALL reject reservations on an unspecified EVSE.</td><td></td></tr><tr><td>H01.FR.20</td><td>H01.FR.04 AND amount of EVSEs available equals the amount of reservations</td><td>The Charging Station SHALL send for all connectors of the EVSE: - a StatusNotificationRequest with connectorStatus = Reserved, OR - a NotifyEventRequest with component = "Connector", variable = "AvailabilityState", trigger = "Delta", actualValue = "Reserved"</td><td>If an EVSE is reserved, all of its connectors are reported as reserved.</td></tr><tr><td>H01.FR.23</td><td>If the Charging Station receives a ReserveNowRequest for evseld AND this EVSE is Available</td><td>The Charging Station SHALL respond with a ReserveNowResponse with status Accepted AND SHALL send for all connectors of the EVSE: - a StatusNotificationRequest with connectorStatus = Reserved, OR - a NotifyEventRequest with component = "Connector", variable = "AvailabilityState", trigger = "Delta", actualValue = "Reserved"</td><td>If an EVSE is reserved, all of its connectors are reported as reserved.</td></tr><tr><td>H01.FR.24</td><td>H01.FR.06 AND amount of reservations for a specific connectorType equals the amount of available EVSEs with that specific connectorType</td><td>The Charging Station SHALL send for all connectors of the EVSEs that have the specific connectorType - a StatusNotificationRequest with connectorStatus = Reserved, OR - a NotifyEventRequest with component = "Connector", variable = "AvailabilityState", trigger = "Delta", actualValue = "Reserved"</td><td>If an EVSE is reserved for a specific connectorType, all connectors on the EVSE are reported as reserved.</td></tr></table>
+
+# H02 - Cancel Reservation
+
+Table 148. H02 - Cancel Reservation
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Cancel Reservation</td></tr><tr><td>2</td><td>ID</td><td>H02</td></tr><tr><td></td><td>Functional block</td><td>H. Reservation</td></tr><tr><td>3</td><td>Objective(s)</td><td>To cancel a reservation on a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how an EV Driver can cancel an existing reservation. The CSMS can cancel the reservation the EV Driver has on a Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver asks the CSMS to cancel a reservation.
+2. To cancel a reservation the CSMS sends CancelReservationRequest to the Charging Station.
+3. If the Charging Station has a reservation matching the reservationId in the request PDU, it returns the status Accepted.
+4. If a specific EVSE was reserved for this reservation, the Charging Station sends StatusNotificationRequest with the status Available for all the Connectors of that EVSE.
+5. The CSMS responds with StatusNotificationResponse to the Charging Station.
+6. The reservation is cancelled.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>- The Functional Block Reservation is installed.
+- EV Driver has a reservation at the Charging Station.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The CSMS was able to cancel the EV Driver's reservation at the Charging Stations.
+Failure postcondition:
+n/a.</td></tr></table>
+
+
+Figure 81. Sequence Diagram: Cancel Reservation
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The Charging Station does not send a ReservationStatusUpdate, because it was explicitly cancelled by CSMS, so it is already aware of the event.</td></tr></table>
+
+# H02 - Cancel Reservation - Requirements
+
+Table 149. H02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>H02.FR.01</td><td>The Charging Station has received a CancelReservationRequest and no matching reservationId.</td><td>The Charging Station SHALL return Rejected.</td></tr></table>
+
+H03 - Use a reserved EVSE
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>H02.FR.02</td><td>If a Charging Station receives a CancelReservationRequest with a valid, known reservationId.</td><td>The reservation SHALL be cancelled.</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Use a reserved EVSE</td></tr><tr><td>2</td><td>ID</td><td>H03</td></tr><tr><td></td><td>Functional block</td><td>H. Reservation</td></tr><tr><td>3</td><td>Objective(s)</td><td>Use a reserved EVSE</td></tr><tr><td>4</td><td>Description</td><td>This use cases covers how a reserved EVSE can be used based on IdToken and GroupIdToken information.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td>S1</td><td>Scenario objective</td><td>Use an EVSE reserved by the same IdToken</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a ReserveNowRequest to a Charging Station to reserve an EVSE for use by a specific IdTokenType.
+2. Upon receipt of the ReserveNowRequest, the Charging Station responds with a ReserveNowResponse.
+3. When a specific EVSE is reserved for this reservation, the Charging Station sends a StatusNotificationRequest with the status Reserved for all the Connectors of that EVSE.
+4. The CSMS responds with a StatusNotificationResponse to the Charging Station.
+5. The EV Driver presents an IdTokenType at the Charging Station, and the IdTokenType is the same as the reservation's IdTokenType, the Charging Station recognizes the IdTokenType and starts charging and E02 - Start Transaction - Cable Plugin First applies.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr></table>
+
+
+Figure 82. Sequence Diagram: Use a reserved EVSE with IdToken
+
+<table><tr><td>S2</td><td>Scenario objective</td><td>Use an EVSE reserved by the same GroupIdToken</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a ReserveNowRequest with the Groupld to a Charging Station to reserve a EVSE for use by a specific IdTokenType.
+2. Upon receipt of the ReserveNowRequest, the Charging Station responds with a ReserveNowResponse.
+3. When a specific EVSE is reserved for this reservation, the Charging Station sends a StatusNotificationRequest with the status Reserved for all the Connectors of that EVSE.
+4. The CSMS responds with a StatusNotificationResponse to the Charging Station.
+5. The EV Driver presents an IdTokenType at the Charging Station, and the IdTokenType is different from the reservation's IdTokenType, the Charging Station sends an InvalidateRequest to the CSMS.
+6. The CSMS responds with an InvalidateResponse. This response message includes the Groupld.
+7. Based on the matching Groupld information in both responses, the Charging Station starts charging and E02 - Start Transaction - Cable Plugin First applies.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr></table>
+
+
+Figure 83. Sequence Diagram: Use a reserved EVSE with GroupId
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>It is RECOMMENDED to validate the Identifier with anauthorizeRequest after reception of ReserveNowRequest and before the start of the transaction.</td></tr></table>
+
+# H03 - Use a reserved EVSE - Requirements
+
+Table 150. H03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>H03.FR.01</td><td>Reservation is pending for a specific idToken for a specific evseld</td><td>The Charging Station SHALL allow charging on that EVSE when IdToken presented for authorization matches the specific idToken from the reservation.</td></tr><tr><td>H03.FR.02</td><td>Reservation is pending for a specific idToken for a specific connectorType</td><td>The Charging Station SHALL allow charging on an EVSE with a connector of type connectorType when IdToken presented for authorization matches the specific idToken from the reservation.</td></tr><tr><td>H03.FR.03</td><td>Reservation is pending for a specific idToken without a specific evseld or connectorType</td><td>The Charging Station SHALL allow charging on an EVSE when IdToken presented for authorization matches the specific idToken from the reservation.</td></tr><tr><td>H03.FR.04</td><td>H03.FR.01 AND attribute groupldToken in reservation has a value</td><td>The Charging Station SHALL allow charging on that EVSE when IdToken presented for authorization matches the specific idToken from the reservation or when the associated groupldToken matches.</td></tr><tr><td>H03.FR.05</td><td>H03.FR.02 AND attribute groupldToken in reservation has a value</td><td>The Charging Station SHALL allow charging on an EVSE with a connector of type connectorType when IdToken presented for authorization matches the specific idToken from the reservation or when the associated groupldToken matches.</td></tr><tr><td>H03.FR.06</td><td>H03.FR.03 AND attribute groupldToken in reservation has a value</td><td>The Charging Station SHALL allow charging on any EVSE when IdToken presented for authorization matches the specific idToken from the reservation or when the associated groupldToken matches.</td></tr><tr><td>H03.FR.07</td><td>If attribute groupldToken in the reservation has a value (it is optional).</td><td>In order to determine the groupldToken that is associated with an incoming IdToken, the Charging Station MAY look it up in its Local Authorization List or Authorization Cache.</td></tr><tr><td>H03.FR.08</td><td>H03.FR.07 AND If the incoming IdToken is not found in the Local Authorization List or Authorization Cache.</td><td>The Charging Station SHALL send an AuthorizedRequest for the incoming IdToken to the CSMS in order to get its associated groupldToken. (Note: This AuthorizedRequest may already have been performed when the idToken was presented for authorization.)</td></tr><tr><td>H03.FR.09</td><td>When an idToken or groupldToken is presented that matches a reservation</td><td>Charging Station SHALL consider the reservation to be used (consumed)</td></tr><tr><td>H03.FR.10</td><td>H03.FR.09 AND Connector associated with reservation has status Reserved</td><td>Charging Station SHALL set connector status to Available if no cable has been plugged-in, or Occupied if a cable has already been plugged-in.</td></tr></table>
+
+H04 - Reservation Ended, not used
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reservation Ended, not used</td></tr><tr><td>2</td><td>ID</td><td>H04</td></tr><tr><td></td><td>Functional block</td><td>H. Reservation</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable a Charging Station to notify the CSMS about a reservation that has expired.</td></tr><tr><td>4</td><td>Description</td><td>This use cases covers how the Charging Station notifies the CSMS about a reservation, that has ended/timed out before the EV Driver starts using the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station has a reservation.
+2. The expiryDate of the reservation is reached.
+3. The Charging Station removes the reservation.
+4. If a specific EVSE was reserved for this reservation, the Charging Station makes the EVSE available again and notifies the CSMS about this by sending a StatusNotificationRequest with the status Available for that all the Connectors of that EVSE.
+5. The CSMS responds with a StatusNotificationResponse.
+6. The Charging Station sends a ReservationStatusUpdateRequest with status Expired to the CSMS.
+7. The CSMS responds with a ReservationStatusUpdateResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr></table>
+
+
+Figure 84. Sequence Diagram: Reservation Ended, not used
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# H04 - Reservation Ended, not used - Requirements
+
+Table 151. H04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>H04.FR.01</td><td>The reservation ends (expirationDateTime reached)</td><td>The Charging Station SHALL send a ReservationStatusUpdateRequest with status Expired.</td></tr><tr><td>H04.FR.02</td><td>H04.FR.01 AND If a specific EVSE was reserved for this reservation</td><td>The Charging Station SHALL allow charging again on this EVSE.</td></tr><tr><td>H04.FR.03</td><td>H04.FR.02</td><td>The Charging Station SHALL send a StatusNotificationRequest with status Available to the CSMS, notifying the CSMS the all the connectors of this EVSE are available again for any EV Driver.</td></tr></table>
+
+# I. TariffAndCost
+
+# 1. Introduction
+
+This Functional Block provides tariff and cost information to an EV Driver, when a Charging Station is capable of showing this on a display.
+
+Before a driver starts charging he needs to be given tariff information, given detailed prices for all the components that make up the tariff plan applicable to this driver at this Charging Station. As this is a human readable text message, it can also be used for other things, like a personal welcome message.
+
+Some business cases might require the EV Driver to be shown the running total cost during charging, updated at a regular, fitting interval. When the EV Driver stops charging, he needs to be shown to the total cost of the just stopped transaction.
+
+All tariffs and costs are in the currency configured in the Configuration Variable Currency.
+
+# 1.1. Why no structured tariff information?
+
+Because tariff structures can become very complex it will be difficult to convert these to human-readable text in the Charging Station. The CSO is the owner of the tariffs and should be able to provide the Charging Station with a human-readable tariff text. If the CSO is not able to generate human-readable texts from its own tariffs, how can a Charging Station be expected to be able to this. That is why we have kept the complexity of tariffs out of OCPP.
+
+# 2. Use cases & Requirements
+
+# I01 - Show EV Driver-specific Tariff Information
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Show EV Driver-specific Tariff Information</td></tr><tr><td>2</td><td>ID</td><td>I01</td></tr><tr><td></td><td>Functional block</td><td>I. Tariff and Cost</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show an EV Driver-specific tariff before the start of a transaction.</td></tr><tr><td>4</td><td>Description</td><td>When an EV Driver wants to charge an EV he wants to know how much charging will cost him at the Charging Station he is at. The EV Driver is authenticated by his (RFID) token. The Charging Station asks the CSMS for information about the presented token. The CSMS returns information about the token, including the tariff applicable to this EV Driver.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver wants to charge an EV, he presents his IdTokenType.
+2. The Charging Station sends AuthorizationRequest to the CSMS to request authorization.
+3. Upon receipt of AuthorizationRequest, the CSMS responds with AuthorizationResponse. This response message indicates whether or not the IdTokenType is accepted by the CSMS, and reports the EV Driver-specific tariff in the personalMessage field.
+4. The Charging Station shows the EV Driver-specific tariff to the EV Driver.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>I04 - Show Failback Tariff Information</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station supports Tariff Information</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The EV Driver is authorized, knows which tariff is applicable for him/her and can start charging.
+Failure postcondition:
+If the authorization status is other than Accepted, the EV Driver can not start and might not know the tariff.</td></tr></table>
+
+
+Figure 85. Sequence Diagram: Show EV Driver-specific tariff information
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The tariff information presented this way might be equal to any token presented.
+If known, and applicable, it is advisable to show the tariff information in a language understood by the EV Driver.
+It is advisable to give the driver the option to cancel the transaction when he does not agree with the tariff. This could be not plugging in the cable, or a cancel button in the user interface etc. As long at it is clear to the driver how a transaction can be canceled.</td></tr></table>
+
+# I01 - Show EV Driver-specific Tariff Information - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I01.FR.01</td><td></td><td>The CSMS MAY send EV Driver-specific tariff information in the PersonalMessage field of an ActivateResponse message.</td></tr><tr><td>I01.FR.02</td><td></td><td>The CSMS SHALL only send the tariff information if the Charging Station supports the tariff or DisplayMessage functionality.</td></tr><tr><td>I01.FR.03</td><td>I01.FR.01</td><td>The Charging Station SHALL show the EV Driver-specific tariff information to the EV Driver.</td></tr></table>
+
+# 102 - Show EV Driver Running Total Cost During Charging
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Show EV Driver Running Total Cost During Charging</td></tr><tr><td>2</td><td>ID</td><td>I02</td></tr><tr><td></td><td>Functional block</td><td>I. Tariff and Cost</td></tr><tr><td>3</td><td>Objectives</td><td>To show an EV Driver the running total cost during charging</td></tr><tr><td>4</td><td>Description</td><td>While a transaction is ongoing, the driver wants to know how much the running total cost is, updated at a relevant interval.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. Every Y seconds the CSMS sends a CostUpdatedRequest to the Charging Station to update the current total cost.
+2. Upon receipt of the CostUpdatedRequest, the Charging Station responds with a CostUpdatedResponse.
+3. The Charging Station shows the current total cost to the EV Driver.</td></tr><tr><td></td><td>Alternative scenario</td><td>1. Upon receipt of a TransactionEventRequest with eventType = Updated the CSMS returns the running cost corresponding to the timestamp and meterValue in the field totalCost in the TransactionEventResponse.
+2. The Charging Station shows the current total cost to the EV Driver.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station supports Tariff Information Ongoing transaction</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The EV Driver knows the running total cost during charging.
+Failure postcondition:
+Total cost not known to the EV Driver during charging.</td></tr></table>
+
+
+Figure 86. Sequence Diagram: Show EV Driver Running Total Cost During Charging
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>Updating the running cost very often will create a lot of messages, which might result in high mobile data cost.</td></tr></table>
+
+# I02 - Show EV Driver Running Total Cost During Charging - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I02.FR.01</td><td></td><td>The CSMS SHALL send either a CostUpdatedRequest at a relevant interval/moment or return the running cost in a TransactionEventResponse. This might depend on the charging speed, running cost, etc.</td></tr><tr><td>I02.FR.02</td><td>Upon receipt of a CostUpdatedRequest message.</td><td>The Charging Station SHALL respond with a CostUpdatedResponse message.</td></tr><tr><td>I02.FR.03</td><td>I02.FR.02</td><td>The Charging Station SHALL show the current total cost to the EV Driver.</td></tr><tr><td>I02.FR.04</td><td>When running cost is reported in TransactionEventResponse</td><td>The Charging Station SHALL show the current running cost to the EV Driver.</td></tr></table>
+
+# 103 - Show EV Driver Final Total Cost After Charging
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Show EV Driver Final Total Cost After Charging</td></tr><tr><td>2</td><td>ID</td><td>I03</td></tr><tr><td></td><td>Functional block</td><td>I. Tariff and Cost</td></tr><tr><td>3</td><td>Objectives</td><td>To show an EV Driver the total cost after the transaction is finished.</td></tr><tr><td>4</td><td>Description</td><td>An EV Driver stops an ongoing transaction by presenting his identification token (for example RFID). The transaction is stopped and the total cost of the transaction is shown to the EV Driver.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver presents an IdTokenType to stop the transaction.
+2. The Charging Station sends TransactionEventRequest (eventType = Ended)
+3. The CSMS responds with TransactionEventResponse containing the total cost of the transaction.
+4. The Charging Station shows the total cost to the EV Driver.</td></tr><tr><td></td><td>Alternative scenario's</td><td>I05 - Show Failback Total Cost Message</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station supports Tariff Information Ongoing transaction</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The EV Driver knows the total cost of the transaction.
+Failure postcondition:
+The EV Driver does NOT know the total cost of the transaction.</td></tr></table>
+
+
+Figure 87. Sequence Diagram: Show EV Driver Final Total Cost After Charging
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>If the Charging Station was offline when the transaction ended and the TransactionEventResponse with totalCost is received when the Charging Station comes back online some time after that, then there is no use in displaying the cost, because the user has likely left already. A similar situation applies when TxStopPoint is defined as ParkingBayOccupancy, in which case the EV must leave the Charging Station to cause the transaction to end.
+The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.
+TxStopPoint: ParkingBayOccupancy, EVConnected, Authorized
+This use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are send. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+# I03 - Show EV Driver Final Total Cost After Charging - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I03.FR.01</td><td>When transaction is stopped</td><td>The Charging Station SHALL send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>I03.FR.02</td><td>I03.FR.01 AND When Total Cost is known to the CSMS.</td><td>The CSMS SHALL send the total cost of the transaction in the totalCost field of the TransactionResponse message.</td></tr><tr><td>I03.FR.03</td><td>I03.FR.02 AND Charging Station was online when transaction stopped</td><td>The Charging Station SHALL display the total cost to the EV Driver.</td></tr><tr><td>I03.FR.04</td><td></td><td>To indicate a free transaction, the CSMS SHALL set totalCost to 0.00. Thus omitting totalCost does not imply that the transaction was free.</td></tr><tr><td>I03.FR.05</td><td>I02.FR.02 AND TxStopPoint is defined as ParkingBayOccupancy</td><td>The Charging Station SHOULD NOT display the total cost to the EV Driver. (Driver has left already).</td></tr></table>
+
+# 104 - Show Fallback Tariff Information
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Show Failback Tariff Information</td></tr><tr><td>2</td><td>ID</td><td>I04</td></tr><tr><td></td><td>Functional block</td><td>I. Tariff and Cost</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show an EV Driver some information, generic tariff, a message etc., when the Charging Station cannot retrieve tariff information for this EV Driver.</td></tr><tr><td>4</td><td>Description</td><td>When an EV Driver wants to charge an EV, he wants an indication of how much charging will cost him at the Charging Station he is at, but the Charging Station cannot get a specific tariff for this EV Driver (for example: the Charging Station is Offline, or no EV Driver-specific tariff is available). For such scenarios, a fallback tariff information message can be configured in the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver wants to charge an EV, he presents his IdTokenType.
+2. The Charging Station authorizes the EV Driver against the Authorization Cache
+3. The Charging Station shows the TariffFallbackMessage to the EV Driver.</td></tr><tr><td></td><td>Alternative scenario's</td><td>I01 - Show EV Driver-specific Tariff Information</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station supports Tariff Information
+the Configuration Variable: TariffFallbackMessage is configured.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+EV Driver has been shown the fallback tariff information message
+Failure postcondition:
+EV Driver has no information about the tariff at this Charging Station.</td></tr></table>
+
+
+Figure 88. Sequence Diagram: Show Back Tariff Information
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>n/a</td></tr></table>
+
+# 104 - Show Fallback Tariff Information - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I04.FR.01</td><td>When the Charging Station cannot get a specific tariff for the EV Driver (for example: the Charging Station is Offline, or no EV Driver-specific tariff is available.)</td><td>The Charging Station SHALL display a fallback tariff information message to the EV Driver, which is configured in the Configuration Variable: TariffFallbackMessage.</td></tr><tr><td>I04.FR.02</td><td></td><td>The CSMS MAY configure the TariffFallbackMessage via the Configuration Variable: TariffFallbackMessage.</td></tr></table>
+
+I05 - Show Fallback Total Cost Message
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Show Failback Total Cost Message</td></tr><tr><td>2</td><td>ID</td><td>I05</td></tr><tr><td></td><td>Functional block</td><td>I. Tariff and Cost</td></tr><tr><td>3</td><td>Objectives</td><td>To show an EV Driver a message instead of the actual total cost when the Charging Station is Offline when a transaction is stopped.</td></tr><tr><td>4</td><td>Description</td><td>When an EV Driver wants to stop an ongoing transaction, but the Charging Station is Offline. The transaction will be stopped as described earlier. The Charging Station cannot retrieve the total cost for the stopped transaction. The EV Driver needs to be given some message, this message can be configured in the Configuration Variable: TotalCostFallbackMessage.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver presents IdTokenType to stop the transaction.
+2. The Charging Station stops the energy offer.
+3. The Charging Station shows the TotalCostFallbackMessage to the EV Driver.</td></tr><tr><td></td><td>Alternative scenario's</td><td>I03 - Show EV Driver Final Total Cost After Charging</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station supports Tariff Information
+The Charging Station is Offline
+the Configuration Variable: TotalCostFallbackMessage is configured.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The EV Driver has received a pre-configured fallback message.
+Failure postcondition:
+The EV Driver has not received a pre-configured fallback message.</td></tr></table>
+
+
+Figure 89. Sequence Diagram: Show Back Total Cost Message
+
+I05 - Show Fallback Total Cost Message - Requirements
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>n/a</td></tr></table>
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I05.FR.01</td><td></td><td>The CSMS MAY configure the fallback total cost information message via the Configuration Variable:
+TotalCostFallbackMessage.</td></tr><tr><td>I05.FR.02</td><td>When the Charging Station cannot retrieve the total cost for the stopped transaction, because the Charging Station is offline.</td><td>The Charging Station SHALL show a fallback total cost information message to the EV Driver.</td></tr></table>
+
+# 106 - Update Tariff Information During Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Update Tariff Information During Transaction</td></tr><tr><td>2</td><td>ID</td><td>I06</td></tr><tr><td></td><td>Functional block</td><td>I. Tariff and Cost</td></tr><tr><td>3</td><td>Objectives</td><td>To show an EV Driver updated tariff information during a transaction.</td></tr><tr><td>4</td><td>Description</td><td>During charging (especially DC fast charging) it might be useful to show the EV driver updated tariff information when it becomes available.
+Example: If a tariff has a bandwidth:
+charging will cost between 0,25 and 0,40 euro/kWh depending on current energy price. Current price is 0,28 euro/kWh.
+Then when the price changing, this tariff information needs to be updated:
+charging will cost between 0,25 and 0,40 euro/kWh depending on current energy price. Current price is 0,32 euro/kWh.</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends TransactionRequest (eventType = Updated) messages during the transaction.
+2. When the CSMS receives a TransactionRequest message it checks if there is updated tariff information available.
+3. The CSMS acknowledges with a TransactionResponse message, which contains the updated tariff information if available.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station supports Tariff Information
+There is a transaction ongoing</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The updated tariff information is shown to the EV Driver.
+Failure postcondition:
+The EV Driver has not been shown the updated tariff information.</td></tr></table>
+
+
+Figure 90. Sequence Diagram: Update Tariff Information During Transaction
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>There may be a policy or a legal requirement in place, that the tariff communicated at the start of the transaction must be used for the entire transaction, in which case no updated tariff information should be sent during the transaction.</td></tr></table>
+
+# I06 - Update Tariff Information During Transaction - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I06.FR.01</td><td>When the CSMS receives a TransactionRequest (eventType = Updated) from the Charging Station.</td><td>The CSMS SHALL check if there is updated tariff information available.</td></tr><tr><td>I06.FR.02</td><td>I06.FR.01 AND When there is updated tariff information available.</td><td>The CSMS SHALL respond with a TransactionResponse message to the Charging Station, containing the updated tariff information in the PersonalMessage field.</td></tr><tr><td>I06.FR.03</td><td>I06.FR.02</td><td>The Charging Station SHALL display the updated tariff information to the EV Driver.</td></tr></table>
+
+# J. MeterValues
+
+# 1. Introduction
+
+This Functional Block describes the functionality that enables a Charging Station to send periodic, possibly clock-aligned MeterValues.
+
+The transfer of the MeterValues from the Charging Station to the CSMS will be taken over by the new Device Management Monitoring feature, however this mechanism has not been proven in the field yet. So the old MeterValuesRequest message remains available for use for now.
+
+Extensive metering data relating to transactions can be recorded and transmitted in different ways depending on its intended purpose. There are two obvious use cases (but the use of meter values is not limited to these two):
+
+Transaction Meter Values
+
+- Clock-Aligned Meter Values
+
+Both types of meter readings MAY be reported in the meterValue element of the TransactionEventRequest message. Clock-Aligned Meter Values MAY be reported in standalone MeterValuesRequest messages.
+
+# 2. Configuration
+
+This section is normative.
+
+# 2.1. Transaction Meter Values
+
+Frequent (e.g. 1-5 minute interval) meter readings taken and transmitted (usually in "real time") to the CSMS, to allow it to provide information updates to the EV user (who is usually not at the Charging Station), via web, app, SMS, etc., as to the progress of the transaction. In OCPP, this is called "sampled meter data", as the exact frequency and time of readings is not very significant, as long as it is "frequent enough". "Sampled meter data" can be configured with the following Configuration Variables:
+
+- SampledDataTxStartedMeasurands
+- SampledDataTxUpdatedMeasures
+- SampledDataTxUpdatedInterval
+- SampledDataTxEndedMeasurands
+- SampledDataTxEndInterval
+
+SampledDataTxUpdatedInterval is the time (in seconds) between sampling of metering (or other) data, intended to be transmitted by TransactionEventRequest (eventType = Updated) messages during a transaction. A value of "0" (numeric zero), by convention, is to be interpreted to mean that no sampled data should be transmitted.
+
+SampledDataTxEndInterval is the time (in seconds) between sampling of metering (or other) data, intended to be transmitted in the TransactionRequest (eventType = Ended) message.
+
+SampledDataTxStartedMeasurands is a comma separated list that prescribes the set of measurands to be included in the meterValues field of a TransactionEventRequest (eventType = Started).
+
+SampledDataTxUpdatedMeasurands is a comma separated list that prescribes the set of measurands to be included in the meterValues field of a TransactionEventRequest (eventType = Updated), every SampledDataTxUpdatedInterval seconds.
+
+SampledDataTxEndMeasuredurands is a comma separated list that prescribes the sampled measurands to be included in the meterValues field of a TransactionRequest (eventType = Ended), these measurands have to be taken every SampledDataTxEndInterval seconds from the start of the transaction, and will only be sent in the TransactionRequest (eventType = Ended).
+
+Care should be taken to ensure that the amount of measurands that is expected at the end of a transaction fits in one TransactionRequest(eventType=Ended) message. Keep the number of measurands in SampledDataTxEndeMeasurands to a minimum and configure a large interval in SampledDataTxEndeInterval to keep the number of samples small.
+
+NOTE Please note: Transaction related MeterValues are never transmitted in MeterValuesRequest.
+
+# 2.2. Clock-Aligned Meter Values
+
+Grid Operator might require meter readings to be taken from fiscally certified energy meters, at specific Clock aligned times (usually every quarter hour, or half hour).
+
+"Clock-Aligned Meter Values" can be configured with the following Configuration Variables:
+
+- AlignedDataMeasurands
+- AlignedDataInterval
+- AlignedDataTxEndedMeasurands
+- AlignedDataTxEndInterval
+- AlignedDataSendDuringIdle
+
+AlignedDataInterval is the size of the clock-aligned data interval (in seconds). This defines the set of evenly spaced meter data aggregation intervals per day, starting at 00:00:00 (midnight), at which time the Charging Station should take measurements and send them to the CSMS in a MeterValuesRequest message. A value of "0" (numeric zero), by convention, is to be interpreted to mean that no clock-aligned data should be transmitted.
+
+AlignedDataTxEndPeriod is the size of the clock-aligned data interval (in seconds). This defines the set of evenly spaced
+
+meter data aggregation intervals per day, starting at 00:00:00 (midnight) intended to be transmitted in the TransactionRequest (eventType = Ended) message.
+
+For example, a value of 900 (15 minutes) indicates that every day should be broken into 96 15-minute intervals, starting at 0:00 and then measured every 15 minutes: 0:15, 0:30, 0:45, 1:00, 1:15 etc.
+
+AlignedDataMeasurands is a comma separated list that prescribes the set of measurands to be included in a MeterValuesRequest PDU, every AlignedDataInterval seconds.
+
+AlignedDataTxEndMeasuredurands is a comma separated list that prescribes the set of clock-aligned periodic measurands to be included in the meterValue elements of TransactionRequest (eventType = Ended) PDU for every AlignedDataTxEndInterval of the transaction.
+
+AlignedDataSendDuringIdle can be used to only send clock aligned meter values when there are no ongoing transactions.
+
+# NOTE
+
+Clock-aligned meter values for an EVSE that is involved in a transaction MAY be transmitted in TransactionEventRequests with context = Sample.Clock instead of in MeterValuesRequests.
+
+# 2.3. Multiple Locations/Phases
+
+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.
+
+For example: A Charging Station capable of measuring Current.Import on Inlet (all 3 phases) (grid connection) and Outlet (3 phases per EVSE on both its EVSEs). Current.Import is set in AlignedDataMeasurands. AlignedDataInterval is set to 900 (seconds). Then the Charging Station should send: (every 15 minutes)
+
+- a MeterValuesRequest with: evseld = 0; with 3 SampledValue elements, one per phase with location = Inlet.
+- a MeterValuesRequest with: evseld = 1; with 3 SampledValue elements, one per phase with location = Outlet.
+- a MeterValuesRequest with: evseld = 2; with 3 SampledValue elements, one per phase with location = Outlet.
+
+# NOTE
+
+When the configuration variable SampledDataRegisterValuesWithoutPhases has the value true, then meter values of measurand Energy.Active.Importantly Register will only report the total energy over all phases without reporting the individual phase values.
+
+# 2.4. Signed Meter Values
+
+OCPP 2.0.1 supports signed meter values. When a Charging Station support signed meter values it can use the Configuration Variables AlignmentDataSignReadings and SampledDataSignReadings to report this. The CSMS can then use this same variables to turn the use of signed meter values on or off.
+
+When enabled the Charging Station shall put the signed meter value in the SignedMeterValue field of the SampledValue.
+
+# 2.5. Configuration Examples
+
+Below are a few examples of configurations for transaction-related measurands:
+
+# Only sampled energy register values for start/stop at end of transaction
+
+- SampledDataCtrl.TxStartedMeasurands and TxUpdatedMeasurands are left empty.
+- SampleDataCtrl.TxEndedMeasurands = "Energy.Active.Importantly.
+- SampledDataCtrl.TxEndInterval = 0
+
+# Values of energy register at start, during and end of transaction
+
+- SampledDataCtrlr.TxStartedMeasurands = "Energy.Active.Import.Register"
+- SampledDataCtrl.TxUpdatedMeasurands = "Energy.Active.Importantly/register"
+- SampledDataCtrl.TxUpdatedInterval = 300 (every 5 minutes)
+- SampledDataCtrl.TxEndedMeasurands = "Energy.Active.Import.Register"
+- SampledDataCtrl.TxEndInterval = 0
+
+# Only clock-aligned register values during and start/stop at end of transaction
+
+- SampleDataCtrl.TxStartedMeasurands and TxUpdatedMeasurands are left empty.
+- SampleDataCtrl.TxEndedMeasurands = "Energy.Active.Import.Register"
+- SampledDataCtrl.TxEndInterval = 0
+- AlignedDataCtrl.Measurands = "Energy.Active.Import.Register"
+- AlignedDataCtrlInterval = 300 (every 5 minutes)
+
+# 3. Use cases & Requirements
+
+# 3.1. MeterValues
+
+# J01 - Sending Meter Values not related to a transaction
+
+Table 152. J01 - Sending Meter Values not related to a transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Sending Meter Values not related to a transaction</td></tr><tr><td>2</td><td>ID</td><td>J01</td></tr><tr><td></td><td>Functional block</td><td>J. Meter Values</td></tr><tr><td>3</td><td>Objective(s)</td><td>To sample the electrical meter or other sensor/transducer hardware to provide information about the Charging Stations' Meter Values.</td></tr><tr><td>4</td><td>Description</td><td>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.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends a MeterValuesRequest message, for offloading Meter Values to the CSMS.
+2. Upon receipt of a MeterValuesRequest message, the CSMS responds with a MeterValuesResponse message.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station is configured to send Meter values every XX seconds.
+No transaction is running.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+n/a
+Failure postcondition:
+n/a</td></tr></table>
+
+
+
+Figure 91. Sequence Diagram: Sending Meter Values
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The phase field is not applicable to all Measurands.The phase rotation of a Connector relative to the grid connection can be derived by querying the PhaseRotation Configuration Variables of all components in the chain from grid connection up to Connector.The nature of each sampledValue is determined by the optional Measurand, context, location, unit and phase fields.The optional SignedMeterValue field can contain digitally signed binary meter value data.</td></tr></table>
+
+# J01 - Sending Meter Values not related to a transaction - Requirements
+
+Table 153. J01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>J01.FR.01</td><td></td><td>The Charging Station MAY sample the energy meter (or other sensor/transducer hardware) to provide extra information about its Meter Values.</td><td>It is up to the Charging Station when it will send Meter Values. This can be configured using the SetVariablesRequest message to data acquisition intervals and specify data to be acquired & reported.</td></tr><tr><td>J01.FR.02</td><td></td><td>The MeterValuesRequest message SHALL contain the id of the EVSE from which samples were taken.</td><td></td></tr><tr><td>J01.FR.03</td><td>J01.FR.02 AND The evseld is 0.</td><td>The MeterValuesRequest message SHALL be associated with the entire Charging Station.</td><td></td></tr><tr><td>J01.FR.04</td><td>J01.FR.03 AND Measurand is energy related.</td><td>The sample SHALL be taken from the main energy meter.</td><td></td></tr><tr><td>J01.FR.05</td><td>If all captured at the same point in time.</td><td>Each MeterValue element SHALL contain a timestamp.</td><td></td></tr><tr><td>J01.FR.06</td><td>If all captured at the same point in time.</td><td>Each MeterValue(s) element SHALL contain a set of one or more individual SampledValue elements.</td><td></td></tr><tr><td>J01.FR.07</td><td></td><td>The optional measurand field SHALL specify the type of value being measured/reported.</td><td></td></tr><tr><td>J01.FR.08</td><td></td><td>The optional context field SHALL specify the reason/event triggering the reading.</td><td></td></tr><tr><td>J01.FR.09</td><td></td><td>The optional location field SHALL specify where the measurement is taken.</td><td>(e.g. Inlet, Outlet).</td></tr><tr><td>J01.FR.10</td><td></td><td>The optional phase field SHALL specify to which phase or phases of the electric installation the value applies.</td><td></td></tr><tr><td>J01.FR.11</td><td></td><td>The Charging Station SHALL report all phase number dependent values from the electrical meter (or grid connection when absent) point of view.</td><td></td></tr><tr><td>J01.FR.13</td><td>When reporting phase rotation of a component</td><td>The Charging Station SHALL report the phase rotation relative to the grid connection</td><td></td></tr><tr><td>J01.FR.14</td><td>When AlignedDataCtrlInterval > 0 AND EVSE for which measurands are sent, is not involved in a transaction</td><td>The Charging Station SHALL send a MeterValuesRequest message to the CSMS for the measurands in AlignedDataCtrl.Measurands at every AlignedDataCtrlInterval for all evselds, locations and phases for which a configured measurand is supported.</td><td>It is possible that certain measurands are not available for every location. For example, evseld = 0 (grid meter) will not have a "Current.Offered" or "SoC" measurand. See also J01.FR.22</td></tr><tr><td>J01.FR.15</td><td>J01.FR.14 AND Amount of measurands is too much for 1 MeterValuesRequest</td><td>The Charging Station MAY use multiple MeterValuesRequest messages to send all measurands.</td><td></td></tr><tr><td>J01.FR.17</td><td></td><td>The timestamp of a MeterValue SHALL apply to all its SampledValues.</td><td></td></tr><tr><td>J01.FR.18</td><td>When CSMS receives a MeterValuesRequest</td><td>CSMS SHALL respond with MeterValuesResponse.</td><td>Failing to respond with MeterValuesResponse might cause the Charging Station to try the same message again.</td></tr><tr><td>J01.FR.19</td><td>If AlignedDataSendDuringIdle is set to true for an EVSE AND the specified EVSE has an ongoing transaction.</td><td>The Charging Station SHALL stop sending the clock aligned meter values for this EVSE.</td><td></td></tr><tr><td>J01.FR.20</td><td>If AlignedDataSendDuringIdle is set to true for a Charging Station AND the Charging Station has an ongoing transaction.</td><td>The Charging Station SHALL stop sending the clock aligned meter values for all EVSEs and the main power meter.</td><td></td></tr><tr><td>J01.FR.21</td><td>AlignedDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values from components that support data signing and put them in the signedMeterValue field.</td><td></td></tr><tr><td>J01.FR.22</td><td>When AlignedDataCtrlInterval > 0 AND EVSE for which measurands are sent, is involved in a transaction</td><td>The Charging Station SHALL send either: - a MeterValuesRequest message or - a TransactionEventRequest with triggerReason = Sample.Clock to the CSMS for the measurands in AlignedDataCtrl.Measurands at every AlignedDataCtrl.Interval.</td><td>See also J01.FR.14</td></tr></table>
+
+# J02 - Sending transaction related Meter Values
+
+Table 154. J02 - Sending transaction related Meter Values
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Sending transaction related Meter Values</td></tr><tr><td>2</td><td>ID</td><td>J02</td></tr><tr><td></td><td>Functional block</td><td>J. Meter Values</td></tr><tr><td>3</td><td>Objective(s)</td><td>To sample the energy meter or other sensor/transducer hardware to provide information about the Charging Stations' transaction related Meter Values.</td></tr><tr><td>4</td><td>Description</td><td>The Charging Station samples the energy meter or other sensor/transducer hardware to provide information about its transaction related Meter Values. Depending on configuration settings, the Charging Station will send Meter Values during a transaction.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends a TransactionRequest (eventType = Updated) message, for offloading Meter Values to the CSMS.
+2. Upon receipt of a TransactionRequest message, the CSMS responds with a TransactionResponse message.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station is configured to send Meter Values every XX seconds.
+A transaction is running.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+n/a
+Failure postcondition:
+n/a</td></tr></table>
+
+
+
+Figure 92. Sequence Diagram: Sending transaction related Meter Values
+
+<table><tr><td>7</td><td>Error handling</td><td>When Offline, the Charging Station MUST queue any transaction-related messages (Meter Values belonging to a transaction) that it would have sent to the CSMS if the Charging Station had been online.</td></tr><tr><td>8</td><td>Remark(s)</td><td>The phase field is not applicable to all Measurands.The phase rotation of a Connector relative to the grid connection can be derived by querying the PhaseRotation Configuration Variables of all components in the chain from grid connection up to Connector.The nature of each sampledValue is determined by the optional Measurand, context, location, unit and phase fields.The optional SignedMeterValue field can contain digitally signed binary meter value data.</td></tr></table>
+
+# J02 - Sending transaction related Meter Values - Requirements
+
+Table 155. J02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>J02.FR.01</td><td></td><td>The Charging Station MAY sample the energy meter (or other sensor/transducer hardware) to provide extra information about its Meter Values.</td><td>It is up to the Charging Station when it will send Meter Values. This can be configured using the SetVariablesRequest message to data acquisition intervals and specify data to be acquired & reported.</td></tr><tr><td>J02.FR.02</td><td>If all captured at the same point in time.</td><td>Each MeterValue element SHALL contain a set of one or more individual SampledValue elements.</td><td></td></tr><tr><td>J02.FR.03</td><td></td><td>The optional measurand field SHALL specify the type of value being measured/reported.</td><td></td></tr><tr><td>J02.FR.04</td><td></td><td>The optional context field SHALL specify the reason/event triggering the reading.</td><td></td></tr><tr><td>J02.FR.05</td><td></td><td>The optional location field SHALL specify where the measurement is taken.</td><td>(e.g. Inlet, Outlet).</td></tr><tr><td>J02.FR.06</td><td></td><td>The optional phase field SHALL specify to which phase or phases of the electric installation the value applies.</td><td></td></tr><tr><td>J02.FR.07</td><td></td><td>The Charging Station SHALL report all phase number dependent values from the power meter (or grid connection when absent) point of view.</td><td></td></tr><tr><td>J02.FR.09</td><td>When reporting phase rotation of a component</td><td>The Charging Station SHALL report the phase rotation relative to the grid connection.</td><td></td></tr><tr><td>J02.FR.10</td><td>If a TransactionEventRequest message with eventType = Started or eventType = Update contains multiple meterValue elements, rather than one meterValue with one or more sampledValue elements</td><td>All meterValue elements SHALL have a timestamp that is within the current sampling interval, i.e.: (transaction event timestamp - SampledDataTxUpdatedInterval) < meterValue.timestamp <= transaction event timestamp</td><td>Only for eventType = Ended can a TransactionEventRequest have meter values for multiple intervals.</td></tr><tr><td>J02.FR.11</td><td>When SampledDataTxUpdatedInterval > 0</td><td>The Charging Station SHALL send a TransactionEventRequest(eventType = Updated with triggerReason = MeterValuePeriodic with the measurands configured in SampledDataCtrl.TxUpdatedMeasurands in the meterValue field at every SampledDataCtrl.TxUpdatedInterval.</td><td>See E01 for sending of SampledDataCtrl.TxStartedMeasurands and E06 for SampledDataCtrl.TxEndMeasuredurands.</td></tr><tr><td>J02.FR.12</td><td>J02.FR.11 AND Offline AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop TransactionEventRequest(eventType = Updated) messages.</td><td></td></tr><tr><td>J02.FR.13</td><td>J02.FR.12</td><td>When dropping TransactionEventRequest (eventType = Updated) messages, the Charging Station SHALL drop intermediate messages first (1st message, 3th message, 5th message etc.), not start dropping messages from the start or stop adding messages to the queue.</td><td></td></tr><tr><td>J02.FR.14</td><td>J02.FR.11 AND Amount of meter data is too much for 1 TransactionEventRequest (eventType = Updated)</td><td>The Charging Station MAY use multiple TransactionEventRequest (eventType = Updated) messages with the same timestamp to send all measurands.</td><td></td></tr><tr><td>J02.FR.16</td><td></td><td>All "Register" values relating to a single charging transaction, or a non-transactional consumer (e.g. Charging Station internal power supply, overall supply) MUST be monotonically increasing in time.</td><td>Except in the case of a meter replacement. See MeasurandEnumType.</td></tr><tr><td>J02.FR.17</td><td></td><td>For improved auditability, ".Register" values SHOULD be reported exactly as they are directly read from a non-volatile register in the electrical metering hardware, and SHOULD NOT be re-based to zero at the start of transactions</td><td>This allows any "missing energy" between sequential transactions, due to hardware fault, meter replacement, wiring, fraud, etc. to be identified, by allowing the CSMS to confirm that the starting register value of any transaction is identical to the finishing register value of the preceding transaction on the same connector.</td></tr><tr><td>J02.FR.18</td><td></td><td>The timestamp of a MeterValue SHALL apply to all its SampledValues.</td><td></td></tr><tr><td>J02.FR.19</td><td>When CSMS receives a TransactionRequest</td><td>CSMS SHALL respond with TransactionResponse.</td><td>Failing to respond with TransactionEventRespon se might cause the Charging Station to try the same message again.</td></tr><tr><td>J02.FR.20</td><td>When configured to send meter data in the TransactionRequest (eventType = Ended) AND amount of meter data is too much for one TransactionRequest (eventType = Ended) message</td><td>Charging Station MAY remove samples until it fits in a message. When removing samples, the Charging Station SHOULD remove intermediate samples first (for example: 2nd sample, 4th sample, 6th sample etc.).</td><td>Samples should be removed in a way that it does not affect billing. See also E06.FR.12.</td></tr><tr><td>J02.FR.21</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values from components that support data signing and put them in the signedMeterValue field.</td><td></td></tr><tr><td>J02.FR.22</td><td></td><td>Meter values reported in a TransactionRequest message SHALL all be related to EVSE on which the transaction is taking place.</td><td></td></tr></table>
+
+# 3.2. ISO 15118 MeterValue signing
+
+# J03 - Charging Loop with metering information exchange
+
+Table 156. J03 - Charging Loop with metering information exchange
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Charging Loop with metering information exchange</td></tr><tr><td>2</td><td>ID</td><td>J03</td></tr><tr><td></td><td>Functional block</td><td>J. Meter Values</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 F1</td></tr><tr><td>3</td><td>Objectives</td><td>See ISO15118-1, use case Objective F1, page 37.</td></tr><tr><td>4</td><td>Description</td><td>See ISO15118-1, use case Description F1, page 37.</td></tr><tr><td>5</td><td>Prerequisites</td><td>- If authorization according use cases in Functional Block C is applied, it SHALL be finished successfully.
+See ISO15118-1, use case Prerequisites F1, page 37.</td></tr><tr><td>6</td><td>Actors</td><td>EV, EVSE, Charging Station</td></tr><tr><td>7</td><td>Combined scenario description</td><td>15118
+1a. The EV sends a ChargingStatusReq (in case of AC charging) message to the Charging Station, upon which EVSE returns a ChargingStatusRes containing the meter value from the fiscal meter.
+1b. The EV sends a CurrentDemandReq (in case of DC charging) message to the Charging Station, upon which EVSE returns a CurrentDemandRes containing the meter value from the fiscal meter.
+2. The EV sends a MeteringReceiptReq to the Charging Station to acknowledge receipt of the meter value.</td></tr><tr><td>8</td><td>Postcondition(s)</td><td>See ISO15118-1, use case End conditions F1, page 37.</td></tr></table>
+
+
+Figure 93. Charging Loop with metering information exchange
+
+<table><tr><td>9</td><td>Error handling</td><td>n/a</td></tr><tr><td>10</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# J03 - Charging Loop with metering information exchange - Requirements
+
+Table 157. J03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>J03.FR.04</td><td>When the Charging Station receives ISO 15118 signed MeteringReceiptReq message from EV</td><td>The Charging Station SHOULD NOT pass the meter value from the MeteringReceiptReq message to CSMS in a TransactionEventRequest (eventType = Updated) message. Instead, Charging Station sends transaction-related meter values as described in use case J02.</td><td>This does not imply that a Charging Station cannot require EV to send MeteringReceiptReq messages. An implementation at a Charging Station can be such, that every meter value from the fiscal meter that is send to CSMS (as per use case J02) must first have been acknowledged by a MeterReceiptReq from the EV.</td></tr></table>
+
+# K. SmartCharging
+
+# 1. Introduction
+
+This Functional Block describes all the functionalities that enable the CSO (or a third party) to influence the charging current/power transferred during a transaction, or set limits to the amount of current/power a Charging Station can draw from the grid.
+
+Smart Charging in general has more than one definition. It can mean that the grid capacity is used in such a manner that consumers are able to charge their batteries fully at any time, even if large groups of consumers wish to 'fill up' simultaneously. Smart can also mean that energy prices can be taken into consideration when charging. Or again smart can be taken as using a local supply of sustainable energy from solar panels. And it is even 'smarter' when the Electric Vehicle (EV) driver wishes to be part of the solution. Within OCPP, Smart Charging means that a CSMS gains the ability to influence the (de-)charging power or current of a specific EV, or the total allowed energy consumption on an entire Charging Station / a group of Charging Stations. Different setups can be used. The following four typical kinds of smart charging will be used to illustrate the possible behavior of smart charging using OCPP:
+
+- Internal Load Balancing
+- Central Smart Charging
+- Local Smart Charging
+- External Smart Charging Control Signals
+
+These types will be explained in Types of Smart Charging. Of course, more complex use cases are possible in which two or more of the above use cases are combined into one more complex system.
+
+NOTE A mapping of the ISO 15118 and OCPP terminology is provided in ISO 15118 and OCPP terminology mapping
+
+# 2. Types of Smart Charging
+
+This section is informative.
+
+# 2.1. Internal Load Balancing
+
+The simplest form of smart charging is the Load Balancing use case. This concerns internal load balancing within the Charging Station, where the Charging Station controls current/power per EVSE. The Charging Station is configured with a fixed limit, e.g. the maximum current of the connection to the grid. The Charging Station in this case is responsible for optimizing charging for all its EVSEs. When a charging station is not directly connected to the grid, the energy system of a client will be responsible for the power supply.
+
+This setup is typically used to set limits that are necessary due to known physical limits.
+
+
+Figure 94. Internal Load Balancing Smart Charging Topology
+
+# 2.2. Central Smart Charging
+
+The next level in smart charging is when the CSMS has the ability to influence the charging power or current of a specific EV, the total allowed energy consumption on an entire Charging Station or a group of Charging Stations. Central Smart Charging assumes that charge limits are controlled by the CSMS. This could for example be based on a grid connection, energy availability on the grid (e.g. capacity forecast from the grid operator (DSO)) or the wiring of a building. In this setup, the CSMS can optimize charging not only on one Charging Station, but one level "up": it can optimize more than one Charging Station that share a connection and thus calculate a more efficient schedule for charging.
+
+
+Figure 95. Central Smart Charging Topology
+
+Central Smart Charging can be done with a Control Pilot signal, albeit with some limitations, because an EV cannot communicate its charging needs via the Control Pilot signal. In analogy to the Local Smart Charging use case, an EVSE can execute a charging schedule by the Control Pilot signal.
+
+# 2.3. Local Smart Charging
+
+Local Smart Charging describes a use case in which smart charging enabled Charging Stations have charging limits controlled locally by a Local Controller, not the CSMS. This type of smart charging assumes the existence of a Local Controller, which is a logical component that controls a group of Charging Stations. A typical use would be a number of Charging Stations in a parking garage where the rating of the connection to the grid is less than the sum the ratings of the Charging Stations. Another application might be that the Local Controller receives information about the availability of power from a DSO or a local smart grid node.
+
+
+Figure 96. Local Smart Charging Topology
+
+# 2.4. External Smart Charging Control Signals
+
+The OCPP protocol is originally developed for communication between a CSMS and one or more Charging Stations. As described in the above, this means that a Charging Station Operator (CSO) CSMS controls a Charging Station and, based on the charging limits of both the EV and the Charging Station, the CSO determines how fast the EV is charged. However, in some situations / applications of OCPP enabled Charging Stations, these are not the only 2 factors that determine the charging speed. Other inputs that determine charging speed could be DSO signals (e.g. via IEC 61850 [IEC61850-7-420], IEC 60870 [IEC60870-5-104], DNP3 [DNP3] or OpenADR [OPENADR]) or signals from a Building / Home Energy Management System. Although these signals are out of scope for OCPP, it seems clear from an OCPP perspective that the CSMS is to be informed of changes in charging by external signals. However, this also leads to a number of questions, such as how to deal with conflicting signals. The figure below presents an example setup with an Energy Management System, where the external signals are visualized both in a setup with direct communication to the Charging Station as well as a multiple Charging Station setup using a Local Controller:
+
+
+Figure 97. External Smart Charging
+
+
+Figure 98. External Smart Charging via LC
+
+If a Charging Station is connected both to the outside world as well as to an Energy Management System (EMS), this could result in a situation where the EMS, for whatever reason, decides that charging is not opportune, despite a charging schedule it might have received from the CSMS. This means that the Charging Station will not behave as expected by the CSMS. To prevent this, the Charging Station will have to be able to notify the CSMS that it has received a command from the EMS. An example reason could be an airconditioning system that is given preference / priority instead of charging an EV by a home user (in this case assuming that using the airconditioning and EV charging at the same time is not possible). This EMS might be in place to manage the maximum limit of a connection, but this can also be externally controlled.
+
+# 3. Charging profiles
+
+# 3.1. Introduction
+
+Influencing the charge power or current is based on sending energy transfer limits at specific points in time to a Charging Station. Those limits are combined in a ChargingProfile. A ChargingProfile holds the ChargingSchedule which defines a block of charging Power or Current limits and can contain a start time and duration. These can be applied to Charging Stations as well as to EVSEs of the Charging Stations. In Example ChargingProfile an example of a ChargingProfile is given to illustrate how these charging profiles can be used.
+
+A CSMS can send a charging profile to a Charging Station using the message SetChargingProfileRequest, in the following situations:
+
+- At the start of a transaction to set the charging profile for the transaction
+- In a RequestStartTransaction request sent to a Charging Station
+- During a transaction to change the active profile for the transaction
+- Outside the context of a transaction as a separate message to set a charging profile to a local controller, Charging Station, or a default charging profile to an EVSE.
+
+# 3.2. Charging profile purposes
+
+This section describes a number of types of charging profiles that are supported in OCPP. There are four different types of charging profiles, depending on their purpose:
+
+<table><tr><td>ChargingProfile
+Purpose</td><td>Description</td></tr><tr><td>ChargingStationMaxProfile</td><td>In internal load balancing scenarios, the Charging Station has one or more local charging profiles that limit the power or current to be shared by all EVSEs of the Charging Station. The CSMS SHALL configure such a profile with ChargingProfilePurpose set to "ChargingStationMaxProfile". ChargingStationMaxProfile can only be set at Charging Station evseld 0.</td></tr><tr><td>TxProfile</td><td>A transaction-specific profile with purpose TxProfile overrules the TxDefaultProfile for the duration of the current transaction only or until the TxProfile expires, whichever occurs earlier.</td></tr><tr><td>TxDefaultProfile</td><td>Default schedules for new transactions that MAY be used to impose charging policies. An example could be a policy that prevents charging during the day.</td></tr><tr><td>ChargingStationExternalConstraints</td><td>When an external system, not the CSMS, sets a charging limit or schedule, the Charging Station uses this purpose to report such a limit/schedule.</td></tr></table>
+
+# 3.3. Charging profile recurrence
+
+This section explains the different kinds of charging schedules that can be used in a charging profile, as defined by the value of the attribute chargingProfileKind:
+
+<table><tr><td>ChargingProfile Kind</td><td>Description</td></tr><tr><td>Absolute</td><td>The charging schedule periods are relative to an absolute point in time defined in the schedule. This requires that startSchedule is set to a starting point in time. Use this, for example, to define a schedule that reduces charging between 17:00h and 21:00h, regardless of when charging session was started.</td></tr><tr><td>Recurring</td><td>The charging schedule restarts periodically at the first schedule period. To be most useful, this requires that startSchedule is set to a starting point in time. Use this in combination with recurrenceKind = Daily, for example, to define a schedule that reduces charging between 17:00h and 21:00h every day, regardless of when charging session was started.</td></tr><tr><td>Relative</td><td>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.</td></tr></table>
+
+# 3.4. Stacking charging profiles
+
+It is allowed to stack charging profiles of the same ChargingProfile purpose in order to describe complex calendars. For example, one can define ChargingProfile of purpose TxDefaultProfile with a duration and recurrence of one week that allows full power or current charging on weekdays from 23:00h to 06:00h and from 00:00h to 24:00h in weekends and reduced power or current charging at other times. On top of that, one can define other TxDefaultProfiles that define exceptions to this rule, for example for holidays.
+
+A ChargingProfile holds a ChargingSchedule that defines limits for a certain time interval. Precedence of ChargingSchedules is determined by the stackLevel of their ChargingProfile. When more than one ChargingProfile with the same chargingProfilePurpose is valid, then a ChargingSchedule of a ChargingProfile with a higher stack level overrules a ChargingSchedule from a ChargingProfile with a lower stack level.
+
+To avoid conflicts, it is not allowed to have multiple charging profiles with the same stackLevel and same chargingProfilePurpose to be valid on the same EVSE at a given time. Note, that a charging profile for EVSE #0 is considered to be active on all EVSEs!
+
+# 3.5. Combining Charging Profile Purposes
+
+The Composite Schedule that will guide the charging level is a combination of the prevailing Charging Profiles of the different chargingProfilePurposes and stack levels.
+
+As mentioned before, for each charging profile purpose, at any point in time, the leading charging schedule for that purpose is the charging schedule that has a schedule period defined for that time and that belongs to a charging profile with the highest stack level that is valid at that time, as determined by their validFrom and validTo parameters. The Composite Schedule is then calculated by taking the lowest charging limit (taking the different chargingRateUnits into account) among the leading profiles of the different purposes for each time interval.
+
+The only exception is when both a TxDefaultProfile and a TxProfile are valid. In that case, the TxProfile will always overrule the TxDefaultProfile, hence the Composite Schedule will not take the leading profile of purpose TxDefaultProfile into account in this specific situation. Note that time intervals do not have to be of fixed length, nor do they have to be the same for every ChargingProfile purpose. This means that a resulting Composite Schedule MAY contain intervals of different lengths.
+
+In case the Charging Station is equipped with more than one EVSE, the limit value of ChargingStationMaxProfile is the limit for all EVSEs combined.
+
+The two figures below will be used to give an example of combining multiple charging profiles with different stackLevels and Purposes.
+
+
+Figure 99. Multiple valid charging profiles - situation 1
+
+Suppose that at a certain time interval the valid charging profiles are as in the above figure (situation 1). The composite schedule for this time interval will then be the lowest of the charging limits given in the ChargingStationMaxProfile with stackLevel 0, the TxDefaultProfile with stackLevel 2 and the ChargingStationExternalConstraints profile with stackLevel 1.
+
+
+Figure 100. Multiple valid charging profiles - situation 2
+
+On the other hand, consider the situation in which for a certain time interval the valid charging profiles are as in the above figure (situation 2). The composite schedule for this time interval will then be the lowest of the charging limits given in the ChargingStationMaxProfile with stackLevel 0, the TxProfile with stackLevel 1 and the ChargingStationExternalConstraints profile with stackLevel 1. Note that in this situation the TxProfile overrules the TxDefaultProfile.
+
+# 3.6. Example Charging Profile
+
+This section is informative.
+
+The following data structure describes a daily default profile that limits the power to 6 kW between 08:00h and 20:00h and to 11 kW between 00:00h and 08:00h and between 20:00h and 00:00h.
+
+<table><tr><td>ChargingProfile</td><td></td><td></td><td></td></tr><tr><td>chargingProfileId</td><td>100</td><td></td><td></td></tr><tr><td>stackLevel</td><td>0</td><td></td><td></td></tr><tr><td>chargingProfilePurpose</td><td>TxDefaultProfile</td><td></td><td></td></tr><tr><td>chargingProfileKind</td><td>Recurring</td><td></td><td></td></tr><tr><td>reccuracyKind</td><td>Daily</td><td></td><td></td></tr><tr><td>chargingSchedule</td><td colspan="3">(List of 1 ChargingSchedule elements)</td></tr><tr><td></td><td>ChargingSchedule</td><td></td><td></td></tr><tr><td></td><td>duration</td><td>86400 (=24 hours)</td><td></td></tr><tr><td></td><td>startSchedule</td><td>2013-01-01T00:00Z</td><td></td></tr><tr><td></td><td>chargingRateUnit</td><td>W</td><td></td></tr><tr><td></td><td>chargingSchedulePeriod</td><td colspan="2">(List of 3 ChargingSchedulePeriod elements)</td></tr><tr><td></td><td></td><td>ChargingSchedulePeriod</td><td></td></tr><tr><td></td><td></td><td>startPeriod</td><td>0 (=00:00)</td></tr><tr><td></td><td></td><td>limit</td><td>11000</td></tr><tr><td></td><td></td><td>numberPhases</td><td>3</td></tr><tr><td></td><td></td><td>ChargingSchedulePeriod</td><td></td></tr><tr><td></td><td></td><td>startPeriod</td><td>28800 (=08:00)</td></tr><tr><td></td><td></td><td>limit</td><td>6000</td></tr><tr><td></td><td></td><td>numberPhases</td><td>3</td></tr><tr><td></td><td></td><td>ChargingSchedulePeriod</td><td></td></tr><tr><td></td><td></td><td>startPeriod</td><td>72000 (=20:00)</td></tr><tr><td></td><td></td><td>limit</td><td>11000</td></tr><tr><td></td><td></td><td>numberPhases</td><td>3</td></tr></table>
+
+# IMPORTANT
+
+The amount of phases used during charging is limited by the capabilities of: The Charging Station, EV and Cable between CS and EV. If any of these three is not capable of 3 phase charging, the EV will be charged using the number of phases that is supported by all three.
+
+# IMPORTANT
+
+Switching the number of used phases during a schedule or transaction should be done with care. Some EVs MAY not support this and changing the amount of phases MAY result in physical damage. With the Configuration Variable: Phases3to1 The Charging Station can tell if it supports switching the amount of phases during a transaction.
+
+# TIP
+
+On days on which daylight saving goes into or out of effect, a special profile might be needed (e.g. for relative profiles).
+
+# 3.6.1. Example Using Stacked Charging Profiles
+
+A CSO wishes to limit charging to $2\mathrm{kW}$ during the peak hours of the day from 17:00h to 20:00h. This limit does not apply to Sundays and this limit does not apply to Christmas Day either.
+
+If this applies to a large number or charging stations, then it is not practical to delete the charging profile every Sunday and then add it again on Monday. A possible solution is to add profiles with higher stack level for the exceptions to the base profile. See the following JSON examples where stack levels #2 and #3 are used to define exceptions for Sunday and Christmas.
+
+(1) TxDefaultProfile, stack #1: time-of-day limitation to 2 kW, recurring every day from 17:00h to 20:00h.
+
+```txt
+"chargingProfile": { "id": 10, "stkLevel": 1, "chargingProfilePurpose": "TxDefaultProfile", "chargingProfileKind": "Recurring", "recurrencyKind": "Daily", "chargingSchedule": [ { "id": 1, "startSchedule": "2020-01-09T17:00:00", "duration": 1080, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 2000} ] } ]
+```
+
+(2) TxDDefaultProfile, stack #2: overruling Sundays to no limit, recurring every week starting 2020-01-05.
+
+```txt
+"chargingProfile": { "id": 11, "stkLevel": 2, "chargingProfilePurpose": "TxDefaultProfile", "chargingProfileKind": "Recurring", "reccurcyKind": "Weekly", "chargingSchedule": [ { "id": 1, "startSchedule": "2020-01-05T00:00:00", "duration": 86400, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 999999} ] } ]
+```
+
+(3) TxDefaultProfile, stack #3: overruling Christmas Day 2020 to no limit, fixed date 2020-12-25.
+
+Note, that this profile is only valid in the year 2020.
+
+```javascript
+"chargingProfile": { "id": 12, "stkLevel": 3, "chargingProfilePurpose": "TxDefaultProfile", "chargingProfileKind": "Absolute", "validFrom": "2020-01-01T00:00:00", "validTo": "2021-01-01T00:00:00", "chargingSchedule": [ { "id": 1, "startSchedule": "2020-12-25T00:00:00", "duration": 86400, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 999999} ] } ]
+```
+
+# NOTE
+
+Normally, when no limits are desired for charging, one will not define a charging schedule period for those hours (see stack level #1 for hours outside 17:00h - 20:00h). However, when overruling a charging schedule by one from a profile with a higher stack level, it is not possible to define a charging schedule period that has no limit. Therefore, the charging schedules for stack #2 and #3 in the above example use a (arbitrary) high value of 999999.
+
+# 4. Smart Charging Signals to a Charging Station from Multiple Actors
+
+This section is normative.
+
+Within OCPP, multiple mechanism are supported for Smart Charging, i.e. multiple mechanisms are available that can add a limit when charging an EV:
+
+1. The CSMS can influence charging by sending a SetChargingProfile message to the Charging Station. See K01 - SetChargingProfile.
+2. The EV can influence charging based on the PlugAndCharge functionality: the ISO 15118 enables EV initiated Charging Limits. See Section 5.3. ISO 15118 based Smart Charging.
+3. Some local input, for example a Home Energy Management System (HEMS) or DSO, can influence the charging, for example via an External Smart Charging Control signal. See K11 - Set / Update External Charging Limit.
+4. A Charging Station can limit charging when it is load balancing when more than 1 EV is charging.
+
+The assumption is that all parties that might be involved in setting limits for charging an EV will use one of the above mechanisms directly or indirectly.
+
+To determine how a Charging Station should respond to simultaneous smart charging signals from multiple actors, the following rules should be followed:
+
+Table 158. Smart Charging rules for multiple actor situation
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>SC.01</td><td></td><td>At any point in time, the charging limit, which is the result of merging the schedules from external sources and the OCPP charging profiles with the highest stackLevel from each of the purposes ChargingStationMaxProfile, ChargingStationExternalConstraints and TxDefaultProfile (or TxProfile), SHALL be less than or equal to the lowest value of available power or current in any of the merged schedules.</td><td>For safety purposes.</td></tr><tr><td>SC.02</td><td>When the ChargingProfile has changed</td><td>The Charging Station SHALL always inform the CSMS.</td><td>The message used for this varies depending on the which of the mechanisms mentioned at the start of this section is applicable: 1. n/a 2. NotifyEVChargingScheduleRequest 3. NotifyChargingLimitRequest 4. TransactionEventRequest</td></tr><tr><td>SC.03</td><td></td><td>Reporting to the CSMS concerning a changed limit in the ChargingProfile for mechanisms 3 and 4 as described in SC.02 MAY be skipped if the change in the limit is smaller than the percentage defined in the Configuration Variable: LimitChangeSignificance.</td><td>This is to prevent the Charging Station to send a lot of messages for small fluctuations (e.g. due to HEMS / smart meter input at the Charging Station)</td></tr><tr><td>SC.04</td><td></td><td>The GetCompositeScheduleResponse message SHALL always report the expected charging schedule, i.e. the lowest limit for charging. This means that when an EV has a charging limit X and indicates (e.g. using the ISO 15118 protocol) that it will use less energy than offered, amount Y, the Charging Station SHALL report limit Y.</td><td></td></tr></table>
+
+# 5. Use cases & Requirements
+
+# 5.1. General Smart Charging
+
+# K01 - SetChargingProfile
+
+Table 159. K01 - Central Smart Charging
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>SetChargingProfile</td></tr><tr><td>2</td><td>ID</td><td>K01</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sets charging limits by sending SetChargingProfileRequest to the Charging Station.
+2. The Charging Station responds with SetChargingProfileResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station Successfully influences the charging power or current of a specific EV, following the SetChargingProfileRequest sent by the CSMS.
+Failure postcondition:
+The Charging Station was not able to influence the charging power or current of a specific EV, following the SetChargingProfileRequest sent by the CSMS.</td></tr></table>
+
+
+
+Figure 101. Sequence Diagram: SetChargingProfile
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# K01 - SetChargingProfile - Requirements
+
+Table 160. K01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K01.FR.01</td><td></td><td>The CSMS MAY choose to set charging limits to a transaction using TxProfile.</td><td></td></tr><tr><td>K01.FR.02</td><td></td><td>The CSMS MAY send a new charging profile for the EVSE that SHALL be used as a limit schedule for the EV.</td><td></td></tr><tr><td>K01.FR.03</td><td></td><td>The CSMS SHALL include the transactionId in the SetChargingProfileRequest when setting a TxProfile.</td><td>The transactionId is used to match the profile to a specific transaction.</td></tr><tr><td>K01.FR.04</td><td>K01.FR.03 AND the given transactionId is known</td><td>The Charging Station SHALL apply the sent TxProfile to the transaction with the specified transactionId.</td><td></td></tr><tr><td>K01.FR.05</td><td>When a SetChargingProfileRequest with an already known ChargingProfile.id is received AND the existing ChargingProfile does NOT have chargingProfilePurpose = ChargingStationExter nalConstraints</td><td>The Charging Station SHALL replace the existing ChargingProfile with the one specified.</td><td>ChargingStationExternalCon straints profile cannot be replaced.</td></tr><tr><td>K01.FR.06</td><td>When chargingProfilePurpose is NOT TxProfile</td><td>The CSMS SHALL NOT send a ChargingProfile with a stackLevel - chargingProfilePurpose - evsId combination that already exists in another ChargingProfile (with different id) on the Charging Station and has an overlapping validity period.</td><td>This is to ensure that no two charging profiles with same stack level and purpose can be valid at the same time.</td></tr><tr><td>K01.FR.07</td><td>When the Charging Station accepts a SetChargingProfileRequest</td><td>The Charging Station SHALL re-evaluate its collection of charging profiles to determine which ChargingProfile will become active.</td><td></td></tr><tr><td>K01.FR.08</td><td></td><td>The CSMS MAY send charging profiles to a Charging Station that are to be used as default charging profiles.</td><td></td></tr><tr><td>K01.FR.09</td><td>When a SetChargingProfileRequest with a TxProfile is received AND there is no transaction active on the specified EVSE</td><td>The Charging Station SHALL send a SetChargingProfileResponse with status Rejected.</td><td></td></tr><tr><td>K01.FR.10</td><td>When validFrom and validTo of a ChargingProfile are not set</td><td>The Charging Station SHALL consider the ChargingProfile to be valid indefinitely until it is explicitly replaced.</td><td></td></tr><tr><td>K01.FR.11</td><td>If ChargingSchedule has a duration AND ChargingSchedulePeriod.sta rtPeriod >= ChargingSchedule.duration</td><td>The Charging Station SHALL not execute the ChargingSchedulePeriod, because it is past the duration of the ChargingSchedule.</td><td></td></tr><tr><td>K01.FR.12</td><td></td><td>A ChargingSchedulePeriod remains active until the next ChargingSchedulePeriod in the list starts or until ChargingSchedule.duration has elapsed.</td><td></td></tr><tr><td>K01.FR.13</td><td>When concurrencyKind is used in combination with a ChargingSchedule duration shorter than concurrencyKind period.</td><td>The Charging Station SHALL fall back to default behavior after ChargingSchedule duration ends.</td><td></td></tr><tr><td>K01.FR.14</td><td>When a SetChargingProfileRequest with a TxDefaultProfile and evseld = 0 is received AND No other TxDefaultProfile with the same stackLevel is installed on any specific EVSE.</td><td>The Charging Station SHALL apply, but not copy, this profile to all EVSEs.</td><td>A TxDefaultProfile charging profile on EVSE #0 is "owned by" EVSE #0, but has effect on all EVSEs.</td></tr><tr><td>K01.FR.15</td><td>When a SetChargingProfileRequest with a TxDefaultProfile and evseld > 0 is received AND No TxDefaultProfile with the same stackLevel is installed on EVSE #0.</td><td>The Charging Station SHALL only apply this profile to the specified EVSE.</td><td></td></tr><tr><td>K01.FR.16</td><td></td><td>TxProfile SHALL only be used with evseld >0.</td><td></td></tr><tr><td>K01.FR.17</td><td></td><td>When more than one ChargingProfile with the same chargingProfilePurpose is valid, as determined by their validFrom and validTo fields, then a ChargingSchedule from a ChargingProfile with a higher stackLevel/ overrules a ChargingSchedule from a ChargingProfile with a lower stackLevel.</td><td></td></tr><tr><td>K01.FR.19</td><td></td><td>The CSMS SHALL NOT set phaseToUse in a SetChargingProfileRequest when numberPhases is other than 1.</td><td></td></tr><tr><td>K01.FR.20</td><td></td><td>The CSMS SHALL NOT set phaseToUse in a SetChargingProfileRequest when the EVSE does not have ACPPhaseSwitchingSupported defined and set to true.</td><td></td></tr><tr><td>K01.FR.21</td><td></td><td>The optional ChargingSchedule field minChargingRate MAY be used by the Charging Station to optimize the power distribution between the EVSEs.</td><td>The parameter informs the Local Controller that charging below minChargingRate is inefficient, giving the possibility to select another balancing strategy.</td></tr><tr><td>K01.FR.22</td><td></td><td>The CSMS SHALL NOT set chargingProfilePurpose to ChargingStationExternalConstraints in a SetChargingProfileRequest.</td><td>This purpose is only used when an external system has set a charging limit/schedule.</td></tr><tr><td>K01.FR.26</td><td>When a SetChargingProfileRequest is received with a value for chargingRateUnit, that is not configured in the configuration variable ChargingScheduleChargingRateUnit.</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status Rejected.</td><td></td></tr><tr><td>K01.FR.27</td><td></td><td>ChargingProfiles set via SetChargingProfileRequest SHALL be persistent across reboots/power cycles.</td><td></td></tr><tr><td>K01.FR.28</td><td>When a SetChargingProfileRequest is received for an evseld that does not exist.</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status Rejected</td><td></td></tr><tr><td>K01.FR.29</td><td>When Charging Station does not support smart charging.</td><td>Charging Station SHALL respond with RPC Framework CALLERROR: NotSupported or NotImplemented.</td><td></td></tr><tr><td>K01.FR.30</td><td>chargingProfile has a chargingSchedule with startSchedule set to a time in the future</td><td>The Charging Station SHALL only start imposing the limitation of this schedule as of point in time set by startSchedule</td><td></td></tr><tr><td>K01.FR.31</td><td></td><td>The startPeriod of the first chargingSchedulePeriod in a chargingSchedule SHALL always be 0.</td><td></td></tr><tr><td>K01.FR.32</td><td>(K01.FR.14 OR K01.FR.15) AND a transaction is active on the specified EVSE(s) (evseld = 0 refers to all EVSEs.)</td><td>The Charging Station SHALL continue the transaction on the specified EVSE(s), but switch to using the new/updated TxDefaultProfile.</td><td></td></tr><tr><td>K01.FR.33</td><td>K01.FR.03 AND the given transactionId is not known</td><td>The Charging Station SHALL reject the SetChargingProfileRequest.</td><td></td></tr><tr><td>K01.FR.34</td><td>The CSMS has not received a NotifyEVChargingNeedsRequest for the current transaction, i.e. charging session is not using ISO 15118</td><td>The ChargingProfile in the SetChargingProfileRequest SHALL contain only one ChargingScheduleType.</td><td>See use cases K15-K17 for ISO 15118 smart charging.</td></tr><tr><td>K01.FR.35</td><td></td><td>The list of ChargingSchedulePeriod elements in a chargingSchedule SHALL be ordered by increasing values of ChargingSchedulePeriod.startPeriod.</td><td>This means the list is in chronological order</td></tr><tr><td>K01.FR.36</td><td>When validFrom of a ChargingProfile is set</td><td>The Charging Station SHALL consider the ChargingProfile to be valid when current time >= validFrom.</td><td></td></tr><tr><td>K01.FR.37</td><td>When validTo of a ChargingProfile is set</td><td>The Charging Station SHALL consider the ChargingProfile to be valid when current time < validTo.</td><td></td></tr><tr><td>K01.FR.38</td><td>When chargingProfilePurpose = ChargingStationMaxPr ofile</td><td>chargingProfileKind SHALL NOT be Relative</td><td></td></tr><tr><td>K01.FR.39</td><td>When chargingProfilePurpose is TxProfile</td><td>The CSMS SHALL NOT send a ChargingProfile with a stackLevel - transactionId combination that already exists in another ChargingProfile (with different id) with purpose TxProfile.</td><td>This is to ensure that no two charging profiles with same stack level and purpose can be valid at the same time.</td></tr><tr><td>K01.FR.40</td><td>When chargingProfileKind of a ChargingProfile is Absolute or Recurring</td><td>A value for startSchedule SHALL exist in the ChargingSchedule of the ChargingProfile.</td><td>This determines start date-time of the schedule and of the concurrency sequence.</td></tr><tr><td>K01.FR.41</td><td>When chargingProfileKind of a ChargingProfile is Relative</td><td>The field startSchedule SHALL be absent in the ChargingSchedule of the ChargingProfile.</td><td>A relative profile starts from when the profile is activated.</td></tr><tr><td>K01.FR.42</td><td>K01.FR.41</td><td>It is RECOMMENDED to make the ChargingSchedulePeriods relative to the moment the Charging Station is ready to deliver energy, i.e. when the EV driver is authorized and the EV is connected.</td><td>This is the point in a transaction where the charging station is ready to deliver energy. If PowerPathClosed is a TxStartPoint, then this will concur with the start of a transaction. In the next OCPP version, this will become a more strict requirement.</td></tr><tr><td>K01.FR.43</td><td>When a SetChargingProfileRequest with a value for numberPhases is received AND the EVSE is of type AC AND the Charging Station cannot ensure that no more than the received numberPhases will be used</td><td>The Charging Station SHALL respond with status = Rejected</td><td>Note that even when for example the ChargingProfile defines 3 phases and the Charging Station is able to charge with 3 phases, it is not guaranteed that the EV or cable are able to charge with 3 phases. Based on received MeterValues the CSMS can determine the used number of phases. Please refer to requirement K01.FR.50 and K01.FR.51, for correctly calculating the limits per phase.</td></tr><tr><td>K01.FR.44</td><td>When a SetChargingProfileRequest with a value for numberPhases or phaseToUse is received AND the EVSE is of type DC</td><td>The Charging Station MAY respond with status = Accepted, instead of Rejected and ignore the provided values for numberPhases and phaseToUse.</td><td></td></tr><tr><td>K01.FR.45</td><td>When a SetChargingProfileRequest with a value for numberPhases is received AND the EVSE is of type AC AND the received numberPhases is NOT supported by the Charging Station and higher than the numberPhases that are supported by the Charging Station</td><td>The Charging Station MAY respond with status = Accepted, instead of Rejected and impose the limits to a lower numberPhases</td><td>Please refer to requirement K01.FR.50 and K01.FR.51, for correctly calculating the limits per phase.</td></tr><tr><td>K01.FR.46</td><td>When a SetChargingProfileRequest with numberPhases = 1 and a value for phaseToUse is received AND the EVSE is of type AC AND the EVSE is capable of switching the phase connected to the EV, which is indicated by ACPhaseSwitchingSupporte d defined as true OR the EVSE is already going to use the received phaseToUse</td><td>The Charging Station SHALL use the phase indicated by the received phaseToUse to connect to the EV.</td><td></td></tr><tr><td>K01.FR.47</td><td>When a SetChargingProfileRequest with numberPhases = 1 and phaseToUse is omitted is received AND the EVSE is of type AC</td><td>The Charging Station SHALL select the phase on its own.</td><td></td></tr><tr><td>K01.FR.48</td><td>When a SetChargingProfileRequest with a value for phaseToUse is received AND the EVSE is NOT capable of switching the phase connected to the EV, which is indicated by ACPhaseSwitchingSupporte d not being implemented or defined as false AND the EVSE is NOT going to use the received phaseToUse</td><td>The Charging Station SHALL respond with status = Rejected.</td><td></td></tr><tr><td>K01.FR.49</td><td>When a SetChargingProfileRequest without a value for numberPhases is received AND the EVSE is of type AC</td><td>The Charging Station SHALL assume numberPhases = 3 as a default value.</td><td></td></tr><tr><td>K01.FR.50</td><td>When a SetChargingProfileRequest with a chargingRateUnit = W is received AND The ChargingSchedule is used for AC charging</td><td>The Charging Station SHOULD calculate the phase current limit via: Current per phase = Power / (Line Voltage * Number of Phases).</td><td>The "Line Voltage" used in the calculation is not the measured voltage, but the set voltage for the area (for example, 230 or 110 V). The "Number of Phases" is the numberPhases from the ChargingSchedulePeriod. It is usually more convenient to use chargingRateUnit = A for AC charging.</td></tr><tr><td>K01.FR.51</td><td>When a SetChargingProfileRequest with a chargingRateUnit = A is received</td><td>The Charging Station SHALL use the provided limits, to limit the amount of Ampere per phase, not the sum of all phases.</td><td></td></tr><tr><td>K01.FR.52</td><td>When a SetChargingProfileRequest with a TxDefaultProfile and evseld = 0 is received AND A TxDefaultProfile with the same stackLevel is installed on a specific EVSE and its chargingProfile.id does NOT equal the received chargingProfile.id</td><td>The Charging Station SHALL respond with a SetChargingProfileResponse with status Rejected and optionally with reasonCode = DuplicateProfile.</td><td></td></tr><tr><td>K01.FR.53</td><td>When a SetChargingProfileRequest with a TxDefaultProfile and evseld > 0 is received AND A TxDefaultProfile with the same stackLevel is installed on EVSE #0 and its chargingProfile.id does NOT equal the received chargingProfile.id</td><td>The Charging Station SHALL respond with a SetChargingProfileResponse with status Rejected and optionally with reasonCode = DuplicateProfile.</td><td></td></tr></table>
+
+# K02 - Central Smart Charging
+
+Table 161. K02 - Central Smart Charging
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Central Smart Charging</td></tr><tr><td>2</td><td>ID</td><td>K02</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by the EV. The CSMS calculates a ChargingSchedule to stay within limits which MAY be imposed by any external system.See: Central Smart Charging</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. After authorization the Charging Station will set a maximum current, that an EV might draw via the Control Pilot signal. This limit is based on (default) ChargingProfiles that the Charging Station previously received from the CSMS.2. The EV starts charging and a TransactionEventRequest is sent to the CSMS.3. The CSMS responds with a TransactionResponse.4. In response to a TransactionEventRequest the CSMS MAY choose to set charging limits to the transaction using a SetChargingProfileRequest.5. The Charging Station responds with a SetChargingProfileResponse.6. While charging is in progress the EVSE will continuously adapt the maximum current or power according to the installed ChargingProfiles.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>K03 - Local Smart ChargingK04 - Internal Load Balancing</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Functional Block Smart Charging is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The Charging Station Successfully influences the charging power or current of a specific EV, following the SetChargingProfileRequest sent by the CSMS.Failure postcondition:The Charging Station was not able to influence the charging power or current of a specific EV, following the SetChargingProfileRequest sent by the CSMS.</td></tr></table>
+
+
+Figure 102. Sequence Diagram: Central Smart Charging
+
+Explanation for the above figure:
+
+- After authorization the EVSE will set a maximum current to use via the Control Pilot signal. This limit is based on a (default) charging profile that the EVSE had previously received from the CSMS. The EV starts charging and a TransactionEventRequest is sent to the CSMS.
+- While charging is in progress the EVSE will continuously adapt the maximum current or power according to the charging profile. Optionally, at any point in time the CSMS may send a new charging profile for the EVSE. The Charging Station will then also take this new schedule into account when calculating a new composite schedule. This way the CSMS can influence the charging of an ongoing transaction.
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td rowspan="4">8</td><td rowspan="4">Remark(s)</td><td>The CSMS determines the constraints on ChargingSchedule per transaction.</td></tr><tr><td>The CSMS imposes charging limits on EVSEs. In response to a TransactionRequest the CSMS may choose to set charging limits to the transaction using the TxProfile. It is RECOMMENDED to check the offline flag in TransactionRequest prior to sending a charging profile to check if the transaction is likely to be still ongoing, the TransactionRequest might have been cached during an Offline period. The final schedule constraints that apply to a transaction are determined by merging the profiles with purposes ChargingStationMaxProfile with the profile TxProfile or TxDefaultProfile in case no profile of purpose TxProfile is provided. Zero or more of the following ChargingProfile purposes MAY have been previously received from the CSMS: ChargingStationMaxProfile or TxDefaultProfile.</td></tr><tr><td>It is recommended to omit the duration field of the ChargingSchedule from a TxProfile, so that it automatically lasts until the end of the transaction. If the TxProfile expires before the transaction ends, it falls back to the lowest limit of the active TxDefaultProfile and ChargingStationMaxProfile. If there are no other active profiles, it falls back to the local limit of the Charging Station.</td></tr><tr><td>The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows: TxStartPoint: Authorized, DataSigned, PowerPathClosed, EnergyTransfer This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use case: E01 - Start Transaction options.</td></tr></table>
+
+# K02 - Central Smart Charging - Requirements
+
+Table 162. K02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K02.FR.01</td><td></td><td>The CSMS SHALL use charging profiles to stay within the limits imposed by any external system.</td><td></td></tr><tr><td>K02.FR.02</td><td>After authorization.</td><td>The EVSE will set a maximum current to use via the Control Pilot signal.</td><td>This requirement only applies to AC chargers that use 61851. The limit may be based on a (default) charging profile that the EVSE previously received from the CSMS.</td></tr><tr><td>K02.FR.03</td><td></td><td>In order to ensure that an updated ChargingProfile applies only to the current transaction, the CSMS SHALL set the chargingProfilePurpose of the ChargingProfile to TxProfile.</td><td>An updated charging profile can be sent by the CSMS by sending a ChargingProfile with the same chargingProfileId.</td></tr><tr><td>K02.FR.04</td><td>If a transaction-specific profile with purpose TxProfile is present.</td><td>The TxProfile SHALL overrule the default charging profile with purpose TxDefaultProfile for the duration of the current transaction only.</td><td></td></tr><tr><td>K02.FR.05</td><td>K02.FR.04 After the transaction is stopped</td><td>The TxProfile SHALL be deleted.</td><td></td></tr><tr><td>K02.FR.06</td><td></td><td>The optional ChargingSchedule field minChargingRate MAY be used by the Charging Station to optimize the power distribution between the EVSEs.</td><td>The parameter informs the Local Controller that charging below minChargingRate is inefficient, giving the possibility to select another balancing strategy.</td></tr><tr><td>K02.FR.07</td><td></td><td>The CSMS SHALL NOT set chargingProfilePurpose to ChargingStationExternalConstraints in a SetChargingProfileRequest.</td><td>This purpose is only used when an external system has set a charging limit/schedule.</td></tr><tr><td>K02.FR.08</td><td>K02.FR.04 AND The charging schedule of TxProfile ends, before the transaction ends, because the set duration or validTo period expired</td><td>The Charging Station SHALL fall back to using the lowest limit of the active TxDefaultProfile and ChargingStationMaxProfile. If there are no other active profiles, it falls back to the local limit of the Charging Station</td><td></td></tr></table>
+
+# K03 - Local Smart Charging
+
+Table 163. K03 - Local Smart Charging
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Local Smart Charging</td></tr><tr><td>2</td><td>ID</td><td>K03</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable charging limits to be set at the Charging Station by a Local Controller.</td></tr><tr><td>4</td><td>Description</td><td>Local Smart Charging describes a use case in which smart charging enabled Charging Stations have charging limits controlled locally by a Local Controller, not directly by the CSMS. The charging limits MAY either be pre-configured in the Local Controller in one way or another, or they can be set by the CSMS. The Local Controller SHALL contain the logic to distribute this capacity among the connected EVSEs by adjusting their limits as needed.
+This use case for Local Smart Charging is about limiting the amount of power that can be used by a group of Charging Stations, to a certain maximum.
+See Figure Local Smart Charging Topology</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV, Local Controller, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. After authorization the Charging Station will set a maximum current, an EV might draw, via the Control Pilot signal. This limit is based on a TxDefaultProfile that the Charging Station previously received from the CSMS.
+2. The EV starts charging, the Charging Station sends a TransactionEventRequest.
+3. A TransactionRequest is sent to the CSMS via the Local Controller, so that the Local Controller knows a transaction has started.
+4. During the transaction, the Local Controller sends a SetChargingProfileRequest to influence the charging current/power.
+5. The Charging Station calculates the charging limits based on the installed ChargingProfiles.
+6. The Local Controller just passes on the messages between Charging Station and CSMS, so that the CSMS can address all the Local Smart Charging group members individually.
+7. While charging is in progress the EVSE will continuously adapt the maximum current according to the installed ChargingProfiles.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Functional Block Smart Charging is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Local Controller Successfully controls maximum charging limits via the Control Pilot Signal.
+Failure postcondition:
+n/a</td></tr></table>
+
+
+Figure 103. Sequence Diagram: Local Smart Charging
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The Local Controller for Local Smart Charging can be implemented in different ways, for example: as a separate physical component or as part of a ‘master’ Charging Station controlling a number of other Charging Stations.The Local Controller MAY or MAY NOT have any EVSEs of its own.The limits on Charging Stations in a Local Smart Charging group can either be pre-configured in the Local Controller in one way or another, or they can be set by the CSMS. The Local Controller contains the logic to distribute this capacity among the connected EVSEs by adjusting their limits as needed.</td></tr></table>
+
+# K03 - Local Smart Charging - Requirements
+
+Table 164. K03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K03.FR.01</td><td></td><td>The Local Controller MAY impose charging limits on a Charging Station.</td><td></td></tr><tr><td>K03.FR.02</td><td>K03.FR.01</td><td>These limits MAY be changed dynamically during the charging process in order to keep the power consumption of the group of Charging Stations within the group limits.</td><td></td></tr><tr><td>K03.FR.03</td><td>If at any point in time the Local Controller sends a new ChargingProfile to an EVSE</td><td>The Charging Station SHALL take this new ChargingProfile into account when calculating a new composite schedule that it will use to charge the EV.</td><td></td></tr><tr><td>K03.FR.04</td><td></td><td>A Transaction with a chargingPriority that is higher than other transactions SHALL be fulfilled as long as possible, even if other transactions have to be suspended.</td><td></td></tr><tr><td>K03.FR.05</td><td>If a chargingPriority is given in a TransactionResponse that is different from the chargingPriority in the IdTokenInfo.</td><td>The chargingPriority from the TransactionResponse shall be used for this transaction and for this transaction only.</td><td>It shall therefore not be stored e.g. in the Authorization Cache.</td></tr><tr><td>K03.FR.06</td><td>When no chargingPriority is known.</td><td>The Transaction or IdToken SHALL be assumed to have chargingPriority 0.</td><td></td></tr><tr><td>K03.FR.07</td><td></td><td>The optional ChargingSchedule field minChargingRate MAY be used by the Charging Station to optimize the power distribution between the EVSEs.</td><td>The parameter informs the Local Controller that charging below minChargingRate is inefficient, giving the possibility to select another balancing strategy.</td></tr><tr><td>K03.FR.08</td><td></td><td>The Local Controller SHALL NOT set chargingProfilePurpose to ChargingStationExternalConstraints in a SetChargingProfileRequest.</td><td>This purpose is only used when an external system has set a charging limit/schedule.</td></tr></table>
+
+# K04 - Internal Load Balancing
+
+Table 165. K04 - Internal Load Balancing
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Internal Load Balancing</td></tr><tr><td>2</td><td>ID</td><td>K04</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable internal load balancing within the Charging Station and between EVSEs.</td></tr><tr><td>4</td><td>Description</td><td>The Load Balancing use case is about internal load balancing within the Charging Station, where the Charging Station controls current/power per EVSE.The Charging Station is configured with a fixed limit, e.g. the maximum current of the connection to the grid.See K01 - Set Charging Profile</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EVSE</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sets known physical grid connection limits by sending a ChargingProfile.2. The Charging Station controls current/power per EVSE.3. The EVSE sends a Control Pilot signal to the EV.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Functional Block Smart Charging is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The Charging Station Successfully balances the current/power between the different EVSEs,based on what the CSMS is sending.Failure postcondition:ChargingProfile is not Accepted. Charging is possible, although the Charging Station will not adhere to the ChargingProfile.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# K04 - Internal Load Balancing - Requirements
+
+Table 166. K04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K04.FR.01</td><td></td><td>The Charging Station SHALL control the ChargingSchedule per EVSE.</td><td></td></tr><tr><td>K04.FR.02</td><td></td><td>The Charging Station SHALL be configured with a fixed limit.</td><td>e.g. the maximum current of the connection to the grid.</td></tr><tr><td>K04.FR.03</td><td></td><td>A ChargingProfile with the purpose ChargingStationMaxProfile can only be set at Charging Station EVSE with Id 0.</td><td></td></tr><tr><td>K04.FR.04</td><td></td><td>The optional ChargingSchedule field minChargingRate MAY be used by the Charging Station to optimize the power distribution between the EVSEs.</td><td>The parameter informs the Local Controller that charging below minChargingRate is inefficient, giving the possibility to select another balancing strategy.</td></tr><tr><td>K04.FR.05</td><td></td><td>The combined energy flow of all EVSEs (and the Charging Station hardware itself) SHALL NOT be greater than the limit set by ChargingStationMaxProfile.</td><td></td></tr></table>
+
+# K05 - Remote Start Transaction with Charging Profile
+
+Table 167. K05 - Remote Start Transaction with Charging Profile
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remote Start Transaction with Charging Profile</td></tr><tr><td>2</td><td>ID</td><td>K05</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to remotely start a transaction by directly including a ChargingProfile, in order to assure that the transaction will use the right ChargingProfile.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS can remotely start a transaction with purpose TxProfile. This assures that the right TxProfile is used. Also, when the Charging Station goes Offline after receiving RequestStartTransactionRequest. This is also needed, as switching from three phase- to one phase charging is not always possible and the transaction needs to start at the right phase.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, External Trigger</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS requests a Charging Station to remotely start a transaction by sending a RequestStartTransactionRequest with a ChargingProfile with purpose TxProfile.
+2. The Charging Station responds with a RequestStartTransactionResponse indicating that it is able to start the transaction and will use the ChargingProfile.
+3. The Charging Station informs the CSMS that a transaction has started by sending a TransactionEventRequest (eventType = Started) message.
+4. The transaction is started in the same way as described in E. Transaction.
+5. The Charging Station sends a TransactionEventRequest (eventType = Updated) to inform the CSMS that it is charging.
+6. The Charging Station continues the regular smart charging session, following the set ChargingProfiles.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Functional Block Smart Charging is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station Successfully charges taking into account the provided ChargingProfile.
+Failure postcondition:
+The transaction is not started.
+The Charging Station Unsuccessfully charges taking into account the provided ChargingProfile.</td></tr></table>
+
+
+Figure 104. Sequence Diagram: Remote Start Transaction with Charging Profile
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows: TxStartPoint: EVConnected, Authorized, DataSigned, PowerPathClosed, EnergyTransfer This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use case: E01 - Start Transaction options. When a ChargingProfile with purpose TxProfile is provided as part of a RequestStartTransactionRequest, then a transactionId cannot be provided in the ChargingProfile, because it is not known at the time.</td></tr></table>
+
+# K05 - Remote Start Transaction with Charging Profile - Requirements
+
+Table 168. K05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K05.FR.01</td><td></td><td>The CSMS MAY include a ChargingProfile in a RequestStartTransactionRequest.</td><td></td></tr><tr><td>K05.FR.02</td><td>K05.FR.01</td><td>The Purpose of the ChargingProfile SHALL always be TxProfile.</td><td></td></tr><tr><td>K05.FR.03</td><td>K05.FR.01 AND NOT K05.FR.04</td><td>The Charging Station SHALL use the given profile to calculate its composite schedule.</td><td></td></tr><tr><td>K05.FR.04</td><td>If a Charging Station without support for Smart Charging receives a RequestStartTransactionRequest with a ChargingProfile.</td><td>The Charging Station SHALL ignore the specified ChargingProfile.</td><td>The device model variable SmartChargingCtrl.Enabled tells CSMS whether smart charging is supported.</td></tr><tr><td>K05.FR.05</td><td>If a Charging Station with support for Smart Charging receives a RequestStartTransactionRequest with an invalid ChargingProfile.</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected and optionally with reasonCode = "InvalidProfile" or "InvalidSchedule".</td><td>The device model variable SmartChargingCtrl.Enabled tells CSMS whether smart charging is supported.</td></tr></table>
+
+# K06 - Offline Behavior Smart Charging During Transaction
+
+Table 169. K06 - Offline Behavior Smart Charging During Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Offline Behavior Smart Charging During Transaction</td></tr><tr><td>2</td><td>ID</td><td>K06</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Charging Station to continue to use the current ChargingProfile for the duration of the transaction while it is Offline.</td></tr><tr><td>4</td><td>Description</td><td>If a Charging Station goes Offline after having received a transaction-specific ChargingProfile with purpose TxProfile, then it continues to use this profile for the duration of the transaction.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a SetChargingProfileRequest to the Charging Station with a TxProfile.
+2. The Charging Station responds with a SetChargingProfileResponse.
+3. While charging is in progress the EVSE will continuously adapt the maximum current or power according to the installed ChargingProfiles.
+4. The Charging Station is Offline and operates stand-alone.
+5. While charging is in progress the EVSE will continuously adapt the maximum current or power according to the already installed ChargingProfiles.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+The Functional Block Smart Charging is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station continues to use the charging profiles which are available.
+Failure postcondition:
+n/a</td></tr></table>
+
+
+Figure 105. Sequence Diagram: Offline Behavior Smart Charging
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# K06 - Offline Behavior Smart Charging During Transaction - Requirements
+
+Table 170. K06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>K06.FR.01</td><td>If the Charging Station goes Offline after having received a transaction-specific ChargingProfile with purpose TxProfile.</td><td>The Charging Station SHALL continue to use this profile for the duration of the transaction.</td></tr><tr><td>K06.FR.02</td><td>If the Charging Station goes Offline, without having any charging profiles.</td><td>The Charging Station SHALL execute the transaction as if no constraints apply.</td></tr></table>
+
+# K07 - Offline Behavior Smart Charging at Start of Transaction
+
+Table 171. K07 - Offline Behavior Smart Charging at Start of Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Offline Behavior Smart Charging at Start of Transaction</td></tr><tr><td>2</td><td>ID</td><td>K07</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Charging Station to continue to use a ChargingProfile for a transaction which is started Offline.</td></tr><tr><td>4</td><td>Description</td><td>By setting a TxDefaultProfile on a Charging Station, the CSMS can assure that any transaction, which is started while the communication with the CSMS is Offline, uses this profile.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a SetChargingProfileRequest to the Charging Station with a TxDefaultProfile.
+2. The Charging Station responds with a SetChargingProfileResponse.
+3. The Charging Station goes Offline and operates stand-alone.
+4. The Charging Station allows automatic authorization of any presented IdToken by either:
+a. The Local Authorization List; a list of identifiers that can be synchronized with the CSMS.
+b. Authorization Cache entries; which autonomously maintains a record of previously presented identifiers that have been successfully authorized by the CSMS. (Successfully meaning: a response received on a message containing an IdToken).
+c. Configuration Variable: OfflineTxForUnknownIdEnabled = TRUE
+5. The transaction is started in the same way as described in E. Transactions.
+6. While charging is in progress the EVSE will continuously adapt the maximum current or power according to the already installed ChargingProfiles.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station is Offline.
+The Functional Block Smart Charging is installed.
+The IdToken is known in the Local Authorization List, the IdToken is known in the Authorization Cache, or unknown offline authorization is enabled.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station uses the installed TxDefaultProfile which are available for the Offline started transaction.
+Failure postcondition:
+n/a</td></tr></table>
+
+
+Figure 106. Sequence Diagram: Offline Behavior Smart Charging
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>See section Combining Charging Profile Purposes for a description on how to combine different charging profile purposes.</td></tr></table>
+
+# K07 - Offline Behavior Smart Charging at Start of Transaction - Requirements
+
+Table 172. K07 - Requirements
+Table 173. K08 - Get Composite Schedule
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K07.FR.01</td><td>If a Charging Station goes Offline before a transaction is started or before a transaction-specific ChargingProfile with purpose TxProfile was received.</td><td>The Charging Station SHALL use the charging profiles which are available.</td><td>With purpose TxDefaultProfile for the duration of the current transaction only.</td></tr></table>
+
+# K08 - Get Composite Schedule
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Composite Schedule</td></tr><tr><td>2</td><td>ID</td><td>K08</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objective(s)</td><td>To request the Charging Station to report the composite charging schedule.</td></tr><tr><td>4</td><td>Description</td><td>This use cases describes how the CSMS requests the Charging Station to report the Composite Charging Schedule, as calculated by the Charging Station, by sending GetCompositeScheduleRequest.
+The CompositeSchedule is the result of the calculation of all active schedules and possible local limits present in the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS requests the Charging Station to report the Composite Charging Schedule by sending a GetCompositeScheduleRequest.
+2. The Charging Station calculates the schedule.
+3. The Charging Station responds with a GetCompositeScheduleResponse with the status and ChargingSchedule.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Functional Block Smart Charging is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The CSMS Successfully received the composite schedule from the Charging Station.
+Failure postcondition:
+The CSMS did not receive the composite schedule from the Charging Station.</td></tr></table>
+
+
+Figure 107. Sequence Diagram: Get Composite Schedule
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Please note that the charging schedule sent by the Charging Station is only indicative for that point in time. This schedule might change over time due to external causes (e.g. local balancing based on grid connection capacity is active and one EVSE becomes available).The Composite Schedule that will guide the charging level is a combination of the prevailing Charging Profiles of the different chargingProfilePurposes.This Composite Schedule is calculated by taking the minimum value for each time interval (see: Smart Charging signals to a Charging Station from multiple actors). Time intervals do not have to be of fixed length, nor do they have to be the same for every charging profile purpose. This means that a resulting Composite Schedule MAY contain intervals of different lengths.The reported schedule, in GetCompositeScheduleResponse, is the result of the calculation of all active schedules and possible local limits present in the Charging Station.The composite schedule reports the expected power or current the Charging Station expects to consume from the grid, for the requested EVSE, during the requested time period.When requested for evseid=0, the Charging Station will calculate the total expected consumption for the grid connection.</td></tr></table>
+
+# K08 - Get Composite Schedule - Requirements
+
+Table 174. K08 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>K08.FR.01</td><td></td><td>The CSMS MAY request the Charging Station to report the CompositeSchedule by sending GetCompositeScheduleRequest.</td></tr><tr><td>K08.FR.02</td><td>Upon receipt of GetCompositeScheduleRequest.</td><td>The Charging Station SHALL calculate the scheduled time intervals, from the moment of message receipt up to the Duration (in seconds) and send them to the CSMS.</td></tr><tr><td>K08.FR.03</td><td>If the evseld in the GetCompositeScheduleRequest is set to '0'</td><td>The Charging Station SHALL report the total expected power or current the Charging Station expects to consume from the grid during the requested time period.</td></tr><tr><td>K08.FR.04</td><td></td><td>At any point in time, the available power or current in the CompositeSchedule, which is the result of merging the schedules of charging profiles ChargingStationMaxProfile, ChargingStationExternalConstraints and TxDefaultProfile (or TxProfile), SHALL be less than or equal to lowest value of available power or current in any of the merged schedules.</td></tr><tr><td>K08.FR.05</td><td>If the Charging Station is not able to report the requested schedule, for instance if the evseld is unknown</td><td>The Charging Station SHALL respond with the status Rejected.</td></tr><tr><td>K08.FR.06</td><td>K08.FR.02 AND When there is no transaction active on an EVSE</td><td>The Charging Station SHALL calculate the CompositeSchedule as if there is a transaction ongoing on the EVSE that is using the TxDefaultProfile (if this profile purpose is set)</td></tr><tr><td>K08.FR.07</td><td>When receiving a GetCompositeScheduleRequest with a chargingRateUnit, which is not configured in the configuration variable ChargingScheduleChargingRateUnit</td><td>The Charging Station SHALL respond with GetCompositeScheduleResponse with status Rejected.</td></tr></table>
+
+# K09 - Get Charging Profiles
+
+Table 175. K09 - Get Charging Profiles
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Charging Profile</td></tr><tr><td>2</td><td>ID</td><td>K09</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objectives</td><td>To enable the CSMS to view the Charging Schedules/limits installed in a Charging Station, these can be installed by the CSMS or some other source.</td></tr><tr><td>4</td><td>Description</td><td>With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1 The CSMS asks the Charging Station for the installed charging profiles by sending a GetChargingProfilesRequest message.
+2 The Charging Station responds, indicating if it can report Charging Schedules by sending a GetChargingProfilesResponse message.
+3 Charging Station sends a number of ReportChargingProfilesRequest messages to CSMS.
+4 The CSMS acknowledges reception of the reports by sending a ReportChargingProfilesResponse to the Charging Station for every ReportChargingProfilesRequest.</td></tr><tr><td>5</td><td>Prerequisites</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS knows which charging profiles have been installed in the Charging Station that match the requested parameters.</td></tr></table>
+
+
+Figure 108. Sequence diagram of the use case "Get Charging Profiles"
+
+<table><tr><td>7</td><td>Error Handling</td><td>When the Charging Station has no charging profiles that match the parameters in the GetChargingProfilesRequest the Charging Station SHALL respond with: NoProfiles.</td></tr><tr><td>8</td><td>Remarks</td><td>The charging profiles report can be split over multiple ReportChargingProfilesRequest messages, this can be because charging profiles for different charging sources need to be reported, or because there is just to much data for one message. To indicate that more reports will follow the flag tbc can be used.</td></tr></table>
+
+# K09 - Get Charging Profiles - Requirements
+
+Table 176. K09 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K09.FR.01</td><td>When requestId is set in the GetChargingProfilesRequest</td><td>The Charging Station SHALL set the requestId in every ReportChargingProfilesRequest that is sent as a result of this GetChargingProfilesRequest.</td><td></td></tr><tr><td>K09.FR.02</td><td>When the charging profiles are reported in more than one ReportChargingProfilesRequest</td><td>The Charging Station SHALL set the tbc flag to true for all ReportChargingProfilesRequest messages except the last.</td><td></td></tr><tr><td>K09.FR.03</td><td></td><td>The CSMS SHALL specify in chargingProfile criteria in GetChargingProfilesRequest either: - a (list of) chargingProfileId(s) OR - one or more of the fields stackLevel, chargingLimitSource, chargingProfilePurpose.</td><td>These fields are filter values of equal importance, but because a chargingProfileId uniquely identifies a charging profile, the other fields are not needed if chargingProfiles are used.</td></tr><tr><td>K09.FR.04</td><td>If evseld is set to a value greater than 0 in the GetChargingProfilesRequest</td><td>The Charging Station SHALL report the installed charging profiles for the specified EVSE that match all fields in chargingProfile.</td><td></td></tr><tr><td>K09.FR.05</td><td>If evseld is set to 0 in GetChargingProfilesRequest</td><td>The Charging Station SHALL only report charging profiles installed on the Charging Station itself (the grid connection) that match all fields in chargingProfile.</td><td>EVSE #0 can have a ChargingStation MaxProfile, ChargingStation ExternalConstraints or a TxDefaultProfile. Note, that a TxDefaultProfile is not applied to EVSE #0 but to all individual EVSEs (see K01.FR.14).</td></tr><tr><td>K09.FR.06</td><td>If evseld is NOT set in the GetChargingProfilesRequest</td><td>The Charging Station SHALL report all installed charging profiles that match all fields in chargingProfile.</td><td></td></tr></table>
+
+# K10 - Clear Charging Profile
+
+Table 177. K10 - Clear Charging Profile
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Clear Charging Profile</td></tr><tr><td>2</td><td>ID</td><td>K10</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objective(s)</td><td>To clear some or all of the charging profiles.</td></tr><tr><td>4</td><td>Description</td><td>If the CSMS wishes to clear some or all of the charging profiles that were previously sent to the Charging Station, then the CSMS sends a ClearChargingProfileRequest to the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a ClearChargingProfileRequest to the Charging Station.
+2. The Charging Station responds with a ClearChargingProfileResponse specifying whether it was able to process the request in the status.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>One or more ChargingProfiles are installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The requested charging profiles are Successfully cleared.
+Failure postcondition:
+The requested charging profiles are not cleared, as no ChargingProfile is found.</td></tr></table>
+
+
+Figure 109. Sequence Diagram of the use case "Clear Charging Profile"
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# K10 - Clear Charging Profile - Requirements
+
+Table 178. K10 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K10.FR.01</td><td>If the Charging Station does not have any matching ChargingProfile.</td><td>Upon receipt of a ClearChargingProfileRequest, the Charging Station SHALL respond with the status Unknown.</td><td></td></tr><tr><td>K10.FR.02</td><td></td><td>The CSMS SHALL either specify a chargingProfile.id OR include one or more of the fields stackLevel, evseld and chargingProfilePurpose in the ClearChargingProfileRequest to specify which Charging Profiles need to be cleared.</td><td></td></tr><tr><td>K10.FR.03</td><td>Upon receipt of a ClearChargingProfileRequest with a specified chargingProfileId AND the chargingProfilePurpose of the referenced ChargingProfile is NOT ChargingStationExternalConstraints</td><td>The Charging Station SHALL clear the Charging Profile with the matching id and respond with a ClearChargingProfileResponse message with status = Accepted.</td><td></td></tr><tr><td>K10.FR.04</td><td>NOT K10.FR.03 AND NOT K10.FR.08 AND Upon receipt of a ClearChargingProfileRequest, with optional values for evseld, chargingProfilePurpose, stackLevel</td><td>The Charging Station SHALL clear the ChargingProfile(s) that match (as logical AND) the values in the request, except those for that have ChargingProfile = ChargingStationExternalConstraints and respond with a ClearChargingProfileResponse message with status = Accepted.</td><td></td></tr><tr><td>K10.FR.05</td><td>After clearing one or more Charging Profiles.</td><td>The Charging Station SHALL recalculate its composite schedule and set the resulting maximum power/current values to all ongoing transactions.</td><td></td></tr><tr><td>K10.FR.06</td><td></td><td>The CSMS SHALL NOT set chargingProfilePurpose to ChargingStationExternalConstraints in a ClearChargingProfileRequest.</td><td></td></tr><tr><td>K10.FR.07</td><td>K10.FR.05 AND the cleared profile has chargingProfilePurpose = TxDefaultProfile</td><td>The Charging Station SHALL continue any active transaction, that started with a TxDefaultProfile, as if it was started without a TxDefaultProfile.</td><td></td></tr><tr><td>K10.FR.08</td><td>Upon receipt of a ClearChargingProfileRequest, with optional values for evseld, chargingProfilePurpose, stackLevel AND the matched ChargingProfile(s) all have ChargingProfile = ChargingStationExter nalConstraints</td><td>The Charging Station SHALL respond with a ClearChargingProfileResponse message with status = Unknown.</td><td>Charging profiles for external constraints are disregarded by ClearChargingProfile message.</td></tr><tr><td>K10.FR.09</td><td>Upon receipt of a ClearChargingProfileRequest with a specified chargingProfileId AND the chargingProfilePurpose of the referenced ChargingProfile = ChargingStationExter nalConstraints</td><td>The Charging Station SHALL respond with a ClearChargingProfileResponse message with status = Unknown.</td><td>Charging profiles for external constraints are disregarded by ClearChargingProfile message.</td></tr></table>
+
+# 5.2. External Charging Limit based Smart Charging
+
+# K11 - Set / Update External Charging Limit With Ongoing Transaction
+
+Table 179. K11 - Set / update external charging limit with ongoing transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set / Update External Charging Limit With Ongoing Transaction</td></tr><tr><td>2</td><td>ID</td><td>K11</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objectives</td><td>To inform the CSMS of a charging schedule or charging limit imposed by an External Control System on the Charging Station with ongoing transaction(s).</td></tr><tr><td>4</td><td>Description</td><td>An External Control System sends a charging limit/schedule to a Charging Station. This limit is sent to the CSMS.</td></tr><tr><td></td><td>Actors</td><td>External Control System, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. External control system sends charging limit/schedule to Charging Station.
+2. Optional: Charging Station calculates new charging schedule.
+3. Charging Station adjusts the charging speed of the ongoing transaction(s).
+4. If the charging limit changed by more than: LimitChangeSignificance, the Charging Station sends a NotifyChargingLimitRequest message to CSMS with optionally the set charging limit/schedule.
+5. The CSMS responds with NotifyChargingLimitResponse to the Charging Station.
+6. If the charging rate changes by more than: LimitChangeSignificance, the Charging Station sends a TransactionEventRequest message to inform the CSMS.
+7. The CSMS responds with TransactionEventResponse to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station is not in error state.
+An external system can set/clear a charging limit/schedule on the Charging Station via another connection than OCPP.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The ongoing transaction will be limited by the received charging limit from the external system.
+The CSMS is informed of the new limit/schedule imposed by the external system.</td></tr></table>
+
+
+Figure 110. Sequence diagram of the use case "Setting / Updating External Charging Limit with Ongoing Transaction"
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The external system could, for example, use IEC 61850 [IEC61850-7-420] or OpenADR [OPENADR] to communicate the grid limit to the Charging Station, but this could be any protocol. Furthermore, an example of an external system is given, in this case a DSO that might set an external charging limit in case of grid problems, but this could be any other external system or reason to set a charging limit.</td></tr></table>
+
+# K11 - Set / Update External Charging Limit With Ongoing Transaction - Requirements
+
+Table 180. K11 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K11.FR.01</td><td>When an external charging limit/schedule is received during an ongoing transaction</td><td>The Charging Station SHALL NOT charge the ongoing transaction faster than this given limit/schedule.</td><td></td></tr><tr><td>K11.FR.02</td><td>K11.FR.01 AND Charging limit changed by more than: LimitChangeSignificance</td><td>The Charging Station SHALL inform the CSMS of the new charging limit/schedule imposed by the external system by sending a NotifyChargingLimitRequest.</td><td></td></tr><tr><td>K11.FR.03</td><td>K11.FR.02ANDEnableNotifyChargingLimitWithSchedules is true</td><td>The NotifyChargingLimitRequest SHALL contain the charging limits/schedules as set by the external system.</td><td></td></tr><tr><td>K11.FR.04</td><td>K11.FR.01ANDCharging rate changed by more than:LimitChangeSignifica nce</td><td>The Charging Station SHALL send a TransactionEventRequest message to the CSMS with trigger = ChargingRateChanged</td><td></td></tr><tr><td>K11.FR.05</td><td>K11.FR.02</td><td>The Charging Station SHALL NOT set the chargingLimitSource to CSO in the NotifyChargingLimitRequest.</td><td></td></tr><tr><td>K11.FR.06</td><td>When an external charging limit/schedule is received</td><td>The Charging Station SHALL use purpose ChargingStationExternalConstraints when reporting about this limit (e.g. in a ReportChargingProfilesRequest).</td><td>It is RECOMMENDED to use negative values for the id of a ChargingStationExter nalConstraints profile, to minimize the risk of a clash with an id that CSMS might use for a (future) charging profile.</td></tr></table>
+
+# K12 - Set / Update External Charging Limit Without Ongoing Transaction
+
+Table 181. K12 - Set / update external charging limit without ongoing transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set / Update External Charging Limit Without Ongoing Transaction</td></tr><tr><td>2</td><td>ID</td><td>K12</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objectives</td><td>To inform the CSMS of a charging schedule or charging limit imposed by an external system on the Charging Station for new transactions or on the grid connection.</td></tr><tr><td>4</td><td>Description</td><td>An External Control System sends a charging limit to a Charging Station. This limit is sent to the CSMS.</td></tr><tr><td></td><td>Actors</td><td>External Control System, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. External Control System sends a charging limit to Charging Station (not during a transaction).
+2. Optional: Charging Station calculates new charging schedule.
+3. Charging Station adjusts the charging speed.
+4. If the charging limit changed by more than: LimitChangeSignificance, the Charging Station sends a NotifyChargingLimitRequest message to CSMS with optionally the set charging limit/schedule.
+5. The CSMS responds with a NotifyChargingLimitResponse to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station is not in error state.
+An external system that can set/clear a charging limit/schedule on the Charging Station via another connection than OCPP.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>New transactions will be limited by the received charging limit from the external system.
+The CSMS is informed of the new limit/schedule imposed by the external system.</td></tr></table>
+
+
+Figure 111. Sequence diagram of the use case "Set / Update External Charging Limit Without Ongoing Transaction"
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The external system could, for example, use IEC 61850 [IEC61850-7-420] or OpenADR [OPENADR] to communicate the grid limit to the Charging Station, but this could be any protocol. Furthermore, an example of an external system is given, in this case a DSO that might set an external charging limit in case of grid problems, but this could be any other external system or reason to set a charging limit.</td></tr></table>
+
+# K12 - Set / Update External Charging Limit Without Ongoing Transaction - Requirements
+
+Table 182. K12 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K12.FR.01</td><td>When an external charging limit/schedule is received while no transactions are ongoing</td><td>The total load of all EVSEs SHALL NOT exceed this given limit.</td><td></td></tr><tr><td>K12.FR.02</td><td>K12.FR.01 AND Charging limit changed by more than: LimitChangeSignificance</td><td>The Charging Station SHALL inform the CSMS of the new charging limit/schedule imposed by the external system by sending a NotifyChargingLimitRequest.</td><td></td></tr><tr><td>K12.FR.03</td><td>K12.FR.02 AND EnableNotifyCharging LimitWithSchedules is true</td><td>The NotifyChargingLimitRequest SHALL contain the charging limit/schedule as set by the external system.</td><td></td></tr><tr><td>K12.FR.04</td><td>K12.FR.02</td><td>The Charging Station SHALL NOT set the chargingLimitSource to CSO in the NotifyChargingLimitRequest.</td><td></td></tr><tr><td>K12.FR.05</td><td>When an external charging limit/schedule is received</td><td>The Charging Station SHALL use purpose ChargingStationExternalConstraints when reporting about this limit (e.g. in a ReportChargingProfilesRequest).</td><td>It is RECOMMENDED to use negative values for the id of a ChargingStationExter nalConstraints profile, to minimize the risk of a clash with an id that CSMS might use for a (future) charging profile.</td></tr></table>
+
+# K13 - Reset / Release External Charging Limit
+
+Table 183. K13 - Reset / Release External Charging Limit
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reset / Release External Charging Limit</td></tr><tr><td>2</td><td>ID</td><td>K13</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objectives</td><td>To release a charging limit that was previously imposed.</td></tr><tr><td>4</td><td>Description</td><td>An external control system sends a signal to release a previously imposed charging limit to a Charging Station. The Charging Station notifies the CSMS about this.</td></tr><tr><td></td><td>Actors</td><td>External control system, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. External control system release/removes a charging limit/schedule on the Charging Station
+2. When a transaction is ongoing, the Charging Station calculates the new Charging Schedule and adjusts charging speed.
+3. The Charging Station sends a ClearedChargingLimitRequest to notify the CSMS.
+4. The CSMS acknowledges with a ClearedChargingLimitResponse to the Charging Station.
+5. When the change has impact on an ongoing charging transaction and is more than: LimitChangeSignificance, the Charging Station sends a TransactionEventRequest to notify the CSMS.
+6. The CSMS acknowledges with a TransactionEventResponse to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Previously, a charging limit was sent to the Charging Station under consideration.
+An external system that can set/clear a charging limit/schedule on the Charging Station via another connection than OCPP.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The previously received charging limit is not limiting charging anymore.</td></tr></table>
+
+
+Figure 112. Sequence diagram of the use case "Release / Reset External Charging Limit"
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The external system could, for example, IEC 61850 [IEC61850-7-420] or OpenADR [OPENADR] to release the grid limit, but this could be any protocol. Furthermore, an example of an external system is given, in this case a DSO that might set an external charging limit in case of grid problems, but this could be any other external system or reason to set a charging limit.</td></tr></table>
+
+# K13 - Reset / Release External Charging Limit - Requirements
+
+Table 184. K13 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td></tr><tr><td>K13.FR.01</td><td>A transaction is ongoing AND External charging limit is released/removed</td><td>The Charging Station SHALL NOT limit charging anymore based on the previously received limit.</td></tr><tr><td>K13.FR.02</td><td>K13.FR.01</td><td>The Charging Station SHALL notify the CSMS by sending a ClearedChargingLimitRequest message.</td></tr><tr><td>K13.FR.03</td><td>K13.FR.01 AND Charging rate changed by more than: LimitChangeSignificance</td><td>The Charging Station SHALL send a TransactionEventRequest message to the CSMS with trigger = ChargingRateChanged.</td></tr></table>
+
+# K14 - External Charging Limit with Local Controller
+
+Table 185. K14 - External Charging Limit with Local Controller
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Handle external charging limit with a local controller</td></tr><tr><td>2</td><td>ID</td><td>K14</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objective(s)</td><td>To adjust the charging limits according to the External Control System requirements.</td></tr><tr><td>4</td><td>Description</td><td>An external control system sends a charging limit to the Local Controller. The Local Controller notifies the CSMS, calculates the new charging schedules and sends a SetChargingProfileRequest messages to all Charging Stations for which the charging profile has changed.</td></tr><tr><td></td><td>Actors</td><td>External control system, Local Controller, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. External control system sends a charging limit/schedule to Local Controller.
+2. Local Controller sends a NotifyChargingLimitRequest message to the CSMS.
+3. Local Controller calculates new Charging Profiles for all connected Charging Stations.
+4. Local Controller sends a SetChargingProfileRequest message to all Charging Stations for which the charging profile has changed.
+5. External control system sends a charging limit/schedule to Local Controller.
+6. Local Controller sends a ClearedChargingLimitRequest message to the CSMS.
+7. Local Controller calculates new Charging Profiles for all connected Charging Stations.
+8. Local Controller sends a ClearChargingProfileRequest messages to all affected Charging Stations.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Ongoing transaction(s).
+An external system that can set/clear a charging limit/schedule on Local Controller via another connection than OCPP.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The ongoing transactions will be limited by the received charging limit from the external system.
+The CSMS is informed of the new limit/schedule imposed by the external system.
+Failure postcondition:
+The CSMS is not informed about the changed charging limit.
+The External Control System is not able to change the charging limit.</td></tr></table>
+
+
+Figure 113. Sequence Diagram: External Charging Limit with Local Controller.
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# K14 - External Charging Limit with Local Controller - Requirements
+
+Table 186. K14 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>K14.FR.01</td><td>When an external charging limit/schedule is received</td><td>The total load of all Charging Stations SHALL NOT exceed this given limit.</td></tr><tr><td>K14.FR.02</td><td>K14.FR.01 AND Charging limit changed by more than: LimitChangeSignificance</td><td>The Local Controller SHALL inform the CSMS of the new charging limit/schedule imposed by the external system by sending a NotifyChargingLimitRequest.</td></tr><tr><td>K14.FR.03</td><td>When an external charging limit/schedule is released</td><td>The local controller SHALL notify the CSMS by sending a ClearedChargingLimitRequest.</td></tr><tr><td>K14.FR.04</td><td>K14.FR.03</td><td>The local controller SHALL clear the hard limit on Charging Stations by sending a ClearChargingProfileRequest message to the Charging Stations.</td></tr><tr><td>K14.FR.05</td><td>When the Local Controller receives an external charging limit/schedule</td><td>It SHALL send a SetChargingProfileRequest to all Charging Stations for which the charging profile has changed.</td></tr><tr><td>K14.FR.06</td><td>K14.FR.05</td><td>The Local Controller SHALL NOT set chargingProfilePurpose to ChargingStationExternalConstraints.</td></tr></table>
+
+# 5.3. ISO 15118 based Smart Charging
+
+# K15 - Charging with load leveling based on High Level Communication
+
+Table 187. K15 - Charging with load leveling based on High Level Communication
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Charging with load leveling based on High Level Communication.</td></tr><tr><td>2</td><td>ID</td><td>K15</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 E1 AC Charging with load leveling based on High Level Communication, and E4 DC charging with load leveling based on High Level Communication.</td></tr><tr><td>3</td><td>Objectives</td><td>See ISO15118-1, use case Objective E1, page 29.</td></tr><tr><td>4</td><td>Description</td><td>See ISO15118-1, use case Description E1, page 29.</td></tr><tr><td>5</td><td>Actors</td><td>EV, Charging Station, CSMS.</td></tr><tr><td>6</td><td>Combined scenario description</td><td>1. The EV sends a ChargeParameterDiscoveryReq message to the Charging Station.
+2. The Charging Station sends a NotifyEVChargingNeedsRequest message to the CSMS.
+3. The CSMS sends a NotifyEVChargingNeedsResponse message to the Charging Station.
+4. The CSMS sends a SetChargingProfileRequest message to the Charging Station.
+5. The Charging Station sends a SetChargingProfileResponse message to the CSMS.
+6. The Charging Station responds to the EV with a ChargeParameterDiscoveryRes message to the EV.
+7. The EV sends a PowerDeliveryReq message to the Charging Station with ChargeProgress=Start. This marks the point in time when the EVSE provides voltage to its output power outlet and the EV can start to recharge its battery.
+8. The contactor is closed.
+9. The transaction is updated with a TransactionEventRequest message.
+10. A PowerdeliveryRes message is sent to the EV.
+11. Optionally, the Charging Station sends a NotifyEVChargingScheduleRequest message to the CSMS.</td></tr><tr><td>7</td><td>Prerequisites</td><td>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.</td></tr><tr><td>8</td><td>Postcondition(s)</td><td>See ISO15118-1, use case End conditions E1, page 29.</td></tr></table>
+
+
+Figure 114. Sequence Diagram: Charging with load leveling based on High Level Communication
+
+<table><tr><td>9</td><td>Error handling</td><td>The Charging Station needs to use the information from the SetChargingProfileRequest message to create the response to the ISO 15118 ChargeParameterDiscoveryReq towards the EV. This message has a timeout of 60 seconds, which means the SetChargingProfileRequest has to be sent well within 60 seconds after receiving the NotifyEVChargingNeedsRequest. If the Charging Station does not receive the SetChargingProfileRequest in time or when the NotifyEVChargingNeedsResponse has status = Processing, then the Charging Station will return a schedule in ChargeParameterDiscoverRes that matches the capabilities of the EVSE. When CSMS sends the SetChargingProfileRequest at a later time, then this will trigger a renegotiation according to use case K16 - Renegotiation initiated by CSMS.</td></tr><tr><td>10</td><td>Remark(s)</td><td>Signed SalesTariffs are currently not supported. If these are needed please use P01 - Data Transfer to the Charging Station to send these to the Charging Station.</td></tr></table>
+
+# K15 - Charging with load leveling based on High Level Communication - Requirements
+
+Table 188. K15 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K15.FR.01</td><td>When the Charging Station receives charging needs from the EV</td><td>The Charging Station SHALL send a NotifyEVChargingNeedsRequest to the CSMS.</td><td></td></tr><tr><td>K15.FR.02</td><td>K15.FR.01</td><td>In response to a NotifyEVChargingNeedsRequest the CSMS SHALL send a NotifyEVChargingNeedsResponse.</td><td></td></tr><tr><td>K15.FR.03</td><td>K15.FR.02</td><td>If the CSMS is able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Accepted'.</td><td></td></tr><tr><td>K15.FR.04</td><td>K15.FR.02</td><td>If the CSMS is not able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Rejected'.</td><td></td></tr><tr><td>K15.FR.05</td><td>K15.FR.02</td><td>If the CSMS is able to provide a charging schedule; but needs processing time, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Processing'.</td><td>The Charging Station does not have to wait for the SetChargingProfileRequest. CSMS will send it later and trigger a renegotiation as per use case K16.</td></tr><tr><td>K15.FR.06</td><td></td><td>A NotifyEVChargingNeedsRequest SHALL contain either ACChargingParameters or DCChargingParameters.</td><td></td></tr><tr><td>K15.FR.07</td><td>K15.FR.03 or K15.FR.05</td><td>The CSMS SHALL send a SetChargingProfileRequest with chargingProfilePurpose = TxProfile and a transactionId and at most three chargingSchedule and optional salesTariff elements, that each contain no more periods than specified by maxScheduleTuples in NotifyEVChargingNeedsRequest and by device model variable SmartChargingCtrlPeriodsPerSchedule.</td><td>The Charging Station will calculate the composite schedule(s) for the EVSE (taking into account a ChargingStationMaxProfile or ChargingStationExternalConstraints if present) and will convert that to the SASScheduleList format for ISO 15118.</td></tr><tr><td>K15.FR.08</td><td>K15.FR.01</td><td>The CSMS SHOULD send a SetChargingProfileRequest to the Charging Station within 60 seconds.</td><td>This is to satisfy the ISO 15118 ChargeParameterDiscoveryReq timeout.</td></tr><tr><td>K15.FR.09</td><td>K15.FR.07 AND EV returns a charging profile</td><td>Charging Station SHALL verify that provided charging profile is within boundaries of the ChargingSchedule from CSMS.</td><td>In ISO 15118 EV can sent its charging profile as part of PowerDeliveryReq.</td></tr><tr><td>K15.FR.10</td><td>K15.FR.09</td><td>Charging Station SHALL send the EV charging profile in a NotifyEVChargingScheduleRequest message to CSMS.</td><td></td></tr><tr><td>K15.FR.11</td><td>K15.FR.10 AND EV charging profile is within limits of CSMS ChargingSchedule</td><td>CSMS responds with NotifyEVChargingScheduleResponse with status Accepted to Charging Station.</td><td>Note: Already checked by Charging Station, but CSMS does its own check.</td></tr><tr><td>K15.FR.12</td><td>K15.FR.10 AND EV charging profile is NOT within limits of CSMS ChargingSchedule</td><td>CSMS responds with NotifyEVChargingScheduleResponse with status Rejected to Charging Station.</td><td></td></tr><tr><td>K15.FR.13</td><td>K15.FR.12</td><td>CSMS starts new renegotiation as per use case K16.</td><td></td></tr><tr><td>K15.FR.14</td><td>K15.FR.11</td><td>The Charging Station SHOULD take the schedule from the NotifyEVChargingScheduleRequest into account when calculating the actual Composite schedule.</td><td></td></tr><tr><td>K15.FR.15</td><td>K15.FR.01 AND Charging Station is offline</td><td>The Charging Station SHALL use the TxDefaultProfile (if present) and generate a charging schedule within the limits of its composite schedule.</td><td></td></tr><tr><td>K15.FR.16</td><td>K15.FR.07</td><td>It is RECOMMENDED to configure the Charging Station, such that a TransactionEvent with idToken has been sent prior to the NotifyEVChargingNeedsRequest Message, so that CSMS can take the user into account when creating a charging schedule.</td><td></td></tr><tr><td>K15.FR.17</td><td>When Charging Station receives a SetChargingProfileRequest immediately after the transaction has started and before it has sent the NotifyEVChargingNeed sRequest to CSMS</td><td>The Charging Station SHOULD respond with SetChargingProfileResponse with status = Rejected and a statusInfo withreasonCode= InvalidMessageSeq.</td><td>CSMS sent profile too early. It does not harm if CS accepts the charging profile instead of rejecting it, as long as it sends a charging profile again when it receives the NotifyEVChargingNeedsRequest.</td></tr><tr><td>K15.FR.18</td><td>K15.FR.03 OR K15.FR.05</td><td>CSMS IS RECOMMENDED to use only one chargingSchedule in a SetChargingProfileRequest.</td><td>This ensures that there is no doubt about which schedule the EV will follow, even when no NotifyEVChargingScheduleRequest is received.</td></tr><tr><td>K15.FR.19</td><td>K15.FR.07 AND EV does not return a charging profile</td><td>Charging Station IS RECOMMENDED to return an EV charging profile as a chargingSchedule in a NotifyEVChargingScheduleRequest message to CSMS that matches the schedule that was selected by the EV (i.e. chargingSchedule.id = SAScheduleTupleld)</td><td>In ISO 15118-2 the EV charging profile and the selected schedule are returned as ChargingProfile and SAScheduleTupleld in PowerDeliveryReq.</td></tr></table>
+
+# K16 - Renegotiation initiated by CSMS
+
+Table 189. K16 - Renegotiation initiated by CSMS
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Renegotiation initiated by CSMS.</td></tr><tr><td>2</td><td>ID</td><td>K16</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objectives</td><td>To control the charging power or current of a Charging Station</td></tr><tr><td>4</td><td>Description</td><td>The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by the EV. The CSMS calculates a ChargingSchedule to stay within limits which MAY be imposed by an external system.
+Note: Description of actions between EV and Charging Station is informative only and not mandated by OCPP.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1 CSMS sends a SetChargingProfileRequest to the Charging Station.
+2 Charging Station responds with a SetChargingProfileResponse to the CSMS.
+3 When EV sends the next CurrentDemandReq (for DC) or ChargingStatusReq (for AC), the Charging Station will respond with evseNotification = ReNegotiation.
+4 EV sends a PowerDeliveryReq with chargeProgress = ReNegotiate to confirm this.
+5 Charging Station responds with a PowerDeliveryRes.
+6 EV sends a ChargeParameterDiscoveryReq.
+7 Charging Station responds with a ChargeParameterDiscoveryRes with an SAScheduleList that contains the ChargingSchedule data from the SetChargingProfileRequest.
+8 EV sends a PowerDeliveryReq with chargeProgress = Start (with an optional charging profile) to confirm this.
+9 Charging Station responds with PowerDeliveryRes and, if charging was suspended at start of the renegotiation, will resume power delivery.
+10 If EV provided a charging profile in the previous step, then Charging Station will send a NotifyEVChargingScheduleRequest to the CSMS.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging session started according to use case K15.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Charging session uses the new charging profile.</td></tr></table>
+
+
+Figure 115. Renegotiation initiated by CSMS
+
+<table><tr><td>7</td><td>Remark(s)</td><td>Signed Sales Tariffs are currently not supported. If these are needed please use P01 - Data Transfer to the Charging Station to send these to the Charging Station.</td></tr></table>
+
+# K16 - Renegotiation initiated by CSMS - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>NOTE</td></tr><tr><td>K16.FR.01</td><td>CSMS sends a new SetChargingProfileRequest</td><td>Charging Station SHALL respond with a SetChargingProfileResponse with status = Accepted.</td><td></td></tr><tr><td>K16.FR.02</td><td>K16.FR.01</td><td>Charging Station SHALL initiate schedule renegotiation with EV.</td><td>In ISO 15118 this is done by replying with EVSENotification=ReNegotiation to a CurrentDemandReq (for DC) or ChargingStatusReq (for AC) message.</td></tr><tr><td>K16.FR.03</td><td>K16.FR.02</td><td>Charging Station SHALL provide the ChargingSchedule data to the EV.</td><td>In ISO 15118 this is done in the ChargeParameterDiscoverRes message.</td></tr><tr><td>K16.FR.04</td><td>EV returns a charging profile</td><td>Charging Station SHALL verify that provided charging profile is within boundaries of the ChargingSchedule from CSMS.</td><td>In ISO 15118 EV may provide this as part of the PowerDeliveryReq message.</td></tr><tr><td>K16.FR.05</td><td>K16.FR.04</td><td>Charging Station SHALL send the EV charging profile in a NotifyEVChargingScheduleRequest message to CSMS.</td><td></td></tr><tr><td>K16.FR.06</td><td>K16.FR.05 AND EV charging profile is within limits of CSMS ChargingSchedule</td><td>CSMS responds with NotifyEVChargingScheduleResponse with status Accepted to Charging Station.</td><td>Note: Already checked by Charging Station, but CSMS does its own check.</td></tr><tr><td>K16.FR.07</td><td>K16.FR.05ANDEV charging profile is NOT within limits of CSMSChargingSchedule</td><td>CSMS responds withNotifyEVChargingScheduleResponse withstatus Rejected to Charging Station.</td><td></td></tr><tr><td>K16.FR.08</td><td>K16.FR.07</td><td>CSMS starts new renegotiation as per use case K16.</td><td></td></tr><tr><td>K16.FR.09</td><td>When the Charging Station receives charging needs from the EV</td><td>The Charging Station SHOULD NOT send a NotifyEVChargingNeedsRequest to the CSMS.</td><td>CSMS initiated the renegotiation and has just sent a new charging profile, based on the initial charging needs from EV, energy already consumed by EV and whatever information has caused CSMS to update the charging profile.In ISO 15118 charging needs are sent via ChargeParameter-DiscoveryReq.</td></tr><tr><td>K16.FR.10</td><td>K16.FR.04</td><td>The Charging Station SHOULD take the schedule from the NotifyEVChargingScheduleRequest into account when calculating the actual Composite schedule.</td><td></td></tr><tr><td>K16.FR.11</td><td>K16.FR.02ANDcurrent or power in new charging schedule is lower than actual current or power</td><td>The Charging Station SHALL request EV to lower current or power to a value matching the new charging schedule at the first possible opportunity.</td><td>In ISO 15118 this can be communicated in CurrentDemandRes (for DC) or ChargingStatusRes (for AC).</td></tr><tr><td>K16.FR.12</td><td>K16.FR.09ANDCharging Station sends a NotifyEVChargingNeed sRequest</td><td>The CSMS SHALL send a SetChargingProfileRequest.</td><td>This situation is not desirable, because charging profile will likely be the same as in K16.FR.01, but this is added for robustness when Charging Station is not adhering to K16.FR.09.</td></tr><tr><td>K16.FR.13</td><td>EV does not return a charging profile</td><td>Charging Station IS RECOMMENDED to return an EV charging profile as a chargingSchedule in a NotifyEVChargingScheduleRequest message to CSMS that matches the schedule that was selected by the EV (i.e.chargingSchedule.id = SAScheduleTupled)</td><td>In ISO 15118-2 the EV charging profile and the selected schedule are returned as ChargingProfile and SAScheduleTupled in PowerDeliveryReq.</td></tr></table>
+
+# K17 - Renegotiation initiated by EV
+
+Table 190. K17 - Renegotiation initiated by EV
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Renegotiation initiated by EV.</td></tr><tr><td>2</td><td>ID</td><td>K16</td></tr><tr><td></td><td>Functional block</td><td>K. Smart Charging</td></tr><tr><td>3</td><td>Objectives</td><td>To let an EV request a new charging schedule.</td></tr><tr><td>4</td><td>Description</td><td>The EV signals the Charging Station that it wants to renegotiate and it provides new charging needs, which the Charging Station sends to the CSMS. Based on this and other parameters, the CSMS calculates a new charging schedule and sends it via SetChargingProfileRequest to Charging Station, which communicates it to the EV.
+Note: Description of actions between EV and Charging Station is informative only and not mandated by OCPP.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1 When EV sends a ChargeParameterDiscoveryReq with charging needs parameters, then Charging Station sends this information in a NotifyEVChargingNeedsRequest to CSMS.
+2 CSMS responds with NotifyEVChargingNeedsResponse to Charging Station.
+3 CSMS calculates new charging schedule, that tries to accommodate the EV charging needs and still fits within the schedule boundaries imposed by other parameters.
+4 CSMS sends a SetChargingProfileRequest with the new schedule to the Charging Station.
+5 Charging Station responds with SetChargingProfileResponse with status Accepted.
+6 Charging Station sends new charging schedule to EV in a ChargeParameterDiscoveryRes message.
+7 EV sends a PowerDeliveryReq with chargeProgress = Start (with an optional charging profile) to confirm this.
+8 Charging Station responds with PowerDeliveryRes and, if charging was suspended at start of the renegotiation, will resume power delivery.
+9 If EV provided a charging profile in the previous step, then Charging Station will send a NotifyEVChargingScheduleRequest to the CSMS.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging session started according to use case K15.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Charging session uses the new charging profile.</td></tr></table>
+
+
+Figure 116. Renegotiation initiated by EV
+
+<table><tr><td>7</td><td>Remark(s)</td><td>Signed SalesTariffs are currently not supported. If these are needed please use P01 - Data Transfer to the Charging Station to send these to the Charging Station.</td></tr></table>
+
+# K17 - Renegotiation initiated by EV - Requirements
+
+Table 191. K17 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K17.FR.01</td><td>EV triggers a renegotiation and sends new charging needs</td><td>The Charging Station SHALL send a NotifyEVChargingNeedsRequest to the CSMS.</td><td></td></tr><tr><td>K17.FR.02</td><td>K17.FR.01</td><td>In response to a NotifyEVChargingNeedsRequest the CSMS SHALL send a NotifyEVChargingNeedsResponse.</td><td></td></tr><tr><td>K17.FR.03</td><td>K17.FR.02</td><td>If the CSMS is able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Accepted'.</td><td></td></tr><tr><td>K17.FR.04</td><td>K17.FR.02</td><td>If the CSMS is not able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Rejected'.</td><td></td></tr><tr><td>K17.FR.05</td><td>K17.FR.02</td><td>If the CSMS is able to provide a charging schedule; but needs processing time, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Processing'.</td><td></td></tr><tr><td>K17.FR.06</td><td></td><td>A NotifyEVChargingNeedsRequest SHALL contain either ACChargingParameters or DCChargingParameters.</td><td></td></tr><tr><td>K17.FR.07</td><td>K17.FR.03 or K17.FR.05</td><td>The CSMS SHALL send a SetChargingProfileRequest with chargingProfilePurpose = TxProfile and at most three chargingSchedule and optional salesTariff elements, that each contain no more periods than specified by maxScheduleTuples in NotifyEVChargingNeedsRequest and by device model variable SmartChargingCtrl.PeriodsPerSchedule.</td><td></td></tr><tr><td>K17.FR.08</td><td>K17.FR.01</td><td>The CSMS SHOULD send a SetChargingProfileRequest to the Charging Station within 60 seconds.</td><td>This is to satisfy the ISO 15118 ChargeParameterDiscoveryReq timeout.</td></tr><tr><td>K17.FR.09</td><td>K17.FR.07 AND EV returns a charging profile</td><td>Charging Station SHALL verify that provided charging profile is within boundaries of the ChargingSchedule from CSMS.</td><td>In ISO 15118 EV can sent its charging profile as part of PowerDeliveryReq.</td></tr><tr><td>K17.FR.10</td><td>K17.FR.09</td><td>Charging Station SHALL send the EV charging profile in a NotifyEVChargingScheduleRequest message to CSMS.</td><td></td></tr><tr><td>K17.FR.11</td><td>K17.FR.10 AND EV charging profile is within limits of CSMS ChargingSchedule</td><td>CSMS responds with NotifyEVChargingScheduleResponse with status Accepted to Charging Station.</td><td>Note: Already checked by Charging Station, but CSMS does its own check.</td></tr><tr><td>K17.FR.12</td><td>K17.FR.10 AND EV charging profile is NOT within limits of CSMS ChargingSchedule</td><td>CSMS responds with NotifyEVChargingScheduleResponse with status Rejected to Charging Station.</td><td></td></tr><tr><td>K17.FR.13</td><td>K17.FR.12</td><td>CSMS starts new renegotiation as per use case K16.</td><td></td></tr><tr><td>K17.FR.14</td><td>K17.FR.11</td><td>The Charging Station SHOULD take the schedule from the NotifyEVChargingScheduleRequest into account when calculating the actual Composite schedule.</td><td></td></tr><tr><td>K17.FR.15</td><td>K17.FR.01 AND Charging Station is offline</td><td>The Charging Station SHALL use the TxDefaultProfile (if present) and generate a charging schedule within the limits of its composite schedule.</td><td></td></tr><tr><td>K17.FR.16</td><td>K17.FR.07 EV does not return a charging profile</td><td>Charging Station IS RECOMMENDED to return an EV charging profile as a chargingSchedule in a NotifyEVChargingScheduleRequest message to CSMS that matches the schedule that was selected by the EV (i.e. chargingSchedule.id = SAScheduleTupleld)</td><td>In ISO 15118-2 the EV charging profile and the selected schedule are returned as ChargingProfile and SAScheduleTupleld in PowerDeliveryReq.</td></tr></table>
+
+# L. FirmwareManagement
+
+# 1. Introduction
+
+This Functional Block describes the functionality that enables a CSO to update the firmware of a Charging Station.
+
+When a Charging Station needs to be updated with new firmware, the CSMS informs the Charging Station of the time at which the Charging Station can start downloading the new firmware. The Charging Station SHALL notify the CSMS after each step as it downloads and installs the new firmware.
+
+# 2. Use cases & Requirements
+
+# L01 - Secure Firmware Update
+
+Table 192. L01 - Secure Firmware Update
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Secure Firmware Update</td></tr><tr><td>2</td><td>ID</td><td>L01</td></tr><tr><td></td><td>Functional block</td><td>L. Firmware Management</td></tr><tr><td>3</td><td>Objective(s)</td><td>Download and install a Secure firmware update.</td></tr><tr><td>4</td><td>Description</td><td>Illustrate how a Charging Station processes a Secure firmware update.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station, Charging Station Manufacturer</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends an Update FirmwareRequest message that contains the location of the firmware, the time after which it should be retrieved, and information on how many times the Charging Station should retry downloading the firmware.
+2. The Charging Station verifies the validity of the certificate against the Manufacturer root certificate.
+3. If the certificate is valid, the Charging Station starts downloading the firmware, and sends a FirmwareStatusNotificationRequest with status Downloading.
+If the certificate is not valid or could not be verified, the Charging Station aborts the firmware update process and sends a Update FirmwareResponse with status InvalidCertificate and a SecurityEventNotificationRequest with the security event InvalidFirmwareSigningCertificate (See part 2 appendices for the full list of security events).
+4. If the Firmware successfully downloaded, the Charging Station sends a FirmwareStatusNotificationRequest with status Downloaded.
+Otherwise, it sends a FirmwareStatusNotificationRequest with status DownloadFailed.
+5. If the verification is successful, the Charging Station sends a FirmwareStatusNotificationRequest with status Installing.
+If the verification of the firmware fails or if a signature is missing entirely, the Charging Station sends a FirmwareStatusNotificationRequest with status InvalidSignature and a SecurityEventNotificationRequest with the security event InvalidFirmwareSignature (See part 2 appendices for the full list of security events).
+6. If the installation is successful, the Charging Station sends a FirmwareStatusNotificationRequest with status Installed.
+Otherwise, it sends a FirmwareStatusNotificationRequest with status InstallationFailed.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>L02 - Non-Secure Firmware Update</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station Manufacturer provided a firmware update.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The firmware is updated and the Charging Station is in Installed status.
+Failure postconditions:
+The certificate is not valid or could not be verified and the Charging Station is in InvalidCertificate status.
+Downloading the firmware failed and the Charging Station is in DownloadFailed status.
+The verification of the firmware's digital signature failed and the Charging Station is in InvalidSignature status.
+The installation of the firmware is not successful and the Charging Station is in InstallationFailed status.</td></tr></table>
+
+
+Figure 117. Sequence diagram secure firmware upgrade (happy flow)
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>As an example in this use case the requestId = 123, but this could be any value.Measures SHOULD be taken to secure the firmware when it is stored on a server or workstation.The Charging Station has a required Configuration Variable that reports which file transfer protocols it supports: FileTransferProtocolsWhen migrating to a new version of OCPP it is RECOMMENDED to install a fallback NetworkConnectionProfile with the new configuration.The requirements for the Firmware Signing Certificate are described in the: Certificate Properties section.The manufacturer SHALL NOT use intermediate certificates for the firmware signing certificate in the Charging Station.FTP needs to be able to use Passive FTP, to be able to transverse over as much different typologies as possible.</td></tr></table>
+
+
+Figure 118. Firmware status transitions
+
+# L01 - Secure Firmware Update - Requirements
+
+Table 193. L01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>L01.FR.01</td><td>Whenever the Charging Station enters a new state in the firmware update process.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest message to the CSMS with this new status. What reason to use is described in the description of FirmwareStatusEnumType.</td><td></td></tr><tr><td>L01.FR.02</td><td>When the Charging Station enters the Invalid Certificate state in the firmware process.</td><td>The Charging Station SHALL send a SecurityEventNotificationRequest message to the CSMS with the security eventInvalidFirmwareSigningCertificate (See part 2 appendices for the full list of security events).</td><td></td></tr><tr><td>L01.FR.03</td><td>When the Charging Station enters the Invalid Signature state.</td><td>The Charging Station SHALL send a SecurityEventNotificationRequest message to the CSMS with the security eventInvalidFirmwareSigning (See part 2 appendices for the full list of security events).</td><td></td></tr><tr><td>L01.FR.04</td><td>When the Charging Station has successfully downloaded the new firmware</td><td>The signature SHALL be validated, by calculating the signature over the entire firmware file using the RSA-PSS or ECSchnorr algorithm for signing, and the SHA256 algorithm for calculating hash values.</td><td></td></tr><tr><td>L01.FR.05</td><td>L01.FR.04 AND (installDateTime is not set OR current time >= installDateTime)</td><td>The Charging Station SHALL install the new firmware as soon as it is able to.</td><td></td></tr><tr><td>L01.FR.06</td><td>L01.FR.05 AND The Charging Station has ongoing transactions AND When it is not possible to start installation of firmware while a transaction is ongoing</td><td>The Charging Station SHALL wait until all transactions have ended, before commencing installation.</td><td></td></tr><tr><td>L01.FR.07</td><td>L01.FR.06 or L01.FR.33 AND configuration variable AllowNewSessionsPendingFirmware Update is false or does not exist</td><td>The Charging Station SHALL set all EVSE that are not in use to UNAVAILABLE while the Charging Station waits for the ongoing transactions to end. Until the firmware is installed, any EVSE that becomes available SHALL be set to UNAVAILABLE.</td><td></td></tr><tr><td>L01.FR.08</td><td></td><td>It is RECOMMENDED that the firmware is sent encrypted to the Charging Station. This can either be done by using a secure protocol (such as HTTPS, SFTP, or FTPS) to send the firmware, or by encrypting the firmware itself before sending it.</td><td></td></tr><tr><td>L01.FR.09</td><td></td><td>Firmware updates SHALL be digitally protected to ensure authenticity and to provide proof of origin.</td><td>This protection is achieved by applying a digital signature over the hash value of the firmware image. Ideally, this signature is already computed by the manufacturer. This way proof of origin of the firmware image can be tracked back to the original author of the firmware.</td></tr><tr><td>L01.FR.10</td><td></td><td>Every FirmwareStatusNotificationRequest sent for a firmware update SHALL contain the same requestId as the UpdateFirmwareRequest that started this firmware update.</td><td></td></tr><tr><td>L01.FR.11</td><td></td><td>For security purposes the CSMS SHALL include the Firmware Signing certificate (see Keys used in OCPP) in the UpdateFirmwareRequest.</td><td></td></tr><tr><td>L01.FR.12</td><td></td><td>For verifying the certificate (see Certificate Hierarchy) use the rules for X.509 certificates [19]. The Charging Station MUST verify the file's digital signature using the Firmware Signing certificate.</td><td></td></tr><tr><td>L01.FR.13</td><td>When the Charging Station does not start downloading firmware, because it is busy charging or because retrieveDateTime is in the future</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status DownloadScheduled.</td><td></td></tr><tr><td>L01.FR.14</td><td>When the Charging Station enters the Download Paused state.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status DownloadPaused.</td><td>For example when the Charging Station has tasks with higher priorities.</td></tr><tr><td>L01.FR.15</td><td>When a Charging Station needs to reboot before installing the downloaded firmware.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status InstallRebooting, before rebooting.</td><td></td></tr><tr><td>L01.FR.16</td><td>L01.FR.04 AND When installDateTime is set to a time in the future</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status InstallScheduled and install the firmware at the specified installation time.</td><td></td></tr><tr><td>L01.FR.20</td><td></td><td>The field requestId in FirmwareStatusNotificationRequest is mandatory, unless status = Idle.</td><td></td></tr><tr><td>L01.FR.21</td><td>When the Charging Station receives an UpdateFirmwareRequest</td><td>The Charging Station SHALL validate the certificate before accepting the message.</td><td></td></tr><tr><td>L01.FR.22</td><td>L01.FR.21 AND the certificate is invalid</td><td>The Charging Station SHALL respond with UpdateFirmwareResponse with status InvalidCertificate.</td><td></td></tr><tr><td>L01.FR.23</td><td>When the Charging Station needs to reboot during a firmware update AND the bootloader is unable to send OCPP messages</td><td>The Charging Station MAY omit the FirmwareStatusNotificationRequest message with status Installing.</td><td></td></tr><tr><td>L01.FR.24</td><td>When a Charging Station is installing new Firmware OR is going to install new Firmware, but has received an UpdateFirmware command to install it at a later time AND the Charging Station receives a new UpdateFirmwareRequest</td><td>The Charging Station SHOULD cancel the ongoing firmware update AND respond with status AcceptedCanceled.</td><td>The Charging Station SHOULD NOT first check if the new firmware file exists, this way the CSMS will be able to cancel an ongoing firmware update without starting a new one. The Charging Station may send a FirmwareStatusNotificationRequest with status DownloadFailed or InstallationFailed for the firmware update that has now been canceled.</td></tr><tr><td>L01.FR.25</td><td>Charging Station receives a TriggerMessageRequest for FirmwareStatusNotification AND last sent FirmwareStatusNotificationRequest had status = Installed</td><td>Charging Station SHALL return a FirmwareStatusNotificationRequest with status = Idle.</td><td></td></tr><tr><td>L01.FR.26</td><td>Charging Station receives a TriggerMessageRequest for FirmwareStatusNotification AND last sent FirmwareStatusNotificationRequest had NOT status Installed</td><td>Charging Station SHALL return a FirmwareStatusNotificationRequest with the last sent status.</td><td></td></tr><tr><td>L01.FR.27</td><td>L01.FR.24 AND the Charging Station is unable to cancel the firmware installation</td><td>The Charging Station MAY respond with status = Rejected.</td><td></td></tr><tr><td>L01.FR.28</td><td>When the Charging Station has successfully installed the new firmware</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status Installed AND The Charging Station SHOULD have activated the new firmware already or do so immediately.</td><td>Activating the new firmware MAY involve an automatic reboot, but not necessarily so.</td></tr><tr><td>L01.FR.29</td><td>If the verification of the new firmware (e.g. using a checksum or some other means) fails</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status InstallVerificationFailed</td><td></td></tr><tr><td>L01.FR.30</td><td>When the Charging Station has failed all retry attempts to download the firmware.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status DownloadFailed.</td><td>A Charging Station MAY send a new Downloading status upon each retry attempt.</td></tr><tr><td>L01.FR.31</td><td>L01.FR.28</td><td>The Charging Station SHALL send a SecurityEventNotificationRequest message with type = "FirmwareUpdated".</td><td></td></tr><tr><td>L01.FR.32</td><td>When a Charging Station has successfully installed the new firmware AND the Charging Station needs to reboot before activating the new firmware</td><td>The Charging Station SHALL either: (a) send an optional FirmwareStatusNotificationRequest with status = InstallRebooting before rebooting and send a mandatory FirmwareStatusNotificationRequest with status = Installed by the newly activated firmware, or (b) only send a FirmwareStatusNotificationRequest with status set to Installed without reporting the reboot and activation of the new firmware.</td><td>Option (a) is preferred, because it notifies CSMS of an upcoming reboot of the Charging Station, and the final status = Installed is sent by the new firmware image, so that CSMS can be sure that the new firmware is active. This is not guaranteed by option (b) when rebooting of the new firmware should fail.</td></tr><tr><td>L01.FR.33</td><td>L01.FR.05 AND The Charging Station has ongoing transactions AND a reboot is needed to activate the installed firmware</td><td>The Charging Station SHALL wait until all transactions have ended, before activating the installed firmware.</td><td>E.g. in case of A/B firmware updates.</td></tr><tr><td>L01.FR.34</td><td>L01.FR.04 AND installDateTime is not set AND Charging Station is waiting for a transaction to finish</td><td>The Charging Station MAY send a FirmwareStatusNotificationRequest with status InstallScheduled.</td><td>The case where installDateTime is set is covered by L01.FR.16.</td></tr></table>
+
+# L02 - Non-Secure Firmware Update
+
+Table 194. L02 - Non-Secure Firmware Update
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Non-Secure Firmware Update</td></tr><tr><td>2</td><td>ID</td><td>L02</td></tr><tr><td></td><td>Functional block</td><td>L. Firmware Management</td></tr><tr><td>3</td><td>Objective(s)</td><td>Download and install a Non-Secure firmware update.</td></tr><tr><td>4</td><td>Description</td><td>Illustrate how a Charging Station processes a Non-Secure firmware update.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends an UpdateFirmwareRequest message that contains the location of the firmware, the time after which it should be retrieved, and information on how many times the Charging Station should retry downloading the firmware.
+2. The Charging station responds with an UpdateFirmwareResponse.
+3. The Charging station sends a FirmwareStatusNotificationRequest with status Downloading.
+4. The CSMS responds with a FirmwareStatusNotificationResponse.
+5. The Charging station sends a FirmwareStatusNotificationRequest with status Downloaded.
+6. The CSMS responds with a FirmwareStatusNotificationResponse.
+7. The Charging station sends a FirmwareStatusNotificationRequest with status Installing.
+8. The CSMS responds with a FirmwareStatusNotificationResponse.
+9. The Charging station sends a FirmwareStatusNotificationRequest with status Installed.
+10. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>L01 - Secure Firmware Update</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station Manufacturer provided a firmware update.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+Firmware update was successfully installed.
+Failure postcondition:
+Firmware update failed.</td></tr></table>
+
+
+Figure 119. Sequence diagram Non-Secure firmware upgrade
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Measures SHOULD be taken to secure the firmware when it is stored on a server or workstation.
+When migrating to a new version of OCPP it is RECOMMENDED to install a fallback NetworkConnectionProfile with the new configuration.
+FTP needs to be able to use Passive FTP, to be able to transverse over as much different typologies as possible.</td></tr></table>
+
+# L02 - Non-Secure Firmware Update - Requirements
+
+Table 195. L02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>L02.FR.01</td><td>Whenever the Charging Station enters a new status in the firmware update process.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest message to the CSMS with this new status.</td><td></td></tr><tr><td>L02.FR.02</td><td>When the Charging Station has successfully downloaded the new firmware AND (installDateTime is not set OR current time >= installDateTime)</td><td>The Charging Station SHALL install the new firmware as soon as it is able to.</td><td></td></tr><tr><td>L02.FR.03</td><td>L02.FR.02 AND The Charging Station has ongoing transactions AND When it is not possible to start installation of firmware while a transaction is ongoing</td><td>The Charging Station SHALL wait until all transactions have ended, before commencing installation.</td><td></td></tr><tr><td>L02.FR.04</td><td>L02.FR.03 or L02.FR.22 AND configuration variable AllowNewSessionsPendingFirmwareUpdate is false or does not exist</td><td>The Charging Station SHALL set all EVSE that are not in use to UNAVAILABLE while the Charging Station waits for the ongoing transactions to end. Until the firmware is installed, any EVSE that becomes available SHALL be set to UNAVAILABLE.</td><td></td></tr><tr><td>L02.FR.05</td><td></td><td>It is RECOMMENDED that the firmware is sent encrypted to the Charging Station. This can either be done by using a secure protocol (such as HTTPS, SFTP, or FTPS) to send the firmware, or by encrypting the firmware itself before sending it.</td><td></td></tr><tr><td>L02.FR.06</td><td></td><td>Every FirmwareStatusNotificationRequest sent for a firmware update SHALL contain the same requestId as the UpdateFirmwareRequest that started this firmware update.</td><td></td></tr><tr><td>L02.FR.07</td><td>When the Charging Station does not start downloading firmware, because it is busy charging or because retrieveDateTime is in the future</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status DownloadScheduled.</td><td></td></tr><tr><td>L02.FR.08</td><td>When the Charging Station enters the Download Paused state.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status DownloadPaused.</td><td>For example when the Charging Station has tasks with higher priorities.</td></tr><tr><td>L02.FR.09</td><td>When a Charging Station needs to reboot before installing the downloaded firmware.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status InstallRebooting, before rebooting.</td><td></td></tr><tr><td>L02.FR.10</td><td>When the Charging Station has successfully downloaded the new firmware AND installDateTime is set to time in the future</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status InstallScheduled and install the firmware at the specified installation time.</td><td></td></tr><tr><td>L02.FR.14</td><td></td><td>The field requestId in FirmwareStatusNotificationRequest is mandatory, unless status = Idle.</td><td></td></tr><tr><td>L02.FR.15</td><td>When a Charging Station is installing new Firmware OR is going to install new Firmware, but has received an UpdateFirmware command to install it at a later time AND the Charging Station receives a new UpdateFirmwareRequest</td><td>The Charging Station SHOULD cancel the ongoing firmware update AND respond with status AcceptedCanceled.</td><td>The Charging Station SHOULD NOT first check if the new firmware file exists, this way the CSMS will be able to cancel an ongoing firmware update without starting a new one.</td></tr><tr><td>L02.FR.16</td><td>Charging Station receives a TriggerMessageRequest for FirmwareStatusNotification AND last sent FirmwareStatusNotificationRequest had status = Installed</td><td>Charging Station SHALL return a FirmwareStatusNotificationRequest with status = Idle.</td><td></td></tr><tr><td>L02.FR.17</td><td>Charging Station receives a TriggerMessageRequest for FirmwareStatusNotification AND last sent FirmwareStatusNotificationRequest had NOT status Installed</td><td>Charging Station SHALL return a FirmwareStatusNotificationRequest with the last sent status.</td><td></td></tr><tr><td>L02.FR.18</td><td>L02.FR.15 AND the Charging Station is unable to cancel the firmware installation</td><td>The Charging Station MAY respond with status = Rejected.</td><td></td></tr><tr><td>L02.FR.19</td><td>When the Charging Station has failed all retry attempts to download the firmware.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status DownloadFailed.</td><td>A Charging Station MAY send a new Downloading status upon each retry attempt.</td></tr><tr><td>L02.FR.20</td><td>When the Charging Station has successfully installed and activated the new firmware</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status Installed.</td><td>Activation of the new firmware may involve a reboot.</td></tr><tr><td>L02.FR.21</td><td>When the Charging Station has successfully installed the new firmware AND the Charging Station needs to reboot before activating the new firmware</td><td>The Charging Station SHALL either: (a) send an optional FirmwareStatusNotificationRequest with status = InstallRebooting before rebooting and send a mandatory FirmwareStatusNotificationRequest with status = Installed by the newly activated firmware, or (b) only send a FirmwareStatusNotificationRequest with status set to Installed without reporting the reboot and activation of the new firmware.</td><td>Option (a) is preferred, because it notifies CSMS of an upcoming reboot of the Charging Station, and the final status = Installed is sent by the new firmware image, so that CSMS can be sure that the new firmware is active. This is not guaranteed by option (b) when rebooting of the new firmware should fail.</td></tr><tr><td>L02.FR.22</td><td>L02.FR.02 AND The Charging Station has ongoing transactions AND a reboot is needed to activate the installed firmware</td><td>The Charging Station SHALL wait until all transactions have ended, before activating the installed firmware.</td><td>E.g. in case of A/B firmware updates.</td></tr><tr><td>L02.FR.23</td><td>When the Charging Station has successfully downloaded the firmware AND installDateTime is not set AND Charging Station is waiting for a transaction to finish</td><td>The Charging Station MAY send a FirmwareStatusNotificationRequest with status InstallScheduled.</td><td>The case where installDateTime is set is covered by L02.FR.10.</td></tr></table>
+
+# L03 - Publish Firmware file on Local Controller
+
+Table 196. L03 - Publish Firmware file on Local Controller
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Publish Firmware file on Local Controller.</td></tr><tr><td>2</td><td>ID</td><td>L03</td></tr><tr><td></td><td>Functional block</td><td>L. FirmwareManagement</td></tr><tr><td>3</td><td>Objective(s)</td><td>To allow Charging Stations to download a firmware update directly from the Local Controller.</td></tr><tr><td>4</td><td>Description</td><td>The Local Controller downloads and publishes a firmware update at the specified URL. This allows the CSMS to send UpdateFirmwareRequests with the URI pointing to the Local Controller, to any Charging Station connected to the Local Controller. This allows the site to save bandwidth and data on the WAN interface.</td></tr><tr><td></td><td>Actors</td><td>Local Controller, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a PublishFirmwareRequest to instruct the Local Controller to download and publish the firmware, including an MD5 checksum of the firmware file.
+2. Upon receipt of PublishFirmwareRequest, the Local Controller responds with PublishFirmwareResponse.
+3. The Local Controller starts downloading the firmware.
+4. The Local Controller verifies the MD5 checksum.
+5. The Local Controller publishes the firmware file at the URI(s) stated in PublishFirmwareStatusNotificationRequest.
+6. The CSMS instructs Charging Stations to update their firmware, as described in Use Case L01 - Secure Firmware Update</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The firmware is successfully published by the Local Controller.
+Failure postcondition:
+The Local Controller could not download the firmware file, and has sent the DownloadFailed status.
+The Local Controller could not verify the MD5 checksum, and has sent the InvalidChecksum status.
+The Local Controller could not publish the firmware file, and has sent the PublishFailed status.</td></tr></table>
+
+
+Figure 120. Sequence Diagram: showing publishing of firmware (happy flow)
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>For information about MD5 checksum see RFC-1321 [RFC1321].</td></tr></table>
+
+# L03 - Publish Firmware file on Local Controller - Requirements
+
+Table 197. L03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>L03.FR.01</td><td></td><td>Whenever the Local Controller enters a new status in the publishing process, it SHALL send a PublishFirmwareStatusNotificationRequest message to the CSMS.</td></tr><tr><td>L03.FR.02</td><td></td><td>The MD5 checksum SHALL be calculated over the entire firmware file.</td></tr><tr><td>L03.FR.03</td><td></td><td>The Local Controller SHALL publish the firmware file using all its supported protocols (e.g. HTTP, HTTPS, and FTP)</td></tr><tr><td>L03.FR.04</td><td></td><td>The Local Controller SHALL set URI's for all supported protocols (e.g. HTTP, HTTPS, and FTP) in the location field of the PublishFirmwareStatusNotificationRequest message with status Published.</td></tr><tr><td>L03.FR.05</td><td>Upon receipt of a PublishFirmwareRequest message.</td><td>The Local Controller SHALL respond with a PublishFirmwareResponse message, indicating whether it has accepted the request.</td></tr><tr><td>L03.FR.06</td><td>If the Local Controller cannot download the firmware file.</td><td>The Local Controller SHALL send a PublishFirmwareStatusNotificationRequest with status DownloadFailed.</td></tr><tr><td>L03.FR.07</td><td>If the Local Controller cannot verify the MD5 checksum.</td><td>The Local Controller SHALL send a PublishFirmwareStatusNotificationRequest with status InvalidChecksum.</td></tr><tr><td>L03.FR.08</td><td>If the Local Controller cannot publish the firmware file.</td><td>The Local Controller SHALL send a PublishFirmwareStatusNotificationRequest with status PublishFailed.</td></tr><tr><td>L03.FR.09</td><td>After successfully publishing the firmware file.</td><td>The Local Controller SHALL send a PublishFirmwareStatusNotificationRequest with status Published.</td></tr><tr><td>L03.FR.10</td><td>Charging Station receives a TriggerMessageRequest for PublishFirmwareStatusNotifi cation AND last sent PublishFirmwareStatusNotificationR equest had status = Published</td><td>Charging Station SHALL return a PublishFirmwareStatusNotificationRequest with status = Idle.</td></tr><tr><td>L03.FR.11</td><td>Charging Station receives a TriggerMessageRequest for PublishFirmwareStatusNotifi cation AND last sent PublishFirmwareStatusNotificationR equest had NOT status Published</td><td>Charging Station SHALL return a PublishFirmwareStatusNotificationRequest with the last sent status.</td></tr></table>
+
+# L04 - Unpublish Firmware file on Local Controller
+
+Table 198. L04 - Unpublish Firmware file on Local Controller
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Unpublish Firmware file on Local Controller.</td></tr><tr><td>2</td><td>ID</td><td>L04</td></tr><tr><td></td><td>Functional block</td><td>L. FirmwareManagement</td></tr><tr><td>3</td><td>Objective(s)</td><td>Stop the Local Controller from publishing a firmware update to Charging Stations.</td></tr><tr><td>4</td><td>Description</td><td>Stop serving a firmware update to connected Charging Stations.</td></tr><tr><td></td><td>Actors</td><td>Local Controller, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends an UnpublishFirmwareRequest to instruct the local controller to unpublish the firmware.
+2. The Local Controller unpublishes the firmware.
+3. The local Controller responds with an UnpublishFirmwareResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A firmware successfully published by the Local Controller.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+Firmware file no longer published.
+Failure postcondition:
+n/a</td></tr></table>
+
+
+Figure 121. Sequence Diagram: Unpublishing a firmware file
+
+Table 199. L04 - Requirements
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The CSMS uses a MD5 checksum over the entire firmware file as a unique identifier to indicate which firmware file needs to be unpublished.</td></tr></table>
+
+# L04 - Unpublish Firmware file on Local Controller - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>L04.FR.01</td><td>If the Local Controller receives an UnpublishFirmwareRequest message AND There is no ongoing download.</td><td>The firmware file SHALL be unpublished.</td></tr><tr><td>L04.FR.02</td><td>After successfully unpublished the firmware file.</td><td>The local controller SHALL send an UnpublishFirmwareResponse message with status Unpublished.</td></tr><tr><td>L04.FR.03</td><td>If the Local Controller receives an UnpublishFirmwareRequest message AND There is no published file.</td><td>The Local Controller SHALL send an UnpublishFirmwareResponse message with status NoFirmware.</td></tr><tr><td>L04.FR.04</td><td>If the Local Controller receives an UnpublishFirmwareRequest message AND If a Charging Station is downloading the firmware file.</td><td>The Local Controller SHALL respond with the Downloading status AND not unpublished the firmware file.</td></tr></table>
+
+# M. ISO 15118 CertificateManagement
+
+# 1. Introduction
+
+The ISO/IEC JWG 15118 for the Vehicle to Grid Communication Interface (V2G CI) was founded in 2009 with means to the need of a complementary international standard to IEC 61851-1 [IEC61851-1] providing bi-directional digital communication based on Internet protocols. The major purpose of 15118 is to establish a more advanced and autonomously working charge control mechanism between EVs and charging infrastructures. The standard is currently under development and will ultimately provide means for various authentication schemes (e.g. plug charge vs. external identification means, like RFID cards), automatic handling of charging services as well as (proprietary) value added services, charge scheduling and advance planning, etc.
+
+The 15118 standard is of interest to the Open Charge Alliance, as it provides the exchange of charging schedules and enables to control the amount of power that an EV may draw from a Charging Station, in which some form of vehicle to grid communication is necessary. Especially the second part, which specifies the messages to be exchanged between the communication partners (Application Layer), the associated data and data types (Presentation Layer) via TCP/IP based Transport and Network Layer, is important to acknowledge in this specification. The authorization for charging is provided either by External Identification Means (EIM), such as an RFID card, or by the Plug and Charge (PnC) mechanism using a contract certificate stored in the EV, handled by the certificate handling process in use case elements "C", eliminating the need of other authorization means.
+
+This 15118 OCPP Functional Block has been designed to meet a number of alignment objectives:
+
+- To allow the communication between an EV (BEV or a PHEV) and an EVSE.
+ To allow the support of certificate-based authentication and authorization at the Charging Station, i.e. plug and charge.
+
+For illustration purposes: the figure below shows a complete sequence with authorization and scheduling.
+
+# NOTE
+
+To the below figure: this sequence only applies for AC charging, although the certificate handling (which is the focus in this section) does not differ in AC or DC.
+
+
+15118 Identification, Authentication
+
+ServiceDiscoveryReq()
+
+ServiceDiscoveryRes()
+
+PaymentServiceSelectionReq()
+
+PaymentServiceSelectionRes()
+
+CertificateUpdateReq()
+
+
+opt [15118 Certificate Installation or Update]
+
+PaymentDetailsReq()
+
+
+seq 15118 Target Setting and charge Scheduling
+
+ChargeParameterDiscoveryReq()
+
+
+
+EV is charging..
+
+User terminates charging
+
+PowerDeliveryReq(ChargeProcess=Stop)
+
+
+Stopping Transaction
+Figure 122. Sequence with Authorization and Scheduling
+
+User disconnects cable
+
+TransactionEventRequest(eventType = Ended,
+
+triggerReason = EVCommunicationLost, chargingState = Idle, ...)
+
+TransactionEventResponse(...)
+
+<table><tr><td>NOTE</td><td>The time-out on the ChargeParameterDiscoveryReq is 2 seconds, but this can be prolonged up to 60 seconds to wait for charging profile to be provided by the CSMS. See ISO 15118-2 [ISO15118-2].</td></tr><tr><td>NOTE</td><td>Please note that it is highly RECOMMENDED to use one of the TLS based security profiles from functional block A, not doing this might "break" the ISO 15118 security.</td></tr><tr><td colspan="2">In order to control the amount of power that an EV may draw from a Charging Station, some form of vehicle to grid communication is necessary. OCPP has been designed to support the ISO 15118 standard for communication between the EV and Charging Station (EVSE). However, it is anticipated that for the coming years, the majority of EVs will only support the control pilot PWM signal IEC61851, so care has been taken to support smart charging with this as well.</td></tr><tr><td>NOTE</td><td>A mapping of the ISO 15118 and OCPP terminology is provided in ISO 15118 and OCPP terminology mapping and abbreviations used in ISO 15118 are listed in ISO 15118 Abbreviations.</td></tr></table>
+
+# 2. ISO 15118 Certificates
+
+# 2.1. ISO 15118 Certificate structure
+
+The ISO 15118 standard provides a Plug & Charge mechanism. This is an identification and authorization mode where the customer just has to plug his electric vehicle into the EVSE and all aspects of authentication, authorization, load control and billing are automatically taken care of without the need for further user interaction. This is facilitated by the application of digital signatures and exchange of X.509 certificates bound to a Public Key Infrastructures (PKI) model.
+
+The PKI structure defined by ISO 15118 is shown in the figure below. In general, four PKIs need to be in place.
+
+- PKI for the Charging Station Operator (CSO)
+- PKI for the Certificate Provisioning Service (CPS)
+- PKI for the Mobility Operator (MO)
+- PKI for the car manufacturer (OEM)
+
+The trust anchor (root CA) for the CSO and CPS is the so-called V2G Root CA. On the other hand, it is up to the respective OEM and MO to operate a Root CA of their own or derive their certificates from a V2G Root CA (indicated by the dotted lines between V2G Root and MO Sub-CA 1 and OEM Sub-CA 1, respectively).
+
+
+Figure 123. PKIs applied for Plug & Charge identification mode
+
+If only one Sub-CA layer is used, i.e. a Sub-CA signed by a Root CA directly signs leaf certificates, the profile of Sub-CA 2 shall apply for that Sub-CA (Source: ISO15118-2)
+
+OCPP needs to make sure that the necessary information can be exchanged between the EV, the Charging Station and a backend IT infrastructure to facilitate the contract provisioning. Contract provisioning is a process defined within ISO 15118 that describes how an EV can retrieve a valid contract certificate during a communication session in order to authenticate and authorize itself for the charging process.
+
+Given the PKI structure in the figure above, OCPP must provide messages which are able to transmit the following certificates:
+
+CPS certificate chain
+
+Comprised of Prov Sub-CA 1, Prov Sub-CA 2 and leaf provisioning certificate. Sent with the CertificateInstallationRes and CertificateUpdateRes message.
+
+MO certificate chain
+
+Comprised of MO Sub-CA 1, MO Sub-CA 2 and contract certificate. Sent with the messages CertificateInstallationRes, CertificateUpdateReq, and CertificateUpdateRes.
+
+OEM provisioning certificate
+
+Sent with the CertificateInstallationReq message.
+
+Furthermore, some ISO 15118 messages require digital XML-based signatures. Those signatures need to be validated by the receiving party by using the corresponding certificate chain and verifying the chain of signatures all the way up to the respective
+
+trust anchor (V2G root, MO root or OEM root). Table 13 on page 45 of ISO15118-2 provides an overview of applied XML-based signatures in ISO 15118. As you can see in there, the Charging Station (EVSE is part of a Charging Station) needs to verify the signature of the following messages.
+
+# - AuthorizationReq
+
+Certificate chain needed to verify signature is provided with PaymentDetailsReq.
+
+# - MeteringReceipts
+
+Certificate chain needed to verify signature is provided with PaymentDetailsReq.
+
+# CertificateUpdateReq
+
+Certificate chain needed to verify signature is provided with this message.
+
+The signature verification as well as the check of the validity of each certificate provided by the EV can be done offline. These three messages are signed with the private key belonging to the public key of the contract certificate that is installed in the EV. The CSO needs to make sure that the corresponding MO root CA certificate (MO trust anchor) is installed on the Charging Station to enable signature verification offline (the chain of contract certificates and sub-CA certificates is already fulfilled by the EV in the PaymentDetailsReq message so only the MO root CA is required).
+
+The PaymentDetailsReq message is sent before the AuthorizationReq and MeteringReceiptReq message. Therefore, the Charging Station must temporarily save the certificate chain provided with the PaymentDetailsReq message as long as the current transaction is active in order to be able to verify the signature created by the EV. After the transaction has been terminated, the temporarily saved certificate chain must be deleted on the Charging Station side.
+
+Please note that the Charging Station only needs to check the contract certificate upon the receipt of the PaymentDetailsReq message from the EV which delivers the ContractSignatureCertChain, containing the contract certificate and possible sub-CA certificates, excluding the root CA certificate. However, it does not need to check the contract certificate upon installation or update of the contract certificate, upon delivery to the EV.
+
+On the contrary, the signature provided with the CertificateInstallationReq needs to be verified by a so-called secondary actor, a market stakeholder communicating with the CSO backend. This means that OCPP needs to provide means for transmitting the complete CertificateInstallationReq message.
+
+The CertificateUpdateRes and CertificateInstallationRes need to be sent from the CSO backend to the charging station as Base64 encoded binary data. The Charging Station removes the Base64 encoding and sends it to the EV as a binary EXI message.
+
+Finally, the Charging Station certificate (labelled as EVSE Leaf Certificate in figure 1) together with its private key is used to establish a secure connection between EV and EVSE via TLS. According to ISO 15118, this certificate should be valid for only 2 to 3 months. To install or update the Charging Station certificate, please refer to Certificate installation Charging Station.
+
+While the Charging Station can verify the signature and validity period of each certificate in the MO contract certificate chain offline, there are two things which the Charging Station cannot verify offline:
+
+# 1. The authorization status of the EMAID
+
+The EMAID is a unique identifier issued by the MO together with the contract certificate. Therefore, only the MO can provide information on whether the user is authorized for charging based on this EMAID or not. The Charging Station needs to forward the EMAID to the CSO after having checked that the signature of each certificate in the contract certificate chain is valid. This order of steps is necessary because the contract certificate protects the EMAID against manipulation by means of the digital signature of its issuer. The Charging Station could also work with a white list of EMAIDs cached locally. However, white lists need to be frequently updated to ensure that the authorization information used is not outdated.
+
+# 2. The revocation status of each certificate
+
+Reasons for revoking a certificate are e.g. that the private key belonging to the public key of a certificate has been corrupted or that the algorithm used to create a signature is not considered to be secure anymore. Revocation status is checked using an OCSP responder whose address is given as an attribute value of an X.509 certificate.
+
+# 2.2. Using ISO 15118 Certificates in OCPP
+
+From an OCPP perspective, based on the above paragraph, the Charging Station needs to have one or more of each of the following certificate types:
+
+<table><tr><td>Type</td><td>Description</td></tr><tr><td>V2GChargingStation Certificate</td><td>Certificate of the Charging Station. In 15118 this is called the SECC Certificate (or EVSE Leaf Certificate). This certificate is used during the set-up of the TLS connection between the Charging Station and the EV.</td></tr><tr><td>V2GRootCertificate</td><td>Certificate of the ISO15118 V2G Root. The V2G Charging Station Certificate MUST BE derived from this root.</td></tr><tr><td>MORootCertificate</td><td>Certificate from an eMobility Service provider. To support PnC charging with contracts from service providers that not derived their certificates from the V2G root.</td></tr><tr><td>NOTE</td><td>The V2G Charging Station Certificate might be the same as the certificate used for securing the connection between the Charging Station and the CSMS. For this to work, this certificate MUST BE to be derived from a V2G Root.</td></tr><tr><td colspan="2">A Contract Certificate can be derived from a V2G root, or an eMobility root. This means the Charging Station needs to be in possession of the corresponding root certificate to be able to authenticate the driver by means of the Contract Certificate and the associated certificate chain.</td></tr><tr><td>NOTE</td><td>When a Charging Station is online this does not have to be the case, because it can send an InvalidateRequest message with the Contract Certificate to be validated by the CSMS.</td></tr></table>
+
+The V2G Charging Station Certificate needs to be derived from a V2G root. If this root is not known by the EV, no connection via 15118 is possible, so charging controlled by 15118 is NOT possible. In the event a Charging Station needs to support more than one V2G root, multiple V2G Charging Station Certificates are needed.
+
+# 2.3. 15118 communication set-up
+
+At the beginning of a 15118 communication session the EV will initiate a TLS Connection. In this request, the car presents its known V2G root certificates.
+
+During the TLS handshake, the EVCC can request the OCSP status of the Charging Station and intermediate certificates using OCSP stapling as defined in IETF RFC 6961. The Charging Station can retrieve this information by sending a GetCertificateStatusRequest to the CSMS, see use case M06 - Get Charging Station Certificate status.
+
+
+Figure 124. Communication set-up
+
+# 2.4. Certificate - Use Case mapping
+
+The following table contains the use cases that can be used to manage the certificates needed for ISO 15118 charging from OCPP:
+
+Table 200. Certificates relevant for 15118
+
+<table><tr><td>Certificate</td><td>Used for</td><td>Use Case</td><td>Remark</td></tr><tr><td>ChargingStationCertificate</td><td>Charging Station - CSMS connection</td><td>A02 and A03</td><td>Used for OCPP security in general. Certificate chain must also be available and can be retrieved by the Charging Station when installing the certificate.</td></tr><tr><td>CPS Certificate Chain</td><td>Plug & Charge authentication</td><td>M03, M04 and M05</td><td></td></tr><tr><td>EVContractCertificate</td><td>Plug & Charge authentication</td><td>M01 and M02</td><td>Shorter life time certificate (for plug & charge)</td></tr><tr><td>MORootCertificate</td><td>Plug & Charge authentication</td><td>M03, M04 and M05</td><td></td></tr><tr><td>MO Certificate Chain</td><td>Plug & Charge authentication</td><td>N.a.</td><td>It is only necessary to install MO root certificate for Plug & Charge authentication, other intermediate certificates are offered by the EV</td></tr><tr><td>OEMProvisioningCertificate</td><td>Installing Certificates in the EV</td><td>M01 and M02</td><td>Long life time installed in EV by OEM</td></tr><tr><td>V2GChargingStationCertificate</td><td>EV - Charging Station TLS connection</td><td>A02 and A03</td><td>Certificate chain must also be available and can be retrieved by the Charging Station when installing the certificate.</td></tr><tr><td>V2GRootCertificate</td><td>EV - Charging Station TLS connection</td><td>M03, M04 and M05</td><td>It is only necessary to install a V2G root certificate for Plug & Charge authentication.</td></tr><tr><td>V2GIntermediateCertificate</td><td>Plug & Charge authentication</td><td>A02, A03, M03 and M04</td><td>Intermediate certificates between the V2GChargingStationCertificate and V2GRootCertificate. May be used during TLS setup between EV and Charging Station.</td></tr></table>
+
+# 3. Use cases from ISO 15118 relevant for OCPP
+
+See ISO15118-1 page 17 for a list of all elementary use cases. The bold indicated use case component are identified as of influence of the OCPP communication following ISO15118-1.
+
+Table 201. 15118 use cases relevant for OCPP (Source original table: ISO15118-1)
+
+<table><tr><td>No.</td><td>Use case element name / grouping</td></tr><tr><td>A1</td><td>Begin of charging process with forced High Level Communication</td></tr><tr><td>A2</td><td>Begin of charging process with concurrent IEC61851-1 and High Level Communication</td></tr><tr><td>B1</td><td>EV/Charging Station communication setup</td></tr><tr><td>C1</td><td>Certificate update</td></tr><tr><td>C2</td><td>Certificate installation</td></tr><tr><td>D1</td><td>Authorization using Contract Certificates performed at the EVSE</td></tr><tr><td>D2</td><td>Authorization using Contract Certificates performed with help of SA</td></tr><tr><td>D3</td><td>Authorization at EVSE using external credentials performed at the EVSE</td></tr><tr><td>D4</td><td>Authorization at EVSE using external credentials performed with help of SA</td></tr><tr><td>E1</td><td>AC charging with load leveling based on High Level Communication</td></tr><tr><td>E2</td><td>Optimized charging with scheduling to Secondary Actor</td></tr><tr><td>E3</td><td>Optimized charging with scheduling at EV</td></tr><tr><td>E4</td><td>DC charging with load leveling based on High Level Communication</td></tr><tr><td>E5</td><td>Resume to Authorized Charge Schedule</td></tr><tr><td>F0</td><td>Charging loop</td></tr><tr><td>F1</td><td>Charging loop with metering information exchange</td></tr><tr><td>F2</td><td>Charging loop with interrupt from the Charging Station</td></tr><tr><td>F3</td><td>Charging loop with interrupt from the EV or user</td></tr><tr><td>F4</td><td>Reactive power compensation</td></tr><tr><td>F5</td><td>Vehicle to grid support</td></tr><tr><td>G1</td><td>Value added services</td></tr><tr><td>G2</td><td>Charging details</td></tr><tr><td>H1</td><td>End of charging process</td></tr></table>
+
+# NOTE
+
+Not all 15118 related OCPP use cases are described in this functional block. This functional block describes installing and updating certificates in the EV and CA certificate handling (also for non 15118 related purposes). Please refer to ISO 15118 Authorization for the authorization related use cases. The Smart Charging related use cases are described in the chapter Smart Charging.
+
+# 4. Use cases & Requirements
+
+# M01 - Certificate installation EV
+
+Table 202. M01 - Certificate installation
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Certificate Installation</td></tr><tr><td>2</td><td>ID</td><td>M01</td></tr><tr><td></td><td>Functional block</td><td>M. ISO 15118 Certificate Management</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 C2</td></tr><tr><td>3</td><td>Objectives</td><td>To install a new certificate from the CSMS in the EV.</td></tr><tr><td>4</td><td>Description</td><td>The EV initiates installing a new certificate. The Charging Station forwards the request for a new certificate to the CSMS.See also ISO15118-1, use case Description C2, page 22.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>15118:See ISO15118-1, use case Description C2, Scenario Description, first 3 bullets, page 22.OCPP:- The Charging Station sends Get15118EVCertificateRequest message with action = Install to the CSMS.- The CSMS responds with Get15118EVCertificateResponse to the Charging Station.</td></tr><tr><td></td><td>Alternative scenario's</td><td>n/a</td></tr><tr><td>5</td><td>Prerequisites</td><td>- Communication between EV and EVSE SHALL be established successfully.- Online connection between Charging Station and CSMS SHALL be possible.- CSMS should be able to communicate with a third party that can process the CertificateInstallationRequest, for example a contract certificate pool.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>See ISO15118-1, use case End conditions C2, page 23.</td></tr></table>
+
+
+Figure 125. Certificate Installation
+
+Table 203. M01 - Requirements
+
+<table><tr><td>7</td><td>Error handling</td><td>In case the CSMS is not able to respond within the specified time, the Charging Station SHALL indicate failure to the EV.</td></tr><tr><td>8</td><td>Remark(s)</td><td>The message timeout in ISO15118-2 for CertificateInstallationReq is 5 seconds.
+There may be alternative communication paths for doing a certificate installation. However, these are outside the scope of this standard.</td></tr></table>
+
+Source: ISO15118-1
+
+# M01 - Certificate installation - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>M01.FR.01</td><td>Upon receiving a 15118 CertificateInstallationReq</td><td>The Charging Station SHALL forward the request to the CSMS using the Get15118EVCertificateRequest message with action = Install.</td><td>The CSMS is responsible for forwarding it to the secondary actor which will process the CertificateUpdateRequest. This could be a contract certificate pool as outlined in application guide VDE-AR-2802-100-1.</td></tr></table>
+
+# M02 - Certificate Update EV
+
+Table 204. M02 - Certificate Update
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Certificate Update</td></tr><tr><td>2</td><td>ID</td><td>M02</td></tr><tr><td></td><td>Functional block</td><td>M. ISO 15118 Certificate Management</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 C1</td></tr><tr><td>3</td><td>Objectives</td><td>See ISO15118-1, use case Objective C1, page 20.</td></tr><tr><td>4</td><td>Description</td><td>See ISO15118-1, use case Description C1, page 21 up to and including the third "NOTE".</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>15118:See ISO15118-1, use case Objective C1, Scenario Description, first 3 bullets, page 21.OCPP:- The Charging Station sends a Get15118EVCertificateRequest message with action = update to the CSMS.- The CSMS responds with Get15118EVCertificateResponse to the Charging Station.15118:See ISO15118-1, use case Description C1, Scenario Description, last 2 bullets, page 21.</td></tr><tr><td>5</td><td>Prerequisites</td><td>- Communication between EV and EVSE SHALL be established successfully.- Online connection between Charging Station and CSMS SHALL be possible.- CSMS should be able to communicate with a third party that can process the CertificateInstallationRequest, for example a contract certificate pool.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>See ISO15118-1, use case Objective C1 and C2, page 20/22.</td></tr></table>
+
+
+Figure 126. Certificate Update
+
+<table><tr><td>7</td><td>Error handling</td><td>In case the CSMS is not able to respond within the specified time, the Charging Station SHALL indicate failure to the EV.</td></tr><tr><td>8</td><td>Remark(s)</td><td>See ISO15118-1, use case Requirements C1, trigger, page 21.
+The message timeout in ISO15118-2 for CertificateUpdateReq is 5 seconds.</td></tr></table>
+
+# M02 - Certificate Update - Requirements
+
+Table 205. M02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>M02.FR.01</td><td></td><td>Upon receiving a CertificateUpdateReq the Charging Station SHALL forward the request to the CSMS using the Get15118EVCertificateRequest message with action = update.</td><td>The CSMS is responsible for forwarding it to the secondary actor which will process the CertificateUpdateRequest. This could be a contract certificate pool as outlined in application guide VDE-AR-E 2802-100-1.</td></tr></table>
+
+# M03 - Retrieve list of available certificates from a Charging Station
+
+Table 206. M03 - Retrieve list of available certificates from a Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Retrieve list of available certificates from a Charging Station</td></tr><tr><td>2</td><td>ID</td><td>M03</td></tr><tr><td></td><td>Functional block</td><td>M. ISO 15118 Certificate Management</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to retrieve a list of available certificates from a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>To facilitate the management of the Charging Station's installed certificates, a method of retrieving the installed certificates is provided. The CSMS requests the Charging Station to send a list of installed certificates</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS requests the Charging Station to send a list of installed certificates by sending a GetInstalledCertificatesRequest
+2. The Charging Station responds with a GetInstalledCertificatesResponse</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS received a list of installed certificates</td></tr></table>
+
+
+Figure 127. Retrieve list of available certificates from a Charging Station
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>For installing the (V2G) Charging Station Certificate, see use cases A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station. The V2G certificate chain SHOULD not include the V2GRootCertificate. This SHOULD be installed using Use case M05 - Install CA certificate in a Charging Station.</td></tr></table>
+
+# M03 - Retrieve list of available certificates from a Charging Station - Requirements
+
+Table 207. M03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>M03.FR.01</td><td>After receiving a GetInstalledCertificatesRequest</td><td>The Charging Station SHALL respond with a GetInstalledCertificatesResponse.</td></tr><tr><td>M03.FR.02</td><td>M03.FR.01 AND No certificate matching certificateType was found</td><td>The Charging Station SHALL indicate this by setting status in the GetInstalledCertificatesResponse to NotFound.</td></tr><tr><td>M03.FR.03</td><td>M03.FR.01 AND A certificate matching certificateType was found</td><td>The Charging Station SHALL indicate this by setting status in the GetInstalledCertificatesResponse to Accepted.</td></tr><tr><td>M03.FR.04</td><td>M03.FR.03</td><td>The Charging Station SHALL include the hash data for each matching installed certificate in the GetInstalledCertificatesResponse.</td></tr><tr><td>M03.FR.05</td><td>When the Charging Station receives a GetInstalledCertificatesRequest with certificateType V2GCertificateChain</td><td>The Charging Station SHALL include the hash data for each installed certificate belonging to a V2G certificate chain. Sub CA certificates SHALL be placed as a childCertificate under the V2G Charging Station certificate.</td></tr></table>
+
+# M04 - Delete a specific certificate from a Charging Station
+
+Table 208. M04 - Delete a specific certificate from a Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Delete a specific certificate from a Charging Station</td></tr><tr><td>2</td><td>ID</td><td>M04</td></tr><tr><td></td><td>Functional block</td><td>M. ISO 15118 Certificate Management</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to request the Charging Station to delete an installed certificate.</td></tr><tr><td>4</td><td>Description</td><td>To facilitate the management of the Charging Station's installed certificates, a method of deleting an installed certificate is provided. The CSMS requests the Charging Station to delete a specific certificate.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS requests the Charging Station to delete an installed certificate by sending a DeleteCertificateRequest.
+2. The Charging Station responds with a DeleteCertificateResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The requested certificate was deleted from the Charging Station.</td></tr></table>
+
+
+
+Figure 128. Delete Installed Certificate
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>For installing the (V2G) Charging Station Certificate, see use cases A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station. The V2G certificate chain SHOULD not include the V2GRootCertificate. This SHOULD be installed using Use case M05 - Install CA certificate in a Charging Station.
+It is possible to delete the last (every) installed CSMSRootCertificates. When all CSMSRootCertificates are deleted, the Charging Station cannot validate CSMS Certificates, so it will not be able to connect to a CSMS. Before a CSMS would ever send a DeleteCertificateRequest that would delete the last/all CSMSRootCertificates the CSMS is ADVISED to make very sure that this is what is really wanted.
+It is possible to delete the last (every) installed ManufacturerRootCertificates, when all ManufacturerRootCertificates are deleted, no "Signed Firmware" can be installed in the Charging Station.</td></tr></table>
+
+# M04 - Delete a specific certificate from a Charging Station - Requirements
+
+Table 209. M04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>M04.FR.01</td><td>After receiving a DeleteCertificateRequest</td><td>The Charging Station SHALL respond with a DeleteCertificateResponse.</td><td></td></tr><tr><td>M04.FR.02</td><td>M04.FR.01 AND The requested certificate was found</td><td>The Charging Station SHALL attempt to delete it, and indicate success by setting status to Accepted in the DeleteCertificateResponse.</td><td></td></tr><tr><td>M04.FR.03</td><td>M04.FR.01 AND (The deletion fails OR the Charging Station rejects the request to delete the specified certificate.)</td><td>The Charging Station SHALL indicate failure by setting status to Failed in the DeleteCertificateResponse.</td><td>A Charging Station may reject the request to prevent the deletion of a certificate, if it is the last one from its certificate type.</td></tr><tr><td>M04.FR.04</td><td>M04.FR.01 AND The requested certificate was not found</td><td>The Charging Station SHALL indicate failure by setting 'status' to 'NotFound' in the DeleteCertificateResponse.</td><td></td></tr><tr><td>M04.FR.06</td><td>M04.FR.01 AND When certificateHashData refers to the Charging Station Certificate (see use case A)</td><td>Charging Station SHALL respond with DeleteCertificateReponse with status = Failed.</td><td>Deletion of the Charging Station Certificate is not allowed via DeleteCertificateRequest.</td></tr><tr><td>M04.FR.07</td><td>When deleting a certificate</td><td>The CSMS SHALL use the same hashAlgorithm as the Charging Station uses to report the certificateHashData for the certificate in the GetInstalledCertificatesResponse.</td><td>This ensures CSMS uses a hashAlgorithm that is supported by the Charging Station.</td></tr><tr><td>M04.FR.08</td><td>M04.FR.02 AND Certificate to delete is a sub-CA or root certificate</td><td>Charging Station MAY also delete all child certificates.</td><td>Else these child certificates remain as unusable orphan certificates that can no longer be deleted.</td></tr></table>
+
+# M05 - Install CA certificate in a Charging Station
+
+Table 210. M05 - Install CA certificate in a Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Install CA certificate in a Charging Station</td></tr><tr><td>2</td><td>ID</td><td>M05</td></tr><tr><td></td><td>Functional block</td><td>M. ISO 15118 Certificate Management</td></tr><tr><td>3</td><td>Objective(s)</td><td>To facilitate the management of the Charging Station's installed certificates, a method to install a new CA certificate.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS requests the Charging Station to install a new CSMS root certificate, an eMobility Operator root certificate, Manufacturer root certificate, or a V2G root certificate.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS requests the Charging Station to install a new certificate by sending an InstallCertificateRequest.
+2. The Charging Station responds with an InstallCertificateResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The new certificate was installed in the Charging Station trust store.</td></tr></table>
+
+
+Figure 129. Install CA certificate in a Charging Station
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Even though the messages CertificateSignedRequest (see use cases A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station) and InstallCertificateRequest (use case M05) are both used to send certificates, their purposes are different. CertificateSignedRequest is used to return the the Charging Stations own public certificate and V2G certificate(s) signed by a Certificate Authority. InstallCertificateRequest is used to install Root certificates.For installing the (V2G) Charging Station Certificate, see use cases A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station. The V2G certificate chain SHOULD not include the V2GRootCertificate. This SHOULD be installed using this use case.It is allowed to have multiple certificates of the same type installed.</td></tr></table>
+
+# M05 - Install CA certificate in a Charging Station - Requirements
+
+Table 211. M05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>M05.FR.01</td><td>After receiving an InstallCertificateRequest</td><td>The Charging Station SHALL attempt to install the certificate and respond with an InstallCertificateResponse.</td></tr><tr><td>M05.FR.02</td><td>M05.FR.01 AND The installation was successful</td><td>The Charging Station SHALL indicate success by setting 'status' to 'Accepted' in the InstallCertificateResponse.</td></tr><tr><td>M05.FR.03</td><td>M05.FR.01 AND The installation failed</td><td>The Charging Station SHALL indicate failure by by setting 'status' to 'Failed' in the InstallCertificateResponse.</td></tr><tr><td>M05.FR.06</td><td>When a new certificate gets installed AND the CertificateEntries.maxLimit is going to be exceeded</td><td>The Charging Station SHALL respond with status Rejected.</td></tr><tr><td>M05.FR.07</td><td>M05.FR.01 AND The certificate is invalid.</td><td>The Charging Station SHALL indicate rejection by setting 'status' to 'Rejected' in the InstallCertificateResponse.</td></tr><tr><td>M05.FR.09</td><td>When AdditionalRootCertificateCheck is true</td><td>Only one certificate (plus a temporarily fallback certificate) of certificateType CSMSRootCertificate is allowed to be installed at a time.</td></tr><tr><td>M05.FR.10</td><td>When AdditionalRootCertificateCheck is true AND installing a new certificate of certificateType CSMSRootCertificate</td><td>The new CSMS Root certificate SHALL replace the old CSMS Root certificate AND the new Root Certificate MUST be signed by the old Root Certificate it is replacing</td></tr><tr><td>M05.FR.11</td><td>M05.FR.10 AND the new CSMS Root certificate is NOT signed by the old CSMS Root certificate</td><td>The Charging Station SHALL NOT install the new CSMS Root Certificate and respond with status Rejected.</td></tr><tr><td>M05.FR.12</td><td>M05.FR.10 AND the new CSMS Root certificate is signed by the old CSMS Root certificate</td><td>The Charging Station SHALL install the new CSMS Root Certificate AND temporarily keep the old CSMS Root certificate as a fallback certificate AND respond with status Accepted</td></tr><tr><td>M05.FR.13</td><td>M05.FR.12 AND the Charging Station successfully connected to the CSMS using the new CSMS Root certificate</td><td>The Charging Station SHALL remove the old CSMS Root (fallback) certificate.</td></tr><tr><td>M05.FR.14</td><td>M05.FR.12 AND The Charging Station is attempting to reconnect to the CSMS (NOT migrating to another CSMS with Use Case B10 - Migrate to new CSMS), but determines that the server certificate provided by the CSMS is invalid when using the new CSMS Root certificate to verify it</td><td>The Charging Station SHALL try to use the old CSMS Root (fallback) certificate to verify the server certificate.</td></tr><tr><td>M05.FR.15</td><td>M05.FR.12 AND When the Charging Station is migrating to another CSMS with Use Case B10 - Migrate to new CSMS, but determines that the server certificate provided by the CSMS is invalid when using the new CSMS Root certificate to verify it</td><td>The Charging Station SHALL use the NetworkProfileConnectionAttempts mechanism as described at Use Case B10 - Migrate to new CSMS .</td></tr><tr><td>M05.FR.16</td><td>M05.FR.15 AND If after the number of attempts the connection fails AND If it goes back to the old NetworkConnectionProfile (See B10.FR.03)</td><td>The Charging Station SHALL use the old CSMS Root (fallback) certificate to verify the server certificate.</td></tr><tr><td>M05.FR.17</td><td>NOT M05.FR.10 AND After receiving an InstallCertificateRequest for a certificate that is already present in the certificate trust store of the Charging Station</td><td>The Charging Station SHALL replace the certificate and respond with InstallCertificateResponse with status = Accepted.</td></tr></table>
+
+# M06 - Get V2G Charging Station Certificate status
+
+Table 212. M06 - Get V2G Charging Station Certificate status
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get V2G Charging Station Certificate status</td></tr><tr><td>2</td><td>ID</td><td>M06</td></tr><tr><td></td><td>Functional block</td><td>M. ISO 15118 Certificate Management</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable a Charging Station to cache the OCSP certificate status needed for the TLS handshake between EV and Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>When the cable gets plugged in and an ISO 15118 supported EV gets connected to the Charging Station, the EV requests the Charging Station to prove the validity of the (SubCA) certificates by an OCSPResponse. A request needs to be sent per SubCA. Because the timeout constraint in ISO 15118 is too strict to make the call to an external server, OCPP requires to cache the OCSP certificate status of the certificates beforehand. The Charging Station needs to refresh the cached OCSP data once a week..</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station requests the CSMS to provide OCSP certificate status by sending a GetCertificateStatusRequest.
+2. The CSMS responds with a GetCertificateStatusResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station received the OCSP certificate status for the requested certificate
+Failure postcondition:
+The retrieval of the OCSP certificate status by the CSMS failed</td></tr></table>
+
+
+Figure 130. Get V2G Charging Station Certificate status
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The status indicator in the GetCertificateStatusResponse indicates whether or not the CSMS was successful in retrieving the certificate status. it does NOT indicate the validity of the certificate.For installing the (V2G) Charging Station Certificate, see use cases A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station. The V2G certificate chain SHOULD not include the V2GRootCertificate. This SHOULD be installed using Use case M05 - Install CA certificate in a Charging Station.OCPP allows for only one certificate per GetCertificateStatusRequest. Because when multiple answers on a GetCertificateStatusRequest are to be expected, it makes handling the request and status more complex. So a GetCertificateStatusRequest needs to be sent per SubCA.responderURL is required in OCPP, while it is optional in ISO 15118. Without a responderURL in a certificate it cannot work, so a responderURL is required for any certificate for which a GetCertificateStatusRequest can be expected.</td></tr></table>
+
+# M06 - Get V2G Charging Station Certificate status - Requirements
+
+Table 213. M06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>M06.FR.01</td><td>After receiving a GetCertificateStatusRequest</td><td>The CSMS SHALL respond with a GetCertificateStatusResponse.</td></tr><tr><td>M06.FR.02</td><td>M06.FR.01ANDThe CSMS was successful in retrieving the OCSP certificate status</td><td>The CSMS SHALL indicate success by setting 'status' to 'Accepted' in the GetCertificateStatusResponse.</td></tr><tr><td>M06.FR.03</td><td>M06.FR.02</td><td>The CSMS SHALL include the OCSP response data in the OCSPResult field in the GetCertificateStatusResponse.</td></tr><tr><td>M06.FR.04</td><td>M06.FR.01ANDThe CSMS was not successful in retrieving the OCSP certificate status</td><td>The CSMS SHALL indicate it was not successful by setting status to Failed in the GetCertificateStatusResponse.</td></tr><tr><td>M06.FR.06</td><td></td><td>The Charging Station SHALL request and cache the OCSP status for its V2G certificates.</td></tr><tr><td>M06.FR.07</td><td></td><td>After the Charging Station Certificate has been updated, The Charging Station SHALL refresh the cached OCSP data by sending a GetCertificateStatusRequest for the new certificate, and also for the intermediate certificates.</td></tr><tr><td>M06.FR.08</td><td></td><td>The CSMS SHALL format the response data according to OCSPResponse as defined in IETF RFC 6960, formatted according to ASN.1 [X.680].</td></tr><tr><td>M06.FR.09</td><td></td><td>The OCSPResponse data SHALL be DER encoded.</td></tr><tr><td>M06.FR.10</td><td></td><td>The Charging Station SHALL refresh the cached OCSP data at least once a week.</td></tr></table>
+
+# N. Diagnostics
+
+# 1. Introduction
+
+This Functional Block describes the diagnostics functionality of OCPP. This functionality enables remote diagnostics of problems with a Charging Station. A Charging Station can be requested to upload a file with diagnostics information (optionally limited to a specified interval).
+
+# 2. Use cases & Requirements
+
+# 2.1. Logging
+
+# N01 - Retrieve Log Information
+
+Table 214. N01 - Retrieve Log Information
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Retrieve Log</td></tr><tr><td>2</td><td>ID</td><td>N01</td></tr><tr><td></td><td>Functional block</td><td>N. Diagnostics</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS retrieving of log information from a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers the functionality of getting log information from a Charging Station. The CSMS can request a Charging Station to upload a file with log information to a given location (URL). The format of this log file is not prescribed. The Charging Station uploads a log file and gives information about the status of the upload by sending status notifications to the CSMS.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a GetLogRequest to the Charging Station.
+2. The Charging Station responds with a GetLogResponse.
+3. The Charging Station sends a LogStatusNotificationRequest with the status Uploading
+4. The CSMS responds with a LogStatusNotificationResponse acknowledging the status update request.
+5. Uploading of the diagnostics files.
+6. The Charging Station sends LogStatusNotificationRequest with the status Uploaded.
+7. The CSMS responds with LogStatusNotificationResponse, acknowledging the status update request.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>- Diagnostics information is available for upload.
+- URL to upload file to is reachable and exists.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+Log file successfully uploaded.
+Failure postcondition:
+Log file not successfully uploaded and failed.</td></tr></table>
+
+
+Figure 131. Sequence Diagram: Get Diagnostics
+
+<table><tr><td>7</td><td>Error handling</td><td>When the upload fails and the transfer protocol supports "resume" the Charging Station is RECOMMENDED to try to resume before aborting the upload.</td></tr><tr><td>8</td><td>Remark(s)</td><td>As an example in this use case the requestId = 123, but this could be any value.</td></tr><tr><td></td><td></td><td>When a Charging Station is requested to upload a log file, the CSMS supplies in the request an URL where the Charging Station SHALL upload the file. The URL also contains the protocol which must be used to upload the file.</td></tr><tr><td></td><td></td><td>It is recommended that the log file is uploaded via FTP or FTPS. FTP(S) is better optimized for large binary data than HTTP. Also FTP(S) has the ability to resume uploads. In case an upload is interrupted, the Charging Station can resume uploading after the part it already has uploaded. The FTP URL is of format: ftp://User-password@host:port/path in which the parts User-password@, :password or :port may be excluded.</td></tr><tr><td></td><td></td><td>The Charging Station has a required Configuration Variable that reports which file transfer protocols it supports: FileTransferProtocols</td></tr><tr><td></td><td></td><td>The format of the log file is not prescribed.</td></tr><tr><td></td><td></td><td>FTP needs to be able to use Passive FTP, to be able to transverse over as much different typologies as possible.</td></tr></table>
+
+# N01 - Retrieve Log Information - Requirements
+
+Table 215. N01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N01.FR.01</td><td>Upon receipt of a GetLogRequest AND if the requested log information is available</td><td>The Charging Station SHALL respond with a GetLogResponse stating the name of the file and status Accepted.</td><td></td></tr><tr><td>N01.FR.02</td><td>N01.FR.01</td><td>The Charging Station SHALL start uploading a single log file to the specified location</td><td></td></tr><tr><td>N01.FR.03</td><td>N01.FR.02 AND The GetLogRequest contained logType SecurityLog</td><td>The Charging Station SHALL upload its security log</td><td></td></tr><tr><td>N01.FR.04</td><td>N01.FR.02 AND The GetLogRequest contained logType DiagnosticsLog</td><td>The Charging Station SHALL upload its diagnostics.</td><td></td></tr><tr><td>N01.FR.05</td><td>Upon receipt of a GetLogRequest AND if the requested log information is NOT available</td><td>The Charging Station SHALL respond with a GetLogResponse WITH status Rejected.</td><td></td></tr><tr><td>N01.FR.07</td><td></td><td>Every LogStatusNotificationRequest sent for a log upload SHALL contain the same requestId as the GetLogRequest that started this log upload.</td><td></td></tr><tr><td>N01.FR.08</td><td>When uploading a log document is started</td><td>The Charging Station SHALL send a LogStatusNotificationRequest with status Uploading.</td><td></td></tr><tr><td>N01.FR.09</td><td>When a log document is uploaded successfully</td><td>The Charging Station SHALL send a LogStatusNotificationRequest with status Uploaded.</td><td></td></tr><tr><td>N01.FR.10</td><td>When uploading a log document failed</td><td>The Charging Station SHALL send a LogStatusNotificationRequest with status UpLoadFailure, BadMessage, PermissionDenied OR NotSupportedOperation.</td><td>It is RECOMMENDED to send the status only after all retry attempts have failed.A Charging Station MAY send a new Uploading status upon each retry attempt.</td></tr><tr><td>N01.FR.12</td><td>When a Charging Station is assembling or uploading the log file AND the Charging Station receives a new GetLogRequest</td><td>The Charging Station SHOULD cancel the ongoing log file upload AND respond with status AcceptedCanceled.</td><td></td></tr><tr><td>N01.FR.13</td><td></td><td>The field requestId in LogStatusNotificationRequest is mandatory, unless the message was triggered by a TriggerMessageRequest AND there is no log upload ongoing.</td><td></td></tr><tr><td>N01.FR.14</td><td></td><td>It is RECOMMENDED that Charging Station and CSMS support at least HTTP(s) as transport mechanism for the log file upload</td><td>HTTP transport is most likely to be supported, since it is also used for OCPP messaging.</td></tr><tr><td>N01.FR.15</td><td></td><td>Charging Station SHALL at least support the CSMS trust chain for secure transports</td><td></td></tr><tr><td>N01.FR.16</td><td></td><td>It is RECOMMENDED that Charging Station supports the usual CAs provided by the operating system</td><td>The log file storage of CSMS may be a cloud service operated separately from the CSMS itself and not part of the CSMS trustchain.</td></tr><tr><td>N01.FR.17</td><td>When CSMS requires basic authorization for the upload</td><td>CSMS is RECOMMENDED to require a different basic authorization password for the upload, then the one used for OCPP connectivity.</td><td>This is to avoid leaking the OCPP password to 3rd parties if the log file storage is a different system. Basic authorization can be added to the URL as follows: http://username:password@d@csms.org/logs</td></tr><tr><td>N01.FR.18</td><td></td><td>Is is RECOMMENDED that CSMS accepts both PUT and POST requests for uploads from Charging Station.</td><td></td></tr><tr><td>N01.FR.19</td><td>When Charging Station uses a HTTP(s) POST request to upload the log file</td><td>Charging Station SHALL provide at least the following attributes: Content-Type: (e.g. application/occtet-stream) and Content-Disposition: with a specification of the filename.</td><td>For example: Content-Type: application/occtet-stream Content-Disposition: form-data; name="uploadfile"; filename="logfile_20210420.zip"</td></tr><tr><td>N01.FR.20</td><td>N01.FR.12 AND Charging Station cancels the log file upload</td><td>The Charging Station SHALL send a LogStatusNotificationRequest with status = AcceptedCanceled.</td><td>N01.FR.12 is a "SHOULD" requirement. Only send status notification when requirement is executed.</td></tr></table>
+
+# 2.2. Configure Monitoring
+
+NOTE
+
+For managing the monitoring of a Charging Station a basic understanding of Device Model concepts is essential. These concepts are explained in "OCPP 2.0.1: Part 1 - Architecture & Topology", chapter 4.
+
+# N02 - Get Monitoring report
+
+Table 216. N02 - Get Monitoring Report
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Monitoring Report</td></tr><tr><td>2</td><td>ID</td><td>N02</td></tr><tr><td></td><td>Functional block</td><td>N. Diagnostics</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to retrieve a report about configured monitoring settings per component and variable.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests the Charging Station to send a report about configured monitoring settings per component and variable. Optionally, this list can be filtered on monitoringCriteria and componentVariables.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request a monitoring report from a Charging Station.
+2. The CSMS sends a GetMonitoringReportRequest to the Charging Station.
+3. The Charging Station responds with a GetMonitoringReportResponse.
+4. The Charging Station sends a NotifyMonitoringReportRequest to the CSMS.
+5. The CSMS responds with a NotifyMonitoringReportResponse.
+6. Steps #4 and #5 are repeated until all data of the monitoring report has been sent.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Station supports Monitoring</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS received a report about the configured monitoring settings.</td></tr></table>
+
+
+Figure 132. Sequence Diagram: Get Monitoring Report
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# N02 - Get Monitoring Report - Requirements
+
+Table 217. N02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N02.FR.01</td><td>NOT N02.FR.10 AND When the Charging Station receives a getMonitoringReportRequest for supported monitoringCriteria OR without monitoringCriteria</td><td>The Charging Station SHALL send a getMonitoringReportResponse with Accepted.</td></tr><tr><td>N02.FR.02</td><td>When the Charging Station receives a getMonitoringReportRequest for not supported monitoringCriteria</td><td>The Charging Station SHALL send a getMonitoringReportResponse with NotSupported.</td></tr><tr><td>N02.FR.03</td><td>N02.FR.01</td><td>The Charging Station SHALL send the requested information via one or more notifyMonitoringReportRequest messages to the CSMS.</td></tr><tr><td>N02.FR.04</td><td>N02.FR.01 AND The getMonitoringReportRequest contained a requestId</td><td>Every notifyMonitoringReportRequest sent for this getMonitoringReportRequest SHALL contain the same requestId.</td></tr><tr><td>N02.FR.05</td><td>N02.FR.01 AND monitoringCriteria and componentVariables are NOT both empty.</td><td>The set of monitors reported in one or more notifyMonitoringReportRequest messages is limited to the set defined by monitoringCriteria and componentVariables.</td></tr><tr><td>N02.FR.06</td><td>N02.FR.01 AND monitoringCriteria is NOT empty AND componentVariables is empty.</td><td>The set of monitors reported in one or more notifyMonitoringReportRequest messages is limited to the set defined by monitoringCriteria.</td></tr><tr><td>N02.FR.07</td><td></td><td>The maximum number of componentVariables in onegetMonitoringReportRequest message is given by theItemsPerMessageGetReport Configuration Variable</td></tr><tr><td>N02.FR.08</td><td>N02.FR.01 ANDmonitoringCriteria is absent ANDcomponentVariables is NOT empty.</td><td>The set of monitors reported in one or morenotifyMonitoringReportRequest messages is limited to the setdefined by componentVariables.</td></tr><tr><td>N02.FR.09</td><td></td><td>The sequence number contained in the seqNo field of theNotifyMonitoringReportRequest is incremental per report. So theNotifyMonitoringReportRequest message which contains thefirst report part, SHALL have a seqNo with value 0.</td></tr><tr><td>N02.FR.10</td><td>When the Charging Station receives aGetMonitoringReportRequest withacombinations of criteria which results in anempty result set.</td><td>The Charging Station SHALL respond with aGetMonitoringReportResponse(status=EmptyResultSet).</td></tr><tr><td>N02.FR.11</td><td>N02.FR.01 ANDmonitoringCriteria is empty ANDcomponentVariables is empty.</td><td>The set of all existing monitors is reported in one or morenotifyMonitoringReportRequest messages.</td></tr><tr><td>N02.FR.12</td><td>If monitoringCriteria containsThresholdMonitoring</td><td>All monitors with type = UpperThreshold or type =LowerThreshold are reported.</td></tr><tr><td>N02.FR.13</td><td>If monitoringCriteria containsDeltaMonitoring</td><td>All monitors with type = Delta are reported.</td></tr><tr><td>N02.FR.14</td><td>If monitoringCriteria containsPeriodicMonitoring</td><td>All monitors with type = Periodic or type =PeriodicClockAligned are reported.</td></tr><tr><td>N02.FR.16</td><td>When Charging Station receives aGetMonitoringReportRequest withcomponentVariable elements in which variable ismissing</td><td>The Charging Station SHALL report for every variable of thecomponent in componentVariable.</td></tr><tr><td>N02.FR.17</td><td>When Charging Station receives aGetMonitoringReportRequest withcomponentVariable elements in which variable ispresent, but instance is missing</td><td>The Charging Station SHALL report for every instance of thevariable of the component in componentVariable.</td></tr><tr><td>N02.FR.18</td><td>N02.FR.11 ANDWhen Charging Station receives aGetMonitoringReportRequest with a componentin a componentVariable element that has acolumn.evse.id, butcomponent.evseconnector is missing</td><td>The Charging Station SHALL report the component(s) with thiscomponent.name, component.instance and component.evse.idfor every component.evseconnector, whilst taking into accountN02.FR.20.</td></tr><tr><td>N02.FR.19</td><td>N02.FR.11 ANDWhen Charging Station receives aGetMonitoringReportRequest with a componentin a componentVariable element that has acolumn.evse.id</td><td>The Charging Station SHALL report the component(s) with thiscomponent.name, component.instance and component.evse field (including top level component without component.evse), whilst taking into account N02.FR.20.</td></tr><tr><td>N02.FR.20</td><td>N02.FR.11 ANDWhen Charging Station receives aGetMonitoringReportRequest with a componentin a componentVariable element that has a valuefor component.instance</td><td>The Charging Station SHALL report the component(s) with thiscomponent.name for every component.instance field, whilsttaking into account N02.FR.18, N02.FR.19.</td></tr><tr><td>N02.FR.21</td><td>N02.FR.11 ANDWhen Charging Station receives aGetMonitoringReportRequest with a componentin a componentVariable element that has nocomponent.instance field</td><td>The Charging Station SHALL report the component(s) with thiscomponent.name for every component.instance field or thecomponent(s) without component.instance field, whichever isthe case, whilst taking into account N02.FR.18, N02.FR.19.</td></tr></table>
+
+# N03 - Set Monitoring Base
+
+Table 218. N03 - Set Monitoring Base
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set Monitoring Base</td></tr><tr><td>2</td><td>ID</td><td>N03</td></tr><tr><td></td><td>Functional block</td><td>N. Diagnostics</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to request the Charging Station to activate a set of preconfigured monitoring settings, as denoted by the value of MonitoringBase.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests the Charging Station to activate a set of preconfigured monitoring settings, as denoted by the value of MonitoringBase. It is up to the manufacturer of the Charging Station to define which monitoring settings are activated by All, FactoryDefault and HardWiredOnly.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request a Charging Station to set a monitoring base.
+2. The CSMS sends a SetMonitoringBaseRequest to the Charging Station.
+3. The Charging Station responds with a SetMonitoringBaseResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Station supports Monitoring</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station activated the set of monitoring settings, as denoted by the value of MonitoringBase.</td></tr></table>
+
+
+Figure 133. Sequence Diagram: Set Monitoring Base
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Upon receipt of a SetMonitoringBaseRequest for HardWiredOnly or FactoryDefault the Charging Station will discard of any previously configured custom monitors and will activate the monitoring settings that are related to given MonitoringBase.For a MonitoringBase = All the Charging Station will activate all pre-configured monitors and leave previously configured custom monitors intact. This includes the custom monitors that were created when changing an existing pre-configured monitor.When the set of pre-configured monitors for All and FactoryDefault is the same, then the difference between the two is, that with FactoryDefault all custom monitors are deleted before the factory default pre-configured monitors are restored.</td></tr></table>
+
+# N03 - Set Monitoring Base - Requirements
+
+Table 219. N03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N03.FR.01</td><td>When the Charging Station accepts a setMonitoringBaseRequest</td><td>Then the Charging Station SHALL send a setMonitoringBaseResponse with Accepted.</td></tr><tr><td>N03.FR.02</td><td>When the Charging Station receives a setMonitoringBaseRequest for a not supported monitoringBase</td><td>Then the Charging Station SHALL send a setMonitoringBaseResponse with NotSupported.</td></tr><tr><td>N03.FR.03</td><td>N03.FR.01 AND When the Charging Station received a setMonitoringBaseRequest with monitoringBase All</td><td>Then the Charging Station SHALL activate all preconfigured monitoring whilst leaving all installed custom monitors (including changed preconfigured monitors) intact.</td></tr><tr><td>N03.FR.04</td><td>N03.FR.01 AND When the Charging Station received a setMonitoringBaseRequest with monitoringBase FactoryDefault</td><td>Then the Charging Station SHALL delete all custom monitors (including overruled pre-configured monitors) and activate the default monitoring settings as recommended by the manufacturer.</td></tr><tr><td>N03.FR.05</td><td>N03.FR.01 AND When the Charging Station received a setMonitoringBaseRequest with monitoringBase HardWiredOnly</td><td>Then the Charging Station SHALL clear all custom and disable all pre-configured monitors. Only hard-wired monitors remain active.</td></tr></table>
+
+# N04 - Set Variable Monitoring
+
+Table 220. N04 - Set Variable Monitoring
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set Variable Monitoring</td></tr><tr><td>2</td><td>ID</td><td>N04</td></tr><tr><td></td><td>Functional block</td><td>N. Diagnostics</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to request the Charging Station to set monitoring triggers on Variables.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests the Charging Station to set monitoring triggers on Variables. Multiple triggers can be set for upper or lower thresholds, delta changes or periodic reporting.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request a Charging Station to set a variable monitoring setting.
+2. The CSMS sends a SetVariableMonitoringRequest to the Charging Station.
+3. The Charging Station responds with a SetVariableMonitoringResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Station supports Monitoring
+The specific Variable supports Monitoring</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station activated the set of monitoring triggers on the Variables.</td></tr></table>
+
+
+
+Figure 134. Sequence Diagram: Set Variable Monitoring
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>All variableMonitoring settings are persistent across reboot.
+A variableMonitoring setting is persistent after a firmware update, if the monitored variable still exists and it is still monitor-able. Otherwise the variableMonitoring setting is removed.</td></tr></table>
+
+# N04 - Set Variable Monitoring - Requirements
+
+Table 221. N04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N04.FR.01</td><td>When the Charging Station receives a SetVariableMonitoringRequest with an X number of SetMonitoringData elements</td><td>The Charging Station SHALL respond with an SetVariableMonitoringResponse with an equal (X) number of SetMonitoringResult elements, one for every SetMonitoringData element in the SetVariableMonitoringRequest.</td><td></td></tr><tr><td>N04.FR.02</td><td>N04.FR.01</td><td>Every SetMonitoringResult element in the SetVariableMonitoringResponse SHALL contain the same component and variable combination as one of the SetVariableMonitoringRequest elements in the SetVariableMonitoringRequest.</td><td></td></tr><tr><td>N04.FR.03</td><td>When the Charging Station receives a SetVariableMonitoringRequest with an unknown Component in SetMonitoringData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: UnknownComponent.</td><td></td></tr><tr><td>N04.FR.04</td><td>When the Charging Station receives a SetVariableMonitoringRequest with a Variable that is unknown for the given Component in SetMonitoringData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: UnknownVariable.</td><td></td></tr><tr><td>N04.FR.05</td><td>When the Charging Station receives a SetVariableMonitoringRequest with an MonitorType which is not supported by the specific Variable</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: UnsupportedMonitorType.</td><td></td></tr><tr><td>N04.FR.06</td><td>When the Charging Station receives a SetVariableMonitoringRequest with monitor type UpperThreshold or LowerThreshold AND the monitorValue is lower or higher than the range of the given Variable</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: Rejected.</td><td>More information can be provided in the optional statusInfo element.</td></tr><tr><td>N04.FR.07</td><td>When the Charging Station receives a SetVariableMonitoringRequest for a monitor that conflicts with safety requirements.</td><td>The Charging Station MAY set the attributeStatus field in the corresponding SetMonitoringResult to: Rejected.</td><td>e.g. when the requested monitoring overrides factory set security monitoring.</td></tr><tr><td>N04.FR.08</td><td>When the Charging Station was able to set the given monitorValue in the SetMonitoringData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: Accepted.</td><td>Please refer to use case N07 - Alert Event on how to handle the different monitor types.</td></tr><tr><td>N04.FR.09</td><td></td><td>The maximum size and number of items of monitoringData in one SetVariableMonitoringRequest message is determined by the ItemsPerMessageSetVariableMonitoring and BytesPerMessageSetVariableMonitoring Configuration Variables.</td><td></td></tr><tr><td>N04.FR.10</td><td>When the Charging Station receives a SetVariableMonitoringRequest for a component/variable combination for which a monitor with the same type and severity already exists with a different id.</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: Duplicate.</td><td>There cannot be two monitors of the same type with the same severity on the same variable. E.g. when a component/variable has a monitor with an UpperThreshold at value "67" and severity "4-Error", then there cannot be another UpperThreshold at value "78" with same severity "4-Error" defined.</td></tr><tr><td>N04.FR.11</td><td>When the Charging Station receives a SetVariableMonitoringRequest without an Id AND N04.FR.08</td><td>The Charging Station will generate an Id and return it in the SetVariableMonitoringResponse.</td><td></td></tr><tr><td>N04.FR.12</td><td>When the Charging Station receives a SetVariableMonitoringRequest with an Id AND A monitor exists matching the given Id AND The given Component/Variable combination corresponds with the existing VariableMonitor.</td><td>The Charging Station SHALL replace the monitor.</td><td></td></tr><tr><td>N04.FR.13</td><td>When the Charging Station receives a SetVariableMonitoringRequest with an Id AND No monitor exists matching the given Id.</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: Rejected.</td><td></td></tr><tr><td>N04.FR.14</td><td>When the Charging Station receives a SetVariableMonitoringRequest with type Delta and value contains a negative value.</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: Rejected.</td><td>More information can be provided in the optional statusInfo element.</td></tr><tr><td>N04.FR.15</td><td>N04.FR.12 AND The replaced VariableMonitor belonged to the 'PreconfiguredMonitors'.</td><td>The new VariableMonitor shall be classified as a 'CustomMonitor', until reset by a SetMonitoringBaseRequest.</td><td></td></tr><tr><td>N04.FR.16</td><td>When the Charging Station receives a SetVariableMonitoringRequest with an Id AND a monitor exists matching the given Id AND the given Component/Variable combination does NOT correspond with the existing VariableMonitor.</td><td>The Charging Station SHALL respond with Rejected AND NOT replace the VariableMonitor.</td><td>It is not allowed to change Variable or Component of a monitor.</td></tr><tr><td>N04.FR.17</td><td>When the CSMS sends a SetVariableMonitoringRequest with type Delta for a Variable that is NOT of a numeric type</td><td>It is RECOMMENDED to use a monitorValue of 1.</td><td>monitorValue is irrelevant for non-numeric types (e.g. any type except decimal or integer), since the monitor is triggered by every change of the Variable.</td></tr><tr><td>N04.FR.18</td><td>N04.FR.12 AND The id in the SetVariableMonitoringRequest refers to a HardWiredMonitor</td><td>The Charging Station SHALL respond with Rejected AND NOT replace the VariableMonitor.</td><td>It is not possible to change a hardwired monitor.</td></tr><tr><td>N04.FR.19</td><td>The Charging Station has rebooted</td><td>The CSMS IS RECOMMENDED to send a GetMonitoringReportRequest message to get a new list of monitors.</td><td>Custom monitors are persistent after reboot or firmware update, but IDs may have changed.</td></tr></table>
+
+# N05 - Set Monitoring Level
+
+Table 222. N05 - Set Monitoring Level
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set Monitoring Level</td></tr><tr><td>2</td><td>ID</td><td>N05</td></tr><tr><td></td><td>Functional block</td><td>N. Diagnostics</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to request the Charging Station to restrict the reporting of monitoring events by NotifyEventRequest to only those monitors with a severity number lower than or equal to a certain severity.</td></tr><tr><td>4</td><td>Description</td><td>It may be desirable to restrict the reporting of monitoring events, to only those monitors with a severity number lower than or equal to a certain severity. For example when the data-traffic between Charging Station and CSMS needs to limited for some reason. The CSMS can control which events it will to be notified of by the Charging Station with the SetMonitoringLevelRequest message.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request a Charging Station to restrict the reporting of monitoring events, by setting a severity level limit.
+2. The CSMS sends a SetMonitoringLevelRequest to the Charging Station.
+3. The Charging Station responds with a SetMonitoringLevelResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Station supports Monitoring</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station restricted the reporting of monitoring events by NotifyEventRequest to only those wanted by the user.</td></tr></table>
+
+
+Figure 135. Sequence Diagram: Set Monitoring Level
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# N05 - Set Monitoring Level - Requirements
+
+Table 223. N05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N05.FR.01</td><td>When the Charging Station accepts a setMonitoringLevelRequest</td><td>The Charging Station SHALL send a setMonitoringLevelResponse with Accepted.</td></tr><tr><td>N05.FR.02</td><td>When the Charging Station receives a setMonitoringLevelRequest for a severity that is out of range</td><td>The Charging Station SHALL send a setMonitoringLevelResponse with Rejected.</td></tr><tr><td>N05.FR.03</td><td>N05.FR.01</td><td>The Charging Station SHALL restrict the reporting of monitoring events by NotifyEventRequest to only those monitors with a severity number lower than or equal to the given severity.</td></tr></table>
+
+# N06 - Clear / Remove Monitoring
+
+Table 224. N06 - Clear / Remove Monitoring
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Clear / Remove Monitoring</td></tr><tr><td>2</td><td>ID</td><td>N06</td></tr><tr><td></td><td>Functional block</td><td>N. Diagnostics</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to clear / remove monitoring settings.</td></tr><tr><td>4</td><td>Description</td><td>A monitoring setting can be cleared (removed) by sending a ClearVariableMonitoringRequest with the id of the monitoring setting.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request clearing/removing one or more variables in a Charging Station.
+2. The CSMS sends a ClearVariableMonitoringRequest to the Charging Station.
+3. The Charging Station responds with a ClearVariableMonitoringResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Station supports Monitoring</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station cleared / removed the requested monitoring settings.</td></tr></table>
+
+
+Figure 136. Sequence Diagram: Clear / Remove Monitoring
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# N06 - Clear / Remove Monitoring - Requirements
+
+Table 225. N06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N06.FR.01</td><td>When the Charging Station accepts a ClearVariableMonitoringRequest</td><td>The Charging Station SHALL send a ClearVariableMonitoringResponse with Accepted.</td></tr><tr><td>N06.FR.02</td><td>When the Charging Station receives a ClearVariableMonitoringRequest with a non existing id</td><td>The Charging Station SHALL send a ClearVariableMonitoringResponse with NotFound.</td></tr><tr><td>N06.FR.03</td><td>When the Charging Station receives a ClearVariableMonitoringRequest for an id referring to a monitor that cannot be cleared (for example because it is hardcoded).</td><td>The Charging Station SHALL send a ClearVariableMonitoringResponse with Rejected.</td></tr><tr><td>N06.FR.04</td><td></td><td>The CSMS SHALL NOT put more id elements in a ClearVariableMonitoringRequest than reported by the Charging Station via: ItemsPerMessageClearVariableMonitoring and BytesPerMessageClearVariableMonitoring.</td></tr><tr><td>N06.FR.05</td><td></td><td>For every id in a ClearVariableMonitoringRequest the Charging Station SHALL add a clearMonitoringResult element to the ClearVariableMonitoringResponse sent to the CSMS.</td></tr><tr><td>N06.FR.06</td><td>Charging Station receives a ClearVariableMonitoringRequest with more id elements than allowed by ItemsPerMessageClearVariableMonitoring</td><td>The Charging Station MAY respond with a CALLERROR(OccurrenceConstraintViolation)</td></tr><tr><td>N06.FR.07</td><td>Charging Station receives a ClearVariableMonitoringRequest with a length of more bytes than allowed by BytesPerMessageClearVariableMonitoring</td><td>The Charging Station MAY respond with a CALLERROR(FormatViolation)</td></tr></table>
+
+# 2.3. Monitoring Events
+
+# N07 - Alert Event
+
+Table 226. N07 - Alert Event
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Alert Event</td></tr><tr><td>2</td><td>ID</td><td>N07</td></tr><tr><td></td><td>Functional block</td><td>N. Diagnostics</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the Charging Station the ability to notify the CSMS about monitoring events.</td></tr><tr><td>4</td><td>Description</td><td>NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. If a threshold or a delta value has exceeded, the Charging Station sends a NotifyEventRequest to the CSMS.
+2. The CSMS responds with a NotifyEventResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station has active monitoring settings.
+The monitoring setting(s) might have been configured explicitly via a SetVariableMonitoring message or it might be "hard-wired" in the Charging Station's firmware.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station notified the CSMS about the monitoring events.</td></tr></table>
+
+
+Figure 137. Sequence Diagram: Alert Event
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Requirement N07.FR.04 states that events with a severity equal or less than OfflineMonitoringEventQueuingSeverity shall be queued while the charging station is offline, and delivered once online. This implies that events with a severity greater than OfflineMonitoringEventQueuingSeverity will not be sent to CSMS. The result is, that the logical chain of events may be broken when the charging station is back online.For example, a monitoring event for a variable exceeding a threshold occurred while offline and was not sent. Once back online, at some point in time the monitoring event is reported with the variable cleared set to true, but CSMS did not even know that the threshold had been exceeded.CSMS will have to be able to deal with that.This problem can be prevented, while still adhering to the specification, by not simply discarding these monitoring events, but by delaying the evaluation of those monitors that exceed OfflineMonitoringEventQueuingSeverity, until the charging station comes back online. The result is, that when the charging station is back online, CSMS will get the monitoring events that apply to the current situation, and it is fully up-to-date regarding the monitors. Only those monitoring events that were triggered & cleared during the offline period will remain invisible to CSMS.</td></tr></table>
+
+# N07 - Alert Event - Requirements
+
+Table 227. N07 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N07.FR.02</td><td>When a monitored value returns to within the set UpperThreshold or LowerThreshold</td><td>The Charging Station SHALL send a NotifyEventRequest with an eventData with the attribute cleared is true.</td><td></td></tr><tr><td>N07.FR.03</td><td>When the CSMS receives an notifyEventRequest</td><td>The CSMS SHALL respond with an empty NotifyEventResponse.</td><td></td></tr><tr><td>N07.FR.04</td><td>When a monitor is triggered AND The severity number of the monitor is equal to or lower than the severity number set in the Configuration Variable OfflineMonitoringEventQueuingSeverity AND The Charging Station is offline</td><td>The Charging Station SHALL queue this NotifyEventRequest and deliver it when it is back online.</td><td></td></tr><tr><td>N07.FR.05</td><td>When a monitor is triggered AND another event caused this event</td><td>The Charging Station MAY include the eventId of the other event in the cause field of the eventData element in the NotifyEventRequest message.</td><td></td></tr><tr><td>N07.FR.06</td><td>When a monitor is triggered</td><td>An eventData element in a NotifyEventRequest SHALL contain the Component, Variable and variableMonitoringId that caused the event.</td><td></td></tr><tr><td>N07.FR.07</td><td>When a monitor is triggered</td><td>The Charging Station SHALL set the seqNo of the first NotifyEventRequest sent for this event to 0.</td><td></td></tr><tr><td>N07.FR.10</td><td>When a monitor is triggered AND A variableMonitoring setting has been set on a write-only variable.</td><td>The actualField of the NotifyEventRequest SHALL be empty.</td><td></td></tr><tr><td>N07.FR.11</td><td>When modifying a set UpperThreshold or LowerThreshold VariableMonitor.</td><td>The Charging Station SHALL check if the new threshold clears the old threshold OR if the new threshold is exceeded by the monitored value.</td><td></td></tr><tr><td>N07.FR.12</td><td>When removing a set UpperThreshold or LowerThreshold VariableMonitor AND the threshold was exceeded.</td><td>The Charging Station SHALL NOT send a NotifyEventRequest with an eventData with the attribute cleared is true.</td><td></td></tr><tr><td>N07.FR.13</td><td></td><td>A VariableMonitoring needs to be stored persistently across reboot.</td><td></td></tr><tr><td>N07.FR.14</td><td>When a variableMonitoring setting of type UpperThreshold or LowerThreshold has been triggered AND after a reboot occurred the monitored value returned within the configured threshold.</td><td>The Charging Station SHALL send a NotifyEventRequest with an eventData with the attribute cleared is true.</td><td></td></tr><tr><td>N07.FR.15</td><td>When a monitor is triggered AND The severity of the monitor is greater than the monitoring severity level set in a SetMonitoringLevelRequest by the CSMS (see use case N05 - Set Monitoring Level)</td><td>The Charging Station SHALL NOT send a NotifyEventRequest for the triggered monitor.</td><td></td></tr><tr><td>N07.FR.16</td><td>When there is a monitor with type UpperThreshold on a Component/Variable combination AND the Actual value (attributeType Actual) of the Variable exceeds monitorValue</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Alerting for the triggered monitor.</td><td>Notification is sent when exceeding the threshold, not on the threshold.</td></tr><tr><td>N07.FR.17</td><td>When there is a monitor with type LowerThreshold on a Component/Variable combination AND the Actual value (attributeType Actual) of the Variable drops below monitorValue</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Alerting for the triggered monitor.</td><td>Notification is sent when dropping below the threshold, not on the threshold.</td></tr><tr><td>N07.FR.18</td><td>When there is a monitor with type Delta on a Component/Variable combination AND the Variable is of a numeric type AND the Actual value (attributeType Actual) of the Variable has changed more than plus or minus monitorValue since the time that this monitor was set or since the last time this event notice was sent, whichever was last</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Delta for the triggered monitor.</td><td></td></tr><tr><td>N07.FR.19</td><td>When there is a monitor with type Delta on a Component/Variable combination AND the Variable is NOT of a numeric type AND the Actual value (attributeType Actual) of the Variable has changed since the time that this monitor was set or since the last time this event notice was sent, whichever was last (Note: For variables that are not numeric, like boolean, string or enumerations, a monitor of type Delta will trigger an event notice whenever the variable changes, regardless of the value of monitorValue)</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Delta for the triggered monitor.</td><td></td></tr></table>
+
+# N08 - Periodic Event
+
+Table 228. N08 - Periodic Event
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Periodic Event</td></tr><tr><td>2</td><td>ID</td><td>N08</td></tr><tr><td></td><td>Functional block</td><td>N. Diagnostics</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the Charging Station the ability to notify the CSMS periodically about monitoring events.</td></tr><tr><td>4</td><td>Description</td><td>NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. If a periodic value has exceeded, the Charging Station sends a NotifyEventRequest with trigger periodic to the CSMS.
+2. The CSMS responds with a NotifyEventResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station has active monitoring settings.
+The monitoring setting(s) might have been configured explicitly via a SetVariableMonitoring message or it might be "hard-wired" in the Charging Station's firmware.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station notified the CSMS about the monitoring events.</td></tr></table>
+
+
+Figure 138. Sequence Diagram: Periodic Event
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# N08 - Periodic Event - Requirements
+
+Table 229. N08 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N08.FR.02</td><td>When the CSMS receives an NotifyEventRequest</td><td>The CSMS SHALL respond with an empty NotifyEventResponse.</td></tr><tr><td>N08.FR.03</td><td>N08.FR.06 OR N08.FR.07 AND The severity number of the monitor is equal to or lower than the severity number set in the Configuration Variable OfflineMonitoringEventQueueingSeverity AND The Charging Station is offline</td><td>The Charging Station SHALL queue this NotifyEventRequest and deliver it when it is back online.</td></tr><tr><td>N08.FR.04</td><td>N08.FR.06 OR N08.FR.07 AND This NotifyEventRequest is the first or only report part.</td><td>The Charging Station SHALL set seqNo to 0.</td></tr><tr><td>N08.FR.05</td><td>N08.FR.06 OR N08.FR.07 AND When the variableMonitoring setting which triggered the event is either of type Periodic or PeriodicClockAligned</td><td>The Charging Station SHALL set trigger to Periodic.</td></tr><tr><td>N08.FR.06</td><td>When there is a monitor with type Periodic on a Component/Variable combination AND the number of seconds specified in monitorValue have passed (starting from the time that this monitor was set or triggered)</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Periodic for the triggered monitor.</td></tr><tr><td>N08.FR.07</td><td>When there is a monitor with type PeriodicClockAligned on a Component/Variable combination AND the number of seconds specified by monitorValue, starting from the nearest clock-aligned interval after this monitor was set, have passed (For example, a monitorValue of 900 will trigger event notices at 0, 15, 30 and 45 minutes after the hour, every hour)</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Periodic for the triggered monitor.</td></tr></table>
+
+# 2.4. Customer Information
+
+# N09 - Get Customer Information
+
+Table 230. N09 - Get Customer Information
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Customer Information</td></tr><tr><td>2</td><td>ID</td><td>N09</td></tr><tr><td></td><td>Functional block</td><td>N. Diagnostics</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to retrieve raw customer information from a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS sends a message to the Charging Station to retrieve raw customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a CustomerInformationRequest with the report flag set to true to the Charging Station with a reference to a customer (idToken, customerCertificate or customerIdentifier).2. The Charging Station responds with CustomerInformationResponse, indicating whether it will send it or not.3. The Charging Station sends one or more NotifyCustomerInformationRequest messages to the CSMS.4. The CSMS responds with one or more NotifyCustomerInformationResponse messages to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS has Successfully received a CustomerInformationResponse message with status Accepted AND has Successfully received the requested data.</td></tr></table>
+
+
+Figure 139. Sequence Diagram: Get Customer Information
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# N09 - Get Customer Information - Requirements
+
+Table 231. N09 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N09.FR.01</td><td>When the CSMS wants to retrieve CustomerInformation from the Charging Station.</td><td>The report flag in the CustomerInformationRequest SHALL be set to true.</td><td></td></tr><tr><td>N09.FR.02</td><td>When the Charging Station receives a CustomerInformationRequest AND it is in a state where it can process this request.</td><td>the Charging Station SHALL respond with a CustomerInformationResponse message with status Accepted .</td><td></td></tr><tr><td>N09.FR.03</td><td>When the Charging Station is in a state where it cannot process this request.</td><td>On receipt of the CustomerInformationRequest the Charging Station SHALL respond with a CustomerInformationResponse with status Rejected .</td><td></td></tr><tr><td>N09.FR.04</td><td></td><td>The CSMS SHALL include a reference to a customer by including either an idToken, customerCertificate or customerIdentifier in the CustomerInformationRequest.</td><td></td></tr><tr><td>N09.FR.05</td><td>N09.FR.02 AND the Charging Station has information stored about the customer referred to by the customer identifier</td><td>The Charging Station SHALL send the requested information via one or more NotifyCustomerInformationRequest messages to the CSMS.</td><td></td></tr><tr><td>N09.FR.06</td><td>N09.FR.02 AND the Charging Station has no information stored about the customer referred to by the customer identifier.</td><td>The Charging Station SHALL send one NotifyCustomerInformationRequest message to the CSMS indicating that no data was found.</td><td></td></tr><tr><td>N09.FR.07</td><td>When receiving a CustomerInformationRequest with both the report flag as well as the clear flag are set to false</td><td>It is RECOMMENDED to respond with status a CustomerInformationResponse message with status Rejected .</td><td></td></tr><tr><td>N09.FR.08</td><td>When requesting user information according to the customerCertificate</td><td>The CSMS SHALL use the hashAlgorithm, which was used to install the certificate.</td><td>When a new firmware is installed it is RECOMMENDED that the CSMS requests the certificate first using GetInstalledCertificates Request to be sure of the used hashAlgorithm.</td></tr><tr><td>N09.FR.09</td><td>When CustomerInformationRequest contains none of idToken, customerCertificate or customerIdentifier OR CustomerInformationRequest contains more than one of idToken, customerCertificate or customerIdentifier</td><td>Charging Station SHALL respond with status = Invalid</td><td>Only one value for either idToken, customerCertificate or customerIdentifier may be provided. Charging Station counterpart requirement of N09.FR.04.</td></tr></table>
+
+# N10 - Clear Customer Information
+
+Table 232. N10 - Clear Customer Information
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Clear Customer Information</td></tr><tr><td>2</td><td>ID</td><td>N10</td></tr><tr><td></td><td>Functional block</td><td>N. Diagnostics</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to clear (and retrieve) raw customer information from a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS sends a message to the Charging Station to clear (and retrieve) raw customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends CustomerInformationRequest with the clear flag set to true to the Charging Station with a reference to a customer (idToken, customerCertificate or customerIdentifier).2. The Charging Station responds with CustomerInformationResponse, indicating whether it will send it or not.3. If the report flag is set to true, the Charging Station sends one or more NotifyCustomerInformationRequest messages to the CSMS.4. The CSMS responds with one or more NotifyCustomerInformationResponse messages to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS has Successfully received a CustomerInformationResponse message with status Accepted, the Charging Station has removed the customer information as requested and (if report flag was set to true) the CSMS has Successfully received the removed data.</td></tr></table>
+
+
+Figure 140. Sequence Diagram: Clear Customer Information
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# N10 - Clear Customer Information - Requirements
+
+Table 233. N10 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N10.FR.01</td><td>When the Charging Station receives a CustomerInformationRequest AND it is in a state where it can process this request.</td><td>the Charging Station SHALL respond with a CustomerInformationResponse message with status Accepted .</td><td></td></tr><tr><td>N10.FR.02</td><td>When the Customer referred to by the customer identifier is present in the Local Authorization List of a Charging Station</td><td>The CSMS SHALL update the Local Authorization List using the SendLocalListRequest (see D01 - Send Local Authorization List).</td><td>To prevent problems with Local Authorization List versions.</td></tr><tr><td>N10.FR.03</td><td>N10.FR.01 AND receiving a CustomerInformationRequest with the clear flag set to true and the report flag set to true AND the Charging Station has information stored about the customer referred to by the customer identifier.</td><td>The Charging Station SHALL remove all customer related data for the Customer referred to by the customer identifier from the Charging Station, except from the LocalList AND the Charging Station SHALL send the cleared information via one or more NotifyCustomerInformationRequest messages to the CSMS.</td><td>To prevent problems with LocalList versions only the CSMS can change the contents of the LocalList.</td></tr><tr><td>N10.FR.04</td><td>N10.FR.01 AND receiving a CustomerInformationRequest with the clear flag set to true and the report flag set to true AND the Charging Station has no information stored about the customer referred to by the customer identifier.</td><td>The Charging Station SHALL send one NotifyCustomerInformationRequest message to the CSMS indicating that no data was found.</td><td></td></tr><tr><td>N10.FR.05</td><td>When the Charging Station receives a CustomerInformationRequest and is in a state where it cannot process this request.</td><td>The Charging Station SHALL respond with a CustomerInformationResponse with status Rejected</td><td></td></tr><tr><td>N10.FR.06</td><td>N10.FR.01 AND receiving a CustomerInformationRequest with the clear flag set to true, the report flag set to false</td><td>The Charging Station SHALL remove all customer related data for the Customer referred to by the customer identifier from the Charging Station, except from the LocalList AND the Charging Station SHALL send one NotifyCustomerInformationRequest message to the CSMS indicating that the data was cleared.</td><td>To prevent problems with LocalList versions only the CSMS can change the contents of the LocalList.</td></tr><tr><td>N10.FR.07</td><td>When receiving a CustomerInformationRequest with both the report flag as well as the clear flag are set to false</td><td>It is RECOMMENDED to respond with a CustomerInformationResponse message with status Rejected.</td><td></td></tr><tr><td>N10.FR.08</td><td></td><td>The CSMS SHALL include a reference to a customer by including either an idToken, customerCertificate or customerIdentifier in the CustomerInformationRequest.</td><td></td></tr><tr><td>N10.FR.09</td><td>When clearing user information according to the customerCertificate</td><td>The CSMS SHALL use the hashAlgorithm, which was used to install the certificate.</td><td>When a new firmware is installed it is RECOMMENDED that the CSMS requests the certificate first using GetInstalledCertificatesRequest to be sure of the used hashAlgorithm.</td></tr></table>
+
+# O. DisplayMessage
+
+# 1. Introduction
+
+With the DisplayMessage feature, OCPP enables a CSO to display a message or a cycle of messages on a Charging Station, that is not part of the firmware of the Charging Station. The CSO gets control over these messages: the CSO can set, retrieve (get), replace and clear messages.
+
+Every message can be configured in different languages and different message formats. See DisplayMessageSupportedFormats. So the Charging Station can select the correct format/language when it needs to display a message to a user. Every message the CSO sends to the Charging Station has some parameters to control when and how a message is shown: priority, state, start/end time etc. See DisplayMessageSupportedPriorities.
+
+# NOTE
+
+It is not possible to retrieve/modify messages not configured via SetDisplayMessageRequest. (In other words: Message coded in the firmware of a Charging Station cannot be modified.)
+
+# 2. Use cases & Requirements
+
+# 001 - Set DisplayMessage
+
+Table 234.001 - Set DisplayMessage
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set DisplayMessage</td></tr><tr><td>2</td><td>ID</td><td>001</td></tr><tr><td></td><td>Functional block</td><td>O. DisplayMessage</td></tr><tr><td>3</td><td>Objectives</td><td>To enable a CSO to display additional messages on a Charging Station that are not part of the firmware.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a CSO can set a message to be displayed on a Charging Station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>CSO, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO configures the CSMS to send a request to set a new message.
+2. The CSMS sends a SetDisplayMessageRequest message to the Charging Station.
+3. The Charging Station accepts the request by sending a SetDisplayMessageResponse message to the CSMS.
+4. The Charging Station shows the new message on the display at the configured moment.</td></tr><tr><td></td><td>Alternative scenario's</td><td>002 - Set DisplayMessage for Transaction
+006 - Replace DisplayMessage</td></tr><tr><td>5</td><td>Prerequisites</td><td>No messages configured with the same IDs.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The new message will be displayed on the Charging Station (time, duration and position depending on configuration)</td></tr></table>
+
+
+Figure 141. Set DisplayMessage sequence diagram
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The maximum number of messages that can be stored in a Charging Station can be read by the CSMS in the Configuration Variable:NumberOfDisplayMessages.maxLimit.</td></tr></table>
+
+# 001 - Set DisplayMessage - Requirements
+
+Table 235.001 - Set DisplayMessage - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>001.FR.01</td><td>When the Charging Station receives a
+MessageInfo object via a
+SetDisplayMessageRequest and the priority of
+the message is not supported by the Charging
+Station</td><td>The Charging Station SHALL send a
+SetDisplayMessageResponse with status: NotSupportedPriority.</td></tr><tr><td>001.FR.02</td><td>When the Charging Station receives a
+MessageInfo object via a
+SetDisplayMessageRequest and the state of the
+message is not supported by the Charging
+Station</td><td>The Charging Station SHALL send a
+SetDisplayMessageResponse with status: NotSupportedState.</td></tr><tr><td>001.FR.03</td><td>When the Charging Station receives a
+MessageInfo object via a
+SetDisplayMessageRequest and the format of
+the message is not supported by the Charging
+Station</td><td>The Charging Station SHALL send a
+SetDisplayMessageResponse with status:
+NotSupportedMessageFormat.</td></tr><tr><td>001.FR.04</td><td></td><td>When a CSMS sends a message to a Charging Station that does
+not belong to a transaction, the field: transactionId in the
+Message field SHALL be omitted.</td></tr><tr><td>001.FR.05</td><td></td><td>The CSMS MAY include astartTime andEndTime when setting a
+message.</td></tr><tr><td>001.FR.06</td><td>001.FR.05</td><td>The Charging Station SHALL NOT display the DisplayMessage
+message before thestartTime.</td></tr><tr><td>001.FR.07</td><td>001.FR.05</td><td>The Charging Station SHALL remove a DisplayMessage
+message after theendTime.</td></tr><tr><td>001.FR.08</td><td>When the Charging Station knows the language
+preferences of the EV Driver</td><td>The Charging Station SHALL display the DisplayMessage
+message in the preferred language, if available.</td></tr><tr><td>001.FR.09</td><td>001.FR.08</td><td>When no matching language is available, it is RECOMMENDED to
+show a DisplayMessage message in English as fall-back, if
+available.</td></tr><tr><td>001.FR.10</td><td></td><td>The Charging Station SHALL store the messages in persistent
+storage, so they survive a power cycle/reboot of the Charging
+Station.</td></tr><tr><td>001.FR.11</td><td>When the Charging Station receives a
+SetDisplayMessageRequest and the total
+number of messages after having handled this
+request will exceed
+NumberOfDisplayMessages.maxLimit.</td><td>The Charging Station SHALL respond with status: Rejected.</td></tr><tr><td>001.FR.12</td><td>When the Charging Station receives a
+SetDisplayMessageRequest and the priority of
+the message is NormalCycle</td><td>The Charging Station SHALL show this message at the
+configured moment in the normal cycle of messages.</td></tr><tr><td>001.FR.13</td><td>When the Charging Station receives a
+SetDisplayMessageRequest and the priority of
+the message is InFront</td><td>The Charging Station SHALL show this message at the
+configured moment, regardless of the normal cycle of
+messages.</td></tr><tr><td>001.FR.14</td><td>When multiple messages with priority InFront
+are configured to be shown at the same time</td><td>The Charging Station SHALL cycle these messages.</td></tr><tr><td>001.FR.15</td><td>When the Charging Station receives a
+SetDisplayMessageRequest and the priority of
+the message is AlwaysFront</td><td>The Charging Station SHALL show this message at the
+configured moment, regardless of other installed messages.
+Hence, it shall not cycle it with other messages and the Charging
+Station's own messages shall not override this message.</td></tr><tr><td>001.FR.16</td><td>001.FR.15 AND
+Another message with priority AlwaysFront is
+already set</td><td>The Charging Station SHALL replace the old message with the
+newly set message.</td></tr><tr><td>001.FR.17</td><td></td><td>Language SHALL be specified as RFC-5646 tags, see: [RFC5646],
+example: US English is: "en-US"</td></tr></table>
+
+# 002 - Set DisplayMessage for Transaction
+
+Table 236.002 - Set DisplayMessage for Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set DisplayMessage for Transaction</td></tr><tr><td>2</td><td>ID</td><td>002</td></tr><tr><td></td><td>Functional block</td><td>0. DisplayMessage</td></tr><tr><td></td><td>Parent use case</td><td>001 - Set DisplayMessage</td></tr><tr><td>3</td><td>Objectives</td><td>To enable a CSO to display messages during an ongoing transaction on a Charging Station that are not build in to the firmware.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a CSO can set a message to be displayed on a Charging Station for a specific transaction. Depending on the given parameters the message shall be displayed a certain way on the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>CSO, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO configures the CSMS to send a request to show a new message during a given transaction.
+2. The CSMS sends a SetDisplayMessageRequest message with the transactionId to the Charging Station.
+3. The Charging Station accepts the request by sending a SetDisplayMessageResponse message to the CSMS.
+4. The Charging Station shows the new message on the display while the transaction is ongoing.</td></tr><tr><td></td><td>Alternative scenario's</td><td>001 - Set MessageMessage
+006 - Replace MessageMessage</td></tr><tr><td>5</td><td>Prerequisites</td><td>No messages configured with the same IDs.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The new message will be displayed on the Charging Station while the transaction is ongoing (time, duration and position depend on configuration)</td></tr></table>
+
+
+Figure 142. Set DisplayMessage for transaction sequence diagram
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The maximum number of messages that can be stored in a Charging Station can be read by the CSMS in the Configuration Variable:NumberOfDisplayMessages.maxLimit.</td></tr></table>
+
+# 002 - Set DisplayMessage for Transaction - Requirements
+
+Table 237.002 - Set DisplayMessage for Transaction - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>002.FR.01</td><td>When the Charging Station receives a Message object via a SetDisplayMessageRequest and the transactionId of the message is not known by the Charging Station</td><td>The Charging Station SHALL send a SetDisplayMessageResponse with status: UnknownTransaction.</td></tr><tr><td>002.FR.02</td><td>When the transaction with the given transactionId ends</td><td>The Charging Station SHALL remove the message from the list of messages.</td></tr><tr><td>002.FR.03</td><td>When the Charging Station receives a MessagingInfo object via a SetDisplayMessageRequest and the priority of the message is not supported by the Charging Station</td><td>The Charging Station SHALL send a SetDisplayMessageResponse with status: NotSupportedPriority.</td></tr><tr><td>002.FR.04</td><td>When the Charging Station receives a MessagingInfo object via a SetDisplayMessageRequest and the state of the message is not supported by the Charging Station</td><td>The Charging Station SHALL send a SetDisplayMessageResponse with status: NotSupportedState.</td></tr><tr><td>002.FR.05</td><td>When the Charging Station receives a MessagingInfo object via a SetDisplayMessageRequest and the format of the message is not supported by the Charging Station</td><td>The Charging Station SHALL send a SetDisplayMessageResponse with status: NotSupportedMessageFormat.</td></tr><tr><td>002.FR.06</td><td></td><td>The Charging Station SHALL NOT display the DisplayMessage message before the startTime.</td></tr><tr><td>002.FR.07</td><td></td><td>The Charging Station SHALL remove a DisplayMessage message after the endTime.</td></tr><tr><td>002.FR.08</td><td>When the Charging Station knows the language preferences of the EV Driver</td><td>The Charging Station SHALL display the DisplayMessage message in the preferred language, if available.</td></tr><tr><td>002.FR.09</td><td>002.FR.08</td><td>When no matching language is available, it is RECOMMENDED to show a DisplayMessage message in English as fall-back, if available.</td></tr><tr><td>002.FR.10</td><td></td><td>The Charging Station SHALL store the messages in persistent storage, so they survive a power cycle/reboot of the Charging Station.</td></tr><tr><td>002.FR.11</td><td>When the Charging Station receives a SetDisplayMessageRequest and the total number of messages after having handled this request will exceed NumberOfDisplayMessages.maxLimit.</td><td>The Charging Station SHALL respond with status: Rejected.</td></tr><tr><td>002.FR.12</td><td></td><td>Language SHALL be specified as RFC-5646 tags, see: [RFC5646], example: US English is: "en-US"</td></tr><tr><td>002.FR.14</td><td>When the Charging Station receives a SetDisplayMessageRequest and the priority of the message is NormalCycle</td><td>The Charging Station SHALL show this message in the normal cycle of messages.</td></tr><tr><td>002.FR.15</td><td>When the Charging Station receives a SetDisplayMessageRequest and the priority of the message is InFront</td><td>The Charging Station SHALL show this message at the configured moment, regardless of the normal cycle of messages.</td></tr><tr><td>002.FR.16</td><td>When multiple messages with priority InFront are configured to be shown at the same time</td><td>The Charging Station SHALL cycle these messages.</td></tr><tr><td>002.FR.17</td><td>When the Charging Station receives a SetDisplayMessageRequest and the priority of the message is AlwaysFront</td><td>The Charging Station SHALL show this message at the configured moment, regardless of other installed messages. Hence, it shall not cycle it with other messages and the Charging Station's own message shall not override this message.</td></tr><tr><td>002.FR.18</td><td>002.FR.17 AND Another message with priority AlwaysFront is already set</td><td>The Charging Station SHALL replace the old message with the newly set message.</td></tr></table>
+
+# 003 - Get All DisplayMessages
+
+Table 238.003 - Get All DisplayMessage IDs
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get All DisplayMessages</td></tr><tr><td>2</td><td>ID</td><td>003</td></tr><tr><td></td><td>Functional block</td><td>O. DisplayMessage</td></tr><tr><td>3</td><td>Objectives</td><td>Enable a CSO to retrieve all messages currently configured in a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a CSO can request all the installed DisplayMessages configured via OCPP in a Charging Station.
+The Charging Station can remove messages when they are out-dated, or transactions have ended.
+It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td></td><td>Actors</td><td>CSO, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO asks the CSMS to retrieve all messages.
+2. The CSMS sends a GetDisplayMessagesRequest message to the Charging Station.
+3. The Charging Station responds with a GetDisplayMessagesResponse Accepted, indicating it has configured messages and will send them.
+4. The Charging Station sends one or more NotifyDisplayMessagesRequest messages to the CSMS (depending on the amount of messages to be sent).
+5. The CSMS responds to every notify with a NotifyDisplayMessagesResponse message.</td></tr><tr><td>5</td><td>Prerequisites</td><td>There is at least one message configured in the Charging Station</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr></table>
+
+
+Figure 143. Get All DisplayMessages sequence diagram
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>Only messages configured via OCPP can be retrieved via a GetDisplayMessagesRequest.</td></tr></table>
+
+# 003 - Get All DisplayMessages - Requirements
+
+Table 239.003 - Get All DisplayMessage IDs - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>003.FR.01</td><td>When all fields except requestId in a GetDisplayMessagesRequest are omitted AND at least one display message is configured.</td><td>The Charging Station SHALL respond with Accepted.</td></tr><tr><td>003.FR.02</td><td>003.FR.01</td><td>The Charging Station SHALL send all configured DisplayMessages via NotifyDisplayMessagesRequest.</td></tr><tr><td>003.FR.03</td><td>003.FR.02 AND There are more DisplayMessages than the Charging Station can send in 1 NotifyDisplayMessagesRequest</td><td>The Charging Station SHALL split the DisplayMessages over multiple NotifyDisplayMessagesRequest messages.</td></tr><tr><td>003.FR.04</td><td>003.FR.03</td><td>The Charging Station SHALL set the tbc field is true in every NotifyDisplayMessagesRequest messages, except the last.</td></tr><tr><td>003.FR.05</td><td>003.FR.04</td><td>The Charging Station SHALL set the requestId field to the same value as the requestId in the GetDisplayMessagesRequest.</td></tr><tr><td>003.FR.06</td><td>When NO DisplayMessages are configured</td><td>The Charging Station SHALL respond with Unknown.</td></tr></table>
+
+# 004 - Get Specific DisplayMessages
+
+Table 240.004 - Get a Specific DisplayMessages
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Specific DisplayMessages</td></tr><tr><td>2</td><td>ID</td><td>004</td></tr><tr><td></td><td>Functional block</td><td>0. DisplayMessage</td></tr><tr><td>3</td><td>Objectives</td><td>Enable a CSO to retrieve one or more specific DisplayMessages, currently configured in a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a CSO can request/query for (specific) DisplayMessage, configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able query the Charging Station for installed DisplayMessages, so the CSO known which messages are (still) configured.</td></tr><tr><td></td><td>Actors</td><td>CSO, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO asks the CSMS to query for DisplayMessages.
+2. The CSMS sends a GetDisplayMessagesRequest message with the query parameters to the Charging Station.
+3. When the Charging Station has DisplayMessages that match the requested parameters, it responds with GetDisplayMessagesResponse Accepted.
+4. The Charging Station sends one or more NotifyDisplayMessagesRequest message to the CSMS (depending on the amount of messages to be send).
+5. The CSMS response every notify with a NotifyDisplayMessagesResponse message.</td></tr><tr><td>5</td><td>Prerequisites</td><td>There is a message with the given id configured in the Charging Station</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr></table>
+
+
+Figure 144. Get a specific DisplayMessages sequence diagram
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>Only message configured via OCPP can be retrieved via GetDisplayMessagesRequest.</td></tr></table>
+
+# 004 - Get Specific DisplayMessage - Requirements
+
+Table 241. 004 - Get Specific DisplayMessages - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>004.FR.01</td><td>When one or more of the fields in a GetDisplayMessagesRequest are used AND The Charging Station has DisplayMessages configured that match the parameters in the request</td><td>The Charging Station SHALL respond with Accepted.</td></tr><tr><td>004.FR.02</td><td>When one or more of the fields in a GetDisplayMessagesRequest are used AND The Charging Station has NO DisplayMessages configured that match the parameters in the request</td><td>The Charging Station SHALL respond with Unknown.</td></tr><tr><td>004.FR.03</td><td>004.FR.01</td><td>The Charging Station SHALL send all configured DisplayMessages via NotifyDisplayMessagesRequest.</td></tr><tr><td>004.FR.04</td><td>004.FR.03 AND There are more DisplayMessages than the Charging Station can send in 1 NotifyDisplayMessagesRequest</td><td>The Charging Station SHALL split the DisplayMessages over multiple NotifyDisplayMessagesRequest messages.</td></tr><tr><td>004.FR.05</td><td>004.FR.04</td><td>The Charging Station SHALL set the tbc field is true in every NotifyDisplayMessagesRequest messages, except the last.</td></tr><tr><td>004.FR.06</td><td>004.FR.05</td><td>The Charging Station SHALL set the requestId field to the same value as the requestId in the GetDisplayMessagesRequest.</td></tr><tr><td>004.FR.07</td><td>When NO DisplayMessages are configured</td><td>The Charging Station SHALL respond with Unknown.</td></tr></table>
+
+# 005 - Clear a DisplayMessage
+
+Table 242.005 - Clear a DisplayMessage
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Clear a DisplayMessage</td></tr><tr><td>2</td><td>ID</td><td>005</td></tr><tr><td></td><td>Functional block</td><td>0. DisplayMessage</td></tr><tr><td>3</td><td>Objectives</td><td>Enable a CSO to remove a specific message, currently configured in a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a CSO can remove a specific message, configured via OCPP in a Charging Station.</td></tr><tr><td></td><td>Actors</td><td>CSO, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO asks the CSMS to remove a specific message.
+2. The CSMS sends a ClearDisplayMessageRequest message with the id of the specific message to the Charging Station.
+3. The Charging Station removes the message.
+4. The Charging Station response by sending a ClearDisplayMessageResponse message to the CSMS.</td></tr><tr><td>5</td><td>Prerequisites</td><td>There is a message with the given id configured in the Charging Station</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The message with the given id is removed from the Charging Station</td></tr></table>
+
+
+Figure 145. Clear a DisplayMessage sequence diagram
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>Only messages configured via OCPP can be cleared/removed via ClearDisplayMessageRequest</td></tr></table>
+
+# 005 - Clear a DisplayMessage - Requirements
+
+Table 243.005 - Clear a DisplayMessage - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>005.FR.01</td><td>When a Charging Station receives a ClearDisplayMessageRequest AND there is a message configured in the Charging Station with that id</td><td>The Charging Station SHALL respond with a ClearDisplayMessageResponse message with status: Accepted.</td></tr><tr><td>005.FR.02</td><td>When a Charging Station receives a ClearDisplayMessageRequest AND there is no message configured in the Charging Station with the given id</td><td>The Charging Station SHALL respond with a ClearDisplayMessageResponse message with status: Unknown.</td></tr></table>
+
+# 006 - Replace DisplayMessage
+
+Table 244.006 - Replace DisplayMessage
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Replace DisplayMessage</td></tr><tr><td>2</td><td>ID</td><td>006</td></tr><tr><td></td><td>Functional block</td><td>0. DisplayMessage</td></tr><tr><td>3</td><td>Objectives</td><td>Enable a CSO to replace DisplayMessages, already configured on a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a CSO can replace a DisplayMessage that is previously configured in a Charging Station. Replace the message content, but also all the given parameters with the new one.</td></tr><tr><td></td><td>Actors</td><td>CSO, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO asks the CSMS to replace an existing DisplayMessage.
+2. The CSMS sends a SetDisplayMessageRequest message to the Charging Station with the a DisplayMessage with the same ID as already configured in the Charging Station.
+3. The Charging Station accepts the request by sending a SetDisplayMessageResponse message to the CSMS.
+4. The Charging Station shows the updated/replaced message on the display at the configured moment.</td></tr><tr><td></td><td>Alternative scenario's</td><td>001 - Set DisplayMessage and 002 - Set DisplayMessage for Transaction</td></tr><tr><td>5</td><td>Prerequisites</td><td>There is a message with the same id configured in the Charging Station</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The DisplayMessage is replaced by the one provided with the same ID.</td></tr></table>
+
+
+Figure 146. Replace DisplayMessage sequence diagram
+
+<table><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>n/a</td></tr></table>
+
+# 006 - Replace DisplayMessage - Requirements
+
+Table 245.006 - Replace DisplayMessage - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>006.FR.01</td><td>When a Charging Station receives a SetDisplayMessageRequest AND there is a message configured in the Charging Station with the same id</td><td>The Charging Station SHALL replace the existing message with the new message (including all the new parameters) AND respond with a SetDisplayMessageResponse message with status: Accepted for this message.</td></tr></table>
+
+# P. DataTransfer
+
+# 1. Introduction
+
+This Functional Block describes the functionality that enables parties to extend existing commands with custom attributes or add new custom commands to OCPP
+
+OCPP offers two mechanisms to create vendor-specific custom extension.
+
+1. The DataTransferRequest message allows for the exchange of data or messages not standardized in OCPP. As such, it offers a framework within OCPP for experimental functionality that may find its way into future OCPP versions. Experimenting can be done without creating new (possibly incompatible) OCPP dialects. Secondly, it offers a possibility to implement additional functionality agreed upon between specific CSMS and Charging Station vendors.
+2. A CustomData element exists as an optional element in the JSON schemas of all types. CustomData is the only class in the JSON schema files that allows additional properties. It can thus be used to add additional custom attributes to any type. The CustomData has been deliberately left out of the specification document, because it would introduce a lot of clutter and it is not meant to be used in standard implementations. See also [OCPP2.0-PART4].
+
+The DataTransferRequest/Response contains a field without a length or type specification. It can be convenient to use this field as structured JSON content.
+
+Example of embedded JSON
+
+```txt
+[2,
+"unique msg id>","DataTransfer",
+{ "vendorId": "com.mycompany.ice", "messageId": "iceParkedAtCs" "data": { "start_time": "2020-04-01T11:01:02" }
+]
+```
+
+# IMPORTANT
+
+Please use with extreme caution and only for optional functionality, since it will impact your compatibility with other systems that do not make use of this option. We recommend mentioning the usage explicitly in your documentation and/or communication. Please consider consulting the Open Charge Alliance before turning to this option to add functionality.
+
+# 2. Use cases & Requirements
+
+# P01 - Data Transfer to the Charging Station
+
+Table 246. P01 - Data Transfer to the Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Data Transfer to the Charging Station</td></tr><tr><td>2</td><td>ID</td><td>P01</td></tr><tr><td></td><td>Functional block</td><td>P. Data Transfer</td></tr><tr><td>3</td><td>Objective(s)</td><td>To send information from the CSMS to the Charging Station for a function that is not supported by OCPP.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers the functionality of sending a DataTransfer message to the Charging Station from the CSMS.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends information to a Charging Station for a function not supported by OCPP with DataTransferRequest.
+2. The Charging Station responds to the CSMS with DataTransferResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+DataTransferRequest is received Successfully and Accepted
+Failure postcondition:
+Message has been Accepted but the contained request is Rejected.
+In all other cases the usage of status Accepted or Rejected and the data element is part of the vendor-specific agreement between the parties involved.</td></tr></table>
+
+
+
+Figure 147. Sequence Diagram: Data Transfer to the Charging Station
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Data Transfer is used if information for a function is not supported by OCPP.
+The length of data in both the request and response message is undefined and it is RECOMMENDED that this is agreed upon by all parties involved.</td></tr></table>
+
+# P01 - Data Transfer to the Charging Station - Requirements
+
+Table 247. P01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>P01.FR.01</td><td></td><td>The Charging Station SHALL only use DataTransferRequest for a function which is not supported by OCPP.</td></tr><tr><td>P01.FR.02</td><td></td><td>The vendor should be a value from the reversed DNS namespace, where the top tiers of the name, when reversed, should correspond to the publicly registered primary DNS name of the Vendor organization.</td></tr><tr><td>P01.FR.03</td><td></td><td>The messageid in the request message MAY be used to indicate a specific message or implementation.</td></tr><tr><td>P01.FR.04</td><td></td><td>The length of data in both the request and response message is undefined and it is RECOMMENDED that this is agreed upon by all parties involved.</td></tr><tr><td>P01.FR.05</td><td>If the recipient of the request has no implementation for the specific vendorId.</td><td>The recipient SHALL return a status UnknownVendor.</td></tr><tr><td>P01.FR.06</td><td>Upon receipt of DataTransferRequest and in case of a messageld mismatch (if used).</td><td>The recipient SHALL return status UnknownMessageId.</td></tr><tr><td>P01.FR.07</td><td></td><td>The usage of status Accepted or Rejected and the data element SHALL be part of the vendor-specific agreement between the parties involved.</td></tr></table>
+
+# P02 - Data Transfer to the CSMS
+
+Table 248. P02 - Data Transfer to the CSMS
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Data Transfer to the CSMS</td></tr><tr><td>2</td><td>ID</td><td>P02</td></tr><tr><td></td><td>Functional block</td><td>P. Data Transfer</td></tr><tr><td>3</td><td>Objective(s)</td><td>To send information from the Charging Station to the CSMS for a function which is not supported by OCPP.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers the functionality of sending a DataTransfer message to the CSMS from the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends information to the CSMS for a function not supported by OCPP with DataTransferRequest.
+2. The CSMS responds to the Charging Station with DataTransferResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+DataTransferRequest is received Successfully and Accepted
+Failure postcondition:
+Message has been accepted but the contained request is Rejected.
+In all other cases the usage of status Accepted or Rejected and the data element is part of the vendor-specific agreement between the parties involved.</td></tr></table>
+
+
+
+Figure 148. Sequence Diagram: Data Transfer to the CSMS
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Data Transfer is used if information for a function is not supported by OCPP.
+The length of data in both the request and response message is undefined and should be agreed upon by all parties involved.</td></tr></table>
+
+# P02 - Data Transfer to the CSMS - Requirements
+
+Table 249. P02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>P02.FR.01</td><td></td><td>The vendorId in the request message SHOULD be known to the Charging Station and uniquely identify the vendor-specific implementation.</td></tr><tr><td>P02.FR.02</td><td></td><td>The Charging Station SHALL only use DataTransferRequest for a function which is not supported by OCPP.</td></tr><tr><td>P02.FR.03</td><td></td><td>The VendorId SHOULD be a value from the reversed DNS namespace, where the top tiers of the name, when reversed, should correspond to the publicly registered primary DNS name of the Vendor organization.</td></tr><tr><td>P02.FR.04</td><td></td><td>The msgageld in the request message MAY be used to indicate a specific message or implementation.</td></tr><tr><td>P02.FR.05</td><td></td><td>The length of data in both the request and response message is undefined and it is RECOMMENDED that this is agreed upon by all parties involved.</td></tr><tr><td>P02.FR.06</td><td>If the recipient of the request has no implementation for the specific vendorId.</td><td>The recipient SHALL return a status UnknownVendor.</td></tr><tr><td>P02.FR.07</td><td>Upon receipt of DataTransferRequest and in case of a messageld mismatch (if used).</td><td>The recipient SHALL return status UnknownMessageId.</td></tr><tr><td>P02.FR.08</td><td></td><td>The usage of status Accepted or Rejected and the data element SHALL be part of the vendor-specific agreement between the parties involved.</td></tr></table>
+
+# Messages, Datatypes & Enumerations
+
+# 1. Messages
+
+# 1.1. Authorization
+
+# 1.1.1.authorizeRequest
+
+This contains the field definition of theauthorizeRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificate</td><td>string[0..5500]</td><td>0..1</td><td>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.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>1..1</td><td>Required. This contains the identifier that needs to be authorized.</td></tr><tr><td>iso15118CertificateHashData</td><td>OCSPRequestDataType</td><td>0..4</td><td>Optional. Contains the information needed to verify the EV Contract Certificate via OCSP. Not needed if certificate is provided.</td></tr></table>
+
+# 1.1.2.authorizeResponse
+
+This contains the field definition of theauthorizeResponse PDU sent by the CSMS to the Charging Station in response to anauthorizeRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateStatus</td><td>AuthorizationCertificateStatusEnumType</td><td>0..1</td><td>Optional. Certificate status information. - if all certificates are valid: return 'Accepted'. - if one of the certificates was revoked, return 'CertificateRevoked'.</td></tr><tr><td>idTokenInfo</td><td>IdTokenInfoType</td><td>1..1</td><td>Required. This contains information about authorization status, expiry and group id.</td></tr></table>
+
+# 1.2. BootNotification
+
+# 1.2.1. BootNotificationRequest
+
+This contains the field definition of the BootNotificationRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>reason</td><td>BootReasonEnumType</td><td>1..1</td><td>Required. This contains the reason for sending this message to the CSMS.</td></tr><tr><td>chargingStation</td><td>ChargingStationType</td><td>1..1</td><td>Required. Identifies the Charging Station</td></tr></table>
+
+# 1.2.2. BootNotificationResponse
+
+This contains the field definition of the BootNotificationResponse PDU sent by the CSMS to the Charging Station in response to a BootNotificationRequest.
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>currentTime</td><td>dateTime</td><td>1..1</td><td>Required. This contains the CSMS's current time.</td></tr><tr><td>interval</td><td>integer</td><td>1..1</td><td>Required. When Status is Accepted, this contains the heartbeat interval in seconds. If the CSMS returns something other than Accepted, the value of the interval field indicates the minimum wait time before sending a next BootNotification request.</td></tr><tr><td>status</td><td>RegistrationStatusEnumType</td><td>1..1</td><td>Required. This contains whether the Charging Station has been registered within the CSMS.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.3. CancelReservation
+
+# 1.3.1. CancelReservationRequest
+
+This contains the field definition of the CancelReservationRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>reservationId</td><td>integer</td><td>1..1</td><td>Required. Id of the reservation to cancel.</td></tr></table>
+
+# 1.3.2. CancelReservationResponse
+
+This contains the field definition of the CancelReservationResponse PDU sent by the Charging Station to the CSMS in response to a CancelReservationRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>CancelReservationStatusEnumTyp e</td><td>1..1</td><td>Required. This indicates the success or failure of the canceling of a reservation by CSMS.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.4. CertificateSigned
+
+# 1.4.1. CertificateSignedRequest
+
+This contains the field definition of the CertificateSignedRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateChain</td><td>string[0..10000]</td><td>1..1</td><td>Required. The signed PEM encoded X.509 certificate. This SHALL also contain the necessary sub CA certificates, when applicable. The order of the bundle follows the certificate chain, starting from the leaf certificate. The Configuration Variable MaxCertificateChainSize can be used to limit the maximum size of this field.</td></tr><tr><td>certificateType</td><td>CertificateSigningUseEnumType</td><td>0..1</td><td>Optional. Indicates the type of the signed certificate that is returned. When omitted the certificate is used for both the 15118 connection (if implemented) and the Charging Station to CSMS connection. This field is required when a certificateType was included in the SignCertificateRequest that requested this certificate to be signed AND both the 15118 connection and the Charging Station connection are implemented.</td></tr></table>
+
+# 1.4.2. CertificateSignedResponse
+
+This contains the field definition of the CertificateSignedResponse PDU sent by the Charging Station to the CSMS in response to a CertificateSignedRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>CertificateSignedStatusEnumType</td><td>1..1</td><td>Required. Returns whether certificate signing has been accepted, otherwise rejected.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.5. ChangeAvailability
+
+# 1.5.1. ChangeAvailabilityRequest
+
+This contains the field definition of the ChangeAvailabilityRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>operationalStatus</td><td>OperationalStatusEnumType</td><td>1..1</td><td>Required. This contains the type of availability change that the Charging Station should perform.</td></tr><tr><td>evse</td><td>EVSEType</td><td>0..1</td><td>Optional. Contains Id's to designate a specific EVSE/connector by index numbers. When omitted, the message refers to the Charging Station as a whole.</td></tr></table>
+
+# 1.5.2. ChangeAvailabilityResponse
+
+This contains the field definition of the ChangeAvailabilityResponse PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ChangeAvailabilityStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station is able to perform the availability change.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.6. ClearCache
+
+# 1.6.1. ClearCacheRequest
+
+This contains the field definition of the ClearCacheRequest PDU sent by the CSMS to the Charging Station. No fields are defined.
+
+# 1.6.2. ClearCacheResponse
+
+This contains the field definition of the ClearCacheResponse PDU sent by the Charging Station to the CSMS in response to a
+
+ClearCacheRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ClearCacheStatusEnumType</td><td>1..1</td><td>Required. Accepted if the Charging Station has executed the request, otherwise rejected.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.7. ClearChargingProfile
+
+# 1.7.1. ClearChargingProfileRequest
+
+This contains the field definition of the ClearChargingProfileRequest PDU sent by the CSMS to the Charging Station. The CSMS can use this message to clear (remove) either a specific charging profile (denoted by id) or a selection of charging profiles that match with the values of the optional evse, stackLevel and ChargingProfilePurpose fields.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>chargingProfileId</td><td>integer</td><td>0..1</td><td>Optional. The Id of the charging profile to clear.</td></tr><tr><td>chargingProfileCriteria</td><td>ClearChargingProfileType</td><td>0..1</td><td>Optional. Specifies the charging profile.</td></tr></table>
+
+# 1.7.2. ClearChargingProfileResponse
+
+This contains the field definition of the ClearChargingProfileResponse PDU sent by the Charging Station to the CSMS in response to a ClearChargingProfileRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ClearChargingProfileStatusEnumType</td><td>1..1</td><td>Required. Indicates if the Charging Station was able to execute the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.8. ClearDisplayMessage
+
+# 1.8.1. ClearDisplayMessageRequest
+
+This contains the field definition of the ClearDisplayMessageRequest PDU sent by the CSMS to the Charging Station. The CSMS asks the Charging Station to clear a display message that has been configured in the Charging Station to be cleared/removed. See also 005 - Clear a Display Message.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>1..1</td><td>Required. Id of the message that SHALL be removed from the Charging Station.</td></tr></table>
+
+# 1.8.2. ClearDisplayMessageResponse
+
+This contains the field definition of the ClearDisplayMessageResponse PDU sent by the Charging Station to the CSMS in a response to a ClearDisplayMessageRequest. See also 005 - Clear a Display Message.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ClearMessageStatusEnumType</td><td>1..1</td><td>Required. Returns whether the Charging Station has been able to remove the message.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.9. ClearedChargingLimit
+
+# 1.9.1. ClearedChargingLimitRequest
+
+This contains the field definition of the ClearedChargingLimitRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>chargingLimitSource</td><td>ChargingLimitSourceEnumType</td><td>1..1</td><td>Required. Source of the charging limit.</td></tr><tr><td>evseld</td><td>integer</td><td>0..1</td><td>Optional. EVSE Identifier.</td></tr></table>
+
+# 1.9.2. ClearedChargingLimitResponse
+
+This contains the field definition of the ClearedChargingLimitResponse PDU sent by the CSMS to the Charging Station. No fields are defined.
+
+# 1.10. ClearVariableMonitoring
+
+# 1.10.1. ClearVariableMonitoringRequest
+
+This contains the field definition of the ClearVariableMonitoringRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>1..*</td><td>Required. List of the monitors to be cleared, identified by there Id.</td></tr></table>
+
+# 1.10.2. ClearVariableMonitoringResponse
+
+This contains the field definition of the ClearVariableMonitoringResponse PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>clearMonitoringResult</td><td>ClearMonitoringResultType</td><td>1..*</td><td>Required. List of result statuses per monitor.</td></tr></table>
+
+# 1.11. CostUpdated
+
+# 1.11.1. CostUpdatedRequest
+
+This contains the field definition of the CostUpdatedRequest PDU sent by the CSMS to the Charging Station. With this request the CSMS can send the current cost of a transaction to a Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>totalCost</td><td>decimal</td><td>1..1</td><td>Required. Current total cost, based on the information known by the CSMS, of the transaction including taxes. In the currency configured with the configuration Variable: [Currency]</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. Transaction Id of the transaction the current cost are asked for.</td></tr></table>
+
+# 1.11.2. CostUpdatedResponse
+
+This contains the field definition of the CostUpdatedResponse PDU sent by the Charging Station to the CSMS in response to CostUpdatedRequest. No fields are defined.
+
+# 1.12. CustomerInformation
+
+This contains the field definition of the CustomerInformationRequest PDU sent by the CSMS to the Charging Station.
+
+# 1.12.1. CustomerInformationRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of the request.</td></tr><tr><td>report</td><td>boolean</td><td>1..1</td><td>Required. Flag indicating whether the Charging Station should return NotifyCustomerInformationRequest messages containing information about the customer referred to.</td></tr><tr><td>clear</td><td>boolean</td><td>1..1</td><td>Required. Flag indicating whether the Charging Station should clear all information about the customer referred to.</td></tr><tr><td>customerIdentifier</td><td>string[0..64]</td><td>0..1</td><td>Optional. A (e.g. vendor specific) identifier of the customer this request refers to. This field contains a custom identifier other than IdToken and Certificate. One of the possible identifiers (customerIdentifier, customerIdToken or customerCertificate) should be in the request message.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>0..1</td><td>Optional. The IdToken of the customer this request refers to. One of the possible identifiers (customerIdentifier, customerIdToken or customerCertificate) should be in the request message.</td></tr><tr><td>customerCertificate</td><td>CertificateDataType</td><td>0..1</td><td>Optional. The Certificate of the customer this request refers to. One of the possible identifiers (customerIdentifier, customerIdToken or customerCertificate) should be in the request message.</td></tr></table>
+
+# 1.12.2. CustomerInformationResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>CustomerInformationStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the request was accepted.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.13. DataTransfer
+
+# 1.13.1. DataTransferRequest
+
+This contains the field definition of the DataTransferRequest PDU sent either by the CSMS to the Charging Station or vice versa.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>messageId</td><td>string[0..50]</td><td>0..1</td><td>Optional. May be used to indicate a specific message or implementation.</td></tr><tr><td>data</td><td>anyType</td><td>0..1</td><td>Optional. Data without specified length or format. This needs to be decided by both parties (Open to implementation).</td></tr><tr><td>vendorId</td><td>string[0..255]</td><td>1..1</td><td>Required. This identifies the Vendor specific implementation</td></tr></table>
+
+# 1.13.2. DataTransferResponse
+
+This contains the field definition of the DataTransferResponse PDU sent by the Charging Station to the CSMS or vice versa in response to a DataTransferRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>DataTransferStatusEnumType</td><td>1..1</td><td>Required. This indicates the success or failure of the data transfer.</td></tr><tr><td>data</td><td>anyType</td><td>0..1</td><td>Optional. Data without specified length or format, in response to request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.14. DeleteCertificate
+
+# 1.14.1. DeleteCertificateRequest
+
+Used by the CSMS to request deletion of an installed certificate on a Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateHashData</td><td>CertificateHashDataType</td><td>1..1</td><td>Required. Indicates the certificate of which deletion is requested.</td></tr></table>
+
+# 1.14.2. DeleteCertificateResponse
+
+Response to a DeleteCertificateRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>DeleteCertificateStatusEnumType</td><td>1..1</td><td>Required. Charging Station indicates if it can process the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.15. FirmwareStatusNotification
+
+# 1.15.1. FirmwareStatusNotificationRequest
+
+This contains the field definition of the FirmwareStatusNotificationRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>FirmwareStatusEnumType</td><td>1..1</td><td>Required. This contains the progress status of the firmware installation.</td></tr><tr><td>requestId</td><td>integer</td><td>0..1</td><td>Optional. The request id that was provided in the UpdateFirmwareRequest that started this firmware update. This field is mandatory, unless the message was triggered by a TriggerMessageRequest AND there is no firmware update ongoing.</td></tr></table>
+
+# 1.15.2. FirmwareStatusNotificationResponse
+
+This contains the field definition of the FirmwareStatusNotificationResponse PDU sent by the CSMS to the Charging Station in response to a FirmwareStatusNotificationRequest. No fields are defined.
+
+# 1.16. Get15118EVCertificate
+
+# 1.16.1. Get15118EVCertificateRequest
+
+This message is sent by the Charging Station to the CSMS if an ISO 15118 vehicle selects the service Certificate installation. NOTE: This message is based on CertificateInstallationReq Res from ISO 15118 2.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>iso15118SchemaVersion</td><td>string[0..50]</td><td>1..1</td><td>Required. Schema version currently used for the 15118 session between EV and Charging Station. Needed for parsing of the EXI stream by the CSMS.</td></tr><tr><td>action</td><td>CertificateActionEnumType</td><td>1..1</td><td>Required. Defines whether certificate needs to be installed or updated.</td></tr><tr><td>exiRequest</td><td>string[0..5600]</td><td>1..1</td><td>Required. Raw CertificateInstallationReq request from EV, Base64 encoded.</td></tr></table>
+
+# 1.16.2. Get15118EVCertificateResponse
+
+Response message from CSMS to Charging Station containing the status and optionally new certificate. NOTE: This message is based on CertificateInstallationReq Res from ISO 15118-2.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>Iso15118EVCertificateStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the message was processed properly.</td></tr><tr><td>exiResponse</td><td>string[0..5600]</td><td>1..1</td><td>Required. Raw CertificateInstallationRes response for the EV, Base64 encoded. The Charging Station can let the CSMS know it supports a higher field size by reporting this using the device model as OCPPCommCtrlr.FieldLength["Get15118EVCertificateResponse.exiResponse"] = <New max length></td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.17. GetBaseReport
+
+# 1.17.1. GetBaseReportRequest
+
+This contains the field definition of the GetBaseReportRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of the request.</td></tr><tr><td>reportBase</td><td>ReportBaseEnumType</td><td>1..1</td><td>Required. This field specifies the report base.</td></tr></table>
+
+# 1.17.2. GetBaseReportResponse
+
+This contains the field definition of the GetBaseReportResponse PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericDeviceModelStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station is able to accept this request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.18. GetCertificateStatus
+
+# 1.18.1. GetCertificateStatusRequest
+
+This contains the field definition of the GetCertificateStatusRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>ocspRequestData</td><td>OCSPRequestDataType</td><td>1..1</td><td>Required. Indicates the certificate of which the status is requested.</td></tr></table>
+
+# 1.18.2. GetCertificateStatusResponse
+
+This contains the field definition of the GetCertificateStatusResponse PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GetCertificateStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the charging station was able to retrieve the OCSP certificate status.</td></tr><tr><td>ocspResult</td><td>string[0..5500]</td><td>0..1</td><td>Optional. OCSPResponse class as defined in IETF RFC 6960. DER encoded (as defined in IETF RFC 6960), and then base64 encoded. MAY only be omitted when status is not Accepted.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.19. GetChargingProfiles
+
+# 1.19.1. GetChargingProfilesRequest
+
+The message GetChargingProfilesRequest can be used by the CSMS to request installed charging profiles from the Charging Station. The charging profiles will then be reported by the Charging Station via ReportChargingProfilesRequest messages.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. Reference identification that is to be used by the Charging Station in the ReportChargingProfilesRequest when provided.</td></tr><tr><td>evseld</td><td>integer</td><td>0..1</td><td>Optional. For which EVSE installed charging profiles SHALL be reported. If 0, only charging profiles installed on the Charging Station itself (the grid connection) SHALL be reported. If omitted, all installed charging profiles SHALL be reported. Reported charging profiles SHALL match the criteria in field chargingProfile.</td></tr><tr><td>chargingProfile</td><td>ChargingProfileCriterionType</td><td>1..1</td><td>Required. Specifies the charging profile.</td></tr></table>
+
+# 1.19.2. GetChargingProfilesResponse
+
+This contains the field definition of the GetChargingProfilesResponse PDU sent by the Charging Station to the CSMS in response to a GetChargingProfilesRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GetChargingProfileStatusEnumTyp e</td><td>1..1</td><td>Required. This indicates whether the Charging Station is able to process this request and will send ReportChargingProfilesRequest messages.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.20. GetCompositeSchedule
+
+# 1.20.1. GetCompositeScheduleRequest
+
+This contains the field definition of the GetCompositeScheduleRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>duration</td><td>integer</td><td>1..1</td><td>Required. Length of the requested schedule in seconds.</td></tr><tr><td>chargingRateUnit</td><td>ChargingRateUnitEnumType</td><td>0..1</td><td>Optional. Can be used to force a power or current profile.</td></tr><tr><td>evseld</td><td>integer</td><td>1..1</td><td>Required. The ID of the EVSE for which the schedule is requested. When evseid=0, the Charging Station will calculate the expected consumption for the grid connection.</td></tr></table>
+
+# 1.20.2. GetCompositeScheduleResponse
+
+This contains the field definition of the GetCompositeScheduleResponse PDU sent by the Charging Station to the CSMS in response to a GetCompositeScheduleRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. The Charging Station will indicate if it was able to process the request</td></tr><tr><td>schedule</td><td>CompositeScheduleType</td><td>0..1</td><td>Optional. This field contains the calculated composite schedule. It may only be omitted when this message contains status Rejected.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.21. GetDisplayMessages
+
+# 1.21.1. GetDisplayMessagesRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>0..*</td><td>Optional. If provided the Charging Station shall return Display Messages of the given ids. This field SHALL NOT contain more ids than set in NumberOfDisplayMessages.maxLimit</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of this request.</td></tr><tr><td>priority</td><td>MessagePriorityEnumType</td><td>0..1</td><td>Optional. If provided the Charging Station shall return Display Messages with the given priority only.</td></tr><tr><td>state</td><td>MessageStateEnumType</td><td>0..1</td><td>Optional. If provided the Charging Station shall return Display Messages with the given state only.</td></tr></table>
+
+# 1.21.2. GetDisplayMessagesResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GetDisplayMessagesStatusEnumType</td><td>1..1</td><td>Required. Indicates if the Charging Station has Display Messages that match the request criteria in the GetDisplayMessagesRequest</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.22. GetInstalledCertificates
+
+# 1.22.1. GetInstalledCertificatesRequest
+
+Used by the CSMS to request an overview of the installed certificates on a Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateType</td><td>GetCertificateldUseEnumType</td><td>0..*</td><td>Optional. Indicates the type of certificates requested.
+When omitted, all certificate types are requested.</td></tr></table>
+
+# 1.22.2. GetInstalledCertificatesResponse
+
+Response to a GetInstalledCertificateDsRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GetInstalledCertificateStatusEnum Type</td><td>1..1</td><td>Required. Charging Station indicates if it can process the request.</td></tr><tr><td>certificateDataChain</td><td>CertificateDataChainType</td><td>0..*</td><td>Optional. The Charging Station includes the Certificate information for each available certificate.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.23. GetLocalListVersion
+
+# 1.23.1. GetLocalListVersionRequest
+
+This contains the field definition of the GetLocalListVersionRequest PDU sent by the CSMS to the Charging Station. No fields are defined.
+
+# 1.23.2. GetLocalListVersionResponse
+
+This contains the field definition of the GetLocalListVersionResponse PDU sent by the Charging Station to CSMS in response to a GetLocalListVersionRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>versionNumber</td><td>integer</td><td>1..1</td><td>Required. This contains the current version number of the local authorization list in the Charging Station.</td></tr></table>
+
+# 1.24. GetLog
+
+# 1.24.1. GetLogRequest
+
+This contains the field definition of the GetLogRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>logType</td><td>LogEnumType</td><td>1..1</td><td>Required. This contains the type of log file that the Charging Station should send.</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of this request</td></tr><tr><td>retries</td><td>integer</td><td>0..1</td><td>Optional. This specifies how many times the Charging Station must retry to upload the log before giving up. If this field is not present, it is left to Charging Station to decide how many times it wants to retry. If the value is 0, it means: no retries.</td></tr><tr><td>retrypInterval</td><td>integer</td><td>0..1</td><td>Optional. The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charging Station to decide how long to wait between attempts.</td></tr><tr><td>log</td><td>LogParametersType</td><td>1..1</td><td>Required. This field specifies the requested log and the location to which the log should be sent.</td></tr></table>
+
+# 1.24.2. GetLogResponse
+
+This contains the field definition of the GetLogResponse PDU sent by the Charging Station to the CSMS in response to a GetLogRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>LogStatusEnumType</td><td>1..1</td><td>Required. This field indicates whether the Charging Station was able to accept the request.</td></tr><tr><td>filename</td><td>string[0..255]</td><td>0..1</td><td>Optional. This contains the name of the log file that will be uploaded. This field is not present when no logging information is available.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.25. GetMonitoringReport
+
+# 1.25.1. GetMonitoringReportRequest
+
+This contains the field definition of the GetMonitoringReportRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of the request.</td></tr><tr><td>monitoringCriteria</td><td>MonitoringCriterionEnumType</td><td>0..3</td><td>Optional. This field contains criteria for components for which a monitoring report is requested</td></tr><tr><td>componentVariable</td><td>ComponentVariableType</td><td>0..*</td><td>Optional. This field specifies the components and variables for which a monitoring report is requested.</td></tr></table>
+
+# 1.25.2. GetMonitoringReportResponse
+
+This contains the field definition of the GetMonitoringReportResponse PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericDeviceModelStatusEnumType</td><td>1..1</td><td>Required. This field indicates whether the Charging Station was able to accept the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.26. GetReport
+
+# 1.26.1. GetReportRequest
+
+This contains the field definition of the GetReportRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of the request.</td></tr><tr><td>componentCriteria</td><td>ComponentCriterionEnumType</td><td>0..4</td><td>Optional. This field contains criteria for components for which a report is requested</td></tr><tr><td>componentVariable</td><td>ComponentVariableType</td><td>0..*</td><td>Optional. This field specifies the components and variables for which a report is requested.</td></tr></table>
+
+# 1.26.2. GetReportResponse
+
+The response to a GetReportRequest, sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericDeviceModelStatusEnumType</td><td>1..1</td><td>Required. This field indicates whether the Charging Station was able to accept the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.27. GetTransactionStatus
+
+# 1.27.1. GetTransactionStatusRequest
+
+With this message, the CSMS can ask the Charging Station whether it has transaction-related messages waiting to be delivered to the CSMS. When a transactionId is provided, only messages for a specific transaction are asked for.
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. The Id of the transaction for which the status is requested.</td></tr></table>
+
+# 1.27.2. GetTransactionStatusResponse
+
+The response to a GetTransactionStatusRequest, sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>ongoingIndicator</td><td>boolean</td><td>0..1</td><td>Optional. Whether the transaction is still ongoing.</td></tr><tr><td>messagesInQueue</td><td>boolean</td><td>1..1</td><td>Required. Whether there are still message to be delivered.</td></tr></table>
+
+# 1.28. GetVariables
+
+# 1.28.1. GetVariablesRequest
+
+This contains the field definition of the GetVariablesRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>getVariableData</td><td>GetVariableDataType</td><td>1..*</td><td>Required. List of requested variables.</td></tr></table>
+
+# 1.28.2. GetVariablesResponse
+
+This contains the field definition of the GetVariablesResponse PDU sent by the CSMS to the Charging Station in response to GetVariablesRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>getVariableResult</td><td>GetVariableResultType</td><td>1..*</td><td>Required. List of requested variables and their values.</td></tr></table>
+
+# 1.29. Heartbeat
+
+# 1.29.1. HeartbeatRequest
+
+This contains the field definition of the HeartbeatRequest PDU sent by the Charging Station to the CSMS. No fields are defined.
+
+# 1.29.2. HeartbeatResponse
+
+This contains the field definition of the HeartbeatResponse PDU sent by the CSMS to the Charging Station in response to a HeartbeatRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>currentTime</td><td>dateTime</td><td>1..1</td><td>Required. Contains the current time of the CSMS.</td></tr></table>
+
+# 1.30. InstallCertificate
+
+# 1.30.1. InstallCertificateRequest
+
+Used by the CSMS to request installation of a certificate on a Charging Station. Note: This message is not for installing a TLS client certificate in a charging station. The CertificateSignedRequest mechanism is used for that.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateType</td><td>InstallCertificateUseEnumType</td><td>1..1</td><td>Required. Indicates the certificate type that is sent.</td></tr><tr><td>certificate</td><td>string[0..5500]</td><td>1..1</td><td>Required. A PEM encoded X.509 certificate.</td></tr></table>
+
+# 1.30.2. InstallCertificateResponse
+
+The response to a InstallCertificateRequest, sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>InstallCertificateStatusEnumType</td><td>1..1</td><td>Required. Charging Station indicates if installation was successful.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.31. LogStatusNotification
+
+# 1.31.1. LogStatusNotificationRequest
+
+This contains the field definition of the LogStatusNotificationRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>UploadLogStatusEnumType</td><td>1..1</td><td>Required. This contains the status of the log upload.</td></tr><tr><td>requestId</td><td>integer</td><td>0..1</td><td>Optional. The request id that was provided in GetLogRequest that started this log upload. This field is mandatory, unless the message was triggered by a TriggerMessageRequest AND there is no log upload ongoing.</td></tr></table>
+
+# 1.31.2. LogStatusNotificationResponse
+
+This contains the field definition of the LogStatusNotificationResponse PDU sent by the CSMS to the Charging Station in response to LogStatusNotificationRequest. No fields are defined.
+
+# 1.32. MeterValues
+
+# 1.32.1. MeterValuesRequest
+
+This contains the field definition of the MeterValuesRequest PDU sent by the Charging Station to the CSMS. This message might be removed in a future version of OCPP. It will be replaced by Device Management Monitoring events.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer</td><td>1..1</td><td>Required. This contains a number (>0) designating an EVSE of the Charging Station. ‘0’ (zero) is used to designate the main power meter.</td></tr><tr><td>meterValue</td><td>MeterValueType</td><td>1..*</td><td>Required. The sampled meter values with timestamps.</td></tr></table>
+
+# 1.32.2. MeterValuesResponse
+
+This contains the field definition of the MeterValuesResponse PDU sent by the CSMS to the Charging Station in response to a MeterValuesRequest PDU. This message might be removed in a future version of OCPP. It will be replaced by Device Management Monitoring events.
+
+No fields are defined.
+
+# 1.33. NotifyChargingLimit
+
+# 1.33.1. NotifyChargingLimitRequest
+
+The message NotifyChargingLimitRequest can be used to communicate a charging limit, set by an external system on the Charging Station (Not installed by the CSO via SetChargingProfileRequest), to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer</td><td>0..1</td><td>Optional. The charging schedule contained in this notification applies to an EVSE. evseld must be > 0.</td></tr><tr><td>chargingLimit</td><td>ChargingLimitType</td><td>1..1</td><td>Required. This contains the source of the charging limit and whether it is grid critical.</td></tr><tr><td>chargingSchedule</td><td>ChargingScheduleType</td><td>0..*</td><td>Optional. Contains limits for the available power or current over time, as set by the external source.</td></tr></table>
+
+# 1.33.2. NotifyChargingLimitResponse
+
+The NotifyChargingLimitResponse message is sent by the CSMS to the Charging Station in response to a NotifyChargingLimitsRequest. No fields are defined.
+
+# 1.34. NotifyCustomerInformation
+
+This contains the field definition of the NotifyCustomerInformationRequest PDU sent by the Charging Station to the CSMS.
+
+# 1.34.1. NotifyCustomerInformationRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>data</td><td>string[0..512]</td><td>1..1</td><td>Required. (Part of) the requested data. No format specified in which the data is returned. Should be human readable.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. “to be continued” indicator. Indicates whether another part of the monitoringData follows in an upcoming notifyMonitoringReportRequest message. Default value when omitted is false.</td></tr><tr><td>seqNo</td><td>integer</td><td>1..1</td><td>Required. Sequence number of this message. First message starts at 0.</td></tr><tr><td>generatedAt</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp of the moment this message was generated at the Charging Station.</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of the request.</td></tr></table>
+
+# 1.34.2. NotifyCustomerInformationResponse
+
+# 1.35. NotifyMessages
+
+# 1.35.1. NotifyDisplayMessagesRequest
+
+This contains the field definition of the NotifyDisplayMessagesRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The id of the GetDisplayMessagesRequest that requested this message.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. "to be continued" indicator. Indicates whether another part of the report follows in an upcoming NotifyDisplayMessagesRequest message. Default value when omitted is false.</td></tr><tr><td>messageInfo</td><td>MessageInfoType</td><td>0..*</td><td>Optional. The requested display message as configured in the Charging Station.</td></tr></table>
+
+# 1.35.2. NotifyDisplayMessagesResponse
+
+The NotifyDisplayMessagesResponse message is sent by the CSMS to the Charging Station in response to a NotifyDisplayMessagesRequest. No fields are defined.
+
+# 1.36. NotifyEVChargingNeeds
+
+# 1.36.1. NotifyEVChargingNeedsRequest
+
+The Charging Station uses this message to communicate the charging needs as calculated by the EV to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>maxScheduleTuples</td><td>integer</td><td>0..1</td><td>Optional. Contains the maximum schedule tuples the car supports per schedule.</td></tr><tr><td>evseld</td><td>integer</td><td>1..1</td><td>Required. Defines the EVSE and connector to which the EV is connected. Evseld may not be 0.</td></tr><tr><td>chargingNeeds</td><td>ChargingNeedsType</td><td>1..1</td><td>Required. The characteristics of the energy delivery required.</td></tr></table>
+
+# 1.36.2. NotifyEVChargingNeedsResponse
+
+Response to a NotifyEVChargingNeedsRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>NotifyEVChargingNeedsStatusEnu mType</td><td>1..1</td><td>Required. Returns whether the CSMS has been able to process the message successfully. It does not imply that the evChargingNeeds can be met with the current charging profile.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.37. NotifyEVChargingSchedule
+
+# 1.37.1. NotifyEVChargingScheduleRequest
+
+The Charging Station uses this message to communicate the charging schedule as calculated by the EV to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>timeBase</td><td>dateTime</td><td>1..1</td><td>Required. Periods contained in the charging profile are relative to this point in time.</td></tr><tr><td>evseld</td><td>integer</td><td>1..1</td><td>Required. The charging schedule contained in this notification applies to an EVSE. Evseld must be > 0.</td></tr><tr><td>chargingSchedule</td><td>ChargingScheduleType</td><td>1..1</td><td>Required. Planned energy consumption of the EV over time. Always relative to timeBase.</td></tr></table>
+
+# 1.37.2. NotifyEVChargingScheduleResponse
+
+Response to a NotifyEVChargingScheduleRequest message.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Returns whether the CSMS has been able to process the message successfully. It does not imply any approval of the charging schedule.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.38. Notify
+
+# 1.38.1. NotifyRequest
+
+This contains the field definition of the NotifyEventRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>generatedAt</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp of the moment this message was generated at the Charging Station.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. “to be continued” indicator. Indicates whether another part of the report follows in an upcoming notifyEventRequest message. Default value when omitted is false.</td></tr><tr><td>seqNo</td><td>integer</td><td>1..1</td><td>Required. Sequence number of this message. First message starts at 0.</td></tr><tr><td>eventData</td><td>-eventDataType</td><td>1..*</td><td>Required. List of EventData. An EventData element contains only the Component, Variable and VariableMonitoring data that caused the event. The list of EventData will usually contain one eventData element, but the Charging Station may decide to group multiple events in one notification. For example, when multiple events triggered at the same time.</td></tr></table>
+
+# 1.38.2. NotifyResponse
+
+Response to NotifyRequest. No fields are defined.
+
+# 1.39. NotifyMonitoringReport
+
+# 1.39.1. NotifyMonitoringReportRequest
+
+This contains the field definition of the NotifyMonitoringRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The id of the GetMonitoringRequest that requested this report.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. “to be continued” indicator. Indicates whether another part of the monitoringData follows in an upcoming notifyMonitoringReportRequest message. Default value when omitted is false.</td></tr><tr><td>seqNo</td><td>integer</td><td>1..1</td><td>Required. Sequence number of this message. First message starts at 0.</td></tr><tr><td>generatedAt</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp of the moment this message was generated at the Charging Station.</td></tr><tr><td>monitor</td><td>MonitoringDataType</td><td>0..*</td><td>Optional. List of MonitoringData containing monitoring settings.</td></tr></table>
+
+# 1.39.2. NotifyMonitoringReportResponse
+
+Response to a NotifyMonitoringRequest message. No fields are defined.
+
+# 1.40. NotifyReport
+
+# 1.40.1. NotifyReportRequest
+
+This contains the field definition of the NotifyReportRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The id of the GetReportRequest or GetBaseReportRequest that requested this report</td></tr><tr><td>generatedAt</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp of the moment this message was generated at the Charging Station.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. “to be continued” indicator. Indicates whether another part of the report follows in an upcoming notifyReportRequest message. Default value when omitted is false.</td></tr><tr><td>seqNo</td><td>integer</td><td>1..1</td><td>Required. Sequence number of this message. First message starts at 0.</td></tr><tr><td>reportData</td><td>报告显示数据类型</td><td>0..*</td><td>Optional. List of Data type.</td></tr></table>
+
+# 1.40.2. NotifyReportResponse
+
+Response to a NotifyReportRequest message. No fields are defined.
+
+# 1.41. PublishFirmware
+
+# 1.41.1. PublishFirmwareRequest
+
+This contains the field definition of the PublishFirmwareRequest PDU sent by the CSMS to the Local Controller.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>location</td><td>string[0..512]</td><td>1..1</td><td>Required. This contains a string containing a URI pointing to a location from which to retrieve the firmware.</td></tr><tr><td>retries</td><td>integer</td><td>0..1</td><td>Optional. This specifies how many times the Charging Station must retry to download the firmware before giving up. If this field is not present, it is left to Charging Station to decide how many times it wants to retry. If the value is 0, it means: no retries.</td></tr><tr><td>checksum</td><td>identifierString[0..32]</td><td>1..1</td><td>Required. The MD5 checksum over the entire firmware file as a hexadecimal string of length 32.</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of the request.</td></tr><tr><td>retrypInterval</td><td>integer</td><td>0..1</td><td>Optional. The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charging Station to decide how long to wait between attempts.</td></tr></table>
+
+# 1.41.2. PublishFirmwareResponse
+
+This contains the field definition of the PublishFirmwareResponse PDU sent by the Local Controller to the CSMS in response to a PublishFirmwareRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the request was accepted.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.42. PublishFirmwareStatusNotification
+
+# 1.42.1. PublishFirmwareStatusNotificationRequest
+
+This contains the field definition of the PublishFirmwareStatusNotificationRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>PublishFirmwareStatusEnumType</td><td>1..1</td><td>Required. This contains the progress status of the publishfirmware installation.</td></tr><tr><td>location</td><td>string[0..512]</td><td>0..*</td><td>Optional. Required if status is Published. Can be multiple URI's, if the Local Controller supports e.g. HTTP, HTTPS, and FTP.</td></tr><tr><td>requestId</td><td>integer</td><td>0..1</td><td>Optional. The request id that was provided in the PublishFirmwareRequest which triggered this action.</td></tr></table>
+
+# 1.42.2. PublishFirmwareStatusNotificationResponse
+
+This contains the field definition of the PublishFirmwareStatusNotificationResponse PDU sent by the CSMS to the Charging station in response to a PublishFirmwareStatusNotificationRequest.
+
+# 1.43.ReportChargingProfiles
+
+# 1.43.1. ReportChargingProfilesRequest
+
+Reports charging profiles installed in the Charging Station, as requested via a GetChargingProfilesRequest message. The charging profile report can be split over multiple ReportChargingProfilesRequest messages, this can be because charging profiles for different charging sources need to be reported, or because there is just to much data for one message.
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. Id used to match the GetChargingProfilesRequest message with the resulting ReportChargingProfilesRequest messages. When the CSMS provided a requestId in the GetChargingProfilesRequest, this field SHALL contain the same value.</td></tr><tr><td>chargingLimitSource</td><td>ChargingLimitSourceEnumType</td><td>1..1</td><td>Required. Source that has installed this charging profile.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. To Be Continued. Default value when omitted: false. false indicates that there are no further messages as part of this report.</td></tr><tr><td>evseld</td><td>integer</td><td>1..1</td><td>Required. The evse to which the charging profile applies. If evseld = 0, the message contains an overall limit for the Charging Station.</td></tr><tr><td>chargingProfile</td><td>ChargingProfileType</td><td>1..*</td><td>Required. The charging profile as configured in the Charging Station.</td></tr></table>
+
+# 1.43.2. ReportChargingProfilesResponse
+
+The ReportChargingProfilesResponse message is sent by the CSMS to the Charging Station in response to a ReportChargingProfilesRequest. No fields are defined.
+
+# 1.44. RequestStartTransaction
+
+# 1.44.1. RequestStartTransactionRequest
+
+This contains the field definitions of the RequestStartTransactionRequest PDU sent to Charging Station by CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer</td><td>0..1</td><td>Optional. Number of the EVSE on which to start the transaction. Evseld SHALL be > 0</td></tr><tr><td>remoteStartId</td><td>integer</td><td>1..1</td><td>Required. Id given by the server to this start request. The Charging Station will return this in the TransactionEventRequest, letting the server know which transaction was started for this request.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>1..1</td><td>Required. The identifier that the Charging Station must use to start a transaction.</td></tr><tr><td>chargingProfile</td><td>ChargingProfileType</td><td>0..1</td><td>Optional. Charging Profile to be used by the Charging Station for the requested transaction. ChargingProfilePurpose MUST be set to TxProfile</td></tr><tr><td>groupldToken</td><td>IdTokenType</td><td>0..1</td><td>Optional. The groupldToken is only relevant when the transaction is to be started on an EVSE for which a reservation for groupldToken is active, and the configuration variable AuthorizationRemoteStart = false (otherwise the AuthorizationResponse could return the groupldToken).</td></tr></table>
+
+# 1.44.2. RequestStartTransactionResponse
+
+This contains the field definitions of the RequestStartTransactionResponse PDU sent from Charging Station to CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>RequestStartStopStatusEnumType</td><td>1..1</td><td>Required. Status indicating whether the Charging Station accepts the request to start a transaction.</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. When the transaction was already started by the Charging Station before the RequestStartTransactionRequest was received, for example: cable plugged in first. This contains the transactionId of the already started transaction.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.45. RequestStopTransaction
+
+# 1.45.1. RequestStopTransactionRequest
+
+This contains the field definitions of the RequestStopTransactionRequest PDU sent to Charging Station by CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. The identifier of the transaction which the Charging Station is requested to stop.</td></tr></table>
+
+# 1.45.2. RequestStopTransactionResponse
+
+This contains the field definitions of the RequestStopTransactionResponse PDU sent from Charging Station to CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>RequestStartStopStatusEnumType</td><td>1..1</td><td>Required. Status indicating whether Charging Station accepts the request to stop a transaction.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.46. ReservationStatusUpdate
+
+# 1.46.1. ReservationStatusUpdateRequest
+
+This contains the field definition of the ReservationStatusUpdateRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>reservationId</td><td>integer</td><td>1..1</td><td>Required. The ID of the reservation.</td></tr><tr><td>reservationUpdateStatus</td><td>ReservationUpdateStatusEnumType</td><td>1..1</td><td>Required. The updated reservation status.</td></tr></table>
+
+# 1.46.2. ReservationStatusUpdateResponse
+
+This contains the field definition of the ReservationStatusUpdateResponse PDU sent by the CSMS to the Charging Station in response to a ReservationStatusUpdateRequest. No fields are defined.
+
+# 1.47. ReserveNow
+
+# 1.47.1. ReserveNowRequest
+
+This contains the field definition of the ReserveNowRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>1..1</td><td>Required. Id of reservation.</td></tr><tr><td>expiryDateTime</td><td>dateTime</td><td>1..1</td><td>Required. Date and time at which the reservation expires.</td></tr><tr><td>connectorType</td><td>ConnectorEnumType</td><td>0..1</td><td>Optional. This field specifies the connector type.</td></tr><tr><td>evseld</td><td>integer</td><td>0..1</td><td>Optional. This contains ID of the evse to be reserved.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>1..1</td><td>Required. The identifier for which the reservation is made.</td></tr><tr><td>groupldToken</td><td>IdTokenType</td><td>0..1</td><td>Optional. The group identifier for which the reservation is made.</td></tr></table>
+
+# 1.47.2. ReserveNowResponse
+
+This contains the field definition of the ReserveNowResponse PDU sent by the Charging Station to the CSMS in response to ReserveNowRequest PDU.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ReserveNowStatusEnumType</td><td>1..1</td><td>Required. This indicates the success or failure of the reservation.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.48. Reset
+
+# 1.48.1. ResetRequest
+
+This contains the field definition of the ResetRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>type</td><td>ResetEnumType</td><td>1..1</td><td>Required. This contains the type of reset that the Charging Station or EVSE should perform.</td></tr><tr><td>evseld</td><td>integer</td><td>0..1</td><td>Optional. This contains the ID of a specific EVSE that needs to be reset, instead of the entire Charging Station.</td></tr></table>
+
+# 1.48.2. ResetResponse
+
+This contains the field definition of the ResetResponse PDU sent by the Charging Station to the CSMS in response to ResetRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ResetStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station is able to perform the reset.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.49. SecurityEventNotification
+
+# 1.49.1. SecurityEventNotificationRequest
+
+Sent by the Charging Station to the CSMS in case of a security event.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>type</td><td>string[0..50]</td><td>1..1</td><td>Required. Type of the security event. This value should be taken from the Security events list.</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. Date and time at which the event occurred.</td></tr><tr><td>techInfo</td><td>string[0..255]</td><td>0..1</td><td>Optional. Additional information about the occurred security event.</td></tr></table>
+
+# 1.49.2. SecurityEventNotificationResponse
+
+Sent by the CSMS to the Charging Station to confirm the receipt of a SecurityEventNotificationRequest message. No fields are defined.
+
+# 1.50.SendLocalList
+
+# 1.50.1.SendLocalListRequest
+
+This contains the field definition of the SendLocalListRequest PDU sent by the CSMS to the Charging Station. If no (empty) localAuthorizationList is given and the updateType is Full, all IdTokens are removed from the list. Requesting a Differential update without or with empty localAuthorizationList will have no effect on the list. All IdTokens in the localAuthorizationList MUST be unique, no duplicate values are allowed.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>versionNumber</td><td>integer</td><td>1..1</td><td>Required. In case of a full update this is the version number of the full list. In case of a differential update it is the version number of the list after the update has been applied.</td></tr><tr><td>updateType</td><td>UpdateEnumType</td><td>1..1</td><td>Required. This contains the type of update (full or differential) of this request.</td></tr><tr><td>localAuthorizationList</td><td>AuthorizationData</td><td>0..*</td><td>Optional. This contains the Local Authorization List entries.</td></tr></table>
+
+# 1.50.2. SendLocalListResponse
+
+This contains the field definition of the SendLocalListResponse PDU sent by the Charging Station to the CSMS in response to SendLocalListRequest PDU.
+
+Class
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>SendLocalListStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station has successfully received and applied the update of the Local Authorization List.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.51. SetChargingProfile
+
+# 1.51.1. SetChargingProfileRequest
+
+This contains the field definition of the SetChargingProfileRequest PDU sent by the CSMS to the Charging Station. The CSMS uses this message to send charging profiles to a Charging Station.
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer</td><td>1..1</td><td>Required. For TxDefaultProfile an evseld=0 applies the profile to each individual evse. For ChargingStationMaxProfile and ChargingStationExternalConstraints an evseld=0 contains an overall limit for the whole Charging Station.</td></tr><tr><td>chargingProfile</td><td>ChargingProfileType</td><td>1..1</td><td>Required. The charging profile to be set at the Charging Station.</td></tr></table>
+
+# 1.51.2. SetChargingProfileResponse
+
+This contains the field definition of the SetChargingProfileResponse PDU sent by the Charging Station to the CSMS in response to SetChargingProfileRequest PDU.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ChargingProfileStatusEnumType</td><td>1..1</td><td>Required. Returns whether the Charging Station has been able to process the message successfully. This does not guarantee the schedule will be followed to the letter. There might be other constraints the Charging Station may need to take into account.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.52. SetDisplayMessage
+
+# 1.52.1. SetDisplayMessageRequest
+
+This contains the field definition of the SetDisplayMessageRequest PDU sent by the CSMS to the Charging Station. The CSMS asks the Charging Station to configure a new display message that the Charging Station will display (in the future). See also 001 - Set Display Message, 002 - Set Display Message for Transaction and 006 - Replace Display Message
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>message</td><td>MessageInfoType</td><td>1..1</td><td>Required. Message to be configured in the Charging Station, to be displayed.</td></tr></table>
+
+# 1.52.2. SetDisplayMessageResponse
+
+This contains the field definition of the SetDisplayMessageResponse PDU sent by the Charging Station to the CSMS in a response to a SetDisplayMessageRequest. See also 001 - Set Display Message, 002 - Set Display Message for Transaction and 006 - Replace Display Message
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>DisplayMessageStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station is able to display the message.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.53. SetMonitoringBase
+
+# 1.53.1. SetMonitoringBaseRequest
+
+This contains the field definition of the SetMonitoringBaseRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>monitoringBase</td><td>MonitoringBaseEnumType</td><td>1..1</td><td>Required. Specify which monitoring base will be set</td></tr></table>
+
+# 1.53.2. SetMonitoringBaseResponse
+
+This contains the field definition of the SetMonitoringBaseResponse PDU sent by the Charging Station to the CSMS in response to a SetMonitoringBaseRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericDeviceModelStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the Charging Station was able to accept the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.54. SetMonitoringLevel
+
+# 1.54.1. SetMonitoringLevelRequest
+
+This contains the field definition of the SetMonitoringLevelRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>severity</td><td>integer</td><td>1..1</td><td>Required. The Charging Station SHALL only report events with a severity number lower than or equal to this severity. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.The severity levels have the following meaning:0-DangerIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately.1-Hardware FailureIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required.2-System FailureIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required.3-CriticalIndicates a critical error. Action is required.4-ErrorIndicates a non-urgent error. Action is required.5-A AlertIndicates an alert event. Default severity for any type of monitoring event.6-WarningIndicates a warning event. Action may be required.7-NoticeIndicates an unusual event. No immediate action is required.8-InformationalIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required.9-DebugIndicates information useful to developers for debugging, not useful during operations.</td></tr></table>
+
+# 1.54.2. SetMonitoringLevelResponse
+
+This contains the field definition of the SetMonitoringLevelResponse PDU sent by the Charging Station to the CSMS in response to a SetMonitoringLevelRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the Charging Station was able to accept the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.55. SetNetworkProfile
+
+# 1.55.1. SetNetworkProfileRequest
+
+With this message the CSMS gains the ability to configure the connection data (e.g. CSMS URL, OCPP version, APN, etc) on a Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>configurationSlot</td><td>integer</td><td>1..1</td><td>Required. Slot in which the configuration should be stored.</td></tr><tr><td>connectionData</td><td>NetworkConnectionProfileType</td><td>1..1</td><td>Required. Connection details.</td></tr></table>
+
+# 1.55.2. SetNetworkProfileResponse
+
+This contains the field definition of the SetNetworkProfileResponse PDU sent by the Charging Station to the CSMS in response to a SetNetworkProfileRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>SetNetworkProfileStatusEnumType</td><td>1..1</td><td>Required. Result of operation.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.56. SetVariableMonitoring
+
+# 1.56.1. SetVariableMonitoringRequest
+
+This contains the field definition of the SetVariableMonitoringRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>setMonitoringData</td><td>SetMonitoringDataType</td><td>1..*</td><td>Required. List of MonitoringData containing monitoring settings.</td></tr></table>
+
+# 1.56.2. SetVariableMonitoringResponse
+
+This contains the field definition of the SetVariableMonitoringResponse PDU sent by the Charging Station to the CSMS in response to a SetVariableMonitoringRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>setMonitoringResult</td><td>SetMonitoringResultType</td><td>1..*</td><td>Required. List of result statuses per monitor.</td></tr></table>
+
+# 1.57. SetVariables
+
+# 1.57.1. SetVariablesRequest
+
+This contains the field definition of the SetVariablesRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>setVariableData</td><td>SetVariableDataType</td><td>1..*</td><td>Required. List of Component-Variable pairs and attribute values to set.</td></tr></table>
+
+# 1.57.2. SetVariablesResponse
+
+This contains the field definition of the SetVariablesResponse PDU sent by the Charging Station to the CSMS in response to a SetVariablesRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>setVariableResult</td><td>SetVariableResultType</td><td>1..*</td><td>Required. List of result statuses per Component-Variable.</td></tr></table>
+
+# 1.58. SignCertificate
+
+# 1.58.1. SignCertificateRequest
+
+Sent by the Charging Station to the CSMS to request that the Certificate Authority signs the public key into a certificate.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>csr</td><td>string[0..5500]</td><td>1..1</td><td>Required. The Charging Station SHALL send the public key in form of a Certificate Signing Request (CSR) as described in RFC 2986 [22] and then PEM encoded, using the SignCertificateRequest message.</td></tr><tr><td>certificateType</td><td>CertificateSigningUseEnumType</td><td>0..1</td><td>Optional. Indicates the type of certificate that is to be signed. When omitted the certificate is to be used for both the 15118 connection (if implemented) and the Charging Station to CSMS connection.</td></tr></table>
+
+# 1.58.2. SignCertificateResponse
+
+Sent by the CSMS to the Charging Station in response to the SignCertificateRequest message.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Specifies whether the CSMS can process the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.59. StatusNotification
+
+# 1.59.1. StatusNotificationRequest
+
+This contains the field definition of the StatusNotificationRequest PDU sent by the Charging Station to the CSMS. This message might be removed in a future version of OCPP. It will be replaced by Device Management Monitoring events.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. The time for which the status is reported.</td></tr><tr><td>connectorStatus</td><td>Connector statusesEnumType</td><td>1..1</td><td>Required. This contains the current status of the Connector.</td></tr><tr><td>evseld</td><td>integer</td><td>1..1</td><td>Required. The id of the EVSE to which the connector belongs for which the status is reported.</td></tr><tr><td>connectorId</td><td>integer</td><td>1..1</td><td>Required. The id of the connector within the EVSE for which the status is reported.</td></tr></table>
+
+# 1.59.2. StatusNotificationResponse
+
+This contains the field definition of StatusNotificationResponse sent by the CSMS to the Charging Station in response to a StatusNotificationRequest. This message might be removed in a future version of OCPP. It will be replaced by Device Management Monitoring events.
+
+No fields are defined.
+
+# 1.60. TransactionEvent
+
+# 1.60.1. TransactionRequest
+
+This section contains the field definition of the TransactionEventRequest PDU sent by the Charging Station to the CSMS. For each of the eventTypes; Started, Updated and Ended, the corresponding cardinality is specified.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>eventType</td><td>TransactionEventEnumType</td><td>1..1</td><td>Required. This contains the type of this event. The first TransactionEvent of a transaction SHALL contain: "Started" The last TransactionEvent of a transaction SHALL contain: "Ended" All others SHALL contain: "Updated"</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. The date and time at which this transaction event occurred.</td></tr><tr><td>triggerReason</td><td>TriggerReasonEnumType</td><td>1..1</td><td>Required. Reason the Charging Station sends this message to the CSMS</td></tr><tr><td>seqNo</td><td>integer</td><td>1..1</td><td>Required. Incremental sequence number, helps with determining if all messages of a transaction have been received.</td></tr><tr><td>offline</td><td>boolean</td><td>0..1</td><td>Optional. Indication that this transaction event happened when the Charging Station was offline. Default = false, meaning: the event occurred when the Charging Station was online.</td></tr><tr><td>NumberOfPhasesUsed</td><td>integer</td><td>0..1</td><td>Optional. If the Charging Station is able to report the number of phases used, then it SHALL provide it. When omitted the CSMS may be able to determine the number of phases used via device management.</td></tr><tr><td>cableMaxCurrent</td><td>integer</td><td>0..1</td><td>Optional. The maximum current of the connected cable in Ampere (A).</td></tr><tr><td>reservationId</td><td>integer</td><td>0..1</td><td>Optional. This contains the Id of the reservation that terminates as a result of this transaction.</td></tr><tr><td>transactionInfo</td><td>TransactionType</td><td>1..1</td><td>Required. Contains transaction specific information.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>0..1</td><td>Optional. This contains the identifier for which a transaction 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 TransactionRequest for every authorization (for starting or for stopping) done for this transaction, so that CSMS can return the idTokenInfo in the TransactionResponse. IdToken should not be present in the TransactionRequest when a transaction is ended by a RequestStopTransactionRequest or a ResetRequest.</td></tr><tr><td>evse</td><td>EVSEType</td><td>0..1</td><td>Optional. This identifies which evse (and connector) of the Charging Station is used.</td></tr><tr><td>meterValue</td><td>MeterValueType</td><td>0..*</td><td>Optional. This contains the relevant meter values. Depending on the EventType of this TransactionEvent the following Configuration Variable is used to configure the content: Started: SampledDataTxStartedMeasurands Updated: SampledDataTxUpdatedMeasurands Ended: SampledDataTxEndedMeasurands & AlignedDataTxEndedMeasurands</td></tr></table>
+
+# 1.60.2. TransactionResponse
+
+This contains the field definition of the TransactionEventResponse PDU sent by the CSMS to the Charging Station in response to a
+
+TransactionEventRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>totalCost</td><td>decimal</td><td>0..1</td><td>Optional. When eventType of TransactionRequest is Updated, then this value contains the running cost. When eventType of TransactionRequest is Ended, then this contains the final total cost of this transaction, including taxes, in the currency configured with the Configuration Variable: Currency. Absence of this value does not imply that the transaction was free. To indicate a free transaction, the CSMS SHALL send a value of 0.00.</td></tr><tr><td>chargingPriority</td><td>integer</td><td>0..1</td><td>Optional. Priority from a business point of view. Default priority is 0, The range is from -9 to 9. Higher values indicate a higher priority. The chargingPriority in TransactionResponse is temporarily, so it may not be set in the IdTokenInfoType afterwards. Also the chargingPriority in TransactionResponse overrules the one in IdTokenInfoType.</td></tr><tr><td>idTokenInfo</td><td>IdTokenInfoType</td><td>0..1</td><td>Optional. This contains information about authorization status, expiry and group id. Is required when the transactionRequest contained an idToken.</td></tr><tr><td>updatedPersonalMessage</td><td>MessageContentType</td><td>0..1</td><td>Optional. This can contain updated personal message that can be shown to the EV Driver. This can be used to provide updated tariff information.</td></tr></table>
+
+# 1.61. TriggerMessage
+
+# 1.61.1. TriggerMessageRequest
+
+This contains the field definition of the TriggerMessageRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestedMessage</td><td>MessageTriggerEnumType</td><td>1..1</td><td>Required. Type of message to be triggered.</td></tr><tr><td>evse</td><td>EVsetType</td><td>0..1</td><td>Optional. Can be used to specify the EVSE and Connector if required for the message which needs to be sent.</td></tr></table>
+
+# 1.61.2. TriggerMessageResponse
+
+This contains the field definition of the TriggerMessageResponse PDU sent by the Charging Station to the CSMS in response to TriggerMessageResponse.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>TriggerMessageStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the Charging Station will send the requested notification or not.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.62. UnlockConnector
+
+# 1.62.1. UnlockConnectorRequest
+
+This contains the field definition of the UnlockConnectorRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer</td><td>1..1</td><td>Required. This contains the identifier of the EVSE for which a connector needs to be unlocked.</td></tr><tr><td>connectorId</td><td>integer</td><td>1..1</td><td>Required. This contains the identifier of the connector that needs to be unlocked.</td></tr></table>
+
+# 1.62.2. UnlockConnectorResponse
+
+This contains the field definition of the UnlockConnectorResponse PDU sent by the Charging Station to the CSMS in response to an UnlockConnectorRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>UnlockStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station has unlocked the connector.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.63. UnpublishFirmware
+
+# 1.63.1. UnpublishFirmwareRequest
+
+This contains the field definition of the UnpublishFirmwareRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>checksum</td><td>identifierString[0..32]</td><td>1..1</td><td>Required. The MD5 checksum over the entire firmware file as a hexadecimal string of length 32.</td></tr></table>
+
+# 1.63.2. UnpublishFirmwareResponse
+
+This contains the field definition of the UnpublishFirmwareResponse PDU sent by the Charging Station to the CSMS in response to a UnpublishFirmwareRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>UnpublishFirmwareStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the Local Controller succeeded in unpublishing the firmware.</td></tr></table>
+
+# 1.64. UpdateFirmware
+
+# 1.64.1. UpdateFirmwareRequest
+
+This contains the field definition of the UpdateFirmwareRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>retries</td><td>integer</td><td>0..1</td><td>Optional. This specifies how many times the Charging Station must retry to download the firmware before giving up. If this field is not present, it is left to Charging Station to decide how many times it wants to retry. If the value is 0, it means: no retries.</td></tr><tr><td>retrypInterval</td><td>integer</td><td>0..1</td><td>Optional. The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charging Station to decide how long to wait between attempts.</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of this request</td></tr><tr><td>firmware</td><td>FirmwareType</td><td>1..1</td><td>Required. Specifies the firmware to be updated on the Charging Station.</td></tr></table>
+
+# 1.64.2. UpdateFirmwareResponse
+
+This contains the field definition of the UpdateFirmwareResponse PDU sent by the Charging Station to the CSMS in response to an UpdateFirmwareRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>UpdateFirmwareStatusEnumType</td><td>1..1</td><td>Required. This field indicates whether the Charging Station was able to accept the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 2. Datatypes
+
+# 2.1. ACChargingParametersType
+
+Class
+
+EV AC charging parameters.
+
+ACChargingParametersType is used by: Common:ChargingNeedsType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>energyAmount</td><td>integer</td><td>1..1</td><td>Required. Amount of energy requested (in Wh). This includes energy required for preconditioning.</td></tr><tr><td>evMinCurrent</td><td>integer</td><td>1..1</td><td>Required. Minimum current (amps) supported by the electric vehicle (per phase).</td></tr><tr><td>evMaxCurrent</td><td>integer</td><td>1..1</td><td>Required. Maximum current (amps) supported by the electric vehicle (per phase). Includes cable capacity.</td></tr><tr><td>evMaxVoltage</td><td>integer</td><td>1..1</td><td>Required. Maximum voltage supported by the electric vehicle</td></tr></table>
+
+# 2.2. Additional类型的
+
+Class
+
+Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.
+
+AdditionalInfoType is used by: Common:IdTokenType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>additionalIdToken</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. This field specifies the additional IdToken.</td></tr><tr><td>type</td><td>string[0..50]</td><td>1..1</td><td>Required. This defines the type of the additionalIdToken. This is a custom type, so the implementation needs to be agreed upon by all involved parties.</td></tr></table>
+
+# 2.3.APNType
+
+Class
+
+Collection of configuration data needed to make a data-connection over a cellular network.
+
+# NOTE
+
+When asking a GSM modem to dial in, it is possible to specify which mobile operator should be used. This can be done with the mobile country code (MCC) in combination with a mobile network code (MNC). Example: If your preferred network is Vodafone Netherlands, the MCC=204 and the MNC=04 which means the key PreferredNetwork = 20404 Some modems allows to specify a preferred network, which means, if this network is not available, a different network is used. If you specify UseOnlyPreferredNetwork and this network is not available, the modem will not dial in.
+
+APNType is used by: SetNetworkProfileRequest.NetworkConnectionProfileType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>apn</td><td>string[0..512]</td><td>1..1</td><td>Required. The Access Point Name as an URL.</td></tr><tr><td>apnUserName</td><td>string[0..20]</td><td>0..1</td><td>Optional. APN username.</td></tr><tr><td>apnPassword</td><td>string[0..20]</td><td>0..1</td><td>Optional. APN Password.</td></tr><tr><td>simPin</td><td>integer</td><td>0..1</td><td>Optional. SIM card pin code.</td></tr><tr><td>preferredNetwork</td><td>identifierString[0..6]</td><td>0..1</td><td>Optional. Preferred network, written as MCC and MNC concatenated. See note.</td></tr><tr><td>useOnlyPreferredNetwork</td><td>boolean</td><td>0..1</td><td>Optional. Default: false. Use only the preferred Network, do not dial in when not available. See Note.</td></tr><tr><td>apnAuthentication</td><td>APNAAuthenticationEnumType</td><td>1..1</td><td>Required. Authentication method.</td></tr></table>
+
+# 2.4. AuthorizationData
+
+Class
+
+Contains the identifier to use for authorization.
+
+AuthorizationData is used by: SendLocalListRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>idTokenInfo</td><td>IdTokenInfoType</td><td>0..1</td><td>Optional. Required when UpdateType is Full. This contains information about authorization status, expiry and group id. For a Differential update the following applies: If this element is present, then this entry SHALL be added or updated in the Local Authorization List. If this element is absent, the entry for this IdToken in the Local Authorization List SHALL be deleted.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>1..1</td><td>Required. This contains the identifier which needs to be stored for authorization.</td></tr></table>
+
+# 2.5. CertificateDataChainType
+
+Class
+
+CertificateDataChainType is used by: GetInstalledCertificatesResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateType</td><td>GetCertificateldUseEnumType</td><td>1..1</td><td>Required. Indicates the type of the requested certificate(s).</td></tr><tr><td>certificateHashData</td><td>CertificateHashDataType</td><td>1..1</td><td>Required. Information to identify a certificate.</td></tr><tr><td>childCertificateHashData</td><td>CertificateHashDataType</td><td>0..4</td><td>Optional. Information to identify the child certificate(s).</td></tr></table>
+
+# 2.6. CertificateHashDataType
+
+Class
+
+CertificateDataType is used by: Common: CertificateHashDataChainType, DeleteCertificateRequest, CustomerInformationRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>hashAlgorithm</td><td>HashAlgorithmEnumType</td><td>1..1</td><td>Required. Used algorithms for the hashes provided.</td></tr><tr><td>issuerNameHash</td><td>identifierString[0..128]</td><td>1..1</td><td>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.</td></tr><tr><td>issuerKeyHash</td><td>string[0..128]</td><td>1..1</td><td>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.</td></tr><tr><td>serialNumber</td><td>identifierString[0..40]</td><td>1..1</td><td>Required. The string representation of the hexadecimal value of the serial number without the prefix "0x" and without leading zeroes.</td></tr></table>
+
+# 2.7. ChargingLimitType
+
+Class
+
+ChargingLimitType is used by: NotifyChargingLimitRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>chargingLimitSource</td><td>ChargingLimitSourceEnumType</td><td>1..1</td><td>Required. Represents the source of the charging limit.</td></tr><tr><td>isGridCritical</td><td>boolean</td><td>0..1</td><td>Optional. Indicates whether the charging limit is critical for the grid.</td></tr></table>
+
+# 2.8. ChargingNeedsType
+
+Class
+
+ChargingNeedsType is used by: NotifyEVChargingNeedsRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestedEnergyTransfer</td><td>EnergyTransferModeEnumType</td><td>1..1</td><td>Required. Mode of energy transfer requested by the EV.</td></tr><tr><td>departureTime</td><td>dateTime</td><td>0..1</td><td>Optional. Estimated departure time of the EV.</td></tr><tr><td>acChargingParameters</td><td>ACChargingParametersType</td><td>0..1</td><td>Optional. EV AC charging parameters.</td></tr><tr><td>dcChargingParameters</td><td>DCChargingParametersType</td><td>0..1</td><td>Optional. EV DC charging parameters</td></tr></table>
+
+# 2.9. ChargingProfileCriterionType
+
+Class
+
+A ChargingProfile consists of ChargingSchedule, describing the amount of power or current that can be delivered per time interval.
+
+ChargingProfileCriterionType is used by: GetChargingProfilesRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>chargingProfilePurpose</td><td>ChargingProfilePurposeEnumType</td><td>0..1</td><td>Optional. Defines the purpose of the schedule transferred by this profile</td></tr><tr><td>stackLevel</td><td>integer</td><td>0..1</td><td>Optional. Value determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.</td></tr><tr><td>chargingProfileld</td><td>integer</td><td>0..*</td><td>Optional. List of all the chargingProfiles requested. Any ChargingProfile that matches one of these profiles will be reported. If omitted, the Charging Station SHALL not filter on chargingProfileld. This field SHALL NOT contain more ids than set in ChargingProfileEntries.maxLimit</td></tr><tr><td>chargingLimitSource</td><td>ChargingLimitSourceEnumType</td><td>0..4</td><td>Optional. For which charging limit sources, charging profiles SHALL be reported. If omitted, the Charging Station SHALL not filter on chargingLimitSource.</td></tr></table>
+
+# 2.10. ChargingProfileType
+
+Class
+
+A ChargingProfile consists of ChargingSchedule, describing the amount of power or current that can be delivered per time interval.
+
+ChargingProfileType is used by: RequestStartTransactionRequest, SetChargingProfileRequest, ReportChargingProfilesRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>1..1</td><td>Required. Id of ChargingProfile.</td></tr><tr><td>stkLevel</td><td>integer</td><td>1..1</td><td>Required. Value determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.</td></tr><tr><td>chargingProfilePurpose</td><td>ChargingProfilePurposeEnumType</td><td>1..1</td><td>Required. Defines the purpose of the schedule transferred by this profile</td></tr><tr><td>chargingProfileKind</td><td>ChargingProfileKindEnumType</td><td>1..1</td><td>Required. Indicates the kind of schedule.</td></tr><tr><td>recrencyKind</td><td>RecrencyKindEnumType</td><td>0..1</td><td>Optional. Indicates the start point of a recurrence.</td></tr><tr><td>validFrom</td><td>dateTime</td><td>0..1</td><td>Optional. Point in time at which the profile starts to be valid. If absent, the profile is valid as soon as it is received by the Charging Station.</td></tr><tr><td>validTo</td><td>dateTime</td><td>0..1</td><td>Optional. Point in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. SHALL only be included when ChargingProfilePurpose is set to TxProfile in a SetChargingProfileRequest. The transactionId is used to match the profile to a specific transaction.</td></tr><tr><td>chargingSchedule</td><td>ChargingScheduleType</td><td>1..3</td><td>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.</td></tr></table>
+
+# 2.11. ChargingSchedulePeriodType
+
+Class
+
+Charging schedule period structure defines a time period in a charging schedule.
+
+ChargingSchedulePeriodType is used by: Common:ChargingScheduleType, Common:CompositeScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>startPeriod</td><td>integer</td><td>1..1</td><td>Required. Start of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.</td></tr><tr><td>limit</td><td>decimal</td><td>1..1</td><td>Required. Charging rate limit during the schedule period, in the applicable chargingRateUnit, for example in Amperes (A) or Watts (W). Accepts at most one digit fraction (e.g. 8.1).</td></tr><tr><td>numberPhases</td><td>integer</td><td>0..1</td><td>Optional. The number of phases that can be used for charging.
+For a DC EVSE this field should be omitted.
+For an AC EVSE a default value of numberPhases = 3 will be assumed if the field is absent.</td></tr><tr><td>phaseToUse</td><td>integer</td><td>0..1</td><td>Optional. Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true.
+It's not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.</td></tr></table>
+
+# 2.12. ChargingScheduleType
+
+Class
+
+Charging schedule structure defines a list of charging periods, as used in: GetCompositeSchedule.conf and ChargingProfile.
+
+ChargingScheduleType is used by: Common:ChargingProfileType, NotifyChargingLimitRequest, NotifyEVChargingScheduleRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>1..1</td><td>Required. Identifies the ChargingSchedule.</td></tr><tr><td>startSchedule</td><td>dateTime</td><td>0..1</td><td>Optional. Starting point of an absolute or recurring schedule.</td></tr><tr><td>duration</td><td>integer</td><td>0..1</td><td>Optional. Duration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction if chargingProfilePurpose = TxProfile.</td></tr><tr><td>chargingRateUnit</td><td>ChargingRateUnitEnumType</td><td>1..1</td><td>Required. The unit of measure Limit is expressed in.</td></tr><tr><td>minChargingRate</td><td>decimal</td><td>0..1</td><td>Optional. Minimum charging rate supported by the EV. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates. Accepts at most one digit fraction (e.g. 8.1)</td></tr><tr><td>chargingSchedulePeriod</td><td>ChargingSchedulePeriodType</td><td>1..1024</td><td>Required. List of ChargingSchedulePeriod elements defining maximum power or current usage over time. The maximum number of periods, that is supported by the Charging Station, if less than 1024, is set by device model variable SmartChargingCtrl.PeriodsPerSchedule.</td></tr><tr><td>salesTariff</td><td>SalesTariffType</td><td>0..1</td><td>Optional. Sales tariff associated with this charging schedule.</td></tr></table>
+
+# 2.13. ChargingStationType
+
+Class
+
+The physical system where an Electrical Vehicle (EV) can be charged.
+
+ChargingStationType is used by: BootNotificationRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>serialNumber</td><td>string[0..25]</td><td>0..1</td><td>Optional. Vendor-specific device identifier.</td></tr><tr><td>model</td><td>string[0..20]</td><td>1..1</td><td>Required. Defines the model of the device.</td></tr><tr><td>vendorName</td><td>string[0..50]</td><td>1..1</td><td>Required. Identifies the vendor (not necessarily in a unique manner).</td></tr><tr><td>firmwareVersion</td><td>string[0..50]</td><td>0..1</td><td>Optional. This contains the firmware version of the Charging Station.</td></tr><tr><td>modem</td><td>ModemType</td><td>0..1</td><td>Optional. Defines the functional parameters of a communication link.</td></tr></table>
+
+# 2.14. ClearChargingProfileType
+
+Class
+
+A ChargingProfile consists of a ChargingSchedule, describing the amount of power or current that can be delivered per time interval.
+
+ClearChargingProfileType is used by: ClearChargingProfileRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer</td><td>0..1</td><td>Optional. Specifies the id of the EVSE for which to clear charging profiles. An evseld of zero (0) specifies the charging profile for the overall Charging Station. Absence of this parameter means the clearing applies to all charging profiles that match the other criteria in the request.</td></tr><tr><td>chargingProfilePurpose</td><td>ChargingProfilePurposeEnumType</td><td>0..1</td><td>Optional. Specifies to purpose of the charging profiles that will be cleared, if they meet the other criteria in the request.</td></tr><tr><td>stackLevel</td><td>integer</td><td>0..1</td><td>Optional. Specifies the stackLevel for which charging profiles will be cleared, if they meet the other criteria in the request.</td></tr></table>
+
+# 2.15. ClearMonitoringResultType
+
+Class
+
+ClearMonitoringResultType is used by: ClearVariableMonitoringResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ClearMonitoringStatusEnumType</td><td>1..1</td><td>Required. Result of the clear request for this monitor, identified by its Id.</td></tr><tr><td>id</td><td>integer</td><td>1..1</td><td>Required. Id of the monitor of which a clear was requested.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 2.16. ComponentType
+
+Class
+
+A physical or logical component
+
+ComponentType is used by: Common:ComponentVariableType, Common:MessageInfoType, GetVariablesRequest.GetVariableDataType, GetVariablesResponse.GetVariableResultType, NotifyMonitoringReportRequest.MonitoringDataType, NotifyReportRequest.ReportDataType, SetVariableMonitoringRequest.SetMonitoringDataType, SetVariableMonitoringResponse.SetMonitoringResultType, SetVariablesRequest.SetVariableDataType, SetVariablesResponse.SetVariableResultType, NotifyEventRequest.EventDataType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>name</td><td>identifierString[0..50]</td><td>1..1</td><td>Required. Name of the component. Name should be taken from the list of standardized component names whenever possible. CaseInsensitive. strongly advised to use Camel Case.</td></tr><tr><td>instance</td><td>identifierString[0..50]</td><td>0..1</td><td>Optional. Name of instance in case the component exists as multiple instances. CaseInsensitive. strongly advised to use Camel Case.</td></tr><tr><td>evse</td><td>EVSEType</td><td>0..1</td><td>Optional. Specifies the EVSE when component is located at EVSE level, also specifies the connector when component is located at Connector level.</td></tr></table>
+
+# 2.17. ComponentVariableType
+
+Class
+
+Class to report components, variables and variable attributes and characteristics.
+
+ComponentVariableType is used by: GetMonitoringReportRequest, GetReportRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which a report of Variable is requested.</td></tr><tr><td>variable</td><td>VariableType</td><td>0..1</td><td>Optional. Variable(s) for which the report is requested.</td></tr></table>
+
+# 2.18. CompositeScheduleType
+
+Class
+
+CompositeScheduleType is used by: GetCompositeScheduleResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer</td><td>1..1</td><td>Required. The ID of the EVSE for which the schedule is requested. When evseid=0, the Charging Station calculated the expected consumption for the grid connection.</td></tr><tr><td>duration</td><td>integer</td><td>1..1</td><td>Required. Duration of the schedule in seconds.</td></tr><tr><td>scheduleStart</td><td>dateTime</td><td>1..1</td><td>Required. Date and time at which the schedule becomes active. All time measurements within the schedule are relative to this timestamp.</td></tr><tr><td>chargingRateUnit</td><td>ChargingRateUnitEnumType</td><td>1..1</td><td>Required. The unit of measure Limit is expressed in.</td></tr><tr><td>chargingSchedulePeriod</td><td>ChargingSchedulePeriodType</td><td>1..*</td><td>Required. List of ChargingSchedulePeriod elements defining maximum power or current usage over time.</td></tr></table>
+
+# 2.19. ConsumptionCostType
+
+Class
+
+ConsumptionCostType is used by: Common:SalesTariffEntryType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>startValue</td><td>decimal</td><td>1..1</td><td>Required. The lowest level of consumption that defines the starting point of this consumption block. The block interval extends to the start of the next interval.</td></tr><tr><td>cost</td><td>CostType</td><td>1..3</td><td>Required. This field contains the cost details.</td></tr></table>
+
+# 2.20. CostType
+
+Class
+
+CostType is used by: Common:ConsumptionCostType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>costKind</td><td>CostKindEnumType</td><td>1..1</td><td>Required. The kind of cost referred to in the message element amount</td></tr><tr><td>amount</td><td>integer</td><td>1..1</td><td>Required. The estimated or actual cost per kWh</td></tr><tr><td>amountMultiplier</td><td>integer</td><td>0..1</td><td>Optional. Values: -3..3, The amountMultiplier defines the exponent to base 10 (dec). The final value is determined by: amount * 10^ amountMultiplier</td></tr></table>
+
+# 2.21. DCChargingParametersType
+
+Class
+
+EV DC charging parameters
+
+DCChargingParametersType is used by: Common:ChargingNeedsType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evMaxCurrent</td><td>integer</td><td>1..1</td><td>Required. Maximum current (amps) supported by the electric vehicle. Includes cable capacity.</td></tr><tr><td>evMaxVoltage</td><td>integer</td><td>1..1</td><td>Required. Maximum voltage supported by the electric vehicle</td></tr><tr><td>energyAmount</td><td>integer</td><td>0..1</td><td>Optional. Amount of energy requested (in Wh). This includes energy required for preconditioning.</td></tr><tr><td>evMaxPower</td><td>integer</td><td>0..1</td><td>Optional. Maximum power (in W) supported by the electric vehicle. Required for DC charging.</td></tr><tr><td>stateOfCharge</td><td>integer, 0 < = val < = 100</td><td>0..1</td><td>Optional. Energy available in the battery (in percent of the battery capacity)</td></tr><tr><td>evEnergyCapacity</td><td>integer</td><td>0..1</td><td>Optional. Capacity of the electric vehicle battery (in Wh)</td></tr><tr><td>fullSoC</td><td>integer, 0 < = val < = 100</td><td>0..1</td><td>Optional. Percentage of SoC at which the EV considers the battery fully charged. (possible values: 0 - 100)</td></tr><tr><td>bulkSoC</td><td>integer, 0 < = val < = 100</td><td>0..1</td><td>Optional. Percentage of SoC at which the EV considers a fast charging process to end. (possible values: 0 - 100)</td></tr></table>
+
+# 2.22.EventDataType
+
+Class
+
+Class to report an event notification for a component-variable.
+
+EventDataType is used by: NotifyRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>eventId</td><td>integer</td><td>1..1</td><td>Required. Identifies the event. This field can be referred to as a cause by other events.</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp of the moment the report was generated.</td></tr><tr><td>trigger</td><td>EventTriggerEnumType</td><td>1..1</td><td>Required. Type of trigger for this event, e.g. exceeding a threshold value.</td></tr><tr><td>cause</td><td>integer</td><td>0..1</td><td>Optional. Refers to the Id of an event that is considered to be the cause for this event.</td></tr><tr><td>actualValue</td><td>string[0..2500]</td><td>1..1</td><td>Required. Actual value (attributeType Actual) of the variable.The Configuration Variable Reporting研究成果 can be used to limit GetVariableResult_ATTRIBUTEValue,VariableAttribute.value and DataData(actualValue. The max size of these values will always remain equal.</td></tr><tr><td>techCode</td><td>string[0..50]</td><td>0..1</td><td>Optional. Technical (error) code as reported by component.</td></tr><tr><td>techInfo</td><td>string[0..500]</td><td>0..1</td><td>Optional. Technical detail information as reported by component.</td></tr><tr><td>cleared</td><td>boolean</td><td>0..1</td><td>Optional. Cleared is set to true to report the clearing of a monitored situation, i.e. a 'return to normal'.</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. If an event notification is linked to a specific transaction, this field can be used to specify its transactionId.</td></tr><tr><td>variableMonitoringId</td><td>integer</td><td>0..1</td><td>Optional. Identifies the VariableMonitoring which triggered the event.</td></tr><tr><td>eventNotificationType</td><td>EventNotificationEnumType</td><td>1..1</td><td>Required. Specifies the event notification type of the message.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which event is notified.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which event is notified.</td></tr></table>
+
+# 2.23. EVSEType
+
+Class
+
+Electric Vehicle Supply Equipment
+
+EVSetType is used by: Common:ComponentType, TriggerMessageRequest, ChangeAvailabilityRequest, TransactionEventRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>1..1</td><td>Required. EVSE Identifier. This contains a number (>0) designating an EVSE of the Charging Station.</td></tr><tr><td>connectorId</td><td>integer</td><td>0..1</td><td>Optional. An id to designate a specific connector (on an EVSE) by connector index number.</td></tr></table>
+
+# 2.24. FirmwareType
+
+Class
+
+Represents a copy of the firmware that can be loaded/updated on the Charging Station.
+
+FirmwareType is used by: UpdateFirmwareRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>location</td><td>string[0..512]</td><td>1..1</td><td>Required. URI defining the origin of the firmware.</td></tr><tr><td>retrieveDateTime</td><td>dateTime</td><td>1..1</td><td>Required. Date and time at which the firmware shall be retrieved.</td></tr><tr><td>installDateTime</td><td>dateTime</td><td>0..1</td><td>Optional. Date and time at which the firmware shall be installed.</td></tr><tr><td>signingCertificate</td><td>string[0..5500]</td><td>0..1</td><td>Optional. Certificate with which the firmware was signed. PEM encoded X.509 certificate.</td></tr><tr><td>signature</td><td>string[0..800]</td><td>0..1</td><td>Optional. Base64 encoded firmware signature.</td></tr></table>
+
+# 2.25. GetVariableDataType
+
+Class
+
+Class to hold parameters for GetVariables request.
+
+GetVariableDataType is used by: GetVariablesRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>attributeType</td><td>AttributeEnumType</td><td>0..1</td><td>Optional. Attribute type for which value is requested. When absent, default Actual is assumed.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which the Variable is requested.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which the attribute value is requested.</td></tr></table>
+
+# 2.26. GetVariableResultType
+
+Class
+
+Class to hold results of GetVariables request.
+
+GetVariableResultType is used by: GetVariablesResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>attributeStatus</td><td>GetVariableStatusEnumType</td><td>1..1</td><td>Required. Result status of getting the variable.</td></tr><tr><td>attributeType</td><td>AttributeEnumType</td><td>0..1</td><td>Optional. Attribute type for which value is requested. When absent, default Actual is assumed.</td></tr><tr><td>attributeValue</td><td>string[0..2500]</td><td>0..1</td><td>Optional. Value of requested attribute type of component-variable. This field can only be empty when the given status is NOT accepted.The Configuration Variable ReportingValueSize can be used to limit GetVariableResult(attributeValue,VariableAttribute.value and EventDataactualValue. The max size of these values will always remain equal.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which the Variable is requested.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which the attribute value is requested.</td></tr><tr><td>attributeStatusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed attribute status information.</td></tr></table>
+
+# 2.27. IdTokenInfoType
+
+Class
+
+Contains status information about an identifier. It is advised to not stop charging for a token that expires during charging, as ExpiryDate is only used for caching purposes. If ExpiryDate is not given, the status has no end date.
+
+IdTokenInfoType is used by: Common:AuthorizationData,authorizeResponse,TransactionEventResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>AuthorizationStatusEnumType</td><td>1..1</td><td>Required. Current status of the ID Token.</td></tr><tr><td>cacheExpiryDateTime</td><td>dateTime</td><td>0..1</td><td>Optional. Date and Time after which the token must be considered invalid.</td></tr><tr><td>chargingPriority</td><td>integer</td><td>0..1</td><td>Optional. Priority from a business point of view. Default priority is 0, The range is from -9 to 9. Higher values indicate a higher priority. The chargingPriority in TransactionEventResponse overrules this one.</td></tr><tr><td>language1</td><td>string[0..8]</td><td>0..1</td><td>Optional. Preferred user interface language of identifier user. Contains a language code as defined in [RFC5646].</td></tr><tr><td>evseld</td><td>integer</td><td>0..*</td><td>Optional. Only used when the IdToken is only valid for one or more specific EVSEs, not for the entire Charging Station.</td></tr><tr><td>language2</td><td>string[0..8]</td><td>0..1</td><td>Optional. Second preferred user interface language of identifier user. Don’t use when language1 is omitted, has to be different from language1. Contains a language code as defined in [RFC5646].</td></tr><tr><td>groupldToken</td><td>IdTokenType</td><td>0..1</td><td>Optional. This contains the group identifier.</td></tr><tr><td>personalMessage</td><td>MessageContentType</td><td>0..1</td><td>Optional. Personal message that can be shown to the EV Driver and can be used for tariff information, user greetings etc.</td></tr></table>
+
+# 2.28. Id-TokenType
+
+Class
+
+Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.
+
+IdTokenType is used by: Common:AuthorizationData, Common:IdTokenInfoType, RequestStartTransactionRequest,authorizeRequest, TransactionEventRequest, ReserveNowRequest, CustomerInformationRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>idToken</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.</td></tr><tr><td>type</td><td>IdTokenEnumType</td><td>1..1</td><td>Required. Enumeration of possible idToken types.</td></tr><tr><td>additionalInfo</td><td>AdditionalInfoType</td><td>0..*</td><td>Optional. AdditionalInfo can be used to send extra information which can be validated by the CSMS in addition to the regular authorization with IdToken. AdditionalInfo contains one or more custom types, which need to be agreed upon by all parties involved. When AdditionalInfo is NOT implemented or a not supported AdditionalInfo.type is used, the CSMS/Charging Station MAY ignore the AdditionalInfo.</td></tr></table>
+
+# 2.29. ParametersType
+
+Class
+
+Generic class for the configuration of logging entries.
+
+LogParametersType is used by: GetLogRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>remoteLocation</td><td>string[0..512]</td><td>1..1</td><td>Required. The URL of the location at the remote system where the log should be stored.</td></tr><tr><td>oldestTimestamp</td><td>dateTime</td><td>0..1</td><td>Optional. This contains the date and time of the oldest logging information to include in the diagnostics.</td></tr><tr><td>latestTimestamp</td><td>dateTime</td><td>0..1</td><td>Optional. This contains the date and time of the latest logging information to include in the diagnostics.</td></tr></table>
+
+# 2.30. MessageContentType
+
+Class
+
+Contains message details, for a message to be displayed on a Charging Station.
+
+MessageContentType is used by: Common:IdTokenInfoType, Common:MessageInfoType, TransactionEventResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>format</td><td>MessageFormatEnumType</td><td>1..1</td><td>Required. Format of the message.</td></tr><tr><td>language</td><td>string[0..8]</td><td>0..1</td><td>Optional. Message language identifier. Contains a language code as defined in [RFC5646].</td></tr><tr><td>content</td><td>string[0..512]</td><td>1..1</td><td>Required. Message contents.</td></tr></table>
+
+# 2.31. MessagingInfoType
+
+Class
+
+Contains message details, for a message to be displayed on a Charging Station.
+
+MessageInfoType is used by: SetDisplayMessageRequest, NotifyDisplayMessagesRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>1..1</td><td>Required. Unique id within an exchange context. It is defined within the OCPP context as a positive Integer value (greater or equal to zero).</td></tr><tr><td>priority</td><td>MessagePriorityEnumType</td><td>1..1</td><td>Required. With what priority should this message be shown</td></tr><tr><td>state</td><td>MessageStateEnumType</td><td>0..1</td><td>Optional. During what state should this message be shown. When omitted this message should be shown in any state of the Charging Station.</td></tr><tr><td>startTime</td><td>dateTime</td><td>0..1</td><td>Optional. From what date-time should this message be shown. If omitted: directly.</td></tr><tr><td>endDateTime</td><td>dateTime</td><td>0..1</td><td>Optional. Until what date-time should this message be shown, after this date/time this message SHALL be removed.</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. During which transaction shall this message be shown. Message SHALL be removed by the Charging Station after transaction has ended.</td></tr><tr><td>message</td><td>MessageContentType</td><td>1..1</td><td>Required. Contains message details for the message to be displayed on a Charging Station.</td></tr><tr><td>display</td><td>ComponentType</td><td>0..1</td><td>Optional. When a Charging Station has multiple Displays, this field can be used to define to which Display this message belongs.</td></tr></table>
+
+# 2.32. MeterValueType
+
+Class
+
+Collection of one or more sampled values in MeterValuesRequest and TransactionEvent. All sampled values in a MeterValue are sampled at the same point in time.
+
+MeterValueType is used by: MeterValuesRequest, TransactionEventRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp for measured value(s).</td></tr><tr><td>sampledValue</td><td>SampledValueType</td><td>1.*</td><td>Required. One or more measured values</td></tr></table>
+
+# 2.33. ModemType
+
+Class
+
+Defines parameters required for initiating and maintaining wireless communication with other devices.
+
+ModemType is used by: BootNotificationRequest.CchargingStationType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>iccid</td><td>identifierString[0..20]</td><td>0..1</td><td>Optional. This contains the ICCID of the modem's SIM card.</td></tr><tr><td>imsi</td><td>identifierString[0..20]</td><td>0..1</td><td>Optional. This contains the IMSI of the modem's SIM card.</td></tr></table>
+
+# 2.34. MonitoringDataType
+
+Class
+
+Class to hold parameters of SetVariableMonitoring request.
+
+MonitoringDataType is used by: NotifyMonitoringRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which monitoring report was requested.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which monitoring report was requested.</td></tr><tr><td>variableMonitoring</td><td>VariableMonitoringType</td><td>1..*</td><td>Required. List of monitors for this Component-Variable pair.</td></tr></table>
+
+# 2.35. NetworkConnectionProfileType
+
+Class
+
+The NetworkConnectionProfile defines the functional and technical parameters of a communication link.
+
+NetworkConnectionProfileType is used by: SetNetworkProfileRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>ocppVersion</td><td>OCPPVersionEnumType</td><td>1..1</td><td>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.</td></tr><tr><td>ocppTransport</td><td>OCPPTransportEnumType</td><td>1..1</td><td>Required. Defines the transport protocol (e.g. SOAP or JSON). Note: SOAP is not supported in OCPP 2.0, but is supported by other versions of OCPP.</td></tr><tr><td>ocppCsmsUrl</td><td>string[0..512]</td><td>1..1</td><td>Required. URL of the CSMS(s) that this Charging Station communicates with, without the Charging Station identity part. The SecurityCtrl.Identity field is appended to ocppCsmsUrl to provide the full websocket URL</td></tr><tr><td>messageTimeout</td><td>integer</td><td>1..1</td><td>Required. Duration in seconds before a message send by the Charging Station via this network connection times-out. The best setting depends on the underlying network and response times of the CSMS. If you are looking for a some guideline: use 30 seconds as a starting point.</td></tr><tr><td>securityProfile</td><td>integer</td><td>1..1</td><td>Required. This field specifies the security profile used when connecting to the CSMS with this NetworkConnectionProfile.</td></tr><tr><td>ocppInterface</td><td>OCPPInterfaceEnumType</td><td>1..1</td><td>Required. Applicable Network Interface. Charging Station is allowed to use a different network interface to connect if the given one does not work</td></tr><tr><td>vpn</td><td>VPNType</td><td>0..1</td><td>Optional. Settings to be used to set up the VPN connection</td></tr><tr><td>apn</td><td>APNType</td><td>0..1</td><td>Optional. Collection of configuration data needed to make a data-connection over a cellular network.</td></tr></table>
+
+# 2.36. OCSPRequestDataType
+
+Class
+
+OCSPRequestDataType is used by: InvalidateRequest, GetCertificateStatusRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>hashAlgorithm</td><td>HashAlgorithmEnumType</td><td>1..1</td><td>Required. Used algorithms for the hashes provided.</td></tr><tr><td>issuerNameHash</td><td>identifierString[0..128]</td><td>1..1</td><td>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.</td></tr><tr><td>issuerKeyHash</td><td>string[0..128]</td><td>1..1</td><td>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.</td></tr><tr><td>serialNumber</td><td>identifierString[0..40]</td><td>1..1</td><td>Required. The string representation of the hexadecimal value of the serial number without the prefix "0x" and without leading zeroes.</td></tr><tr><td>responderURL</td><td>string[0..512]</td><td>1..1</td><td>Required. This contains the responder URL (Case insensitive).</td></tr></table>
+
+# 2.37. RelativeTimeIntervalType
+
+Class
+
+RelativeTimeIntervalType is used by: Common.SalesTariffEntryType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>start</td><td>integer</td><td>1..1</td><td>Required. Start of the interval, in seconds from NOW.</td></tr><tr><td>duration</td><td>integer</td><td>0..1</td><td>Optional. Duration of the interval, in seconds.</td></tr></table>
+
+# 2.38.ReportDataType
+
+Class
+
+Class to report components, variables and variable attributes and characteristics.
+
+ReportDataType is used by: NotifyRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which a report of Variable is requested.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which report is requested.</td></tr><tr><td>attribute</td><td>VariableAttributeType</td><td>1..4</td><td>Required. Attribute data of a variable.</td></tr><tr><td>characteristics</td><td>VariableCharacteristicsType</td><td>0..1</td><td>Optional. Fixed read-only parameters of a variable.</td></tr></table>
+
+# 2.39. SalesTariffEntryType
+
+Class
+
+SalesTariffEntryType is used by: Common:SalesTariffType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>ePriceLevel</td><td>integer, 0 < = val</td><td>0..1</td><td>Optional. Defines the price level of this SalesTariffEntry (referring to NumEPriceLevels). Small values for the EPriceLevel represent a cheaper TariffEntry. Large values for the EPriceLevel represent a more expensive TariffEntry.</td></tr><tr><td>relativeTimeInterval</td><td>RelativeTimeIntervalType</td><td>1..1</td><td>Required. Defines the time interval the SalesTariffEntry is valid for, based upon relative times.</td></tr><tr><td>consumptionCost</td><td>ConsumptionCostType</td><td>0..3</td><td>Optional. Defines additional means for further relative price information and/or alternative costs.</td></tr></table>
+
+# 2.40. SalesTariffType
+
+Class
+
+NOTE ThisdataType is based on dataTypes from ISO 15118-2.
+
+SalesTariffType is used by: Common:ChargingScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>1..1</td><td>Required. SalesTariff identifier used to identify one sales tariff. An SAID remains a unique identifier for one schedule throughout a charging session.</td></tr><tr><td>salesTariffDescription</td><td>string[0..32]</td><td>0..1</td><td>Optional. A human readable title/short description of the sales tariff e.g. for HMI display purposes.</td></tr><tr><td>numEPriceLevels</td><td>integer</td><td>0..1</td><td>Optional. Defines the overall number of distinct price levels used across all provided SalesTariff elements.</td></tr><tr><td>salesTariffEntry</td><td>SalesTariffEntryType</td><td>1..1024</td><td>Required. Encapsulating element describing all relevant details for one time interval of the SalesTariff. The number of SalesTariffEntry elements is limited by the parameter maxScheduleTuples.</td></tr></table>
+
+# 2.41. SampledValueType
+
+Class
+
+Single sampled value in MeterValues. Each value can be accompanied by optional fields.
+
+To save on mobile data usage, default values of all of the optional fields are such that. The value without any additional fields will be interpreted, as a register reading of active import energy in Wh (Watt-hour) units.
+
+SampledValueType is used by: Common:MeterValueType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>value</td><td>decimal</td><td>1..1</td><td>Required. Indicates the measured value.</td></tr><tr><td>context</td><td>ReadingContextEnumType</td><td>0..1</td><td>Optional. Type of detail value: start, end or sample. Default = "Sample.Periodic"</td></tr><tr><td>measurand</td><td>MeasurandEnumType</td><td>0..1</td><td>Optional. Type of measurement. Default = "Energy.Active.Importantly Registered"</td></tr><tr><td>phase</td><td>PhaseEnumType</td><td>0..1</td><td>Optional. Indicates how the measured value is to be interpreted. For instance between L1 and neutral (L1-N) Please note that not all values of phase are applicable to all Measurands. When phase is absent, the measured value is interpreted as an overall value.</td></tr><tr><td>location</td><td>LocationEnumType</td><td>0..1</td><td>Optional. Indicates where the measured value has been sampled. Default = "Outlet"</td></tr><tr><td>signedMeterValue</td><td>SignedMeterValueType</td><td>0..1</td><td>Optional. Contains the MeterValueSignature with sign/encoding method information.</td></tr><tr><td>unitOfMeasure</td><td>UnitOfMeasureType</td><td>0..1</td><td>Optional. Represents a UnitOfMeasure including a multiplier</td></tr></table>
+
+# 2.42. SetMonitoringDataType
+
+Class
+
+Class to hold parameters of SetVariableMonitoring request.
+
+SetMonitoringDataType is used by: SetVariableMonitoringRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>0..1</td><td>Optional. An id SHALL only be given to replace an existing monitor. The Charging Station handles the generation of id's for new monitors.</td></tr><tr><td>transaction</td><td>boolean</td><td>0..1</td><td>Optional. Monitor only active when a transaction is ongoing on a component relevant to this transaction. Default = false.</td></tr><tr><td>value</td><td>decimal</td><td>1..1</td><td>Required. Value for threshold or delta monitoring. For Periodic or PeriodicClockAligned this is the interval in seconds.</td></tr><tr><td>type</td><td>MonitorEnumType</td><td>1..1</td><td>Required. The type of this monitor, e.g. a threshold, delta or periodic monitor.</td></tr><tr><td>severity</td><td>integer</td><td>1..1</td><td>Required. The severity that will be assigned to an event that is triggered by this monitor. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.The severity levels have the following meaning:0-DangerIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately.1-Hardware FailureIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required.2-System FailureIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required.3-CriticalIndicates a critical error. Action is required.4-ErrorIndicates a non-urgent error. Action is required.5-A AlertIndicates an alert event. Default severity for any type of monitoring event.6-WarningIndicates a warning event. Action may be required.7-NoticeIndicates an unusual event. No immediate action is required.8-InformationalIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required.9-DebugIndicates information useful to developers for debugging, not useful during operations.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which monitor is set.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which monitor is set.</td></tr></table>
+
+# 2.43. SetMonitoringResultType
+
+Class
+
+Class to hold result of SetVariableMonitoring request.
+
+SetMonitoringResultType is used by: SetVariableMonitoringResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>0..1</td><td>Optional. Id given to the VariableMonitor by the Charging Station. The Id is only returned when status is accepted. Installed VariableMonitors should have unique id's but the id's of removed Installed monitors should have unique id's but the id's of removed monitors MAY be reused.</td></tr><tr><td>status</td><td>SetMonitoringStatusEnumType</td><td>1..1</td><td>Required. Status is OK if a value could be returned. Otherwise this will indicate the reason why a value could not be returned.</td></tr><tr><td>type</td><td>MonitorEnumType</td><td>1..1</td><td>Required. The type of this monitor, e.g. a threshold, delta or periodic monitor.</td></tr><tr><td>severity</td><td>integer</td><td>1..1</td><td>Required. The severity that will be assigned to an event that is triggered by this monitor. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.The severity levels have the following meaning:0-DangerIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately.1-Hardware FailureIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required.2-System FailureIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required.3-CriticalIndicates a critical error. Action is required.4-ErrorIndicates a non-urgent error. Action is required.5-A AlertIndicates an alert event. Default severity for any type of monitoring event.6-WarningIndicates a warning event. Action may be required.7-NoticeIndicates an unusual event. No immediate action is required.8-InformationalIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required.9-DebugIndicates information useful to developers for debugging, not useful during operations.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which status is returned.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which status is returned.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 2.44. SetVariableDataType
+
+Class
+
+SetVariableDataType is used by: SetVariablesRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>attributeType</td><td>AttributeEnumType</td><td>0..1</td><td>Optional. Type of attribute: Actual, Target, MinSet, MaxSet. Default is Actual when omitted.</td></tr><tr><td>attributeValue</td><td>string[0..1000]</td><td>1..1</td><td>Required. Value to be assigned to attribute of variable. The value is allowed to be an empty string (""). The Configuration Variable ConfigurationValueSize can be used to limit SetVariableData(attributeValue and VariableCharacteristics.valueList. The max size of these values will always remain equal.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. The component for which the variable data is set.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Specifies the that needs to be set.</td></tr></table>
+
+# 2.45. SetVariableResultSetType
+
+Class
+
+SetVariableResultType is used by: SetVariablesResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>attributeType</td><td>AttributeEnumType</td><td>0..1</td><td>Optional. Type of attribute: Actual, Target, MinSet, MaxSet. Default is Actual when omitted.</td></tr><tr><td>attributeStatus</td><td>SetVariableStatusEnumType</td><td>1..1</td><td>Required. Result status of setting the variable.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. The component for which result is returned.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. The variable for which the result is returned.</td></tr><tr><td>attributeStatusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed attribute status information.</td></tr></table>
+
+# 2.46. SignedMeterValueType
+
+Class
+
+Represent a signed version of the meter value.
+
+SignedMeterValueType is used by: Common:SampledValueType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>signedMeterData</td><td>string[0..2500]</td><td>1..1</td><td>Required. Base64 encoded, contains the signed data which might contain more then just the meter value. It can contain information like timestamps, reference to a customer etc.</td></tr><tr><td>signingMethod</td><td>string[0..50]</td><td>1..1</td><td>Required. Method used to create the digital signature.</td></tr><tr><td>encodingMethod</td><td>string[0..50]</td><td>1..1</td><td>Required. Method used to encode the meter values before applying the digital signature algorithm.</td></tr><tr><td>publicKey</td><td>string[0..2500]</td><td>1..1</td><td>Required. Base64 encoded, sending depends on configuration variable PublicKeyWithSignedMeterValue.</td></tr></table>
+
+# 2.47. StatusBarType
+
+Class
+
+Element providing more information about the status.
+
+StatusInfoType is used by: Common:ClearMonitoringResultType, BootNotificationResponse, CancelReservationResponse, TriggerMessageResponse, UnlockConnectorResponse, UpdateFirmwareResponse, ClearDisplayMessageResponse, Get15118EVCertificateResponse, GetCompositeScheduleResponse, ChangeAvailabilityResponse, GetLogResponse, ClearChargingProfileResponse, NotifyEVChargingNeedsResponse, ClearCacheResponse, NotifyEVChargingScheduleResponse, RequestStartTransactionResponse, RequestStopTransactionResponse, SetChargingProfileResponse, SetDisplayMessageResponse, SetNetworkProfileResponse, SignCertificateResponse, DataTransferResponse, CertificateSignedResponse, DeleteCertificateResponse, GetChargingProfilesResponse, GetInstalledCertificatesResponse, InstallCertificateResponse, GetBaseReportResponse, GetMonitoringReportResponse, GetReportResponse, GetVariablesResponse.GetVariableResultType, ReserveNowResponse, SetMonitoringBaseResponse, SetMonitoringLevelResponse, SetVariableMonitoringResponse.SetMonitoringResultType, SetVariablesResponse.setVariableResultType, PublishFirmwareResponse, GetCertificateStatusResponse, ResetResponse, GetDisplayMessagesResponse, CustomerInformationResponse, SendLocalListResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>reasonCode</td><td>string[0..20]</td><td>1..1</td><td>Required. A predefined code for the reason why the status is returned in this response. The string is case-insensitive.</td></tr><tr><td>additionalInfo</td><td>string[0..512]</td><td>0..1</td><td>Optional. Additional text to provide detailed information.</td></tr></table>
+
+# 2.48. TransactionType
+
+Class
+
+TransactionType is used by: TransactionEventRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. This contains the Id of the transaction.</td></tr><tr><td>chargingState</td><td>ChargingStateEnumType</td><td>0..1</td><td>Optional. Current charging state, is required when state has changed.</td></tr><tr><td>timeSpentCharging</td><td>integer</td><td>0..1</td><td>Optional. Contains the total time that energy flowed from EVSE to EV during the transaction (in seconds). Note that timeSpentCharging is smaller or equal to the duration of the transaction.</td></tr><tr><td>stoppedReason</td><td>ReasonEnumType</td><td>0..1</td><td>Optional. The <i>stoppedReason </i>is the reason/event that 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 <i>stoppedReason </i>is "Local"</td></tr><tr><td>remoteStartId</td><td>integer</td><td>0..1</td><td>Optional. The ID given to remote start request (RequestStartTransactionRequest. This enables to CSMS to match the started transaction to the given start request.</td></tr></table>
+
+# 2.49. UnitOfMeasureType
+
+Class
+
+Represents a UnitOfMeasure with a multiplier
+
+UnitOfMeasureType is used by: Common:SampledValueType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>unit</td><td>string[0..20]</td><td>0..1</td><td>Optional. Unit of the value. Default = "Wh" if the (default) measurand is an "Energy" type. This field SHALL use a value from the list Standardized Units of Measurements in Part 2 Appendices. If an applicable unit is available in that list, otherwise a "custom" unit might be used.</td></tr><tr><td>multiplier</td><td>integer</td><td>0..1</td><td>Optional. Multiplier, this value represents the exponent to base 10. I.e. multiplier 3 means 10 raised to the 3rd power. Default is 0.</td></tr></table>
+
+# 2.50. VariableAttributeType
+
+Class
+
+Attribute data of a variable.
+
+VariableAttributeType is used by: NotifyReportRequest.ReportDataType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>type</td><td>AttributeEnumType</td><td>0..1</td><td>Optional. Attribute: Actual, MinSet, MaxSet, etc. Defaults to Actual if absent.</td></tr><tr><td rowspan="2">value</td><td rowspan="2">string[0..2500]</td><td rowspan="2">0..1</td><td>Optional. Value of the attribute. May only be omitted when mutability is set to 'WriteOnly'.</td></tr><tr><td>The Configuration Variable ReportingValueSize can be used to limit GetVariableResult(attributeValue, VariableAttribute.value and EventDataactualValue. The max size of these values will always remain equal.</td></tr><tr><td>mutability</td><td>MutabilityEnumType</td><td>0..1</td><td>Optional. Defines the mutability of this attribute. Default is ReadWrite when omitted.</td></tr><tr><td>persistent</td><td>boolean</td><td>0..1</td><td>Optional. If true, value will be persistent across system reboots or power down. Default when omitted is false.</td></tr><tr><td>constant</td><td>boolean</td><td>0..1</td><td>Optional. If true, value that will never be changed by the Charging Station at runtime. Default when omitted is false.</td></tr></table>
+
+# 2.51. VariableCharacteristicsType
+
+Class
+
+Fixed read-only parameters of a variable.
+
+VariableCharacteristicsType is used by: NotifyReportRequest.ReportDataType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>unit</td><td>string[0..16]</td><td>0..1</td><td>Optional. Unit of the variable. When the transmitted value has a unit, this field SHALL be included.</td></tr><tr><td>dataType</td><td>DataEnumType</td><td>1..1</td><td>Required. Data type of this variable.</td></tr><tr><td>minLimit</td><td>decimal</td><td>0..1</td><td>Optional. Minimum possible value of this variable.</td></tr><tr><td>maxLimit</td><td>decimal</td><td>0..1</td><td>Optional. Maximum possible value of this variable. When the datatype of this Variable is String, OptionList, SequenceList or MemberList, this field defines the maximum length of the (CSV) string.</td></tr><tr><td>valuesList</td><td>string[0..1000]</td><td>0..1</td><td>Optional. Mandatory whendataType = OptionList, MemberList or 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.</td></tr><tr><td>supportsMonitoring</td><td>boolean</td><td>1..1</td><td>Required. Flag indicating if this variable supports monitoring.</td></tr></table>
+
+# 2.52. VariableMonitoringType
+
+Class
+
+A monitoring setting for a variable.
+
+VariableMonitoringType is used by: NotifyMonitoringReportRequest.MonitoringDataType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>1..1</td><td>Required. Identifies the monitor.</td></tr><tr><td>transaction</td><td>boolean</td><td>1..1</td><td>Required. Monitor only active when a transaction is ongoing on a component relevant to this transaction.</td></tr><tr><td>value</td><td>decimal</td><td>1..1</td><td>Required. Value for threshold or delta monitoring. For Periodic or PeriodicClockAligned this is the interval in seconds.</td></tr><tr><td>type</td><td>MonitorEnumType</td><td>1..1</td><td>Required. The type of this monitor, e.g. a threshold, delta or periodic monitor.</td></tr><tr><td>severity</td><td>integer</td><td>1..1</td><td>Required. The severity that will be assigned to an event that is triggered by this monitor. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.The severity levels have the following meaning:0-DangerIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately.1-Hardware FailureIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required.2-System FailureIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required.3-CriticalIndicates a critical error. Action is required.4-ErrorIndicates a non-urgent error. Action is required.5-A AlertIndicates an alert event. Default severity for any type of monitoring event.6-WarningIndicates a warning event. Action may be required.7-NoticeIndicates an unusual event. No immediate action is required.8-InformationalIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required.9-DebugIndicates information useful to developers for debugging, not useful during operations.</td></tr></table>
+
+# 2.53.类型的
+
+Class
+
+Reference key to a component-variable.
+
+VariableType is used by: Common:ComponentVariableType, GetVariablesRequest.GetVariableDataType,
+
+GetVariablesResponse.getVariableResultType, NotifyMonitoringReportRequest.MonitoringDataType, NotifyReportRequest.ReportDataType, SetVariableMonitoringRequest.SetMonitoringDataType, SetVariableMonitoringResult.SetMonitoringResultType, SetVariablesRequest.SetVariableDataType, SetVariablesResponse.SetVariableResultType, NotifyEventRequest.EventDataType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>name</td><td>identifierString[0..50]</td><td>1..1</td><td>Required. Name of the variable. Name should be taken from the list of standardized variable names whenever possible. CaseInsensitive. strongly advised to use Camel Case.</td></tr><tr><td>instance</td><td>identifierString[0..50]</td><td>0..1</td><td>Optional. Name of instance in case the variable exists as multiple instances. CaseInsensitive. strongly advised to use Camel Case.</td></tr></table>
+
+# 2.54. VPNType
+
+Class
+
+VPN Configuration settings
+
+VPNType is used by: SetNetworkProfileRequest.NetworkConnectionProfileType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>server</td><td>string[0..512]</td><td>1..1</td><td>Required. VPN Server Address</td></tr><tr><td>user</td><td>string[0..20]</td><td>1..1</td><td>Required. VPN User</td></tr><tr><td>group</td><td>string[0..20]</td><td>0..1</td><td>Optional. VPN group.</td></tr><tr><td>password</td><td>string[0..20]</td><td>1..1</td><td>Required. VPN Password.</td></tr><tr><td>key</td><td>string[0..255]</td><td>1..1</td><td>Required. VPN shared secret.</td></tr><tr><td>type</td><td>VPNEnumType</td><td>1..1</td><td>Required. Type of VPN</td></tr></table>
+
+# 3. Enumerations
+
+# 3.1. APNAAuthenticationEnumType
+
+Enumeration
+
+APNAuthenticationEnumType is used by: setNetworkProfile:SetNetworkProfileRequest.APNType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>CHAP</td><td>Use CHAP authentication</td></tr><tr><td>NONE</td><td>Use no authentication</td></tr><tr><td>PAP</td><td>Use PAP authentication</td></tr><tr><td>AUTO</td><td>Sequentially try CHAP, PAP, NONE.</td></tr></table>
+
+# 3.2. AttributeEnumType
+
+Enumeration
+
+AttributeEnumType is used by: Common:VariableAttributeType, getVariables:GetVariablesRequest.GetVariableDataType, getVariables:GetVariablesResponse.GetVariableResultType, setVariables:SetVariablesRequest.SetVariableDataType, setVariables:SetVariablesResponse.SetVariableResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Actual</td><td>The actual value of the variable.</td></tr><tr><td>Target</td><td>The target value for this variable.</td></tr><tr><td>MinSet</td><td>The minimal allowed value for this variable</td></tr><tr><td>MaxSet</td><td>Thne maximum allowed value for this variable</td></tr></table>
+
+# 3.3. AuthorizationStatusEnumType
+
+Enumeration
+
+Status of an authorization response.
+
+AuthorizationStatusEnumType is used by: Common:IdTokenInfoType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Identifier is allowed for charging.</td></tr><tr><td>Blocked</td><td>Identifier has been blocked. Not allowed for charging.</td></tr><tr><td>ConcurrentTx</td><td>Identifier is already involved in another transaction and multiple transactions are not allowed. (Only relevant for the response to a transactionRequest(eventType=Started).)</td></tr><tr><td>Expired</td><td>Identifier has expired. Not allowed for charging.</td></tr><tr><td>Invalid</td><td>Identifier is invalid. Not allowed for charging.</td></tr><tr><td>NoCredit</td><td>Identifier is valid, but EV Driver doesn’t have enough credit to start charging. Not allowed for charging.</td></tr><tr><td>NotAllowedTypeEVE</td><td>Identifier is valid, but not allowed to charge at this type of EVSE.</td></tr><tr><td>NotAtThisLocation</td><td>Identifier is valid, but not allowed to charge at this location.</td></tr><tr><td>NotAtThisTime</td><td>Identifier is valid, but not allowed to charge at this location at this time.</td></tr><tr><td>Unknown</td><td>Identifier is unknown. Not allowed for charging.</td></tr></table>
+
+# 3.4.authorizeCertificateStatusEnumType
+
+Enumeration
+
+Status of the EV Contract certificate.
+
+AuthorizationCertificateStatusEnumType is used by: authorize:AuthorizationResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Positive response</td></tr><tr><td>SignatureError</td><td></td></tr><tr><td>CertificateExpired</td><td>If the contract certificate in the AuthorizationRequest is expired.</td></tr><tr><td>CertificateRevoked</td><td>If the Charging Station or CSMS determine (via a CRL or OCSP response) that the contract certificate in the AuthorizationRequest is marked as revoked.</td></tr><tr><td>NoCertificateAvailable</td><td></td></tr><tr><td>CertChainError</td><td>If the contract certificate contained in the AuthorizationRequest message is not valid.</td></tr><tr><td>ContractCancelled</td><td>If the EMAID provided by EVCC is invalid, unknown, expired or blocked.</td></tr></table>
+
+# 3.5. BootReasonEnumType
+
+Enumeration
+
+BootReasonEnumType is used by: bootNotification:BootNotificationRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ApplicationReset</td><td>The Charging Station rebooted due to an application error.</td></tr><tr><td>FirmwareUpdate</td><td>The Charging Station rebooted due to a firmware update.</td></tr><tr><td>LocalReset</td><td>The Charging Station rebooted due to a local reset command.</td></tr><tr><td>PowerUp</td><td>The Charging Station powered up and registers itself with the CSMS.</td></tr><tr><td>RemoteReset</td><td>The Charging Station rebooted due to a remote reset command.</td></tr><tr><td>ScheduledReset</td><td>The Charging Station rebooted due to a scheduled reset command.</td></tr><tr><td>Triggered</td><td>Requested by the CSMS via a TriggerMessage</td></tr><tr><td>Unknown</td><td>The boot reason is unknown.</td></tr><tr><td>Watchdog</td><td>The Charging Station rebooted due to an elapsed watchdog timer.</td></tr></table>
+
+# 3.6. CancelReservationStatusEnumType
+
+Enumeration
+
+Status in CancelReservationResponse.
+
+CancelReservationStatusEnumType is used by: cancelReservation:CancelReservationResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Reservation for the identifier has been canceled.</td></tr><tr><td>Rejected</td><td>Reservation could not be canceled, because there is no reservation active for the identifier.</td></tr></table>
+
+# 3.7. CertificateActionEnumType
+
+Enumeration
+
+CertificateActionEnumType is used by: get15118EVCertificate:Get15118EVCertificateRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Install</td><td>Install the provided certificate.</td></tr><tr><td>Update</td><td>Update the provided certificate.</td></tr></table>
+
+# 3.8. CertificateSignedStatusEnumType
+
+Enumeration
+
+CertificateSignedStatusEnumType is used by: certificateSigned:CertificateSignedResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Signed certificate is valid.</td></tr><tr><td>Rejected</td><td>Signed certificate is invalid.</td></tr></table>
+
+# 3.9. CertificateSigningUseEnumType
+
+Enumeration
+
+CertificateSigningUseEnumType is used by: signCertificate:SignCertificateRequest, certificateSigned:CertificateSignedRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ChargingStationCertificate</td><td>Client side certificate used by the Charging Station to connect the CSMS.</td></tr><tr><td>V2GCertificate</td><td>Use for certificate for 15118 connections. This means that the certificate should be derived from the V2G root.</td></tr></table>
+
+# 3.10. ChangeAvailabilityStatusTypeDef
+
+Enumeration
+
+Status returned in response to ChangeAvailabilityRequest.
+
+ChangeAvailabilityStatusEnumType is used by: changeAvailability:ChangeAvailabilityResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Rejected</td><td>Request has not been accepted and will not be executed.</td></tr><tr><td>Scheduled</td><td>Request has been accepted and will be executed when transaction(s) in progress have finished.</td></tr></table>
+
+# 3.11. ChargingLimitSourceEnumType
+
+Enumeration
+
+Enumeration for indicating from which source a charging limit originates.
+
+ChargingLimitSourceEnumType is used by: notifyChargingLimit:NotifyChargingLimitRequest.ChargingLimitType, clearedChargingLimit:ClearedChargingLimitRequest, getChargingProfiles:GetChargingProfilesRequest.ChargingProfileCriterionType, reportChargingProfiles:ReportChargingProfilesRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>EMS</td><td>Indicates that an Energy Management System has sent a charging limit.</td></tr><tr><td>Other</td><td>Indicates that an external source, not being an EMS or system operator, has sent a charging limit.</td></tr><tr><td>SO</td><td>Indicates that a System Operator (DSO or TSO) has sent a charging limit.</td></tr><tr><td>CSO</td><td>Indicates that the CSO has set this charging profile.</td></tr></table>
+
+# 3.12. ChargingProfileKindEnumType
+
+Enumeration
+
+Kind of charging profile.
+
+ChargingProfileKindEnumType is used by: Common:ChargingProfileType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Absolute</td><td>Schedule periods are relative to a fixed point in time defined in the schedule. This requires that startSchedule is set to a starting point in time.</td></tr><tr><td>Recurring</td><td>The schedule restarts periodically at the first schedule period. To be most useful, this requires that startSchedule is set to a starting point in time.</td></tr><tr><td>Relative</td><td>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.</td></tr></table>
+
+# 3.13. ChargingProfilePurposeEnumType
+
+Enumeration
+
+Purpose of the charging profile.
+
+ChargingProfilePurposeEnumType is used by: Common:ChargingProfileType, clearChargingProfile:ClearChargingProfileRequest.ClearChargingProfileType, getChargingProfiles:GetChargingProfilesRequest.ChargingProfileCriterionType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ChargingStationExte-ronalConstraints</td><td>Additional constraints that will be incorporated into a local power schedule. Only valid for a Charging Station. Therefore evse.Id MUST be 0 in the SetChargingProfileRequest message.</td></tr><tr><td>ChargingStationMaxProfile</td><td>Configuration for the maximum power or current available for an entire Charging Station.</td></tr><tr><td>TxDefaultProfile</td><td>Default profile that can be configured in the Charging Station. When a new transaction is started, this profile SHALL be used, unless it was a transaction that was started by a RequestStartTransactionRequest with a ChargingProfile that is accepted by the Charging Station.</td></tr><tr><td>TxProfile</td><td>Profile with constraints to be imposed by the Charging Station on the current transaction, or on a new transaction when this is started via a RequestStartTransactionRequest with a ChargingProfile. A profile with this purpose SHALL cease to be valid when the transaction terminates.</td></tr></table>
+
+# 3.14. ChargingProfileStatusEnumType
+
+Enumeration
+
+Status returned in response to SetChargingProfileRequest.
+
+ChargingProfileStatusEnumType is used by: setChargingProfile:SetChargingProfileResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Rejected</td><td>Request has not been accepted and will not be executed.</td></tr></table>
+
+# 3.15. ChargingRateUnitEnumType
+
+Enumeration
+
+Unit in which a charging schedule is defined.
+
+ChargingRateUnitEnumType is used by: Common:ChargingScheduleType, Common:CompositeScheduleType, getCompositeSchedule:GetCompositeScheduleRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>W</td><td>Watts (power). This is the TOTAL allowed charging power. If used for AC Charging, the phase current should be calculated via: Current per phase = Power / (Line Voltage * Number of Phases). The "Line Voltage" used in the calculation is not the measured voltage, but the set voltage for the area (hence, 230 of 110 volt). The "Number of Phases" is the numberPhases from the ChargingSchedulePeriod. It is usually more convenient to use this for DC charging. Note that if numberPhases in a ChargingSchedulePeriod is absent, 3 SHALL be assumed.</td></tr><tr><td>A</td><td>Amperes (current). The amount of Ampere per phase, not the sum of all phases. It is usually more convenient to use this for AC charging.</td></tr></table>
+
+# 3.16. ChargingStateEnumType
+
+Enumeration
+
+The state of the charging process.
+
+ChargingStateEnumType is used by: transactionEvent:TransactionRequest. TransactionType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Charging</td><td>The contactor of the Connector is closed and energy is flowing to between EVSE and EV.</td></tr><tr><td>EVConnected</td><td>There is a connection between EV and EVSE, in case the protocol used between EV and the Charging Station can detect a connection, the protocol needs to detect this for the state to become active. The connection can either be wired or wireless.</td></tr><tr><td>SuspendedEV</td><td>When the EV is connected to the EVSE and the EVSE is offering energy but the EV is not taking any energy.</td></tr><tr><td>SuspendedEVSE</td><td>When the EV is connected to the EVSE but the EVSE is not offering energy to the EV, e.g. due to a smart charging restriction, local supply power constraints, or when charging has stopped because of the authorization status in the response to a transactionRequest indicating that charging is not allowed etc.</td></tr><tr><td>Idle</td><td>There is no connection between EV and EVSE.</td></tr></table>
+
+# 3.17. ClearCacheStatusEnumType
+
+Enumeration
+
+Status returned in response to ClearCacheRequest.
+
+ClearCacheStatusEnumType is used by: clearCache:ClearCacheResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Command has been executed.</td></tr><tr><td>Rejected</td><td>Command has not been executed.</td></tr></table>
+
+# 3.18. ClearChargingProfileStatusEnumType
+
+Enumeration
+
+Status returned in response to ClearChargingProfileRequest.
+
+ClearChargingProfileStatusEnumType is used by: clearChargingProfile:ClearChargingProfileResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Unknown</td><td>No Charging Profile(s) were found matching the request.</td></tr></table>
+
+# 3.19.ClearMessageStatusEnumType
+
+Enumeration
+
+Result for a ClearDisplayMessageRequest as used in a ClearDisplayMessageResponse.
+
+ClearMessageStatusEnumType is used by: clearDisplayMessage:ClearDisplayMessageResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request successfully executed: message cleared.</td></tr><tr><td>Unknown</td><td>Given message (based on the id) not known.</td></tr></table>
+
+# 3.20. ClearMonitoringStatusEnumType
+
+Enumeration
+
+ClearMonitoringStatusEnumType is used by: Common:ClearMonitoringResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Monitor successfully cleared.</td></tr><tr><td>Rejected</td><td>Clearing of monitor rejected.</td></tr><tr><td>NotFound</td><td>Monitor Id is not found.</td></tr></table>
+
+# 3.21. ComponentCriterionEnumType
+
+Enumeration
+
+ComponentCriterionEnumType is used by: getReport:GetReportRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Active</td><td>Components that are active, i.e. having Active = 1</td></tr><tr><td>Available</td><td>Components that are available, i.e. having Available = 1</td></tr><tr><td>Enabled</td><td>Components that are enabled, i.e. having Enabled = 1</td></tr><tr><td>Problem</td><td>Components that reported a problem, i.e. having Problem = 1</td></tr></table>
+
+# 3.22. ConnectorEnumType
+
+Enumeration
+
+Allowed values of ConnectorCode.
+
+# NOTE
+
+This enumeration does not attempt to include every possible power connector type worldwide as an individual type, but to specifically define those that are known to be in use (or likely to be in use) in the Charging Stations using the OCPP protocol. In particular, many of the very large number of domestic electrical sockets designs in use in many countries are excluded, unless there is evidence that they are or are likely to be approved for use on Charging Stations in some jurisdictions (e.g. as secondary connectors for charging light EVs such as electric scooters). These light connector types can be represented with the enumeration value Other1PhMax16A. Similarly, any single phase connector not otherwise enumerated that is rated for 16A or over should be reported as Other1PhOver16A. All 3 phase connector types not explicitly enumerated should be represented as Other3Ph.
+
+ConnectorEnumType is used by: reserveNow:ReserveNowRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>cCCS1</td><td>Combined Charging System 1 (captive cabled) a.k.a. Combo 1</td></tr><tr><td>cCCS2</td><td>Combined Charging System 2 (captive cabled) a.k.a. Combo 2</td></tr><tr><td>cG105</td><td>JARI G105-1993 (captive cabled) a.k.a. CHAdeMO</td></tr><tr><td>cTesla</td><td>Tesla Connector (captive cabled)</td></tr><tr><td>cType1</td><td>IEC62196-2 Type 1 connector (captive cabled) a.k.a. J1772</td></tr><tr><td>cType2</td><td>IEC62196-2 Type 2 connector (captive cabled) a.k.a. Menkes connector</td></tr><tr><td>s309-1P-16A</td><td>16A 1 phase IEC60309 socket</td></tr><tr><td>s309-1P-32A</td><td>32A 1 phase IEC60309 socket</td></tr><tr><td>s309-3P-16A</td><td>16A 3 phase IEC60309 socket</td></tr><tr><td>s309-3P-32A</td><td>32A 3 phase IEC60309 socket</td></tr><tr><td>sBS1361</td><td>UK domestic socket a.k.a. 13Amp</td></tr><tr><td>sCEE-7-7</td><td>CEE 7/7 16A socket. May represent 7/4 & 7/5 a.k.a Schuko</td></tr><tr><td>sType2</td><td>IEC62196-2 Type 2 socket a.k.a. Mennekes connector</td></tr><tr><td>sType3</td><td>IEC62196-2 Type 2 socket a.k.a. Scame</td></tr><tr><td>Other1PhMax16A</td><td>Other single phase (domestic) sockets not mentioned above, rated at no more than 16A. CEE7/17, AS3112, NEMA 5-15, NEMA 5-20, JISC8303, TIS166, SI 32, CPCS-CCC, SEV1011, etc.</td></tr><tr><td>Other1PhOver16A</td><td>Other single phase sockets not mentioned above (over 16A)</td></tr><tr><td>Other3Ph</td><td>Other 3 phase sockets not mentioned above. NEMA14-30, NEMA14-50.</td></tr><tr><td>Pan</td><td>Pantograph connector</td></tr><tr><td>wInductive</td><td>Wireless inductively coupled connection (generic)</td></tr><tr><td>wResonant</td><td>Wireless resonant coupled connection (generic)</td></tr><tr><td>Undetermined</td><td>Yet to be determined (e.g. before plugged in)</td></tr><tr><td>Unknown</td><td>Unknown; not determinable</td></tr></table>
+
+# 3.23. Connector statusesEnumType
+
+Enumeration
+
+A status can be reported for the Connector of an EVSE of a Charging Station. States considered Operative are: Available, Reserved and Occupied. States considered Inoperative are: Unavailable, Faulted.
+
+ConnectorStatusEnumType is used by: statusNotification:StatusNotificationRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Available</td><td>When a Connector becomes available for a new User (Operative)</td></tr><tr><td>Occupied</td><td>When a Connector becomes occupied, so it is not available for a new EV driver. (Operative)</td></tr><tr><td>Reserved</td><td>When a Connector becomes reserved as a result of ReserveNow command (Operative)</td></tr><tr><td>Unavailable</td><td>When a Connector becomes unavailable as the result of a Change Availability command or an event upon which the Charging Station transitions to unavailable at its discretion. Upon receipt of ChangeAvailability message command, the status MAY change immediately or the change MAY be scheduled. When scheduled, StatusNotification SHALL be send when the availability change becomes effective (Inoperative)</td></tr><tr><td>Faulted</td><td>When a Connector (or the EVSE or the entire Charging Station it belongs to) has reported an error and is not available for energy delivery. (Inoperative).</td></tr></table>
+
+# 3.24. CostKindEnumType
+
+Enumeration
+
+CostKindEnumType is used by: Common:CostType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>CarbonDioxideEmission</td><td>Absolute value. Carbon Dioxide emissions, in grams per kWh.</td></tr><tr><td>RelativePricePercentage</td><td>Relative value. Price per kWh, as percentage relative to the maximum price stated in any of all tariffs indicated to the EV.</td></tr><tr><td>RenewableGenerationPercentage</td><td>Relative value. Percentage of renewable generation within total generation.</td></tr></table>
+
+# 3.25. CustomerInformationStatusEnumType
+
+Enumeration
+
+Status in CancelReservationResponse.
+
+CustomerInformationStatusEnumType is used by: customerInformation:CustomerInformationResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>The Charging Station accepted the message.</td></tr><tr><td>Rejected</td><td>When the Charging Station is in a state where it cannot process this request.</td></tr><tr><td>Invalid</td><td>In a request to the Charging Station no reference to a customer is included.</td></tr></table>
+
+# 3.26. DataEnumType
+
+Enumeration
+
+DataEnumType is used by: Common:VariableCharacteristicsType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>string</td><td>This variable is of the type string.</td></tr><tr><td>decimal</td><td>This variable is of the type decimal.</td></tr><tr><td>integer</td><td>This variable is of the type integer.</td></tr><tr><td>dateTime</td><td>DateTime following the [RFC3339] specification.</td></tr><tr><td>boolean</td><td>This variable is of the type boolean.</td></tr><tr><td>OptionList</td><td>Supported/allowed values for a single choice, enumerated, text variable.</td></tr><tr><td>SequenceList</td><td>Supported/allowed values for an ordered sequence variable.</td></tr><tr><td>MemberList</td><td>Supported/allowed values for a mathematical set variable.</td></tr></table>
+
+# 3.27. DataTransferStatusEnumType
+
+Enumeration
+
+Status in DataTransferResponse.
+
+DataTransferStatusEnumType is used by: dataTransfer:DataTransferResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Message has been accepted and the contained request is accepted.</td></tr><tr><td>Rejected</td><td>Message has been accepted but the contained request is rejected.</td></tr><tr><td>UnknownMessageld</td><td>Message could not be interpreted due to unknown msgageld string.</td></tr><tr><td>UnknownVendorId</td><td>Message could not be interpreted due to unknown vendorId string.</td></tr></table>
+
+# 3.28. DeleteCertificateStatusEnumType
+
+Enumeration
+
+DeleteCertificateStatusEnumType is used by: deleteCertificate:DeleteCertificateResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Normal successful completion (no errors).</td></tr><tr><td>Failed</td><td>The Charging Station either failed to remove the certificate or rejected the request. A Charging Station may reject the request to prevent the deletion of a certificate, if it is the last one from its certificate type.</td></tr><tr><td>NotFound</td><td>Requested resource not found.</td></tr></table>
+
+# 3.29. DisplayMessageStatusEnumType
+
+Enumeration
+
+Result for a SetDisplayMessageRequest as used in a SetDisplayMessageResponse.
+
+DisplayMessageStatusEnumType is used by: setDisplayMessage:SetDisplayMessageResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request to display message accepted.</td></tr><tr><td>NotSupportedMessageFormat</td><td>None of the formats in the given message are supported.</td></tr><tr><td>Rejected</td><td>Request cannot be handled.</td></tr><tr><td>NotSupportedPriority</td><td>The given MessagePriority not supported for displaying messages by Charging Station.</td></tr><tr><td>NotSupportedState</td><td>The given MessageState not supported for displaying messages by Charging Station.</td></tr><tr><td>UnknownTransaction</td><td>Given Transaction not known/ongoing.</td></tr></table>
+
+# 3.30. EnergyTransferModeEnumType
+
+Enumeration
+
+Enumeration of energy transfer modes.
+
+EnergyTransferModeEnumType is used by: Common:ChargingNeedsType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>DC</td><td>DC charging.</td></tr><tr><td>AC_single_phase</td><td>AC single phase charging according to IEC 62196.</td></tr><tr><td>AC_two_phase</td><td>AC two phase charging according to IEC 62196.</td></tr><tr><td>AC_three_phase</td><td>AC three phase charging according to IEC 62196.</td></tr></table>
+
+# 3.31.EventNotificationEnumType
+
+Enumeration
+
+Specifies the event notification type of the message.
+
+EventNotificationEnumType is used by: notifyEvent:NotifyRequest.EventDataType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>HardWiredNotification</td><td>The software implemented by the manufacturer triggered a hardwired notification.</td></tr><tr><td>HardWiredMonitor</td><td>Triggered by a monitor, which is hardwired by the manufacturer.</td></tr><tr><td>PreconfiguredMonitor</td><td>Triggered by a monitor, which is preconfigured by the manufacturer.</td></tr><tr><td>CustomMonitor</td><td>Triggered by a monitor, which is set with the setvariablemonitoringrequest message by the Charging Station Operator.</td></tr></table>
+
+# 3.32.EventTriggerEnumType
+
+Enumeration
+
+EventTriggerEnumType is used by: notifyEvent:NotifyRequest.EventDataType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Alerting</td><td>Monitored variable has passed an Lower or Upper Threshold. Also used as trigger type for a HardWiredNotification.</td></tr><tr><td>Delta</td><td>Delta Monitored Variable value has changed by more than specified amount</td></tr><tr><td>Periodic</td><td>Periodic Monitored Variable has been sampled for reporting at the specified interval</td></tr></table>
+
+# 3.33. FirmwareStatusEnumType
+
+Enumeration
+
+Status of a firmware download.
+
+A value with "Intermediate state" in the description, is an intermediate state, update process is not finished.
+
+A value with "Failure end state" in the description, is an end state, update process has stopped, update failed.
+
+A value with "Successful end state" in the description, is an end state, update process has stopped, update successful.
+
+FirmwareStatusEnumType is used by: firmwareStatusNotification:FirmwareStatusNotificationRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Downloaded</td><td>Intermediate state. New firmware has been downloaded by Charging Station.</td></tr><tr><td>DownloadFailed</td><td>Failure end state. Charging Station failed to download firmware.</td></tr><tr><td>Downloading</td><td>Intermediate state. Firmware is being downloaded.</td></tr><tr><td>DownloadScheduled</td><td>Intermediate state. Downloading of new firmware has been scheduled.</td></tr><tr><td>DownloadPaused</td><td>Intermediate state. Downloading has been paused.</td></tr><tr><td>Idle</td><td>Charging Station is not performing firmware update related tasks. Status Idle SHALL only be used as in a FirmwareStatusNotificationRequest that was triggered by TriggerMessageRequest.</td></tr><tr><td>InstallationFailed</td><td>Failure end state. Installation of new firmware has failed.</td></tr><tr><td>Installing</td><td>Intermediate state. Firmware is being installed.</td></tr><tr><td>Installed</td><td>Successful end state. New firmware has successfully been installed in Charging Station.</td></tr><tr><td>InstallRebooting</td><td>Intermediate state. Charging Station is about to reboot to activate new firmware. 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.</td></tr><tr><td>InstallScheduled</td><td>Intermediate state. Installation of the downloaded firmware is scheduled to take place on installDateTime given in UpdateFirmware request.</td></tr><tr><td>InstallVerificationFailed</td><td>Failure end state. Verification of the new firmware (e.g. using a checksum or some other means) has failed and installation will not proceed. (Final failure state)</td></tr><tr><td>InvalidSignature</td><td>Failure end state. The firmware signature is not valid.</td></tr><tr><td>SignatureVerified</td><td>Intermediate state. Provide signature successfully verified.</td></tr></table>
+
+# 3.34. GenericDeviceModel狀態EnumType
+
+Enumeration
+
+GenericDeviceModelStatusEnumType is used by: getBaseReport:GetBaseReportResponse, getMonitoringReport:GetMonitoringReportResponse, getReport:GetReportResponse, setMonitoringBase:SetMonitoringBaseResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Rejected</td><td>Request has not been accepted and will not be executed.</td></tr><tr><td>NotSupported</td><td>The content of the request message is not supported.</td></tr><tr><td>EmptyResultSet</td><td>If the combination of received criteria result in an empty result set.</td></tr></table>
+
+# 3.35.Generic statusesEnumType
+
+Enumeration
+
+Generic message response status
+
+GenericStatusEnumType is used by: getCompositeScheduleGetCompositeScheduleResponse, notifyEVChargingSchedule:NotifyEVChargingScheduleResponse, signCertificate:SignCertificateResponse, setMonitoringLevel:SetMonitoringLevelResponse, publishFirmware:PublishFirmwareResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Rejected</td><td>Request has not been accepted and will not be executed.</td></tr></table>
+
+# 3.36. GetCertificateldUseEnumType
+
+Enumeration
+
+GetCertificateldUseEnumType is used by: Common: CertificateHashDataChainType, getInstalledCertificates:GetInstalledCertificatesRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>V2GRootCertificate</td><td>Use for certificate of the V2G Root.</td></tr><tr><td>MORootCertificate</td><td>Use for certificate from an eMobility Service provider. To support PnC charging with contracts from service providers that not derived their certificates from the V2G root.</td></tr><tr><td>CSMSRootCertificate</td><td>Root certificate for verification of the CSMS certificate.</td></tr><tr><td>V2GCertificateChain</td><td>ISO 15118 V2G certificate chain (excluding the V2GRootCertificate).</td></tr><tr><td>ManufacturerRootCertificate</td><td>Root certificate for verification of the Manufacturer certificate.</td></tr></table>
+
+# 3.37. GetCertificateStatusEnumType
+
+Enumeration
+
+GetCertificateStatusEnumType is used by: getCertificateStatus:GetCertificateStatusResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Successfully retrieved the OCSP certificate status.</td></tr><tr><td>Failed</td><td>Failed to retrieve the OCSP certificate status.</td></tr></table>
+
+# 3.38. GetChargingProfileStatusEnumType
+
+Enumeration
+
+GetChargingProfileStatusEnumType is used by: getChargingProfiles:GetChargingProfilesResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Normal successful completion (no errors).</td></tr><tr><td>NoProfiles</td><td>No ChargingProfiles found that match the information in the GetChargingProfilesRequest.</td></tr></table>
+
+# 3.39. GetDisplayMessagesStatusEnumType
+
+Enumeration
+
+GetDisplayMessagesStatusEnumType is used by: getDisplayMessages:GetDisplayMessagesResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request accepted, there are Display Messages found that match all the requested criteria. The Charging Station will send NotifyDisplayMessagesRequest messages to report the requested Display Messages.</td></tr><tr><td>Unknown</td><td>No messages found that match the given criteria.</td></tr></table>
+
+# 3.40. GetInstalledCertificateStatusEnumType
+
+Enumeration
+
+GetInstalledCertificateStatusEnumType is used by: getInstalledCertificates:GetInstalledCertificatesResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Normal successful completion (no errors).</td></tr><tr><td>NotFound</td><td>Requested resource not found.</td></tr></table>
+
+# 3.41. GetVariableStatusTypeDef
+
+Enumeration
+
+GetVariableStatusEnumType is used by: getVariables:GetVariablesResponse.GetVariableResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Variable successfully set.</td></tr><tr><td>Rejected</td><td>Request is rejected.</td></tr><tr><td>UnknownComponent</td><td>Component is not known.</td></tr><tr><td>UnknownVariable</td><td>Variable is not known.</td></tr><tr><td>NotSupportedAttributeType</td><td>The AttributeType is not supported.</td></tr></table>
+
+# 3.42. HashAlgorithmEnumType
+
+Enumeration
+
+HashAlgorithmEnumType is used by: Common: CertificateHashDataType, Common: OCSPRequestDataType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>SHA256</td><td>SHA-256 hash algorithm.</td></tr><tr><td>SHA384</td><td>SHA-384 hash algorithm.</td></tr><tr><td>SHA512</td><td>SHA-512 hash algorithm.</td></tr></table>
+
+# 3.43. IdTokenEnumType
+
+Enumeration
+
+Allowable values of the IdTokenType field.
+
+IdTokenEnumType is used by: Common:IdTokenType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Central</td><td>A centrally, in the CSMS (or other server) generated id (for example used for a remotely started transaction that is activated by SMS). No format defined, might be a UUID.</td></tr><tr><td>eMAID</td><td>Electro-mobility account id as defined in ISO 15118</td></tr><tr><td>ISO14443</td><td>ISO 14443 UID of RFID card. It is represented as an array of 4 or 7 bytes in hexadecimal representation.</td></tr><tr><td>ISO15693</td><td>ISO 15693 UID of RFID card. It is represented as an array of 8 bytes in hexadecimal representation.</td></tr><tr><td>KeyCode</td><td>User use a private key-code to authorize a charging transaction. For example: Pin-code.</td></tr><tr><td>Local</td><td>A locally generated id (e.g. internal id created by the Charging Station). No format defined, might be a UUID</td></tr><tr><td>MacAddress</td><td>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").</td></tr><tr><td>NoAuthorization</td><td>Transaction is started and no authorization possible. Charging Station only has a start button or mechanical key etc. IdToken field SHALL be left empty.</td></tr></table>
+
+# 3.44. InstallCertificateStatusEnumType
+
+Enumeration
+
+InstallCertificateStatusEnumType is used by: installCertificate:InstallCertificateResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>The installation of the certificate succeeded.</td></tr><tr><td>Rejected</td><td>The certificate is invalid and/or incorrect OR the CSO tries to install more certificates than allowed.</td></tr><tr><td>Failed</td><td>The certificate is valid and correct, but there is another reason the installation did not succeed.</td></tr></table>
+
+# 3.45. InstallCertificateUseEnumType
+
+Enumeration
+
+InstallCertificateUseEnumType is used by: installCertificate:InstallCertificateRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>V2GRootCertificate</td><td>Use for certificate of the V2G Root, a V2G Charging Station Certificate MUST be derived from one of the installed V2GRootCertificate certificates.</td></tr><tr><td>MORootCertificate</td><td>Use for certificate from an eMobility Service provider. To support PnC charging with contracts from service providers that not derived their certificates from the V2G root.</td></tr><tr><td>CSMSRootCertificate</td><td>Root certificate, used by the CA to sign the CSMS and Charging Station certificate.</td></tr><tr><td>ManufacturerRootCertificate</td><td>Root certificate for verification of the Manufacturer certificate.</td></tr></table>
+
+# 3.46. Iso15118EVCertificateStatusEnumType
+
+Enumeration
+
+Iso15118EVCertificateStatusEnumType is used by: get15118EVCertificate:Get15118EVCertificateResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>exiResponse included. This is no indication whether the update was successful, just that the message was processed properly.</td></tr><tr><td>Failed</td><td>Processing of the message was not successful, no exiResponse included.</td></tr></table>
+
+# 3.47. LocationEnumType
+
+Enumeration
+
+Allowable values of the optional "location" field of a value element.
+
+LocationEnumType is used by: Common:SampledValueType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Body</td><td>Measurement inside body of Charging Station (e.g. Temperature).</td></tr><tr><td>Cable</td><td>Measurement taken from cable between EV and Charging Station.</td></tr><tr><td>EV</td><td>Measurement taken by EV.</td></tr><tr><td>Inlet</td><td>For the Charging Station (evseld = 0): measurement at network ("grid") inlet connection.
+For measurements with evseld > 0, these are measurements taken at the EVSE inlet (This can be useful for a DC charger).</td></tr><tr><td>Outlet</td><td>Measurement at a Connector. Default value.</td></tr></table>
+
+# 3.48. LogEnumType
+
+Enumeration
+
+LogEnumType is used by: getLogGetLogRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>DiagnosticsLog</td><td>This contains the field definition of a diagnostics log file</td></tr><tr><td>SecurityLog</td><td>Sent by the CSMS to the Charging Station to request that the Charging Station uploads the security log.</td></tr></table>
+
+# 3.49. logStatusEnumType
+
+Enumeration
+
+Generic message response status
+
+LogStatusEnumType is used by: getLogGetLogResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Accepted this log upload. This does not mean the log file is uploaded is successfully, the Charging Station will now start the log file upload.</td></tr><tr><td>Rejected</td><td>Log update request rejected.</td></tr><tr><td>AcceptedCanceled</td><td>Accepted this log upload, but in doing this has canceled an ongoing log file upload.</td></tr></table>
+
+# 3.50. MeasurandEnumType
+
+Enumeration
+
+Allowable values of the optional "measurand" field of a Value element, as used in MeterValuesRequest and TransactionEventRequest with eventTypes Started, Ended and Updated. Default value of "measurand" is always "Energy.Active.Import.Register".
+
+Note 1: Two measurands (Current.Offered and Power.Offered) are available that are strictly speaking no measured values. They indicate the maximum amount of current/power that is being offered to the EV and are intended for use in smart charging applications.
+
+Note 2: Import is energy flow from the Grid to the Charging Station, EV or other load. Export is energy flow from the EV to the Charging Station and/or from the Charging Station to the Grid. Except in the case of a meter replacement, all "Register" values relating to a single charging transaction, or a non-transactional consumer (e.g. Charging Station internal power supply, overall supply) MUST be monotonically increasing in time.
+
+Note 3: The actual quantity of energy corresponding to a reported ".Register" value is computed as the register value in question minus the register value recorded/reported at the start of the transaction or other relevant starting reference point in time. For improved auditability, ".Register" values SHOULD be reported exactly as they are directly read from a non-volatile register in the electrical metering hardware, and SHOULD NOT be re-based to zero at the start of transactions. This allows any "missing energy" between sequential transactions, due to hardware fault, meter replacement, mis-wiring, fraud, etc. to be identified, by allowing the CSMS to confirm that the starting register value of any transaction is identical to the finishing register value of the preceding transaction on the same connector.
+
+MeasurandEnumType is used by: Common:SampledValueType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Current.Export</td><td>Instantaneous current flow from EV</td></tr><tr><td>Current.Import</td><td>Instantaneous current flow to EV</td></tr><tr><td>Current.Offered</td><td>Maximum current offered to EV</td></tr><tr><td>Energy.Active.Expor
+t.Register</td><td>Numerical value read from the "active electrical energy" (Wh or kWh) register of the (most authoritative) electrical meter measuring energy exported (to the grid).</td></tr><tr><td>Energy.Active.Import
+t.Register</td><td>Numerical value read from the "active electrical energy" (Wh or kWh) register of the (most authoritative) electrical meter measuring energy imported (from the grid supply).</td></tr><tr><td>Energy.Reactive.Exp ort.Register</td><td>Numerical value read from the "reactive electrical energy" (varh or kvarh) register of the (most authoritative) electrical meter measuring energy exported (to the grid).</td></tr><tr><td>Energy.Reactive.Imp ort.Register</td><td>Numerical value read from the "reactive electrical energy" (varh or kvarh) register of the (most authoritative) electrical meter measuring energy imported (from the grid supply).</td></tr><tr><td>Energy.Active.Expor tInterval</td><td>Absolute amount of "active electrical energy" (Wh or kWh) exported (to the grid) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for ClockAlignedDataInterval and TxnMeterValueSampleInterval.</td></tr><tr><td>Energy.Active.Import tInterval</td><td>Absolute amount of "active electrical energy" (Wh or kWh) imported (from the grid supply) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for ClockAlignedDataInterval and TxnMeterValueSampleInterval.</td></tr><tr><td>Energy.Active.Net</td><td>Numerical value read from the "net active electrical energy" (Wh or kWh) register.</td></tr><tr><td>Energy.Reactive.Exp ort.Interval</td><td>Absolute amount of "reactive electrical energy" (varh or kvarh) exported (to the grid) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for ClockAlignedDataInterval and TxnMeterValueSampleInterval.</td></tr><tr><td>Energy.Reactive.Imp ort.Interval</td><td>Absolute amount of "reactive electrical energy" (varh or kvarh) imported (from the grid supply) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for ClockAlignedDataInterval and TxnMeterValueSampleInterval.</td></tr><tr><td>Energy.Reactive.Net</td><td>Numerical value read from the "net reactive electrical energy" (varh or kvarh) register.</td></tr><tr><td>Energy.Apparent.Net</td><td>Numerical value read from the "apparent electrical energy" (VAh or kVAh) register.</td></tr><tr><td>Energy.Apparent.Import port</td><td>Numerical value read from the "apparent electrical import energy" (VAh or kVAh) register.</td></tr><tr><td>Energy.Apparent.Import port</td><td>Numerical value read from the "apparent electrical export energy" (VAh or kVAh) register.</td></tr><tr><td>Frequency</td><td>Instantaneous reading of powerline frequency</td></tr><tr><td>Power.Active.Import</td><td>Instantaneous active power exported by EV. (W or kW)</td></tr><tr><td>Power.Active.Import</td><td>Instantaneous active power imported by EV. (W or kW)</td></tr><tr><td>Power.Factor</td><td>Instantaneous power factor of total energy flow</td></tr><tr><td>Power.Offered</td><td>Maximum power offered to EV</td></tr><tr><td>Power.Reactive.Exp ort</td><td>Instantaneous reactive power exported by EV. (var or kvar)</td></tr><tr><td>Power.Reactive.Imp ort</td><td>Instantaneous reactive power imported by EV. (var or kvar)</td></tr><tr><td>SoC</td><td>State of charge of charging vehicle in percentage</td></tr><tr><td>Voltage</td><td>Instantaneous DC or AC RMS supply voltage.For location = Inlet and evseld = 0: voltage at charging station grid connection.For location = Outlet and evseld > 0: voltage at EVSE outlet towards the EV.</td></tr></table>
+
+# 3.51. MessageFormatEnumType
+
+Enumeration
+
+Format of a message to be displayed on the display of the Charging Station.
+
+MessageFormatEnumType is used by: Common:MessageContentType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ASCII</td><td>Message content is ASCII formatted, only printable ASCII allowed.</td></tr><tr><td>HTML</td><td>Message content is HTML formatted.</td></tr><tr><td>URI</td><td>Message content is URI that Charging Station should download and use to display. for example a HTML page to be shown in a web-browser.</td></tr><tr><td>UTF8</td><td>Message content is UTF-8 formatted.</td></tr></table>
+
+# 3.52. MessagePriorityEnumType
+
+Enumeration
+
+Priority with which a message should be displayed on a Charging Station.
+
+MessagePriorityEnumType is used by: Common:MessageInfoType, getDisplayMessages:GetDisplayMessagesRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>AlwaysFront</td><td>Show this message always in front. Highest priority, don’t cycle with other messages. When a newer message with this MessagePriority is received, this message is replaced. No Charging Station own message may override this message.</td></tr><tr><td>InFront</td><td>Show this message in front of the normal cycle of messages. When more messages with this priority are to be shown, they SHALL be cycled.</td></tr><tr><td>NormalCycle</td><td>Show this message in the cycle of messages.</td></tr></table>
+
+# 3.53. MessageStateEnumType
+
+Enumeration
+
+State of the Charging Station during which a message SHALL be displayed.
+
+MessageStateEnumType is used by: Common:MessageInfoType, getDisplayMessages:GetDisplayMessagesRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Charging</td><td>Message only to be shown while the Charging Station is charging.</td></tr><tr><td>Faulted</td><td>Message only to be shown while the Charging Station is in faulted state.</td></tr><tr><td>Idle</td><td>Message only to be shown while the Charging Station is idle (not charging).</td></tr><tr><td>Unavailable</td><td>Message only to be shown while the Charging Station is in unavailable state.</td></tr></table>
+
+# 3.54. MessageTriggerEnumType
+
+Enumeration
+
+Type of request to be triggered by trigger messages.
+
+MessageTriggerEnumType is used by: triggerMessage:TriggerMessageRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>BootNotification</td><td>To trigger BootNotification.</td></tr><tr><td>LogStatusNotification</td><td>To trigger LogStatusNotification.</td></tr><tr><td>FirmwareStatusNotification</td><td>To trigger FirmwareStatusNotification.</td></tr><tr><td>Heartbeat</td><td>To trigger Heartbeat.</td></tr><tr><td>MeterValues</td><td>To trigger MeterValues.</td></tr><tr><td>SignChargingStation Certificate</td><td>To trigger a SignCertificate with certificateType: ChargingStationCertificate.</td></tr><tr><td>SignV2GCertificate</td><td>To trigger a SignCertificate with certificateType: V2GCertificate</td></tr><tr><td>StatusNotification</td><td>To trigger StatusNotification.</td></tr><tr><td>TransactionEvent</td><td>To trigger TransactionEvent.</td></tr><tr><td>SignCombinedCertificate</td><td>To trigger a SignCertificate with certificateType: ChargingStationCertificate AND V2GCertificate</td></tr><tr><td>PublishFirmwareStatusNotification</td><td>To trigger PublishFirmwareStatusNotification.</td></tr></table>
+
+# 3.55. MonitorEnumType
+
+Enumeration
+
+MonitorEnumType is used by: Common:VariableMonitoringType, setVariableMonitoring:SetVariableMonitoringRequest.SetMonitoringDataType, setVariableMonitoring:SetVariableMonitoringResponse.SetMonitoringResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>UpperThreshold</td><td>Triggers an event notice when the actual value of the Variable rises above monitorValue</td></tr><tr><td>LowerThreshold</td><td>Triggers an event notice when the actual value of the Variable drops below monitorValue.</td></tr><tr><td>Delta</td><td>Triggers an event notice when the actual value has changed more than plus or minus monitorValue since the time that this monitor was set or since the last time this event notice was sent, whichever was last. For variables that are not numeric, like boolean, string or enumerations, a monitor of type Delta will trigger an event notice whenever the variable changes, regardless of the value of monitorValue.</td></tr><tr><td>Periodic</td><td>Triggers an event notice every monitorValue seconds interval, starting from the time that this monitor was set.</td></tr><tr><td>PeriodicClockAligne-d</td><td>Triggers an event notice every monitorValue seconds interval, starting from the nearest clock-aligned interval after this monitor was set. For example, a monitorValue of 900 will trigger event notices at 0, 15, 30 and 45 minutes after the hour, every hour.</td></tr></table>
+
+# 3.56. MonitoringBaseEnumType
+
+Enumeration
+
+MonitoringBaseEnumType is used by: setMonitoringBase:SetMonitoringBaseRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>All</td><td>Activate all pre-configured monitors.</td></tr><tr><td>FactoryDefault</td><td>Activate the default monitoring settings as recommended by the manufacturer. This is a subset of all pre-configured monitors.</td></tr><tr><td>HardWiredOnly</td><td>Clears all custom monitors and disables all pre-configured monitors.</td></tr></table>
+
+# 3.57. MonitoringCriterionEnumType
+
+Enumeration
+
+MonitoringCriterionEnumType is used by: getMonitoringReport:GetMonitoringReportRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ThresholdMonitorin g</td><td>Report variables and components with a monitor of type UpperThreshold or LowerThreshold.</td></tr><tr><td>DeltaMonitoring</td><td>Report variables and components with a monitor of type Delta.</td></tr><tr><td>PeriodicMonitoring</td><td>Report variables and components with a monitor of type Periodic or PeriodicClockAligned.</td></tr></table>
+
+# 3.58. MutabilityEnumType
+
+Enumeration
+
+MutabilityEnumType is used by: Common:VariableAttributeType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ReadOnly</td><td>This variable is read-only.</td></tr><tr><td>WriteOnly</td><td>This variable is write-only.</td></tr><tr><td>ReadWrite</td><td>This variable is read-write.</td></tr></table>
+
+# 3.59. NotifyEVChargingNeedsStatusEnumType
+
+Enumeration
+
+NotifyEVChargingNeedsStatusEnumType is used by: notifyEVChargingNeeds:NotifyEVChargingNeedsResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>A schedule will be provided momentarily.</td></tr><tr><td>Rejected</td><td>Service not available.</td></tr><tr><td>Processing</td><td>The CSMS is gathering information to provide a schedule.</td></tr></table>
+
+# 3.60. OCPPInterfaceEnumType
+
+Enumeration
+
+Enumeration of network interfaces.
+
+OCPPInterfaceEnumType is used by: setNetworkProfile:SetNetworkProfileRequest.NetworkConnectionProfileType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Wired0</td><td>Use wired connection 0</td></tr><tr><td>Wired1</td><td>Use wired connection 1</td></tr><tr><td>Wired2</td><td>Use wired connection 2</td></tr><tr><td>Wired3</td><td>Use wired connection 3</td></tr><tr><td>Wireless0</td><td>Use wireless connection 0</td></tr><tr><td>Wireless1</td><td>Use wireless connection 1</td></tr><tr><td>Wireless2</td><td>Use wireless connection 2</td></tr><tr><td>Wireless3</td><td>Use wireless connection 3</td></tr></table>
+
+# 3.61. OCPPTransportEnumType
+
+Enumeration
+
+Enumeration of OCPP transport mechanisms. SOAP is currently not a valid value for OCPP 2.0.
+
+OCPPTransportEnumType is used by: setNetworkProfile:SetNetworkProfileRequest.NetworkConnectionProfileType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>JSON</td><td>Use JSON over WebSockets for transport of OCPP PDU's</td></tr><tr><td>SOAP</td><td>Use SOAP for transport of OCPP PDU's</td></tr></table>
+
+# 3.62. OCPPVersionEnumType
+
+Enumeration
+
+Enumeration of OCPP versions.
+
+OCPPVersionEnumType is used by: setNetworkProfile:SetNetworkProfileRequest.NetworkConnectionProfileType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>OCPP12</td><td>OCPP version 1.2</td></tr><tr><td>OCPP15</td><td>OCPP version 1.5</td></tr><tr><td>OCPP16</td><td>OCPP version 1.6</td></tr><tr><td>OCPP20</td><td>OCPP version 2.0
+The OCPP 2.0 release of OCPP has been deprecated, so this value OCPP20 must now be used for OCPP 2.0.1 implementations in the NetworkConnectionProfile. Note that OCPP 2.0.1 does have its own WebSocket subprotocol name: ocpp2.0.1.</td></tr></table>
+
+# 3.63. OperationalStatusEnumType
+
+Enumeration
+
+Requested availability change.
+
+OperationalStatusEnumType is used by: changeAvailability:ChangeAvailabilityRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Inoperative</td><td>Charging Station is not available for charging.</td></tr><tr><td>Operative</td><td>Charging Station is available for charging.</td></tr></table>
+
+# 3.64. PhaseEnumType
+
+Enumeration
+
+Phase specifies how a measured value is to be interpreted. Please note that not all values of Phase are applicable to all Measurands.
+
+PhaseEnumType is used by: Common:SampledValueType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>L1</td><td>Measured on L1</td></tr><tr><td>L2</td><td>Measured on L2</td></tr><tr><td>L3</td><td>Measured on L3</td></tr><tr><td>N</td><td>Measured on Neutral</td></tr><tr><td>L1-N</td><td>Measured on L1 with respect to Neutral conductor</td></tr><tr><td>L2-N</td><td>Measured on L2 with respect to Neutral conductor</td></tr><tr><td>L3-N</td><td>Measured on L3 with respect to Neutral conductor</td></tr><tr><td>L1-L2</td><td>Measured between L1 and L2</td></tr><tr><td>L2-L3</td><td>Measured between L2 and L3</td></tr><tr><td>L3-L1</td><td>Measured between L3 and L1</td></tr></table>
+
+# 3.65. PublishFirmwareStatusEnumType
+
+Enumeration
+
+Status for when publishing a Firmware.
+
+PublishFirmwareStatusEnumType is used by: publishFirmwareStatusNotification:PublishFirmwareStatusNotificationRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Idle</td><td></td></tr><tr><td>DownloadScheduled</td><td>Intermediate state. Downloading of new firmware has been scheduled.</td></tr><tr><td>Downloading</td><td>Intermediate state. Firmware is being downloaded.</td></tr><tr><td>Downloaded</td><td>Intermediate state. New firmware has been downloaded by Charging Station.</td></tr><tr><td>Published</td><td>The firmware has been successfully published.</td></tr><tr><td>DownloadFailed</td><td>Failure end state. Charging Station failed to download firmware.</td></tr><tr><td>DownloadPaused</td><td>Intermediate state. Downloading has been paused.</td></tr><tr><td>InvalidChecksum</td><td>Failure end state. The firmware checksum is not matching.</td></tr><tr><td>ChecksumVerified</td><td>Intermediate state. The Firmware checksum is successfully verified.</td></tr><tr><td>PublishFailed</td><td>Publishing the new firmware has failed.</td></tr></table>
+
+# 3.66. ReadingContextEnumType
+
+Enumeration
+
+Values of the context field.
+
+ReadingContextEnumType is used by: Common:SampledValueType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Interruption.Begin</td><td>Value taken at start of interruption.</td></tr><tr><td>Interruption.End</td><td>Value taken when resuming after interruption.</td></tr><tr><td>Other</td><td>Value for any other situations.</td></tr><tr><td>Sample.Clock</td><td>Value taken at clock aligned interval.</td></tr><tr><td>Sample.Periodic</td><td>Value taken as periodic sample relative to start time of transaction.</td></tr><tr><td>Transaction.Begin</td><td>Value taken at start of transaction.</td></tr><tr><td>Transaction.End</td><td>Value taken at end of transaction.</td></tr><tr><td>Trigger</td><td>Value taken in response to TriggerMessageRequest.</td></tr></table>
+
+# 3.67. ReasonEnumType
+
+Enumeration
+
+Reason for stopping a transaction.
+
+ReasonEnumType is used by: transactionEvent:TransactionRequest. TransactionType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>DeAuthorized</td><td>The transaction was stopped because of the authorization status in the response to a transactionEventRequest.</td></tr><tr><td>EmergencyStop</td><td>Emergency stop button was used.</td></tr><tr><td>EnergyLimitReached</td><td>EV charging session reached a locally enforced maximum energy transfer limit</td></tr><tr><td>EVDisconnected</td><td>Disconnecting of cable, vehicle moved away from inductive charge unit.</td></tr><tr><td>GroundFault</td><td>A GroundFault has occurred</td></tr><tr><td>ImmediateReset</td><td>A Reset(Immediate) command was received.</td></tr><tr><td>Local</td><td>Stopped locally on request of the EV Driver at the Charging Station. This is a regular termination of a transaction. Examples: presenting an IdToken tag, pressing a button to stop.</td></tr><tr><td>LocalOutOfCredit</td><td>A local credit limit enforced through the Charging Station has been exceeded.</td></tr><tr><td>MasterPass</td><td>The transaction was stopped using a token with a MasterPassGroupId.</td></tr><tr><td>Other</td><td>Any other reason.</td></tr><tr><td>OvercurrentFault</td><td>A larger than intended electric current has occurred</td></tr><tr><td>PowerLoss</td><td>Complete loss of power.</td></tr><tr><td>PowerQuality</td><td>Quality of power too low, e.g. voltage too low/high, phase imbalance, etc.</td></tr><tr><td>Reboot</td><td>A locally initiated reset/reboot occurred. (for instance watchdog kicked in)</td></tr><tr><td>Remote</td><td>Stopped remotely on request of the CSMS. This is a regular termination of a transaction. Examples: termination using a smartphone app, exceeding a (non local) prepaid credit.</td></tr><tr><td>SOCLimitReached</td><td>Electric vehicle has reported reaching a locally enforced maximum battery State of Charge (SOC)</td></tr><tr><td>StoppedByEV</td><td>The transaction was stopped by the EV</td></tr><tr><td>TimeLimitReached</td><td>EV charging session reached a locally enforced time limit</td></tr><tr><td>Timeout</td><td>EV not connected within timeout</td></tr></table>
+
+# 3.68. RecurrencyKindEnumType
+
+Enumeration
+
+ConcurrencyKindEnumType is used by: Common:ChargingProfileType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Daily</td><td>The schedule restarts every 24 hours, at the same time as in the startSchedule.</td></tr><tr><td>Weekly</td><td>The schedule restarts every 7 days, at the same time and day-of-the-week as in the startSchedule.</td></tr></table>
+
+# 3.69. Registration statusesylumType
+
+Enumeration
+
+Result of registration in response to BootNotificationRequest.
+
+RegistrationStatusEnumType is used by: bootNotification:BootNotificationResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Charging Station is accepted by the CSMS.</td></tr><tr><td>Pending</td><td>CSMS is not yet ready to accept the Charging Station. CSMS may send messages to retrieve information or prepare the Charging Station.</td></tr><tr><td>Rejected</td><td>Charging Station is not accepted by CSMS. This may happen when the Charging Station id is not known by CSMS.</td></tr></table>
+
+# 3.70.ReportBaseEnumType
+
+Enumeration
+
+ReportBaseEnumType is used by: getBaseReport:GetBaseRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ConfigurationInventory</td><td>Required. A (configuration) report that lists all Components/Variables that can be set by the operator.</td></tr><tr><td>FullInventory</td><td>Required. A (full) report that lists everything except monitoring settings.</td></tr><tr><td>SummaryInventory</td><td>Optional. A (summary) report that lists Components/Variables relating to the Charging Station's current charging availability, and to any existing problem conditions.For the Charging Station Component:- AvailabilityState.For each EVSE Component:- AvailabilityState.For each Connector Component:- AvailabilityState (if known and different from EVSE).For all Components in an abnormal State:- Active (Problem, Tripped, Overload, Failback) variables.- Any other diagnostically relevant Variables of the Components.- Include TechCode and TechInfo where available.All monitored Component_variables in Critical or Alert state shall also be included.- Charging Stations that do not have Monitoring implemented are NOT REQUIRED to include Connector Availability, monitoring alerts, and MAY limit problem reporting detail to just the active Problem boolean Variable.</td></tr></table>
+
+# 3.71. RequestStartStopStatusEnumType
+
+Enumeration
+
+The result of a RequestStartTransactionRequest or RequestStopTransactionRequest.
+
+RequestStartStopStatusEnumType is used by: requestStartTransaction:RequestStartTransactionResponse, requestStopTransaction:RequestStopTransactionResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Command will be executed.</td></tr><tr><td>Rejected</td><td>Command will not be executed.</td></tr></table>
+
+# 3.72. ReservationUpdateStatusEnumType
+
+Enumeration
+
+ReservationUpdateStatusEnumType is used by: reservationStatusUpdate:ReservationStatusUpdateRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Expired</td><td>The reservation is expired.</td></tr><tr><td>Removed</td><td>The reservation is removed.</td></tr></table>
+
+# 3.73. ReserveNowStatusEnumType
+
+Enumeration
+
+Status in ReserveNowResponse.
+
+ReserveNowStatusEnumType is used by: reserveNow:ReserveNowResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Reservation has been made.</td></tr><tr><td>Faulted</td><td>Reservation has not been made, because evse, connectors or specified connector are in a faulted state.</td></tr><tr><td>Occupied</td><td>Reservation has not been made. The evse or the specified connector is occupied.</td></tr><tr><td>Rejected</td><td>Reservation has not been made. Charging Station is not configured to accept reservations.</td></tr><tr><td>Unavailable</td><td>Reservation has not been made, because evse, connectors or specified connector are in an unavailable state.</td></tr></table>
+
+# 3.74. ResetEnumType
+
+Enumeration
+
+Type of reset requested.
+
+ResetEnumType is used by: reset:ResetRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Immediate</td><td>Immediate reset of the Charging Station.</td></tr><tr><td>OnIdle</td><td>Delay reset until no more transactions are active.</td></tr></table>
+
+# 3.75. ResetStatusEnumType
+
+Enumeration
+
+Result of ResetRequest.
+
+ResetStatusEnumType is used by: reset:ResetResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Command will be executed.</td></tr><tr><td>Rejected</td><td>Command will not be executed.</td></tr><tr><td>Scheduled</td><td>Reset command is scheduled, Charging Station is busy with a process that cannot be interrupted at the moment. Reset will be executed when process is finished.</td></tr></table>
+
+# 3.76.SendLocalListStatusEnumType
+
+Enumeration
+
+Type of update for SendLocalListRequest.
+
+SendLocalListStatusEnumType is used by: sendLocalList:SendLocalListResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Local Authorization List successfully updated.</td></tr><tr><td>Failed</td><td>Failed to update the Local Authorization List.</td></tr><tr><td>VersionMismatch</td><td>Version number in the request for a differential update is less or equal then version number of current list.</td></tr></table>
+
+# 3.77. SetMonitoringStatusEnumType
+
+Enumeration
+
+SetMonitoringStatusEnumType is used by: setVariableMonitoring:SetVariableMonitoringResponse.SetMonitoringResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Monitor successfully set.</td></tr><tr><td>UnknownComponent</td><td>Component is not known.</td></tr><tr><td>UnknownVariable</td><td>Variable is not known.</td></tr><tr><td>UnsupportedMonitorType</td><td>Requested monitor type is not supported.</td></tr><tr><td>Rejected</td><td>Request is rejected.</td></tr><tr><td>Duplicate</td><td>A monitor already exists for the given type/severity combination.</td></tr></table>
+
+# 3.78. SetNetworkProfileStatusEnumType
+
+Enumeration
+
+Possible values of SetNetworkProfileStatus as used in SetNetworkProfileResponse.
+
+SetNetworkProfileStatusEnumType is used by: setNetworkProfile:SetNetworkProfileResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Setting new data successful</td></tr><tr><td>Rejected</td><td>Setting new data rejected</td></tr><tr><td>Failed</td><td>Setting new data failed</td></tr></table>
+
+# 3.79. SetVariableStatusTypeDef
+
+Enumeration
+
+SetVariableStatusEnumType is used by: setVariables:SetVariablesResponse.SetVariableResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Variable successfully set.</td></tr><tr><td>Rejected</td><td>Request is rejected.</td></tr><tr><td>UnknownComponent</td><td>Component is not known.</td></tr><tr><td>UnknownVariable</td><td>Variable is not known.</td></tr><tr><td>NotSupportedAttributeType</td><td>The AttributeType is not supported.</td></tr><tr><td>RebootRequired</td><td>A reboot is required.</td></tr></table>
+
+# 3.80. TransactionEventEnumType
+
+Enumeration
+
+TransactionEventEnumType is used by: transactionEvent:TransactionRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Ended</td><td>Last event of a transaction</td></tr><tr><td>Started</td><td>First event of a transaction.</td></tr><tr><td>Updated</td><td>Transaction event in between 'Started' and 'Ended'.</td></tr></table>
+
+# 3.81. TriggerMessageStatusEnumType
+
+Enumeration
+
+Status in TriggerMessageResponse.
+
+TriggerMessageStatusEnumType is used by: triggerMessage:TriggerMessageResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Requested message will be sent.</td></tr><tr><td>Rejected</td><td>Requested message will not be sent.</td></tr><tr><td>NotImplemented</td><td>Requested message cannot be sent because it is either not implemented or unknown.</td></tr></table>
+
+# 3.82. TriggerReasonEnumType
+
+Enumeration
+
+Reason that triggered a transactionEventRequest.
+
+TriggerReasonEnumType is used by: transactionEvent:TransactionRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Authorized</td><td>Charging is authorized, by any means. Might be an RFID, or other authorization means.</td></tr><tr><td>CablePluggedIn</td><td>Cable is plugged in and EVDetected.</td></tr><tr><td>ChargingRateChanged</td><td>Rate of charging changed by more than LimitChangeSignificance.</td></tr><tr><td>ChargingStateChanged</td><td>Charging State changed.</td></tr><tr><td>Deauthorized</td><td>The transaction was stopped because of the authorization status in the response to a transactionEventRequest.</td></tr><tr><td>EnergyLimitReached</td><td>Maximum energy of charging reached. For example: in a pre-paid charging solution</td></tr><tr><td>EVCommunicationLost</td><td>Communication with EV lost, for example: cable disconnected.</td></tr><tr><td>EVConnectTimeout</td><td>EV not connected before the connection is timed out.</td></tr><tr><td>MeterValueClock</td><td>Needed to send a clock aligned meter value</td></tr><tr><td>MeterValuePeriodic</td><td>Needed to send a periodic meter value</td></tr><tr><td>TimeLimitReached</td><td>Maximum time of charging reached. For example: in a pre-paid charging solution</td></tr><tr><td>Trigger</td><td>Requested by the CSMS via a TriggerMessageRequest.</td></tr><tr><td>UnlockCommand</td><td>CSMS sent an Unlock Connector command.</td></tr><tr><td>StopAuthorized</td><td>An EV Driver has been authorized to stop charging. For example: By swiping an RFID card.</td></tr><tr><td>EVDeparted</td><td>EV departed. For example: When a departing EV triggers a parking bay detector.</td></tr><tr><td>EVDetected</td><td>EV detected. For example: When an arriving EV triggers a parking bay detector.</td></tr><tr><td>RemoteStop</td><td>A RequestStopTransactionRequest has been sent.</td></tr><tr><td>RemoteStart</td><td>A RequestStartTransactionRequest has been sent.</td></tr><tr><td>AbnormalCondition</td><td>An Abnormal Error or Fault Condition has occurred.</td></tr><tr><td>SignedDataReceived</td><td>Signed data is received from the energy meter.</td></tr><tr><td>ResetCommand</td><td>CSMS sent a Reset Charging Station command.</td></tr></table>
+
+# 3.83. UnlockStatusEnumType
+
+Enumeration
+
+Status in response to UnlockConnectorRequest.
+
+UnlockStatusEnumType is used by: unlockConnector:UnlockConnectorResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Unlocked</td><td>Connector has successfully been unlocked.</td></tr><tr><td>UnlockFailed</td><td>Failed to unlock the connector.</td></tr><tr><td>OngoingAuthorizedTransaction</td><td>The connector is not unlocked, because there is still an authorized transaction ongoing.</td></tr><tr><td>UnknownConnector</td><td>The specified connector is not known by the Charging Station.</td></tr></table>
+
+# 3.84. UnpublishFirmwareStatusEnumType
+
+Enumeration
+
+Status for when publishing a Firmware.
+
+UnpublishFirmwareStatusEnumType is used by: unpublishedFirmware:UnpublishFirmwareResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>DownloadOngoing</td><td>Intermediate state. Firmware is being downloaded.</td></tr><tr><td>NoFirmware</td><td>There is no published file.</td></tr><tr><td>Unpublished</td><td>Successful end state. Firmware file no longer being published.</td></tr></table>
+
+# 3.85. UpdateEnumType
+
+Enumeration
+
+UpdateEnumType is used by: sendLocalList:SendLocalListRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Differential</td><td>Indicates that the current Local Authorization List must be updated with the values in this message.</td></tr><tr><td>Full</td><td>Indicates that the current Local Authorization List must be replaced by the values in this message.</td></tr></table>
+
+# 3.86. UpdateFirmwareStatusEnumType
+
+Enumeration
+
+Generic message response status
+
+Update FirmwareStatusEnumType is used by: updateFirmware:UpdateFirmwareResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Accepted this firmware update request. This does not mean the firmware update is successful, the Charging Station will now start the firmware update process.</td></tr><tr><td>Rejected</td><td>Firmware update request rejected.</td></tr><tr><td>AcceptedCanceled</td><td>Accepted this firmware update request, but in doing this has canceled an ongoing firmware update.</td></tr><tr><td>InvalidCertificate</td><td>The certificate is invalid.</td></tr><tr><td>RevokedCertificate</td><td>Failure end state. The Firmware Signing certificate has been revoked.</td></tr></table>
+
+# 3.87. UploadLogStatusEnumType
+
+Enumeration
+
+UploadLogStatusEnumType is used by: logStatusNotification:LogStatusNotificationRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>BadMessage</td><td>A badly formatted packet or other protocol incompatibility was detected.</td></tr><tr><td>Idle</td><td>The Charging Station is not uploading a log file. Idle SHALL only be used when the message was triggered by a TriggerMessageRequest.</td></tr><tr><td>NotSupportedOperation</td><td>The server does not support the operation</td></tr><tr><td>PermissionDenied</td><td>Insufficient permissions to perform the operation.</td></tr><tr><td>Uploaded</td><td>File has been uploaded successfully.</td></tr><tr><td>UploadFailure</td><td>Failed to upload the requested file.</td></tr><tr><td>Uploading</td><td>File is being uploaded.</td></tr><tr><td>AcceptedCanceled</td><td>On-going log upload is canceled and new request to upload log has been accepted.</td></tr></table>
+
+# 3.88. VPENUMType
+
+Enumeration
+
+Enumeration of VPN Types.
+
+VPNEnumType is used by: setNetworkProfile:SetNetworkProfileRequest. VPNType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>IKEv2</td><td>IKEv2 VPN</td></tr><tr><td>IPSec</td><td>IPSec VPN</td></tr><tr><td>L2TP</td><td>L2TP VPN</td></tr><tr><td>PPTP</td><td>PPTP VPN</td></tr></table>
+
+# Referenced Components and Variables
+
+# 1. Controller Components
+
+This section gives an overview of the 'Controller' components, which are introduced in OCPP 2.0. A controller component can be recognized by the 'Ctrl' suffix and is responsible for the configuration of a certain functionality. Most of the 'Referenced' components that are described in this document, are 'Controller' components.
+
+The table below contains a summary of all Controller components, for more details, please refer to Part 2 - Appendices.
+
+<table><tr><td>Controller Component</td><td>Description</td></tr><tr><td>AlignedDataCtrlr</td><td>Responsible for configuration relating to the reporting of clock-aligned meter data.</td></tr><tr><td>AuthCacheCtrlr</td><td>Responsible for configuration relating to the use of a local cache for authorization for Charging Station use.</td></tr><tr><td>AuthCtrlr</td><td>Responsible for configuration relating to the use of authorization for Charging Station use.</td></tr><tr><td>CHAdeMOCtrlr</td><td>Responsible for configuration relating to the CHAdeMO controller</td></tr><tr><td>ClockCtrlr</td><td>Provides a means to configure management of time tracking by Charging Station.</td></tr><tr><td>CustomizationCtrlr</td><td>Responsible for configuration relating to custom vendor-specific implementations, using the DataTransfer message and CustomData extensions.</td></tr><tr><td>DeviceDataCtrlr</td><td>Responsible for configuration relating to the exchange and storage of Charging Station device model data.</td></tr><tr><td>DisplayMessageCtrlr</td><td>Responsible for configuration relating to the display of messages to Charging Station users.</td></tr><tr><td>ISO15118Ctrlr</td><td>Responsible for configuration relating to the ISO 15118 controller</td></tr><tr><td>LocalAuthListCtrlr</td><td>Responsible for configuration relating to the use of local authorization lists for Charging Station use.</td></tr><tr><td>MonitoringCtrlr</td><td>Responsible for configuration relating to the exchange of monitoring event data.</td></tr><tr><td>OCPPCommCtrlr</td><td>Responsible for configuration relating to information exchange between Charging Station and CSMS.</td></tr><tr><td>ReservationCtrlr</td><td>Responsible for configuration relating to reservations.</td></tr><tr><td>SampledDataCtrlr</td><td>Responsible for configuration relating to the reporting of sampled meter data.</td></tr><tr><td>SecurityCtrlr</td><td>Responsible for configuration relating to security of communications between Charging Station and CSMS.</td></tr><tr><td>SmartChargingCtrlr</td><td>Responsible for configuration relating to Smart Charging.</td></tr><tr><td>TariffCostCtrlr</td><td>Responsible for configuration relating to tariff and cost display.</td></tr><tr><td>TxCtrlr</td><td>Responsible for configuration relating to transaction characteristics and behaviour.</td></tr></table>
+
+Every Controller component has an 'Enabled' variable. This variable can be used to enable/disable a certain functionality. Any data in the charging station is not part of the controller component, so when disabling a functionality, any relating data stored in the
+
+Charging Station will not be changed or removed.
+
+For example: if ReservationCtrl is disabled when there is an active reservation, the EVSE will become available, but the reservation entries will still be there – they are just not used. If afterwards ReservationCtrl is enabled again, the reservation entries will become active again as long as they have not expired and no transaction is in progress. If a transaction has started in the mean time, that transaction remains active. The reservation is then considered expired.
+
+# 2. Referenced Components and Variables
+
+Below follows a list of all Component Variable combinations with a role standardized in this specification.
+
+These Configuration Variables replace the Configuration Keys from OCPP 1.x
+
+The list is split by functionality: General, Security, Authorization, Local Authorization List Management related, Authorization Cache, Transaction, Metering, Reservation, Smart Charging, Tariff & Cost, Diagnostics, Display Message and Charging Infrastructure related.
+
+A required Configuration Variable mentioned under a particular function block only has to be supported by the Charging Station if it supports that functional block.
+
+Please see chapter 4 in "Part 1 - Architecture & Topology" about the addressing of Components and Variables in the Device Model.
+
+Requirements for all the Configuration Variables in this document:
+
+- All variables that are writable SHALL have the VariableAttribute field: persistence = true, and SHALL thus be stored in a persistent way.
+- Any fields not defined SHALL be left empty.
+- Any field marked with a \* (Asterisk) can be of any possible value.
+- When the AttributeType is NOT given, the CSMS and Charging Station SHALL assume the AttributeType to be Actual.
+
+# NOTE
+
+See 'OCPP 2.0 Part 4 - JSON over Websocket implementation guide' for a number of Configuration Variables that are specific to controlling the JSON/Websocket behavior.
+
+# 2.1. General
+
+# NOTE
+
+WebSocket-related variables are described in "OCPP-2.0.1 Part 4 JSON over WebSockets".
+
+# 2.1.1.ActiveNetworkProfile
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ActiveNetworkProfile</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Indicates the configuration profile the station uses at that moment to connect to the network. This configuration variable only has to be implemented when NetworkConnectionProfile is implemented.</td></tr></table>
+
+# 2.1.2. AllowNewSessionsPendingFirmwareUpdate
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ChargingStation</td></tr><tr><td rowspan="3">Variable</td><td>,name</td><td colspan="2">AllowNewSessionsPendingFirmwareUpdate</td></tr><tr><td>Attributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>Characteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Indicates whether new sessions can be started on EVSEs, while Charging Station is waiting for all EVSEs to become Available in order to start a pending firmware update.When a firmware update is waiting to be installed and this variable exists and has the value true, then, the Charging Station will not set free EVSEs to Unavailable, pending the update. This means that it may take longer until there is a point in time when all EVSEs of the Charging Station are free and it can perform the firmware update.</td></tr></table>
+
+# 2.1.3. DefaultMessageTimeout
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">MessageTimeout</td></tr><tr><td>variableInstance</td><td colspan="2">Default</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">The purpose of the message timeout is to be able to consider a request message as not sent and continue with other tasks when the message did not arrive due to communication errors or software failure. The message timeout setting in a Charging Station can be configured in the messageTimeout field in the NetworkConnectionProfile.</td></tr></table>
+
+# 2.1.4. FileTransferProtocols
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">FileTransferProtocols</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>Description</td><td colspan="3">List of supported file transfer protocols.Possible values: FTP, FTPS, HTTP, HTTPS, SFTP.</td></tr></table>
+
+# 2.1.5. HeartbeatInterval
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">HeartbeatInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>minLimit</td><td>1</td></tr><tr><td>Description</td><td colspan="3">Interval of inactivity (no OCPP exchanges) with CSMS after which the Charging Station should send HeartbeatRequest.</td></tr></table>
+
+# 2.1.6. NetworkConfigurationPriority
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">NetworkConfigurationPriority</td></tr><tr><td rowspan="2">variableAttributes</td><td>attributeType</td><td>Actual</td></tr><tr><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>SequenceList</td></tr><tr><td>valueList</td><td>List of possible values</td></tr><tr><td>Description</td><td colspan="3">A comma separated ordered list of the priority of the possible Network Connection Profiles. The list of possible available profile slots for the network configuration profiles SHALL be reported, via the valueList characteristic of this Variable.</td></tr></table>
+
+# 2.1.7. NetworkProfileConnectionAttempts
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">NetworkProfileConnectionAttempts</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Specifies the number of connection attempts the Charging Station executes before switching to a different profile.</td></tr></table>
+
+# 2.1.8. OfflineThreshold
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">OfflineThreshold</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When the offline period of a Charging Station exceeds the OfflineThreshold it is recommended to send a StatusNotificationRequest for all its Connectors when the Charging Station is back online.</td></tr></table>
+
+# 2.1.9. QueueAllMessages
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>ijklname</td><td colspan="2">QueueAllMessages</td></tr><tr><td>ijklAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>ijklCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When this variable is set to true, the Charging Station will queue all message until they are delivered to the CSMS. When set to false the Charging Station will only queue Transaction related messages as required in: E04.FR.01. and other requirementsWhen this variable is the to true, and the Charging Station is running low on memory, the Charging Station SHALL drop TransactionEvent messages last, and when dropping measurements/meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the beginning or end of the measurements/meter data.Default = false</td></tr></table>
+
+# 2.1.10. MessageAttemptsTransactionEvent
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">MessageAttempts</td></tr><tr><td>variableInstance</td><td colspan="2">TransactionEvent</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">How often the Charging Station should try to submit a TransactionRequest message when the CSMS fails to process it.</td></tr></table>
+
+# 2.1.11. MessageAttemptIntervalTransactionEvent
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>OCPPCommCtrlr</td></tr><tr><td rowspan="6">Variable</td><td>variableName</td><td colspan="2">MessageAttemptInterval</td></tr><tr><td>variableInstance</td><td colspan="2">TransactionEvent</td></tr><tr><td rowspan="2">variableAttributes</td><td>attributeType</td><td>Actual</td></tr><tr><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">How long the Charging Station should wait before resubmitting a TransactionRequest message that the CSMS failed to process.</td></tr></table>
+
+# 2.1.12.UnlockOnEVSideDisconnect
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">UnlockOnEVSideDisconnect</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite/ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When set to true, the Charging Station SHALL unlock the cable on the Charging Station side when the cable is unplugged at the EV. For an EVSE with only fixed cables, the mutability SHALL be ReadOnly and the actual value SHALL be false. For a charging station with fixed cables and sockets, the variable is only applicable to the sockets.</td></tr></table>
+
+# 2.1.13. WebSocketPingInterval
+
+This configuration variable is described in "OCPP-2.0.1 Part 4 JSON over WebSockets".
+
+# 2.1.14. ResetRetries
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ResetRetries</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Number of times to retry a reset of the Charging Station when a reset was unsuccessful.</td></tr></table>
+
+# 2.1.15. MessageFieldLength
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">FieldLength</td></tr><tr><td>variableInstance</td><td colspan="2">.<message>.<field></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">This variable is used to report the length of <field> in <message> when it is larger than the length that is defined in the standard OCPP message schema.</td></tr></table>
+
+# 2.1.16. ItemsPerMessageGetReport
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ItemsPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">GetReport</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of ComponentVariable entries that can be sent in one getReportRequest or GetMonitoringReportRequest message.</td></tr></table>
+
+# 2.1.17. ItemsPerMessageGetVariables
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ItemsPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">GetVariables</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of GetVariableData objects in GetVariablesRequest.</td></tr></table>
+
+# 2.1.18. BytesPerMessageGetReport
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BytesPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">GetReport</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Message Size (in bytes) - puts constraint on getReportRequest or GetMonitoringReportRequest message size.</td></tr></table>
+
+# 2.1.19. BytesPerMessageGetVariables
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BytesPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">GetVariables</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Message Size (in bytes) - puts constraint on GetVariablesRequest message size.</td></tr></table>
+
+# 2.1.20. ConfigurationValueSize
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ConfigurationValueSize</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>1000</td></tr><tr><td>Description</td><td colspan="3">This Configuration Variable can be used to limit the following fields: SetVariableData(attributeValue and
+VariableCharacteristics.valueList. The max size of these values will always remain equal.</td></tr></table>
+
+# 2.1.21. ReportingValueSize
+
+<table><tr><td>Required</td><td>no</td></tr></table>
+
+<table><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ReportingValueSize</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>2500</td></tr><tr><td>Description</td><td colspan="3">This Configuration Variable can be used to limit the following fields: GetVariableResult(attributeValue, VariableAttribute.value and EventData的实际Value. The max size of these values will always remain equal.</td></tr></table>
+
+# 2.1.22. ItemsPerMessageSetVariables
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ItemsPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">SetVariables</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of SetVariableData objects in SetVariablesRequest.</td></tr></table>
+
+# 2.1.23. BytesPerMessageSetVariables
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BytesPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">SetVariables</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Message Size (in bytes) - puts constraint on SetVariablesRequest message size.</td></tr></table>
+
+# 2.1.24. DateTime
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">DateTime</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>DateTime</td></tr><tr><td>Description</td><td colspan="3">Contains the current date and time.</td></tr></table>
+
+# 2.1.25. NtpSource
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">NtpSource</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>valuesList</td><td>DHCP, manual</td></tr><tr><td>Description</td><td colspan="3">When an NTP client is implemented, this variable can be used to configure the client: Use the NTP server provided via DHCP, or use the manually configured NTP server.</td></tr></table>
+
+# 2.1.26. NtpServerUri
+
+<table><tr><td>Required</td><td>no</td></tr></table>
+
+<table><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">NtpServerUri</td></tr><tr><td>variableInstance</td><td colspan="2">Single digit, multiple servers allowed, primary NtpServer has instance '1', the secondary has instance '2'. etc</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">When an NTP client is implemented, this variable can be used to configure the client: This contains the address of the NTP server.Multiple NTP servers can be configured. These can be back-up NTP servers. If the NTP client supports it, it can also connect to multiple NTP servers simultaneous to get a more reliable time source.</td></tr></table>
+
+# 2.1.27.TimeOffset
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">TimeOffset</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td rowspan="3">Description</td><td colspan="3">Configured current local time offset in the format: "+01:00", "-02:00" etc.</td></tr><tr><td colspan="3">When a TimeOffset is used, it is advised not to implement: TimeZone. If a Charging Station has implemented both TimeOffset and TimeZone it is RECOMMENDED to not use both at the same time.</td></tr><tr><td colspan="3">The time offset is for display purposes.</td></tr></table>
+
+# 2.1.28. NextTimeOffsetTransitionDateTime
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">NextTimeOffsetTransitionDateTime</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>DateTime</td></tr><tr><td>Description</td><td colspan="3">Date time of the next time offset transition. On this date time, the clock displayed to the EV driver will be given the new offset as configured via 'TimeOffsetNextTransition'.This can be used to manually configure the next start or end of a daylight saving time period.</td></tr></table>
+
+# 2.1.29.TimeOffsetNextTransition
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TimeOffset</td></tr><tr><td>variableInstance</td><td colspan="2">NextTransition</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">Next local time offset in the format: "+01:00", "-02:00" etc.
+New offset that will be set on the next time offset transition as configured via
+'NextTimeOffsetTransitionDateTime'.
+This can be used to manually configure the offset for the start or end of the daylight saving time period.</td></tr></table>
+
+# 2.1.30.TimeSource
+
+<table><tr><td>Required</td><td>yes</td></tr></table>
+
+<table><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TimeSource</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>SequenceList</td></tr><tr><td>valuesList</td><td>List of all implemented time sources. Possible values: Heartbeat, NTP, GPS, RealTimeClock, MobileNetwork, RadioTimeTransmitter</td></tr><tr><td>Description</td><td colspan="3">Via this variable, the Charging Station provides the CSMS with the option to configure a clock source, if more than 1 are implemented.
+By providing a list of possible sources, the CSO can configure fallback sources.
+Example:
+"NTP,Heartbeat" means, use NTP, but when none of the NTP servers responses, use time synchronization via Heartbeat.
+NOTE: RadioTimeTransmitter: At various locations around the globe, low-frequency radio transmitters provide accurate local time information e.g. DCF77 in Germany, MSF in the United Kingdom, JJY in Japan etc. Such a radio time clock can be used as a time source for a Charging Station. The Charging Station shall convert the broadcasted time to UTC. For this TimeZone, TimeOffset, 'NextTimeOffsetTransitionDateTime' and 'TimeOffsetNextTransition' can be used.</td></tr></table>
+
+# 2.1.31.TimeZone
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">TimeZone</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td rowspan="3">Description</td><td colspan="3">Configured current local time zone in the format: "Europe/Oslo", "Asia/Singapore" etc.</td></tr><tr><td colspan="3">When a time zone is used, it is advised not to implement: TimeOffset. If a Charging Station has implemented both TimeOffset and TimeZone it is RECOMMENDED to not use both at the same time.</td></tr><tr><td colspan="3">The time zone is for display purposes.</td></tr></table>
+
+# 2.1.32. TimeAdjustmentReportingThreshold
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TimeAdjustmentReportingThreshold</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When the clock time is adjusted forwards or backwards for more then TimeAdjustmentReportingThreshold number of seconds, a SecurityEventNotification( "SettingSystemTime") is sent by the charging station. A reasonable value is 20 seconds.</td></tr></table>
+
+# 2.1.33.CustomImplementationEnabled
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>CustomizationCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">CustomImplementationEnabled</td></tr><tr><td>variableInstance</td><td colspan="2"><VendorId></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">This standard configuration variable can be used to enable/disable custom implementations that the Charging Station supports.It is recommended to first check if the custom behavior is able to be implemented using the device model, otherwise DataTransfer message(s) and/or CustomData fields can be used.</td></tr></table>
+
+# 2.2. Security related
+
+# 2.2.1. 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.
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BasicAuthPassword</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>WriteOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>40 (Max length of the BasicAuthPassword)</td></tr><tr><td>Description</td><td colspan="3">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 (alpha-numeric 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.</td></tr></table>
+
+# 2.2.2. Identity
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Identity</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly orReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>48 (Charging Station Identity)</td></tr><tr><td>Description</td><td colspan="3">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".</td></tr></table>
+
+# 2.2.3. OrganizationName
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">OrganizationName</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">This configuration variable is used to set the organization name of the CSO or an organization trusted by the CSO. It is used to set the O (organizationName) RDN in the subject field of the client certificate. See also A00.FR.509.</td></tr></table>
+
+# 2.2.4. CertificateEntries
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">CertificateEntries</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>Maximum number of Certificates installed at any time.</td></tr><tr><td>Description</td><td colspan="3">Amount of Certificates currently installed on the Charging Station.</td></tr></table>
+
+# 2.2.5. SecurityProfile
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SecurityProfile</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">This configuration variable is used to report the security profile used by the Charging Station.</td></tr></table>
+
+# 2.2.6. AdditionalRootCertificateCheck
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">AdditionalRootCertificateCheck</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When set to true, only one certificate (plus a temporarily fallback certificate) of certificateType CSMSRootCertificate is allowed to be installed at a time. When installing a new CSMS Root certificate, the new certificate SHALL replace the old one AND the new CSMS Root Certificate MUST be signed by the old CSMS Root Certificate it is replacing. This configuration variable is required unless only "security profile 1 - Unsecured Transport with Basic Authentication" is implemented. Please note that security profile 1 SHOULD only be used in trusted networks. Note: When using this additional security mechanism please be aware that the Charging Station needs to perform a full certificate chain verification when the new CSMS Root certificate is being installed. However, once the old CSMS Root certificate is set as the fallback certificate, the Charging Station needs to perform a partial certificate chain verification when verifying the server certificate during the TLS handshake. Otherwise the verification will fail once the old CSMS Root (fallback) certificate is either expired or removed. Note 2: The statement that the variable is required, means that the configuration variable must be present, but does NOT indicate that the feature must be implemented. This is an optional feature. By setting the value to false, the Charging Station indicates that it does not support this feature, whereas true means that it does support the feature.</td></tr></table>
+
+# 2.2.7.MaxCertificateChainSize
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">MaxCertificateChainSize</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>10000</td></tr><tr><td>Description</td><td>This configuration variable can be used to limit the size of the 'certificateChain' field from the CertificateSignedRequest PDU. This value SHOULD NOT be set too small. The smaller this value, the less security architectures the Charging Station will support. It is RECOMMENDED to set at least a size of 5600. This will allow the Charging Station to support most security architectures.</td></tr></table>
+
+# 2.2.8. CertSigningWaitMinimum
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">CertSigningWaitMinimum</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">This configuration variable defines how long the Charging Station has to wait before generating another CSR, in the case the CSMS accepts the SignCertificateRequest, but never returns the signed certificate back. This value will be doubled after every attempt. The amount of attempts is configured at CertSigningRepeatTimes If the certificate signing process is slow, this setting allows the CSMS to tell the Charging Station to allow more time.</td></tr></table>
+
+# 2.2.9. CertSigningRepeatTimes
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">CertSigningRepeatTimes</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">This variable can be used to configure the amount of times the Charging Station SHALL double the previous back-off time, starting with the number of seconds configured at CertSigningWaitMinimum, every time the back-off time expires without having received the CertificateSignedRequest containing the from the CSR generated signed certificate. When the maximum number of increments is reached, the Charging Station SHALL stop resending the SignCertificateRequest, until it is requested by the CSMS using a TriggerMessageRequest.</td></tr></table>
+
+# 2.3. Authorization related
+
+# 2.3.1. Enabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If set to false, then no authorization is done before starting a transaction or when reading an idToken. If an idToken was provided, then it will be put in the idToken field of the TransactionRequest. If no idToken was provided, then idToken in TransactionRequest will be left empty and type is set to NoAuthorization.</td></tr></table>
+
+# 2.3.2. AdditionalInfoItemsPerMessage
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">AdditionallInfoItemsPerMessage</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of AdditionalInfo items that can be sent in one message. This configuration variable only has to be implemented when AdditionalInfo is implemented.</td></tr></table>
+
+# 2.3.3. OfflineTxForUnknownIdEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>name</td><td colspan="2">OfflineTxForUnknownIdEnabled</td></tr><tr><td>name</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>name</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this key exists, the Charging Station supports Unknown Offline Authorization. If this key reports a value of true, Unknown Offline Authorization is enabled.</td></tr></table>
+
+# 2.3.4.authorizeRemoteStart
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>,name=</td><td colspan="2">AuthorizeRemoteStart</td></tr><tr><td>variables</td><td>mutability</td><td>ReadOnly orReadWrite. Choice is up to Charging Station implementation.</td></tr><tr><td>attributes</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether a remote request to start a transaction in the form of RequestStartTransactionRequest message should be authorized beforehand like a local action to start a transaction.</td></tr></table>
+
+# 2.3.5. LocalauthorizeOffline
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">LocalAuthorizationOffline</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether the Charging Station, when Offline, will start a transaction for locally-authorized identifiers.</td></tr></table>
+
+# 2.3.6. LocalPreauthorize
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">LocalPreauthorize</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether the Charging Station, when online, will start a transaction for locally-authorized identifiers without waiting for or requesting an AuthorizationResponse from the CSMS.</td></tr></table>
+
+# 2.3.7. MasterPassgroupId
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">MasterPassGroupld</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>36 (The maximum string length of MasterPassGroupld)</td></tr><tr><td>Description</td><td colspan="3">IdTokens that have this id as groupld belong to the Master Pass Group. Meaning they can stop any ongoing transaction, but cannot start transactions. This can, for example, be used by law enforcement personal to stop any ongoing transaction when an EV has to be towed away.</td></tr></table>
+
+# 2.3.8. DisableRemoteAuthorization
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">DisableRemoteAuthorization</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When set to true this instructs the Charging Station to not issue any AuthorizationRequests, but only use Authorization Cache and Local Authorization List to determine validity of idTokens.Note: The difference between AuthCtrlrDISABLERemoteAuthorization and AuthCacheCtrlrDISABLEPostAuthorization is that the latter only disables re-authorization of tokens that are as not-Accepted in the Authorization Cache or Local Authorization List, whereas AuthCtrlrDISABLERemoteAuthorization disables all authorization with CSMS.</td></tr></table>
+
+# 2.4. Authorization Cache related
+
+# 2.4.1. AuthCacheEnabled
+
+NOTE When the value of this variable is changed, the content of the authorization cache should not be altered.
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCacheCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable exists and reports a value of true, Authorization Cache is enabled.</td></tr></table>
+
+# 2.4.2. AuthCacheAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCacheCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable exists and reports a value of true, Authorization Cache is supported, but not necessarily enabled.</td></tr></table>
+
+# 2.4.3. AuthCacheLifeTime
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCacheCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">LifeTime</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Indicates how long it takes until a token expires in the authorization cache since it is last used.</td></tr></table>
+
+# 2.4.4. AuthCacheStorage
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>AuthCacheCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Storage</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>The maximum number of bytes</td></tr><tr><td>Description</td><td colspan="3">Indicates the number of bytes currently used by the Authorization Cache. MaxLimit indicates the maximum number of bytes that can be used by the Authorization Cache.</td></tr></table>
+
+# 2.4.5. AuthCachePolicy
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCacheCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Policy</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>valuesList</td><td>LRU, LFU, FIFO, CUSTOM</td></tr><tr><td>Description</td><td colspan="3">Cache Entry Replacement Policy: least recently used, least frequently used, first in first out, other custom mechanism.</td></tr></table>
+
+# 2.4.6. AuthCacheDisablePostAuthorization
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCacheCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">DisablePostAuthorize</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When set to true this variable disables the behavior to request authorization for an idToken that is stored in the cache with a status other than Accepted, as stated in C10.FR.03 and C12.FR.05.</td></tr></table>
+
+# 2.5. Local Authorization List Management related
+
+# 2.5.1. LocalAuthListEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable exists and reports a value of true, Local Authorization List is enabled.</td></tr></table>
+
+# 2.5.2. LocalAuthListEntries
+
+<table><tr><td>Required</td><td colspan="3">when LocalAuthListAvailable is true</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Entries</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>The maximum number of IdTokens that can be stored in the Local Authorization List.</td></tr><tr><td>Description</td><td colspan="3">Amount of IdTokens currently in the Local Authorization List.
+The maxLimit of this variable SHALL be provided to report the maximum number of IdTokens that can be stored in the Local Authorization List.</td></tr></table>
+
+# 2.5.3. LocalAuthListAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable exists and reports a value of true, Local Authorization List is supported.</td></tr></table>
+
+# 2.5.4. ItemsPerMessageSendLocalList
+
+<table><tr><td>Required</td><td colspan="3">when LocalAuthListAvailable is true</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ItemsPerMessage</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr></table>
+
+# 2.5.5. BytesPerMessageSendLocalList
+
+<table><tr><td>Required</td><td colspan="3">when LocalAuthListAvailable is true</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">BytesPerMessage</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr></table>
+
+# 2.5.6. LocalAuthListStorage
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Storage</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>The maximum number of bytes</td></tr><tr><td>Description</td><td colspan="3">Indicates the number of bytes currently used by the Local Authorization List. MaxLimit indicates the maximum number of bytes that can be used by the Local Authorization List.</td></tr></table>
+
+# 2.5.7. LocalAuthListDisablePostauthorize
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">DisablePostAuthorize</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When set to true this variable disables the behavior to request authorization for an idToken that is stored in the local authorization list with a status other than Accepted, as stated in C14.FR.03.</td></tr></table>
+
+# 2.5.8. LocalAuthListSupportsExpiryDateTime
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>LocalAuthListCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SupportsExpiryDateTime</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">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.</td></tr></table>
+
+# 2.6. Transaction related
+
+# 2.6.1. EVConnectionTimeOut
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">EVConnectionTimeOut</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Interval from between "starting" of a transaction until incipient transaction is automatically canceled, due to failure of EV driver to (correctly) insert the charging cable connector(s) into the appropriate socket(s). The Charging Station SHALL go back to the original state, probably: 'Available'. "Starting" might be the swiping of the RFID, pressing a start button, a RequestStartTransactionRequest being received etc.</td></tr></table>
+
+# 2.6.2. StopTxOnEVSideDisconnect
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">StopTxOnEVSideDisconnect</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite or ReadOnly, depending on Charging Station implementation.</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When set to true, the Charging Station SHALL deauthorize the transaction when the cable is unplugged from the EV.</td></tr></table>
+
+# 2.6.3. TxBeforeAcceptedEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">TxBeforeAcceptedEnabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">With this configuration variable the Charging Station can be configured to allow charging before having received a BootNotificationResponse with RegistrationStatus: Accepted. See: Transactions before being accepted by a CSMS.</td></tr></table>
+
+# 2.6.4. TxStartPoint
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>TxCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxStartPoint</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly orReadWrite. Choice is up to Charging Station implementation.</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valueList</td><td>See TxStartStopPoint values for allowed values. It is not required to implement all possible values.</td></tr><tr><td>Description</td><td colspan="3">Defines when the Charging Station starts a new transaction: first transactioneventRequest: eventType = Started. When any event in the given list occurs, the Charging Station SHALL start a transaction. The Charging Station SHALL only send the Started event once for every transaction. It is advised to put all events that should be part of a transaction in the list, in case the start event never occurs. Because the possible events don't always have to come in the same order it is possible to provide a list of events. Which ever comes first will then cause a transaction to be started. For example: EVConnected, Authorized would mean that a transaction is started when an EV is detected (Cable is connected), or when an EV Driver swipes his RFID card en the CSMS successfully authorizes the ID for charging.</td></tr></table>
+
+# 2.6.5. TxStopPoint
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxStopPoint</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly orReadWrite. Choice is up to Charging Station implementation.</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valueList</td><td>See TxStartStopPoint values for allowed values. It is not required to implement all possible values.</td></tr><tr><td>Description</td><td colspan="3">Defines when the Charging Station ends a transaction: last transactioneventRequest: eventType = Ended. When any event in the given list is no longer valid, the Charging Station SHALL end the transaction. The Charging Station SHALL only send the Ended event once for every transaction.</td></tr></table>
+
+# 2.6.6. TxStartStopPoint values
+
+# 2.6.6.1. TxStartPoint values
+
+The following table lists the values allowed for the TxStartPoint variable. These values represent logical steps or events that (may) occur during a charging session. When such an event occurs, and it is listed in in the TxStartPoint variable, then this marks the start of a transaction.
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ParkingBayOccupancy</td><td>An object (probably an EV) is detected in the parking/charging bay.</td></tr><tr><td>EVConnected</td><td>Both ends of the Charging Cable have been connected (if this can be detected, else detection of a cable being plugged into the socket), or for wireless charging: initial communication between EVSE and EV is established.</td></tr><tr><td>Authorized</td><td>Driver or EV has been authorized, this can also be some form of anonymous authorization like a start button.</td></tr><tr><td>PowerPathClosed</td><td>All preconditions for charging have been met, power can flow. This event is the logical AND of EVConnected and Authorized and should be used if a transaction is supposed to start when EV is connected and authorized. Despite its name, this event is not related to the state of the power relay.
+Note: There may be situations where PowerPathClosed does not imply that charging starts at that moment, e.g. because of delayed charging or a battery that is too hot.</td></tr><tr><td>EnergyTransfer</td><td>Energy is being transferred between EV and EVSE.</td></tr><tr><td>DataSigned</td><td>The moment when the signed meter value is received from the fiscal meter, that is used in the TransactionEventRequest with context = Transaction.Begin and triggerReason = SignedDataReceived. This TxStartPoint might be applicable when legislation exists that only allows a billable transaction to start when the first signed meter value has been received.</td></tr></table>
+
+# 2.6.6.2. TxStopPoint values
+
+The following table lists the values allowed for the TxStopPoint variable. These values represent logical steps or events that (may) occur during a charging session. When such an event occurs, and it is listed in in the TxStopPoint variable, then this marks the end of a transaction.
+
+The values are the same as for TxStartPoint, but in this case the meaning is different, since it refers to the ending of the event, rather than the start. For use with TxStopPoint each value should be interpreted as if it had "Not" prefixed to it. See the following table:
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ParkingBayOccupancy</td><td>An object (probably an EV) is no longer detected in the parking/charging bay.</td></tr><tr><td>EVConnected</td><td>One or both ends of the Charging Cable have been disconnected (if this can be detected, else detection of a cable being unplugged from the socket), or for wireless charging: communication between EVSE and EV is lost.</td></tr><tr><td>Authorized</td><td>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 TransactionRequest with eventType = Ended will be transmitted.</td></tr><tr><td>PowerPathClosed</td><td>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 TransactionRequest 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.</td></tr><tr><td>EnergyTransfer</td><td>Energy is not being transferred between EV and EVSE. This is not recommended to use as a TxStopPoint, because it will stop the transaction as soon as EV or EVSE (temporarily) suspend the charging.</td></tr><tr><td>DataSigned</td><td>This condition has no meaning as a TxStopPoint and should not be used as such.</td></tr></table>
+
+# 2.6.7. MaxEnergyOnInvalidId
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">MaxEnergyOnInvalidId</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>Wh</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum amount of energy in Wh delivered when an identifier is deauthorized by the CSMS after start of a transaction.</td></tr></table>
+
+# 2.6.8. StopTxOnInvalidId
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">StopTxOnInvalidId</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">whether the Charging Station will deauthorize an ongoing transaction when it receives a non-Accepted authorization status in TransactionEventResponse for this transaction.</td></tr></table>
+
+# 2.7. Metering related
+
+# 2.7.1. SampleDataEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable reports a value of true, Sampled Data is enabled.</td></tr></table>
+
+# 2.7.2. SampledDataAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable reports a value of true, Sampled Data is supported.</td></tr></table>
+
+# 2.7.3. SampledDataSignReadings
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SignReadings</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If set to true, the Charging Station SHALL include signed meter values in the TransactionEventRequest to the CSMS. Some Charging Stations might only be able to sign Transaction.Begin and Transaction.End meter values. When a Charging Station does not support signed meter values it SHALL NOT report this variable.</td></tr></table>
+
+# 2.7.4. SampledDataTxEndedMeasurands
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxEndedMeasurands</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>maxLimit</td><td>The maximum length of the CSV formatted string, to be defined by the implementer.</td></tr></table>
+
+2.7.5. SampledDataTxEndInterval
+
+<table><tr><td>Description</td><td>Sampled measurands to be included in the meterValues element of TransactionRequest (eventType = Ended), every SampledDataTxEndInterval 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 TransactionRequest (eventType = Ended).</td></tr></table>
+
+2.7.6. SampledDataTxStartedMeasurands
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxEndInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Interval between sampling of metering (or other) data, intended to be transmitted in the TransactionEventRequest(eventType = Ended) message. For transaction data (evseld>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 TxEndInterval = 0 is recommended, since other values may result in a lot of data to be transmitted in the TransactionEventRequest (eventType = Ended) message.</td></tr></table>
+
+2.7.7. SampledDataTxUpdatedMeasurands
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxStartedMeasurands</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>maxLimit</td><td>The maximum length of the CSV formatted string, to be defined by the implementer.</td></tr><tr><td>Description</td><td colspan="3">Sampled measurand(s) to be taken at the start of any transaction to be included in the meterValues field of the first TransactionEventRequest message send at the start of a transaction (eventType = Started). 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 SampledDataTxStartedMeasurands. If the Charging Station has a meter, recommended to use as default: "Energy.Active.Importantly.Register"</td></tr></table>
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxUpdatedMeasurands</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>maxLimit</td><td>The maximum length of the CSV formatted string, to be defined by the implementer.</td></tr><tr><td>Description</td><td>Sampled measurands to be included in the meterValues element of every TransactionRequest (eventType = Updated), every SampledDataTxUpdatedInterval seconds from the start 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 SampledDataTxUpdatedMeasurands.
+If the Charging Station has a meter, recommended to use as default: "Energy.Active.Import.Register"</td></tr></table>
+
+# 2.7.8. SampledDataTxUpdatedInterval
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>component Name</td><td colspan="2">SampledDataCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxUpdatedInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Interval between sampling of metering (or other) data, intended to be transmitted via TransactionEventRequest(eventType = Updated) messages. For transaction data (evseld>0), samples are acquired and transmitted periodically at this interval from the start of the charging transaction.A value of "0" (numeric zero), by convention, is to be interpreted to mean that no sampled data should be transmitted during the transaction.</td></tr></table>
+
+# 2.7.9.AlignedDataEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable reports a value of true, Aligned Data is enabled.</td></tr></table>
+
+# 2.7.10.AlignedDataAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable reports a value of true, Aligned Data is supported.</td></tr></table>
+
+# 2.7.11.AlignedDataMeasurands
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>ijklname</td><td colspan="2">Measurands</td></tr><tr><td>ijklAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">ijklCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>maxLimit</td><td>The maximum length of the CSV formatted string, to be defined by the implementer.</td></tr><tr><td>Description</td><td colspan="3">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.</td></tr></table>
+
+# 2.7.12.AlignedDataInterval
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Interval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">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.
+A value of "0" (numeric zero), by convention, is to be interpreted to mean that no clock-aligned data should be transmitted.</td></tr></table>
+
+# 2.7.13.AlignedDataSendDuringIdle
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SendDuringIdle</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If set to true, the Charging Station SHALL NOT send clock aligned meter values when a transaction is ongoing. When an EVSE is specified, it SHALL stop sending the clock aligned meter values for this EVSE when it has an ongoing transaction. When no EVSE is specified, it SHALL stop sending the clock aligned meter values when any transaction is ongoing on this Charging Station.</td></tr></table>
+
+# 2.7.14.AlignedDataSignReadings
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SignReadings</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If set to true, the Charging Station SHALL include signed meter values in the SampledValueType in the TransactionEventRequest to the CSMS for those measurands defined in AlignedDataTxEndedMeasurands. When a Charging Station does not support signed meter values it SHALL NOT report this variable.</td></tr></table>
+
+# 2.7.15.AlignedDataTxEndedMeasurands
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxEndedMeasurands</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>maxLimit</td><td>The maximum length of the CSV formatted string, to be defined by the implementer.</td></tr><tr><td>Description</td><td>Clock-aligned periodic measurand(s) to be included in the meterValues element of TransactionRequest(eventType = Ended) for every AlignedDataTxEndInterval 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 TxEndAlignedData.
+When left empty, no Clock-aligned measurands SHALL be put into the TransactionRequest (eventType = Ended).</td></tr></table>
+
+# 2.7.16.AlignedDataTxEndedInterval
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxEndInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">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 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.</td></tr></table>
+
+# 2.7.17.PublicKeyWithSignedMeterValue
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">PublicKeyWithSignedMeterValue</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>valueList</td><td>Never,OncePerTransaction,EveryMeterValue</td></tr><tr><td>Description</td><td colspan="3">This Configuration Variable can be used to configure whether a public key needs to be sent with a signed meter value. Note, that the field is required, so it needs to be present as an empty string when the public key is not sent.</td></tr></table>
+
+# 2.7.18. SampledDataRegisterValuesWithoutPhases
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">RegisterValuesWithoutPhases</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable reports a value of true, then meter values of measurand Energy.Active.Import.Register will only report the total energy over all phases without reporting the individual phase values. If this variable is absent or false, then the value for each phase is reported, possibly also with a total value (depending on the meter).</td></tr></table>
+
+# 2.8. Reservation related
+
+# 2.8.1. ReservationEnabled
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>ReservationCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Reservation is enabled.</td></tr></table>
+
+# 2.8.2. ReservationAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ReservationCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Reservation is supported.</td></tr></table>
+
+# 2.8.3. ReservationNonEvseSpecific
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ReservationCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">NonEvseSpecific</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this configuration variable is present and set to true: Charging Station supports Reservation where EVSE id is not specified.</td></tr></table>
+
+# 2.9. Smart Charging related
+
+# 2.9.1. SmartChargingEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Smart Charging is enabled.</td></tr></table>
+
+# 2.9.2. SmartChargingAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Smart Charging is supported.</td></tr></table>
+
+# 2.9.3. ACPhaseSwitchingSupported
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ACPhaseSwitchingSupported</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">This variable can be used to indicate an on-load/in-transaction capability. If defined and true, this EVSE supports the selection of which phase to use for 1 phase AC charging.</td></tr></table>
+
+# 2.9.4. ChargingProfileMaxStackLevel
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ProfileStackLevel</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum acceptable value for stackLevel in a ChargingProfile. Since the lowest stackLevel is 0, this means that if SmartChargingCtrl.ProfileStackLevel = 1, there can be at most 2 valid charging profiles per Charging Profile Purpose per EVSE.</td></tr></table>
+
+# 2.9.5. ChargingScheduleChargingRateUnit
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">RateUnit</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>Description</td><td colspan="3">A list of supported quantities for use in a ChargingSchedule.
+Allowed values: 'A' and 'W'</td></tr></table>
+
+# 2.9.6.PeriodsPerSchedule
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">PeriodsPerSchedule</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of periods that may be defined per ChargingSchedule.</td></tr></table>
+
+# 2.9.7. ExternalControlSignalsEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ExternalControlSignalsEnabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly orReadWrite. Choice is up to Charging Station implementation.</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Indicates whether a Charging Station should respond to external control signals that influence charging.</td></tr></table>
+
+# 2.9.8. NotifyChargingLimitWithSchedules
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">NotifyChargingLimitWithSchedules</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Indicates if the Charging Station should include the externally set charging limit/schedule in the message when it sends a NotifyChargingLimitRequest message. This might increase the data usage significantly, especially when an external system sends new profiles/limits with a short interval. Default is false when omitted.</td></tr></table>
+
+# 2.9.9. Phases3to1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Phases3to1</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If defined and true, this Charging Station supports switching from 3 to 1 phase during a transaction.</td></tr></table>
+
+# 2.9.10. ChargingProfileEntries
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrl</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">Entries</td></tr><tr><td>VariableInstance</td><td colspan="2">ChargingProfiles</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>Maximum number of Charging profiles installed at any time.</td></tr><tr><td>Description</td><td colspan="3">Amount of Charging profiles currently installed on the Charging Station.</td></tr></table>
+
+# 2.9.11. LimitChangeSignificance
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">LimitChangeSignificance</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>decimal</td></tr><tr><td>Description</td><td colspan="3">If at the Charging Station side a change in the limit in a ChargingProfile is lower than this percentage, the Charging Station MAY skip sending a NotifyChargingLimitRequest or a TransactionEventRequest message to the CSMS. It is RECOMMENDED to set this key to a low value. See Smart Charging signals to a Charging Station from multiple actors.</td></tr></table>
+
+# 2.10. Tariff & Cost related
+
+# 2.10.1. TariffEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableInstance</td><td colspan="2">Tariff</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Tariff is enabled.</td></tr></table>
+
+# 2.10.2. TariffAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableInstance</td><td colspan="2">Tariff</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Tariff is supported.</td></tr></table>
+
+# 2.10.3. TariffFallbackMessage
+
+Required for Charging Stations supporting Tariff Information.
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TariffFallbackMessage</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>255</td></tr><tr><td>Description</td><td colspan="3">Message (and/or tariff information) to be shown to an EV Driver when there is no driver specific tariff information available.</td></tr></table>
+
+# 2.10.4. Enabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableInstance</td><td colspan="2">Cost</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Cost is enabled.</td></tr></table>
+
+# 2.10.5. CostAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableInstance</td><td colspan="2">Cost</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Cost is supported.</td></tr></table>
+
+# 2.10.6. TotalCostFallbackMessage
+
+Required for Charging Stations supporting Tariff Information.
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TotalCostFallbackMessage</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>255</td></tr><tr><td>Description</td><td colspan="3">Message to be shown to an EV Driver when the Charging Station cannot retrieve the cost for a transaction at the end of the transaction.</td></tr></table>
+
+# 2.10.7. Currency
+
+Required for Charging Stations supporting Tariff Information.
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Currency</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>3</td></tr><tr><td>Description</td><td colspan="3">Currency used by this Charging Station in a ISO 4217 [ISO4217] formatted currency code.</td></tr></table>
+
+# 2.11. Diagnostics related
+
+# 2.11.1. MonitoringEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Monitoring is enabled.</td></tr></table>
+
+# 2.11.2. MonitoringAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Monitoring is supported.</td></tr></table>
+
+# 2.11.3. ItemsPerMessageClearVariableMonitoring
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ItemsPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">ClearVariableMonitoring</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of IDs in a ClearVariableMonitoringRequest.</td></tr></table>
+
+# 2.11.4. ItemsPerMessageSetVariableMonitoring
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ItemsPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">SetVariableMonitoring</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of setMonitoringData elements that can be sent in one setVariableMonitoringRequest message.</td></tr></table>
+
+# 2.11.5. BytesPerMessageClearVariableMonitoring
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BytesPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">ClearVariableMonitoring</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Message Size (in bytes) - puts constraint on ClearVariableMonitoringRequest message size.</td></tr></table>
+
+# 2.11.6. BytesPerMessageSetVariableMonitoring
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BytesPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">SetVariableMonitoring</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Message Size (in bytes) - puts constraint on setVariableMonitoringRequest message size.</td></tr></table>
+
+# 2.11.7.OfflineMonitoringEventQueuingSeverity
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>ijklname</td><td colspan="2">OfflineQueuingSeverity</td></tr><tr><td>ijklAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>ijklCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When set and the Charging Station is offline, the Charging Station shall queue any notifyEventRequest messages triggered by a monitor with a severity number equal to or lower than the severity configured here. Value ranging from 0 (Emergency) to 9 (Debug).</td></tr></table>
+
+# 2.11.8.ActiveMonitoringBase
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ActiveMonitoringBase</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>Description</td><td colspan="3">Shows the currently used MonitoringBase. Valid values according MonitoringBaseEnumType: A11, FactoryDefault, HardwiredOnly.</td></tr></table>
+
+# 2.11.9.ActiveMonitoringLevel
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ActiveMonitoringLevel</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Shows the currently used MonitoringLevel. Valid values are severity levels of SetMonitoringLevelRequest: 0-9.</td></tr></table>
+
+# 2.12. Display Message related
+
+# 2.12.1.DisplayMessageEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DisplayMessageCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Display Message is enabled.</td></tr></table>
+
+# 2.12.2. DisplayMessageAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DisplayMessageCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Display Message is supported.</td></tr></table>
+
+# 2.12.3.NumberOfDisplayMessages
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DisplayMessageCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">DisplayMessages</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>Maximum number of different messages that can configured in this Charging Station simultaneous, via SetDisplayMessageRequest.</td></tr><tr><td>Description</td><td colspan="3">Amount of different messages that are currently configured in this Charging Station, via SetDisplayMessageRequest</td></tr></table>
+
+# 2.12.4. DisplayMessageSupportedFormats
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DisplayMessageCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SupportedFormats</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>Description</td><td colspan="3">List of message formats supported by this Charging Station. Possible values: MessageFormat.</td></tr></table>
+
+# 2.12.5. DisplayMessageSupportedPriorities
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DisplayMessageCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SupportedPriorities</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>Description</td><td colspan="3">List of the priorities supported by this Charging Station. Possible values: MessagePriority.</td></tr></table>
+
+# 2.13. Charging Infrastructure related
+
+# 2.13.1. Available
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td rowspan="4">Components</td><td rowspan="3">componentName</td><td colspan="2">ChargingStation</td></tr><tr><td colspan="2">EVSE</td></tr><tr><td colspan="2">Connector</td></tr><tr><td>evse</td><td colspan="2">* (for EVSE and Connector)</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When true the Component exists and is locally configured/wired for use, but may not be (remotely) Enabled. This variable is required on any Component that can be reported by the Charging Station. As a minimum it shall exist on ChargingStation, EVSE and Connector.</td></tr><tr><td>Note</td><td colspan="3">If any other variables are reported for a Component, then reporting Available does not add much value and may be omitted. However, the variable needs to exist, because it can be queried for by a GetCustomReport request for all Components that are 'available'.EVSE and Connector components are addressed on their respective tier. So, EVSE #1 is addressed as component EVSE on tier "evse = 1" and connector #1 on this EVSE is addressed as component Connector on tier "evse = 1, connector = 1.</td></tr></table>
+
+# 2.13.2. AvailabilityState
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td rowspan="3">Components</td><td rowspan="2">componentName</td><td colspan="2">ChargingStation</td></tr><tr><td colspan="2">EVSE</td></tr><tr><td>evse</td><td colspan="2">* (for EVSE)</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">AvailabilityState</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>optionList</td></tr><tr><td>valuesList</td><td>Available, Occupied, Reserved, Unavailable, Faulted</td></tr><tr><td>Description</td><td colspan="3">This variable reports current availability state for the ChargingStation and EVSE. If a Connector has its own availability state independent of the EVSE, then this variable may be used to report the Connector's availability state. As such it replicates ConnectorStatus values reported in StatusNotification messages.
+An EVSE component is addressed on its own tier. So, EVSE #1 is addressed as component EVSE on tier "evse = 1.</td></tr></table>
+
+# 2.13.3. AllowReset
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td>EVSE</td></tr><tr><td>evse</td><td>*</td></tr></table>
+
+<table><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">AllowReset</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Component can be reset. Can be used to announce that an EVSE can be reset individually.</td></tr></table>
+
+# 2.13.4. ConnectorType
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">Connector</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ConnectorType</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">Value of the type of connector as defined by ConnectorEnumType in "Part 2 - Specification" plus additionally: cGBT, cChaoJi, OppCharge.</td></tr></table>
+
+# 2.13.5. PhaseRotation
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">*</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>name</td><td colspan="2">PhaseRotation</td></tr><tr><td>variables</td><td>mutability</td><td>ReadOnly orReadWrite.</td></tr><tr><td>characteristics</td><td>dataType</td><td>String</td></tr><tr><td>Description</td><td colspan="3">This variable describes the phase rotation of a Component relative to its parent Component, using a three letter string consisting of the letters: R, S, T and x.The letter 'R' can be identified as phase 1 (L1), 'S' as phase 2 (L2), 'T' as phase 3 (L3).The lower case 'x' is used to designate a phase that is not connected.An empty string means that phase rotation is not applicable or not known.Certain measurands, like voltage and current, are reported with a phase relative to the grid connection. In order to support this, all components in the chain from Connector to ElectricalFeed need to have a value for PhaseRotation.Some examples:""(unknown)"RST"(Standard Reference Phasing)"RTS"(Reversed Reference Phasing)"SRT"(Reversed 240 degree rotation)"STR"(Standard 120 degree rotation)"TRS"(Standard 240 degree rotation)"TSR"(Reversed 120 degree rotation)"RSx"(Two phases connected)"Rxx"(One phase connected)</td></tr></table>
+
+# 2.13.6. SupplyPhases
+
+<table><tr><td>Required</td><td>yes</td></tr></table>
+
+<table><tr><td rowspan="4">Components</td><td rowspan="3">componentName</td><td colspan="2">ChargingStation</td></tr><tr><td colspan="2">EVSE</td></tr><tr><td colspan="2">Connector</td></tr><tr><td>evse</td><td colspan="2">* (for EVSE and Connector)</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SupplyPhases</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Number of alternating current phases connected/available. 1 or 3 for AC, 0 means DC (no alternating phases). Null value indicates that the number of phases (e.g. in use) is unknown.</td></tr></table>
+
+# 2.13.7. Power
+
+<table><tr><td>Required</td><td colspan="3">yes (maxLimit only)</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">EVSE</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Power</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>decimal</td></tr><tr><td>maxLimit</td><td>decimal</td></tr><tr><td>Description</td><td colspan="3">The variableCharacteristic maxLimit, that holds the maximum power that this EVSE can provide, is required. The Actual value of the instantaneous (real) power is desired, but not required.</td></tr></table>
+
+# 2.13.8. Example Reporting of EVSEs and Connectors via device model
+
+The following example illustrates how the device model reports EVSEs and Connectors for an example charging station that has two EVSEs, of which EVSE #1 has one Type2 connector and EVSE #2 has two connectors: CCS and CHAdeMO.
+
+<table><tr><td colspan="4">Component</td><td colspan="2">Variable</td><td colspan="2">VariableAttribute</td><td colspan="3">VariableCharacteristics</td></tr><tr><td>name</td><td>evse id</td><td>evse conne-ctorId</td><td>instance</td><td>name</td><td>instance</td><td>type</td><td>value</td><td>dataType</td><td>maxLimit</td><td>supports Monitorin g</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>AvailabilityState</td><td></td><td>Actual</td><td>Available</td><td>boolean</td><td></td><td>false</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>SupplyPhases</td><td></td><td>Actual</td><td>integer</td><td>3</td><td></td><td>false</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>ACCurrent</td><td>"L1"</td><td>Actual</td><td>decimal</td><td>45.0</td><td></td><td>true</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>ACCurrent</td><td>"L2"</td><td>Actual</td><td>decimal</td><td>44.9</td><td></td><td>true</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>ACCurrent</td><td>"L3"</td><td>Actual</td><td>decimal</td><td>44.9</td><td></td><td>true</td></tr><tr><td>EVSE</td><td>1</td><td></td><td>"left"</td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>1</td><td></td><td>"left"</td><td>AvailabilityState</td><td></td><td>Actual</td><td>Available</td><td>optionList</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>1</td><td></td><td>"left"</td><td>SupplyPhases</td><td></td><td>Actual</td><td>3</td><td>integer</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>1</td><td></td><td>"left"</td><td>Power</td><td></td><td>Actual</td><td>0.0</td><td>decimal</td><td>22000.0</td><td>true</td></tr><tr><td>Connector</td><td>1</td><td>1</td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>Connector</td><td>1</td><td>1</td><td></td><td>ConnectorType</td><td></td><td>Actual</td><td>sType2</td><td>string</td><td></td><td>false</td></tr><tr><td>Connector</td><td>1</td><td>1</td><td></td><td>SupplyPhases</td><td></td><td>Actual</td><td>3</td><td>integer</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>2</td><td></td><td>"right"</td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>2</td><td></td><td>"right"</td><td>AvailabilityState</td><td></td><td>Actual</td><td>Occupied</td><td>optionList</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>2</td><td></td><td>"right"</td><td>SupplyPhases</td><td></td><td>Actual</td><td>0</td><td>integer</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>2</td><td></td><td>"right"</td><td>Power</td><td></td><td>Actual</td><td>41000.0</td><td>decimal</td><td>50000.0</td><td>true</td></tr><tr><td>Connector</td><td>2</td><td>1</td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>1</td><td></td><td>AvailabilityState</td><td></td><td>Actual</td><td>Occupied</td><td>optionList</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>1</td><td></td><td>ConnectorType</td><td></td><td>Actual</td><td>cCCS2</td><td>string</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>1</td><td></td><td>SupplyPhases</td><td></td><td>Actual</td><td>0</td><td>integer</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>2</td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>2</td><td></td><td>AvailabilityState</td><td></td><td>Actual</td><td>Unavailable</td><td>optionList</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>2</td><td></td><td>ConnectorType</td><td></td><td>Actual</td><td>cG105</td><td>string</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>2</td><td></td><td>SupplyPhases</td><td></td><td>Actual</td><td>0</td><td>integer</td><td></td><td>false</td></tr></table>
+
+# NOTE
+
+An instance name has been given to the EVSEs in this example. This is to illustrate that it is allowed to provide an instance name even if only one instance of the component exists. It is not required to do so.
+
+The variable Voltage of ChargingStation has been added to show an example of a multi-instance variable.
+
+Not all VariableAttributes and VariableCharacteristics are shown in the table.
+
+# 2.14. ISO 15118 Related
+
+# 2.14.1. CentralContractValidationAllowed
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td rowspan="3">Variable</td><td>名字</td><td colspan="2">CentralValidationAllowed</td></tr><tr><td>Attributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>Characteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable exists and has the value true, then Charging Station can provide a contract certificate that it cannot validate, to the CSMS for validation as part of theauthorizeRequest.</td></tr></table>
+
+# 2.14.2. ContractValidationOffline
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td rowspan="3">Variable</td><td>ijklntleName</td><td colspan="2">ContractValidationOffline</td></tr><tr><td>ijklntleAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>ijklntleCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable is true, then Charging Station will try to validate a contract certificate when it is offline.</td></tr></table>
+
+# 2.14.3. ProtocolSupportedByEV
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">ConnectedEV</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ProtocolSupportedByEV</td></tr><tr><td>variableInstance</td><td colspan="2"><Priority></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">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"</td></tr></table>
+
+# 2.14.4. ProtocolAgreed
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">ConnectedEV</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ProtocolAgreed</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">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"</td></tr></table>
+
+# 2.14.5. ISO15118PnCEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">PnCEnabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable is true, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is enabled.
+If this variable is false, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is disabled.</td></tr></table>
+
+# 2.14.6. ISO15118V2G Certificate Installation Enabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">V2G Certificate InstallationEnabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable is true, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station is enabled.
+If this variable is false, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station is disabled.</td></tr></table>
+
+# 2.14.7. ISO15118ContractCertificateInstallationEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ContractCertificateInstallationEnabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable is true, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is enabled.
+If this variable is false, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is disabled.</td></tr></table>
+
+# 2.14.8. ISO15118RequestMeteringReceipt
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">RequestMeteringReceipt</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable is true, then Charging Station shall request a metering receipt from EV before sending a fiscal meter value to CSMS.</td></tr></table>
+
+# 2.14.9.IS015118SeccId
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td>evse</td><td colspan="2">* (optional)</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Seccld</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">The name of the SECC in the string format as required by ISO 15118.
+It is used as the commonName (CN) of the SECC leaf certificate.
+Example: "DE-ICE-S-0003C4D5578786756453309675436-2"</td></tr></table>
+
+# 2.14.10. ISO15118CountryName
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td>evse</td><td colspan="2">* (optional)</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">CountryName</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">The countryName of the SECC in the ISO 3166-1 format.
+It is used as the countryName (C) of the SECC leaf certificate.
+Example: "DE"</td></tr></table>
+
+# 2.14.11. ISO15118OrganizationName
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td>evse</td><td colspan="2">* (optional)</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">OrganizationName</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">The organizationName of the CSO operating the charging station.
+It is used as the organizationName (O) of the SECC leaf certificate.
+Example: "John Doe Charging Services Ltd"
+Note: This value will usually be identical to SecurityCtrlr.OrganizationName, but it does not have to be.</td></tr></table>
+
+# 2.14.12. ISO15118EvseId
+
+<table><tr><td>Required</td><td>no</td></tr></table>
+
+<table><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">EVSE</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ISO15118Evseld</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">The name of the EVSE in the string format as required by ISO 15118 and IEC 63119-2.
+Example: "DE*ICE*E*1234567890*1"</td></tr></table>
--- /dev/null
+# OCPP
+
+# Table of Contents
+
+Disclaimer 1
+
+Version History 2
+
+1. Introduction. 3
+
+1.1. Purpose of this document 3
+1.2. Intended audience 3
+1.3. OCPP-S and OCPP-J. 3
+1.4. Conventions 3
+1.5. Definitions & Abbreviations 3
+1.6. References 4
+
+2. Benefits & Issues 5
+
+3. WebSockets 6
+
+3.1. Client request 6
+3.2. Server response 7
+3.3. WebSocketCompression 8
+
+4. RPC framework. 9
+
+4.1. Introduction 9
+4.2. Message structures for different message types 11
+4.3. RPC Framework Error Codes 14
+4.4. Extension fallback mechanism 14
+
+5. Connection 15
+
+5.1. Data integrity. 15
+5.2. WebSocket Ping in relation to OCPP Heartbeat 15
+5.3. Reconnecting 16
+5.4. Network node hierarchy 16
+
+6. OCPP Routing 17
+
+6.1. Local Controller 17
+6.2. Connections 17
+6.3. Connection loss 18
+6.4. Local Controller initiated messages 18
+6.5. Local Controller Security 18
+
+7. Signed Messages 20
+
+7.1. Signed Message Format 20
+7.2. Handling Signed Messages 20
+7.3. Allowed Algorithms 20
+7.4. Key Management 21
+
+8. Configuration 22
+
+8.1. RetryBackOffRepeatTimes 22
+8.2. RetryBackOffRandomRange 22
+8.3. RetryBackOffWaitMinimum 22
+8.4. WebSocketPingInterval 22
+
+9. CustomData Extension 24
+
+# 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
+
+<table><tr><td>Version</td><td>Date</td><td>Description</td></tr><tr><td>2.0.1 Edition 3</td><td>2024-05-06</td><td>OCPP 2.0.1 Edition 3. All errata from OCPP 2.0.1 Part 4 until and including Errata 2024-04 have been merged into this version of the specification.</td></tr><tr><td>2.0.1</td><td>2020-03-31</td><td>Final version of OCPP 2.0.1</td></tr><tr><td>2.0</td><td>2018-04-11</td><td>OCPP 2.0 April 2018
+Update for 2.0
+Section added for OCPP Routing and Signed Messages</td></tr><tr><td>1.6</td><td>2015-10-08</td><td>Updated to 1.6
+Asciidoc formatting, remove JSON schema for 1.5
+Some clarification
+Added 1.6 json schema</td></tr></table>
+
+# 1. Introduction
+
+# 1.1. Purpose of this document
+
+The purpose of this document is to give the reader the information required to create a correct interoperable OCPP JSON implementation (OCPP-J). We will try to explain what is mandatory, what is considered good practice and what one should not do, based on our own experience. Undoubtedly misunderstandings or ambiguities will remain but by means of this document we aim to prevent them as much as possible.
+
+# 1.2. Intended audience
+
+This document is intended for developers looking to understand and/or implement OCPP JSON in a correct and interoperable way. Rudimentary knowledge of implementing web services on a server or embedded device is assumed.
+
+# 1.3. OCPP-S and OCPP-J
+
+With the introduction of OCPP 1.6, there were two different flavors of OCPP; SOAP and JSON. To avoid confusion in communication on the type of implementation we recommend using the distinct suffixes -J and -S to indicate JSON or SOAP. In generic terms this would be OCPP-J for JSON and OCPP-S for SOAP. Version specific terminology would be OCPP1.6J or OCPP1.2S. If no suffix is specified for OCPP 1.2 or 1.5 then a SOAP implementation must be assumed. As of release 1.6 this can no longer be implicit and should always be made clear. If a system supports both the JSON and SOAP variant it is considered good practice to label this OCPP1.6JS instead of just OCPP1.6.
+
+OCPP 2.0.1 only supports JSON, but it is preferable to keep using the -J designation. As a new transport mechanism might be introduced in a future version of OCPP. So it will be OCPP2.0.1J.
+
+# 1.4. Conventions
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
+
+# 1.5. Definitions & Abbreviations
+
+<table><tr><td>Abbreviation</td><td>Description</td></tr><tr><td>IANA</td><td>Internet Assigned Numbers Authority (www.iana.org).</td></tr><tr><td>OCPP-J</td><td>OCPP communication over WebSocket using JSON. Specific OCPP versions should be indicated with the J extension. OCPP2.0.1J means we are talking about a JSON/WebSocket implementation of 2.0.1.</td></tr><tr><td>OCPP-S</td><td>OCPP communication over SOAP and HTTP(S). As of version 1.6 this should explicitly mentioned. Older versions are assumed to be S unless clearly specified otherwise, e.g. OCPP1.5 is the same as OCPP1.5S</td></tr><tr><td>RPC</td><td>Remote procedure call</td></tr><tr><td>WAMP</td><td>WAMP is an open WebSocket subprotocol that provides messaging patterns to handle asynchronous data.</td></tr></table>
+
+# 1.6. References
+
+<table><tr><td>Reference</td><td>Description</td></tr><tr><td>[EMI3-BO]</td><td>"eMI3 standard version V1.0" http://emi3group.com/documents-links/</td></tr><tr><td>[OCPP2.0-PART2]</td><td>"OCPP 2.0.1: Part 2 - Specification". http://www.openchargealliance.org/downloads/</td></tr><tr><td>[RFC1951]</td><td>"DEFLATE Compressed Data Format Specification version 1.3". https://www.ietf.org/rfc/rfc1951</td></tr><tr><td>[RFC2119]</td><td>"Key words for use in RFCs to Indicate Requirement Levels". S. Bradner. March 1997. http://www.ietf.org/rfc/rfc2119.txt</td></tr><tr><td>[RFC2616]</td><td>"Hypertext Transfer Protocol – HTTP/1.1". http://tools.ietf.org/html/rfc2616</td></tr><tr><td>[RFC2617]</td><td>"HTTP Authentication: Basic and Digest Access Authentication". http://tools.ietf.org/html/rfc2617</td></tr><tr><td>[RFC3629]</td><td>"UTF-8, a transformation format of ISO 10646". http://tools.ietf.org/html/rfc3629</td></tr><tr><td>[RFC3986]</td><td>"Uniform Resource Identifier (URI): Generic Syntax". http://tools.ietf.org/html/rfc3986</td></tr><tr><td>[RFC5246]</td><td>"The Transport Layer Security (TLS) Protocol; Version 1.2". http://tools.ietf.org/html/rfc5246</td></tr><tr><td>[RFC6455]</td><td>"The WebSocket Protocol". http://tools.ietf.org/html/rfc6455</td></tr><tr><td>[RFC7515]</td><td>"JSON Web Signatures (JWS)". https://tools.ietf.org/html/rfc7515</td></tr><tr><td>[RFC7518]</td><td>"JSON Web Algorithms (JWA)". https://tools.ietf.org/html/rfc7518</td></tr><tr><td>[RFC7692]</td><td>"Compression Extensions for WebSocket". https://tools.ietf.org/html/rfc7692</td></tr><tr><td>[RFC8259]</td><td>"The JavaScript Object Notation (JSON) Data Interchange Format". T. Bray. December 2017. https://tools.ietf.org/html/rfc8259</td></tr><tr><td>[WAMP]</td><td>http://wamp.ws/</td></tr></table>
+
+# 2. Benefits & Issues
+
+The WebSocket protocol is defined in [RFC6455]. Working implementations of earlier draft WebSocket specifications exist, but OCPP-J implementations SHOULD use the protocol described in [RFC6455].
+
+Be aware that WebSocket defines its own message structure on top of TCP. Data sent over a WebSocket, on a TCP level, is wrapped in a WebSocket frame with a header. When using a framework this is completely transparent. When working for an embedded system however, WebSocket libraries may not be available and then one has to frame messages correctly according to [RFC6455] him/herself.
+
+# 3. WebSockets
+
+For the connection between a Charging Station and a Charging Station Management System (CSMS) using OCPP-J, the CSMS acts as a WebSocket server and the Charging Station acts as a WebSocket client.
+
+# 3.1. Client request
+
+To set up a connection, the Charging Station initiates a WebSocket connection as described in [RFC6455] section 4, "Opening Handshake".
+
+OCPP-J imposes extra constraints on the URL and the WebSocket subprotocol, detailed in the following two sections 4.1.1 and 4.1.2.
+
+The Client (Charging Station) SHALL keep this WebSocket connection open all the time.
+
+# 3.1.1. The connection URL
+
+To initiate a WebSocket connection, the Charging Station needs a URL ([RFC3986]) to connect to. This URL is henceforth called the "connection URL". This connection URL is specific to a Charging Station. The Charging Station's connection URL contains the Charging Station identity so that the CSMS knows which Charging Station a WebSocket connection belongs to. However it is RECOMMENDED to let the CSMS NOT solely rely on the connection URL to identify a Charging Station, but to double-check the Charging Station's identity against their authentication credentials.
+
+A CSMS supporting OCPP-J MUST provide at least one OCPP-J endpoint URL, from which the Charging Station SHOULD derive its connection URL. This OCPP-J endpoint URL can be any URL with a "ws" or "wss" scheme. How the Charging Station obtains an OCPP-J endpoint URL is outside of the scope of this document.
+
+To derive its connection URL, the Charging Station modifies the OCPP-J endpoint URL by appending to the path first a '/' (U+002F SOLIDUS) and then a string uniquely identifying the Charging Station. This uniquely identifying string has to be percent-encoded as necessary as described in [RFC3986].
+
+Example 1: for a Charging Station with identity "CS001" connecting to a CSMS with OCPP-J endpoint URL
+
+"ws://csms.example.com/ocpp" this would give the following connection URL:
+
+ws://csms.example.com/ocpp/CS001
+
+Example 2: for a Charging Station with identity "RDAM 123" connecting to a CSMS with OCPP-J endpoint URL
+
+"wss://csms.example.com/ocppj" this would give the following URL:
+
+wss://csms.example.com/ocppj/RDAM%20123
+
+The Charging Station identity datatype is identifierString (For definition see [OCPP2.0.1-PART2] Additionally the colon": character might not be used, because the unique identifier is also used for the basic authentication username. The colon": character is used to separate the basic authentication username and the password. The maximum length of the Charging Station identity is: 48 (Note: Maximum length was chosen to ensure compatibility with EVSE ID from [EMI3-B0] "Part 2: business objects."
+
+# 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 1.OCPP Versions
+
+<table><tr><td>OCPP version</td><td>WebSocket subprotocol name</td></tr><tr><td>1.2</td><td>ocpp1.2</td></tr><tr><td>1.5</td><td>ocpp1.5</td></tr><tr><td>1.6</td><td>ocpp1.6</td></tr><tr><td>2.0</td><td>ocpp2.0</td></tr><tr><td>2.0.1</td><td>ocpp2.0.1</td></tr></table>
+
+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.
+
+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.
+
+# 3.1.3. Example of an opening HTTP request
+
+The following is an example of an opening HTTP request of an OCPP-J connection handshake:
+
+GET /webServices/ocpp/CS3211 HTTP/1.1
+
+Host: some.server.com:33033
+
+Upgrade: websocket
+
+Connection: Upgrade
+
+Sec-WebSocket-Key: x3JJHMdbDL1EzLkh9GBhXDw==
+
+Sec-WebSocket-Protocol: ocpp2.0.1, ocpp1.6
+
+Sec-WebSocket-Version: 13
+
+The bold parts are found as such in every WebSocket handshake request, the other parts are specific to this example.
+
+In this example, the CSMS's OCPP-J endpoint URL is "ws://some.server.com:33033/webServices/ocpp". The Charging Station's unique identifier is "CS3211", so the path to request becomes "webServices/ocpp/CS3211".
+
+With the Sec-WebSocket-Protocol header, the Charging Station indicates here that it can use OCPP2.0.1J and OCPP1.6J, with a preference for the former.
+
+The other headers in this example are part of the HTTP and WebSocket protocols and are not relevant to those implementing OCPP-J on top of third-party WebSocket libraries. The roles of these headers are explained in [RFC2616] and [RFC6455].
+
+# 3.2. Server response
+
+Upon receiving the Charging Station's request, the CSMS has to finish the handshake with a response as described in [RFC6455].
+
+The following OCPP-J-specific conditions apply:
+
+- If the CSMS does not recognize the Charging Station identifier in the URL path, it SHOULD send an HTTP response with status 404 and abort the WebSocket connection as described in [RFC6455].
+- If the CSMS does not agree to using one of the subprotocols offered by the client, it MUST complete the WebSocket handshake with a response without a Sec-WebSocket-Protocol header and then immediately close the WebSocket connection.
+
+So if the CSMS accepts the above example request and agrees to using OCPP 2.0.1J with the Charging Station, the CSMS's response will look as follows:
+
+HTTP/1.1 101 Switching Protocols
+
+Upgrade: websocket
+
+Connection: Upgrade
+
+Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
+
+Sec-WebSocket-Protocol:ocpp2.0.1
+
+The bold parts are found as such in every WebSocket handshake response, the other parts are specific to this example.
+
+The role of the Sec-WebSocket-Accept header is explained in [RFC6455].
+
+The Sec-WebSocket-Protocol header indicates that the server will be using OCPP2.0.1J on this connection.
+
+For a definition on how a server SHALL report a 'failure to process the message', see: CALLERROR
+
+# 3.3. WebSocket Compression
+
+OCPP 2.0.1 supports RFC 7692: Compression Extensions for WebSocket see: [RFC6455]
+
+Table 2. WebSocket compression support requirement for devices
+
+<table><tr><td>Device</td><td>WebSocket Compression Support</td></tr><tr><td>Charging Station</td><td>Optional</td></tr><tr><td>CSMS</td><td>Required</td></tr><tr><td>Local Controller</td><td>Required</td></tr></table>
+
+OCPP Requires the CSMS (and Local Controller) to support RFC 7692, WebSocket compression is seen as a relative simple way to reduce mobile data usage. For a Charging Station this is not a hard requirement, as this might be more complex to implement on an embedded platform, but as this is seen as efficient solution to reduce mobile data usage, it is RECOMMENDED to be implemented on a Charging Station that uses a mobile data connection.
+
+OCPP Requires the CSMS (and Local Controller) to support RFC 7692, WebSocket compression is seen as a relative simple way to reduce mobile data usage. For a Charging Station this is not a hard requirement, as this might be more complex to implement on an embedded platform, but as this is seen as efficient solution to reduce mobile data usage, it is RECOMMENDED to be implemented on a Charging Station that uses a mobile data connection.
+
+RFC 7692 allows the Charging Station and the CSMS to do a negotiation during the connection setup. When both parties support the Compression Extension they will then use DEFLATE compression ([RFC1951]) when sending data over the line. When one of the parties doesn't support it, the JSON will be sent uncompressed (like in OCPP 1.6J).
+
+When the Charging Station detects that compression is not used, it is RECOMMENDED not to close the connection, as turning of compression can be very useful during development, testing and debugging.
+
+For more detailed information read the RFC 7692.
+
+# 4. RPC framework
+
+# 4.1. Introduction
+
+A WebSocket is a full-duplex connection, simply put a pipe where data goes in and data can come out and without a clear relation between in and out. The WebSocket protocol by itself provides no way to relate messages as requests and responses. To encode these request/response relations we need a small protocol on top of WebSocket. This problem occurs in more use cases of WebSocket so there are existing schemes to solve it. The most widely-used is WAMP (see [WAMP]) but with the current version of that framework handling RPCs symmetrically is not WAMP compliant. Since the required framework is very simple we decided to define our own framework, inspired by WAMP, leaving out what we do not need and adding what we find missing.
+
+Basically what we need is very simple: we need to send a message (CALL) and receive a reply (CALLRESULT) or an explanation why the message could not be handled properly (CALLERROR). For possible future compatibility we will keep the numbering of these message in sync with WAMP. Our actual OCPP message will be put into a wrapper that at least contains the type of message, a unique message ID and the payload, the OCPP message itself.
+
+# 4.1.1. Synchronicity
+
+A Charging Station or CSMS SHALL NOT send a CALL message to the other party unless all the CALL messages it sent before have been responded to or have timed out. This does not mean that the CSMS cannot send a message to another Charging Station, while waiting for a response of a first Charging Station, this rule is per OCPP-J connection. A CALL message has been responded to when a CALLERROR or CALLRESULT message has been received with the message ID of the CALL message.
+
+A CALL message has timed out when:
+
+- it has not been responded to, and
+- an implementation-dependent timeout interval has elapsed since the message was sent.
+
+Implementation are free to choose this timeout interval. It is RECOMMENDED that they take into account the kind of network used to communicate with the other party. Mobile networks typically have much longer worst-case round-trip times than fixed lines.
+
+# NOTE
+
+The above requirements do not rule out that a Charging Station or CSMS will receive a CALL message from the other party while it is waiting for a CALLERROR or CALLRESULT. Such a situation is difficult to prevent because CALL messages from both sides can always cross each other.
+
+# 4.1.2. Message validity and Character encoding
+
+The whole message consisting of wrapper and payload MUST be valid JSON encoded with the UTF-8 (see [RFC3629]) character encoding. Furthermore, the Charging Station and CSMS have the right to reject messages which are not conform the JSON schemas.
+
+Note that all valid US-ASCII text is also valid UTF-8, so if a system sends only US-ASCII text, all messages it sends comply with the UTF-8 requirement. Non US-ASCII characters SHOULD only be used for sending natural-language text. An example of such natural-language text is the MessageType which contains the text of a DisplayMessage in OCPP 2.0.1
+
+# 4.1.3. The message type
+
+To identify the type of message one of the following Message Type Numbers MUST be used.
+
+Table 3. Message types
+
+<table><tr><td>MessageType</td><td>Message Type Number</td><td>Description</td></tr><tr><td>CALL</td><td>2</td><td>Request message</td></tr><tr><td>CALLRESULT</td><td>3</td><td>Response message</td></tr><tr><td>CALLERROR</td><td>4</td><td>Error response to a request message</td></tr></table>
+
+When a server receives a message with a Message Type Number not in this list, it SHALL ignore the message payload. Each message type may have additional required fields.
+
+# 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 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.
+
+Table 4. Unique Message ID
+
+<table><tr><td>Name</td><td>Datatype</td><td>Restrictions</td></tr><tr><td>messageId</td><td>string[36]</td><td>Unique message ID, maximum length of 36 characters, to allow for UUIDs/GUIDs</td></tr></table>
+
+# 4.1.5. JSON Payload
+
+The Payload of a message is a JSON object containing the arguments relevant to the Action.
+
+If there is no payload JSON allows for two different notations: null or and empty object {}. Although it seems trivial, we consider it good practice to only use the empty object statement. Null usually represents something undefined, which is not the same as empty, and also {} is shorter.
+
+When a field is optional in the OCPP action (0..1 or 0..\*) and is left empty for a specific request/response, JSON allows for a couple of different ways to put this in a JSON string. But because OCPP is designed for wireless links, OCPP only allows 1 option: Do no put the field in the payload (so null, {} or [] are not allowed for an empty field).
+
+When a field has a cardinality of zero/one to many (0.._ or 1.._) and it has been given one entity, than it will still remain a list, but of size 1.
+
+# 4.1.6. Action
+
+The Action field in the CALL message MUST be the OCPP message name without the "Request" suffix.
+
+For example: For a "BootNotificationRequest" the action field will be set to "BootNotification".
+
+BTW: The CALLRESULT does not contain the action field. A client can match the Response (CALLRESULT) with the Request (CALL) via the Messaging field.
+
+# 4.1.7. Message Validity
+
+An message is only valid when:
+
+Action is a known Action.
+
+- The JSON payload is valid JSON
+- All the required field for the Action are present
+- All data is of the correct data type.
+
+When a message is not valid, the server SHALL respond with a CALLERROR
+
+# 4.2. Message structures for different message types
+
+# NOTE
+
+You may find the Charging Station identity missing in the following paragraphs. The identity is exchanged during the WebSocket connection handshake and is a property of the connection. Every message is sent by or directed at this identity. There is therefore no need to repeat it in each message.
+
+# 4.2.1. CALL
+
+A CALL always consists of 4 elements: The standard elements MessageTyped and Messaging, a specific Action that is required on the other side and a payload, the arguments to the Action. The syntax of a CALL looks like this:
+
+[ \langle MessageTypeId \rangle, \langle MessageId \rangle, \langle Action \rangle, \{ \langle Payload \rangle \} ]
+
+Table 5. CALL Fields
+
+<table><tr><td>Field</td><td>Datatype</td><td>Meaning</td></tr><tr><td>MessageTypel d</td><td>integer</td><td>This is a Message Type Number which is used to identify the type of the message.</td></tr><tr><td>Messageld</td><td>string[36]</td><td>This is a unique identifier that will be used to match request and result.</td></tr><tr><td>Action</td><td>string</td><td>The name of the remote procedure or action. This field SHALL contain a case-sensitive string. The field SHALL contain the OCPP Message name without the "Request" suffix. For example: For a "BootNotificationRequest", this field shall be set to "BootNotification".</td></tr><tr><td>Payload</td><td>JSON</td><td>JSON Payload of the action, see: JSON Payload for more information.</td></tr></table>
+
+For example, a BootNotificationRequest could look like this:
+
+```json
+[
+ 2,
+ "19223201",
+ "BootNotification",
+ {
+ "reason": "PowerUp",
+ "chargingStation": { "model": "SingleSocketCharger", "vendorName": "VendorX" }
+ }
+]
+```
+
+# 4.2.2. CALLRESULT
+
+If the call can be handled correctly the result will be a regular CALLRESULT. Error situations that are covered by the definition of the OCPP response definition are not considered errors in this context. They are regular results and as such will be treated as a normal CALLRESULT, even if the result is undesirable for the recipient.
+
+A CALLRESULT always consists of 3 elements: The standard elements MessageTyped and Messaging and a payload, containing the response to the Action in the original Call.
+
+The syntax of a CALLRESULT looks like this:
+
+[ \langle MessageTypeId \rangle, \langle MessageId \rangle, \{ \langle Payload \rangle \} ]
+
+Table 6. CALLRESULT Fields
+
+<table><tr><td>Field</td><td>Datatype</td><td>Meaning</td></tr><tr><td>MessageTypeld</td><td>integer</td><td>This is a Message Type Number which is used to identify the type of the message.</td></tr><tr><td>Messageld</td><td>string[36]</td><td>This must be the exact same ID that is in the call request so that the recipient can match request and result.</td></tr><tr><td>Payload</td><td>JSON</td><td>JSON Payload of the action, see: JSON Payload for more information.</td></tr></table>
+
+For example, a BootNotification response could look like this:
+
+```json
+[
+ 3,
+ "19223201",
+ { "currentTime": "2013-02-01T20:53:32.486Z", "interval": 300, "status": "Accepted" }
+]
+```
+
+# 4.2.3. CALLERROR
+
+We only use CALLERROR in two situations:
+
+1. An error occurred during the transport of the message. This can be a network issue, an availability of service issue, etc.
+2. The call is received but the content of the call does not meet the requirements for a proper message. This could be missing mandatory fields, an existing call with the same unique identifier is being handled already, unique identifier too long, invalid JSON or OCPP syntax etc.
+
+When a server needs to report a 'failure to process the message', the server SHALL use a Message Type:可能发生 (MessageTypeNumber = 4).
+
+When a server receives a corrupt message, the CALLERROR SHALL NOT directly include syntactically invalid JSON (For example, without encoding it first). When also the Messagingd cannot be read, the CALLERROR SHALL contain "-1" as Messagingd.
+
+When a message contains any invalid OCPP and/or it is not conform the JSON schema, the system is allowed to drop the message.
+
+A CALLERROR always consists of 5 elements: The standard elements MessageTyped and Messaging, an errorCode string, an errorDescription string and an errorDetails object.
+
+The syntax of a CALLERROR looks like this:
+
+[ \left[ \langle MessageTypeId \rangle, \langle MessageId \rangle, \langle ErrorCode \rangle, \langle ErrorDescription \rangle, \langle ErrorDetails \rangle \right] ]
+
+Table 7. CALLERROR Fields
+
+<table><tr><td>Field</td><td>Datatype</td><td>Meaning</td></tr><tr><td>MessageTypeld</td><td>integer</td><td>This is a Message Type Number which is used to identify the type of the message.</td></tr><tr><td>Messageld</td><td>string[36]</td><td>This must be the exact same id that is in the call request so that the recipient can match request and result.</td></tr><tr><td>ErrorCode</td><td>string</td><td>This field must contain a string from the RPC Framework Error Codes table.</td></tr><tr><td>ErrorDescription</td><td>string[255]</td><td>Should be filled in if possible, otherwise a clear empty string ""</td></tr><tr><td>ErrorDetails</td><td>JSON</td><td>This JSON object describes error details in an undefined way. If there are no error details you MUST fill in an empty object {}.</td></tr></table>
+
+For example, a CALLERROR could look like this:
+
+```json
+[4, "162376037", "NotSupported", "SetDisplayMessageRequest not implemented", {}]
+```
+
+# 4.3. RPC Framework Error Codes
+
+The following table contains all the allowed error codes for the OCPP RPC Framework.
+
+Table 8. Valid Error Codes
+
+<table><tr><td>ErrorCode</td><td>Description</td></tr><tr><td>FormatViolation</td><td>Payload for Action is syntactically incorrect</td></tr><tr><td>GenericError</td><td>Any other error not covered by the more specific error codes in this table</td></tr><tr><td>InternalError</td><td>An internal error occurred and the receiver was not able to process the requested Action successfully</td></tr><tr><td>MessageTypeNotSupported</td><td>A message with an Message Type Number received that is not supported by this implementation.</td></tr><tr><td>NotImplemented</td><td>Requested Action is not known by receiver</td></tr><tr><td>NotSupported</td><td>Requested Action is recognized but not supported by the receiver</td></tr><tr><td>OccurrenceConstraintViolation</td><td>Payload for Action is syntactically correct but at least one of the fields violates occurrence constraints</td></tr><tr><td>PropertyConstraintViolation</td><td>Payload is syntactically correct but at least one field contains an invalid value</td></tr><tr><td>ProtocolError</td><td>Payload for Action is not conform the PDU structure</td></tr><tr><td>RpcFrameworkError</td><td>Content of the call is not a valid RPC Request, for example: Messaging could not be read.</td></tr><tr><td>SecurityError</td><td>During the processing of Action a security issue occurred preventing receiver from completing the Action successfully</td></tr><tr><td>TypeConstraintViolation</td><td>Payload for Action is syntactically correct but at least one of the fields violates data type constraints (e.g. "somestring": 12)</td></tr></table>
+
+# 4.4. Extension fallback mechanism
+
+Future versions of OCPP might add extra Message Types (other then CALL, CALLRESULT and CALLERROR)
+
+When an OCPP 2.0.1 implementation receives a message with an unknown message type, it SHALL respond with an CALLERROR with errorCode: MessageTypeErrorSupported. This SHOULD notify the sending party about the not supported Message Type. The Sending Party SHALL then either terminate the connection, or fallback to the known: CALL, CALLRESULT and CALLERROR.
+
+# 5. Connection
+
+# 5.1. Data integrity
+
+For data integrity we rely on the underlying TCP/IP transport layer mechanisms.
+
+# 5.2. WebSocket Ping in relation to OCPP Heartbeat
+
+The WebSocket specification defines Ping and Pong frames that are used to check if the remote endpoint is still responsive. In practice this mechanism is also used to prevent the network operator from quietly closing the underlying network connection after a certain period of inactivity. This WebSocket feature can be used as a substitute for most of the OCPP Heartbeat messages, but cannot replace all of its functionality.
+
+An important aspect of the Heartbeat response is time synchronisation. The Ping and Pong frames cannot be used for this so at least one original Heartbeat message a day is recommended to ensure a correct clock setting on the Charging Station.
+
+# 5.3. Reconnecting
+
+When the connection is lost, the Charging Station SHALL try to reconnect. When reconnecting, the Charging Station SHALL use an increasing back-off time with some randomization until it has successfully reconnected. This prevents an overload of the CSMS when all Charging Stations reconnect after a restart of the CSMS.
+
+The first reconnection attempts SHALL be after a back-off time of: RetryBackOffWaitMinimum seconds, plus a random value with a maximum of RetryBackOffRandomRange seconds. After every failed reconnection attempt the Charging Station SHALL double the previous back-off time, with a maximum of RetryBackOffRepeatTimes, adding a new random value with a maximum of RetryBackOffRandomRange seconds to every reconnection attempt. After RetryBackOffRepeatTimes reconnection attempts, the Charging Station SHALL keep reconnecting with the last back-off time, not increasing it any further.
+
+When reconnecting, a Charging Station should not send a BootNotification unless one or more of the elements in the BootNotification have changed since the last connection. For the previous SOAP based solutions this was considered good practice but when using WebSocket the server can already make the match between the identity and a communication channel at the moment the connection is established. There is no need for an additional message.
+
+# 5.4. Network node hierarchy
+
+The physical network topology is not influenced by a choice for JSON or SOAP. In case of JSON however the issues with Network Address Translation (NAT) have been resolved by letting the Charging Station open a TCP connection to the CSMS and keeping this connection open for communication initiated by the CSMS. It is therefore no longer necessary to have a smart device capable of interpreting and redirecting SOAP calls in between the CSMS and the Charging Station.
+
+# 6. OCPP Routing
+
+For some topologies it is required to route OCPP-J messages. For example when implementing a Local Controller.
+
+This section contains a solution for OCPP message routing that will work with any Charging Station and CSMS.
+
+# 6.1. Local Controller
+
+A Local controller is a device that sits between the CSMS and any number of Charging Stations, creating a local group. It is located near to the Charging Station (maybe even connected wired to the Charging Stations), so it does not have problem of losing the connection to the Charging Stations. This is practically useful for doing Local Smart Charging: load balancing between the Charging Stations on the same location. The Local Controller can see all the messages, ongoing transactions etc. It can send charging profiles to the Charging Station to influence the energy used by the Charging Stations, this way preventing the group to use more energy than available at the location at that time.
+
+The Local Controller SHALL work so the Charging Station doesn't have to behave different when connected to the Local Controller, compared to a direct connection to a CSMS. A Local Controller SHALL work so that a Charging Station can work out of the box with the Local Controller, requiring only the parameters that are needed to connect to the Local Controller to be set. The Local Controller SHALL work so that the CSMS can not notice if the Charging Station is connecting to it directly, or via the Local Controller.
+
+
+Figure 1. Local Controller Topology
+
+# 6.2. Connections
+
+For each Charging Station that connects to the Local Controller, two connections will be established:
+
+1. A WebSocket connection from the Charging Station to the Local Controller (configured in the Charging Station)
+2. A WebSocket connection from the Local Controller to the CSMS (configured in the Local Controller)
+
+Both connections should use a similar connection URI with the same Charging Station identifier. To the CSMS, the connection from the Local Controller appears to be a regular Charging Station connection.
+
+The Local Controller may open a separate WebSocket connection to the CSMS that allows the CSMS to address the Local Controller directly, which may be useful for changing settings or setting overall Charging Profiles.
+
+When a Charging Station connects to the Local Controller, it SHALL connect to it like it would to a CSMS, using the same URI Path in the connection URL as it would use to connect to the CSMS. When the connection between Charging Station and the CSMS is successfully set up, the Local Controller SHALL set up a WebSocket connection to the CSMS with the same URI Path in the connection URL that was used by the Charging Station to setup the connection. The Local Controller SHALL open a WebSocket connection for every Charging Station that connects to it.
+
+
+Figure 2. Local Controller WebSocket Connections
+
+# 6.3. Connection loss
+
+Whenever one or more WebSocket connections between CSMS and the Local Controller are lost, the Local Controller SHALL close all corresponding WebSocket to the Charging Stations that are connected to it. This is needed to force the Charging Station to queue messages as it would have done if it would have been connected to the CSMS directly and would have lost the connection to that CSMS.
+
+Whenever the connection between a Charging Station and the Local Controller is lost, the Local Controller SHALL close the WebSocket connection it has for the Charging Station to the CSMS. This is needed to let the CSMS know the Charging Station is offline and no CSMS initiated messages can be sent to it.
+
+# 6.4. Local Controller initiated messages
+
+The Local Controller SHALL relay any Charging Station initiated message to the CSMS (and vice versa).
+
+Since the Local Controller can also initiate its own messages to the Charging Station(s), a Local Controller SHALL take care of the following:
+
+1. If a Local Controller sends its own messages to a Charging Station, it SHALL guarantee that its messages have IDs that do not collide with IDs used by the CSMS, now and in the future. This can be done by either assigning a range of numbers to the Local Controller to use (and the CSMS to skip), or by using UUIDs/GUIDs.
+2. Replies to messages from the Charging Station to messages initiated by the Local Controller SHALL NOT be sent to the CSMS.
+
+# 6.5. Local Controller Security
+
+For the local controller, the normal OCPP security mechanisms will be used, as described in [OCPP2.0.1-PART2], part A. Security. All security profiles described there MAY be used when a Local Controller is deployed. The security section (part A) only describes the roles of the CSMS, and Charging Station. When a local controller is used, the security specification SHALL be interpreted as follows:
+
+- In the connection from the Charging Station to the Local Controller, the Charging Station SHALL act as the Charging Station, and the Local Controller SHALL act as the CSMS. When TLS is used, the Local Controller SHALL be the TLS server, and the Charging Station SHALL be the TLS client.
+- In the connection from the Local Controller to the CSMS, the Local Controller SHALL act as the Charging Station, and the CSMS SHALL acts as the CSMS. When TLS is used, the CSMS SHALL be the TLS server, and the Local Controller SHALL be the TLS client.
+
+When TLS with Client Side Certificates is used, the Local Controller SHALL have both a CSMS Certificate, and a Charging Station certificate (see [OCPP2.0.1-PART2] Part A - Keys used in OCPP), as it can function in both roles. These certificates SHALL be unique to the Local Controller. The Local Controller SHALL NOT store the Charging Station certificates of the attached Charging Stations. It SHALL also NOT store the CSMS Certificate of the CSMS. These certificates SHALL be kept private on their respective owners. The Local Controller SHALL only use its own certificates for setting up the TLS connections.
+
+It SHALL be possible to distinguish the Local Controller from the CSMS based on the URL in the CSMS Certificate. Because the Local Controller is placed in the field, there is a risk that its certificates get stolen from it, e.g. by an attack on the hardware. In that case, it SHALL only be possible to use the CSMS Certificate on the Local Controller to communicate with the attached Charging Stations, not with any other Charging Stations in the infrastructure.
+
+The TLS connections terminate on the Local Controller. So, the Local Controller can both read and manipulate data sent between
+
+the CSMSs and Charging Stations. If the security of the Local Controller is compromised, it will affect all attached Charging Stations. It is therefore RECOMMENDED to take sufficient security measures to protect the Local Controller. It is also RECOMMENDED to sign critical commands or replies with the mechanism described in Signed Messages. In this way, it can be detected if the Local Controller tries to manipulate data.
+
+# 7. Signed Messages
+
+For certain architectures it can be useful to use signed OCPP messages. This gives the Charging Station and the CSMS the ability to guarantee that messages are sent by the other party. For example when a Local Controller is involved, the Charging Station can know that a message received from the Local Controller is created and signed by the CSMS.
+
+Message signing can also be used when forwarding data from the Charging Station or the CSMS to 3th parties such as a DSO (Distribution System Operator).
+
+Because message signing is not needed in all architectures and scenarios, it is not required for all OCPP implementations. It will depend on the security requirements if this is required.
+
+This section defines a method to digitally sign any OCPP-J message. For each normal OCPP message an equivalent signed message is defined that encapsulates the normal message, and adds a digital signature.
+
+# 7.1. Signed Message Format
+
+For Signed OCPP Messages, JWS is used. For more information see: [RFC7515].
+
+Suppose we have an OPC calls encoded in the OCPP-J message:
+
+[ \langle MessageTypeId \rangle, \langle MessageId \rangle, \{ \langle Extension \rangle \}, \{ \langle Payload \rangle \} ]
+
+Then we define the equivalent signed message as follows.
+
+[ \left[ <\text{MessageTypeId}>, "<\text{MessageId}>", \{\langle\text{Extension}\rangle\}, "<\text{SignedAction}>", \{\langle\text{SignedPayload}\rangle\} \right] ]
+
+The MessageTyped and Messagingd SHALL stay the same. The <SignedAction> field SHALL be the action name (<Action>) with the string "-Signed" appended. For instance, if "<Action>" is "BootNotification", then "<SignedAction>" is "BootNotification-Signed". The <SignedPayload> SHALL be the JWS encoding of the payload, computed according to the following settings:
+
+- The JWS Payload SHALL be the <Payload> from the original message.
+- The JWS Protected Header SHALL contain a field called "OCPPAction" containing the name (<Action>) of the OCPP action, and a field called "OCPPMessageTypedId" containing the message ID (<MessageTyped>).
+- The JWS Protected Header SHOULD contain the x5t#S256 field to identify the key used for signing, as specified in Section 7.4.
+- The <SignedPayload> SHALL be encoded using the Flattened JWS JSON Serialization syntax.
+
+# 7.2. Handling Signed Messages
+
+When a Charging Station or CSMS receives a signed message, it SHALL extract the encapsulated normal message. It SHALL process it normally, following the OCPP 2.0.1 standard. It MAY perform additional actions that use the digital signature. This is optional, because a secure connection between the CSMS and the Charging Station is expected, hence a second process to validate a signature on message level is redundant. When a Charging Station receives a signed request, and it supports digital signing, it SHALL send a signed reply.
+
+# 7.3. Allowed Algorithms
+
+The algorithms allowed for use with JSON Web Signatures are defined in the JSON Web Algorithms standard [RFC7518]. To limit the cryptographic algorithms that a Charging Station has to implement, for OCPP the same algorithms SHALL be used as for the TLS connection used to secure communications. This means that for generating the digital signatures, the Charging Station and CSMS SHALL use the following algorithms from the JSON Web Algorithms standard [RFC7518], section 3.1:
+
+- ES256: ECDSA using P-256 and SHA-256
+- RS256: RSASSA-PKCS1-v1_5 using SHA-256
+- RS384: RSASSA-PKCS1-v1_5 using SHA-384
+
+Note that RS256 and ES256 are the algorithms recommended by [RFC7518].
+
+# 7.4. Key Management
+
+This section does not prescribe specific keys to be used for digital signatures. The CSMS Certificate and Charging Station Certificate, used for setting up a secure TLS connection, MAY be used for signing. For many use cases, these will however not be the correct keys. For instance, if the use case is to provide non-repudiation of meter readings, the messages should be signed with a certificate stored in the calibrated measuring chip.
+
+To be able to verify the digital signature, one needs to know which key was used to sign it. JSON Web Signatures supports several ways to store a key identifier with the signed message. As the certificates that can be used for signing are not specified, hash values will be used to identify them. Within the OCPP, the Charging Station and CSMS SHOULD include the field x5t#S256 in the JWS Protected Header to identify the certificate. Following the JSON Web Signatures standard [RFC7515] the value of this field SHOULD be set to the SHA-256 hash of the DER encoding of the signing certificate. How stakeholders can look up the certificate based on the hash value is out of scope for this document.
+
+# NOTE
+
+In the set up with a Local Controller, described in Local Controller, the TLS client key that would be signing messages to the CSMS will, in fact, not be the TLS client key that the TLS connection is using, since the key in the Local Controller is different from that in the Charging Station. Similarly, the TLS server key signing messages will be that of the CSMS, not that of the local controller. Therefore, implementation of the protocol MUST NOT regard this mismatch as invalidating the signatures; in fact, it is an expected and desired property to provide end-to-end authenticity.
+
+# 8. Configuration
+
+The following Configuration Variables are added to control JSON/WebSockets behaviour:
+
+# 8.1. RetryBackOffRepeatTimes
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>名字</td><td colspan="2">RetryBackOffRepeatTimes</td></tr><tr><td>name</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>Attributes</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When the Charging Station is reconnecting, after a connection loss, it will use this variable for the amount of times it will double the previous back-off time. When the maximum number of increments is reached, the Charging Station keeps connecting with the same back-off time.</td></tr></table>
+
+# 8.2. RetryBackOffRandomRange
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">RetryBackOffRandomRange</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When the Charging Station is reconnecting, after a connection loss, it will use this variable as the maximum value for the random part of the back-off time. It will add a new random value to every increasing back-off time, including the first connection attempt (with this maximum), for the amount of times it will double the previous back-off time. When the maximum number of increments is reached, the Charging Station will keep connecting with the same back-off time.</td></tr></table>
+
+# 8.3. RetryBackOffWaitMinimum
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">RetryBackOffWaitMinimum</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When the Charging Station is reconnecting, after a connection loss, it will use this variable as the minimum back-off time, the first time it tries to reconnect.</td></tr></table>
+
+# 8.4. WebSocketPingInterval
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">WebSocketPingInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td>A value of 0 disables client side websocket Ping / Pong. In this case there is either no ping / pong or the server initiates the ping and client responds with Pong.
+Positive values are interpreted as number of seconds between pings.
+Negative values are not allowed, SetConfiguration is then expected to return a Rejected result.
+It is recommended to configure WebSocketPingInterval smaller then: MessageAttemptsTransactionEvent * MessageAttemptIntervalTransactionEvent. This will limit the chance of the resend mechanism for transaction-related messages being triggered by connectivity issues.</td></tr></table>
+
+# 9. CustomData Extension
+
+In the JSON schema files all classes have the attribute additionalProperties set to false, such that a JSON parser will not accept any other properties in the message. In order to allow for some flexibility to create non-standard extensions for experimentation purposes, every JSON class has been extended with a "customData" property. This property is of type "CustomDataType", which has only one required property: "vendorld", which is used to identify the kind of customization. However, since it does not have additionalProperties set to false it can be freely extended with new properties.
+
+In the same way as is defined for the DataTransfer message, the "vendorId" should be a value from the reversed DNS namespace, where the top tiers of the name, when reversed, should correspond to the publicly registered primary DNS name of the Vendor organization.
+
+The following example shows the "CustomDataType" definition and the (optional) "customData" property in the schema definition of HeartbeatRequest:
+
+```json
+{
+"\$"schema": "http://json-schema.org/draft-06-schema#" ,
+"\$"id": "HeartbeatRequest",
+"definitions": {
+"CustomDataType": {
+"description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+"dataType": "CustomDataType",
+"type": "object",
+"properties": {
+"vendorId": {
+"type": "string",
+"maxLength": 255 } },
+"required": [ "vendorId" ] } } ,
+"type": "object",
+"additionalProperties": false,
+"properties": {
+"customData": {
+"\$"ref": "#/definitions/CustomDataType" } } } }
+```
+
+Whereas the standard HeartbeatRequest has an empty body, a customized version, that provides the value of the main meter and a count of all sessions to date, could look like this:
+
+```json
+{
+ "customData": {
+ "vendorId": "com.mycompany.customheartbeat",
+ "mainMeterValue": 12345,
+ "sessionsToDate": 342
+ }
+}
+```
+
+A CSMS that has implemented this extension, identified by its "vendorId", will be able to process the data. Other CSMS
+
+implementations will simply ignore these custom properties.
+
+A CSMS can request a report of the CustomizationCtrlr component to get a list of all customizations that are supported by the Charging Station.
--- /dev/null
+# OCPP
+
+# Table of Contents
+
+Disclaimer 1
+
+Version History 2
+
+1. Introduction & Reading Guide 3
+
+2. Certification profiles 4
+
+3. Features. 6
+
+3.1. Optional feature list for charging station 7
+3.2. Optional feature list for CSMS 10
+
+4. List of test cases 12
+
+4.1. Introduction 12
+4.2. Test Cases Core 12
+4.3. Test Cases Advanced Security 33
+4.4. Test Cases Local Authorization List Management 34
+4.5. Test Cases Smart Charging 36
+4.6. Test Cases Advanced Device Management 38
+4.7. Test Cases Reservation 40
+4.8. Test Cases Advanced User Interface 42
+4.9. Test Cases ISO 15118 Support. 44
+
+5. OCPP 2.0.1 Mandatory Controller components per profile. 47
+
+6. Appendix A: additional questions for the Protocol Implementation Conformance Statement 48
+
+6.1. Questions for Charging Stations 48
+6.2. Questions for CSMSs 48
+
+7. Appendix B: Hardware feature set 49
+8. Appendix C: Features vs. OCPP use cases 50
+
+# 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
+
+<table><tr><td>Version</td><td>Date</td><td>Description</td></tr><tr><td>2.0.1 Edition 3</td><td>2024-05-06</td><td>OCPP 2.0.1 Edition 3. All errata from OCPP 2.0.1 Part 5 until and including Errata 2024-04 have been merged into this version of the specification. In this edition all certification profiles are available.</td></tr><tr><td>2.0.1</td><td>2023-06-30</td><td>Release for Core & Advanced Security</td></tr></table>
+
+# 1. Introduction & Reading Guide
+
+This document describes the certification profiles for OCPP 2.0.1. These profiles are sets of use cases that can be certified via the Open Charge Alliance. This document contains the details on what is part of the OCPP 2.0.1 Certification. This document contains:
+
+- The certification profiles and an overview of the functionality per profile.
+- The list of optional features. This list contains specific functionality that is not mandatory for certification, but which can optionally be certified.
+- The list of test cases for each of the certification profiles.
+- The overview of the controller components that must be implemented per profile for certification testing.
+
+For clarity: in the context of the OCPP Certification Program, the term test case refers to a sequence of messages for testing a use case from OCPP. The term feature refers to a functionality, that can be tested with one or more test cases (see Features for a more detailed explanation). Instead of making specific test cases mandatory or optional, the certification program for OCPP 2.0.1 works with features that are optional. Depending on whether the System Under Test (SUT) has implemented a feature, the test case(s) that belong to this feature, must be successfully passed or not.
+
+
+Figure 1. Link between different OCPP Documents in OCPP Certification Program
+
+# 2. Certification profiles
+
+The OCPP protocol has been designed to support a wide variety of charging stations ranging from simple AC home chargers to advanced DC hyperchargers and megawatt chargers. It will be obvious that these charging stations and associated CSMSs will have very different capabilities. As a result it does not make sense to require every vendor to certify for the full OCPP functionality, when only subset is needed for the specific application.
+
+The OCPP certification is built around certification profiles that describe a set of supported functions. A full OCPP certification comprises all certification profiles, but it is possible to get certified for a subset, since not all OCPP functionality may be needed for some vendors.
+
+The OCPP "Core" profile must always be present. It contains the basic OCPP functionality. On top of that other profiles can be added to the certification. These profiles are independent of each other, the only exception being the "ISO 15118 support" profile, which requires a number of "Advanced security" and "Smart charging" test cases to be implemented.
+
+The following table lists the certification profiles and an overview of the functionality per profile:
+
+Table 1. Certification profiles
+
+<table><tr><td>Certification Profile</td><td>Description</td></tr><tr><td>Core</td><td>Basic AuthenticationTLS - server-side certificateUpdate Charging Station Password for HTTP Basic AuthenticationSecurity Event NotificationBooting a Charging StationConfiguring a Charging StationResetting a Charging Station / EVSEAuthorization incl. GroupIdStop Transaction with a Master PassLocal start transaction - Cable plugin first & Authorization firstStart / Stop transaction optionsDisconnect cable on EV-sideCheck Transaction statusRemote start / stop transactionRemote unlock ConnectorRemote TriggerChange Availability - Charging Station / EVSE / ConnectorClock-aligned Meter & Sampled Meter ValuesInstall CA certificatesRetrieve certificates from Charging StationDelete a certificate from a Charging StationAdditionalRootCertificateCheckRetrieve Log InformationGet / Clear Customer InformationSecure Firmware UpdateStore / Clear Authorization Data in Authorization CacheAuthorization through authorization cache</td></tr><tr><td>Advanced Security</td><td>TLS - Client-side certificateUpdate Charging Station CertificateUpgrade Charging Station Security Profile</td></tr><tr><td>Local Authorization List Management</td><td>Authorization through local authorization listSend Local Authorization ListGet Local List Version</td></tr><tr><td>Smart Charging</td><td>Set charging profileRemote start transaction with charging profileGet Composite ScheduleGet Charging ProfileClear Charging Profile</td></tr><tr><td rowspan="7">Advanced Device Management</td><td>Get Monitoring report</td></tr><tr><td>Set Monitoring Base</td></tr><tr><td>Set Variable Monitoring</td></tr><tr><td>Set Monitoring Level</td></tr><tr><td>Get Custom Report</td></tr><tr><td>Clear / Remove Monitoring</td></tr><tr><td>Event Notification</td></tr><tr><td rowspan="7">Advanced User Interface</td><td>Set Display Message</td></tr><tr><td>Get Display Message</td></tr><tr><td>Clear a Display Message</td></tr><tr><td>Show EV Driver Running / Final Total Cost During / After Charging</td></tr><tr><td>Show EV Driver-specific Tariff Information</td></tr><tr><td>Update Tariff Information During Transaction</td></tr><tr><td>Configure Fallback Tariff Information & Total Cost Message</td></tr><tr><td rowspan="5">Reservation</td><td>Reserve a specific EVSE</td></tr><tr><td>Reserve an unspecified EVSE</td></tr><tr><td>Reserve a connector with a specific type</td></tr><tr><td>Reservations using GroupIdToken</td></tr><tr><td>Cancel reservation of an EVSE</td></tr><tr><td rowspan="18">ISO 15118 support</td><td>ISO 15118 Certificate Management:</td></tr><tr><td>Update Charging Station Certificate</td></tr><tr><td>(Check) Certificate Installation / Update EV</td></tr><tr><td>Get Certificate Status</td></tr><tr><td>Install V2G / MO CA certificates</td></tr><tr><td>Retrieve V2G / MO certificates from Charging Station</td></tr><tr><td>Delete a certificate from a Charging Station</td></tr><tr><td>ISO 15118 EIM / PnC Authorization:</td></tr><tr><td>Authorization using External Identification Means</td></tr><tr><td>Authorization using Contract Certificates</td></tr><tr><td>ISO 15118 Smart Charging:</td></tr><tr><td>Set charging profile</td></tr><tr><td>Remote start transaction with charging profile</td></tr><tr><td>Get Composite Schedule</td></tr><tr><td>Get Charging Profile</td></tr><tr><td>Clear Charging Profile</td></tr><tr><td>Renegotiating a Charging Schedule</td></tr><tr><td>ISO 15118 signed meter values</td></tr></table>
+
+# 3. Features
+
+The concept of certification profiles is not enough to cover the variety in OCPP implementations. The OCPP specification contains many optional features, often in the form of optional message fields or configuration variables, that a vendor can use to support advanced functions. Whereas the certification profiles determine which OCPP functionality is implemented, the features describe how much of a certain functionality in a profile has been implemented.
+
+The OCTT test tool uses the features to determine which test cases have to be executed for a charging station or CSMS. For example, the set of TxStartPoints that a charging station supports, has a big impact on the execution of certain test cases. The behavior of a charging station that starts a transaction based on a successful authorization is different from a charging station that starts a transaction as soon as a cable is connected. Similarly, a CSMS that only controls DC fast chargers will not need functionality to unlock a cable at the charging station. For such a CSMS the vendor may decide to not implement the feature Support for unlocking connector.
+
+In most cases a feature corresponds the existence of a configuration variable or its value.
+
+# 3.1. Optional feature list for charging station
+
+The following table lists the optional features. These are features that are not mandatory to implement within a certification profile. Where applicable the associated configuration variable is mentioned in parenthesis.
+
+Table 2. Optional features for charging stations
+
+<table><tr><td>Id</td><td>Feature</td><td>Charging Station</td></tr><tr><td colspan="3">Core</td></tr><tr><td>C-01</td><td>Support for offline authorization of transactions</td><td>Optional. Supporting this feature depends on whether at least one of the following is supported; - Certification Profile: Local Authorization List Management - C-02: Support for allowing offline authorization for unknown ids - C-49: Authorization Cache (AuthCacheEnabled)</td></tr><tr><td>C-02</td><td>Support for allowing Offline Authorization for Unknown Ids (OfflineTxForUnknownIdEnabled)</td><td>Optional</td></tr><tr><td>C-03</td><td>Support for maximizing energy for invalid ids (MaxEnergyOnInvalidId)</td><td>Optional</td></tr><tr><td>C-04</td><td>Support to limit StatusNotifications (MinimumStatusDuration)</td><td>Optional</td></tr><tr><td>C-06</td><td>Authorization status after cable disconnected on EV side (StopTxOnEVSideDisconnect)</td><td>(At least one of the suboptions below is required)</td></tr><tr><td>C-06.1</td><td>Support for maintaining authorization when cable disconnected on EV side</td><td>Optional</td></tr><tr><td>C-06.2</td><td>Support for not maintaining authorization when cable disconnected on EV side</td><td>Optional</td></tr><tr><td>C-07</td><td>Support for using a Master Pass for charging stations with UI (MasterPassGroupld)</td><td>Optional</td></tr><tr><td>C-08</td><td>Support for using a Master Pass for charging stations without UI (MasterPassGroupld)</td><td>Optional</td></tr><tr><td>C-09</td><td>Supported Transaction Start points (TxStartPoint)</td><td>(At least one of the suboptions below is required)</td></tr><tr><td>C-09.1</td><td>Start transaction options - EVConnected</td><td>Optional</td></tr><tr><td>C-09.2</td><td>Start transaction options - Authorized</td><td>Optional</td></tr><tr><td>C-09.3</td><td>Start transaction options - DataSigned</td><td>Optional</td></tr><tr><td>C-09.4</td><td>Start transaction options - PowerPathClosed</td><td>Optional</td></tr><tr><td>C-09.5</td><td>Start transaction options - EnergyTransfer</td><td>Optional</td></tr><tr><td>C-09.6</td><td>Start transaction options - ParkingBayOccupancy</td><td>Optional</td></tr><tr><td>C-10</td><td>Supported Transaction Stop points (TxStopPoint)</td><td>(At least one of the suboptions below is required)</td></tr><tr><td>C-10.1</td><td>Stop transaction options - EVConnected</td><td>Optional</td></tr><tr><td>C-10.2</td><td>Stop transaction options - Authorized</td><td>Optional</td></tr><tr><td>C-10.3</td><td>Stop transaction options - PowerPathClosed</td><td>Optional</td></tr><tr><td>C-10.4</td><td>Stop transaction options - EnergyTransfer</td><td>Optional</td></tr><tr><td>C-10.5</td><td>Stop transaction options - ParkingBayOccupancy</td><td>Optional</td></tr><tr><td>C-12</td><td>Unlocking of connector when cable disconnected on EV side (UnlockOnEVSideDisconnect)</td><td>(At least one of the suboptions below is required)</td></tr><tr><td>C-12.1</td><td>Support for unlocking connector when cable disconnected on EV side</td><td>Optional</td></tr><tr><td>C-12.2</td><td>Support for not unlocking when cable disconnected on EV side</td><td>Optional</td></tr><tr><td>C-13</td><td>Support for Reset per EVSE (AllowReset)</td><td>Optional</td></tr><tr><td>C-14</td><td>Support for retrieving / deleting CustomerInformation - CustomerIdentifier</td><td>Optional</td></tr><tr><td>C-20</td><td>Allowing New Sessions Pending a FirmwareUpdate (AllowNewSessionsPendingFirmwareUpdate)</td><td>Optional</td></tr><tr><td>C-21</td><td>Support for queuing all or only Transaction related messages until they are delivered to the CSMS (QueueAllMessages)</td><td>Optional</td></tr><tr><td colspan="3">Time related settings</td></tr><tr><td>C-23</td><td>Supported time sources (TimeSource)</td><td>{list} at least Heartbeat</td></tr><tr><td>C-25</td><td>Support for setting a TimeOffset (TimeOffset)</td><td>Optional</td></tr><tr><td>C-26</td><td>Support for setting the TimeZone (TimeZone)</td><td>Optional</td></tr><tr><td>C-28</td><td>Toggle sending clock aligned meter values when a transaction is ongoing / Idle(AlignedDataSendDuringIdle)</td><td>Optional</td></tr><tr><td>C-29</td><td>TriggerMessage</td><td>(Select all supportedsuboptions)</td></tr><tr><td>C-29.1</td><td>Trigger message - MeterValues</td><td>Optional</td></tr><tr><td>C-29.2</td><td>Trigger message - TransactionEvent</td><td>Optional</td></tr><tr><td>C-29.3</td><td>Trigger message - LogStatusNotification</td><td>Optional</td></tr><tr><td>C-29.4</td><td>Trigger message - FirmwareStatusNotification</td><td>Optional</td></tr><tr><td>C-29.5</td><td>Trigger message - StatusNotification</td><td>Optional</td></tr><tr><td>C-29.6</td><td>Trigger message - BootNotification</td><td>Optional</td></tr><tr><td colspan="3">Authorization options for local start</td></tr><tr><td>C-30</td><td>Authorization - using RFID ISO14443</td><td>Optional</td></tr><tr><td>C-31</td><td>Authorization - using RFID ISO15693</td><td>Optional</td></tr><tr><td>C-32</td><td>Authorization - using KeyCode</td><td>Optional</td></tr><tr><td>C-33</td><td>Authorization - using locally generated id</td><td>Optional</td></tr><tr><td>C-34</td><td>Authorization - MacAddress</td><td>Optional</td></tr><tr><td>C-35</td><td>Authorization - NoAuthorization</td><td>Optional</td></tr><tr><td colspan="3">Authorization options for remote start (mandatory to support at least one)</td></tr><tr><td>C-36</td><td>Authorization - using RFID ISO14443</td><td>Optional</td></tr><tr><td>C-37</td><td>Authorization - using RFID ISO15693</td><td>Optional</td></tr><tr><td>C-38</td><td>Authorization - using centrally, in the CSMS (or other server) generated id</td><td>Optional</td></tr><tr><td>C-39</td><td>Authorization - NoAuthorization</td><td>Optional</td></tr><tr><td>C-40</td><td>Supported MeterValue Measurands</td><td></td></tr><tr><td>C-40.1</td><td>SampledTxStartedMeasurands</td><td>{list of supported} at least one</td></tr><tr><td>C-40.2</td><td>SampledTxUpdatedMeasurands</td><td>{list of supported} at least one</td></tr><tr><td>C-40.3</td><td>SampledTxEndedMeasurands</td><td>{list of supported} at least one</td></tr><tr><td>C-40.4</td><td>AlignedDataMeasurands</td><td>{list of supported} at least one</td></tr><tr><td>C-40.5</td><td>AlignedDataTxEndedMeasurands</td><td>{list of supported} at least one</td></tr><tr><td>C-41</td><td>Supported Cipher Suites</td><td>{list of cipher suites} → atleast one ofTLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384ORTLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_GCM_SHA384</td></tr><tr><td>C-42</td><td>Signed Metervalues (SampleDataSignReadings)</td><td>Optional</td></tr><tr><td>C-43</td><td>Install Firmware with ongoing transaction(s)</td><td>Optional</td></tr><tr><td>C-47</td><td>Support for falling back to default OCPP reconnection mechanism whenNetworkConnection profile connection has failed</td><td>Optional</td></tr><tr><td>C-48</td><td>Authorization of remote start (AuthorizationRemoteStart)</td><td>(At least one of the suboptionsbelow is required)</td></tr><tr><td>C-48.1</td><td>Option for authorization in case of a remote start</td><td>Optional</td></tr><tr><td>C-48.2</td><td>Option for no authorization in case of a remote start</td><td>Optional</td></tr><tr><td>C-58</td><td>Option for disabling remote authorization (DisableRemoteAuthorization)</td><td>Optional</td></tr><tr><td>C-49</td><td>Authorization Cache (AuthCacheEnabled)</td><td>Optional</td></tr><tr><td>C-59</td><td>Option for disabling remote authorization for cached invalid idTokens (AuthCacheDisablePostAuthorize)</td><td>Optional</td></tr><tr><td>C-51</td><td>Configurable TxStartPoint</td><td>Optional</td></tr><tr><td>C-52</td><td>Configurable TxStopPoint</td><td>Optional</td></tr><tr><td>C-53</td><td>Support for lifetime cached token (AuthCacheLifeTime)</td><td>Optional</td></tr><tr><td>C-54</td><td>Supported policies for replacing cached entries (AuthCachePolicy)</td><td>{ list of supported } at least one</td></tr><tr><td>C-56</td><td>Support for providing the SummaryInventory</td><td>Optional</td></tr><tr><td>C-57</td><td>Support for cancelling ongoing log file upload</td><td>Optional</td></tr><tr><td>C-60</td><td>Support for cancelling ongoing firmware update</td><td>Optional</td></tr><tr><td colspan="3">Advanced Security</td></tr><tr><td>AS-2</td><td>Additional root certificate check mechanism implemented (AdditionalRootCertificateCheck)</td><td>Optional</td></tr><tr><td>AS-3</td><td>Update Charging Station Certificate - CertificateSignedRequest Timeout (CertSigningWaitMinimum,CertSigningRepeatTimes)</td><td>Optional</td></tr><tr><td colspan="3">Smart Charging</td></tr><tr><td>SC-2</td><td>Supported charging rate units (ChargingScheduleChargingRateUnit)</td><td>(Select all supported suboptions)</td></tr><tr><td>SC-2.1</td><td>A</td><td>Optional</td></tr><tr><td>SC-2.2</td><td>W</td><td>Optional</td></tr><tr><td colspan="3">Reservation</td></tr><tr><td>R-2</td><td>Support for reservation of unspecified EVSE (ReservationNonEvseSpecific)</td><td>Optional</td></tr><tr><td>R-3</td><td>Reservation support (ReservationEnabled)</td><td>Optional</td></tr><tr><td colspan="3">Advanced Device Management</td></tr><tr><td>DM-3</td><td>Queue notifyEventRequest messages for specific severities (OfflineMonitoringEventQueuingSeverity)</td><td>Optional</td></tr><tr><td colspan="3">ISO 15118 support</td></tr><tr><td>ISO-3</td><td>Combined charging station Certificate (for both OCPP and ISO 15118)</td><td>Optional</td></tr><tr><td>ISO-4</td><td>Support for retrieving / deleting CustomerInformation - CustomerCertificate</td><td>Optional</td></tr><tr><td>ISO-5</td><td>Charging Station can provide a contract certificate that it cannot validate to the CSMS (CentralContractValidationAllowed)</td><td>Optional</td></tr><tr><td colspan="3">Local Authorization List Management</td></tr><tr><td>LA-1</td><td>Authorization list support (LocalAuthListEnabled)</td><td>Optional</td></tr><tr><td>LA-3</td><td>Option for disabling remote authorization for invalid/idTokens stored at the Local Authorization List (LocalAuthListDisablePostAuthorize)</td><td>Optional</td></tr><tr><td colspan="3">Advanced User Interface</td></tr><tr><td>UI-1</td><td>Supported message priorities (DisplayMessageSupportedPriorities)</td><td>(At least one of the suboptions below is required)</td></tr><tr><td>UI-1.1</td><td>AlwaysFront</td><td>Optional</td></tr><tr><td>UI-1.2</td><td>InFront</td><td>Optional</td></tr><tr><td>UI-1.3</td><td>NormalCycle</td><td>Optional</td></tr><tr><td>UI-2</td><td>Supported message formats (DisplayMessageSupportedFormats)</td><td>(At least one of the suboptions below is required)</td></tr><tr><td>UI-2.1</td><td>ASCII</td><td>Optional</td></tr><tr><td>UI-2.2</td><td>HTML</td><td>Optional</td></tr><tr><td>UI-2.3</td><td>URI</td><td>Optional</td></tr><tr><td>UI-2.4</td><td>UTF8</td><td>Optional</td></tr></table>
+
+# 3.2. Optional feature list for CSMS
+
+The features of a CSMS are not determined by configuration variables. Features in the list below are allowed not to be supported by a CSMS.
+
+Table 3. Optional features for CSMS
+
+<table><tr><td>Id</td><td>Feature</td><td>CSMS</td></tr><tr><td colspan="3">Core</td></tr><tr><td>C-11</td><td>Support for unlocking connector for charging station with detachable cable (UnlockConnector message).</td><td>Optional</td></tr><tr><td>C-13</td><td>Support for Reset per EVSE</td><td>Optional</td></tr><tr><td>C-14</td><td>Support for retrieving / deleting CustomerInformation - CustomerIdentifier</td><td>Optional</td></tr><tr><td>C-15</td><td>Support for scheduled firmware updates</td><td>Optional</td></tr><tr><td>C-16</td><td>Support for checking the TransactionStatus</td><td>Optional</td></tr><tr><td>C-17</td><td>Support for retrieving the ConfigurationInventory</td><td>Optional</td></tr><tr><td colspan="3"></td></tr><tr><td>C-29</td><td>TriggerMessage</td><td>Select all supported suboptions</td></tr><tr><td>C-29.1</td><td>Trigger message - MeterValues</td><td>Optional</td></tr><tr><td>C-29.2</td><td>Trigger message - TransactionEvent</td><td>Optional</td></tr><tr><td>C-29.3</td><td>Trigger message - LogStatusNotification</td><td>Optional</td></tr><tr><td>C-29.4</td><td>Trigger message - FirmwareStatusNotification</td><td>Optional</td></tr><tr><td>C-29.5</td><td>Trigger message - StatusNotification</td><td>Optional</td></tr><tr><td colspan="3">Authorization options for local start</td></tr><tr><td>C-30</td><td>Authorization - using RFID ISO14443</td><td>Required</td></tr><tr><td>C-31</td><td>Authorization - using RFID ISO15693</td><td>Required</td></tr><tr><td>C-32</td><td>Authorization - using KeyCode</td><td>Optional</td></tr><tr><td>C-33</td><td>Authorization - using locally generated id</td><td>Optional</td></tr><tr><td>C-34</td><td>Authorization - MacAddress</td><td>Optional</td></tr><tr><td>C-35</td><td>Authorization - NoAuthorization</td><td>Required</td></tr><tr><td colspan="3">Authorization options for remote start (mandatory to support at least one)</td></tr><tr><td>C-36</td><td>Authorization - using RFID ISO14443</td><td>Required</td></tr><tr><td>C-37</td><td>Authorization - using RFID ISO15693</td><td>Required</td></tr><tr><td>C-38</td><td>Authorization - using centrally, in the CSMS (or other server) generated id</td><td>Optional</td></tr><tr><td>C-39</td><td>Authorization - NoAuthorization</td><td>Optional</td></tr><tr><td colspan="3"></td></tr><tr><td>C-44</td><td>Support for sending a BootNotification Pending before Accepting</td><td>Optional</td></tr><tr><td>C-45</td><td>Support for Multiple elements GetVariablesRequest</td><td>Optional</td></tr><tr><td>C-46</td><td>Support for Multiple elements SetVariablesRequest</td><td>Optional</td></tr><tr><td>C-50</td><td>GetBaseReport - FullInventory</td><td>(At least one of the suboptions below is required)</td></tr><tr><td>C-50.1</td><td>GetBaseReport - FullInventory - During onboarding</td><td>Optional</td></tr><tr><td>C-50.2</td><td>GetBaseReport - FullInventory - Manual trigger</td><td>Optional</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">Advanced Security</td></tr><tr><td></td><td>No optional features for this profile</td><td></td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">Smart Charging</td></tr><tr><td>SC-4</td><td>Support for TxDefaultProfile on EVSEID #0</td><td>Optional</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">Reservation</td></tr><tr><td>R-1</td><td>Support for reservations of connectorType</td><td>Optional</td></tr><tr><td>R-2</td><td>Support for reservations of unspecified EVSE</td><td>Optional</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">Advanced Device Management</td></tr><tr><td></td><td>No optional features for this profile</td><td></td></tr><tr><td colspan="3">ISO 15118 support</td></tr><tr><td>ISO-3</td><td>Combined charging station certificate (for both OCPP and ISO 15118)</td><td>Optional</td></tr><tr><td>ISO-4</td><td>Support for retrieving / deleting CustomerInformation - CustomerCertificate</td><td>Optional</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">Local Authorization List Management</td></tr><tr><td>LA-2</td><td>Support for GetLocalListVersion</td><td>Optional</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">Advanced User Interface</td></tr><tr><td></td><td>No optional features for this profile</td><td></td></tr></table>
+
+# 4. List of test cases
+
+# 4.1. Introduction
+
+This table lists the test cases that are part of the OCPP Certification program. For each of the test cases, the columns "Conf. Test for Charging Station" and "Conf. Test for CSMS" indicate whether the test case is mandatory or not within a Certification Profile. The abbreviations have the following meaning:
+
+- M = Mandatory . This means that IF you implement the certification profile this test case belongs to, you MUST successfully pass this test case.
+ C = Conditional. This means that IF you meet a condition, you MUST pass this test case. Most conditions refer to the optional features that are listed in the Features.
+
+# 4.2. Test Cases Core
+
+<table><tr><td colspan="5"></td><td colspan="2">Related features</td></tr><tr><td>OCTT Id</td><td>OCPP Compliance Testing Tool scenario</td><td>Conf. Test for Charging Station</td><td>Conf. test for CSMS</td><td>Condition / remark</td><td>Feature no.</td><td>Feature</td></tr><tr><td></td><td>Basic Authentication</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_A_01</td><td>Valid username/password combination</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_A_02</td><td>Username does not equal ChargingStationId</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_A_03</td><td>Invalid password</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Update Charging Station Password for HTTP Basic Authentication</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_A_09</td><td>Accepted</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_A_10</td><td>Rejected</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>TLS - server-side certificate</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_A_04</td><td>Valid certificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_A_05</td><td>Invalid certificate</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_A_06</td><td>TLS version too low</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Upgrade Charging Station Security Profile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_A_19</td><td>Accepted</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_A_20</td><td>No valid CSMSRootCertificate installed</td><td>C</td><td></td><td>If the last CSMSRootCertificate can be removed.</td><td>AQ-1</td><td>Can the last CSMSRootCertificate be removed?</td></tr><tr><td>TC_A_22</td><td>Downgrade security profile - Rejected</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Cold Boot Charging Station</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_01</td><td>Accepted</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_B_02</td><td>Pending</td><td>M</td><td>C</td><td>CSMS: If Pending mechanism is implemented</td><td>C-44</td><td>BootNotification Pending</td></tr><tr><td>TC_B_03</td><td>Rejected</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_30</td><td>Pending/Rejected - SecurityError</td><td>M</td><td>C</td><td>For CSMS: if CSMS can be configured to first respond to a BootNotificationRequest with status Pending or Rejected</td><td>C-44 or NOT AQ-6</td><td>BootNotification Pending or Does the CSMS reject unknown Charging Stations during websocket connection setup?</td></tr><tr><td>TC_B_31</td><td>Pending/Rejected - TriggerMessage</td><td></td><td>C</td><td>For CSMS: if CSMS can be configured to first respond to a BootNotificationRequest with status Pending or Rejected</td><td>C-44 or NOT AQ-6</td><td>BootNotification Pending or Does the CSMS reject unknown Charging Stations during websocket connection setup?</td></tr><tr><td></td><td>Status change during offline period</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_51</td><td>> Offline Threshold</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_52</td><td>< Offline Threshold</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Get Variables</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_06</td><td>single value</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_B_07</td><td>multiple values</td><td>M</td><td>C</td><td>If the CSMS supports multiple elements in a GetVariablesRequest</td><td>C-45</td><td>multiple values elements GetVariablesRequest</td></tr><tr><td>TC_B_32</td><td>Unknown component</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_33</td><td>Unknown variable</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_34</td><td>Not supported attribute type</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Set Variables</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_09</td><td>single value</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_B_10</td><td>multiple values</td><td>M</td><td>C</td><td>If the CSMS supports multiple elements in a SetVariablesRequest</td><td>C-46</td><td>multiple values elements SetVariablesRequest</td></tr><tr><td>TC_B_35</td><td>Unknown component</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_36</td><td>Unknown variable</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_37</td><td>Not supported attribute type</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_11</td><td>invalidly formatted values</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_39</td><td>Read-only</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Get Base Report</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_12</td><td>ConfigurationInventory</td><td>M</td><td>C</td><td></td><td>C-17</td><td>ConfigurationInventory</td></tr><tr><td>TC_B_13</td><td>FullInventory</td><td>M</td><td>C</td><td></td><td>C-50.2</td><td>GetBaseReport - FullInventory - Manual trigger</td></tr><tr><td>TC_B_15</td><td>Not Supported base report</td><td>C</td><td></td><td>For CS: If reportBase SummaryInventory is not supported. This is the case when Certification Profile Advanced Device Management is not supported.</td><td>Not C-56</td><td></td></tr><tr><td>TC_B_53</td><td>Test mandatory DM variables via FullInventory</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Reset Charging Station</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_20</td><td>Without ongoing transaction - OnIdle</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_B_21</td><td>With Ongoing Transaction - OnIdle</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_B_22</td><td>With Ongoing Transaction - Immediate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_B_23</td><td>Unavailable persists reset</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_41</td><td>With multiple ongoing transactions - OnIdle</td><td>C</td><td></td><td>For CS: if no. of EVSEs > 1</td><td>HFS-8 > 1</td><td></td></tr><tr><td></td><td>Reset EVSE</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_25</td><td>Without ongoing transaction</td><td>C</td><td>C</td><td></td><td>C-13</td><td>Reset per EVSE</td></tr><tr><td>TC_B_26</td><td>With Ongoing Transaction - OnIdle</td><td>C</td><td>C</td><td></td><td>C-13</td><td>Reset per EVSE</td></tr><tr><td>TC_B_27</td><td>With Ongoing Transaction - Immediate</td><td>C</td><td>C</td><td></td><td>C-13</td><td>Reset per EVSE</td></tr><tr><td>TC_B_28</td><td>Not Supported</td><td>C</td><td></td><td>For CS: Charging Station does not support resetting an individual EVSE</td><td>NOT C-13</td><td>Reset per EVSE</td></tr><tr><td>TC_B_29</td><td>With ongoing transaction - Not Supported</td><td>C</td><td></td><td>For CS: Charging Station does not support resetting an individual EVSE</td><td>NOT C-13</td><td>Reset per EVSE</td></tr><tr><td></td><td>Set new NetworkConnectionProfile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_42</td><td>Accepted</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_B_43</td><td>Rejected</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_44</td><td>Failed</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Migrate to new ConnectionProfile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_45</td><td>Success - Same CSMS Root</td><td>M</td><td></td><td>For CS: at least two configuration slots for networkConnectionProfiles must be supported</td><td></td><td></td></tr><tr><td>TC_B_46</td><td>Fallback mechanism - Same CSMS Root</td><td>M</td><td></td><td>For CS: at least two configuration slots for networkConnectionProfiles must be supported</td><td></td><td></td></tr><tr><td>TC_B_47</td><td>Fallback after NetworkProfileConnectionAttempts per NetworkConfigurationPriority failed - New CSMS Root - New CSMS</td><td>C</td><td></td><td>For CS: at least two configuration slots for networkConnectionProfiles must be supported</td><td>AS-2 and C-47</td><td>Additional Root Certificate check mechanism implemented & Reconnect after NetworkProfileConnectionAttempts</td></tr><tr><td>TC_B_49</td><td>Fallback after NetworkProfileConnectionAttempts per NetworkConfigurationPriority failed - Same CSMS Root</td><td>C</td><td></td><td>For CS: at least two configuration slots for networkConnectionProfiles must be supported</td><td>C-47</td><td>Reconnect after NetworkProfileConnectionAttempts</td></tr><tr><td>TC_B_50</td><td>Success - New CSMS Root - New CSMS</td><td>M</td><td></td><td>For CS: at least two configuration slots for networkConnectionProfiles must be supported</td><td></td><td></td></tr><tr><td></td><td>Network Reconnection</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_57</td><td>After connection loss</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Local start transaction</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_02</td><td>Authorization Invalid/Unknown</td><td>C</td><td>M</td><td>Charging Station:- 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 a cable lock that prevents the EV driver to connect the EV and EVSE before authorization.</td><td>(C-30 or C-31 or C-32) and NOT AQ-2</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode and Does the Charging Station have a cable lock, which prevents the EV driver to connect the EV and EVSE before authorization?</td></tr><tr><td>TC_C_06</td><td>Authorization Restricted</td><td>C</td><td>M</td><td>For CS:- 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 a cable lock, which prevents the EV driver to connect the EV and EVSE before authorization.</td><td>NOT AQ-2 and (C-30 or C-31 or C-32)</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode</td></tr><tr><td>TC_C_07</td><td>Authorization Expired</td><td>C</td><td>M</td><td>For CS:- 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 a cable lock, which prevents the EV driver to connect the EV and EVSE before authorization.</td><td>NOT AQ-2 and (C-30 or C-31 or C-32)</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode</td></tr><tr><td>TC_E_38</td><td>EV not ready</td><td>C</td><td>M</td><td>For CS: not supporting start transaction options EnergyTransfer</td><td>NOT C-09.5 and NOT Product Subtype "Mode 1/2-only Charging Station"</td><td>Start transaction options - EnergyTransfer</td></tr><tr><td>TC_C_56</td><td>Authorization Unknown</td><td>C</td><td></td><td>Charging Station:- The Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode</td></tr><tr><td>TC_C_05</td><td>Authorization invalid - Cable lock</td><td>C</td><td></td><td>For CS:- The Charging Station has a cable lock, which prevents the EV driver to connect the 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.</td><td>(C-30 or C-31 or C-32) and AQ-2</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode</td></tr><tr><td></td><td>Local Stop Transaction</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_04</td><td>Different idToken</td><td>C</td><td></td><td>Charging Station:- The Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode</td></tr><tr><td>TC_E_06</td><td>Accepted</td><td>C</td><td></td><td>The Charging Station supports E07 Transaction locally stopped by IdToken with at least one of the following local start authorization options: C-30, C-31, C-32, C35</td><td>C-30 or C-31 or C-32 or C35</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode / NoAuthorization</td></tr><tr><td></td><td>Authorization by Groupld</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_39</td><td>Success</td><td>C</td><td>M</td><td>For CS: the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode</td></tr><tr><td>TC_C_45</td><td>Master pass - Not able to start transaction + groupld</td><td>C</td><td></td><td>For CS: the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32 and Master Pass</td><td>(C-30 or C-31 or C-32) AND (C-07 OR C-08)</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode and Master Pass</td></tr><tr><td>TC_C_42</td><td>Not stopped by Groupld</td><td>C</td><td></td><td>For CS: the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode</td></tr><tr><td></td><td>Offline Authorization</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_26</td><td>Unknown Id</td><td>C</td><td></td><td>If the feature Unknown Offline Authorization is supported AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-02 and (C-30 or C-31 or C-32)</td><td>Unknown Offline Authorization</td></tr><tr><td></td><td>Stop Transaction with a Master Pass</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_47</td><td>With UI - All transactions</td><td>C</td><td>M</td><td>CS: If the feature Master Pass with UI is supported AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-07 and (C-30 or C-31 or C-32)</td><td>Master Pass - With UI</td></tr><tr><td>TC_C_48</td><td>With UI - With UI - Specific transactions</td><td>C</td><td>M</td><td>CS: If the feature Master Pass with UI is supported AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-07 and (C-30 or C-31 or C-32)</td><td>Master Pass - With UI</td></tr><tr><td>TC_C_49</td><td>Without UI</td><td>C</td><td>M</td><td>CS: If the feature Master Pass with UI is supported AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-08 and (C-30 or C-31 or C-32)</td><td>Master Pass - Without UI</td></tr><tr><td></td><td>Store Authorization Data in the Authorization Cache</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_32</td><td>Persistent over reboot</td><td>C</td><td></td><td>If the Charging Station has an authorization cache, then it must support this use case AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_33</td><td>Update onauthorizeResponse</td><td>C</td><td></td><td>If the Charging Station has an authorization cache, then it must support this use case AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_34</td><td>Update on TransactionResponse</td><td>C</td><td></td><td>If the Charging Station has an authorization cache, then it must support this use case AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_36</td><td>AuthCacheCtrl.LocalPreAuthorize = false</td><td>C</td><td></td><td>If the Charging Station has an authorization cache and AuthCacheEnabled is implemented AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_46</td><td>AuthCacheLifeTime</td><td>C</td><td></td><td>If the Charging Station has an authorization cache, then it must support this use case AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-53 and (C-30 or C-31 or C-32)</td><td>AuthCacheLifeTime</td></tr><tr><td></td><td>Clear Authorization Data in Authorization Cache</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_37</td><td>Accepted</td><td>C</td><td>M</td><td>If the Charging Station has an authorization cache, then it must support this use case AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_38</td><td>Rejected</td><td>C</td><td>M</td><td>If the Charging Station has an authorization cache and AuthCacheEnabled is implemented AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td></td><td>Authorization by Groupld</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_41</td><td>Success with Authorization Cache</td><td>C</td><td></td><td>For CS:- The Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32- If the Charging Station has an authorization cache.</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_44</td><td>Invalid status with Authorization Cache</td><td>C</td><td></td><td>For CS:- The Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32- If the Charging Station has an authorization cache.</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td></td><td>Authorization through authorization cache</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_08</td><td>Accepted</td><td>C</td><td>M</td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_09</td><td>Invalid & Not Accepted</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_12</td><td>Invalid & Accepted</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_10</td><td>Blocked</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_11</td><td>Expired</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_13</td><td>Accepted but cable not connected yet.</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_15</td><td>StopTxOnInvalidld = false, MaxEnergyOnInvalidld > 0</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32 If MaxEnergyOnInvalidld is implemented.</td><td>C-49 and C-03 and (C-30 or C-31 or C-32)</td><td>Authorization Cache & MaxEnergyOnInvalidld</td></tr><tr><td>TC_C_16</td><td>StopTxOnInvalidld = true</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_17</td><td>StopTxOnInvalidld = false</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-49 and (C-30 or C-31 or C-32)</td><td>Authorization Cache</td></tr><tr><td>TC_C_18</td><td>StopTxOnInvalidld = true, MaxEnergyOnInvalidld > 0</td><td>C</td><td></td><td>If the Charging Station has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32 If MaxEnergyOnInvalidld is implemented.</td><td>C-49 and C-03 and (C-30 or C-31 or C-32)</td><td>Authorization Cache & MaxEnergyOnInvalidld</td></tr><tr><td>TC_C_20</td><td>Invalid</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_C_57</td><td>AuthCacheDisablePostAuthorize</td><td>C</td><td></td><td>If the Charging Station supports the option for disabling remote authorization for cached invalid idTokens AND has an authorization cache AND the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-59 and C-49 and (C-30 or C-31 or C-32)</td><td></td></tr><tr><td></td><td>Local start transaction - Cable plugin first</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_03</td><td>Success</td><td>C</td><td>M</td><td>Applicable if one or more of the local start authorization options is implemented.</td><td>NOT AQ-2 and (C-30 - C-35 or ISO 15118 support)</td><td>Authorization options for local start</td></tr><tr><td></td><td>Local start transaction - Authorization first</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_04</td><td>Success</td><td>C</td><td>M</td><td>Applicable if one or more of the local start authorization options is implemented.</td><td>C-30 - C-35 or ISO 15118 support</td><td>Authorization options for local start</td></tr><tr><td>TC_E_05</td><td>Cable plugin timeout</td><td>C</td><td></td><td>Applicable if one or more of the local start authorization options is implemented.</td><td>C-30 - C-35 or ISO 15118 support</td><td>Authorization options for local start</td></tr><tr><td>TC_E_52</td><td>DisableRemoteAuthorization</td><td>C</td><td></td><td>If the Charging Station supports the option for disabling remote authorization and The Charging Station supports at least one of the following local start authorization options C-30, C-31, C-32 and Either Authorization Cache or Local Authorization List is supported.</td><td>C-58 and (C-30 or C-31 or C-32) and (C-49 or Local Authorization List Management)</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode & Authorization Cache & Local Authorization List.</td></tr><tr><td></td><td>Start transaction options</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_09</td><td>EVConnected</td><td>C</td><td>M</td><td>TxStartPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value EVConnected is a supported value. And it should be possible to not set ParkingBayOccupancy.</td><td>C-09.1 and (C-51 or NOT C-09.6)</td><td></td></tr><tr><td>TC_E_10</td><td>Authorized - Local</td><td>C</td><td>M</td><td>TxStartPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value Authorized is a supported value. - If one or more of the local start authorization options is implemented.</td><td>C-09.2 and (C-30 - C-35 or ISO 15118 support)</td><td>Supported Transaction Start Points & Authorization options for local start & Authorization - eMAID</td></tr><tr><td>TC_E_13</td><td>Authorized - Remote</td><td>C</td><td></td><td>TxStartPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value Authorized is a supported value.</td><td>C-09.2</td><td>Supported Transaction Start points</td></tr><tr><td>TC_E_11</td><td>DataSigned</td><td>C</td><td>M</td><td>CS: TxStartPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value DataSigned is a supported value. And it should be possible to not set ParkingBayOccupancy and EVConnected and Authorized. CSMS: Must at least be able to receive a signed MeterValue. It does not need to be able to read it.</td><td>C-09.3 and (C-51 or NOT (C-09.1 or C-09.2 or C-09.6))</td><td>Supported Transaction Start points</td></tr><tr><td>TC_E_01</td><td>PowerPathClosed</td><td>C</td><td>M</td><td>TxStartPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value PowerPathClosed is a supported value. And it should be possible to not set ParkingBayOccupancy and EVConnected and Authorized and DataSigned.</td><td>C-09.4 and (C-51 or NOT (C-09.1 or C-09.2 or C-09.3 or C-09.6))</td><td>Supported Transaction Start points</td></tr><tr><td>TC_E_02</td><td>EnergyTransfer</td><td>C</td><td>M</td><td>TxStartPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value EnergyTransfer is a supported value. And it should be possible to not set ParkingBayOccupancy and EVConnected and Authorized and DataSigned and PowerPathClosed</td><td>C-09.5 and (C-51 or NOT (C-09.1 or C-09.2 or C-09.3 or C-09.4 or C-09.6))</td><td>Supported Transaction Start points</td></tr><tr><td>TC_E_12</td><td>ParkingBayOccupied</td><td>C</td><td>M</td><td>TxStartPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value ParkingBayOccupied is a supported value.</td><td>C-09.6</td><td>Supported Transaction Start points</td></tr><tr><td></td><td>Stop transaction options</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_14</td><td>EVDisconnected - Charging Station side</td><td>C</td><td>M</td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value EVConnected is a supported value. And it should be possible to not set EnergyTransfer and PowerPathClosed and Authorized. Charging Station does NOT have a fixed cable.</td><td>HFS-1 and C-10.1 and (C-52 or NOT (C-10.2 or C-10.3 or C-10.4))</td><td>Supported Transaction Stop points</td></tr><tr><td>TC_E_20</td><td>EVDisconnected - EV side (able to charge IEC 61851-1 EV)</td><td>C</td><td>M</td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value EVConnected is a supported value. And it should be possible to not set EnergyTransfer and PowerPathClosed AND The Charging Station does NOT have following configuration combination; StopTxOnEVSideDisconnect mutability ReadOnly with value true AND TxStopPoint mutability is ReadOnly and contains Authorized</td><td>(C-10.1 AND (NOT (NOT C-52 AND (C-10.3 or C-10.4)))) AND NOT (NOT C.06.1 AND NOT C-52 AND C-10.2)) AND (AQ-9 OR Product Subtype "Mode 1/2-only Charging Station")</td><td>Supported Transaction Stop points</td></tr><tr><td>TC_E_54</td><td>EVDisconnected - EV side (not able to charge IEC 61851-1 EV)</td><td>C</td><td></td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value EVConnected is a supported value. And it should be possible to not set EnergyTransfer and PowerPathClosed AND The Charging Station does NOT have following configuration combination; StopTxOnEVSideDisconnect mutability ReadOnly with value true AND TxStopPoint mutability is ReadOnly and contains Authorized</td><td>C-10.1 AND (NOT (NOT C-52 AND (C-10.2 or C-10.3 or C-10.4))) AND (HFS-4 OR ISO15118 support) AND NOT Product Subtype "Mode 1/2-only Charging Station"</td><td>Supported Transaction Stop points</td></tr><tr><td>TC_E_15</td><td>StopAuthorized - Local</td><td>C</td><td>M</td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value Authorized is a supported value. The Charging Station supports E07 Transaction locally stopped by IdToken with at least one of the following local start authorization options: C-30, C-31, C-32, C35</td><td>C-10.2 and (C-30 or C-31 or C-32 or C35)</td><td>Supported Transaction Stop Points & Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode / NoAuthorization</td></tr><tr><td>TC_E_21</td><td>StopAuthorized - Remote</td><td>C</td><td>M</td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value Authorized is a supported value.</td><td>C-10.2</td><td>Supported Transaction Stop points</td></tr><tr><td>TC_E_16</td><td>Deauthorized - Invalid idToken</td><td>C</td><td>M</td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value 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.</td><td>(C-10.2 or C-10.3) and (C-30 - C-32 or ISO 15118 support) and C-01</td><td>Supported Transaction Stop Points & Local Authorization options for local start & Authorization - eMAID</td></tr><tr><td>TC_E_17</td><td>Deauthorized - EV side disconnect</td><td>C</td><td>M</td><td>-TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value Authorized or PowerPathClosed is a supported value. - StopTxOnEVSideDisconnect needs to ReadWrite or ReadOnly with value true</td><td>(C-10.2 or C-10.3) and C-06.2 and AQ-9</td><td>Supported Transaction Stop points</td></tr><tr><td>TC_E_39</td><td>Deauthorized - timeout</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_E_07</td><td>PowerPathClosed - Local stop</td><td>C</td><td>M</td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value PowerPathClosed is a supported value. And it should be possible to not set Authorized. The Charging Station supports E07 Transaction locally stopped by IdToken with at least one of the following local start authorization options: C-30, C-31, C-32, C35</td><td>C-10.3 and (C-52 or NOT C-10.2) and (C-30 or C-31 or C-32 or C35)</td><td>Supported Transaction Stop Points & Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode / NoAuthorization</td></tr><tr><td>TC_E_35</td><td>PowerPathClosed - Remote stop</td><td>C</td><td></td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value PowerPathClosed is a supported value. And it should be possible to not set Authorized.</td><td>C-10.3 and (C-52 or NOT C-10.2)</td><td>Supported Transaction Stop points</td></tr><tr><td>TC_E_37</td><td>PowerPathClosed - EV side disconnect</td><td>C</td><td></td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value PowerPathClosed is a supported value. And it should be possible to not set EnergyTransfer and EVConnected.</td><td>C-10.3 and (C-52 or NOT (C-10.1 or C-10.4)) AND (AQ-9 OR Product Subtype "Mode 1/2-only Charging Station")</td><td>Supported Transaction Stop points</td></tr><tr><td>TC_E_08</td><td>EnergyTransfer stopped - StopAuthorized</td><td>C</td><td>M</td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value EnergyTransfer is a supported value. And it should be possible to not set PowerPathClosed and Authorized.</td><td>C-10.4 and (C-52 or NOT (C-10.2 or C-10.3))</td><td>Supported Transaction Stop points</td></tr><tr><td>TC_E_22</td><td>EnergyTransfer stopped - SuspendedEV</td><td>C</td><td>M</td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value EnergyTransfer is a supported value.</td><td>C-10.4</td><td>Supported Transaction Stop points</td></tr><tr><td>TC_E_19</td><td>ParkingBayUnoccupied</td><td>C</td><td>M</td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value ParkingBayOccupancy is a supported value. And it should be possible to not set EnergyTransfer and Authorized and PowerPathClosed and EVConnected.</td><td>C-10.5 and (C-52 or NOT (C-10.1 or C-10.2 or C-10.3 or C-10.4))</td><td>Supported Transaction Stop points</td></tr><tr><td></td><td>Disconnect cable on EV-side</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_24</td><td>Deauthorize transaction - UnlockOnEVSideDisconnect is true</td><td>C</td><td></td><td>The Charging Station does NOT have a permanently attached cable. UnlockOnEVSideDisconnect can be set to true StopTxOnEVSideDisconnect can be set to true</td><td>HFS-1 and C-06.2 and C-12.1 and AQ-9 and NOT Product Subtype "Mode 1/2-only Charging Station"</td><td>Support for not maintaining authorization when cable disconnected on EV side & Support for unlocking connector when cable disconnected on EV side</td></tr><tr><td>TC_E_25</td><td>Deauthorize transaction - UnlockOnEVSideDisconnect is false</td><td>C</td><td></td><td>UnlockOnEVSideDisconnect can be set to false StopTxOnEVSideDisconnect can be set to true</td><td>C-06.2 and C-12.2 and (AQ-9 OR Product Subtype "Mode 1/2-only Charging Station")</td><td>Support for not maintaining authorization when cable disconnected on EV side & Support for not unlocking connector when cable disconnected on EV side</td></tr><tr><td>TC_E_26</td><td>Suspend transaction</td><td>C</td><td>M</td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value ParkingBayOccupancy or Authorized is a supported value. And it should be possible to not set EnergyTransfer and PowerPathClosed and EVConnected. UnlockOnEVSideDisconnect can be set to false StopTxOnEVSideDisconnect can be set to false</td><td>(C-10.2 or C-10.5) and (C-52 or NOT (C-10.1 or C-10.3 or C-10.4)) and C-06.1 and C-12.2 and AQ-9 and NOT Product Subtype "Mode 1/2-only Charging Station"</td><td></td></tr><tr><td>TC_E_27</td><td>Suspend transaction - Fixed cable connection timeout</td><td>C</td><td></td><td>TxStopPoint can either be ReadOnly with a subset of the values or have a valueList of supported values, that contains a subset. This testcase is applicable if the value ParkingBayOccupancy or Authorized is a supported value. And it should be possible to not set EnergyTransfer and PowerPathClosed and EVConnected. The Charging Station has a permanently attached cable at the Charging Station side. UnlockOnEVSideDisconnect can be set to false StopTxOnEVSideDisconnect can be set to false</td><td>(C-10.2 or C-10.5) and (C-52 or NOT (C-10.1 or C-10.3 or C-10.4)) and C-06.1 and C-12.2 and HFS-2 and AQ-9 and NOT Product Subtype "Mode 1/2-only Charging Station"</td><td></td></tr><tr><td></td><td>Retry sending transaction message when failed</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_41</td><td>Max retry count reached</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_42</td><td>Success before reaching the max retry count</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_50</td><td>Max retry count reached - CallError</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_51</td><td>Success before reaching the max retry count - CallError</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Offline Behaviour</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_40</td><td>Connection loss during transaction</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_43</td><td>Transaction during offline period</td><td>C</td><td></td><td>Charging Station: If offline authorization is supported and one or more of the local start authorization options is implemented. Or the Charging Station supports NoAuthorization.</td><td>(C-01 and (C-30 - C-34 or ISO 15118 support)) or C-35</td><td>Offline transaction support & Local Authorization options for local start or NoAuthorization support</td></tr><tr><td>TC_E_44</td><td>Stop transaction during offline period</td><td>C</td><td></td><td>Charging Station: If one or more of the local start authorization options is implemented.</td><td>C-30 - C-35 or ISO 15118 support</td><td>Local Authorization options for local start & Authorization - eMAID</td></tr><tr><td>TC_E_45</td><td>Stop transaction during offline period - Same Groupld</td><td>C</td><td></td><td>For CS: the Charging Station supports at least one of the following local start authorization options: C-30, C-31, C-32 and Local Authorization List or Authorization Cache</td><td>(C-30 or C-31 or C-32) AND (Local Authorization List Management or C-49)</td><td>Local Authorization - using RFID ISO14443 / RFID ISO15693 / KeyCode and Local Authorization List or Authorization Cache</td></tr><tr><td></td><td>Check Transaction status</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_28</td><td>TransactionId unknown</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_29</td><td>Transaction with id ongoing - with message in queue</td><td>M</td><td>C</td><td></td><td>C-16</td><td>Check TransactionStatus</td></tr><tr><td>TC_E_30</td><td>Transaction with id ongoing - without message in queue</td><td>M</td><td>C</td><td></td><td>C-16</td><td>Check TransactionStatus</td></tr><tr><td>TC_E_31</td><td>Transaction with id ended - with message in queue</td><td>C</td><td>C</td><td>Charging Station: The following combination of conditions are NOT true: - No local authorization methods are supported AND - TxStopPoint mutability is false and only contains Authorized AND - TxCtrl.R止TxOnEVSideDisconnect mutability is false and value is false</td><td>CSMS: C-16 Charging Station: NOT (NOT (C-30 - C-35) AND (NOT C-10.1 AND NOT C-10.3 AND NOT C-10.4 AND NOT C-10.5) AND NOT C-06.2)</td><td>CSMS: Check TransactionStatus</td></tr><tr><td>TC_E_32</td><td>Transaction with id ended - without message in queue</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_33</td><td>Without transactionId - with message in queue</td><td>M</td><td>C</td><td></td><td>C-16</td><td>Check TransactionStatus</td></tr><tr><td>TC_E_34</td><td>Without transactionId - without message in queue</td><td>M</td><td>C</td><td></td><td>C-16</td><td>Check TransactionStatus</td></tr><tr><td></td><td>Reset Sequence Number</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_53</td><td>CSMS accepting seqNo = 0 at start of transaction</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Remote start transaction</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_F_01</td><td>Cable plugin first</td><td>C</td><td>M</td><td>If the Charging Station does not have a cable lock.</td><td>NOT AQ-2 and (C-36-(or) C-39)</td><td>Authorization options for remote start</td></tr><tr><td>TC_F_02</td><td>Remote start first - AuthorizationRemoteStart is true</td><td>C</td><td>M</td><td>If AuthorizationRemoteStart can be set to true</td><td>C-48.1 and (C-36-(or) C-39)</td><td>Authorization options for remote start</td></tr><tr><td>TC_F_03</td><td>Remote start first - AuthorizationRemoteStart is false</td><td>C</td><td>M</td><td>If AuthorizationRemoteStart can be set to false</td><td>C-48.2 and (C-36-(or) C-39)</td><td>Authorization options for remote start</td></tr><tr><td>TC_F_04</td><td>Remote start first - Cable plugin timeout</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Remote stop transaction</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_F_08</td><td>Success</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_F_09</td><td>Rejected</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Remote unlock Connector</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_F_05</td><td>With ongoing transaction</td><td>C</td><td></td><td>If the Charging Station has a detachable cable.</td><td>HFS-1 and NOT Product Subtype "Mode 1/2-only Charging Station"</td><td></td></tr><tr><td>TC_F_06</td><td>Without ongoing transaction - Accepted</td><td>HFS-1 and NOT Product Subtype "Mode 1/2-only Charging Station"</td><td>C-11</td><td>If the Charging Station has a detachable cable. If the CSMS support the Unlocking connector for Charging Station with detachable cable (UnlockConnector) feature.</td><td>See column 3/4</td><td></td></tr><tr><td>TC_F_07</td><td>Without ongoing transaction - No cable connected</td><td>C</td><td></td><td>If the Charging Station has a detachable cable.</td><td>HFS-1 and NOT Product Subtype "Mode 1/2-only Charging Station"</td><td></td></tr><tr><td>TC_F_10</td><td>Without ongoing transaction - UnknownConnector</td><td>C</td><td></td><td>If the Charging Station has a detachable cable.</td><td>HFS-1 and NOT Product Subtype "Mode 1/2-only Charging Station"</td><td></td></tr><tr><td></td><td>Trigger message</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_F_11</td><td>MeterValues - Specific EVSE</td><td>C</td><td>C</td><td>If the SUT supports TriggerMessage for requestedMessage MeterValues for a specific EVSE.</td><td>C-29.1</td><td>TriggerMessage</td></tr><tr><td>TC_F_12</td><td>MeterValues - All EVSE</td><td>C</td><td>C</td><td>If the SUT supports TriggerMessage for requestedMessage MeterValues for a all EVSE.</td><td>C-29.1</td><td>TriggerMessage</td></tr><tr><td>TC_F_13</td><td>TransactionEvent - Specific EVSE</td><td>C</td><td>C</td><td>If the SUT supports TriggerMessage for requestedMessage TransactionEvent for a specific EVSE.</td><td>C-29.2</td><td>TriggerMessage</td></tr><tr><td>TC_F_14</td><td>TransactionEvent - All EVSE</td><td>C</td><td>C</td><td>If the SUT supports TriggerMessage for requestedMessage TransactionEvent for a all EVSE.</td><td>C-29.2</td><td>TriggerMessage</td></tr><tr><td>TC_F_15</td><td>LogStatusNotification - Idle</td><td>C</td><td>C</td><td>If the SUT supports TriggerMessage for requestedMessage LogStatusNotification.</td><td>C-29.3</td><td>TriggerMessage</td></tr><tr><td>TC_F_16</td><td>LogStatusNotification - Uploading</td><td>C</td><td></td><td>If the Charging Station supports TriggerMessage for requestedMessage LogStatusNotification.</td><td>C-29.3</td><td>TriggerMessage</td></tr><tr><td>TC_F_17</td><td>FirmwareStatusNotification - Specific EVSE not relevant</td><td>C</td><td></td><td>If the Charging Station supports TriggerMessage for requestedMessage FirmwareStatusNotification.</td><td>C-29.4</td><td>TriggerMessage</td></tr><tr><td>TC_F_18</td><td>FirmwareStatusNotification - Idle</td><td>C</td><td>C</td><td>If the SUT supports TriggerMessage for requestedMessage FirmwareStatusNotification.</td><td>C-29.4</td><td>TriggerMessage</td></tr><tr><td>TC_F_19</td><td>FirmwareStatusNotification - Downloading</td><td>C</td><td></td><td>If the Charging Station supports TriggerMessage for requestedMessage FirmwareStatusNotification.</td><td>C-29.4</td><td>TriggerMessage</td></tr><tr><td>TC_F_20</td><td>Heartbeat</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_F_23</td><td>StatusNotification - Specific EVSE - Available</td><td>C</td><td>C</td><td>If the SUT supports TriggerMessage for requestedMessage StatusNotification for a specific EVSE.</td><td>C-29.5</td><td>TriggerMessage</td></tr><tr><td>TC_F_24</td><td>StatusNotification - Specific EVSE - Occupied</td><td>C</td><td>C</td><td>If the SUT supports TriggerMessage for requestedMessage StatusNotification for a specific EVSE.</td><td>C-29.5</td><td>TriggerMessage</td></tr><tr><td>TC_F_26</td><td>BootNotification - Rejected</td><td>C</td><td></td><td>If the Charging Station supports TriggerMessage for requestedMessage BootNotification.</td><td>C-29.6</td><td>TriggerMessage</td></tr><tr><td>TC_F_27</td><td>NotImplemented</td><td>C</td><td>M</td><td>For CS: can only be done when SignCombinedCertificate is notimplemented</td><td>NOT ISO-3</td><td></td></tr><tr><td></td><td>Connector status Notification</td><td></td><td></td><td>Charging Station: This can either be implemented with the StatusNotification or NotifyEvent message.CSMS: Both StatusNotification and NotifyEvent must be supported.</td><td></td><td></td></tr><tr><td>TC_G_01</td><td>Available to Occupied</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_G_02</td><td>Occupied to Available</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_G_20</td><td>Lock Failure</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Change Availability EVSE</td><td></td><td></td><td>Charging Station: This can either be implemented with the StatusNotification or NotifyEvent message.CSMS: Both StatusNotification and NotifyEvent must be supported.</td><td></td><td></td></tr><tr><td>TC_G_03</td><td>Operative to inoperative</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_G_09</td><td>Operative to operative</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_G_04</td><td>Inoperative to operative</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_G_10</td><td>Inoperative to inoperative</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_G_11</td><td>With ongoing transaction</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_G_18</td><td>state persists across reboot</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Change Availability Charging Station</td><td></td><td></td><td>Charging Station: This can either be implemented with the StatusNotification or NotifyEvent message.CSMS: Both StatusNotification and NotifyEvent must be supported.</td><td></td><td></td></tr><tr><td>TC_G_05</td><td>Operative to inoperative</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_G_12</td><td>Operative to operative</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_G_06</td><td>Inoperative to operative</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_G_13</td><td>Inoperative to inoperative</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_G_21</td><td>state persists across reboot</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_G_14</td><td>With ongoing transaction</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Change Availability Connector</td><td></td><td></td><td>Charging Station: This can either be implemented with the StatusNotification or NotifyEvent message.CSMS: Both StatusNotification and NotifyEvent must be supported.</td><td></td><td></td></tr><tr><td>TC_G_07</td><td>Operative to inoperative</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_G_15</td><td>Operative to operative</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_G_08</td><td>Inoperative to operative</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_G_16</td><td>Inoperative to inoperative</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_G_17</td><td>With ongoing transaction</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_G_19</td><td>state persists across reboot</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Clock-aligned Meter Values</td><td></td><td></td><td>Charging Station can choose which measurands are supported (At least one). This can either be implemented with the MeterValues or NotifyEvent message.</td><td></td><td></td></tr><tr><td>TC_J_01</td><td>No transaction ongoing</td><td>M</td><td>M</td><td></td><td>C-40</td><td>Supported MeterValue Measurands</td></tr><tr><td>TC_J_02</td><td>Transaction ongoing</td><td>M</td><td>M</td><td></td><td>C-40</td><td>Supported MeterValue Measurands</td></tr><tr><td>TC_J_03</td><td>EventType Ended</td><td>M</td><td>M</td><td></td><td>C-40</td><td>Supported MeterValue Measurands</td></tr><tr><td>TC_J_04</td><td>Signed</td><td>C</td><td>M</td><td>Charging Station: If signed MeterValues is implemented CSMS: Must at least be able to receive a signed MeterValue. It does not need to be able to read it.</td><td>C-40 and C-42</td><td>Supported MeterValue Measurands & Signed Metervalues</td></tr><tr><td>TC_J_06</td><td>No Meter Values during transaction</td><td>C</td><td></td><td>If AlignedDataSendDuringIdle is supported.</td><td>C-28</td><td>AlignedDataSendDuringIdle</td></tr><tr><td></td><td>Sampled Meter Values</td><td></td><td></td><td>Charging Station can choose which measurands are supported (At least one).</td><td></td><td></td></tr><tr><td>TC_J_07</td><td>EventType Started - EVSE known</td><td>M</td><td>M</td><td></td><td>C-40</td><td>Supported MeterValue Measurands</td></tr><tr><td>TC_J_08</td><td>Context Transaction.Start - EVSE not known</td><td>C</td><td>M</td><td></td><td>C-40 and NOT AQ-8 AND (C-09.2 OR C-09.6)</td><td>Supported MeterValue Measurands & possibility to enforce EVSE being known.</td></tr><tr><td>TC_J_09</td><td>EventType Updated</td><td>M</td><td>M</td><td></td><td>C-40</td><td>Supported MeterValue Measurands</td></tr><tr><td>TC_J_10</td><td>EventType Ended</td><td>M</td><td>M</td><td></td><td>C-40</td><td>Supported MeterValue Measurands</td></tr><tr><td>TC_J_11</td><td>Signed</td><td>C</td><td>M</td><td>Charging Station: If signed MeterValues is implemented CSMS: Must at least be able to receive a signed MeterValue. It does not need to be able to read it.</td><td>C-42</td><td>Supported MeterValue Measurands & Signed Metervalues</td></tr><tr><td></td><td>Remote start transaction with charging profile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_38</td><td>Ignore chargingProfile</td><td>C</td><td></td><td>The Charging Station does NOT support Smart Charging.</td><td>NOT Smart Charging</td><td></td></tr><tr><td></td><td>Secure Firmware Update</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_L_01</td><td>Installation successful</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_L_02</td><td>InstallScheduled</td><td>M</td><td>C</td><td></td><td>C-15</td><td>Scheduled firmware updates</td></tr><tr><td>TC_L_03</td><td>DownloadScheduled</td><td>M</td><td>C</td><td></td><td>C-15</td><td>Scheduled firmware updates</td></tr><tr><td>TC_L_04</td><td>RevokedCertificate</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_L_05</td><td>InvalidCertificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_L_06</td><td>InvalidSignature</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_L_07</td><td>DownloadFailed</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_L_08</td><td>InstallVerificationFailed or InstallationFailed</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_L_09</td><td>InstallationFailed</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_L_10</td><td>AcceptedCanceled</td><td>C</td><td>M</td><td>The Charging Station supports cancelling an ongoing firmware update</td><td>C-60</td><td></td></tr><tr><td>TC_L_11</td><td>Unable to cancel</td><td>C</td><td>M</td><td>The Charging Station does NOT supports cancelling an ongoing firmware update</td><td>NOT C-60</td><td></td></tr><tr><td>TC_L_18</td><td>Missing firmware signing certificate and signature</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_L_12</td><td>Unable to download/install firmware with ongoing transaction - AllowNewSessionsPendingFirmwareUpdate is true</td><td>C</td><td></td><td>AllowNewSessionsPendingFirmwareUpdate is implemented. The Charging Station is unable to download AND install firmware while there is an ongoing transaction.</td><td>C-20 and NOT C-43 and NOT AQ-7 and HFS-8 > 1</td><td>AllowNewSessionsPendingFirmware reUpdate</td></tr><tr><td>TC_L_13</td><td>Unable to download/install firmware with ongoing transaction - AllowNewSessionsPendingFirmwareUpdate is false</td><td>C</td><td>M</td><td>AllowNewSessionsPendingFirmwareUpdate is implemented. The Charging Station is unable to download AND install firmware while there is an ongoing transaction.</td><td>NOT C-43 and NOT AQ-7</td><td></td></tr><tr><td>TC_L_14</td><td>Unable to install and activate firmware with ongoing transaction - AllowNewSessionsPendingFirmwareUpdate is true</td><td>C</td><td></td><td>AllowNewSessionsPendingFirmwareUpdate is implemented. The Charging Station is unable to install firmware while there is an ongoing transaction</td><td>C-20 and NOT C-43 and AQ-7 and HFS-8 > 1</td><td>AllowNewSessionsPendingFirmware reUpdate</td></tr><tr><td>TC_L_15</td><td>Unable to install firmware with ongoing transaction - AllowNewSessionsPendingFirmwareUpdate is false</td><td>C</td><td></td><td>AllowNewSessionsPendingFirmwareUpdate is implemented. The Charging Station is unable to install firmware while there is an ongoing transaction</td><td>NOT C-43 and AQ-7</td><td></td></tr><tr><td>TC_L_16</td><td>Able to update firmware with ongoing transaction</td><td>C</td><td></td><td>If the Charging Station supports Install Firmware with ongoing transaction(s)</td><td>C-43</td><td>Install Firmware with ongoing transaction(s)</td></tr><tr><td></td><td>Retrieve certificates from Charging Station</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_M_12</td><td>CSMSRootCertificate</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_M_13</td><td>ManufacturerRootCertificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_17</td><td>CSMSRootCertificate & ManufacturerRootCertificate</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_M_18</td><td>All certificateTypes</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_19</td><td>No matching certificate found</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Delete a certificate from a Charging Station</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_M_20</td><td>Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_21</td><td>Failed</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_22</td><td>No matching certificate found</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Install CA certificate</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_M_01</td><td>CSMSRootCertificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_02</td><td>ManufacturerRootCertificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_05</td><td>Failed</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_07</td><td>Rejected - Certificate invalid</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_M_09</td><td>AdditionalRootCertificateCheck - Rejected</td><td>C</td><td></td><td>If the Charging Station supports AdditionalRootCertificateCheck with value true</td><td>AS-2</td><td>Additional Root Certificate check mechanism implemented</td></tr><tr><td>TC_M_30</td><td>AdditionalRootCertificateCheck - Reconnect using new CSMS Root - Success</td><td>C</td><td></td><td>If the Charging Station supports AdditionalRootCertificateCheck with value true</td><td>AS-2</td><td>Additional Root Certificate check mechanism implemented</td></tr><tr><td>TC_M_31</td><td>AdditionalRootCertificateCheck - Reconnect using new CSMS Root - Failback mechanism</td><td>C</td><td></td><td>If the Charging Station supports AdditionalRootCertificateCheck with value true</td><td>AS-2</td><td>Additional Root Certificate check mechanism implemented</td></tr><tr><td></td><td>Retrieve Log Information</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_25</td><td>Diagnostics Log - Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_34</td><td>Rejected</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_26</td><td>Diagnostics Log - Upload failed</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_35</td><td>Security Log - Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_36</td><td>Second Request</td><td>C</td><td>M</td><td>If the Charging Station is able to cancel an ongoing log file upload.</td><td>C-57</td><td></td></tr><tr><td></td><td>Get Customer Information</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_27</td><td>Accepted + data</td><td>C</td><td>M</td><td>For CS: The Charging Station needs to support Local Authorization and either the Local Authorization List or Authorization Cache. IdToken is used as customer information.</td><td>(C-30 or C-31 or C-34) and (Local Authorization List Management or C-49)</td><td></td></tr><tr><td>TC_N_28</td><td>Accepted + no data</td><td>C</td><td>M</td><td>For CS: The Charging Station needs to support Local Authorization and either the Local Authorization List or Authorization Cache. IdToken is used as customer information.</td><td>(C-30 or C-31 or C-34) and (Local Authorization List Management or C-49)</td><td></td></tr><tr><td>TC_N_29</td><td>Not Accepted</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Clear Customer Information</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_30</td><td>Clear and report + data</td><td>C</td><td>M</td><td>For CS: The Charging Station needs to support Local Authorization or the Authorization Cache. IdToken is used as customer information.</td><td>(C-30 or C-31 or C-34) and (Local Authorization List Management or C-49)</td><td></td></tr><tr><td>TC_N_31</td><td>Clear and report + no data</td><td>C</td><td>M</td><td>For CS: The Charging Station needs to support Local Authorization or the Authorization Cache. IdToken is used as customer information.</td><td>(C-30 or C-31 or C-34) and (Local Authorization List Management or C-49)</td><td></td></tr><tr><td>TC_N_32</td><td>Clear and no report</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_62</td><td>Clear and report - customerIdentifier</td><td>C</td><td>C</td><td>Support for retrieving / deleting CustomerInformation - CustomerIdentifier</td><td>C-14</td><td></td></tr><tr><td></td><td>Data Transfer to the Charging Station</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_P_01</td><td>Rejected / Unknown VendorId / Unknown MessagingId</td><td>M</td><td></td><td>Charging Station must be able to Reject the message.</td><td></td><td></td></tr><tr><td></td><td>Data Transfer to the CSMS</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_P_02</td><td>Rejected / Unknown VendorId / Unknown MessagingId</td><td></td><td>M</td><td>CSMS must be able to Reject the message.</td><td></td><td></td></tr><tr><td></td><td>CustomData</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_P_03</td><td>Receive custom data</td><td>M</td><td>M</td><td></td><td></td><td></td></tr></table>
+
+4.3. Test Cases Advanced Security
+
+<table><tr><td colspan="5"></td><td colspan="2">Related features</td></tr><tr><td>OCTT Id</td><td>OCPP Compliance Testing Tool scenario</td><td>Conf. Test for Charging Station</td><td>Conf. test for CSMS</td><td>Condition / remark</td><td>Feature no.</td><td>Feature</td></tr><tr><td></td><td>TLS - Client-side certificate</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_A_07</td><td>valid certificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_A_08</td><td>Invalid certificate</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Update Charging Station Certificate by request of CSMS</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_A_11</td><td>Success - Charging Station Certificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_A_14</td><td>Invalid certificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_A_15</td><td>SignCertificateRequest Rejected</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_A_23</td><td>CertificateSignedRequest Timeout</td><td>C</td><td></td><td>If the Charging Station supports CertificateSignedRequest Timeout</td><td>AS-3</td><td></td></tr><tr><td></td><td>Upgrade Charging Station Security Profile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_A_21</td><td>No valid ChargingStationCertificate installed</td><td>C</td><td></td><td>If the last ChargingStationCertificate can be removed (Via other means than OCPP).</td><td>AQ-1</td><td></td></tr><tr><td></td><td>Delete a certificate from a Charging Station</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_M_23</td><td>Unable to delete the Charging Station Certificate</td><td>M</td><td></td><td></td><td></td><td></td></tr></table>
+
+4.4. Test Cases Local Authorization List Management
+
+<table><tr><td colspan="5"></td><td colspan="2">Related features</td></tr><tr><td>OCTT Id</td><td>OCPP Compliance Testing Tool scenario</td><td>Conf. Test for Charging Station</td><td>Conf. test for CSMS</td><td>Condition / remark</td><td>Feature no.</td><td>Feature</td></tr><tr><td></td><td>Offline authorization through local authorization list</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_21</td><td>Accepted</td><td>M</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td></td></tr><tr><td>TC_C_22</td><td>Invalid</td><td>M</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td></td></tr><tr><td>TC_C_23</td><td>Blocked</td><td>M</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td></td></tr><tr><td>TC_C_24</td><td>Expired</td><td>M</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td></td></tr><tr><td>TC_C_25</td><td>Local Authorization List > Authorization Cache</td><td>M</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td></td></tr><tr><td></td><td>Online authorization through local authorization list</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_27</td><td>Accepted</td><td>M</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td></td></tr><tr><td>TC_C_28</td><td>Invalid & Not Accepted</td><td>M</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td></td></tr><tr><td>TC_C_31</td><td>Invalid & Accepted</td><td>M</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td></td></tr><tr><td>TC_C_29</td><td>Blocked</td><td>M</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td></td></tr><tr><td>TC_C_30</td><td>Expired</td><td>M</td><td></td><td>The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td></td></tr><tr><td>TC_C_58</td><td>LocalAuthListDisablePostAuthorize</td><td>C</td><td></td><td>The Charging Station supports the option for disabling remote authorization for invalid idTokens stored at the Local Authorization List AND at least one of the following local start authorization options: C-30, C-31, C-32</td><td>LA-3 and (C-30 or C-31 or C-32)</td><td></td></tr><tr><td></td><td>Authorization by GroupId</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_40</td><td>Success with Local Authorization List</td><td>M</td><td>M</td><td>For CS:- The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td></td></tr><tr><td>TC_C_43</td><td>Invalid status with Local Authorization List</td><td>M</td><td>M</td><td>For CS:- The Charging Station must support at least one of the following local start authorization options: C-30, C-31, C-32</td><td>C-30 or C-31 or C-32</td><td></td></tr><tr><td></td><td>Send Local Authorization List</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_D_01</td><td>Full</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_D_02</td><td>Differential Update</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_D_03</td><td>Differential Remove</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_D_04</td><td>Full with empty list</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_D_05</td><td>Differential with empty list</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_D_06</td><td>VersionMismatch</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_D_07</td><td>Persistent over reboot</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Get Local List Version</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_D_08</td><td>Success</td><td>M</td><td>C</td><td></td><td>LA-2</td><td>GetLocalListVersion</td></tr><tr><td>TC_D_09</td><td>No list available</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_D_10</td><td>Function disabled</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Clear Customer Information</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_46</td><td>Update Local Authorization List</td><td></td><td>M</td><td></td><td></td><td></td></tr></table>
+
+4.5. Test Cases Smart Charging
+
+<table><tr><td colspan="5"></td><td colspan="2">Related features</td></tr><tr><td>OCTT Id</td><td>OCPP Compliance Testing Tool scenario</td><td>Conf. Test for Charging Station</td><td>Conf. test for CSMS</td><td>Condition / remark</td><td>Feature no.</td><td>Feature</td></tr><tr><td></td><td>Set Charging Profile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_01</td><td>TxDefaultProfile - Specific EVSE</td><td>M</td><td>M</td><td>Remark: for CSMS TxDefaultProfile is mandatory, specific values ValidFrom/ValidTo, Duration and limit are tested.</td><td></td><td></td></tr><tr><td>TC_K_10</td><td>TxDefaultProfile - All EVSE</td><td>M</td><td>C</td><td></td><td>SC-4</td><td>Support for TxDefaultProfile on EVSEID #0</td></tr><tr><td>TC_K_60</td><td>TxProfile with ongoing transaction on the specified EVSE</td><td>M</td><td>M</td><td>Remark for CSMS: combination TxProfile and Relative is mandatory</td><td></td><td></td></tr><tr><td>TC_K_02</td><td>TxProfile without ongoing transaction on the specified EVSE</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_11</td><td>Unable to set TxProfile on all EVSE at once</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_03</td><td>ChargingStationMaxProfile</td><td>M</td><td>M</td><td>Remark: for CSMS ChargingStationMaxProfile is mandatory, specific values ValidFrom/ValidTo, Duration and limit are tested.</td><td></td><td></td></tr><tr><td>TC_K_19</td><td>ChargingProfileKind is Recurring</td><td>M</td><td>M</td><td>Remark for CSMS: TxDefaultProfile or ChargingStationMaxProfile. Configurable concurrencyKind: weekly and Daily are mandatory</td><td></td><td></td></tr><tr><td>TC_K_12</td><td>ChargerRateUnit Rejected</td><td>C</td><td></td><td>If only 1 of the 2 ChargingRateUnits is supported by the Charging Station</td><td>NOT (SC-2.1 and SC-2.2)</td><td></td></tr><tr><td>TC_K_13</td><td>Persistent over reboot</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_14</td><td>Unexisting EVSEid</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_28</td><td>TxDefaultProfile with transaction ongoing</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_15</td><td>Not Supported</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_16</td><td>Unknown transactionId</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_21</td><td>ValidFrom</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_22</td><td>ValidTo</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_23</td><td>StartSchedule</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_70</td><td>Multiple Profiles</td><td></td><td>M</td><td>Remark for CSMS: at least two different stacklevels, amount of ChargingProfiles: at least 2 different id's</td><td></td><td></td></tr><tr><td></td><td>Replace charging profile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_04</td><td>With chargingProfiled</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Remote start transaction with charging profile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_37</td><td>Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Get Composite Schedule</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_39</td><td>No ChargingProfile installed on Charging Station</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_40</td><td>Stacking ChargingProfiles</td><td>M</td><td></td><td>Remark for Charging Station: At least max stacklevel 1</td><td>SC-2</td><td>ChargingRateUnit</td></tr><tr><td>TC_K_41</td><td>Combining chargingProfilePurposes</td><td>M</td><td></td><td>Remark for Charging Station: amount of ChargingProfiles at least 3</td><td></td><td></td></tr><tr><td>TC_K_42</td><td>chargingRateUnit not supported</td><td>C</td><td></td><td>If one of the ChargingRateUnits is not supported.</td><td>NOT (SC-2.1 and SC-2.2)</td><td></td></tr><tr><td>TC_K_43</td><td>Specific EVSE</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_44</td><td>Charging Station</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_47</td><td>Unknown EVSEId</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Get Charging Profile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_29</td><td>Evseld 0</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_30</td><td>Evseld > 0</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_31</td><td>No Evseld</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_32</td><td>chargingProfiled</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_33</td><td>Evseld > 0 + stackLevel</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_34</td><td>Evseld > 0 + chargingLimitSource</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_35</td><td>Evseld > 0 + chargingProfilePurpose</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_36</td><td>Evseld > 0 + chargingProfilePurpose + stackLevel</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Clear Charging Profile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_05</td><td>With chargingProfiled</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_06</td><td>With stackLevel/purpose combination for one profile</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_07</td><td>With unknown stackLevel/purpose combination</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_08</td><td>Without previous charging profile</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_09</td><td>Clearing a TxDefaultProfile - With ongoing transaction</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_24</td><td>With stackLevel/purpose combination for multiple profiles</td><td>C</td><td></td><td>Applicable if the Charging Station has more than one EVSE.</td><td>HFS-8 > 1</td><td></td></tr></table>
+
+4.6. Test Cases Advanced Device Management
+
+<table><tr><td colspan="5"></td><td colspan="2">Related features</td></tr><tr><td>OCTT Id</td><td>OCPP Compliance Testing Tool scenario</td><td>Conf. Test for Charging Station</td><td>Conf. test for CSMS</td><td>Condition / remark</td><td>Feature no.</td><td>Feature</td></tr><tr><td></td><td>Get Base Report</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_12</td><td>ConfigurationInventory</td><td></td><td>M</td><td></td><td>C-17</td><td></td></tr><tr><td>TC_B_14</td><td>SummaryInventory</td><td>M</td><td>M</td><td></td><td>C-56</td><td></td></tr><tr><td></td><td>Get Custom Report</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_16</td><td>with component criteria</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_17</td><td>with component/variable</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_18</td><td>with componentCriteria and component/variables</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_B_54</td><td>with component/variable, but no instance</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_55</td><td>with component/variable/instance</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_56</td><td>with component/variable, but no evseld</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Get Monitoring Report</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_01</td><td>with monitoringCriteria</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_02</td><td>with component/variable</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_03</td><td>with component criteria and component/variable</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_47</td><td>Report all</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_60</td><td>with component criteria and list of components/variables</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Set Monitoring Base</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_05</td><td>success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_06</td><td>test removal custom monitors</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Set Variable Monitoring</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_08</td><td>One SetMonitoringData element</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_09</td><td>Multiple elements on different component and variable</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_10</td><td>Multiple monitors on the same component and variable</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_11</td><td>Unknown component</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_12</td><td>Value out of range - Delta monitor</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_13</td><td>Value out of range - Threshold monitor</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_15</td><td>Duplicate Variable type/severity combination</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_24</td><td>Periodic event</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_37</td><td>Unknown Variable</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_39</td><td>Component/Variable combination does NOT correspond</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_40</td><td>Replace Variable Monitor</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_41</td><td>Return to FactoryDefault</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_43</td><td>First SetMonitoringData and third SetMonitoringData are valid, but the second contains an out of range value</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_51</td><td>Modifying a VariableMonitor and trigger</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_52</td><td>Removing a VariableMonitor</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Set Monitoring Level</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_16</td><td>Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_17</td><td>Out of range</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Clear Monitoring</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_18</td><td>Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_19</td><td>Not found</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_44</td><td>Rejected</td><td>C</td><td>M</td><td>CS: If the Charging Station has at least one hardWired monitor.</td><td>AQ-5</td><td></td></tr><tr><td></td><td>Alert Event</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_20</td><td>Threshold value exceeded</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_21</td><td>HardWiredMonitor</td><td>C</td><td>M</td><td>CS: If the Charging Station has at least one hardWired monitor.</td><td>AQ-5</td><td></td></tr><tr><td>TC_N_45</td><td>Delta value exceeded</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_48</td><td>Variable monitoring on write only</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_49</td><td>LowerThreshold/UpperThreshold cleared after reboot</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_50</td><td>Periodic Triggered</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_N_53</td><td>Persistent over reboot</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_56</td><td>Delta value NOT numeric exceeded</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Offline Notification</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_22</td><td>OfflineMonitoringEventQueuingSeverity set equal or lower</td><td>C</td><td></td><td></td><td>DM-3</td><td>OfflineMonitoringEventQueuingSeverity</td></tr><tr><td>TC_N_23</td><td>OfflineMonitoringEventQueuingSeverity set higher</td><td>C</td><td></td><td></td><td>DM-3</td><td>OfflineMonitoringEventQueuingSeverity</td></tr></table>
+
+4.7. Test Cases Reservation
+
+<table><tr><td colspan="5"></td><td colspan="2">Related features</td></tr><tr><td>OCTT Id</td><td>OCPP Compliance Testing Tool scenario</td><td>Conf. Test for Charging Station</td><td>Conf. test for CSMS</td><td>Condition / remark</td><td>Feature no.</td><td>Feature</td></tr><tr><td></td><td>Reset Charging Station</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_B_24</td><td>Reserved persists reset</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Reserve a specific EVSE</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_H_01</td><td>Accepted - Valid idToken</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_H_02</td><td>Accepted - Different idToken</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_H_03</td><td>Occupied - EVSE Reserved</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_H_04</td><td>Occupied - EVSE Occupied</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_H_05</td><td>Faulted</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_H_06</td><td>Unavailable</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_H_07</td><td>Reservation Ended / not used</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_H_22</td><td>Configured to Reject</td><td>C</td><td>M</td><td>For CS: The configuration variableReservationCtrl.ReservationEnabled is implemented</td><td>R-3</td><td></td></tr><tr><td>TC_H_23</td><td>Replace reservation</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_H_19</td><td>Use a reserved EVSE with GroupId</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Reserve an unspecified EVSE</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_H_08</td><td>Accepted</td><td>C</td><td>C</td><td>For CS: Depending on configuration variableReservationNonSpecificEVSE</td><td>R-2</td><td>Support reservations of unspecified EVSE</td></tr><tr><td>TC_H_09</td><td>Occupied - EVSE Reserved</td><td>C</td><td></td><td>Depending on configuration variableReservationNonSpecificEVSE</td><td>R-2</td><td>Support reservations of unspecified EVSE</td></tr><tr><td>TC_H_10</td><td>Occupied - EVSE Occupied</td><td>C</td><td></td><td>Depending on configuration variableReservationNonSpecificEVSE</td><td>R-2</td><td>Support reservations of unspecified EVSE</td></tr><tr><td>TC_H_12</td><td>Unavailable</td><td>C</td><td></td><td>Depending on configuration variableReservationNonSpecificEVSE</td><td>R-2</td><td>Support reservations of unspecified EVSE</td></tr><tr><td>TC_H_13</td><td>Rejected</td><td>C</td><td></td><td>Depending on configuration variableReservationNonSpecificEVSE</td><td>R-2</td><td>Support reservations of unspecified EVSE</td></tr><tr><td>TC_H_14</td><td>Amount of EVSEs available equals the amount ofreservations</td><td>C</td><td>C</td><td>For CS: Depending on configuration variableReservationNonSpecificEVSEFor CSMS: this wil be tested with >1 EVSE</td><td>R-2</td><td>Support reservations of unspecified EVSE</td></tr><tr><td>TC_H_24</td><td>GroupIdToken</td><td>C</td><td></td><td>For CS: Depending on configuration variableReservationNonSpecificEVSE</td><td>R-2</td><td>Support reservations of unspecified EVSE</td></tr><tr><td></td><td>Reserve a connector with a specific type</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_H_15</td><td>Success</td><td>C</td><td>C</td><td></td><td>For CSMS: R-1, For CS: R-2</td><td>For CSMS: Support reservations of connectorType, For CS: Support for reservation of unspecified EVSE</td></tr><tr><td>TC_H_16</td><td>Amount of available connectors of a type equals the amount of reservations</td><td>C</td><td></td><td></td><td>R-2</td><td>Support for reservation of unspecified EVSE</td></tr><tr><td></td><td>Cancel reservation of an EVSE</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_H_17</td><td>Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_H_18</td><td>Rejected</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_H_20</td><td>Charging Station cancels reservation when Faulted</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_H_21</td><td>Charging Station cancels reservation when Unavailable</td><td>M</td><td></td><td></td><td></td><td></td></tr></table>
+
+4.8. Test Cases Advanced User Interface
+
+<table><tr><td colspan="5"></td><td colspan="2">Related features</td></tr><tr><td>OCTT Id</td><td>OCPP Compliance Testing Tool scenario</td><td>Conf. Test for Charging Station</td><td>Conf. test for CSMS</td><td>Condition / remark</td><td>Feature no.</td><td>Feature</td></tr><tr><td></td><td>Show costs to EV Driver</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_L_01</td><td>Show EV Driver running total cost during charging</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_L_02</td><td>Show EV Driver Final Total Cost After Charging</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_L_07</td><td>Show EV Driver running total cost during charging - transactionResponse</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Set Display Message</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_O_01</td><td>Success</td><td>M</td><td>M</td><td></td><td>UI-1 and UI-2</td><td>Supported MessagePriorities & Supported MessageFormats</td></tr><tr><td>TC_O_26</td><td>Rejected</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_O_13</td><td>Display message atStartTime</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_O_14</td><td>Remove message afterEndTime</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_O_17</td><td>NotSupportedPriority</td><td>C</td><td>M</td><td>CS: In case it does not support 1 of the MessagePriorities</td><td>NOT (UI-1.1 and UI-1.2 and UI-1.3)</td><td></td></tr><tr><td>TC_O_18</td><td>NotSupportedState</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_O_19</td><td>NotSupportedMessageFormat</td><td>C</td><td>M</td><td>CS: In case it does not support 1 of the MessageFormats</td><td>NOT (UI-2.1 and UI-2.2 and UI-2.3 and UI-2.4)</td><td></td></tr><tr><td>TC_O_20</td><td>Persistent over reboot</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_O_22</td><td>Multiple In front priority</td><td>C</td><td></td><td>If the Charging Station supports InFront priority</td><td>UI-1.2</td><td>Supported MessagePriorities InFront</td></tr><tr><td>TC_O_24</td><td>Second Alwaysfront priority</td><td>C</td><td></td><td>If the Charging Station supports AlwaysFront priority</td><td>UI-1.1</td><td>Supported MessagePriorities AlwaysFront</td></tr><tr><td>TC_O_36</td><td>State Charging</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_O_37</td><td>State Idle</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_O_38</td><td>State Unavailable</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_O_15</td><td>Language preference of the EV Driver</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_O_12</td><td>Replace DisplayMessage</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Set Display Message - Specific transaction</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_0_06</td><td>Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_0_10</td><td>UnknownTransaction</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_0_27</td><td>Display message atStartTime</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_0_28</td><td>Remove message afterEndTime</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_0_30</td><td>Multiple In front priority</td><td>C</td><td></td><td>CS: If value "InFront" supported</td><td>UI-1.2</td><td>Supported MessagePrioritiesInFront</td></tr><tr><td>TC_0_32</td><td>Second Alwaysfront priority</td><td>C</td><td></td><td>CS: If value "AlwaysFront" supported</td><td>UI-1.1</td><td>Supported MessagePrioritiesAlwaysFront</td></tr><tr><td></td><td>Get all Display Messages</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_0_02</td><td>Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_0_03</td><td>No DisplayMessages configured</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Get a Specific Display Message</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_0_07</td><td>Id</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_0_08</td><td>Priority</td><td>M</td><td>M</td><td></td><td>UI-1</td><td>Supported MessagePriorities</td></tr><tr><td>TC_0_09</td><td>State</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_0_11</td><td>Unknown parameters</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_0_33</td><td>No DisplayMessages configured</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_0_34</td><td>Known Id, but not matching State</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_0_35</td><td>Known Id, but not matching Priority</td><td>C</td><td></td><td>Only if multiple messagePriorities supported</td><td>( UI-1.1and UI-1.2) or ( UI-1.2 and UI-1.3) or ( UI-1.3and UI-1.1)</td><td>Supported MessagePriorities</td></tr><tr><td></td><td>Clear Display Message</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_0_04</td><td>Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_0_05</td><td>Unknown Key</td><td>M</td><td>M</td><td></td><td></td><td></td></tr></table>
+
+4.9. Test Cases ISO 15118 Support
+
+<table><tr><td colspan="5"></td><td colspan="2">Related features</td></tr><tr><td>OCTT Id</td><td>OCPP Compliance Testing Tool scenario</td><td>Conf. Test for Charging Station</td><td>Conf. test for CSMS</td><td>Condition / remark</td><td>Feature no.</td><td>Feature</td></tr><tr><td></td><td>Update Charging Station Certificate by request of CSMS</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_A_12</td><td>Success - V2G Certificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_A_13</td><td>Success - Combined Certificate</td><td>C</td><td>C</td><td>If Combined Charging Station Certificate is supported.</td><td>ISO-3</td><td>Combined Charging Station Certificate</td></tr><tr><td></td><td>Authorization using Contract Certificates 15118</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_50</td><td>Online - Local contract certificate validation - Accepted</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_C_51</td><td>Online - Local contract certificate validation - Rejected</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_C_52</td><td>Online - Central contract certificate validation - Accepted</td><td>C</td><td>M</td><td>Applicable if the Charging Station supports central contract validation.</td><td>ISO-5</td><td></td></tr><tr><td>TC_C_53</td><td>Online - Central contract validation fails</td><td>C</td><td></td><td>Applicable if the Charging Station supports central contract validation.</td><td>ISO-5</td><td></td></tr><tr><td>TC_C_54</td><td>Offline - ContractValidationOffline is true</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_C_55</td><td>Offline - ContractValidationOffline is false</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>End of charging process 15118</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_E_46</td><td>End of charging process 15118</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Set Charging Profile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_01</td><td>TxDefaultProfile - Specific EVSE</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_10</td><td>TxDefaultProfile - All EVSE</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_60</td><td>TxProfile with ongoing transaction on the specified EVSE</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_02</td><td>TxProfile without ongoing transaction on the specified EVSE</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_11</td><td>Unable to set TxProfile on all EVSE at once</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_03</td><td>ChargingStationMaxProfile</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_19</td><td>ChargingProfileKind is Recurring</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_12</td><td>ChargerRateUnit Rejected</td><td>C</td><td></td><td>If only 1 of the 2 ChargingRateUnits is supported by the Charging Station</td><td>NOT (SC-2.1 and SC-2.2)</td><td></td></tr><tr><td>TC_K_13</td><td>Persistent over reboot</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_14</td><td>Unexisting EVSEid</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_28</td><td>TxDefaultProfile with transaction ongoing</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_16</td><td>Unknown transactionId</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_21</td><td>ValidFrom</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_22</td><td>ValidTo</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_23</td><td>StartSchedule</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Replace charging profile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_04</td><td>With chargingProfileId</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Get Composite Schedule</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_39</td><td>No ChargingProfile installed on Charging Station</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_40</td><td>Stacking ChargingProfiles</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_41</td><td>Combining chargingProfilePurposes</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_42</td><td>chargingRateUnit not supported</td><td>C</td><td></td><td>If one of the ChargingRateUnits is not supported.</td><td>NOT (SC-2.1 and SC-2.2)</td><td></td></tr><tr><td>TC_K_43</td><td>Specific EVSE</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_44</td><td>Charging Station</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_47</td><td>Unknown EVSEId</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Get Charging Profile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_29</td><td>Evseld 0</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_30</td><td>Evseld > 0</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_31</td><td>No Evseld</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_32</td><td>chargingProfileId</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_33</td><td>Evseld > 0 + stackLevel</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_34</td><td>Evseld > 0 + chargingLimitSource</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_35</td><td>Evseld > 0 + chargingProfilePurpose</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_36</td><td>Evseld > 0 + chargingProfilePurpose + stackLevel</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Clear Charging Profile</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_05</td><td>With chargingProfileId</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_06</td><td>With stackLevel/purpose combination for one profile</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_24</td><td>With stackLevel/purpose combination for multiple profiles</td><td>C</td><td></td><td>Applicable if the Charging Station has more than one EVSE.</td><td>HFS-8 > 1</td><td></td></tr><tr><td>TC_K_07</td><td>With unknown stackLevel/purpose combination</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_08</td><td>Without previous charging profile</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_09</td><td>Clearing a TxDefaultProfile - With ongoing transaction</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Charging with load leveling based on High Level Communication</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_53</td><td>Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_54</td><td>No SASchedule (rejected)</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_55</td><td>EV charging profile exceeds limits</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_56</td><td>Offline</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Renegotiating a Charging Schedule</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_K_57</td><td>Initiated by EV</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_58</td><td>Initiated by CSMS</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_K_59</td><td>Initiated by CSMS - Send NotifyEVChargingNeeds</td><td></td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Certificate Installation EV</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_M_26</td><td>Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_27</td><td>Failed</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Certificate Update EV</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_M_28</td><td>Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_29</td><td>Failed</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Retrieve certificates from Charging Station</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_M_14</td><td>V2GRootCertificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_15</td><td>V2GCertificateChain</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_16</td><td>MORootCertificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Install CA certificate</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_M_03</td><td>V2GRootCertificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_04</td><td>MORootCertificate</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td></td><td>Get Charging Station Certificate status</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_M_24</td><td>Success</td><td>M</td><td>M</td><td></td><td></td><td></td></tr><tr><td>TC_M_25</td><td>Rejected</td><td>M</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>Clear Customer Information</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>TC_N_63</td><td>Clear and report - customerCertificate</td><td>C</td><td>C</td><td>If Support for retrieving / deleting CustomerInformation - CustomerCertificate is supported.</td><td>ISO-4</td><td></td></tr></table>
+
+# 5. OCPP 2.0.1 Mandatory Controller components per profile
+
+Controller components contain variables that describe the supported features of a Charging Station and influence its behavior. In OCPP 2.0.1 we have configuration variables that are required or optional, but these are contained by controller components. Functionalities cannot be tested without the accompanying controller component, so for certification the following controller components are mandatory:
+
+<table><tr><td>Certification Profile</td><td>Description</td></tr><tr><td>Core</td><td>OCPPCommCtrlr
+TxCtrlr
+DeviceDataCtrlr
+ClockCtrlr
+SecurityCtrlr
+SampledDataCtrlr
+AlignedDataCtrlr
+AuthCtrlr</td></tr><tr><td>Advanced Security</td><td>SecurityCtrlr (already part of Core)</td></tr><tr><td>Smart Charging</td><td>SmartChargingCtrlr</td></tr><tr><td>ISO 15118 Support</td><td>ISO15118Ctrlr
+SmartChargingCtrlr</td></tr><tr><td>Advanced Diagnostics</td><td>MonitoringCtrlr</td></tr><tr><td>Local Authorization List Management</td><td>LocalAuthListCtrlr</td></tr><tr><td>Advanced UI</td><td>TariffCostCtrlr
+DisplayMessageCtrlr</td></tr><tr><td>Reservation</td><td>ReservationCtrlr</td></tr></table>
+
+# 6. Appendix A: additional questions for the Protocol Implementation Conformance Statement
+
+To perform the certification testing, the test lab need some additional information (for the test selection). This concerns the following questions:
+
+# 6.1. Questions for Charging Stations
+
+<table><tr><td>Id</td><td>Additional questions for lab testing</td></tr><tr><td>AQ-1</td><td>Can the last CSMSRootCertificate be removed?</td></tr><tr><td>AQ-2</td><td>Does the Charging Station have a cable lock, which prevents the EV driver to connect the EV and EVSE before authorization?</td></tr><tr><td>AQ-3</td><td>Can the last ChargingStationCertificate be removed (via other means than OCPP)?</td></tr><tr><td>AQ-4</td><td>Is there at least one unsupported NumberOfPhases?</td></tr><tr><td>AQ-5</td><td>Does the Charging Station have at least one hardWired monitor? If yes, which hardWired monitor should be used for the certification test</td></tr><tr><td>AQ-6</td><td>Does the Charging Station have a pre-configured monitor? If yes, which pre-configured monitor should be used for the certification test</td></tr><tr><td>AQ-7</td><td>Is your Charging Station able to download firmware while there is an ongoing transaction?</td></tr><tr><td>AQ-8</td><td>Does your Charging Station enforce a selection of EVSE (by design) prior to authorization?</td></tr><tr><td>AQ-9</td><td>Does your Charging Station support charging an EV using IEC 61851-1 (Mode 3)?</td></tr></table>
+
+# 6.2. Questions for CSMSs
+
+<table><tr><td>Id</td><td>Additional questions for lab testing</td></tr><tr><td>AQ-1</td><td>Can your CSMS be configured to first respond to a BootNotificationRequest with status Pending or Rejected?</td></tr><tr><td>AQ-2</td><td>Is a FullInventory requested during onboarding / booting test cases?</td></tr><tr><td>AQ-6</td><td>Does the CSMS reject unknown Charging Stations during websocket connection setup?</td></tr></table>
+
+# 7. Appendix B: Hardware feature set
+
+The table below gives an overview of the hardware feature set Ids that are used for determining whether test cases are needed / applicable for certification.
+
+Table 4. Hardware features
+
+<table><tr><td>Id</td><td>Hardware Feature</td></tr><tr><td>HFS-1</td><td>Charging Station has a detachable cable</td></tr><tr><td>HFS-2</td><td>Charging Station has a fixed cable</td></tr><tr><td>HFS-3</td><td>Charging Station has AC support</td></tr><tr><td>HFS-4</td><td>Charging Station has DC support</td></tr><tr><td>HFS-5</td><td>Charging Station has 1 phase support</td></tr><tr><td>HFS-6</td><td>Charging Station has 2 phase support</td></tr><tr><td>HFS-7</td><td>Charging Station has 3 phase support</td></tr><tr><td>HFS-8</td><td>No. EVSEs of Charging Station</td></tr><tr><td>HFS-9</td><td>Communication technology</td></tr><tr><td>HFS-10</td><td>RFID readers</td></tr></table>
+
+# 8. Appendix C: Features vs. OCPP use cases
+
+The table below gives an overview of the use cases / configuration variables that the features are applicable for / referring to in the OCPP 2.0.1 Specification Part 2.
+
+Table 5. Optional features vs. related use cases
+
+<table><tr><td>Id</td><td>Feature</td><td>Related use cases</td></tr><tr><td colspan="3">Core</td></tr><tr><td>C-01</td><td>Support for offline authorization of transactions</td><td>C15, C10, C11, C12</td></tr><tr><td>C-02</td><td>Support for allowing Offline Authorization for Unknown Ids(OfflineTxForUnknownldEnabled)</td><td>C15</td></tr><tr><td>C-03</td><td>Support for maximizing energy for invalid ids (MaxEnergyOnInvalidId)</td><td>C15, E05</td></tr><tr><td>C-04</td><td>Support to limit StatusNotifications (MinimumStatusDuration)</td><td>Configuration Variable for G01</td></tr><tr><td>C-06</td><td>Authorization status after cable disconnected on EV side(StopTxOnEVSideDisconnect)</td><td></td></tr><tr><td>C-06.1</td><td>Support for maintaining authorization when cable disconnected on EV side</td><td>E10</td></tr><tr><td>C-06.2</td><td>Support for not maintaining authorization when cable disconnected on EV side</td><td>E09</td></tr><tr><td>C-07</td><td>Support for using a Master Pass for charging stations with UI (MasterPassGroupld)</td><td>C16</td></tr><tr><td>C-08</td><td>Support for using a Master Pass for charging stations without UI (MasterPassGroupld)</td><td>C16</td></tr><tr><td>C-09</td><td>Supported Transaction Start points (TxStartPoint)</td><td>E01</td></tr><tr><td>C-09.1</td><td>Start transaction options - EVConnected</td><td>E01-S2</td></tr><tr><td>C-09.2</td><td>Start transaction options - Authorized</td><td>E01-S3</td></tr><tr><td>C-09.3</td><td>Start transaction options - DataSigned</td><td>E01-S4</td></tr><tr><td>C-09.4</td><td>Start transaction options - PowerPathClosed</td><td>E01-S5</td></tr><tr><td>C-09.5</td><td>Start transaction options - EnergyTransfer</td><td>E01-S6</td></tr><tr><td>C-09.6</td><td>Start transaction options - ParkingBayOccupancy</td><td>E01-S1</td></tr><tr><td>C-10</td><td>Supported Transaction Stop points (TxStopPoint)</td><td>E06</td></tr><tr><td>C-10.1</td><td>Stop transaction options - EVConnected</td><td>E06-S2</td></tr><tr><td>C-10.2</td><td>Stop transaction options - Authorized</td><td>E06-S3</td></tr><tr><td>C-10.3</td><td>Stop transaction options - PowerPathClosed</td><td>E06-S5</td></tr><tr><td>C-10.4</td><td>Stop transaction options - EnergyTransfer</td><td>E06-S6</td></tr><tr><td>C-10.5</td><td>Stop transaction options - ParkingBayOccupancy</td><td>E06-S1</td></tr><tr><td>C-12</td><td>Unlocking of connector when cable disconnected on EV side(UnlockOnEVSideDisconnect)</td><td>E09, E10</td></tr><tr><td>C-12.1</td><td>Support for unlocking connector when cable disconnected on EV side</td><td>E09, E10</td></tr><tr><td>C-12.2</td><td>Support for not unlocking when cable disconnected on EV side</td><td>E09, E10</td></tr><tr><td>C-13</td><td>Support for Reset per EVSE (AllowReset)</td><td>B11, B12</td></tr><tr><td>C-14</td><td>Support for retrieving / deleting CustomerInformation - CustomerIdentifier</td><td>N09, N10</td></tr><tr><td>C-20</td><td>Allowing New Sessions Pending a FirmwareUpdate(AllowNewSessionsPendingFirmwareUpdate)</td><td>Configuration Variable for L01</td></tr><tr><td>C-21</td><td>Support for queuing all or only Transaction related messages until they are delivered to the CSMS (QueueAllMessages)</td><td>Optional</td></tr><tr><td colspan="3">Time related settings</td></tr><tr><td>C-23</td><td>Supported time sources (TimeSource)</td><td></td></tr><tr><td>C-25</td><td>Support for setting a TimeOffset (TimeOffset)</td><td>Configuration Variable (B05,B06)</td></tr><tr><td>C-26</td><td>Support for setting the TimeZone (TimeZone)</td><td>Configuration Variable (B05,B06)</td></tr><tr><td colspan="3"></td></tr><tr><td>C-28</td><td>Toggle sending clock aligned meter values when a transaction is ongoing / Idle(AlignedDataSendDuringIdle)</td><td>Configuration Variable for J01</td></tr><tr><td>C-29</td><td>TriggerMessage</td><td>F06</td></tr><tr><td>C-29.1</td><td>Trigger message - MeterValues</td><td>F06</td></tr><tr><td>C-29.2</td><td>Trigger message - TransactionEvent</td><td>F06</td></tr><tr><td>C-29.3</td><td>Trigger message - LogStatusNotification</td><td>F06</td></tr><tr><td>C-29.4</td><td>Trigger message - FirmwareStatusNotification</td><td>F06</td></tr><tr><td>C-29.5</td><td>Trigger message - StatusNotification</td><td>F06</td></tr><tr><td>C-29.6</td><td>Trigger message - BootNotification</td><td>F06</td></tr><tr><td colspan="3">Authorization options for local start</td></tr><tr><td>C-30</td><td>Authorization - using RFID ISO14443</td><td>C01</td></tr><tr><td>C-31</td><td>Authorization - using RFID ISO15693</td><td>C01</td></tr><tr><td>C-32</td><td>Authorization - using KeyCode</td><td>C04</td></tr><tr><td>C-33</td><td>Authorization - using locally generated id</td><td>C06</td></tr><tr><td>C-34</td><td>Authorization - MacAddress</td><td>C06</td></tr><tr><td>C-35</td><td>Authorization - NoAuthorization</td><td>C02</td></tr><tr><td colspan="3">Authorization options for remote start (mandatory to support at least one)</td></tr><tr><td>C-36</td><td>Authorization - using RFID ISO14443</td><td>C01</td></tr><tr><td>C-37</td><td>Authorization - using RFID ISO15693</td><td>C01</td></tr><tr><td>C-38</td><td>Authorization - using centrally, in the CSMS (or other server) generated id</td><td>C05</td></tr><tr><td>C-39</td><td>Authorization - NoAuthorization</td><td>C02</td></tr><tr><td colspan="3"></td></tr><tr><td>C-40</td><td>Supported MeterValue Measurands(SampledDataTx{Started,Updated,Ended}Measurands,AlignedDataMeasurands)</td><td>J01, J02</td></tr><tr><td>C-41</td><td>Supported Cipher Suites</td><td>See requirement A00.FR.318,A00.FR.319,A00.FR.421,A00.FR.422</td></tr><tr><td>C-42</td><td>Signed Metervales (SampledDataSignReadings)</td><td>J01, J02</td></tr><tr><td>C-43</td><td>Install and activate Firmware with ongoing transaction(s)(AllowNewSessionsPendingFirmwareUpdate)</td><td>Configuration Variable for L01</td></tr><tr><td>C-47</td><td>Support for falling back to default OCPP reconnection mechanism when NetworkConnection profile connection has failed</td><td>B10 (FR.07)</td></tr><tr><td>C-48</td><td>Authorization of remote start (AuthorizationRemoteStart)</td><td>F01, F02</td></tr><tr><td>C-48.1</td><td>Option for authorization in case of a remote start</td><td>F01, F02</td></tr><tr><td>C-48.2</td><td>Option for no authorization in case of a remote start</td><td>F01, F02</td></tr><tr><td>C-58</td><td>Option for disabling remote authorization (DisableRemoteAuthorization)</td><td>Configuration Variable (B05,B06)</td></tr><tr><td>C-49</td><td>Authorization Cache (AuthCacheEnabled)</td><td>C10, C11, C12</td></tr><tr><td>C-59</td><td>Option for disabling remote authorization for cached invalid idTokens(AuthCacheDisablePostAuthorize)</td><td>Configuration Variable for C10,C12</td></tr><tr><td>C-51</td><td>Configurable TxStartPoint</td><td>Configuration Variable for E01</td></tr><tr><td>C-52</td><td>Configurable TxStopPoint</td><td>Configuration Variable for E06</td></tr><tr><td>C-53</td><td>Support for lifetime cached token (AuthCacheLifeTime)</td><td>Configuration Variable for C10</td></tr><tr><td>C-54</td><td>Supported policies for replacing cached entries (AuthCachePolicy)</td><td>Configuration Variable for C10,C11,C12</td></tr><tr><td>C-56</td><td>Support for providing the SummaryInventory</td><td>B07</td></tr><tr><td>C-57</td><td>Support for cancelling ongoing log file upload</td><td>N01 (AcceptedCanceled)</td></tr><tr><td>C-60</td><td>Support for cancelling ongoing firmware update</td><td>L01, L02 (AcceptedCanceled)</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">Advanced Security</td></tr><tr><td>AS-2</td><td>Additional root certificate check mechanism implemented(AdditionalRootCertificateCheck)</td><td>Configuration Variable for M05</td></tr><tr><td>AS-3</td><td>Update Charging Station Certificate - CertificateSignedRequest Timeout(CertSigningWaitMinimum,CertSigningRepeatTimes)</td><td>Configuration Variable for A02,A03</td></tr><tr><td colspan="3">Smart Charging</td></tr><tr><td>SC-2</td><td>Supported charging rate units (ChargingScheduleChargingRateUnit)</td><td>K01</td></tr><tr><td>SC-4</td><td>Support for TxDefaultProfile on EVSEID #0</td><td>K01</td></tr><tr><td colspan="3">Reservation</td></tr><tr><td>R-1</td><td>Support for reservations of connectorType</td><td>H01.S3</td></tr><tr><td>R-2</td><td>Support for reservations of unspecified EVSE (ReservationNonEvseSpecific)</td><td>H01.S1</td></tr><tr><td>R-3</td><td>Reservation support (ReservationEnabled)</td><td>Configuration Variable for H01</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">Advanced Device Management</td></tr><tr><td>DM-3</td><td>Queue notifyEventRequest messages for specific severities(OfflineMonitoringEventQueuingSeverity)</td><td>Configuration Variable for N07</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">ISO 15118 support</td></tr><tr><td>ISO-3</td><td>Combined charging station certificate (for both OCPP and ISO 15118)</td><td>A02/A03</td></tr><tr><td>ISO-4</td><td>Support for retrieving / deleting CustomerInformation - CustomerCertificate</td><td>N09/N10</td></tr><tr><td>ISO-5</td><td>Charging Station can provide a contract certificate that it cannot validate to the CSMS</td><td>Configuration Variable for C07</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">Local Authorization List Management</td></tr><tr><td>LA-1</td><td>Authorization list support (LocalAuthListEnabled)</td><td>Configuration Variable for C13</td></tr><tr><td>LA-2</td><td>Support for GetLocalListVersion</td><td>D02</td></tr><tr><td>LA-3</td><td>Option for disabling remote authorization for invalid idTokens stored at the LocalAuthorization List (LocalAuthListDisablePostauthorize)</td><td>Configuration Variable for C14</td></tr><tr><td colspan="3"></td></tr><tr><td colspan="3">Advanced User Interface</td></tr><tr><td>UI-1</td><td>Supported message priorities(DisplayMessageSupportedPriorities)</td><td>001</td></tr><tr><td>UI-2</td><td>Supported message formats(DisplayMessageSupportedFormats)</td><td>001</td></tr></table>
--- /dev/null
+# OCPP
+
+# Table of Contents
+
+1. Introduction. 2
+
+1.1. About this document 2
+1.2. Conventions 2
+
+2. Test Cases Charging Station 3
+
+2.1. General pre conditions & tool validations 3
+2.2.A Security 4
+2.3.B Provisioning 27
+2.4.C Authorization 90
+2.5.D Local Authorization List Management 156
+2.6.E Transactions 165
+2.7.F Remote Control 218
+2.8.G Availability 242
+2.9.H Reservation 265
+2.10.I Tariff and Cost 291
+2.11.J MeterValues 296
+2.12.K SmartCharging 308
+2.13.L Firmware Management 368
+2.14.M ISO15118CertificateManagement 410
+2.15.N Diagnostics 436
+2.16.O Display Message 506
+2.17.P DataTransfer 545
+2.18. Reusable states 548
+2.19. Memory states 571
+
+3. Test Cases Charging Station Management System 578
+
+3.1. General pre/post conditions & tool validations 578
+3.2.A Security 579
+3.3.B Provisioning 598
+3.4.C Authorization 622
+3.5.D Local Authorization List Management 640
+3.6.E Transactions 646
+3.7.F RemoteControl 676
+3.8.G Availability 692
+3.9.H Reservation 702
+3.10.I Tariff and Cost 713
+3.11.J MeterValues 716
+3.12.K SmartCharging 726
+3.13.L Firmware Management 761
+3.14.M ISO15118CertificateManagement 787
+3.15.N Diagnostics 805
+3.16.O Display Message 835
+3.17.P DataTransfer 856
+3.18. Reusable states 858
+
+# 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
+
+<table><tr><td>Version</td><td>Date</td><td>Modified by</td><td>Description</td></tr><tr><td>OCPP 2.0.1 Edition 3</td><td>2024-05-06</td><td>Open Charge Alliance</td><td>OCPP 2.0.1 Edition 3. All errata from OCPP 2.0.1 Part 6 until and including Errata 2024-04 have been merged into this version of the specification. In this edition all certification profiles are available.</td></tr><tr><td>1.0</td><td>2023-06-30</td><td>Open Charge Alliance</td><td>Release for Core & Advanced Security</td></tr></table>
+
+# 1. Introduction
+
+# 1.1. About this document
+
+This document is created to describe a set of valid test cases for OCPP 2.0.1. These test cases can be executed using the OCPP Compliance Testing Tool (OCTT) for OCPP 2.0.1. The scenarios in the tool are described in detail including the expected behaviour of the System Under Test (SUT). This document is divided in chapters, each describing an OCPP functional block as can be found in the official OCPP specification. These are:
+
+A. Security
+B. Provisioning
+C. Authorization
+D. Local Authorization List Management
+E. Transactions
+F. Remote Control
+G. Availability
+H. Reservation
+I. Tariff and Cost
+J. Meter Values
+K. Smart Charging
+L. Firmware Management
+M. ISO 15118 Certificate Management
+N. Diagnostics
+O. Display Message
+P. Data Transfer
+
+The scenarios in this document are also part of the OCA certification process of OCPP. Please refer to OCPP 2.0.1 Part 5 - Certification Profiles for more information about the relation between certification profiles and the test scenarios in this document.
+
+# 1.2. Conventions
+
+The following conventions / rules apply to all test cases, unless explicitly mentioned otherwise. These will not be mentioned separately at every test case.
+
+- The OCPP specification is always leading.
+ This document does not specify which tests need to be passed for certification, this will be specified in a separate document.
+- All messages shall comply with the OCPP 2.0.1 schemas from the OCPP specification.
+- The messages are to be sent as mentioned in the scenario details.
+- Validations will be mentioned and grouped per step.
+- Messages, datatypes and configuration variables will convey to the following formatting rules:
+
+。Datatypes, messages and configuration variables are displayed bold.
+Values are displayed italic.
+
+# 2. Test Cases Charging Station
+
+# 2.1. General pre conditions & tool validations
+
+General conditions-validations are overruled by testcase specific conditions-validations, unless specifically stated otherwise.
+
+# General pre conditions:
+
+- Charging Station is Accepted by the CSMS
+- Charging Station has a stable active connection to the CSMS
+- Charging Station connectors are available
+- Charging Station is Idle, with no active transactions
+- Charging Station is clear of faults
+- Charging Station has no charging schedules active
+- Charging Station has no active reservations
+- The Configuration variable AuthCtrl.LocalPreAuthorization is set to false.
+- Charging Station has no more OCPP messages to be send in queue
+- Charging Station is not busy with transfer of diagnostics
+- Charging Station is not busy with download of firmware
+- Charging Station is not upgrading firmware
+- Charging Station is ready to accept/start a charging session
+- Charging Station has no Display message configured
+- Charging Station has no active custom monitors
+
+# General tool rules/validations:
+
+- TransactionEventRequest messages don't have to be sent in chronological order. However the provided seqNo are sequentially numbered in chronological order. This way the CSMS is able to determine whether all messages of a transaction have been received.
+- After connecting/disconnecting the EV and EVSE, the Charging Station SHALL report the new status of its connector and report any queued TransactionRequest(s). These message are allowed to be sent in any order.
+- If the transaction was authorized with Reusable State Authorized remote, then the first TransactionEventRequest sent after receiving a RequestStartTransactionRequest message will contain triggerReason with value \_RemoteStart (This will overrule the step specific tool validations) AND will contain transactionInforemoteStartId
+- The first TransactionEventRequest of a transaction MUST contain/eventType Started.
+ The first TransactionEventRequest sent after connecting the EVSE and EV MUST contain evse.id and evseconnectorId
+- The first TransactionEventRequest sent after presenting the idToken MUST contain idToken with value <Configured valid idToken fields>
+- If the energy transfer was stopped with Reusable State StopAuthorized local, then the \_stoppedReason of the last TransactionEventRequest of that transaction with eventType Ended, must have value Local OR be omitted.
+- When validating/comparing time / datetime values, the OCTT will in most cases accept a configurable deviation. The certification labs will configure a deviation of 4 seconds.
+- Every FirmwareStatusNotificationRequest sent for a firmware update SHALL contain the same requestId as the UpdateFirmwareRequest that started the firmware update.
+- The list of ChargingSchedulePeriod elements in a chargingSchedule SHALL be ordered by increasing values of ChargingSchedulePeriod.startPeriod. This means the list is in chronological order.
+- When idToken type NoAuthorization is configured to be used, the OCTT will act/validate differently. No AuthorizationRequest 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.
+
+# 2.2. A Security
+
+Table 1. Test Case Id: TC_A_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Basic Authentication - Valid username/password combination</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A00, B01</td></tr><tr><td>Requirement(s)</td><td colspan="2">A00.FR.202, A00.FR.203, A00.FR.204, A00.FR.205, A00.FR.301, A00.FR.302, A00.FR.304 AND B01.FR.01, B01.FR.05, B01.FR.09</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station uses Basic authentication to authenticate itself to the CSMS, when using security profile 1 or 2.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to authenticate itself to the CSMS using Basic Authentication.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The charging station supports security profile 1 and/or 2
+- The active NetworkConnectionProfile uses either security profile 1 OR 2.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+SecurityCtrl.BasicAuthPassword is <Configured basicAuthPassword></td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Booted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+The authorization header of the HTTP upgrade request must be formatted as follows:
+AUTHORIZATION: Basic<Base64 encoded<ChargingStationId>:<Configured basicAuthPassword>)-
+The ChargingStationId, must equal the ChargingStationId provided at the end of the connection url string of the HTTP request.
+- BasicAuthPassword must consist of minimum 16 and maximum 40 characters
+- BasicAuthPassword may only contain alpha-numeric characters and the special characters allowed by identifierString.</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 2. Test Case Id: TC_A_04_CS
+
+<table><tr><td>Test case name</td><td colspan="2">TLS - server-side certificate - Valid certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A00</td></tr><tr><td>Requirement(s)</td><td colspan="2">A00.FR.309,A00.FR.312,A00.FR.313,A00.FR.319,A00.FR.321,A00.FR.412,A00.FR.422</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS uses a server-side certificate to identify itself to the Charging Station, when using security profile 2 or 3.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to receive a server certificate provided by the CSMS and setup a secured WebSocket connection.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The charging station supports security profile 2 and/or 3
+- The active NetworkConnectionProfile uses either security profile 2 OR 3.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is Booting</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station initiates a TLS handshake and sends a Client Hello to the OCTT.</td><td>2. The OCTT responds with a Server Hello With the <Configured server certificate></td></tr><tr><td>3. The Charging Station performs the following actions:
+Send client certificate
+Client Key Exchange
+Certificate verify
+Change Cipher Spec
+Finished
+Note(s):
+- The client certificate is only sent when the Charging Station uses security profile 3.</td><td>4. The OCTT performs the following actions:
+Change Cipher Spec Finished</td></tr><tr><td>5. The Charging Station sends a HTTP upgrade request to the OCTT
+Note(s):
+- The HTTP request only contains a username/password combination when the Charging Station uses security profile 2.</td><td>6. The OCTT upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td>7. The Charging Station sends a BootNotificationRequest</td><td>8. The OCTT responds with a BootNotificationResponse with status Accepted</td></tr><tr><td>9. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>10. The OCTT responds accordingly.</td></tr><tr><td>Test case name</td><td>TLS - server-side certificate - Valid certificate</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+The OCTT validates the following before sending the server certificate:
+- The Charging Station must use TLS version 1.2 or above
+At least the following set of cipher suites must be supported:
+(TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+AND
+TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384)
+OR
+(TLS_RSA_WITH_AES_128_GCM_SHA256
+AND
+TLS_RSA_WITH_AES_256_GCM_SHA384)
+* Step 9:
+Message: StatusNotificationRequest
+- connectorStatus Available
+Message: NotifyEventRequest
+- eventData[0].trigger Delta
+- eventData[0].actualValue "Available"
+- eventData[0].component.name "Connector"
+- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 3. Test Case Id: TC_A_05_CS
+
+<table><tr><td>Test case name</td><td colspan="2">TLS - server-side certificate - Invalid certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_05_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A00</td></tr><tr><td>Requirement(s)</td><td colspan="2">A00.FR.309,A00.FR.310,A00.FR.311,A00.FR.412,A00.FR.413,A00.FR.414</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS uses a server-side certificate to identify itself to the Charging Station, when using security profile 2 or 3.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to terminate the connection when the received server certificate is invalid.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The charging station supports security profile 2 and/or 3
+- The active NetworkConnectionProfile uses either security profile 2 OR 3.
+- This testcase can be executed multiple times, using different kinds of invalid certificates:Unknown certificate
+expired certificate
+certificate with commonName that does not equal the FQDN of the CSMS.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+OCPPCommCtrl.NetworkProfileConnectionAttempts is 2</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is Booting</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station initiates a TLS handshake and sends a Client Hello to the OCTT.</td><td>2. The OCTT responds with a Server Hello With a <Configured invalid server certificate></td></tr><tr><td>3. The Charging Station deems the server certificate invalid and terminates the connection.</td><td></td></tr><tr><td>4. The Charging Station initiates a TLS handshake and sends a Client Hello to the OCTT.</td><td>5. The OCTT responds with a Server Hello With the <Configured server certificate></td></tr><tr><td rowspan="5"></td><td>6. The Charging Station performs the following actions:Send client certificateClient Key ExchangeCertificate verifyChange Cipher SpecFinishedNote(s):- The client certificate is only sent when the Charging Station uses security profile 3.</td><td>7. The OCTT performs the following actions:Change Cipher SpecFinished</td></tr><tr><td>8. The Charging Station sends a HTTP upgrade request to the OCTTNote(s):- The HTTP request only contains a username/password combination when the Charging Station uses security profile 2.</td><td>9. The OCTT upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td>10. The Charging Station sends a BootNotificationRequest</td><td>11. The OCTT responds with a BootNotificationResponse with status Accepted</td></tr><tr><td>12. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>13. The OCTT responds accordingly.</td></tr><tr><td>14 The Charging Station sends a SecurityEventNotificationRequest</td><td>15 The OCTT responds with a SecurityEventNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 14:Message:SecurityEventNotificationRequest-type must be InvalidCsmsCertificate</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 4. Test Case Id: TC_A_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">TLS - server-side certificate - TLS version too low</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_06_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A00</td></tr><tr><td>Requirement(s)</td><td colspan="2">A00.FR.314,A00.FR.316,A00.FR.416,A00.FR.417,A00.FR.419</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS uses a server-side certificate to identify itself to the Charging Station, when using security profile 2 or 3.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to terminate the connection when it notices the used TLS version is lower than 1.2.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The charging station supports security profile 2 and/or 3
+- The active NetworkConnectionProfile uses either security profile 2 OR 3.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+OCPPCommCtrlr.NetworkProfileConnectionAttempts is 1</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station initiates a TLS handshake and sends a Client Hello to the OCTT.</td><td>2. The OCTT responds with a Server Hello, but uses a TLS version lower than 1.2
+With a <Configured server certificate></td></tr><tr><td>3. The Charging Station notices the used TLS version is lower than 1.2 and terminates the connection.</td><td></td></tr><tr><td>4. The Charging Station initiates a TLS handshake and sends a Client Hello to the OCTT.</td><td>5. The OCTT responds with a Server Hello
+With the <Configured server certificate></td></tr><tr><td rowspan="7"></td><td>6. The Charging Station performs the following actions:
+Send client certificate
+Client Key Exchange
+Certificate verify
+Change Cipher Spec
+Finished
+Note(s):
+- The client certificate is only sent when the Charging Station uses security profile 3.</td><td>7. The OCTT performs the following actions:
+Change Cipher Spec
+Finished</td></tr><tr><td>8. The Charging Station sends a HTTP upgrade request to the OCTT
+Note(s):
+- The HTTP request only contains a username/password combination when the Charging Station uses security profile 2.</td><td>9. The OCTT upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td>10. The Charging Station sends a BootNotificationRequest</td><td>11. The OCTT responds with a BootNotificationResponse with status Accepted</td></tr><tr><td>12. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>13. The OCTT responds accordingly.</td></tr><tr><td>14 The Charging Station sends a SecurityEventNotificationRequest</td><td>15 The OCTT responds with a SecurityEventNotificationResponse</td></tr><tr><td>16 The Charging Station sends a SecurityEventNotificationRequest</td><td>17 The OCTT responds with a SecurityEventNotificationResponse</td></tr><tr><td colspan="2">Note(s):
+- The order in which the requests of steps 12 and 14 and 16 arrive is not relevant.
+- Steps 16 and 17 are optional as the Charging Station might not be able to detect that the TLS handshake failed, because of invalid TLS version.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 14:
+Message: SecurityEventNotificationRequest
+-type must be StartupOfTheDevice or ResetOrReboot</td></tr><tr><td colspan="2">* Step 16:
+Message: SecurityEventNotificationRequest
+-type must be InvalidTLSVersion</td></tr></table>
+
+Table 5. Test Case Id: TC_A_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">TLS - Client-side certificate - valid certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A00</td></tr><tr><td>Requirement(s)</td><td colspan="2">A00.FR.401,A00.FR.402,A00.FR.415,A00.FR.416,A00.FR.422,A00.FR.502,A00.FR.503,A00.FR.507,A00.FR.508,A00.FR.511</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station uses a client-side certificate to identify itself to the CSMS, when using security profile 3.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to provide a valid client certificate and setup a secured WebSocket connection.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The charging station supports security profile 3
+- The active NetworkConnectionProfile uses security profile 3.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is Booting</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station initiates a TLS handshake and sends a Client Hello to the OCTT.</td><td>2. The OCTT responds with a Server Hello With the <Configured server certificate></td></tr><tr><td>3. The Charging Station performs the following actions:
+Send client certificate
+Client Key Exchange
+Certificate verify
+Change Cipher Spec
+Finished</td><td>4. The OCTT performs the following actions:
+Change Cipher Spec Finished</td></tr><tr><td>5. The Charging Station sends a HTTP upgrade request to the OCTT</td><td>6. The OCTT upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td>7. The Charging Station sends a BootNotificationRequest</td><td>8. The OCTT responds with a BootNotificationResponse with status Accepted</td></tr><tr><td>9. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>10. The OCTT responds accordingly.</td></tr><tr><td>Test case name</td><td>TLS - Client-side certificate - valid certificate</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 4: The OCTT validates the following before finishing the TLS handshake: - The Charging Station must use TLS version 1.2 or above At least the following set of cipher suites must be supported: (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 AND TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384) OR (TLS_RSA_WITH_AES_128_GCM_SHA256 AND TLS_RSA_WITH_AES_256_GCM_SHA384) - When using RSA or DSA the key must be at least 2048 bits long. and when using elliptic curve cryptography the key must be at least 224 bits long. - The received Client side certificate must be transmitted in the X.509 format encoded in Privacy-Enhanced Mail (PEM) format. - The certificate must include a serial number. - The subject field of the certificate must contain a commonName RDN which consists of the unique serial number of the Charging Station. NOTE: If one of the above validations fails, the OCTT can still setup the WebSocket connection (if it is able to), but the testcase will FAIL and the OCTT reports why it failed. * Step 9: Message: StatusNotificationRequest - connectorStatus Available Message: NotifyEventRequest - eventData[0].trigger Delta - eventData[0].actualValue "Available" - eventData[0].component.name "Connector" - eventData[0].variable.name "AvailabilityState"</td></tr><tr><td>Post scenario validations: N/a</td></tr></table>
+
+Table 6. Test Case Id: TC_A_09_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Password for HTTP Basic Authentication - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_09_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A01</td></tr><tr><td>Requirement(s)</td><td colspan="2">A01.FR.01, A01.FR.11, A01.FR.12, B01.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case defines how to use the BasicAuthPassword, the password used to authenticate Charging Stations in security profile 1 (Basic Authentication) and security profile 2 (TLS with Basic Authentication)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to accept and store and log the new BasicAuthPassword as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The charging station supports security profile 1 and/or 2</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetVariablesResponse</td><td>1. The OCTT sends a SetVariablesRequest withsetVariableData[1]:- variable.name = "BasicAuthPassword"- component.name = "SecurityCtrl"- attributeValue = "<NewPassword>"</td></tr><tr><td>3. The ChargingStation sends a HTTP upgrade request with an Authorization header, containing a username/password combination (with the new BasicAuthPassword).Note(s):- The Authorization header is formatted as follows:AUTHORIZATION: Basic<Base64 encoded(<Configured ChargingStationId>:<NEW BasicAuthPassword>)</td><td>4. The OCTT validates the username/passowald combination AND upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td>5. The Charging Station sends a BootNotificationRequest</td><td>6. The OCTT responds with aBootNotificationResponse</td></tr><tr><td>7. The Charging Station notifies the OCTT about the current state of all connectors.</td><td>8. The OCTT responds accordingly.</td></tr><tr><td colspan="2">Note(s):- Steps 5, 6, 7, and 8 are only required when status in Step 2 is RebootRequired</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: SetVariablesResponse-status must be Accepted or RebootRequired</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 7. Test Case Id: TC_A_10_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Password for HTTP Basic Authentication - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_10_CS</td></tr><tr><td>Use case ld(s)</td><td colspan="2">A01</td></tr><tr><td>Requirement(s)</td><td colspan="2">A01.FR.01, A01.FR.11, A01.FR.12</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case defines how to use the BasicAuthPassword, the password used to authenticate Charging Stations in security profile 1 (Basic Authentication) and security profile 2 (TLS with Basic Authentication)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reject the new BasicAuthPassword.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The charging station supports security profile 1 and/or 2</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetVariablesResponse</td><td>1. The OCTT sends a SetVariablesRequest
+setVariableData[1]:
+- variable.name = "BasicAuthPassword"
+- component.name = "SecurityCtrl"
+- attributeValue = "<NewPassword which is less than 16 characters>"</td></tr><tr><td></td><td>3. The ChargingStation sends a HTTP upgrade request with an Authorization header, containing a username/password combination (with the old BasicAuthPassword).
+Note(s):
+- The Authorization header is formatted as follows:
+AUTHORIZATION: Basic <Base64 encoded(<Configured ChargingStationId>:<OLD BasicAuthPassword>)</td><td>4. The OCTT validates the username/passport combination AND upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td></td><td colspan="2">5. Execute Reusable State Booted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: SetVariablesResponse
+- status must be Rejected</td></tr><tr><td colspan="2">Post scenario validations:
+BasicAuthPassword should be <Configured BasicAuthPassword>
+N/a</td></tr></table>
+
+Table 8. Test Case Id: TC_A_11_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Certificate by request of CSMS - Success - Charging Station Certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_11_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A02 & F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">A02.FR.02, A02.FR.03, A02.FR.06, A02.FR.08, A02.FR.09 & F06.FR.04,F06.FR.05,F06.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to update its charging station certificate using the TriggerMessageRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to update its Charging Station Certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The charging station supports security profile 3
+- The active NetworkConnectionProfile uses security profile 3.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State RenewChargingStationCertificate for certificateType ChargingStationCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 9. Test Case Id: TC_A_12_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Certificate by request of CSMS - Success - V2G Certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_12_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A02 & F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">A02.FR.02, A02.FR.03, A02.FR.06,A02.FR.13,A02.FR.15 & F06.FR.04,F06.FR.05,F06.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to update its charging station certificate using the TriggerMessageRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to update its V2G Charging Station Certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports ISO 15118.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Memory State RenewV2GChargingStationCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 10. Test Case Id: TC_A_13_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Certificate by request of CSMS - Success - Combined Certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_13_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A00, A02</td></tr><tr><td>Requirement(s)</td><td colspan="2">A00.FR.428,A02.FR.02, A02.FR.03, A02.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to update its charging station certificate using the TriggerMessageRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to update its combined V2G / Charging Station Certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports security profile 3
+- The active NetworkConnectionProfile uses security profile 3.
+- The Charging Station supports ISO 15118.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequest With requestedMessage SignCombinedCertificate</td></tr><tr><td>3 The Charging Station sends a SignCertificateRequest</td><td>4. The OCTT responds with a SignCertificateResponse With status Accepted</td></tr><tr><td>6. The Charging Station responds with a CertificateSignedResponse</td><td>5. The OCTT sends a CertificateSignedRequest With certificateChain <Certificate generated from the received CSR from step 3 and signed by the V2GRoot OR SubCA certificate from the configured V2G certificate chain></td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:
+Message: TriggerMessageResponse
+- status must be Accepted
+* Step 3:
+Message: SignCertificateRequest
+-csr must contain <An CSR that meets the following requirements:
+The key must be at least 224 bits long.
+The received CSR must be transmitted as described in RFC 2986 and then encoded in Privacy-Enhanced Mail (PEM) format>
+* Step 6:
+Message: CertificateSignedResponse
+-csr must be Accepted
+Post scenario validations:
+N/a</td></tr></table>
+
+Table 11. Test Case Id: TC_A_14_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Certificate by request of CSMS - Invalid certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_14_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A02</td></tr><tr><td>Requirement(s)</td><td colspan="2">A02.FR.07,A03.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to update its charging station certificate using the TriggerMessageRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to discard an invalid certificate and report a security event.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports security profile 3
+- The active NetworkConnectionProfile uses security profile 3.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="5">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequest With requestedMessage SignChargingStationCertificate</td></tr><tr><td>3 The Charging Station sends a SignCertificateRequest</td><td>4. The OCTT responds with a SignCertificateResponse With status Accepted</td></tr><tr><td>6. The Charging Station responds with a CertificateSignedResponse</td><td>5. The OCTT sends a CertificateSignedRequest With certificateChain <Configured invalid_signingCertificate> certificateType ChargingStationCertificate</td></tr><tr><td>7 The Charging Station sends a SecurityEventNotificationRequest</td><td>8 The OCTT responds with a SecurityEventNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message: TriggerMessageResponse
+-status must be Accepted
+* Step 3:
+Message: SignCertificateRequest
+-csr must contain <An CSR that meets the following requirements:
+When using RSA or DSA the key must be at least 2048 bits long.
+and when using elliptic curve cryptography the key must be at least 224 bits long.
+The received CSR must be transmitted as described in RFC 2986 and then encoded in Privacy-Enhanced Mail (PEM) format.>
+* Step 6:
+Message: CertificateSignedResponse
+-status must be Rejected
+* Step 7:
+Message: SecurityEventNotificationRequest
+-type must be InvalidChargingStationCertificate</td><td></td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 12. Test Case Id: TC_A_15_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Certificate by request of CSMS - SignCertificateRequest Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_15_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to update its charging station certificate using the TriggerMessageRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to discard an invalid certificate and report a security event.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports security profile 3
+- The active NetworkConnectionProfile uses security profile 3.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequest With requestedMessage
+SignChargingStationCertificate</td></tr><tr><td>3 The Charging Station sends a SignCertificateRequest</td><td>4. The OCTT responds with a SignCertificateResponse With status Rejected</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: TriggerMessageResponse
+- status must be Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 13. Test Case Id: TC_A_23_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Certificate by request of CSMS - CertificateSignedRequest Timeout</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_23_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A02 & F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">A02.FR.17,A02.FR.18</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to update its charging station certificate using the TriggerMessageRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a new signCertificateRequest when it did not receive a certificateSignedRequest after the configured timeout.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The charging station supports security profile 3
+- The Charging Station supports the CertificateSignedRequest Timeout feature</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+SecurityCtrl.CertSigningWaitMinimum is <Configured CertSigningWaitMinimum>
+SecurityCtrl.CertSigningRepeatTimes is 1</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="8">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequest With requestedMessage
+SignChargingStationCertificate</td></tr><tr><td>3 The Charging Station sends a SignCertificateRequest</td><td>4. The OCTT responds with a SignCertificateResponse With status Accepted</td></tr><tr><td></td><td>5. The OCTT does NOT send the CertificateSignedRequest and waits for the SignCertificateRequest to be resend after the <Configured CertSigningWaitMinimum></td></tr><tr><td>6 The Charging Station sends a SignCertificateRequest</td><td>7. The OCTT responds with a SignCertificateResponse With status Accepted</td></tr><tr><td></td><td>8. The OCTT does NOT send the CertificateSignedRequest and waits for the SignCertificateRequest to be resend after the <Configured CertSigningWaitMinimum> times 2</td></tr><tr><td>9 The Charging Station sends a SignCertificateRequest</td><td>10. The OCTT responds with a SignCertificateResponse With status Accepted</td></tr><tr><td>12. The Charging Station responds with a CertificateSignedResponse</td><td>11. The OCTT sends a CertificateSignedRequest With certificateChain <Certificate generated from the received CSR from step 3 and signed by the provided CSMS Root certificate>
+certificateType ChargingStationCertificate</td></tr><tr><td>Test case name</td><td>Update Charging Station Certificate by request of CSMS - CertificateSignedRequest Timeout</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message: TriggerMessageResponse
+- status must be Accepted
+* Step 3/6/9:
+Message: SignCertificateRequest
+- csv must contain <An CSR that meets the following requirements:
+When using RSA or DSA the key must be at least 2048 bits long.
+and when using elliptic curve cryptography the key must be at least 224 bits long.
+The received CSR must be transmitted as described in RFC 2986 and then encoded in Privacy-Enhanced Mail (PEM) format.>
+* Step 5:
+- The Charging Station shall not resend the SignCertificateRequest before the <Configured CertSigningWaitMinimum> expired
+* Step 8:
+- The Charging Station shall not resend the SignCertificateRequest before the <Configured CertSigningWaitMinimum> times 2 expired
+* Step 12:
+Message: CertificateSignedResponse
+- status must be Accepted</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 14. Test Case Id: TC_A_19_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Upgrade Charging Station Security Profile - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_19_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A05</td></tr><tr><td>Requirement(s)</td><td colspan="2">A05.FR.04,A05.FR.05,A05.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS updates the connection details on the Charging Station, to increase the security profile level.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to increase the security profile level when configured to do so by the CSMS.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Security profile must be set to 1 or 2</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:If configured <Security profile> is 1, then CertificateInstalledIf configured <Security profile> is 2, then RenewChargingStationCertificate</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="8">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>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 messageTimeout> -connectionData.ocppCsmsUrl <Configured ocppCsmsUrl> -connectionData.ocpptInterface <Configured ocpptInterface> -connectionData.ocppVersion OCPP20 -connectionData.securityProfile <Configured securityProfile + 1></td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The OCTT sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is "<Configured configurationSlot + 1>,<Configured configurationSlot>"</td></tr><tr><td>6. The Charging Station responds with a ResetResponse</td><td>5. The OCTT sends a ResetRequest with type OnIdleNote(s):- This step will only be executed when the status RebootRequired is returned at step 4.</td></tr><tr><td>7. The Charging Station reconnects to the OCTT with security profile is <Configured securityProfile + 1></td><td>8. The OCTT accepts the connection attempt.</td></tr><tr><td colspan="2">9. Execute Reusable State Booted</td></tr><tr><td>11. The Charging Station responds with GetVariablesResponse</td><td>10. OCTT sends GetVariablesRequest with: - variable.name = "SecurityProfile" - component.name = "SecurityCtrl"</td></tr><tr><td>13. The Charging Station responds with GetVariablesResponse</td><td>12. OCTT sends GetVariablesRequest with: - variable.name = "NetworkConfigurationPriority" - component.name = "OCPPCommCtrl"</td></tr><tr><td>Test case name</td><td>Upgrade Charging Station Security Profile - Accepted</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message SetNetworkProfileResponse
+- status Accepted
+* Step 4:
+Message SetVariablesResponse
+- setVariableResult[0].attributeStatus Accepted OR RebootRequired
+* Step 6:
+Message ResetResponse
+- status Accepted
+* Step 11:
+Message GetVariablesResponse
+- getVariableResult[0].attributeValue <Configured securityProfile + 1>
+* Step 13:
+Message GetVariablesResponse
+- getVariableResult[0].attributeValue Does not contain <Configured configurationSlot></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 15. Test Case Id: TC_A_20_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Upgrade Charging Station Security Profile - No valid CSMSRootCertificate installed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_20_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A05</td></tr><tr><td>Requirement(s)</td><td colspan="2">A05.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to change the connectionData at the Charging Station. By doing this it is able to upgrade the connection to a higher security profile.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reject upgrading to a higher security profile when it does not have a valid CSMSRootCertificate installed.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The OCTT connectionData configuration for SUT Charging Station only allows for ip addresses the OCTT is able to bind.- The Charging Station support at least 2 security profiles, one of which is security profile 1.- The Charging Station does not have a valid CSMSRootCertificate installed.- The first OCTT connectionData configuration slot must be configured for security profile 1.- The second OCTT connectionData configuration slot must be configured for security profile 2 or 3.- When starting this testcase the OCTT will start another webSocket server for the second connectionData slot.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>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.ocpplInterface<Configured ocplInterface2>-connectionData.ocppVersion OCPP20-connectionData.securityProfile<Configured securityProfile2></td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The OCTT sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is <Configured configurationSlot2>,<Configured configurationSlot></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetNetworkProfileResponse-status Accepted* Step 4:Message SetVariablesResponse-setVariableResult[0].attributeStatus Rejected</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 16. Test Case Id: TC_A_21_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Upgrade Charging Station Security Profile - No valid ChargingStationCertificate installed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_21_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A05</td></tr><tr><td>Requirement(s)</td><td colspan="2">A05.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to change the connectionData at the Charging Station. By doing this it is able to upgrade the connection to a higher security profile.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reject upgrading to a higher security profile when it does not have a valid ChargingStationCertificate installed.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The OCTT connectionData configuration for SUT Charging Station only allows for ip addresses the OCTT is able to bind.- The Charging Station support at least 2 security profiles.- The Charging Station does not have a valid ChargingStationCertificate installed.- The Charging Station has a valid CSMSRootCertificate installed.- The second OCTT connectionData configuration slot must be configured for security profile 3.- When starting this testcase the OCTT will start another webSocket server for the second connectionData slot.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>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.ocpptInterface <Configured ocpptInterface2> -connectionData.ocppVersion OCPP20 -connectionData.securityProfile <Configured securityProfile2></td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The OCTT sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is <Configured configurationSlot2>,<Configured configurationSlot></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetNetworkProfileResponse-status Accepted* Step 4:Message SetVariablesResponse-setVariableResult[0].attributeStatus Rejected</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 17. Test Case Id: TC_A_22_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Upgrade Charging Station Security Profile - Downgrade security profile - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_22_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A05, B09</td></tr><tr><td>Requirement(s)</td><td colspan="2">B09.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to change the connectionData at the Charging Station. It tries to downgrade the connection to a lower security profile.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reject downgrading to a lower security profile than the currently active security profile.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The OCTT connectionData configuration for SUT Charging Station only allows for ip addresses the OCTT is able to bind.
+- The Charging Station supports security profile 2 and/or 3.
+- The second OCTT connectionData configuration slot must be configured for a security profile lower than the first OCTT connectionData configuration slot.
+- When starting this testcase the OCTT will start another webSocket server for the second connectionData slot.</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>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.ocpplInterface <Configured ocplInterface2>
+-connectionData.ocppVersion OCPP20
+-connectionData.securityProfile <Configured securityProfile2></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message SetNetworkProfileResponse
+- status Rejected</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+# 2.3. B Provisioning
+
+Table 18. Test Case Id: TC_B_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Cold Boot Charging Station - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B01</td></tr><tr><td>Requirement(s)</td><td colspan="2">B01.FR.01, B01.FR.05, B01.FR.09</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The booting mechanism allows a Charging Station to provide some general information about the Charging Station to the CSMS on startup AND it allows the Charging Station to request whether it is allowed to start sending other OCPP messages.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to perform the booting mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Booted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 19. Test Case Id: TC_B_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Cold Boot Charging Station - Pending</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B02, F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">B02.FR.01, B02.FR.02, B02.FR.04, B02.FR.05, B02.FR.06, B02.FR.08, F06.FR.17</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The booting mechanism allows a Charging Station to provide some general information about the Charging Station to the CSMS on startup AND it allows the Charging Station to request whether it is allowed to start sending other OCPP messages. A CSMS can temporarily halt the Charging Stations operations by returning the Pending status at the BootNotificationResponse. During this time the CSMS is able to retrieve and set configurations from the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to correctly handle the pending state of the boot mechanism.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The testcases; TC_B_06_CS, TC_B_09_CS, TC_B_13_CS are executed with test result PASS.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action:Reboot the Charging Station.</td></tr><tr><td>1. The Charging Station sends aBootNotificationRequest</td><td>2. The OCTT responds with aBootNotificationResponse with status Pendinginterval<Configured heartbeatInterval></td></tr><tr><td>4. The Charging Station responds withSetVariablesResponse</td><td>3. OCTT sends SetVariablesRequest with:- variable.name = "OfflineThreshold"- component.name = "OCPPCommCtrl"- attributeValue = "300"- attributeType is omitted</td></tr><tr><td>6. The Charging Station responds withGetVariablesResponse</td><td>5. OCTT sends GetVariablesRequest with:- variable.name = "OfflineThreshold"- component.name = "OCPPCommCtrl"- attributeType is omitted</td></tr><tr><td>8. Charging Station responds withGetBaseReportResponse</td><td>7. OCTT sends GetBaseReportRequest with:- requestId = <Generated requestId>- reportBase = FullInventory</td></tr><tr><td rowspan="6"></td><td>Charging Station</td><td>CSMS</td></tr><tr><td>9. Charging Station responds with: NotifyReportRequest Note(s): - This step is repeated as often as needed to report all configuration variables.</td><td>10. OCTT sends NotifyResponse</td></tr><tr><td>12. The Charging Station responds with a RequestStartTransactionResponse</td><td>11. The OCTT sends a RequestStartTransactionRequest Note(s): - This step is executed after the OCTT received all NotifyReport messages. This is indicated by the tbc and seqNo fields.</td></tr><tr><td>14. The Charging Station responds with a TriggerMessageResponse</td><td>13. The OCTT sends a TriggerMessageRequest with requestedMessage BootNotification</td></tr><tr><td>15. The Charging Station sends a BootNotificationRequest Note(s): - The Charging Station resends the BootNotificationRequest after having responded to the TriggerMessageRequest, so before the interval from the BootNotificationResponse has been passed.</td><td>16. The OCTT responds with a BootNotificationResponse with status Accepted interval <Configured heartbeatInterval></td></tr><tr><td>17. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>18. The OCTT responds accordingly.</td></tr><tr><td>Test case name</td><td>Cold Boot Charging Station - Pending</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 4:Message: SetVariablesResponse- setVariableResult[0].attributeStatus Accepted* Step 6:Message: GetVariablesResponse-getVariableResult[0].attributeStatus Accepted* Step 8:Message: GetBaseReportResponse-status Accepted* Step 12:Message: RequestStartTransactionResponse-status Rejected* Step 14:Message: TriggerMessageResponse-status Accepted or NotImplemented* Step 15:Message: BootNotificationRequest-reason Triggered (If the status from the response from step 14 contained Accepted)* Step 17:Message: StatusNotificationRequest- connectorStatus AvailableMessage: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Available"- eventData[0].component.name "Connector"- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td>Post scenario validations:- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 20. Test Case Id: TC_B_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Cold Boot Charging Station - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B03</td></tr><tr><td>Requirement(s)</td><td colspan="2">B03.FR.02, B03.FR.04, B03.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The booting mechanism allows a Charging Station to provide some general information about the Charging Station to the CSMS on startup AND it allows the Charging Station to request whether it is allowed to start sending other OCPP messages.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to correctly handle a rejected BootNotification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action:Reboot the Charging Station.</td></tr><tr><td>1. The Charging Station sends aBootNotificationRequest</td><td>2. The OCTT responds with aBootNotificationResponse with status Rejectedinterval<Configured heartbeatInterval></td></tr><tr><td>3. The Charging Station sends aBootNotificationRequestNote(s):- The Charging Station resends theBootNotificationRequest after x seconds, whereby x is equal to or greater than the interval from theBootNotificationResponse.- The Charging Station is not allowed to send anyOCPP message in the meantime.- The Charging Station is allowed to close the connection until it needs to resend theBootNotificationRequest.</td><td>4. The OCTT responds with aBootNotificationResponse with status Acceptedinterval<Configured heartbeatInterval></td></tr><tr><td>5. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>6. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 5:Message: StatusNotificationRequest- connectorStatus AvailableMessage: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Available"- eventData[0].component.name "Connector"- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 21. Test Case Id: TC_B_30_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Cold Boot Charging Station - Pending/Rejected - SecurityError</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_30_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B03</td></tr><tr><td>Requirement(s)</td><td colspan="2">B03.FR.08</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The booting mechanism allows a Charging Station to provide some general information about the Charging Station to the CSMS on startup AND it allows the Charging Station to request whether it is allowed to start sending other OCPP messages. The CSMS may respond to the BootNotificationRequest with status Rejected. During this state, the Charging Station is not allowed to send RPC Framework: CALL message that is NOT a BootNotificationRequest.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to handle unauthorized messages from the CSMS by responding with a SecurityError.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2"></td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends a BootNotificationRequest</td><td>2. The OCTT responds with a BootNotificationResponse with status Rejected</td></tr><tr><td>4. The Charging Station responds with RPC Framework: CALLERROR: SecurityError.</td><td>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</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">N/a</td></tr></table>
+
+Table 22. Test Case Id: TC_B_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Variables - single value</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_06_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B06</td></tr><tr><td>Requirement(s)</td><td colspan="2">B06.FR.01, B06.FR.02, B06.FR.03, B06.FR.04, B06.FR.10, B06.FR.11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">Get the value of one of the required variables of OCPPCommCtrlr</td></tr><tr><td>Purpose</td><td colspan="2">To test getting a single value using GetVariablesRequest for one of the mandatory component/variable combinations that must exist in the DM implementation.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+OCPPCommCtrlrOfflineThreshold is 300</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with
+GetVariablesResponse</td><td>1. OCTT sends GetVariablesRequest with:
+-
+variable.name = "OfflineThreshold"
+-
+component.name = "OCPPCommCtrlr"
+-
+attributeType = Actual</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: GetVariablesResponse
+- attributeStatus = Accepted
+- attributeType = Actual
+- attributeValue = "300"
+- component.name = "OCPPCommCtrlr"
+- variable.name = "OfflineThreshold"
+- attributeStatusInfo is absent or attributeStatusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">Post scenario validations:
+N/A</td></tr></table>
+
+Table 23. Test Case Id: TC_B_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Variables - multiple values</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B06</td></tr><tr><td>Requirement(s)</td><td colspan="2">B06.FR.01, B06.FR.02, B06.FR.03, B06.FR.04, B06.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">Get the value of two required variables</td></tr><tr><td>Purpose</td><td colspan="2">To test getting multiple values using GetVariablesRequest for one of the mandatory component/variable combinations that must exist in the DM implementation.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:OCPPCommCtrlOfflineThreshold is 300AuthCtrl.LocalAuthorizationOffline is true</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds withGetVariablesResponse with attributeStatus = Accepted.</td><td>1. OCTT sends GetVariablesRequest with:- getVariableData[0].variable.name = "OfflineThreshold"- getVariableData[0].component.name = "OCPPCommCtrl"- getVariableData[0].attributeType = Actual- getVariableData[1].variable.name = "LocalAuthorizationOffline"- getVariableData[1].component.name = "AuthCtrl"- getVariableData[1].attributeType = Actual</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: GetVariablesResponse has (in arbitrary order)GetVariableResultType[0]:- attributeStatus = Accepted- attributeType = Actual- attributeValue = 300-component.name = "OCPPCommCtrl"- variable.name = "OfflineThreshold"- attributeStatusInfo is absent or attributeStatusInforeasonCode = "NoError"GetVariableResultType[1]:- attributeStatus = Accepted- attributeType = Actual- attributeValue = "true"- component.name = "AuthCtrl"- variable.name = "LocalAuthorizationOffline"- attributeStatusInfo is absent or attributeStatusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 24. Test Case Id: TC_B_32_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Variables - Unknown component</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_32_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B06</td></tr><tr><td>Requirement(s)</td><td colspan="2">B06.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can use a GetVariablesRequest to retrieve values from device model variables at the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station can handle receiving a GetVariablesRequest for an unknown component.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with GetVariablesResponse</td><td>1. OCTT sends GetVariablesRequest with:
+- variable.name = "OfflineThreshold"
+- component.name = "UnknownComponent"
+- attributeType is omitted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: GetVariablesResponse
+- getVariableResult[0].attributeStatus = UnknownComponent
+- getVariableResult[0].component.name = "UnknownComponent"
+- getVariableResult[0].variable.name = "OfflineThreshold"</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 25. Test Case Id: TC_B_33_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Variables - Unknown variable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_33_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B06</td></tr><tr><td>Requirement(s)</td><td colspan="2">B06.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can use a GetVariablesRequest to retrieve values from device model variables at the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station can handle receiving a GetVariablesRequest for an unknown variable.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with GetVariablesResponse</td><td>1. OCTT sends GetVariablesRequest with:
+- variable.name = "UnknownVariable"
+- component.name = "OCPPCommCtrlr"
+- attributeType is omitted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: GetVariablesResponse
+- getVariableResult[0].attributeStatus = UnknownVariable
+- getVariableResult[0].component.name = "OCPPCommCtrlr"
+- getVariableResult[0].variable.name = "UnknownVariable"</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 26. Test Case Id: TC_B_34_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Variables - Not supported attribute type</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_34_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B06</td></tr><tr><td>Requirement(s)</td><td colspan="2">B06.FR.08</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can use a GetVariablesRequest to retrieve values from device model variables at the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station can handle receiving a GetVariablesRequest for a not supported attribute type.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with GetVariablesResponse</td><td>1. OCTT sends GetVariablesRequest with:
+- variable.name = "OfflineThreshold"
+- component.name = "OCPPCommCtrl"
+- attributeType = Target</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: GetVariablesResponse
+-getVariableResult[0].attributeStatus = NotSupportedcliffeType
+-getVariableResult[0].component.name = "OCPPCommCtrl"
+-getVariableResult[0].variable.name = "OfflineThreshold"
+-getVariableResult[0].attributeType = Target</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 27. Test Case Id: TC_B_09_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variables - single value</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_09_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B05</td></tr><tr><td>Requirement(s)</td><td colspan="2">B05.FR.01, B05.FR.02, B05.FR.03, B05.FR.10, B05.FR.12</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">Set the value of one of the required variables of OCPPCommCtrlr</td></tr><tr><td>Purpose</td><td colspan="2">To test setting a single value using SetVariablesRequest for one of the mandatory component/variable combinations that must exist in the DM implementation.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with SetVariablesResponse with attributeStatus = Accepted.</td><td>1. OCTT sends SetVariablesRequest with:
+- variable.name = "OfflineThreshold"
+- component.name = "OCPPCommCtrlr"
+- attributeValue = "300"
+- attributeType Actual</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: SetVariablesResponse
+- setVariableResult[0].attributeStatus = Accepted
+- setVariableResult[0].attributeType = Actual
+- setVariableResult[0].component.name = "OCPPCommCtrlr"
+- setVariableResult[0].attributename = "OfflineThreshold"
+- setVariableResult[0].attributeStatusInfo is absent or setVariableResult[0].attributeStatusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 28. Test Case Id: TC_B_10_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variables - multiple values</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_10_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B05</td></tr><tr><td>Requirement(s)</td><td colspan="2">B05.FR.01, B05.FR.02, B05.FR.03, B05.FR.10, B05.FR.12</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">Set the value of two required variables</td></tr><tr><td>Purpose</td><td colspan="2">To test setting multiple values using GetVariablesRequest for one of the mandatory component/variable combinations that must exist in the DM implementation.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with SetVariablesResponse with attributeStatus = Accepted.</td><td>1. OCTT sends SetVariablesRequest with: - setVariableData[0].variable.name = "OfflineThreshold" - setVariableData[0].component.name = "OCPPCommCtrl" - setVariableData[0].attributeValue = "300" - setVariableData[0].attributeType = Actual - setVariableData[1].variable.name = "LocalAuthorizationOffline" - setVariableData[1].component.name = "AuthCtrl" - setVariableData[1].attributeValue = "true" - setVariableData[0].attributeType = Actual</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: SetVariablesResponse has (in arbitrary order) SetVariableResultType[1]: - attributeStatus = Accepted - attributeType = Actual - component.name = "OCPPCommCtrl" - variable.name = "OfflineThreshold" - attributeStatusInfo is absent or attributeStatusInforeasonCode = "NoError" SetVariableResultType[2]: - attributeStatus = Accepted - attributeType = Actual - component.name = "AuthCtrl" - variable.name = "LocalAuthorizationOffline" - attributeStatusInfo is absent or attributeStatusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 29. Test Case Id: TC_B_35_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variables - Unknown component</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_35_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B05</td></tr><tr><td>Requirement(s)</td><td colspan="2">B05.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can use a SetVariablesRequest to set values from device model variables at the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station can handle receiving a SetVariablesRequest for an unknown component.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with SetVariablesResponse</td><td>1. OCTT sends SetVariablesRequest with: - variable.name = "OfflineThreshold" - component.name = "UnknownComponent" - attributeType is omitted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: SetVariablesResponse - setVariableResult[0].attributeStatus = UnknownComponent - setVariableResult[0].component.name = "UnknownComponent" - setVariableResult[0].variable.name = "OfflineThreshold"</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 30. Test Case Id: TC_B_36_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variables - Unknown variable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_36_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B05</td></tr><tr><td>Requirement(s)</td><td colspan="2">B05.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can use a SetVariablesRequest to set values from device model variables at the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station can handle receiving a SetVariablesRequest for an unknown variable.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with SetVariablesResponse</td><td>1. OCTT sends SetVariablesRequest with:
+- variable.name = "UnknownVariable"
+- component.name = "OCPPCommCtrl"
+- attributeType is omitted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: SetVariablesResponse
+- setVariableResult[0].attributeStatus = UnknownVariable
+- setVariableResult[0].component.name = "OCPPCommCtrl"
+- setVariableResult[0].variable.name = "UnknownVariable"</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 31. Test Case Id: TC_B_37_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variables - Not supported attribute type</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_37_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B05</td></tr><tr><td>Requirement(s)</td><td colspan="2">B05.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can use a SetVariablesRequest to set values from device model variables at the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station can handle receiving a SetVariablesRequest for a not supported attribute type.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with SetVariablesResponse</td><td>1. OCTT sends SetVariablesRequest with:
+- variable.name = "OfflineThreshold"
+- component.name = "OCPPCommCtrl"
+- attributeType = Target</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: SetVariablesResponse
+- setVariableResult[0].attributeStatus = NotSupportedcliffeType
+- setVariableResult[0].component.name = "OCPPCommCtrl"
+- setVariableResult[0].variable.name = "OfflineThreshold"
+- setVariableResult[0].attributeType = Target</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 32. Test Case Id: TC_B_11_CS
+
+<table><tr><td>Test case name</td><td>Set Variables - invalidly formatted values</td></tr><tr><td>Test case Id</td><td>TC_B_11_CS</td></tr><tr><td>Use case Id(s)</td><td>B05</td></tr><tr><td>Requirement(s)</td><td>B05.FR.07</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>Set the value of two of the required variables of OCPPCommCtrlr</td></tr><tr><td>Purpose</td><td>To test setting of variables of different type with invalidly formatted values using GetVariablesRequest for one of the mandatory component/variable combinations that must exist in the DM implementation.</td></tr><tr><td>Prerequisite(s)</td><td>Charging Station DM has the variable "NextTimeOffsetTransitionDateTime" of component "ClockCtrlr" to test setting of a date.</td></tr><tr><td colspan="2"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td>Configuration State: N/a</td></tr><tr><td>Memory State: N/a</td></tr><tr><td>Reusable State(s): N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variables - invalidly formatted values</td></tr><tr><td rowspan="9">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Notes: Steps 1 to 8 are repeated 5 times for value = <configured offlineThreshold>, <configured offlineThreshold + 0.1>, true, currentTime, "abc"</td></tr><tr><td>2. Charging Station responds with SetVariablesResponse with If value not supported: attributeStatus = Rejected attributeStatusInfo = InvalidValue If component/variable/value supported: attributeStatus = Accepted</td><td>1. OCTT sends SetVariablesRequest with - variable.name = "OfflineThreshold" - component.name = "OCPPCommCtrl" - attributeValue = value</td></tr><tr><td colspan="2">Notes: Steps 3 and 4 will only be tested if this component/variable combination is supported</td></tr><tr><td>4. Charging Station responds with SetVariablesResponse with If value not supported: attributeStatus = Rejected attributeStatusInfo = InvalidValue If component/variable/value supported: attributeStatus = Accepted</td><td>3. OCTT sends SetVariablesRequest with - variable.name = "LimitChangeSignificance" - component.name = "SmartChargingCtrl" - attributeValue = value</td></tr><tr><td colspan="2">Notes: Steps 5 and 6 will only be executed if this component/variable combination is readwrite</td></tr><tr><td>6. Charging Station responds with SetVariablesResponse with If value not supported: attributeStatus = Rejected attributeStatusInfo = InvalidValue If component/variable/value supported: attributeStatus = Accepted</td><td>5. OCTT sends SetVariablesRequest with: - variable.name = "AuthorizeRemoteStart" - component.name = "AuthCtrl" - attributeValue = value</td></tr><tr><td colspan="2">Notes: Steps 7 and 8 will only be executed if the CS supports this component/variable combination</td></tr><tr><td>8. Charging Station responds with SetVariablesResponse with If value not supported: attributeStatus = Rejected attributeStatusInfo = InvalidValue If component/variable/value supported: attributeStatus = Accepted</td><td>7. OCTT sends SetVariablesRequest with: - variable.name = "NextTimeOffsetTransitionDateTime" - component.name = "ClockCtrl" - attributeValue = value</td></tr><tr><td>Test case name</td><td>Set Variables - invalidly formatted values</td></tr><tr><td rowspan="5">Tool validations</td><td>* Step 2:
+Message: SetVariablesResponse has
+SetVariableResultType
+- attributeStatus = Rejected/Accepted
+- attributeType = Actual
+- component.name = "OCPPCommCtrl"
+- variable.name = "OfflineThreshold"
+- attributeStatusInfo is absent or attributeStatusInforeasonCode = InvalidValue (not required)</td></tr><tr><td>* Step 4:
+Message: SetVariablesResponse has
+SetVariableResultType
+- attributeStatus = Rejected/Accepted
+- attributeType = Actual
+- component.name = "AuthCtrl"
+- variable.name = "AuthorizeRemoteStart"
+- attributeStatusInfo is absent or attributeStatusInforeasonCode = InvalidValue (not required)</td></tr><tr><td>* Step 6:
+Message: SetVariablesResponse has
+SetVariableResultType
+- attributeStatus = Rejected/Accepted
+- attributeType = Actual
+- component.name = "SmartChargingCtrl"
+- variable.name = "LimitChangeSignificance"
+- attributeStatusInfo is absent or attributeStatusInforeasonCode = InvalidValue (not required)</td></tr><tr><td>* Step 8:
+Message: SetVariablesResponse has
+SetVariableResultType
+- attributeStatus = Rejected/Accepted
+- attributeType = Actual
+- component.name = "ClockCtrl"
+- variable.name = "NextTimeOffsetTransitionDateTime"
+- attributeStatusInfo is absent or attributeStatusInforeasonCode = InvalidValue (not required)</td></tr><tr><td>Post scenario validations:
+N/A</td></tr></table>
+
+Table 33. Test Case Id: TC_B_39_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variables - Read-only</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_39_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B05</td></tr><tr><td>Requirement(s)</td><td colspan="2">B05.FR.09</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can use a SetVariablesRequest to set values from device model variables at the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station can handle receiving a SetVariablesRequest for a Read-only variable.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with SetVariablesResponse</td><td>1. OCTT sends SetVariablesRequest with:
+- variable.name = "MessageTimeout"
+- variable.instance = "Default"
+- component.name = "OCPPCommCtrl"
+- attributeType is omitted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: SetVariablesResponse
+- setVariableResult[0].attributeStatus = Rejected
+- setVariableResult[0].component.name = "OCPPCommCtrl"
+- setVariableResult[0].variable.name = "MessageTimeout"
+- setVariableResult[0].variable.instance = "Default"</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 34. Test Case Id: TC_B_12_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Base Report - ConfigurationInventory</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_12_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B07</td></tr><tr><td>Requirement(s)</td><td colspan="2">B07.FR.01, B07.FR.03, B07.FR.04, B07.FR.07, B07.FR.10, B07.FR.12</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a ConfigurationInventory base report.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports the ConfigurationInventory base report.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:GetBaseReportResponse</td><td>1. OCTT sends GetBaseReportRequest with:- requestId = <Generated requestId>reportBase = ConfigurationInventory</td></tr><tr><td>3. Charging Station responds with:NotifyReportRequest</td><td>4. OCTT sends NotifyReportResponse</td></tr><tr><td colspan="2">Step 3 and 4 are repeated as often as needed to report all configuration variables.</td></tr><tr><td rowspan="4">Tool validations</td><td colspan="2">* Step 2:Message: GetBaseReportResponse-status = Accepted-statusInfo is absent or statusInfoReasonCode = "NoError"</td></tr><tr><td colspan="2">* Step 3:Message: NotifyReportRequest-requestId = <Generated requestId>- generatedAt = <timestamp at charging station>- seqNo = 0 - if variableCharacteristics.dataType = OptionList, SequenceList or MemberList then valuesListmust be provided.</td></tr><tr><td>while tbc = true</td><td>Expect NotifyReportRequest- seqNo is incremented by 1</td></tr><tr><td colspan="2">Post scenario validations:Check for all received variables:- variableCharacteristics are present-mutability = ReadWrite or WriteOnlyValidate that as a minimum the required writeable variables in section "Referenced Components andVariables" are reported, that are relevant to each functional block that has been implemented.</td></tr></table>
+
+Table 35. Test Case Id: TC_B_13_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Base Report - FullInventory</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_13_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B07</td></tr><tr><td>Requirement(s)</td><td colspan="2">B07.FR.01, B07.FR.03, B07.FR.04, B07.FR.08, B07.FR.10, B07.FR.12</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a FullInventory base report.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports the FullInventory base report.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/A</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:GetBaseReportResponse</td><td>1. OCTT sends GetBaseReportRequest with:- requestId = <Generated requestId>reportBase = FullInventory</td></tr><tr><td>3. Charging Station responds with:NotifyReportRequest</td><td>4. OCTT sends NotifyReportResponse</td></tr><tr><td colspan="2">Step 3 and 4 are repeated as often as needed to report all configuration variables.</td></tr><tr><td rowspan="4">Tool validations</td><td colspan="2">* Step 2:Message: GetBaseReportResponse-status = Accepted-statusInfo is absent or statusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">* Step 3:Message: NotifyReportRequest-requestId = <Generated requestId>- generatedAt = <timestamp at charging station>- seqNo = 0 - if variableCharacteristics.dataType = OptionList, SequenceList or MemberList then valuesListmust be provided.</td></tr><tr><td>while tbc = true</td><td>Expect NotifyReportRequest- seqNo is incremented by 1</td></tr><tr><td colspan="2">Post scenario validations:Check for all received variables:- variableCharacteristics are presentValidate that as a minimum the required variables mentioned in section "Charging Infrastructure Related"are reported as well as the required variables in section "Referenced Components and Variables", that arerelevant to each functional block that has been implemented.</td></tr></table>
+
+Table 36. Test Case Id: TC_B_14_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Base Report - SummaryInventory</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_14_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B07</td></tr><tr><td>Requirement(s)</td><td colspan="2">B07.FR.01, B07.FR.03, B07.FR.04, B07.FR.09, B07.FR.10, B07.FR.12</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a SummaryInventory base report.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports the SummaryInventory base report.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station implementation supports the optional SummaryInventory report</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:GetBaseReportResponse</td><td>1. OCTT sends GetBaseReportRequest with:- requestId = <Generated requestId>reportBase = SummaryInventory</td></tr><tr><td>3. Charging Station responds with:NotifyReportRequest</td><td>4. OCTT sends NotifyReportResponse</td></tr><tr><td colspan="2">Step 3 and 4 are repeated as often as needed to report all configuration variables.</td></tr><tr><td rowspan="4">Tool validations</td><td colspan="2">* Step 2:Message: GetBaseReportResponse- status = Accepted-statusInfo is absent or statusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">* Step 3:Message: NotifyReportRequest- requestId = <Generated requestId>- generatedAt = <timestamp at charging station>- seqNo = 0</td></tr><tr><td>while tbc = true</td><td>Expect NotifyReportRequest- seqNo is incremented by 1</td></tr><tr><td colspan="2">Post scenario validations:Check for all received variables:- variableCharacteristics are present-if variableCharacteristics.dataType = OptionList, SequenceList or MemberList then valuesList must be provided.Result must be a report that lists Components/Variables relating to the Charging Station's current charging availability, and to any existing problem conditions.- For the Charging Station Component: AvailabilityState- For each EVSE Component: AvailabilityState- For each Connector Component: AvailabilityState (if known and different from EVSE). - For all Components in an abnormal State: - Problem, Tripped, Overload, Failback variables.- Any other diagnostically relevant Variables of the Components.</td></tr></table>
+
+Table 37. Test Case Id: TC_B_15_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Base Report - Not Supported base report</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_15_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B07</td></tr><tr><td>Requirement(s)</td><td colspan="2">B07.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a base report that is not supported.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station returns NotSupported when a SummaryInventory base report is requested, but Charging Station does not support it.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station implementation does not support the optional SummaryInventory report.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:GetBaseReportResponse</td><td>1. OCTT sends GetBaseReportRequest with:- requestId = <Generated requestId>reportBase = SummaryInventory</td></tr><tr><td colspan="2">Note(s):- OCTT waits to make sure CS does not send a NotifyReportRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Charging Station responds with:GetBaseReportResponse with:- status = NotSupported-statusInfo is absent or statusInforeasonCode = "UnsupportedParam"</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 38. Test Case Id: TC_B_16_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Custom Report - with component criteria</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_16_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B08</td></tr><tr><td>Requirement(s)</td><td colspan="2">B08.FR.01, B08.FR.03, B08.FR.04, B08.FR.07, B08.FR.09, B089.FR.10, B08.FR.12, B08.FR.13, B08.FR.14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a custom report based on a set of component criteria.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports a custom report query.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented custom reporting (use case B08).</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds:GetReportResponse</td><td>1. OCTT sends GetReportRequest with:- requestId = <Generated requestId>componentCriteria = {Enabled}</td></tr><tr><td>3. Charging Station sends NotifyReportRequest with:- reportData for all components that have the variable "Enabled" set to "true".</td><td>4. OCTT responds with NotifyReportResponse</td></tr><tr><td colspan="2">Steps 3 and 4 may be repeated multiple times until everything has been reported.</td></tr><tr><td colspan="2">OCTT sends a GetVariables for all variables to match results.</td></tr><tr><td>6. Charging Station responds with:GetVariablesResponse</td><td>5. OCTT sends GetVariablesRequest</td></tr><tr><td rowspan="5">Tool validations</td><td colspan="2">* Step 2: +2. Message: GetReportResponse with:- status = Accepted- statusInfo is absent or statusInfo = "NoError"</td></tr><tr><td colspan="2">* step 3:Message: NotifyReportRequest with:- requestId = <Generated requestId>generatedAt = <time of generation at charging station>- seqNo = 0- reportData variableCharacteristics are present- reportData variable.name is "Enabled"- reportData variableAttribute.value = "true"Note: for Enabled there will only be an Actual value.It does not make any sense to have a MinSet, MaxSet or Target value for them.</td></tr><tr><td>While tbc = true</td><td>Message: NotifyReportRequest- seqNo is incremented by one-reportData variableCharacteristics are present-reportData variable.name is "Enabled"- reportData variableAttribute.value = "true"</td></tr><tr><td colspan="2">* Step 6:Message: GetVariablesResponse with:- attributeStatus = Accepted- attributeValue = true</td></tr><tr><td colspan="2">Post scenario validations:Check that every variable, named "Enabled" that was reported in the FullInventory base report with a value of "true" is also reported by the custom report for componentCriteria = { Enabled}.</td></tr></table>
+
+Table 39. Test Case Id: TC_B_17_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Custom Report - with component/variable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_17_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B08</td></tr><tr><td>Requirement(s)</td><td colspan="2">B08.FR.01, B08.FR.03, B08.FR.04, B08.FR.11, B08.FR.12, B08.FR.14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a custom report for AvailabilityState of EVSE #1.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports a custom report query.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented custom reporting (use case B08).</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds:GetReportResponse</td><td>1. OCTT sends GetReportRequest with:- requestId = <Generated requestId> - componentVariable[0].component.name = "EVSE" - componentVariable[0].component.evse.id = 1 - componentVariable[0].variable.name = "AvailabilityState"</td></tr><tr><td>3. Charging Station sends NotifyReportRequest</td><td>4. OCTT responds with NotifyReportResponse</td></tr><tr><td rowspan="3">Tool validations</td><td colspan="2">* Step 2:Message: GetReportResponse with:- status = Accepted- statusInfo is absent or statusInfo = "NoError"</td></tr><tr><td colspan="2">* step 3:Message: NotifyReportRequest with:- requestId = GetReportRequest requestid- generatedAt = <time of generation at charging station>- seqNo = 0- reportData_component.name = "EVSE"- reportData_component.evse.id = 1- reportData_variable.name = "AvailabilityState"- reportData_variableCharacteristics.dataType = OptionList- reportData_variableCharacteristics.valuesList = "Available, Occupied, Reserved, Unavailable, Faulted"- reportData_variableAttribute.mutability = ReadOnly-reportData_variableAttribute.type = ActualNote: for AvailabilityState there will only be an _Actual value.It does not make any sense to have a MinSet, MaxSet or Target value for it...</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 40. Test Case Id: TC_B_18_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Custom Report - with component criteria and component/variable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_18_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B08</td></tr><tr><td>Requirement(s)</td><td colspan="2">B08.FR.01, B08.FR.03, B08.FR.04, B08.FR.05, B08.FR.11, B08.FR.12, B08.FR.14, B08.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a custom report for AvailabilityState of EVSE #1 as Available and with Problem.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports a custom report query and that it takes the component criteria into account, by first request a selection that should return a value and then requesting a selection that should not return a value.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented custom reporting (use case B08).</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Request EVSE::AvailabilityState from _Available components.Note 1: EVSE #1 must be available, because a Charging Station without EVSE is useless.Note 2: Do not confuse Available with AvailabilityState._</td></tr><tr><td>2. Charging Station responds:GetReportResponse</td><td>1. OCTT sends GetReportRequest with:- requestId = <Generated requestId> - componentCriteria = {Available} - componentVariable[0].component.name = "EVSE" - componentVariable[0].component.evse.id = 1 - componentVariable[0].variable.name = "AvailabilityState"</td></tr><tr><td>3. Charging Station sends NotifyReportRequest</td><td>4. OCTT responds with NotifyReportResponse</td></tr><tr><td colspan="2">Request EVSE::AvailabilityState from _Problem components.Note 1: Assuming EVSE #1 does not have Problem variable set._</td></tr><tr><td>6. Charging Station responds:GetReportResponse</td><td>5. OCTT sends GetReportRequest with:- requestId = <Generated requestId> - componentCriteria[0] = Problem - componentVariable[0].component.name = "EVSE" - componentVariable[0].component.evse.id = 1 - componentVariable[0].variable.name = "AvailabilityState"</td></tr><tr><td>Test case name</td><td>Get Custom Report - with component criteria and component/variable</td></tr><tr><td rowspan="4">Tool validations</td><td>* Step 2:
+Message: GetReportResponse with:
+- status = Accepted
+- statusInfo is absent or statusInfo = "NoError"</td></tr><tr><td>* step 3:
+Message: NotifyReportRequest with:
+- requestId = GetReportRequest requestid
+-generatedAt = <time of generation at charging station>
+- seqNo = 0
+-reportData:EVSE
+-reportData:Evse.id = 1
+-reportData:Evse.name = "AvailabilityState"
+-reportData:Evse.dataType = OptionList
+-reportData:Evse(valuesList = "Available, Occupied, Reserved, Unavailable, Faulted"
+-reportData:Evse.type = ReadOnly
+-reportData:Evse attribute.mutability = Actual
+Note: for AvailabilityState there will only be an Actual value.
+It does not make any sense to have a MinSet, MaxSet or Target value for it._</td></tr><tr><td>* Step 6:
+Message: GetReportResponse with:
+- status = EmptyResultSet
+-statusInfo is absent or statusInforeasonCode = "NotFound"</td></tr><tr><td>Post scenario validations:
+N/A</td></tr></table>
+
+NOTE
+
+Test Case Id: TC_B_19_CS
+
+Since ComponentCriterionEnum is defined as enumeration, this will most likely already be caught by the JSON parser.
+
+<table><tr><td>Test case name</td><td colspan="2">Get Custom Report - for unknown component criteria</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_19_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B08</td></tr><tr><td>Requirement(s)</td><td colspan="2">B08.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS sends a GetReport with an invalid value in componentCriteria.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station returns a NotSupported return code in response to an invalid value for componentCriteria.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has one or more not supported componentCriteria.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with: GetReportResponse</td><td>1. OCTT sends GetReportRequest with: - requestId = <Generated requestId - componentCriteria = { Available, <Configured Unsupported componentCriteria>} - *componentVariable is absent</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2
+Message: GetReportResponse
+- status = NotSupported
+- statusInfo is absent or statusInforeasonCode = "UnsupportedParam" or statusInforeasonCode = "InvalidValue"</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 41. Test Case Id: TC_B_20_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Charging Station - Without ongoing transaction - OnIdle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_20_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B11</td></tr><tr><td>Requirement(s)</td><td colspan="2">B11.FR.01, B11.FR.03, B11.FR.04, B01.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can request the Charging Station to reset itself by sending a ResetRequest without any ongoing transaction. This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type OnIdle</td></tr><tr><td>Note(s): - Charging Station rebootss</td><td></td></tr><tr><td>3. The Charging Station sends a BootNotificationRequest</td><td>4. The OCTT responds with a BootNotificationResponse with status Accepted</td></tr><tr><td>5. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>6. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message ResetResponse - status Accepted * Step 5: Message: StatusNotificationRequest - connectorStatus Available Message: NotifyEventRequest - eventData[0].trigger Delta - eventData[0].actualValue "Available" - eventData[0].component.name "Connector" - eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations: - A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 42. Test Case Id: TC_B_21_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Charging Station - With Ongoing Transaction - OnIdle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_21_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B12</td></tr><tr><td>Requirement(s)</td><td colspan="2">B12.FR.01, B12.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can remotely request the Charging Station to reset itself by sending a ResetRequest during a transaction. When ResetRequest "OnIdle" is send the charging stations schedules a reboot after all transactions are stopped.
+This could be example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the reset mechanism while there is an ongoing transaction as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="11">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type OnIdle</td></tr><tr><td colspan="2">3. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">4. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">5. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">Notes(s): Steps 4 and 5 will only be executed if TxStartPoint does not contain: EnergyTransferStarted, DataSigned, PowerPathClosed, or Authorized</td></tr><tr><td colspan="2">6. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">Notes(s): Step 6 will only be executed if TxStartPoint does not contain: EnergyTransferStarted, DataSigned, PowerPathClosed, Authorized, or EVConnected</td></tr><tr><td>7. The Charging Station sends a BootNotificationRequest</td><td>8. The OCTT responds with a BootNotificationResponse</td></tr><tr><td>9. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>10. The OCTT responds accordingly.</td></tr><tr><td>11. The Charging Station sends a SecurityEventNotificationRequest</td><td>12. The OCTT responds with a SecurityEventNotificationResponse</td></tr><tr><td>Test case name</td><td>Reset Charging Station - With Ongoing Transaction - OnIdle</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message ResetResponse
+- status Scheduled
+* Step 7:
+Message BootNotificationRequest
+- reason ScheduledReset
+* Step 9:
+Message: StatusNotificationRequest
+- If the transaction was stopped at step 3, then connectorStatus Occupied
+Else connectorStatus Available
+Message: NotifyEventRequest
+- If the transaction was stopped at step 3, then eventData[0].actualValue "Occupied"
+Else eventData[0].actualValue "Available"
+- eventData[0].trigger Delta
+- eventData[0].component.name "Connector"
+- eventData[0].variable.name "AvailabilityState"
+* Step 11:
+Message: SecurityEventNotificationRequest
+- type StartupOfTheDevice or ResetOrReboot</td></tr><tr><td>Post scenario validations:
+- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 43. Test Case Id: TC_B_22_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Charging Station - With Ongoing Transaction - Immediate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_22_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B12</td></tr><tr><td>Requirement(s)</td><td colspan="2">B12.FR.02, B12.FR.04, E07.FR.03, B01.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can remotely request the Charging Station to reset itself by sending a ResetRequest during a transaction. When ResetRequest "Immediate" is send the charging stations will try to stop all transactions before rebooting.This could be example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type Immediate</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>Note(s):- Charging Station reboots</td><td></td></tr><tr><td>5. The Charging Station sends a BootNotificationRequest</td><td>6. The OCTT responds with a BootNotificationResponse with status Accepted</td></tr><tr><td>7. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>8. The OCTT responds accordingly.</td></tr><tr><td>Test case name</td><td>Reset Charging Station - With Ongoing Transaction - Immediate</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:Message ResetResponse- status Accepted* Step 3:Message TransactionRequesteventType Ended-triggerReason ResetCommand- transactionInfo.chargingState EVConnected- transactionInfo.stoppedReason ImmediateReset-idToken must be omitted* Step 5:Message BootNotificationRequest- reason RemoteReset* Step 7:For <Configured connectorId>:Message: StatusNotificationRequest- connectorStatus OccupiedMessage: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Occupied"- eventData[0].component.name "Connector"- eventData[0].variable.name "AvailabilityState"For <Other connector(s)>:Message: StatusNotificationRequest- connectorStatus AvailableMessage: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Available"- eventData[0].component.name "Connector"- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td>Post scenario validations:- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 44. Test Case Id: TC_B_23_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Charging Station - Unavailable persists reset</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_23_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B11</td></tr><tr><td>Requirement(s)</td><td colspan="2">B11.FR.01, B11.FR.02, B11.FR.03, B11.FR.04, B01.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can request the Charging Station to reset itself by sending a ResetRequest without any ongoing transaction and with the status of Inoperative. This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: Unavailable for <Configured connectorId></td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type OnIdle</td></tr><tr><td>Note(s): - The Charging Station reboot</td><td></td></tr><tr><td>3. The Charging Station sends a BootNotificationRequest</td><td>4. The OCTT responds with a BootNotificationResponse with status Accepted</td></tr><tr><td>5. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>6. The OCTT responds accordingly.</td></tr><tr><td>Test case name</td><td>Reset Charging Station - Unavailable persists reset</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:Message ResetResponse- status Accepted* Step 3:Message BootNotificationRequestreason RemoteReset* Step 5:For <Configured connectorId>:Message: StatusNotificationRequest- connectorStatus UnavailableMessage: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Unavailable"- eventData[0].component.name "Connector"- eventData[0].variable.name "AvailabilityState"For <Other connector(s)>:Message: StatusNotificationRequest- connectorStatus AvailableMessage: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Available"- eventData[0].component.name "Connector"- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td>Post scenario validations:- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 45. Test Case Id: TC_B_24_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Charging Station - Reserved persists reset</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_24_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B11</td></tr><tr><td>Requirement(s)</td><td colspan="2">B11.FR.01, B11.FR.03, B11.FR.04, B11.FR.05, B01.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can request the Charging Station to reset itself by sending a ResetRequest without any ongoing transaction and with the status of Reserved. This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: Reserved for <Configured connectorId></td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type OnIdle</td></tr><tr><td>Note(s): - The Charging Station reboots</td><td></td></tr><tr><td>3. The Charging Station sends a BootNotificationRequest</td><td>4. The OCTT responds with a BootNotificationResponse with status Accepted</td></tr><tr><td>5. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>6. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message ResetResponse - status Accepted * Step 3: Message BootNotificationRequest reason RemoteReset * Step 5: For <Configured connectorId>: Message: StatusNotificationRequest - connectorStatus Reserved Message: NotifyEventRequest - eventData[0].trigger Delta - eventData[0].actualValue "Reserved" - eventData[0].component.name "Connector" - eventData[0].variable.name "AvailabilityState" For <Other connector(s)>: Message: StatusNotificationRequest - connectorStatus Available Message: NotifyEventRequest - eventData[0].trigger Delta - eventData[0].actualValue "Available" - eventData[0].component.name "Connector" - eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations: - A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 46. Test Case Id: TC_B_41_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Charging Station - With multiple ongoing transactions - OnIdle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_41_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B12</td></tr><tr><td>Requirement(s)</td><td colspan="2">B12.FR.01, B12.FR.03, E07.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can remotely request the Charging Station to reset itself by sending a ResetRequest during a transaction. When ResetRequest "OnIdle" is send the charging stations schedules a reboot after all transactions are stopped.
+This could be example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the reset mechanism while there are multiple ongoing transactions as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has more than one EVSE.</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted for EVSE.id = 1
+State is EnergyTransferStarted for EVSE.id = 2</td></tr><tr><td rowspan="15">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type OnIdle</td></tr><tr><td colspan="2">3. Execute Reusable State StopAuthorized for EVSE.id = 1</td></tr><tr><td colspan="2">4. Execute Reusable State EVConnectedPostSession for EVSE.id = 1</td></tr><tr><td colspan="2">5. Execute Reusable State EVDisconnected for EVSE.id = 1</td></tr><tr><td colspan="2">6. Execute Reusable State ParkingBayUnoccupied for EVSE.id = 1</td></tr><tr><td colspan="2">7. Execute Reusable State StopAuthorized for EVSE.id = 2</td></tr><tr><td colspan="2">8. Execute Reusable State EVConnectedPostSession for EVSE.id = 2</td></tr><tr><td colspan="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.</td></tr><tr><td colspan="2">9. Execute Reusable State EVDisconnected for EVSE.id = 2</td></tr><tr><td colspan="2">Note(s):
+If TxStopPoint contains the value EVConnected.
+Then the transaction will have ended at the EVDisconnected state AND the Charging Station will proceed with resetting itself. Proceed to step 11
+Else proceed with step 10</td></tr><tr><td colspan="2">10. Execute Reusable State ParkingBayUnoccupied for EVSE.id = 2</td></tr><tr><td colspan="2">Note(s):
+The transaction will end at this state, if it was not ended at an earlier state. Proceed to step 11.</td></tr><tr><td>11. The Charging Station sends a BootNotificationRequest</td><td>12. The OCTT responds with a BootNotificationResponse</td></tr><tr><td>13. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>14. The OCTT responds accordingly.</td></tr><tr><td>Test case name</td><td>Reset Charging Station - With multiple ongoing transactions - OnIdle</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message ResetResponse
+- status Scheduled
+* Step 11:
+Message BootNotificationRequest
+- reason ScheduledReset
+* Step 13:
+Message: StatusNotificationRequest
+- If the transaction was stopped at step 3, then connectorStatus Occupied
+Else connectorStatus Available
+Message: NotifyEventRequest
+- If the transaction was stopped at step 3, then eventData[0].actualValue "Occupied"
+Else eventData[0].actualValue "Available"
+- eventData[0].trigger Delta
+- eventData[0].component.name "Connector"
+- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td>Post scenario validations:
+- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 47. Test Case Id: TC_B_25_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset EVSE - Without ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_25_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B11</td></tr><tr><td>Requirement(s)</td><td colspan="2">B11.FR.01, B11.FR.08, B11.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can request the Charging Station to reset an EVSE by sending a ResetRequest without any ongoing transaction. This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Individual resetting EVSE supported</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type OnIdle and *evseld*<Configured evseld></td></tr><tr><td>Note(s): - <Configured evseld> reboot</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message ResetResponse - status Accepted</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 48. Test Case Id: TC_B_26_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset EVSE - With Ongoing Transaction - OnIdle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_26_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B12</td></tr><tr><td>Requirement(s)</td><td colspan="2">B12.FR.01, B12.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can remotely request the Charging Station to reset an EVSE by sending a ResetRequest during a transaction. When ResetRequest "OnIdle" is send the charging stations schedules a reboot after all transactions are stopped.
+This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Individual resetting EVSE supported</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a
+ResetResponse</td><td>1. The OCTT sends a ResetRequest
+with type OnIdle
+and evseld <Configured evseld></td></tr><tr><td colspan="2">3. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">4. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">5. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">6. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message ResetResponse
+- status Scheduled</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 49. Test Case Id: TC_B_27_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset EVSE - With Ongoing Transaction - Immediate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_27_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B12</td></tr><tr><td>Requirement(s)</td><td colspan="2">B12.FR.02, B12.FR.08, E07.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can remotely request the Charging Station to reset an EVSE by sending a ResetRequest during a transaction. When ResetRequest "Immediate" is send the charging stations will try to stop all transactions before rebooting.This could be example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Individual resetting EVSE supported</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type Immediate and *evseld*<Configured evseld></td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>Note(s):- The EVSE reboots</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message ResetResponse-status Accepted* Step 3:Message TransactionRequest-eventType Ended-triggerReason ResetCommand- transactionInfo.chargingState EVConnected- transactionInfo.stoppedReason ImmediateReset</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 50. Test Case Id: TC_B_28_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset EVSE - Not Supported</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_28_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B11, B12</td></tr><tr><td>Requirement(s)</td><td colspan="2">B11.FR.01, B11.FR.09, B12.FR.01, B12.FR.09</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can request the Charging Station to reset an EVSE by sending a ResetRequest while it is not supported by the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station does not support resetting individual EVSE</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type OnIdle and *evseld*<Configured evseld></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message ResetResponse - status Rejected</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 51. Test Case Id: TC_B_29_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset EVSE - With ongoing transaction - Not Supported</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_29_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B11</td></tr><tr><td>Requirement(s)</td><td colspan="2">B12.FR.01, B12.FR.09</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can request the Charging Station to reset an EVSE by sending a ResetRequest with ongoing transaction while it is not supported by the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station does not support resetting individual EVSE</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type OnIdle and evseld<Configured evseld></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message ResetResponse - status Rejected</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 52. Test Case Id: TC_B_43_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set new NetworkConnectionProfile - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_43_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B09</td></tr><tr><td>Requirement(s)</td><td colspan="2">B09.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS updates the connection details on the Charging Station. For instance in preparation of a migration to a new CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reject when the CSMS tries to set a network connection profile containing invalid data.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The OCTT sends a SetNetworkProfileRequest with:- configurationSlot is 999-connectionData.messageTimeout<Configured messageTimeout>- connectionData.ocppCsmsUrl<Configured ocppCsmsUrl>- connectionData.ocpplInterface<Configured ocplInterface>- connectionData.ocppVersion OCPP20- connectionData.securityProfile<Configured securityProfile></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetNetworkProfileResponse-status Rejected</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 53. Test Case Id: TC_B_45_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Migrate to new ConnectionProfile - Success - Same CSMS Root</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_45_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B09, B10</td></tr><tr><td>Requirement(s)</td><td colspan="2">B09.FR.01,B10.FR.01,B10.FR.04,B10.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS updates the connection details on the Charging Station. For instance in preparation of a migration to a new CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to migrate to another network connection profile slot.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">At least two configuration slots for networkConnectionProfiles must be supported</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The OCTT sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use -connectionData.messageTimeout<Configured messageTimeout> or <Configured messageTimeout2> -connectionData.ocppCsmsUrl<ocppCsmsUrl that is not currently active> -connectionData.ocpplInterface<Configured ocplInterface> or <Configured ocplInterface2> -connectionData.ocppVersion OCPP20 -connectionData.securityProfile<Configured securityProfile> or <Configured securityProfile2></td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The OCTT sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is Configured slot from Step 1, the previously configured slot</td></tr><tr><td>6. The Charging Station responds with a ResetResponse</td><td>5. The OCTT sends a ResetRequest with type OnIdleNote(s):- This step will only be executed when the status RebootRequired is returned at step 4, or if the charging does not automatically reboot.</td></tr><tr><td colspan="2">7. Execute Reusable State BootedNote(s):- The Charging Station connects using the <Configured connectionData2>.</td></tr><tr><td>Test case name</td><td>Migrate to new ConnectionProfile - Success - Same CSMS Root</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message SetNetworkProfileResponse
+- status Accepted
+* Step 4:
+Message SetVariablesResponse
+- setVariableResult[0].attributeStatus Accepted OR RebootRequired
+* Step 6:
+Message ResetResponse
+- status Accepted</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 54. Test Case Id: TC_B_46_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Migrate to new ConnectionProfile - Fallback mechanism - Same CSMS Root</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_46_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B10</td></tr><tr><td>Requirement(s)</td><td colspan="2">B10.FR.03,B10.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS updates the connection details on the Charging Station. For instance in preparation of a migration to a new CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to use the fallback mechanism when it is unable to connect with the first network connection profile slot.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">At least two configuration slots for networkConnectionProfiles must be supported</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:OCPPCommCtrletworkProfileConnectionAttempts is 2</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aSetNetworkProfileResponse</td><td>1. The OCTT sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use -connectionData.messageTimeout<Configured messageTimeout> or <Configured messageTimeout2> -connectionData.ocppCsmsUrl<ocppCsmsUrl that is not currently active> -connectionData.ocpplInterface<Configured ocplInterface> or <Configured ocplInterface2> -connectionData.ocppVersion OCPP20 -connectionData.securityProfile<Configured securityProfile> or <Configured securityProfile2></td></tr><tr><td>4. The Charging Station responds with aSetVariablesResponse</td><td>3. The OCTT sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is Configured slot from Step 1, the previously configured slot</td></tr><tr><td>6. The Charging Station responds with aResetResponse</td><td>5. The OCTT sends a ResetRequest with type OnIdleNote(s):- This step will only be executed when the status RebootRequired is returned at step 4, or if the charging does not automatically reboot.</td></tr><tr><td rowspan="4"></td><td></td><td>7. The OCTT will NOT respond to the two connection request from the Charging Station from the first connectionSlot.</td></tr><tr><td></td><td>8. The OCTT will accept the connection request from the Charging Station from the second connectionSlot.</td></tr><tr><td colspan="2">Note(s): Set the <Configured Long Operation Time Out> so that Steps 7 and 8 can be completed in this time period.</td></tr><tr><td colspan="2">9. Execute Reusable State Booted Note(s): - The Charging Station connects using the <Configured connectionData>.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message SetNetworkProfileResponse
+- status Accepted
+* Step 4:
+Message SetVariablesResponse
+- setVariableResult[0].attributeStatus Accepted OR RebootRequired
+* Step 6:
+Message ResetResponse
+- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+Table 55. Test Case Id: TC_B_47_CS
+
+<table><tr><td>Test case name</td><td>Migrate to new ConnectionProfile - Fallback after NetworkProfileConnectionAttempts per NetworkConfigurationPriority failed - New CSMS Root - New CSMS</td></tr><tr><td>Test case Id</td><td>TC_B_47_CS</td></tr><tr><td>Use case Id(s)</td><td>B09,B10,M05</td></tr><tr><td>Requirement(s)</td><td>B10.FR.07,M05.FR.15,M05.FR.16</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>The CSMS updates the connection details on the Charging Station. For instance in preparation of a migration to a new CSMS.</td></tr><tr><td>Purpose</td><td>To verify if the Charging Station is able to correctly handle the fallback mechanism in the case it fails to connect to the other CSMS.</td></tr><tr><td>Prerequisite(s)</td><td>- 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</td></tr><tr><td colspan="2"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td>Configuration State:
+OCPPCommCtrlr.NetworkProfileConnectionAttempts is 1</td></tr><tr><td>Memory State:
+CertificateInstalled for certificateType CSMSRootCertificate and certificate <Configured (new) CSMS Root certificate 2></td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Migrate to new ConnectionProfile - Fallback after NetworkProfileConnectionAttempts per NetworkConfigurationPriority failed - New CSMS Root - New CSMS</td></tr><tr><td rowspan="8">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The OCTT sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use - connectionData messageTimeout <Configured messageTimeout> or <Configured messageTimeout2> - connectionData.ocppCsmsUrl <ocppCsmsUrl that is not currently active> - connectionData.ocpplInterface <Configured ocplInterface> or <Configured ocplInterface2> - connectionData.ocppVersion OCPP20 - connectionData.securityProfile <Configured securityProfile> or <Configured securityProfile2></td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The OCTT sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is Configured slot from Step 1, the previously configured slot</td></tr><tr><td>6. The Charging Station responds with a ResetResponse</td><td>5. The OCTT sends a ResetRequest with type OnIdle</td></tr><tr><td>8. During the TLS handshake the Charging Station validates the CSMS certificate. Note(s): - This connection attempt fails, because the Charging Station will use the new CSMS Root certificate to validate the CSMS certificate.</td><td>7. During the TLS handshake the OCTT provides a CSMS certificate which is signed by the <Configured old CSMS Root certificate></td></tr><tr><td>9. The Charging Station switches back to the previous networkprofile configuration and validates the CSMS certificate, using the (fallback) CSMS Root certificate. Note(s): - This connection attempt succeeds, because the Charging Station will now use the (old) CSMS Root certificate to validate the CSMS certificate.</td><td></td></tr><tr><td colspan="2">10. Execute Reusable State Booted</td></tr><tr><td>12. The Charging Station responds with a GetInstalledCertificatesResponse</td><td>11. The OCTT sends a GetInstalledCertificatesRequest with certificateType is CSMSRootCertificate</td></tr><tr><td>Test case name</td><td>Migrate to new ConnectionProfile - Fallback after NetworkProfileConnectionAttempts per NetworkConfigurationPriority failed - New CSMS Root - New CSMS</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 6:
+Message ResetResponse
+- status Accepted
+* Step 12:
+Message: GetInstalledCertificatesResponse
+- status must be Accepted
+- certificateDataChain must contain an entry with following values:
+- certificateType is CSMSRootCertificate
+- certificateData contains <Data from configured old CSMS Root certificate></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 56. Test Case Id: TC_B_49_CS
+
+<table><tr><td>Test case name</td><td>Migrate to new ConnectionProfile - Fallback after NetworkProfileConnectionAttempts per NetworkConfigurationPriority failed - Same CSMS Root</td></tr><tr><td>Test case Id</td><td>TC_B_49_CS</td></tr><tr><td>Use case Id(s)</td><td>B10</td></tr><tr><td>Requirement(s)</td><td>B10.FR.07</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>The CSMS updates the connection details on the Charging Station. For instance in preparation of a migration to a new CSMS.</td></tr><tr><td>Purpose</td><td>To verify if the Charging Station is able to correctly handle the fallback mechanism in the case it fails to connect to the other CSMS.</td></tr><tr><td>Prerequisite(s)</td><td>- The Charging Station supports C-47: mechanism implemented & Reconnect after NetworkProfileConnectionAttempts
+- At least two configuration slots for networkConnectionProfiles must be supported</td></tr><tr><td colspan="2"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td>Configuration State:
+OCPPCommCtrl.NetworkProfileConnectionAttempts is 1
+OCPPCommCtrl.RetryBackOffRepeatTimes is 0
+OCPPCommCtrl.RetryBackOffRandomRange is 0
+OCPPCommCtrl.RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum></td></tr><tr><td>Memory State:
+N/a</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Migrate to new ConnectionProfile - Failback after NetworkProfileConnectionAttempts per NetworkConfigurationPriority failed - Same CSMS Root</td></tr><tr><td rowspan="8">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The OCTT sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use - connectionData.messageTimeout <Configured messageTimeout> or <Configured messageTimeout2> - connectionData.ocppCsmsUrl <ocppCsmsUrl that is not currently active> - connectionData.ocpptInterface <Configured ocpptInterface> or <Configured ocpptInterface2> - connectionData.ocppVersion OCPP20 - connectionData.securityProfile <Configured securityProfile> or <Configured securityProfile2></td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The OCTT sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is Configured slot from Step 1, the previously configured slot</td></tr><tr><td>6. The Charging Station responds with a ResetResponse</td><td>5. The OCTT sends a ResetRequest with type Idle</td></tr><tr><td>7. The Charging Station tries to connect to the alternative internal OCTT endpoint. Note(s): - Make sure to set the <Configured Long Operation Time Out> to be the time required for the CS to revert to the previous network profile configuration.</td><td>8. The connection attempt is not accepted by the OCTT.</td></tr><tr><td>9. The Charging Station switches back to the previous networkprofile configuration and reconnects to the OCTT.</td><td>10. The connection attempt is not accepted by the OCTT.</td></tr><tr><td>11. The Charging Station waits for the duration of the configured RetryBackOffWaitMinimum and reconnects to the OCTT.</td><td>12. The connection attempt is accepted by the OCTT.</td></tr><tr><td colspan="2">13. Execute Reusable State Booted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 6:
+Message ResetResponse
+- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+Table 57. Test Case Id: TC_B_50_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Migrate to new ConnectionProfile - Success - New CSMS Root - New CSMS</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_50_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B10,M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS updates the connection details on the Charging Station. For instance in preparation of a migration to a new CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly handle migrating to the new CSMS using a new CSMS Root certificate to validate the server certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- At least two configuration slots for networkConnectionProfiles must be supported AND
+- The Charging Station must be connected using either security profile 2 or 3.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+CertificatesInstalled for certificateType CSMSRootCertificate and certificate<Configured (new) CSMS Root certificate 2></td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetNetworkProfileResponse</td><td>1. The OCTT sends a SetNetworkProfileRequest with configurationSlot is <Configured configurationSlot> or <Configured configurationSlot2> depending on which one is already in use
+- connectionData.messageTimeout<Configured messageTimeout> or <Configured messageTimeout2>
+- connectionData.ocppCsmsUrl<ocppCsmsUrl that is not currently active>
+- connectionData.ocpplInterface<Configured ocplInterface> or <Configured ocplInterface2>
+- connectionData.ocppVersion OCPP20
+- connectionData.securityProfile<Configured securityProfile> or <Configured securityProfile2></td></tr><tr><td>4. The Charging Station responds with a SetVariablesResponse</td><td>3. The OCTT sends a SetVariablesRequest with variable.name is "NetworkConfigurationPriority" component.name is "OCPPCommCtrl" attributeValue is Configured slot from Step 1, the previously configured slot</td></tr><tr><td>6. The Charging Station responds with a ResetResponse</td><td>5. The OCTT sends a ResetRequest with type OnIdle</td></tr><tr><td>7. The Charging Station connects to the configured alternative internal OCTT endpoint.
+Note(s):
+- During the TLS handshake the Charging Station validates and accepts the CSMS certificate, signed by the <Configured (new) CSMS Root certificate 2>.</td><td>8. The connection attempt is accepted by the OCTT.</td></tr><tr><td colspan="2">9. Execute Reusable State Booted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 6:
+Message ResetResponse
+- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 58. Test Case Id: TC_B_51_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Status change during offline period - > Offline Threshold</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_51_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B04</td></tr><tr><td>Requirement(s)</td><td colspan="2">B04.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">A Charging Station sends a notification to the CSMS to inform the CSMS about a Connector status change. This can be done in two ways. Via a StatusNotificationRequest or a NotifyEventRequest from the device model. When the Charging Station is connected again to the CSMS after having been offline, and the Charging Station was longer offline than the configured threshold, it will report the status of every connector.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station reports the status of all connectors after having been offline for longer than the configured threshold with the configuration variable OfflineThreshold.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">If the Charging Station does not have more than one EVSE, this testcase will be equal to TC_B_52_CS.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:OCPPCommCtrl.RoutineThreshold is <Configured offlineThreshold>OCPPCommCtrl.RetryBackOffWaitMinimum is <Configured offlineThreshold> + 2 secondsOCPPCommCtrl.RetryBackOffRandomRange is 0</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td></td><td>1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">2. Manual Action: Connect the EV and EVSE.</td></tr><tr><td></td><td>3. The OCTT accepts reconnection attempt from the Charging Station, after the configured threshold has been exceeded.</td></tr><tr><td>4. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>5. The OCTT responds accordingly.</td></tr><tr><td>Test case name</td><td>Status change during offline period - > Offline Threshold</td></tr><tr><td>Tool validations</td><td>* Step 4:
+Configured EVSE/Connector:
+Message: StatusNotificationRequest
+- connectorStatus Occupied
+- evseld <Configured evseld>
+- connectorId <Configured connectorId>
+Message: NotifyEventRequest
+- eventData[0].trigger Delta
+- eventData[0].actualValue "Occupied"
+- eventData[0].component.name "Connector"
+- eventData[0].variable.name "AvailabilityState"
+- eventData[0].evse.id <Configured evseld>
+- eventData[0].connectorId <Configured connectorId></td></tr><tr><td></td><td>All other EVSE/Connector(s):
+Message: StatusNotificationRequest
+- connectorStatus Available
+Message: NotifyEventRequest
+- eventData[0].trigger Delta
+- eventData[0].actualValue "Available"
+- eventData[0].component.name "Connector"
+- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td></td><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 59. Test Case Id: TC_B_52_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Status change during offline period - < Offline Threshold</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_52_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B04</td></tr><tr><td>Requirement(s)</td><td colspan="2">B04.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">A Charging Station sends a notification to the CSMS to inform the CSMS about a Connector status change. This can be done in two ways. Via a StatusNotificationRequest or a NotifyEventRequest from the device model. When the Charging Station is connected again to the CSMS after having been offline, and the Charging Station was shorter offline than the configured threshold, it will report the status of all connector that received a status change.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station reports the status of connectors that received a status change after having been offline for shorter than the configured threshold with the configuration variable OfflineThreshold.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:OCPPCommCtrl.OfflineThreshold is <Configured offlineThreshold>OCPPCommCtrl.RetryBackOffWaitMinimum is <Configured offlineThreshold> - 2 secondsOCPPCommCtrl.RetryBackOffRandomRange is 0</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">2. Manual Action: Connect the EV and EVSE.</td></tr><tr><td colspan="2">3. The OCTT accepts reconnection attempt from the Charging Station.</td></tr><tr><td>4. The Charging Station notifies the CSMS about the current state of the configured connector.</td><td>5. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3:Message: StatusNotificationRequest- connectorStatus Occupied- evseld<Configured evseld>- connectorId<Configured connectorId>Message: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Occupied"- eventData[0].component.name "Connector"- eventData[0].variable.name "AvailabilityState"- eventData[0].evse.id<Configured evseld>- eventData[0].connectorId<Configured connectorId></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 60. Test Case Id: TC_B_53_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Base Report - Test mandatory DM variables via FullInventory</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_53_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B07</td></tr><tr><td>Requirement(s)</td><td colspan="2">Chapter Referenced Components and Variables</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a FullInventory base report.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports all required DM variables.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. CS responds with:GetBaseReportResponse with status = Accepted3. CS sends one or more NotifyReportRequest messages to report all its component/variables.</td><td>1. OCTT requests a GetBaseReportRequest with:reportBase = FullInventory andrequestId = <Generated requestId>4. OCTT responds with a NotifyReportResponse for each NotifyReportRequest</td></tr><tr><td rowspan="4">Tool validations</td><td colspan="2">* Step 2:Message: GetBaseReportResponse with:- status = Accepted- statusInfo is absent or statusInfo = "NoError"</td></tr><tr><td colspan="2">* step 3:Message: NotifyReportRequest with:- requestId = <Generated requestId>- generatedAt = <time of generation at charging station>- seqNo = 0</td></tr><tr><td>While tbc = true</td><td>Message: NotifyReportRequest- seqNo is incremented by one</td></tr><tr><td colspan="2">Post scenario validations:The OCTT checks that:- the components / variables that are required according to the OCPP specification are implemented;- for each component/variable, where variableCharacteristics.dataType is set to OptionList, SequenceList or MemberList, the variableCharacteristics.valuesList is not omitted or empty;- for each component/variable, where variableCharacteristics.dataType is OptionList, SequenceList orMemberList, the variableAttribute.value is allowed based on the values in the providedvariableCharacteristics.valuesList;- for variables with mutability set to WriteOnly the variableAttribute.value is omitted in theNotifyReportRequest.</td></tr></table>
+
+Table 61. Test Case Id: TC_B_54_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Custom Report - with component/variable, but no instance</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_54_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B08</td></tr><tr><td>Requirement(s)</td><td colspan="2">B08.FR.01, B08.FR.03, B08.FR.04, B08.FR.11, B08.FR.12, B08.FR.14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a custom report for ItemsPerMessage of DeviceDataCtrl.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station will send all instances if instance is not given.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented custom reporting (use case B08).</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds:GetReportResponse</td><td>1. OCTT sends GetReportRequest with:- requestId = <Generated requestId>componentVariable.parent.name="DeviceDataCtrl"- componentVariable.parent.name = "ItemsPerMessage"</td></tr><tr><td>3. Charging Station sends NotifyReportRequest</td><td>4. OCTT responds with NotifyReportResponse</td></tr><tr><td rowspan="3">Tool validations</td><td colspan="2">* Step 2:Message: GetReportResponse with:- status = Accepted-statusInfo is absent or statusInfo = "NoError"</td></tr><tr><td colspan="2">* step 3:Message: NotifyReportRequest with:- reportData[0].component.name = "DeviceDataCtrl"- reportData[0].variable.name = "ItemsPerMessage"- reportData[0].variable.instance = "GetReport"- reportData[1].component.name = "DeviceDataCtrl"- reportData[1].variable.name = "ItemsPerMessage"- reportData[1].variable.instance = "GetVariable"Note: for AvailabilityState there will only be an Actual value.It does not make any sense to have a MinSet, MaxSet or Target value for it...</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 62. Test Case Id: TC_B_55_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Custom Report - with component/variable/instance</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_55_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B08</td></tr><tr><td>Requirement(s)</td><td colspan="2">B08.FR.01, B08.FR.03, B08.FR.04, B08.FR.11, B08.FR.12, B08.FR.14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a custom report for ItemsPerMessage of DeviceDataCtrlr.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station will send one instances if instance is given.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented custom reporting (use case B08).</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds:GetReportResponse</td><td>1. OCTT sends GetReportRequest with:- requestId = <Generated requestId>componentVariable.parent.name="DeviceDataCtrlr"- componentVariable.parent.name = "ItemsPerMessage"- componentVariable.instance = "GetReport"</td></tr><tr><td>3. Charging Station sends NotifyReportRequest</td><td>4. OCTT responds with NotifyReportResponse</td></tr><tr><td rowspan="3">Tool validations</td><td colspan="2">* Step 2:Message: GetReportResponse with:- status = Accepted-statusInfo is absent or statusInfo = "NoError"</td></tr><tr><td colspan="2">* step 3:Message: NotifyReportRequest with:- reportData[0].component.name = "DeviceDataCtrlr"- reportData[0].variable.name = "ItemsPerMessage"- reportData[0].variable.instance = "GetReport"Note: for AvailabilityState there will only be an Actual value.It does not make any sense to have a MinSet, MaxSet or Target value for it._</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 63. Test Case Id: TC_B_56_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Custom Report - with component/variable, but no evseld</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_56_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B08</td></tr><tr><td>Requirement(s)</td><td colspan="2">B08.FR.01, B08.FR.03, B08.FR.04, B08.FR.11, B08.FR.12, B08.FR.14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a custom report for AvailabilityState of EVSE</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station will send all EVSEs when evseld is not given.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented custom reporting (use case B08).</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds:
+GetReportResponse</td><td>1. OCTT sends GetReportRequest with:
+- requestId = <Generated requestId>
+- componentVariable.parent.name = "EVSE"
+- componentVariable variable.name = "AvailabilityState"</td></tr><tr><td>3. Charging Station sends NotifyReportRequest</td><td>4. OCTT responds with NotifyReportResponse</td></tr><tr><td rowspan="3">Tool validations</td><td colspan="2">* Step 2:
+Message: GetReportResponse with:
+- status = Accepted
+- statusInfo is absent or statusInfo = "NoError"</td></tr><tr><td colspan="2">* step 3:
+Message: NotifyReportRequest with:
+- reportData[i].component.name = "EVSE"
+- reportData[i].variable.name = "AvailabilityState"
+- number of EVSEs = <Configured EVSE count>
+Note: for AvailabilityState there will only be an Actual value.
+It does not make any sense to have a MinSet, MaxSet or Target value for it...</td></tr><tr><td colspan="2">Post scenario validations:
+N/A</td></tr></table>
+
+Table 64. Test Case Id: TC_B_57_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Network Reconnection - After connection loss</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_57_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">Part 4 section 5.3. Reconnecting</td></tr><tr><td>Requirement(s)</td><td colspan="2">Described at section 5.3.</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">When the connection is lost, the Charging Station SHALL try to reconnect. When reconnecting, the Charging Station SHALL use an increasing back-off time until it has successfully reconnected.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reconnect to the CSMS using the described OCPP reconnecting mechanism from part 4.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:OCPPCommCtrl.RetryBackOffRepeatTimes is 2OCPPCommCtrl.RetryBackOffRandomRange is 0OCPPCommCtrl.RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum></td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the websocket connection.</td></tr><tr><td>2. The Charging Station waits for the duration of the configured RetryBackOffWaitMinimum and reconnects to the OCTT.</td><td>3. The connection attempt is accepted by the OCTT.</td></tr><tr><td colspan="2">4. The OCTT closes the websocket connection.</td></tr><tr><td>5. The Charging Station waits for the duration of the configured RetryBackOffWaitMinimum and reconnects to the OCTT.</td><td>6. The connection attempt is not accepted by the OCTT.</td></tr><tr><td>7. The Charging Station waits for the duration of the at step 5 doubled RetryBackOffWaitMinimum and reconnects to the OCTT.</td><td>8. The connection attempt is accepted by the OCTT.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:- The reconnection time is at least the configured RetryBackOffWaitMinimum.* Step 7:- The reconnection time is at least 2 times the reconnection time from step 5.</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+# 2.4. C Authorization
+
+Table 65. Test Case Id: TC_C_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - Authorization Invalid/Unknown</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C01 OR C04 OR C06</td></tr><tr><td>Requirement(s)</td><td colspan="2">C01.FR.02 OR C06.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">When a Charging Station needs to charge an EV, it needs to authorize the EV Driver first at the CSMS before the charging can be started or stopped.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to handle receiving an invalid idToken.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports at least one authorization method described at the following Use cases; C01, C04, C06.
+- The Charging Station does NOT have a cable lock, which prevents the EV driver to connect the EV and EVSE before authorization.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present idToken.</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Invalid</td></tr><tr><td colspan="2">Note(s):
+- The Charging Station SHALL NOT send a TransactionEventRequest message after the AuthorizationRequest from step 1.
+- The OCTT waits <Configured message timeout> seconds, before ending the testcase.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: AuthorizationRequest
+-idToken.idToken <Configured invalid_idtoken_idtoken>
+-idToken.type <Configured invalid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 66. Test Case Id: TC_C_05_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - Authorization invalid - Cable lock</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_05_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C01 OR C04 OR C06</td></tr><tr><td>Requirement(s)</td><td colspan="2">C01.FR.02 OR C06.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">When a Charging Station needs to charge an EV, it needs to authorize the EV Driver first before the charging can be started or stopped.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether a Charging Station with a cable lock, which prevents the EV driver to connect the EV and EVSE before authorization, is able to handle receiving an invalid idToken.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station has a cable lock, which prevents the EV driver to connect the EV and EVSE before authorization.
+- The Charging Station supports at least one authorization method described at the following Use cases; C01, C04, C06.
+- The Charging Station does NOT have the following configuration; TxStartPoint ReadOnly AND value Authorized is NOT set.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present idToken.</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Invalid</td></tr><tr><td colspan="2">Note(s):
+- The Charging Station SHALL NOT send a TransactionEventRequest message after the AuthorizationRequest from step 1.
+- The OCTT waits <Configured message timeout> seconds, before ending the testcase.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: AuthorizationRequest
+-idToken.idToken <Configured invalid_idtoken_idtoken> - idToken.type <Configured invalid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 67. Test Case Id: TC_C_04_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Local Stop Transaction - Different idToken</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C01, C04, E07</td></tr><tr><td>Requirement(s)</td><td colspan="2">C01.FR.02, C01.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The EV Driver tries to stop an ongoing transaction, by locally presenting a different IdToken.</td></tr><tr><td>Purpose</td><td colspan="2">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.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- 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</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrlDisableRemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">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".</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present a different idToken than used to start the transaction.</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Accepted</td></tr><tr><td colspan="2">Note(s):
+- The Charging Station SHALL NOT send 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.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- Charging Station has not sent a TransactionEventRequest(Ended).</td></tr></table>
+
+Table 68. Test Case Id: TC_C_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - AuthorizationBlocked</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_06_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C01</td></tr><tr><td>Requirement(s)</td><td colspan="2">C01.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">When a Charging Station needs to charge an EV, it needs to authorize the EV Driver first at the CSMS before the charging can be started or stopped.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to handle receiving an Linked idToken.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station does NOT have a cable lock, which prevents the EV driver to connect the EV and EVSE before authorization.
+The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl_DISABLERemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present idToken.</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Locked</td></tr><tr><td colspan="2">Note(s):
+- The Charging Station SHALL NOT send a TransactionEventRequest message after the AuthorizationRequest from step 7.
+- The OCTT waits <Configured message timeout> seconds, before ending the testcase.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: AuthorizationRequest
+-idToken.idToken<Configured blocked_idtoken_idtoken>
+-idToken.type<Configured blocked_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 69. Test Case Id: TC_C_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - Authorization Expired</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C01</td></tr><tr><td>Requirement(s)</td><td colspan="2">C01.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">When a Charging Station needs to charge an EV, it needs to authorize the EV Driver first at the CSMS before the charging can be started or stopped.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to handle receiving an Expired idToken.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station does NOT have a cable lock, which prevents the EV driver to connect the EV and EVSE before authorization.
+The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present idToken.</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Expired</td></tr><tr><td colspan="2">Note(s):
+- The Charging Station SHALL NOT send a TransactionEventRequest message after the AuthorizationRequest from step 7.
+- The OCTT waits <Configured message timeout> seconds, before ending the testcase.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: AuthorizationRequest
+-idToken.idToken<Configured expired_idtoken_idtoken>
+-idToken.type<Configured expired_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 70. Test Case Id: TC_C_08_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_08_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_02, C12_FR_04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as no AuthorizationRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able toauthorize an idToken which has status "Accepted" in its cache according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">-AuthCacheCtrl AUTHCacheAvailable is implemented with value true
+-The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheCtrl AUTHCacheEnabled is true (If implemented)
+AuthCtrl.LocalPreAuthorize is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields></td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized</td></tr><tr><td colspan="2">Note(s): Present valid idToken which is already configured in the Authorization Cache</td></tr><tr><td colspan="2">2. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- Energy transfer is started</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 71. Test Case Id: TC_C_09_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - Invalid & Not Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_09_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_05, C10_FR_03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as no AuthorizationRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able toauthorize an idToken which has status "Invalid" in its cache according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">AuthCacheCtrl AUTHCacheAvailable is implemented with value true
+The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheCtrl AUTHCacheEnabled is true (If implemented)
+AuthCtrl.LocalPreAuthorize is true (If implemented)
+AuthCacheCtrlDisablePostAuthorize is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured invalid IdToken fields></td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present Invalid idToken which is already configured in the Authorization Cache</td></tr><tr><td>1. The Charging Station sends a AuthorizationRequest</td><td>2. The OCTT responds with a AuthorizationResponse with idTokenInfo.status Invalid</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message AuthorizationRequest
+-idToken.idToken<Configured invalid_idtoken_idtoken>
+-idToken.type<Configured invalid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 72. Test Case Id: TC_C_10_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - Restricted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_10_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_05, C10_FR_03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as no AuthorizationRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to authorize an idToken which has status "Blocked" in its cache according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">AuthCacheCtrl AUTHCacheAvailable is implemented with value trueThe Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="22">Before(Preparations)</td><td rowspan="22" colspan="2">Configuration State:AuthCacheCtrl AUTHCacheEnabled is true (If implemented)AuthCtrl.LocalPreAuthorize is true (If implemented)AuthCacheCtrlDisablePostAuthorization is false (If implemented)</td></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present Cached idToken which is already configured in the Authorization Cache</td></tr><tr><td>1. The Charging Station sends a AuthorizationRequest</td><td>2. The OCTT responds with a AuthorizedResponse withidTokenInfo.status Restricted</td></tr><tr><td>Tool validations</td><td>* Step 1:*Step 1:*Message AuthorizationRequest- idToken.idToken <Configured blocked_idtoken_idtoken>- idToken.type <Configured blocked_idtoken_type>Post scenario validations:- N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 73. Test Case Id: TC_C_11_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - Expired</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_11_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_05, C10_FR_03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as no AuthorizationRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able toauthorize an idToken which has status "Expired" in its cache according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">AuthCacheCtrl AUTHCacheAvailable is implemented with value true
+The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheCtrl AUTHCacheEnabled is true (If implemented)
+AuthCtrl.LocalPreAuthorize is true (If implemented)
+AuthCacheCtrlDisablePostAuthorize is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured expired IdToken fields></td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present Expired idToken which is already configured in the Authorization Cache</td></tr><tr><td>1. The Charging Station sends a AuthorizationRequest</td><td>2. The OCTT responds with a TransactionEventResponse with idTokenInfo.status Expired</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message AuthorizationRequest
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 74. Test Case Id: TC_C_12_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - Invalid & Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_12_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_05, C10_FR_03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as no AuthorizationRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to authorize an idToken which has status "Invalid" in its cache, but the CSMS has status "Valid", according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- AuthCacheCtrlAuthCacheAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheCtrlAuthCacheEnabled is true (If implemented)
+AuthCtrl.LocalPreAuthorize is true (If implemented)
+AuthCacheCtrlDisablePostAuthorize is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured invalid IdToken fields></td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="5">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present Invalid idToken which is already configured in the Authorization Cache</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Accepted</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest
+Note(s):
+-This step is optional.</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message AuthorizationRequest
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+- Energy transfer is started</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 75. Test Case Id: TC_C_13_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - Accepted but cable not connected yet.</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_13_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_02, C12_FR_04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as no AuthorizationRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able toauthorize an idToken which has status "Accepted" in its cache but the cable is not connected yet according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">-AuthCacheCtrlr.AuthCacheAvailable is implemented with value true
+-The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheCtrlr.AuthCacheEnabled is true (If implemented)
+AuthCtrlr.LocalPreAuthorization is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields> (If implemented)</td></tr><tr><td colspan="2">Reusable State(s):
+If applicable, State is ParkingBayOccupied</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken which is already configured in the Authorization Cache</td></tr><tr><td>1. The Charging Station sends a TransactionEventRequest</td><td>2. The OCTT responds with a TransactionEventResponse with idTokenInfo.status Accepted</td></tr><tr><td colspan="2">Note(s):
+- This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy. - As long as the cable is not plugged in the energy transfer will not start.</td></tr><tr><td colspan="2">3. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">4. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message TransactionEventRequest
+-triggerReason Authorized
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type>
+if transaction was already started
+-eventType Updated
+else
+-eventType Started</td></tr><tr><td colspan="2">Post scenario validations:
+- Energy transfer is started</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 76. Test Case Id: TC_C_14_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - GroupID equal to MasterPassGroupId.</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_14_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_09, C16.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as no InvalidateRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly to an idToken which has the "MasterPassGroupId" as group id according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">AuthCacheCtrlAuthCacheAvailable is implemented with value trueThe Charging station supports MasterPass feature.The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:AuthCacheCtrlAuthCacheEnabled is true (If implemented)AuthCtrl.LocalPreAuthorize is true (If implemented)AuthCtrl.MasterPassGroupId is <Configured MasterPassGroupId></td></tr><tr><td colspan="2">Memory State:Store the idToken that is part of the MasterPass group at the cache.</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action:Present the idToken with group id "MasterPassGroupId" which is already configured in the Authorization Cache</td></tr><tr><td>1. The Charging Station sends aTransactionEventRequest</td><td>2. The OCTT responds with aTransactionResponse</td></tr><tr><td colspan="2">3. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">4. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">5. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">Note(s):Step 3, 4, and 5 are only executed if the transaction is still running.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message TransactionEventRequest- triggerReason StopAuthorized-idToken.idToken<Configured masterPass idToken>- idToken.type<Configured masterPass idTokenType>If eventType Ended, then:- transactionInfo.stoppedReason MasterPass</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 77. Test Case Id: TC_C_15_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - StopTxOnInvalidld = false, MaxEnergyOnInvalidld > 0</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_15_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_02, C12_FR_04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as noauthorizeRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly to an idToken which has status "Accepted" in its cache but is "Invalid" in the CSMS with certain values of StopTxOnInvalidld and MaxEnergyOnInvalidld according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- AuthCacheCtrlAuthCacheAvailable is implemented with value true
+- The Charging Station has MaxEnergyOnInvalidld implemented
+- At least one of the following must be supported; Local auth list, auth cache, StartTxUnknownlds.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+AuthCacheCtrlAuthCacheEnabled is true (If implemented)
+AuthCtrl.LocalPreAuthorize is true (If implemented)
+AuthCtrl.LocalAuthorizationOffline is true
+OfflineTxForUnknownIdEnabled is true (If implemented)
+StopTxOnInvalidld is false
+MaxEnergyOnInvalidld 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></td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields> (If implemented) A known valid idToken is configured in the Local auth list (if implemented) and auth cache (if implemented)</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="7">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Present valid idToken which is already configured in the Authorization Cache</td></tr><tr><td colspan="2">Note(s): The OCTT will wait for_<Configured Transaction Duration> seconds_</td></tr><tr><td colspan="2">2. The OCTT accepts reconnection attempt from the Charging Station.</td></tr><tr><td colspan="2">Note(s):
+- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionEventRequest messages</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionResponse with idTokenInfo.status Invalid (if idToken is not omitted)</td></tr><tr><td>Test case name</td><td>Authorization through authorization cache - StopTxOnInvalidId = false, MaxEnergyOnInvalidId > 0</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 3:
+Message TransactionRequest
+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</td></tr><tr><td>Post scenario validations:
+- Energy transfer is started but only MaxEnergyOnInvalidId amount of energy is delivered</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 78. Test Case Id: TC_C_16_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - StopTxOnInvalidId = true</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_16_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_02, C12_FR_04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as no InvalidateRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly to an idToken which has status "Accepted" in its cache but is "Invalid" in the CSMS when StopTxOnInvalidId is true according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisites(s)</td><td colspan="2">- AuthCacheCtrlr.AuthCacheAvailable is implemented with value true
+- At least one of the following must be supported; Local auth list, auth cache, StartTxUnknownIds.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)
+LocalAuthorizationOffline is true
+StopTxOnInvalidId is true
+MaxEnergyOnInvalidId is 0</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields> (If implemented)
+A known valid idToken is configured in the Local auth list (if implemented) and auth cache (if implemented)</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="8">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Present valid idToken which is already configured in the Authorization Cache</td></tr><tr><td colspan="2">Note(s): The OCTT will wait for 5 seconds</td></tr><tr><td colspan="2">2. The OCTT accepts reconnection attempt from the Charging Station.</td></tr><tr><td colspan="2">Note(s):
+- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionEventRequest messages</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse with idTokenInfo.status Invalid (if idToken is not omitted)</td></tr><tr><td>5. The Charging Station sends a TransactionEventRequest with triggerReason Deauthorized</td><td>6. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>Test case name</td><td>Authorization through authorization cache - StopTxOnInvalidId = true</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 3:
+Message TransactionRequest
+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
+A message with:
+- triggerReason Deauthorized</td></tr><tr><td>Post scenario validations:
+- Energyflow stops on receiving status invalid</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 79. Test Case Id: TC_C_17_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - StopTxOnInvalidld = false</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_17_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_02, C12_FR_04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as no InvalidateRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly to an idToken which has status "Accepted" in its cache but is "Invalid" in the CSMS when StopTxOnInvalidld is false according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">-AuthCacheCtrlr.AuthCacheAvailable is implemented with value true-At least one of the following must be supported; Local auth list, auth cache, StartTxUnknownlds.-The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:AuthCacheEnabled is true (If implemented)LocalPreAuthorize is true (If implemented)OfflineTxForUnknownldEnabled is true (If implemented)StopTxOnInvalidld is falseMaxEnergyOnInvalidld is 0</td></tr><tr><td colspan="2">Memory State:IdTokenCached for <Configured valid IdToken fields> (If implemented) A known valid idToken is configured in the Local auth list (if implemented) and auth cache (if implemented)</td></tr><tr><td colspan="2">Reusable State(s):State is EVConnectedPreSession</td></tr><tr><td rowspan="8">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Present valid idToken which is already configured in the Authorization Cache</td></tr><tr><td colspan="2">Note(s): The OCTT will wait for 5 seconds</td></tr><tr><td colspan="2">2. The OCTT accepts reconnection attempt from the Charging Station.</td></tr><tr><td colspan="2">Note(s):- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionEventRequest messages</td></tr><tr><td>3. The Charging Station sends aTransactionEventRequest</td><td>4. The OCTT responds with aTransactionEventResponse withidTokenInfo.status Invalid (if idToken is not omitted)</td></tr><tr><td>5. The Charging Station sends aTransactionEventRequest with triggerReason SuspendedEVSE</td><td>6. The OCTT responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message TransactionEventRequestA message with:- triggerReason Authorized-idToken.idToken<Configured valid_idtoken_idtoken>- idToken.type<Configured valid_idtoken_type>- offline TrueA message with:- transactionInfo.chargingState SuspendedEVSENo message with: - triggerReason SuspendedEVSE</td></tr><tr><td colspan="2">Post scenario validations:- Energyflow stops on receiving status invalid</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 80. Test Case Id: TC_C_18_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - StopTxOnInvalidId = true, MaxEnergyOnInvalidId > 0</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_18_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_02, C12_FR_04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as no AuthorizationRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly to an idToken which has status "Accepted" in its cache but is "Invalid" in the CSMS when StopTxOnInvalidId is true and MaxEnergyOnInvalidId > 0 according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- AuthCacheCtrlAuthCacheAvailable is implemented with value true
+- The Charging Station has MaxEnergyOnInvalidId implemented.
+- At least one of the following must be supported; Local auth list, auth cache, StartTxUnknownIds.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+AuthCacheEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)
+LocalAuthorizationOffline is true
+OfflineTxForUnknownIdEnabled is true (If implemented)
+StopTxOnInvalidId is true
+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></td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields> (If implemented)
+A known valid idToken is configured in the Local auth list (if implemented) and auth cache (if implemented)</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="8">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Present valid idToken which is already configured in the Authorization Cache</td></tr><tr><td colspan="2">Note(s): The OCTT will wait for_<Configured Transaction Duration> seconds_</td></tr><tr><td colspan="2">2. The OCTT accepts reconnection attempt from the Charging Station.</td></tr><tr><td colspan="2">Note(s):
+- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionEventRequest messages</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse with idTokenInfo.status Invalid (if idToken is not omitted)</td></tr><tr><td>5. The Charging Station sends a TransactionEventRequest with triggerReason Deauthorized</td><td>6. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>Test case name</td><td>Authorization through authorization cache - StopTxOnInvalidId = true, MaxEnergyOnInvalidId > 0</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 3:
+Message TransactionRequest
+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
+* Step 5:
+A message with:
+- triggerReason Deauthorized
+- offline False</td></tr><tr><td>Post scenario validations:
+- Energyflow stops on receiving status invalid</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 81. Test Case Id: TC_C_57_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - AuthCacheDisablePostAuthorize</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_57_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_05, C10_FR_03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver can be authorized to start a transaction by using Cached IdTokens. This enables the EV Driver to start a transaction while the Charging Station is online by using the Authorization Cache in which case the Charging Station can respond faster, since no AuthorizationRequest is being sent. For an IdToken that does not have status "Accepted" the Charging Station will still send an AuthorizationRequest to check against the most recent status from CSMS. However, when the setting AuthCacheDisablePostAuthorize is set to true, then the Charging Station will not do this.</td></tr><tr><td>Purpose</td><td colspan="2">To verify that the Charging Station will not send an AutorizeRequest for an IdToken in the Authorization Cache that is not "Accepted", when AuthCacheDisablePostAuthorize is set to true.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">-AuthCacheCtrlr.Available is implemented with value true
+-AuthCacheCtrlrDISABLEPostAuthorize is implemented
+-The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+AuthCacheCtrlr.Enabled is true (If implemented)
+AuthCtrlr.LocalPreAuthorize is true (If implemented)
+AuthCacheCtrlrDISABLEPostAuthorize is true</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured invalid IdToken fields></td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present Invalid idToken which is already configured in the Authorization Cache</td></tr><tr><td>1. The Charging Station does NOT send a AuthorizationRequest</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Check that Charging Station does NOT send an AuthorizationRequest and authorization is refused.</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 82. Test Case Id: TC_C_27_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Online authorization through local authorization list - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_27_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C14</td></tr><tr><td>Requirement(s)</td><td colspan="2">C14_FR_02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. When online the Charging Station can then locally authorize the IdToken, and is not required to send an AuthorizationRequest for a known IdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to authorize an idToken which has status "Accepted" in its local authorization list according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrl LocalAuthListAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorization is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+A known valid idToken is configured in the Local Authorization List</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="5">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken which is already configured in the Local Authorization List</td></tr><tr><td>1. The Charging Station sends a TransactionEventRequest
+Note(s):
+- This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy</td><td>2. The OCTT responds with a TransactionEventResponse with - idTokenInfo.status Accepted</td></tr><tr><td colspan="2">3. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">4. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message TransactionEventRequest
+- triggerReason Authorized
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+- Energy is transferred</td></tr></table>
+
+Table 83. Test Case Id: TC_C_28_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Online authorization through local authorization list - Invalid & Not Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_28_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C14</td></tr><tr><td>Requirement(s)</td><td colspan="2">C14_FR_03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. When online the Charging Station can then locally authorize the IdToken, and is not required to send anauthorizeRequest for a known IdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly to an idToken which has status "Invalid" in its local authorization list according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrl.LocalAuthListAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorization is true (If implemented)
+*LocalAuthListDisablePostAuthorization * false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+A known invalid idToken is configured in the Local Authorization List</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present invalid idToken which is already configured in the Local Authorization List</td></tr><tr><td>1. The Charging Station sends aauthorizeRequest</td><td>2. The OCTT responds with aauthorizeResponse with idTokenInfo.status Invalid</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+MessageauthorizeRequest
+-idToken.idToken<Configured invalid_idtoken_idtoken>
+-idToken.type<Configured invalid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+Table 84. Test Case Id: TC_C_29_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Online authorization through local authorization list - Restricted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_29_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C14</td></tr><tr><td>Requirement(s)</td><td colspan="2">C14_FR_03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. When online the Charging Station can then locally authorize the IdToken, and is not required to send an AuthorizationRequest for a known IdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly to an idToken which has status "Blocked" in its local authorization list according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrl.LocalAuthListAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)
+*LocalAuthListDisablePostAuthorization * false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+A known blocked idToken is configured in the Local Authorization List</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present blocked idToken which is already configured in the Local Authorization List</td></tr><tr><td>1. The Charging Station sends a AuthorizationRequest</td><td>2. The OCTT responds with a AuthorizationResponse with idTokenInfo.status Restricted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message AuthorizationRequest
+-idToken.idToken <Configured blocked_idtoken_idtoken>
+-idToken.type <Configured blocked_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+Table 85. Test Case Id: TC_C_30_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Online authorization through local authorization list - Expired</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_30_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C14</td></tr><tr><td>Requirement(s)</td><td colspan="2">C14_FR_03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. When online the Charging Station can then locally authorize the IdToken, and is not required to send anauthorizeRequest for a known IdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly to an idToken which has status "Expired" in its local authorization list according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrlr.LocalAuthListAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorization is true (If implemented)
+*LocalAuthListDisablePostAuthorization * false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+A known expired idToken is configured in the Local Authorization List</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present expired idToken which is already configured in the Local Authorization List</td></tr><tr><td>1. The Charging Station sends aauthorizeRequest</td><td>2. The OCTT responds with aauthorizeResponse with idTokenInfo.status Expired</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+MessageauthorizeRequest
+-idToken.idToken<Configured expired_idtoken_idtoken>
+-idToken.type<Configured expired_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+Table 86. Test Case Id: TC_C_31_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Online authorization through local authorization list - Invalid & Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_31_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C14</td></tr><tr><td>Requirement(s)</td><td colspan="2">C14_FR_03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. When online the Charging Station can then locally authorize the IdToken, and is not required to send anauthorizeRequest for a known IdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly to an idToken which has status "Invalid" in its local authorization list, but is actually valid for the CSMS, according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrl.LocalAuthListAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)
+*LocalAuthListDisablePostAuthorization * false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+A known invalid idToken is configured in the Local Authorization List</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized
+Note(s):
+- Present invalid idToken which is already configured in the Local Authorization List</td></tr><tr><td colspan="2">2. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">-N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- Energy is transferred</td></tr></table>
+
+Table 87. Test Case Id: TC_C_58_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Online authorization through local authorization list - LocalAuthListDisablePostAuthorization</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_28_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C14</td></tr><tr><td>Requirement(s)</td><td colspan="2">C14_FR_03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. While online the Charging Station can then locally authorize the IdToken, and is not required to send an AuthorizationRequest for a known IdToken. For an IdToken that does not have status "Accepted" the Charging Station will still send an AuthorizationRequest to check against the most recent status from CSMS. However, when the setting LocalAuthListDisablePostAuthorization is set to true, then the Charging Station will not do this.</td></tr><tr><td>Purpose</td><td colspan="2">To verify that the Charging Station will not send an AuthorizationRequest for an idToken which has status "Invalid" in its local authorization list.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrlr.Available is implemented with value true
+- LocalAuthListCtrlrDISABLEPostAuthorization is implemented.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListCtrlr.Enabled is true (If implemented)
+AuthCtrlr.LocalPreAuthorization is true (If implemented)
+LocalAuthListCtrlrDISABLEPostAuthorization true</td></tr><tr><td colspan="2">Memory State:
+IdTokenLocalAuthList for <Configured invalid idtoken fields></td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present invalid idToken which is already configured in the Local Authorization List</td></tr><tr><td>1. The Charging Station does NOT send a AuthorizationRequest</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Check that Charging Station does NOT send an AuthorizationRequest and authorization is refused.</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 88. Test Case Id: TC_C_32_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Store Authorization Data in the Authorization Cache - Persistent over reboot</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_32_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C10</td></tr><tr><td>Requirement(s)</td><td colspan="2">C10_FR_02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the Charging Station autonomously stores a record of previously presented identifiers that have been successfully authorized by the CSMS in the Authorization Cache. (Successfully meaning: a response received on a message containing an IdToken)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to store the identifiers persistent over reboot according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports the Authorization Cache feature
+- Authorization cache is stored in the non-volatile memory.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheEnabled is true (If implemented)
+LocalPreAuthorize is true</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields></td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Booted</td></tr><tr><td colspan="2">Manual Action: Present valid idToken which is already configured in the Authorization Cache</td></tr><tr><td>2. The Charging Station sends a TransactionRequest
+Note(s):
+- This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy. - As long as the cable is not plugged in the energy transfer will not start.</td><td>3. The OCTT responds with a TransactionResponse with idTokenInfo.status Accepted</td></tr><tr><td colspan="2">4. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message TransactionRequest
+- triggerReason Authorized
+-idToken.idToken <Configured valid_idtoken_idtoken>
+-idToken.type <Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 89. Test Case Id: TC_C_33_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Store Authorization Data in the Authorization Cache - Update on AuthorizationResponse</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_33_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C10</td></tr><tr><td>Requirement(s)</td><td colspan="2">C10_FR_04, C12.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the Charging Station autonomously stores a record of previously presented identifiers that have been successfully authorized by the CSMS in the Authorization Cache. (Successfully meaning: a response received on a message containing an IdToken)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to store the identifiers correctly upon an AutorizeResponse according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- AuthCacheCtrlr.AuthCacheAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheEnabled is true (If implemented)
+LocalPreAuthorize is true
+LocalAuthListEnabled is true</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="13">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Accepted</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest
+Note(s):
+- This step needs to be executed when TxStartPoint contains ParkingBayOccupancy, EVConnected, Authorized, or PowerPathClosed</td><td>4. The OCTT responds with a TransactionEventResponse with idTokenInfo.status Accepted</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr><tr><td colspan="2">6. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">7. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">8. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">9. Execute Reusable State ParkingBayOccupied</td></tr><tr><td colspan="2">10. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">Manual Action: Present same valid idToken</td></tr><tr><td>12. The Charging Station sends a TransactionEventRequest</td><td>13. The OCTT responds with a TransactionEventResponse with idTokenInfo.status Invalid</td></tr><tr><td>Note(s):
+- This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy.</td><td></td></tr><tr><td>Test case name</td><td>Store Authorization Data in the Authorization Cache - Update onauthorizeResponse</td></tr><tr><td>Tool validations</td><td>* Step 1:
+Message AuthorizationRequest
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+* Step 3:
+Message TransactionEventRequest
+- triggerReason Authorized
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+if transaction was already started
+- eventType Updated
+else
+- eventType Started
+* Step 12:
+Message TransactionEventRequest
+- triggerReason Authorized
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+if transaction was already started
+- eventType Updated
+else
+- eventType Started</td></tr><tr><td></td><td>Post scenario validations:
+- N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 90. Test Case Id: TC_C_34_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Store Authorization Data in the Authorization Cache - Update on TransactionResponse</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_34_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C10</td></tr><tr><td>Requirement(s)</td><td colspan="2">C10_FR_05, C12.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the Charging Station autonomously stores a record of previously presented identifiers that have been successfully authorized by the CSMS in the Authorization Cache. (Successfully meaning: a response received on a message containing an IdToken)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to store the identifiers correctly upon an TransactionResponse according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- AuthCacheCtrlr.AuthCacheAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheEnabled is true (If implemented)
+LocalPreAuthorize is true
+LocalAuthListEnabled is true</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields></td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="9">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken</td></tr><tr><td>1. The Charging Station sends a TransactionEventRequest</td><td>2. The OCTT responds with a TransactionEventResponse with idTokenInfo.status Invalid</td></tr><tr><td colspan="2">3. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">4. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">5. Execute Reusable State ParkingBayOccupied</td></tr><tr><td colspan="2">6. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">Manual Action: Present same valid idToken</td></tr><tr><td>7. The Charging Station sends an AuthorizationRequest</td><td>8. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Invalid</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message TransactionEventRequest
+- triggerReason Authorized
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type>
+if transaction was already started
+-eventType Updated
+else
+-eventType Started
+* Step 7:
+Message AuthorizationRequest
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+NOTE
+
+If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 91. Test Case Id: TC_C_36_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Store Authorization Data in the Authorization Cache - AuthCacheCtrl.LocalPreAuthorization = false</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_36_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C10</td></tr><tr><td>Requirement(s)</td><td colspan="2">C10_FR_11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the Charging Station autonomously stores a record of previously presented identifiers that have been successfully authorized by the CSMS in the Authorization Cache. (Successfully meaning: a response received on a message containing an IdToken)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to ignore the Authorization Cache feature when LocalPreAuthorization is set to false according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- AuthCacheCtrlAuthCacheAvailable is implemented
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheEnabled is true
+LocalPreAuthorization is false</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields></td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken which is configured in the Authorization Cache</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Invalid</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message AuthorizationRequest
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 92. Test Case Id: TC_C_37_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Authorization Data in Authorization Cache - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_37_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C11</td></tr><tr><td>Requirement(s)</td><td colspan="2">C11_FR_01, C11.FR.02, C11.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the Charging Station autonomously stores a record of previously presented identifiers that have been successfully authorized by the CSMS in the Authorization Cache. (Successfully meaning: a response received on a message containing an IdToken)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to clear all identifiers from the Authorization Cache according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- AuthCacheCtrl. AuthCacheAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields></td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="8">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ClearCacheResponse</td><td>1. The OCTT sends a ClearCacheRequest</td></tr><tr><td colspan="2">3. Execute Reusable State ParkingBayOccupied</td></tr><tr><td colspan="2">4. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">Manual Action: Present valid idToken which was configured in the Authorization Cache</td></tr><tr><td>5. The Charging Station sends an AuthorizationRequest</td><td>6. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Accepted</td></tr><tr><td>7. The Charging Station sends an TransactionEventRequest with triggerReason Authorized</td><td>8. The OCTT responds with an TransactionEventResponse with</td></tr><tr><td colspan="2">9. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message ClearCacheResponse
+- status Accepted
+* Step 5:
+Message AuthorizationRequest
+-idToken.idToken <Configured valid_idtoken_idtoken>
+-idToken.type <Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 93. Test Case Id: TC_C_38_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Authorization Data in Authorization Cache - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_38_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C11</td></tr><tr><td>Requirement(s)</td><td colspan="2">C11_FR_01, C11.FR.02, C11.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the Charging Station autonomously stores a record of previously presented identifiers that have been successfully authorized by the CSMS in the Authorization Cache. (Successfully meaning: a response received on a message containing an IdToken)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly respond on a request from the CSMS to clear all identifiers from the Authorization Cache while the feature is disabled according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- AuthCacheCtrlAuthCacheAvailable is implemented with value true
+- AuthCacheCtrl.LocalPreAuthorization is implemented
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheEnabled is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields></td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ClearCacheResponse</td><td>1. The OCTT sends a ClearCacheRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message ClearCacheResponse
+- status Rejected</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 94. Test Case Id: TC_C_39_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization by Groupld - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_39_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C09</td></tr><tr><td>Requirement(s)</td><td colspan="2">C09_FR_02, C09_FR_03, C09_FR_05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how a Charging Station can authorize an action for an EV Driver based on Groupld information. This could for example be used if 2 people regularly use the same EV: they can use their own IdToken (e.g. RFID card), and can deauthorize transactions that were started with the other idToken (with the same Groupld).</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly handle the Authorization of idTokens with the same Groupld according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EVConnectedPreSession</td></tr><tr><td rowspan="11">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken with<Configured Groupld></td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with-idTokenInfo.status Accepted-idTokenInfo.groupIdToken.idToken<Configured groupIdToken></td></tr><tr><td>3. The Charging Station sends aTransactionEventRequestNote(s):- This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy</td><td>4. The OCTT responds with aTransactionEventResponse with-idTokenInfo.status Accepted-idTokenInfo.groupIdToken.idToken<Configured groupIdToken></td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr><tr><td colspan="2">Manual Action: Present other valid idToken with<Configured Groupld></td></tr><tr><td>6. The Charging Station sends an AuthorizationRequest</td><td>7. The OCTT responds with an AuthorizationResponse with-idTokenInfo.status Accepted-idTokenInfo.groupIdToken.idToken<Configured groupIdToken></td></tr><tr><td>8. The Charging Station sends aTransactionEventRequest</td><td>9. The OCTT responds with aTransactionEventResponse with-idTokenInfo.status Accepted-idTokenInfo.groupIdToken.idToken<Configured groupIdToken></td></tr><tr><td colspan="2">10. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">11. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">12. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td>Test case name</td><td>Authorization by Groupld - Success</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message AuthorizationRequest
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+* Step 3:
+Message TransactionEventRequest
+- triggerReason Authorized
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+if transaction was already started
+- eventType Updated
+else
+- eventType Started
+* Step 6:
+Message AuthorizationRequest
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+* Step 8:
+Message TransactionEventRequest
+- triggerReason StopAuthorized
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 95. Test Case Id: TC_C_40_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization by Groupld - Success with Local Authorization List</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_40_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C09</td></tr><tr><td>Requirement(s)</td><td colspan="2">C09_FR_02, C09_FR_03, C09_FR_07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how a Charging Station can authorize an action for an EV Driver based on Groupld information. This could for example be used if 2 people regularly use the same EV: they can use their own IdToken (e.g. RFID card), and can deauthorize transactions that were started with the other idToken (with the same Groupld).</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly handle the Authorization of idTokens with the same Groupld when stored in the Local Authorization List according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrlr.LocalAuthListAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+Two known valid idTokens are configured in the Local Authorization List with the same Groupld</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="9">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken with <Configured Groupld> which is configured in the Local Authorization List</td></tr><tr><td>1. The Charging Station sends a TransactionEventRequest
+Note(s):
+- This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy</td><td>2. The OCTT responds with a TransactionEventResponse with
+-idTokenInfo.status Accepted
+-idTokenInfo.groupIdToken.idToken<Configured groupIdToken></td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr><tr><td colspan="2">Manual Action: Present valid idToken2 with <Configured Groupld> which is configured in the Authorization Cache</td></tr><tr><td colspan="2">4. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">5. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">6. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">7. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td>Test case name</td><td>Authorization by Groupld - Success with Local Authorization List</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message TransactionRequest
+- triggerReason Authorized
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+if transaction was already started
+- eventType Updated
+else
+- eventType Started
+* Step 4:
+Message TransactionRequest
+- triggerReason StopAuthorized
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+- eventType Updated</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 96. Test Case Id: TC_C_41_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization by Groupld - Success with Authorization Cache</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_41_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C09</td></tr><tr><td>Requirement(s)</td><td colspan="2">C09_FR_02, C09_FR_03, C09_FR_07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how a Charging Station can authorize an action for an EV Driver based on Groupld information. This could for example be used if 2 people regularly use the same EV: they can use their own IdToken (e.g. RFID card), and can deauthorize transactions that were started with the other idToken (with the same GroupId).</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly handle the Authorization of idTokens with the same GroupId when stored in the Authorization Cache according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- AuthCacheCtrlr.AuthCacheAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields>
+IdTokenCached for <Configured valid IdToken2 fields></td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="9">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken with <Configured GroupId> which is configured in the Authorization Cache</td></tr><tr><td>1. The Charging Station sends a TransactionEventRequest
+Note(s):
+- This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy</td><td>2. The OCTT responds with a TransactionEventResponse with
+TransactionInfo.status Accepted
+-idTokenInfo.groupIdToken.idToken <Configured groupIdToken></td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr><tr><td colspan="2">Manual Action: Present valid idToken2 with <Configured GroupId> which is configured in the Authorization Cache</td></tr><tr><td colspan="2">4. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">5. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">6. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">7. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td>Test case name</td><td>Authorization by Groupld - Success with Authorization Cache</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message TransactionRequest
+- triggerReason Authorized
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+if transaction was already started
+- eventType Updated
+else
+- eventType Started
+* Step 4:
+Message TransactionRequest
+- triggerReason StopAuthorized
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 97. Test Case Id: TC_C_42_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization by Groupld - Not stopped by Groupld</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_42_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C09</td></tr><tr><td>Requirement(s)</td><td colspan="2">C09_FR_11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how a Charging Station can authorize an action for an EV Driver based on Groupld information. This could for example be used if 2 people regularly use the same EV: they can use their own IdToken (e.g. RFID card), and can deauthorize transactions that were started with the other idToken (with the same Groupld).</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly handle the Authorization of idTokens with the same Groupld, while one of them is invalid, according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="8">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken with <Configured Groupld></td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with
+- idTokenInfo.status Accepted
+- idTokenInfo.groupIdToken.idToken <Configured
+groupIdToken></td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest
+Note(s):
+- This step needs to be executed when TxStartPoint
+contains Authorized OR the transaction already
+started. So in the case TxStartPoint contains
+ParkingBayOccupancy</td><td>4. The OCTT responds with a
+TransactionEventResponse with
+- idTokenInfo.status Accepted
+- idTokenInfo.groupIdToken.idToken <Configured
+groupIdToken></td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr><tr><td colspan="2">Manual Action: Present invalid idToken with <Configured Groupld></td></tr><tr><td>6. The Charging Station sends an AuthorizationRequest</td><td>7. The OCTT responds with an AuthorizationResponse
+with
+- idTokenInfo.status Invalid
+- idTokenInfo.groupIdToken.idToken <Configured
+groupIdToken></td></tr><tr><td colspan="2">Note(s): OCTT will wait to see if CS indeed doesn't send a TransactionEventRequest</td></tr><tr><td>Test case name</td><td>Authorization by Groupld - Not stopped by Groupld</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message AuthorizationRequest
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+* Step 3:
+Message TransactionEventRequest
+- triggerReason Authorized
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+if transaction was already started
+- eventType Updated
+else
+- eventType Started
+* Step 6:
+Message AuthorizationRequest
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type></td></tr><tr><td>Post scenario validations:
+- The energy transfer is not stopped</td></tr></table>
+
+Table 98. Test Case Id: TC_C_43_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization by GroupId - Invalid status with Local Authorization List</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_43_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C09</td></tr><tr><td>Requirement(s)</td><td colspan="2">C09_FR_02, C09_FR_03, C09_FR_07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how a Charging Station can authorize an action for an EV Driver based on GroupId information. This could for example be used if 2 people regularly use the same EV: they can use their own IdToken (e.g. RFID card), and can deauthorize transactions that were started with the other idToken (with the same GroupId).</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly handle the Authorization of idTokens with the same GroupId when stored in the Local Authorization List, but one of them is invalid, according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrl.LocalAuthListAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+Two known idTokens are configured in the Local Authorization List with the same GroupId, one is valid and one is invalid.</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="7">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken with <Configured GroupId> which is configured in the Local Authorization List</td></tr><tr><td>1. The Charging Station sends a TransactionEventRequest
+Note(s):
+- This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy</td><td>2. The OCTT responds with a TransactionEventResponse with
+-idTokenInfo.status Accepted
+-idTokenInfo.groupIdToken.idToken <Configured groupIdToken></td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr><tr><td colspan="2">Manual Action: Present invalid idToken with <Configured GroupId> which is configured in the Local Authorization List</td></tr><tr><td>4. The Charging Station sends an AuthorizationRequest</td><td>5. The OCTT responds with an AuthorizationResponse with
+-idTokenInfo.status Invalid
+-idTokenInfo.groupIdToken.idToken <Configured groupIdToken></td></tr><tr><td colspan="2">Note(s): OCTT will wait to see if CS indeed doesn't send a TransactionEventRequest</td></tr><tr><td>Test case name</td><td>Authorization by Groupld - Invalid status with Local Authorization List</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message TransactionRequest
+- triggerReason Authorized
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+if transaction was already started
+- eventType Updated
+else
+- eventType Started
+* Step 4:
+Message AuthorizationRequest
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+* Step 6:
+Message TransactionRequest
+- triggerReason StopAuthorized
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+- eventType Updated</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 99. Test Case Id: TC_C_44_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization by GroupId - Invalid status with Authorization Cache</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_44_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C09</td></tr><tr><td>Requirement(s)</td><td colspan="2">C09_FR_02, C09_FR_03, C09_FR_07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how a Charging Station can authorize an action for an EV Driver based on GroupId information. This could for example be used if 2 people regularly use the same EV: they can use their own IdToken (e.g. RFID card), and can deauthorize transactions that were started with the other idToken (with the same GroupId).</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly handle the Authorization of idTokens with the same GroupId when stored in the Authorization Cache, but one of them is invalid, according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- AuthCacheCtrlAuthCacheAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)
+AuthCacheCtrlDisablePostAuthorize is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields>
+IdTokenCached for <Configured invalid IdToken fields></td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="7">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken with <Configured GroupId> which is configured in the Authorization Cache</td></tr><tr><td>1. The Charging Station sends a TransactionEventRequest
+Note(s):
+- This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy</td><td>2. The OCTT responds with a TransactionEventResponse with
+-idTokenInfo.status Accepted
+-idTokenInfo.groupIdToken.idToken <Configured groupIdToken></td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr><tr><td colspan="2">Manual Action: Present invalid idToken with <Configured GroupId> which is configured in the Authorization Cache</td></tr><tr><td>4. The Charging Station sends an AuthorizationRequest</td><td>5. The OCTT responds with an AuthorizationResponse with
+-idTokenInfo.status Invalid
+-idTokenInfo.groupIdToken.idToken <Configured groupIdToken></td></tr><tr><td colspan="2">Note(s): OCTT will wait to see if CS indeed doesn't send a TransactionEventRequest</td></tr><tr><td>Test case name</td><td>Authorization by Groupld - Invalid status with Authorization Cache</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message TransactionRequest
+- triggerReason Authorized
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+if transaction was already started
+- eventType Updated
+else
+- eventType Started
+* Step 4:
+MessageauthorizeRequest
+- idToken.idToken <Configured invalid_idtoken_idtoken>
+- idToken.type <Configured invalid_idtoken_type></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 100. Test Case Id: TC_C_45_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization by Groupld - Master pass - Not able to start transaction + groupld</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_45_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C09</td></tr><tr><td>Requirement(s)</td><td colspan="2">C16.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how a Charging Station can authorize an action for an EV Driver based on Groupld information. This could for example be used if 2 people regularly use the same EV: they can use their own IdToken (e.g. RFID card), and can deauthorize transactions that were started with the other idToken (with the same Groupld).</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly handle the Authorization of an idToken with the same Groupld as the MasterPassGroupld according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging station supports MasterPass feature.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+TxCtrlr.TxStartPoint should contain Authorized or PowerPathClosed and not contain ParkingBayOccupancy or EVConnected
+AuthCtrlrMASTERPassGroupld is <Configured MasterPassGroupld></td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present configured masterpass idToken</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with
+- idTokenInfo.status Accepted
+- idTokenInfo.groupIdToken.idToken <Configured masterPassGroupld></td></tr><tr><td colspan="2">Note: The Charging Station will not authorize the transaction and send a TransactionEventRequest (in case of TxStartPoint Authorized).</td></tr><tr><td colspan="2">3. Execute Reusable State EVConnectedPreSession</td></tr><tr><td>4. The Charging Station will NOT send a TransactionEventRequest with chargingState Charging and triggerReason ChargingStateChanged</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message AuthorizationRequest
+-idToken.idToken <Configured valid_idtoken_idtoken>
+-idToken.type <Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+Table 101. Test Case Id: TC_C_46_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Store Authorization Data in the Authorization Cache - AuthCacheLifeTime</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_46_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C10</td></tr><tr><td>Requirement(s)</td><td colspan="2">C10_FR_08</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the Charging Station autonomously stores a record of previously presented identifiers that have been successfully authorized by the CSMS in the Authorization Cache. (Successfully meaning: a response received on a message containing an IdToken)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly remove an idToken when this one is not reused again within the specified amount of time (AuthCacheLifeTime) according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- AuthCacheCtrl.AuthCacheAvailable is implemented with value true
+- Configuration variable AuthCacheLifeTime is implemented
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCacheLifeTime is <Configured TransactionDuration>
+AuthCacheCtrl.LocalPreAuthorize is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached <Configured valid idtoken fields></td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Wait for <Configured Transaction Duration> seconds</td></tr><tr><td colspan="2">2. Execute Reusable State Authorized (local)</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 102. Test Case Id: TC_C_47_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop Transaction with a Master Pass - With UI - All transactions</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_47_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C16</td></tr><tr><td>Requirement(s)</td><td colspan="2">C16_FR_01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how somebody with a Master Pass (User) can stop (selected) ongoing transactions, so the cable becomes unlocked. This Master Pass can be configured in: MasterPassGroupld. This could for example be useful for Law Enforcement officials.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly stop all transactions when an idToken which has the MasterPass as Groupld is used and the user has selected to stop all transactions in the User Interface according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports at least one authorization method described at the following Use cases; C01, C04.
+- Charging station has a User Interface
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.MastersPassGroupld is configured</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted for all EVSE</td></tr><tr><td rowspan="8">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present configured masterpass idToken</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Accepted
+idTokenInfo.groupIdToken.idToken <Configured masterPassGroupld></td></tr><tr><td colspan="2">Manual Action: Select to stop all transactions</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest for all EVSE</td><td>4. The OCTT responds with a TransactionEventResponse with idTokenInfo.status Accepted
+idTokenInfo.groupIdToken.idToken <Configured masterPassGroupld>
+for all EVSE</td></tr><tr><td colspan="2">5. Execute Reusable State EVConnectedPostSession for all EVSE</td></tr><tr><td colspan="2">6. Execute Reusable State EVDisconnected for all EVSE</td></tr><tr><td colspan="2">7. Execute Reusable State ParkingBayUnoccupied for all EVSE</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message AuthorizationRequest
+-idToken.idToken <Configured masterpass_idtoken_idtoken>
+-idToken.type <Configured masterpass_idtoken_type>
+* Step 3:
+Message TransactionEventRequest
+- transactionInfo.stoppedReason MasterPass
+-idToken.omit or
+-idToken.idToken <Configured masterpass_idtoken_idtoken> and
+-idToken.type <Configured masterpass_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+Table 103. Test Case Id: TC_C_48_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop Transaction with a Master Pass - With UI - With UI - Specific transactions</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_48_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C16</td></tr><tr><td>Requirement(s)</td><td colspan="2">C16_FR_01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how somebody with a Master Pass (User) can stop (selected) ongoing transactions, so the cable becomes unlocked. This Master Pass can be configured in: MasterPassGroupId. This could for example be useful for Law Enforcement officials.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly stop a transaction when an idToken which has the MasterPass as GroupId is used and the user has selected to stop one transaction in the User Interface according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports at least one authorization method described at the following Use cases; C01, C04.
+- Charging station has a User Interface
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.MastersPassGroupId is configured</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted for all EVSE</td></tr><tr><td rowspan="8">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present configured masterpass idToken</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Accepted
+idTokenInfo.groupIdToken.idToken<Configured
+masterPassGroupId></td></tr><tr><td colspan="2">Manual Action: Select to stop the transaction on EVSE 1</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse with idTokenInfo.status Accepted
+idTokenInfo.groupIdToken.idToken<Configured
+masterPassGroupId></td></tr><tr><td colspan="2">5. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">6. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">7. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message AuthorizationRequest
+-idToken.idToken<Configured masterpass_idtoken_idtoken>
+-idToken.type<Configured masterpass_idtoken_type>
+* Step 3:
+Message TransactionEventRequest
+- transactionInfo.stoppedReason MasterPass
+-idToken.omit or
+-idToken.idToken<Configured masterpass_idtoken_idtoken> and
+-idToken.type<Configured masterpass_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+- All other EVSE still transfer energy</td></tr></table>
+
+Table 104. Test Case Id: TC_C_49_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop Transaction with a Master Pass - Without UI</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_49_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C16</td></tr><tr><td>Requirement(s)</td><td colspan="2">C16_FR_02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how somebody with a Master Pass (User) can stop (selected) ongoing transactions, so the cable becomes unlocked. This Master Pass can be configured in: MasterPassGroupId. This could for example be useful for Law Enforcement officials.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly stop all transactions when an idToken which has the MasterPass as GroupId is used and the Charging station does not have an User Interface according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports at least one authorization method described at the following Use cases; C01, C04. - The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.MastersPassGroupId is configured</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted for EVSEId 1 and EVSEId 2 if the Charging Station has more than one EVSE. With: - <Configured valid_idtoken> for EVSE 1 - <Configured valid_idtoken2> for EVSE 2</td></tr><tr><td rowspan="7">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present configured masterpass idToken</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Accepted
+idTokenInfo.groupIdToken.idToken <Configured masterPassGroupId></td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest for EVSE 1 (and 2)</td><td>4. The OCTT responds with a TransactionEventResponse with idTokenInfo.status Accepted
+idTokenInfo.groupIdToken.idToken <Configured masterPassGroupId> for EVSE 1 (and 2)</td></tr><tr><td colspan="2">5. Execute Reusable State EVConnectedPostSession for EVSE 1 (and 2)</td></tr><tr><td colspan="2">6. Execute Reusable State EVDisconnected for EVSE 1 (and 2)</td></tr><tr><td colspan="2">7. Execute Reusable State ParkingBayUnoccupied for EVSE 1 (and 2)</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message AuthorizationRequest
+-idToken.idToken <Configured masterpass_idtoken_idtoken>
+-idToken.type <Configured masterpass_idtoken_type>
+* Step 3:
+Message TransactionEventRequest
+- transactionInfo.stoppedReason MasterPass
+-idToken.omit or
+-idToken.idToken <Configured masterpass_idtoken_idtoken> and
+-idToken.type <Configured masterpass_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+Table 105. Test Case Id: TC_C_21_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Offline authorization through local authorization list - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_21_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C13</td></tr><tr><td>Requirement(s)</td><td colspan="2">C13.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. When offline the Charging Station can then locally authorize the IdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to authorize an idToken which has status "Accepted" in its local authorization list according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrl.LocalAuthListAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)
+OfflineTxForUnknownIdEnabled is false (If implemented)
+LocalAuthorizationOffline is true</td></tr><tr><td colspan="2">Memory State:
+IdTokenLocalAuthList for <Configured valid idtoken fields></td></tr><tr><td colspan="2">Reusable State(s):
+State is StartOfflineTransaction</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present idToken.</td></tr><tr><td colspan="2">Manual Action: Unplug cable.</td></tr><tr><td colspan="2">Manual Action: Drive out of parkingbay.</td></tr><tr><td>1. The Charging Stations sends a TransactionRequest
+Note(s):
+- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionRequest messages</td><td>2. The OCTT responds with a TransactionResponse
+Note(s):
+- The OCTT will respond to the TransactionRequest containing the idToken, with idtokenInfo.status Accepted</td></tr><tr><td colspan="2">3. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message(s) before the StopAuthorize: TransactionEventRequests
+- offline must be true
+One of the Message(s): TransactionRequest
+- TriggerReason must be StopAuthorized</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 106. Test Case Id: TC_C_22_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Offline authorization through local authorization list - Invalid</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_22_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C13</td></tr><tr><td>Requirement(s)</td><td colspan="2">C13.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. When offline the Charging Station can then locally authorize the IdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly to an idToken which has status "Invalid" in its local authorization list according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrl.LocalAuthListAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)
+OfflineTxForUnknownIdEnabled is false (If implemented)
+LocalAuthorizationOffline is true
+OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + 60.0
+RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration>
+RetryBackOffRandomRange is 0</td></tr><tr><td colspan="2">Memory State:
+IdTokenLocalAuthList for <Configured invalid idtoken fields></td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">2. Manual Action: Drive EV into parking bay.</td></tr><tr><td colspan="2">3. Manual Action: Present idToken.</td></tr><tr><td colspan="2">4. The OCTT accepts reconnection attempt from the Charging Station.</td></tr><tr><td>5. The Charging Stations sends a TransactionEventRequest
+Note(s):
+- The Charging Station will empty its Transaction message queue, this will only contain TransactionEventRequests if TxStartPoint was ParkingBayOccupancy and a Transaction was started.</td><td>6. The OCTT responds with a TransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 5:
+Message TransactionRequest
+- offline must be true
+- TriggerReason must be EVDetected</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 107. Test Case Id: TC_C_23_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Offline authorization through local authorization list - Restricted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_23_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C13</td></tr><tr><td>Requirement(s)</td><td colspan="2">C13.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. When offline the Charging Station can then locally authorize the IdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly to an idToken which has status "Blocked" in its local authorization list according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrl.LocalAuthListAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)
+OfflineTxForUnknownIdEnabled is false (If implemented)
+LocalAuthorizationOffline is true
+OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + 60.0
+RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration>
+RetryBackOffRandomRange is 0</td></tr><tr><td colspan="2">Memory State:
+IdTokenLocalAuthList for <Configured blocked idtoken fields></td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">2. Manual Action: Drive EV into parking bay.</td></tr><tr><td colspan="2">3. Manual Action: Present idToken.</td></tr><tr><td colspan="2">4. The OCTT accepts reconnection attempt from the Charging Station.</td></tr><tr><td>5. The Charging Stations sends a TransactionEventRequest
+Note(s):
+- The Charging Station will empty its Transaction message queue, this will only contain TransactionEventRequests if TxStartPoint was ParkingBayOccupancy and a Transaction was started.</td><td>6. The OCTT responds with a TransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 5:
+Message TransactionRequest
+- offline must be true
+- TriggerReason must be EVDetected</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 108. Test Case Id: TC_C_24_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Offline authorization through local authorization list - Expired</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_24_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C13</td></tr><tr><td>Requirement(s)</td><td colspan="2">C13.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. When offline the Charging Station can then locally authorize the IdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly to an idToken which has status "Expired" in its local authorization list according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrl.LocalAuthListAvailable is implemented with value true
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)
+OfflineTxForUnknownIdEnabled is false (If implemented)
+LocalAuthorizationOffline is true
+OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + 60.0
+RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration>
+RetryBackOffRandomRange is 0</td></tr><tr><td colspan="2">Memory State:
+IdTokenLocalAuthList for <Configured expired idtoken fields></td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">2. Manual Action: Drive EV into parking bay.</td></tr><tr><td colspan="2">3. Manual Action: Present idToken.</td></tr><tr><td colspan="2">4. The OCTT accepts reconnection attempt from the Charging Station.</td></tr><tr><td>5. The Charging Stations sends a TransactionEventRequest
+Note(s):
+- The Charging Station will empty its Transaction message queue, this will only contain TransactionEventRequests if TxStartPoint was ParkingBayOccupancy and a Transaction was started.</td><td>6. The OCTT responds with a TransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 5:
+Message TransactionRequest
+- offline must be true
+- TriggerReason must be EVDetected</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 109. Test Case Id: TC_C_25_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Offline authorization through local authorization list - Local Authorization List > Authorization Cache</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_25_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C13, C14</td></tr><tr><td>Requirement(s)</td><td colspan="2">C13.FR.01, C14.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. When offline the Charging Station can then locally authorize the IdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station does not start a transaction while being offline for an idToken that is stored in the cache, but also in the local authorization list as with status invalid.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- LocalAuthListCtrlr.LocalAuthListAvailable is implemented with value true
+- AuthCacheCtrlr.AuthCacheAvailable is implemented with value true
+- OfflineTxForUnknownIdEnabled is implemented.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)
+OfflineTxForUnknownIdEnabled is true
+LocalAuthorizationOffline is true
+StopTxOnInvalidId is false
+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></td></tr><tr><td colspan="2">Memory State:
+IdTokenCached <Configured valid idtoken fields>
+IdTokenLocalAuthList for <Configured valid idtoken fields, but set as invalid></td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Present idToken.</td></tr><tr><td colspan="2">Note(s): The tool will wait for <Configured Transaction Duration> seconds.</td></tr><tr><td colspan="2">2. The OCTT accepts reconnection attempt from the Charging Station.</td></tr><tr><td colspan="2">3. The Charging Station does NOT start a transaction. MeterValues are allowed.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 110. Test Case Id: TC_C_26_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Offline Authorization - Unknown Id</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_26_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C15 & C13</td></tr><tr><td>Requirement(s)</td><td colspan="2">C15.FR.02,C15.FR.06,C15.FR.08,C13.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is allowed to allow starting a transaction for unknown idTokens when offline and configured to do so.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to start a transaction while being offline for an unknown idToken, when it is configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- OfflineTxForUnknownldEnabled is implemented.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListEnabled is true (If implemented)
+LocalPreAuthorize is true (If implemented)
+OfflineTxForUnknownldEnabled is true
+LocalAuthorizationOffline is true
+MaxEnergyOnInvalidId is 0 (If implemented)
+StopTxOnInvalidId is false</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is StartOfflineTransaction</td></tr><tr><td rowspan="5">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Stations sends a TransactionEventRequest
+Note(s):
+- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionEventRequest messages</td><td>2. The OCTT responds with a TransactionResponse
+Note(s):
+- The OCTT will respond to the TransactionRequest containing the idToken, with idtokenInfo.status Invalid</td></tr><tr><td colspan="2">Manual Action: Present valid idToken.</td></tr><tr><td colspan="2">Manual Action: Unplug cable</td></tr><tr><td>3. The Charging Stations sends a TransactionEventRequest with triggerReason StopAuthorized</td><td>4. The OCTT responds with a TransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+All Message(s): TransactionEventRequest
+- offline must be true
+* Step 1:
+One of the Message(s): TransactionEventRequest
+- chargingState must be SuspendedEVSE</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 111. Test Case Id: TC_C_50_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization using Contract Certificates 15118 - Online - Local contract certificate validation - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_50_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C07</td></tr><tr><td>Requirement(s)</td><td colspan="2">C07.FR.01,C07.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is able to authorize with contract certificates when it supports ISO 15118.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to authorize while locally validating the contract certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="102">Before(Preparations)</td><td rowspan="102" colspan="2">Configuration State:AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)AuthCtrl_DISABLERemoteAuthorization is false (If implemented)For the ISO15118Ctrl of the EVSE used in the PnP transaction:ISO15118Ctrl.CentralContractValidationAllowed is falseISO15118CtrlContractCertificatesInstallationEnabled is trueISO15118Ctrl.V2GCertificateInstallationEnabled is trueISO15118Ctrl.PnCEnabled is trueISO15118Ctrl.Seecd is configured seecdISO15118Ctrl.CountryName is NLISO15118Ctrl.OrganizationName is configured vendorid</td></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr><td></td></tr></table>
+
+Table 112. Test Case Id: TC_C_51_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization using Contract Certificates 15118 - Online - Local contract certificate validation - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_51_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C07</td></tr><tr><td>Requirement(s)</td><td colspan="2">C07.FR.01,C07.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is able to authorize with contract certificates when it supports ISO 15118.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to handle a rejected on an AuthorizationRequest, when authorizing using a contract certificate with an invalid EMAID.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)AuthCtrl.DisableRemoteAuthorization is false (If implemented)For the ISO15118Ctrl of the EVSE used in the PnC transaction:ISO15118Ctrl.CentralContractValidationAllowed is falseISO15118Ctrl.PnCEnabled is true</td></tr><tr><td colspan="2">Memory State:CertificatesInstalled for certificateType V2GRootCertificateCertificatesInstalled for certificateType MORootCertificate</td></tr><tr><td colspan="2">Reusable State(s):State is EVConnectedPreSession</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequestNote(s):-The test case should be robust enough to also handle a GetCertificateStatusRequest</td><td>2. The OCTT responds with a AuthorizationResponse with idTokenInfo.status Invalid and certificateStatus = ContractCancelled</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: AuthorizationRequest-idToken.type must be eMAID- iso15118CertificateHashData is provided</td></tr><tr><td colspan="2">Post scenario validations:EV is not authorized and shall not charge:Charging Station does not send TransactionEventRequest with:- triggerReason = Authorized or chargingState = Charging</td></tr></table>
+
+Table 113. Test Case Id: TC_C_52_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization using Contract Certificates 15118 - Online - Central contract certificate validation - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_52_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C07</td></tr><tr><td>Requirement(s)</td><td colspan="2">C07.FR.01,C07.FR.02,C07.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is able to authorize with contract certificates when it supports ISO 15118.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to authorize, while not being able to locally validate the contract certificate and then send it to the CSMS.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The V2G/MO Root certificate that is needed to validate the EV Contract certificate must NOT be installed at the Charging Station.
+- The Charging Station supports central contract validation.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl.DisableRemoteAuthorization is false (If implemented)
+For the ISO15118Ctrl of the EVSE used for the PnC transaction:
+ISO15118Ctrl.CentralContractValidationAllowed is true
+ISO15118CtrlContractCertificatesInstallationEnabled is true
+ISO15118Ctrl.V2GCertificateInstallationEnabled is true
+ISO15118Ctrl.PnCEnabled is true
+ISO15118Ctrl.Secld is configured seccld
+ISO15118Ctrl.CountryName is NL
+ISO15118Ctrl.OrganizationName is configured vendorId</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest Note(s):
+- The test case should be robust enough to also handle a GetCertificateStatusRequest</td><td>2. The OCTT responds with a AuthorizationResponse with idTokenInfo.status Accepted and certificateStatus = Accepted</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest
+Note(s):
+- This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy or (EVConnected, in the case this testcase was initiated from state EVConnectedPreSession.)</td><td>4. The OCTT responds with a TransactionEventResponse With idTokenInfo.status Accepted</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: AuthorizationRequest
+- idToken.type must be eMAID
+- iso15118CertificateHashData may be provided
+- certificate is provided
+* Step 3:
+Message: TransactionEventRequest
+- triggerReason must be Authorized</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 114. Test Case Id: TC_C_53_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization using Contract Certificates 15118 - Online - Central contract validation fails</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_53_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is able to authorize with contract certificates when it supports ISO 15118.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to handle an invalid contract certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The V2G/MO Root certificate that is needed to validate the EV Contract certificate must NOT be installed at the Charging Station.
+- The Charging Station supports central contract validation.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl.DisableRemoteAuthorization is false (If implemented)
+For the ISO15118Ctrl of the EVSE involved in the PnC transaction:
+ISO15118Ctrl.CentralContractValidationAllowed is true
+ISO15118Ctrl.PnCEnabled is true</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest.
+Note(s):
+-The test case should be robust enough to also handle a GetCertificateStatusRequest</td><td>2. The OCTT responds with a AuthorizationResponse with idTokenInfo.status Invalid and certificateStatus = CertificateRevoked</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: AuthorizationRequest
+-idToken.type must be eMAID
+-iso15118CertificateHashData may be provided
+-certificate is provided</td></tr><tr><td colspan="2">Post scenario validations:
+EV is not authorized and shall not charge:
+Charging Station does not send TransactionEventRequest with:
+- triggerReason = Authorized or chargingState = Charging</td></tr></table>
+
+Table 115. Test Case Id: TC_C_54_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization using Contract Certificates 15118 - Offline - ContractValidationOffline is true</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_54_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C07</td></tr><tr><td>Requirement(s)</td><td colspan="2">C07.FR.08,C07.FR.09,C07.FR.10,C07.FR.11,C07.FR.12</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is able to authorize with contract certificates when it supports ISO 15118.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to authorize using contract certificates, while it is offline.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)OfflineTxForUnknownIdEnabled is true (If implemented)OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + 60.0RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration>RetryBackOffRandomRange is 0Note:<Configured RetryBackOffWaitMinimum_duration should be long enough to execute manual tasks>For ISO15118Ctrl of EVSE involved in PnC transaction:ISO15118Ctrl.RContractValidationOffline is trueISO15118Ctrl.PnCEnabled is true</td></tr><tr><td colspan="2">Memory State:CertificatesInstalled for certificateType V2GRootCertificateCertificatesInstalled for certificateType MORootCertificateIdTokenCached for <Configured valid IdToken fields> (If implemented)IdTokenLocalAuthList for <Configured valid IdToken fields> (If implemented)</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="10">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Drive EV into parking bay.</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td colspan="2">Notes(s): The tool will wait for <Configured Transaction Duration> seconds.</td></tr><tr><td colspan="2">2. The OCTT accepts the reconnection attempt from the Charging Station after <Configured TransactionDuration> seconds.</td></tr><tr><td>3. The Charging Station notifies the CSMS about the status change of the connector.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td>5. The Charging Station sends aTransactionEventRequestNote(s):- This step needs to be executed when TxStartPoint contains EVConnected OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy</td><td>6. The OCTT responds with aTransactionEventResponse</td></tr><tr><td>7. The Charging Station sends aTransactionEventRequestNote(s):- This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy or EVConnected.</td><td>8. The OCTT responds with aTransactionEventResponseWith idTokenInfo.status Accepted</td></tr><tr><td colspan="2">9. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>Test case name</td><td>Authorization using Contract Certificates 15118 - Offline - ContractValidationOffline is true</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 3:
+Message: StatusNotificationRequest
+- connectorStatus must be Occupied
+Message: NotifyEventRequest
+- eventData[0].trigger must be Delta
+- eventData[0].actualValue must be Occupied
+- eventData[0].component.name must be Connector
+- eventData[0].variable.name must be AvailabilityState
+* Step 5:
+Message: TransactionEventRequest
+- triggerReason must be CablePluggedIn
+- transactionInfo.chargingState must be EVConnected
+- offline true
+* Step 7:
+Message: TransactionEventRequest
+- triggerReason must be Authorized
+- offline true</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 116. Test Case Id: TC_C_55_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization using Contract Certificates 15118 - Offline - ContractValidationOffline is false</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_55_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C07</td></tr><tr><td>Requirement(s)</td><td colspan="2">C07.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is able to authorize with contract certificates when it supports ISO 15118.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to handle being offline and not allowing a charging session to start, when it is configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+OfflineTxForUnknownIdEnabled is true (If implemented)
+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>
+For the ISO15118Ctrl of the EVSE involved in the PnC transaction:
+ISO15118CtrlContractValidationOffline is false
+ISO15118Ctrl.PnCEnabled is true</td></tr><tr><td colspan="2">Memory State:
+CertificatesInstalled for certificateType V2GRootCertificate
+CertificatesInstalled for certificateType MORootCertificate
+IdTokenCached for <Configured valid IdToken fields> (If implemented)
+IdTokenLocalAuthList for <Configured valid IdToken fields> (If implemented)</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="9">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Drive EV into parking bay.</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td colspan="2">Note(s): The tool will wait for <Configured Transaction Duration> seconds.</td></tr><tr><td colspan="2">2. The OCTT accepts the reconnection attempt from the Charging Station after <Configured Transaction Duration> seconds.</td></tr><tr><td>3. The Charging Station notifies the CSMS about the status change of the connector.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td>5. The Charging Station sends a TransactionEventRequest
+Note(s):
+- This step needs to be executed when TxStartPoint contains EVConnected OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy</td><td>6. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>7. The Charging Station has NOT started charging and does NOT send TransactionRequest message(s) with triggerReason Authorized OR ChargingStateChanged.</td><td></td></tr><tr><td>Test case name</td><td>Authorization using Contract Certificates 15118 - Offline - ContractValidationOffline is false</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 3:
+Message: StatusNotificationRequest
+- connectorStatus must be Occupied
+Message: NotifyEventRequest
+- eventData[0].trigger must be Delta
+- eventData[0].actualValue must be Occupied
+- eventData[0].component.name must be Connector
+- eventData[0].variable.name must be AvailabilityState
+* Step 5:
+Message: TransactionEventRequest
+- triggerReason must be CablePluggedIn
+- transactionInfo.chargingState must be EVConnected
+- offline true</td></tr><tr><td>Post scenario validations:
+EV is not authorized and shall not charge:
+Charging Station does not send TransactionEventRequest with:
+- triggerReason = Authorized or chargingState = Charging</td></tr></table>
+
+Table 117. Test Case Id: TC_C_56_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - Authorization Unknown</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_56_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C01</td></tr><tr><td>Requirement(s)</td><td colspan="2">C01.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">When a Charging Station needs to charge an EV, it needs to authorize the EV Driver first at the CSMS before the charging can be started or stopped.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to handle receiving an Unknown idToken.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station does NOT have a cable lock, which prevents the EV driver to connect the EV and EVSE before authorization.
+The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present invalid idToken.</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Unknown</td></tr><tr><td colspan="2">Note(s):
+- The Charging Station SHALL NOT send a TransactionEventRequest message after the AuthorizationRequest from step 1.
+- The OCTT waits <Configured message timeout> seconds, before ending the testcase.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: AuthorizationRequest
+-idToken.idToken<Configured invalid_idtoken_idtoken>
+-idToken.type<Configured invalid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+# 2.5. D Local Authorization List Management
+
+Table 118. Test Case Id: TC_D_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Send Local Authorization List - Full</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D01</td></tr><tr><td>Requirement(s)</td><td colspan="2">D01_FR_02, D01_FR_15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a Local Authorization List which a Charging Station can use for the authorization of idTokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to replace the Local Authorization List according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports the Local Authorization List feature</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: LocalAuthListEnabled is true (If implemented) *Configured versionNumber > 0</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SendLocalListResponse</td><td>1. The OCTT sends a SendLocalListRequest with - updateType Full - versionNumber <Configured versionNumber> - localAuthorizationList[0].idToken.idToken <Configured valid_idtoken_idtoken> - localAuthorizationList[0].idToken.type <Configured valid_idtoken_type></td></tr><tr><td>4. The Charging Station responds with a GetLocalListVersionResponse</td><td>3. The OCTT sends a GetLocalListVersionRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message SendLocalListResponse - status Accepted * Step 4: Message GetLocalListVersionResponse - versionNumber <Equal to version sent in step 1></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 119. Test Case Id: TC_D_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Send Local Authorization List - Differential Update</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D01</td></tr><tr><td>Requirement(s)</td><td colspan="2">D01_FR_02, D01_FR_16</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a Local Authorization List which a Charging Station can use for the authorization of idTokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to replace the Local Authorization List in differential type according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports the Local Authorization List feature</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:LocalAuthListEnabled is true (If implemented) *Configured versionNumber > 0</td></tr><tr><td colspan="2">Memory State:IdTokenLocalAuthList for <Configured valid idtoken fields></td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SendLocalListResponse</td><td>1. The OCTT sends a SendLocalListRequest with - upgradeType Differential - versionNumber <Configured versionNumber + 1> - localAuthorizationList[0].idToken.idToken <Configured valid_idtoken_idtoken2> - localAuthorizationList[0].idToken.type <Configured valid_idtoken_type2></td></tr><tr><td colspan="2">Note(s): The message send by OCTT is within ItemsPerMessageSendLocalList AND BytesPerMessageSendLocalList range.</td></tr><tr><td>4. The Charging Station responds with a GetLocalListVersionResponse</td><td>3. The OCTT sends a GetLocalListVersionRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SendLocalListResponse- status Accepted* Step 4:Message GetLocalListVersionResponse-versionNumber <Equal to version send in step 1></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 120. Test Case Id: TC_D_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Send Local Authorization List - Differential Remove</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D01</td></tr><tr><td>Requirement(s)</td><td colspan="2">D01_FR_02, D01_FR_17</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a Local Authorization List which a Charging Station can use for the authorization of idTokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to remove items from the Local Authorization List when send in differential type with data without idToken according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports the Local Authorization List feature</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:LocalAuthListEnabled is true (If implemented) *Configured versionNumber > 0</td></tr><tr><td colspan="2">Memory State:IdTokenLocalAuthList for <Configured valid idtoken fields></td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SendLocalListResponse</td><td>1. The OCTT sends a SendLocalListRequest with - upgradeType Differential - versionNumber <Configured versionNumber + 1> - localAuthorizationList <Contains AuthorizationData elements without idTokenInfo></td></tr><tr><td colspan="2">Note(s): The message send by OCTT is within ItemsPerMessageSendLocalList AND BytesPerMessageSendLocalList range.</td></tr><tr><td>4. The Charging Station responds with a GetLocalListVersionResponse</td><td>3. The OCTT sends a GetLocalListVersionRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SendLocalListResponse- status Accepted* Step 3:Message GetLocalListVersionResponse-versionNumber <Equal to version sent in step 1></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 121. Test Case Id: TC_D_04_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Send Local Authorization List - Full with empy list</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D01</td></tr><tr><td>Requirement(s)</td><td colspan="2">D01_FR_02, D01_FR_04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a Local Authorization List which a Charging Station can use for the authorization of idTokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to remove all items from the Local Authorization List when send in full type with no data according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports the Local Authorization List feature</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: LocalAuthListEnabled is true (If implemented) *Configured versionNumber > 0</td></tr><tr><td colspan="2">Memory State: IdTokenLocalAuthList for <Configured valid idtoken fields></td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SendLocalListResponse</td><td>1. The OCTT sends a SendLocalListRequest with - upgradeType Full - versionNumber <Configured versionNumber> - localAuthorizationList <Empty></td></tr><tr><td>4. The Charging Station responds with a GetLocalListVersionResponse</td><td>3. The OCTT sends a GetLocalListVersionRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message SendLocalListResponse - status Accepted * Step 4: Message GetLocalListVersionResponse - versionNumber <Configured versionNumber></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 122. Test Case Id: TC_D_05_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Send Local Authorization List - Differential with empty list</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_05_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D01</td></tr><tr><td>Requirement(s)</td><td colspan="2">D01_FR_02, D01_FR_05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a Local Authorization List which a Charging Station can use for the authorization of idTokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly respond on a Local Authorization List when send in differential type with no data according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports the Local Authorization List feature</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: LocalAuthListEnabled is true (If implemented) *Configured versionNumber > 0</td></tr><tr><td colspan="2">Memory State: IdTokenLocalAuthList for <Configured valid idtoken fields></td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SendLocalListResponse</td><td>1. The OCTT sends a SendLocalListRequest with - upgradeType Differential - versionNumber <Configured versionNumber + 1> - localAuthorizationList <Empty></td></tr><tr><td>4. The Charging Station responds with a GetLocalListVersionResponse</td><td>3. The OCTT sends a GetLocalListVersionRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message SendLocalListResponse - status Accepted * Step 4: Message GetLocalListVersionResponse - versionNumber <Equal to the version send in step 1></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 123. Test Case Id: TC_D_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Send Local Authorization List - VersionMismatch</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_06_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D01</td></tr><tr><td>Requirement(s)</td><td colspan="2">D01_FR_19</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a Local Authorization List which a Charging Station can use for the authorization of idTokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly respond on a Local Authorization List when send in differential type with with a faulty version number according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports the Local Authorization List feature</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: LocalAuthListEnabled is true (If implemented) *Configured versionNumber > 1</td></tr><tr><td colspan="2">Memory State: IdTokenLocalAuthList for <Configured valid idtoken fields></td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SendLocalListResponse</td><td>1. The OCTT sends a SendLocalListRequest with - upgradeType Differential - versionNumber <Configured versionNumber - 1> - localAuthorizationList <Not Empty></td></tr><tr><td>4. The Charging Station responds with a GetLocalListVersionResponse</td><td>3. The OCTT sends a GetLocalListVersionRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message SendLocalListResponse - status VersionMismatch * Step 4: Message GetLocalListVersionResponse - versionNumber <Configured versionNumber></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 124. Test Case Id: TC_D_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Send Local Authorization List - Persistent over reboot</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D01</td></tr><tr><td>Requirement(s)</td><td colspan="2">D01_FR_10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a Local Authorization List which a Charging Station can use for the authorization of Tokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to save the Local Authorization List persistent over reboot according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports the Local Authorization List feature and stores it in non-volatile memory</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: LocalAuthListEnabled is true (If implemented) *Configured versionNumber > 0</td></tr><tr><td colspan="2">Memory State: IdTokenLocalAuthList for <Configured valid idtoken fields></td></tr><tr><td colspan="2">Charging State: Booted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetLocalListVersionResponse</td><td>1. The OCTT sends a GetLocalListVersionRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message GetLocalListVersionResponse - versionNumber <Configured versionNumber></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 125. Test Case Id: TC_D_08_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Local List Version - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_08_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D02</td></tr><tr><td>Requirement(s)</td><td colspan="2">D02_FR_01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station for the version number of the Local Authorization List by sending a GetLocalListVersionRequest.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond the Local Authorization List version number according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports the Local Authorization List feature</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: LocalAuthListEnabled is true (If implemented) *Configured versionNumber > 0</td></tr><tr><td colspan="2">Memory State: IdTokenLocalAuthList for <Configured valid idtoken fields></td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetLocalListVersionResponse</td><td>1. The OCTT sends a GetLocalListVersionRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message GetLocalListVersionResponse - versionNumber <Configured versionNumber></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 126. Test Case Id: TC_D_10_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Local List Version - Function disabled</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_10_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D02</td></tr><tr><td>Requirement(s)</td><td colspan="2">D02_FR_03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station for the version number of the Local Authorization List by sending a GetLocalListVersionRequest.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond the Local Authorization List version number according to the mechanism as described in the OCPP specification when the LocalAuthListEnabled is set to false.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports the Local Authorization List feature</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:LocalAuthListEnabled is false (If implemented)</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetLocalListVersionResponse</td><td>1. The OCTT sends a GetLocalListVersionRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetLocalListVersionResponse-versionNumber 0</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+# 2.6. E Transactions
+
+Table 127. Test Case Id: TC_E_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - PowerPathClosed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S5)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.05, E01.FR.07, E01.FR.10, E01.FR.15, E01.FR.16</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station starts a transaction when the power path has been closed and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStartPoint is ReadOnly AND (the value PowerPathClosed is NOT set OR (ParkingBayOccupancy OR EVConnected OR Authorized OR DataSigned), is set).
+- If the mutability of TxStartPoint is ReadWrite, then the value PowerPathClosed must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+If the mutability of TxStartPoint is ReadWrite then TxStartPoint contains PowerPathClosed</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is Authorized</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVConnectedPreSession</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 128. Test Case Id: TC_E_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - EnergyTransfer</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S6)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.06, E01.FR.07, E01.FR.10, E01.FR.15, E01.FR.16</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station starts a transaction when the energy transfer starts and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStartPoint is ReadOnly AND (the value EnergyTransfer is NOT set OR (ParkingBayOccupancy OR EVConnected OR Authorized OR DataSigned OR PowerPathClosed), is set).
+- If the mutability of TxStartPoint is ReadWrite, then the value EnergyTransfer must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+If the mutability of TxStartPoint is ReadWrite then TxStartPoint contains EnergyTransfer</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is Authorized</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td>1. The Charging Station notifies the CSMS about the status change of the connector.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: StatusNotificationRequest
+- connectorStatus must be Occupied
+Message: NotifyEventRequest
+- eventData[0].trigger must be Delta
+- eventData[0].actualValue must be Occupied
+- eventData[0].component.name must be Connector
+- eventData[0].variable.name must be AvailabilityState
+* Step 3:
+Message: TransactionEventRequest
+- eventType must be Started
+- If the OCTT is configured to start transactions using a RequestStartTransactionRequest message then triggerReason must be RemoteStart
+Else triggerReason must be ChargingStateChanged or Authorized
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type>
+- evse must be provided
+- evseconnectorId must be provided
+- transactionInfo.chargingState must be Charging</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 129. Test Case Id: TC_E_09_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - EVConnected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_09_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S2)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.02, E01.FR.07, E01.FR.10, E01.FR.15, E01.FR.16</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station starts a transaction when the EV and EVSE are connected and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStartPoint is ReadOnly AND (the value EVConnected is NOT set OR ParkingBayOccupancy is set).
+- If the mutability of TxStartPoint is ReadWrite, then the value EVConnected must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+If the mutability of TxStartPoint is ReadWrite then TxStartPoint contains EVConnected</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is ParkingBayOccupied</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td>1. The Charging Station notifies the CSMS about the status change of the connector.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: StatusNotificationRequest
+- connectorStatus must be Occupied
+Message: NotifyEventRequest
+- eventData[0].trigger must be Delta
+- eventData[0].actualValue must be Occupied
+- eventData[0].component.name must be Connector
+- eventData[0].variable.name must be AvailabilityState
+* Step 3:
+Message: TransactionEventRequest
+- eventType must be Started
+- triggerReason must be CablePluggedIn or ChargingStateChanged
+- evse must be provided
+- evseconnectorId must be provided
+- transactionInfo.chargingState must be EVConnected</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 130. Test Case Id: TC_E_10_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - Authorized - Local</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_10_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S3) AND (C01 OR C02 OR C04 OR C06)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.03, E01.FR.07, E01.FR.10, E01.FR.15, E01.FR.16 AND C01.FR.02, C02.FR.01, C06.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station starts a transaction when the EV and EVSE are connected and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports at least one authorization method described at the following Use cases; C01, C02, C04, C06.
+- The Charging Station does NOT have the following configuration; The mutability of TxStartPoint is ReadOnly AND the value Authorized is NOT set.
+- If the mutability of TxStartPoint is ReadWrite, then the value Authorized must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+If the mutability of TxStartPoint is ReadWrite then TxStartPoint contains Authorized
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present IdToken.</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest
+Note(s):
+- This step needs to be executed, unless AuthEnabled is implemented with mutability ReadOnly AND the value is set to false OR a start button as described at Use case C02 is used (This must be configured at the OCTT).</td><td>2. The OCTT responds with a AuthorizationResponse with idTokenInfo.status Accepted</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: AuthorizationRequest
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type>
+* Step 3:
+Message: TransactionEventRequest
+-eventType must be Started
+-triggerReason must be Authorized
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 131. Test Case Id: TC_E_13_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - Authorized - Remote</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_13_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S3) AND F02</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.03 AND F01.FR.03, F01.FR.04, F01.FR.06, F01.FR.19, F02.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station starts a transaction when the EV and EVSE are connected and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStartPoint is ReadOnly AND the value Authorized is NOT set.
+- If the mutability of TxStartPoint is ReadWrite, then the value Authorized must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+If the mutability of TxStartPoint is ReadWrite then TxStartPoint contains Authorized
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a
+RequestStartTransactionResponse</td><td>1. The OCTT sends a
+RequestStartTransactionRequest
+with idToken.idToken <Configured
+valid_idtoken_idtoken>
+idToken.type <Configured valid_idtoken_type>
+evseld <Configured evseld></td></tr><tr><td>3. The Charging Station sends an AuthorizationRequest
+Note(s):
+- This step needs to be executed when
+AuthCtrl.AuthEnable is implemented with mutability ReadOnly
+AND the value is set to false.</td><td>4. The OCTT responds with an AuthorizationResponse
+with:
+idTokenInfo.status Accepted</td></tr><tr><td>5. The Charging Station sends a
+TransactionEventRequest</td><td>6. The OCTT responds with a
+TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: RequestStartTransactionResponse
+- status must be Accepted
+* Step 3:
+Message: AuthorizationRequest
+-idToken.idToken <Configured valid_idtoken_idtoken>
+-idToken.type <Configured valid_idtoken_type>
+* Step 5:
+Message: TransactionEventRequest
+-eventType must be Started
+- triggerReason must be RemoteStart
+-idToken.idToken <Configured valid_idtoken_idtoken>
+-idToken.type <Configured valid_idtoken_type>
+- transactionInforemoteStartId must be present</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 132. Test Case Id: TC_E_11_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - DataSigned</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_11_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S4)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.04, E01.FR.07, E01.FR.10, E01.FR.15, E01.FR.16</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station starts a transaction when the EV and EVSE are connected and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStartPoint is ReadOnly AND (the value DataSigned is NOT set OR (ParkingBayOccupancy OR EVConnected OR Authorized), is set).
+- If the mutability of TxStartPoint is ReadWrite, then the value DataSigned must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+If the mutability of TxStartPoint is ReadWrite then TxStartPoint contains DataSigned
+SampledDataCtrl.SignReadings is true</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is Authorized</td></tr><tr><td rowspan="5">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td>1. The Charging Station notifies the CSMS about the status change of the connector.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>5. The Charging Station sends a TransactionEventRequest</td><td>6. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>Test case name</td><td>Start transaction options - DataSigned</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: StatusNotificationRequest
+- connectorStatus must be Occupied
+Message: NotifyEventRequest
+- eventData[0].trigger must be Delta
+- eventData[0].actualValue must be Occupied
+- eventData[0].component.name must be Connector
+- eventData[0].variable.name must be AvailabilityState
+* Step 3:
+Message: TransactionEventRequest
+- eventType must be Started
+- If the OCTT is configured to start transactions using a RequestStartTransactionRequest message then triggerReason must be RemoteStart or SignedDataReceived
+Else triggerReason must be SignedDataReceived
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+- evse must be provided
+- evseconnectorld must be provided
+-meterValue is provided with the following values:
+sampledValue.context is Transaction.Begin
+sampledValue-signedMeterValue_encodingMethod is not omitted
+sampledValuesignedMeterValue(publicKey is not omitted
+sampledValuesignedMeterValuesignedMeterData is not omitted
+sampledValue-signedMeterValue/signingMethod is not omitted
+* Step 5:
+Message: TransactionEventRequest
+- eventType must be Updated
+- triggerReason must be ChargingStateChanged
+- transactionInfo.chargingState must be Charging</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 133. Test Case Id: TC_E_12_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - ParkingBayOccupied</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_12_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S1)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.01, E01.FR.07, E01.FR.10, E01.FR.15, E01.FR.16</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station starts a transaction when the EV and EVSE are connected and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStartPoint is ReadOnly AND the value ParkingBayOccupancy is NOT set.
+- If the mutability of TxStartPoint is ReadWrite, then the value ParkingBayOccupancy must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:If the mutability of TxStartPoint is ReadWrite then TxStartPoint contains ParkingBayOccupancy</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Drive EV into parking bay.</td></tr><tr><td>1. The Charging Station sends a TransactionRequest</td><td>2. The OCTT responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: TransactionRequest-eventType must be Started-triggerReason must be EVDetected</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 134. Test Case Id: TC_E_16_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - Deauthorized - Invalid idToken</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_16_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S3)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.04, E06.FR.15 & C15.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when the transaction gets deauthorized by the status from the idTokenInfo at a TransactionEventResponse message and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND the value Authorized OR PowerPathClosed is NOT set OR (EnergyTransfer OR DataSigned is set).
+- If the mutability of TxStopPoint is ReadWrite, then the value Authorized OR PowerPathClosed must be supported.
+- The Charging Station supports local start/stop transaction.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+If the mutability of TxStopPoint is ReadWrite then TxStopPoint contains PowerPathClosed AND/OR Authorized
+AuthCtrllectAuthorized is true (If implemented AND ReadWrite)
+AuthCtrlDisableRemoteAuthorization is false (If implemented)
+OfflineTxForUnknownIdEnabled is true (If implemented)
+StopTxOnInvalidid is true</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid idtoken fields> (If implemented)
+IdTokenLocalAuthList for <Configured valid idtoken fields> (If implemented)</td></tr><tr><td colspan="2">Reusable State(s):
+State is StartOfflineTransaction</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Stations sends a TransactionEventRequest
+Note(s):
+- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionEventRequest messages</td><td>2. The OCTT responds with a TransactionEventResponse
+Note(s):
+- The OCTT will respond to the TransactionEventRequest containing the idToken, with idtokenInfo.status Invalid</td></tr><tr><td>3. The Charging Stations sends a TransactionEventRequest
+Note(s):
+- After having emptied its queue, the Charging Station will send a TransactionEventRequest in which it reports it deauthorized the transaction.</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: TransactionEventRequest
+- offline must be true
+* Step 3:
+Message: TransactionEventRequest
+- eventType must be Ended
+- triggerReason must be Deauthorized
+- transactionInfo.stoppedReason is DeAuthorized</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 135. Test Case Id: TC_E_17_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - Deauthorized - EV side disconnect</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_17_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S3)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.04, E06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when the transaction gets deauthorized by a connection loss from the EV side and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND the value Authorized OR PowerPathClosed is NOT set OR (EnergyTransfer OR DataSigned OR EVConnected is set).- If the mutability of TxStopPoint is _ReadWrite, then the value Authorized OR PowerPathClosed must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="22">Before(Preparations)</td><td colspan="2" rowspan="22">Configuration State:If the mutability of TxStopPoint is ReadWrite then TxStopPoint contains PowerPathClosed AND/OR AuthorizedStopTxOnEVSideDisconnect is trueUnlockOnEVSideDisconnect is falseAuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr><td rowspan="6">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE on EV side (EVSE loses connection with EV).</td></tr><tr><td>1. The Charging Station sends a TransactionEventRequest</td><td>2. The OCTT responds with a TransactionEventResponse</td></tr><tr><td colspan="2">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.</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE on Charging Station side.Note(s):- This manual action needs to be executed when the Charging Station has a detachable cable on the Charging Station side.</td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of the connector.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td>Test case name</td><td>Stop transaction options - Deauthorized - EV side disconnect</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: TransactionRequest
+- triggerReason must be EVCommunicationLost
+- transactionInfo.chargingState must be Idle
+- transactionInfo.stoppedReason must be EVDisconnected
+-eventType must be Ended
+* Step 3:
+Message: StatusNotificationRequest
+- connectorStatus Available
+Message: NotifyEventRequest
+-eventData[0].trigger Delta
+-eventData[0].actualValue "Available"
+-eventData[0].component.name "Connector"
+-eventData[0].variable.name "AvailabilityState"</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 136. Test Case Id: TC_E_39_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - Deauthorized - timeout</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_39_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S3)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.04, E06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when the transaction gets deauthorized because the cable was not plugged in within the Configured durationout and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND the value Authorized is NOT set.
+- If the mutability of TxStopPoint is ReadWrite, then the value Authorized must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+If the mutability of TxStopPoint is ReadWrite then TxStopPoint contains Authorized
+- TxCtrl.EVConnectionTimeout is <Configured ev_connection_timeout>
+- AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is Authorized</td></tr><tr><td rowspan="7">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>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</td><td>2. The OCTT responds with a TransactionEventResponse</td></tr><tr><td colspan="2">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.</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE on EV side.</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE on EVSE side.</td></tr><tr><td>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</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td colspan="2">Note(s):
+Charging Station is allowed to send a TransactionEventRequest for the cableplugin event when this is applicable, but should not start charging.</td></tr><tr><td>Test case name</td><td>Stop transaction options - Deauthorized - timeout</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: TransactionRequest
+- triggerReason must be EVConnectTimeout
+-/eventType must be Updated if TxStartPoint is ParkingBayOccupancy, else Ended
+- transactionInfo.stoppedReason must be Timeout
+* Step 3:
+Message: TransactionRequest
+- triggerReason can only be CablePluggedIn
+- transactionInfo.chagringState should not be Charging
+- eventType must be Updated if TxStartPoint is ParkingBayOccupancy, else Ended</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 137. Test Case Id: TC_E_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - Cable plugin first - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E02 AND (C01 OR C02 OR C04 OR C06)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E02.FR.01, E02.FR.05, E02.FR.06, E02.FR.07, E02.FR.13, E02.FR.15, E02.FR.16, E02.FR.17, E01.FR.16 AND C01.FR.02, C02.FR.01, C06.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first connect the EV and EVSE OR present a form of identification. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to start a charging session when the EV driver first connects the EV and EVSE, before authorization.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports at least one authorization method described at the following Use cases; C01, C02, C04, C06.
+- The Charging Station does NOT have a cable lock, which prevents the EV driver to connect the EV and EVSE before authorization.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl_DISABLERemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized (local)</td></tr><tr><td colspan="2">2. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 138. Test Case Id: TC_E_04_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - Authorization first - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E03 AND (C01 OR C02 OR C04 OR C06)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E03.FR.01, E03.FR.06, E03.FR.12, E01.FR.16 AND C01.FR.02, C02.FR.01, C06.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first connect the EV and EVSE OR present a form of identification. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to start a charging session when the EV driver first presends a form of identification, before connecting the EV and EVSE.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports at least one authorization method described at the following Use cases; C01, C02, C04, C06.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)AuthCtrl.DisableRemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is ParkingBayOccupied (Optional state)</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized (local)</td></tr><tr><td colspan="2">2. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 139. Test Case Id: TC_E_05_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - Authorization first - Cable plugin timeout</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_05_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E03 AND (C01 OR C02 OR C04 OR C06)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E03.FR.01, E03.FR.05, E03.FR.06, E03.FR.12 AND C01.FR.02, C02.FR.01, C06.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first connect the EV and EVSE OR present a form of identification. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to deauthorize the transaction after the EVConnectionTimeout has expired.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports at least one authorization method described at the following Use cases; C01, C02, C04, C06.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+- TxCtrl.EVConnectionTimeOut is <Configured ev_connection_timeout>
+- AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+- AuthCtrl.DisableRemoteAuthorization is false (If implemented)
+- AuthCacheCtrl.Enabled is false (If implemented)
+- AuthCtrl.LocalPreAuthorization is false</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is Authorized (local)</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>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</td><td>2. The OCTT responds with a TransactionEventResponse</td></tr><tr><td colspan="2">Note(s):
+- This step is only executed if TxStartPoint is ParkingBayOccupancy or Authorized
+- Optionally the Charging Station can send a StatusNotificationRequest or NotifyEventRequest with status Available</td></tr><tr><td colspan="2">3. Execute Reusable State Authorized (local)
+Note(s):
+- This step is executed to verify if the EVSE is actually ready to start another charging session.</td></tr><tr><td colspan="2">4. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: TransactionEventRequest
+-triggerReason must be EVConnectTimeout
+If <Configured TxStopPoint> contains Authorized thenieneType must be Ended AND
+transactionInfo.stoppedReason must be Timeout
+ElseieneType must be Updated</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 140. Test Case Id: TC_E_38_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - EV not ready</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_38_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first connect the EV and EVSE OR present a form of identification. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to handle and report if an EV is not ready to start the energy transfer (yet).</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">TxStartPoint should not be EnergyTransfer</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is Authorized</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Set the EV to a state in which it is NOT ready for energy transfer.</td></tr><tr><td colspan="2">1. Execute Reusable State EVConnectedPreSession</td></tr><tr><td>2. The Charging Station sends a TransactionEventRequest</td><td>3. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:
+Message: TransactionEventRequest
+- triggerReason must be ChargingStateChanged
+- transactionInfo.chargingState must be SuspendedEV</td></tr></table>
+
+Table 141. Test Case Id: TC_E_52_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - Authorization first - DisableRemoteAuthorization</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_52_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E03 AND C01</td></tr><tr><td>Requirement(s)</td><td colspan="2">C01.FR.02, C01.FR.05,</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">When DisableRemoteAuthorization is set to true, the Charging Station will only try to look up an IdToken in Authorization Cache or Local Authorization List, and not do an InvalidateRequest for IdTokens. This overrules requirement C01.FR.02 and C01.FR.05.</td></tr><tr><td>Purpose</td><td colspan="2">To verify that the Charging Station will not send an InvalidateRequest when DisableRemoteAuthorization is set to true.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports the authorization method described in C01. (RFID)AuthCtrl.DisableRemoteAuthorization is implemented.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:AuthCtrl.Enabled is true (If implemented)AuthCtrl.DisableRemoteAuthorization is true</td></tr><tr><td colspan="2">Memory State:None of the configured valid IdTokens is present in Authorization Cache or Local Authorization List.</td></tr><tr><td colspan="2">Reusable State(s):State is ParkingBayOccupied (Optional state)</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present an idToken which is not configured in the Local Authorization List nor present in Authorization Cache.</td></tr><tr><td>1. The Charging Station does NOT send a InvalidateRequest</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Check that Charging Station does NOT send an InvalidateRequest and authorization is refused.</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 142. Test Case Id: TC_E_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Local Stop Transaction - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_06_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E07 AND (C01 OR C02 OR C04)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E07.FR.04, E06.FR.15 AND C01.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The EV Driver is able to stop an ongoing transaction, by locally presenting an IdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to perform a local stop authorization.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports at least one authorization method described at the following Use cases; C01, C02, C04.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl_DISABLERemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="5">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State StopAuthorized (local)</td></tr><tr><td colspan="2">2. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">3. Execute Reusable State EVDisconnect</td></tr><tr><td colspan="2">4. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 143. Test Case Id: TC_E_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - PowerPathClosed - Local stop</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S5)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.06, E06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when it is locally stopped by an EV driver and TxStopPoint contains PowerPathClosed.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND (the value PowerPathClosed is NOT set OR Authorized is set).
+- If the mutability of TxStopPoint is ReadWrite, then the value PowerPathClosed must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+TxStopPoint contains PowerPathClosed</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present IdToken to stop charging session.</td></tr><tr><td colspan="2">1. Execute Reusable State StopAuthorized</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 144. Test Case Id: TC_E_35_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - PowerPathClosed - Remote stop</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_35_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S5)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.06, E06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when it is remotely stopped the CSMS and TxStopPoint contains PowerPathClosed.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND (the value PowerPathClosed is NOT set OR Authorized is set).
+- If the mutability of TxStopPoint is ReadWrite, then the value PowerPathClosed must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+TxStopPoint contains PowerPathClosed</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a RequestStopTransactionResponse</td><td>1. The OCTT sends a RequestStopTransactionRequest
+with transactionId <transactionId provided by the Charging Station in TransactionEventRequest></td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: RequestStopTransactionResponse
+- status must be Accepted
+* Step 3:
+Message: TransactionRequest
+- triggerReason must be RemoteStop
+- transactionInfo.stoppedReason must be Remote
+- eventType must be Ended</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 145. Test Case Id: TC_E_37_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - PowerPathClosed - EV side disconnect</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_37_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S5)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.06, E06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when the EV and the EVSE get disconnected and TxStopPoint contains PowerPathClosed.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND (the value PowerPathClosed is NOT set OR (EnergyTransfer OR EVConnected OR DataSigned is set)).- If the mutability of TxStopPoint is ReadWrite, then the value PowerPathClosed must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:TxStopPoint contains PowerPathClosedStopTxOnEVSideDisconnect is false (If mutability is ReadWrite)</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferSuspended</td></tr><tr><td rowspan="3">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE on EV side (EVSE loses connection with EV).</td></tr><tr><td>1. The Charging Station sends aTransactionEventRequest</td><td>2. The OCTT responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* 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</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 146. Test Case Id: TC_E_08_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - EnergyTransfer stopped - StopAuthorized</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_08_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S6)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.07, E06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when the energy transfer stopped normally and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND (the value EnergyTransfer is NOT set OR (Authorized OR PowerPathClosed) is set).
+- If the mutability of TxStopPoint is ReadWrite, then the value EnergyTransfer must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+TxStopPoint contains EnergyTransfer</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. State is StopAuthorized</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 147. Test Case Id: TC_E_22_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - EnergyTransfer stopped - SuspendedEV</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_22_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S6)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.07, E06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when the energy transfer stopped by the EV and the Charging Station has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND the value EnergyTransfer is NOT set.
+- If the mutability of TxStopPoint is ReadWrite, then the value EnergyTransfer must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+TxStopPoint contains EnergyTransfer</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: The EV suspends the energy transfer.</td></tr><tr><td>1. The Charging Station sends a TransactionEventRequest</td><td>2. The OCTT responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* 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 (if chargingState is EVConnected) OR
+-eventType must be Updated (if chargingState is SuspendedEV)</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 148. Test Case Id: TC_E_14_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - EVDisconnected - Charging Station side</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_14_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S2)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.02, E06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when the EV and EVSE are disconnected at the Charging Station side and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND (the value EVConnected is NOT set OR (EnergyTransfer OR PowerPathClosed OR DataSigned OR Authorized is set)).- If the mutability of TxStopPoint is ReadWrite, then the value EVConnected must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:TxStopPoint contains EVConnected</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EVConnectedPostSession</td></tr><tr><td rowspan="4">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE.</td></tr><tr><td>1. The Charging Station notifies the CSMS about the status change of the connector.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: StatusNotificationRequest- connectorStatus must be AvailableMessage: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Available-eventData[0].component.name must be Connector-eventData[0].variable.name must be AvailabilityState* 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 RemoteElse transactionInfo.stoppedReason must be Local, EVDisconnected or be omitted.- eventType must be Ended</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 149. Test Case Id: TC_E_20_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - EVDisconnected - EV side (able to charge IEC 61851-1 EV)</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_20_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S2), E10</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.02, E06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when the EV and EVSE are disconnected at the EV side and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND (the value EVConnected is NOT set OR (EnergyTransfer OR PowerPathClosed is set)).- If the mutability of TxStopPoint is ReadWrite, then the value EVConnected must be supported.- The Charging Station does NOT have following configuration combination; StopTxOnEVSideDisconnectment mutability ReadOnly with value true AND TxStopPoint mutability is ReadOnly and contains Authorized.- The Charging Station is able to charge with a EV that uses IEC 61851-1.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:TxStopPoint contains EVConnectedStopTxOnEVSideDisconnect is false (If mutability is ReadWrite)</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferSuspended</td></tr><tr><td rowspan="3">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE on EV side (EVSE loses connection with EV).</td></tr><tr><td>1. The Charging Station sends aTransactionEventRequest</td><td>2. The OCTT responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: TransactionEventRequest-triggerReason must be EVCommunicationLost- transactionInfo.chargingState must be Idle- transactionInfo.stoppedReason must be EVDisconnected-eventType must be Ended</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 150. Test Case Id: TC_E_54_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - EVDisconnected - EV side (not able to charge IEC 61851-1 EV)</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_54_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S2), E10</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.02, E06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when the EV and EVSE are disconnected at the EV side and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND (the value EVConnected is NOT set OR (EnergyTransfer OR PowerPathClosed is set)).- If the mutability of TxStopPoint is ReadWrite, then the value EVConnected must be supported.- The Charging Station does NOT have following configuration combination; StopTxOnEVSideDisconnectment mutability ReadOnly with value true AND TxStopPoint mutability is ReadOnly and contains Authorized.- The Charging Station supports high level communication.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:TxStopPoint contains EVConnectedStopTxOnEVSideDisconnect is false (If mutability is ReadWrite)</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferSuspended</td></tr><tr><td rowspan="3">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE on EV side (EVSE loses connection with EV).</td></tr><tr><td>1. The Charging Station sends aTransactionEventRequest</td><td>2. The OCTT responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: TransactionEventRequest-triggerReason must be EVCommunicationLost- transactionInfo.chargingState must be Idle- transactionInfo.stoppedReason must be StoppedByEV or EVDisconnected-eventType must be Ended</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 151. Test Case Id: TC_E_15_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - StopAuthorized - Local</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_15_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S3)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.03, E06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when the EV driver locally stops the transaction and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports at least one authorization method described at the following Use cases; C01, C02, C04.
+- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND the value Authorized is NOT set OR PowerPathClosed is set.
+- If the mutability of TxStopPoint is ReadWrite, then the value Authorized must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+TxStopPoint contains Authorized</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Notes(s): The tool will wait for <Configured Transaction Duration> seconds</td></tr><tr><td colspan="2">Manual Action: Present IdToken to stop charging session.</td></tr><tr><td>1. The Charging Station sends a TransactionEventRequest</td><td>2. The OCTT responds with a TransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: TransactionRequest
+-triggerReason must be StopAuthorized
+- transactionInfo.stoppedReason must be Local
+-eventType must be Ended</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 152. Test Case Id: TC_E_21_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - StopAuthorized - Remote</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_21_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S3) AND F03</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.03, E06.FR.15 AND F03.FR.09</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when it receives a RequestStopTransactionRequest and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND the value Authorized is NOT set OR PowerPathClosed is set.- If the mutability of TxStopPoint is ReadWrite, then the value Authorized must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: TxStopPoint contains Authorized</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a RequestStopTransactionResponse</td><td>1. The OCTT sends a RequestStopTransactionRequest with transactionId <transactionId provided by the Charging Station in TransactionEventRequest></td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: RequestStopTransactionResponse - status must be Accepted * Step 3: Message: TransactionRequest - triggerReason must be RemoteStop - transactionInfo.stoppedReason must be Remote - eventType must be Ended</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 153. Test Case Id: TC_E_19_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - ParkingBayUnoccupied</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_19_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S1)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.01, E06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station stops a transaction when the EV left the parking bay and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is ReadOnly AND (the value ParkingBayOccupied is NOT set OR (EnergyTransfer OR PowerPathClosed OR DataSigned OR Authorized OR EVConnected is set)).- If the mutability of TxStopPoint is ReadWrite, then the value ParkingBayOccupied must be supported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:TxStopPoint contains ParkingBayOccupied</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EVDisconnected</td></tr><tr><td rowspan="3">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Drive EV out of parking bay.</td></tr><tr><td>1. The Charging Station sends aTransactionEventRequest</td><td>2. The OCTT responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: TransactionEventRequest- triggerReason must be EVDeparted- If the OCTT is configured to stop transactions using a RequestStopTransactionRequest message then transactionInfo.stoppedReason must be RemoteElse transactionInfo.stoppedReason must be Local-eventType must be Ended</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 154. Test Case Id: TC_E_24_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Disconnect cable on EV-side - Deauthorize transaction - UnlockEVSideDisconnect is true</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_24_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E09</td></tr><tr><td>Requirement(s)</td><td colspan="2">E09.FR.01, E09.FR.02, E09.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station can behave in several different ways when the cable is disconnected at the EV side, based on its configuration. This test case tests one of the possible configuration settings.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station deauthorized the transaction when the EV and EVSE are disconnected at the EV side and it has been configured to do so AND unlocks the cable at Charging Station side.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station does NOT have a permanently attached cable.</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: StopTxDvSideDisconnect is true UnlockEVSideDisconnect is true</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferSuspended</td></tr><tr><td rowspan="5">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE on EV side (EVSE loses connection with EV).</td></tr><tr><td>1. The Charging Station sends a TransactionRequest</td><td>2. The OCTT responds with a TransactionResponse</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE on Charging Station side.</td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of the connector.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: TransactionRequest - triggerReason must be EVCommunicationLost - transactionInfo.chargingState must be Idle * Step 3: Message: StatusNotificationRequest - connectorStatus Available Message: NotifyEventRequest - eventData[0].trigger Delta - eventData[0].actualValue "Available" - eventData[0].component.name "Connector" - eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 155. Test Case Id: TC_E_25_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Disconnect cable on EV-side - Deauthorize transaction - UnlockOnEVSideDisconnect is false</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_25_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E09</td></tr><tr><td>Requirement(s)</td><td colspan="2">E09.FR.01, E09.FR.03, E09.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station can behave in several different ways when the cable is disconnected at the EV side, based on its configuration. This test case tests one of the possible configuration settings.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station deauthorized the transaction when the EV and EVSE are disconnected at the EV side and it has been configured to do so AND keeps the cable locked at Charging Station side.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+StopTxOnEVSideDisconnect is true
+UnlockOnEVSideDisconnect is false</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferSuspended</td></tr><tr><td rowspan="8">Main
+(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE on EV side (EVSE loses connection with EV).</td></tr><tr><td>1. The Charging Station sends a TransactionRequest</td><td>2. The OCTT responds with a TransactionResponse</td></tr><tr><td colspan="2">Manual Action: Present the IdToken that was used to start the transaction.</td></tr><tr><td colspan="2">Note(s):
+- This manual action needs to be executed when the Charging Station has a detachable cable on the Charging Station side.</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE on Charging Station side.</td></tr><tr><td colspan="2">Note(s):
+- This manual action needs to be executed when the Charging Station has a detachable cable on the Charging Station side.</td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of the connector.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: TransactionEventRequest
+-triggerReason must be EVCommunicationLost
+- transactionInfo.chargingState must be Idle
+* Step 3:
+Message: StatusNotificationRequest
+- connectorStatus Available
+Message: NotifyEventRequest
+- eventData[0].trigger Delta
+- eventData[0].actualValue "Available"
+- eventData[0].component.name "Connector"
+- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 156. Test Case Id: TC_E_26_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Disconnect cable on EV-side - Suspend transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_26_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E10</td></tr><tr><td>Requirement(s)</td><td colspan="2">E10.FR.01, E10.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station can behave in several different ways when the cable is disconnected at the EV side, based on its configuration. This test case tests one of the possible configuration settings.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station suspends the transaction when the EV and EVSE are disconnected at the EV side and it has been configured to do so AND is able restart the energy transfer after reconnecting the EV and EVSE.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is 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.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="22">Before(Preparations)</td><td colspan="2" rowspan="22">Configuration State:TxStopPoint contains Authorized (If supported) AND/OR ParkingBayOccupancy (If supported)UnlockOnEVSideDisconnect is falseStopTxOnEVSideDisconnect is false</td></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr><td rowspan="7">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE on EV side (EVSE loses connection with EV).</td></tr><tr><td>1. The Charging Station sends aTransactionEventRequest</td><td>2. The OCTT responds with aTransactionEventResponse</td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of the connector.Note(s):- This step needs to be executed when the Charging Station has a permanently attached cable on the Charging Station side.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td colspan="2">Manual Action: Reconnect the EV and EVSE on EV side.Note(s):- If the Charging Station has a permanently attached cable on the Charging Station side, then this step needs to be executed before the configured EVConnectionTimeout expires.</td></tr><tr><td>5. The Charging Station sends aTransactionEventRequest</td><td>6. The OCTT responds with aTransactionEventResponse</td></tr><tr><td>7. The Charging Station sends aTransactionEventRequest</td><td>8. The OCTT responds with aTransactionEventResponse</td></tr><tr><td>Test case name</td><td>Disconnect cable on EV-side - Suspend transaction</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: TransactionRequest
+- triggerReason must be EVCommunicationLost
+- transactionInfo.chargingState must be Idle
+- eventType must be Updated
+* Step 3:
+Message: StatusNotificationRequest
+- connectorStatus Available
+Message: NotifyEventRequest
+- eventData[0].trigger Delta
+- eventData[0].actualValue "Available"
+- eventData[0].component.name "Connector"
+- eventData[0].variable.name "AvailabilityState"
+* Step 5:
+Message: TransactionRequest
+- triggerReason must be CablePluggedIn
+- transactionInfo.chargingState must be EVConnected
+- eventType must be Updated
+* Step 7:
+Message: TransactionRequest
+- triggerReason must be ChargingStateChanged
+- transactionInfo.chargingState must be Charging
+- eventType must be Updated</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 157. Test Case Id: TC_E_27_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Disconnect cable on EV-side - Suspend transaction - Fixed cable connection timeout</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_27_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E10</td></tr><tr><td>Requirement(s)</td><td colspan="2">E10.FR.02, E10.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station can behave in several different ways when the cable is disconnected at the EV side, based on its configuration. This test case tests one of the possible configuration settings.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station suspends the transaction when the EV and EVSE are disconnected at the EV side and it has been configured to do so AND deauthorizeds the transaction after the configured connection timeout expires.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have the following configuration; The mutability of TxStopPoint is 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.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:TxStopPoint contains Authorized (If supported)TxStopPoint contains ParkingBayOccupancy (If supported)UnlockOnEVSideDisconnect is falseStopTxOnEVSideDisconnect is false</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferSuspended</td></tr><tr><td rowspan="7">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE on EV side (EVSE loses connection with EV).</td></tr><tr><td>1. The Charging Station sends aTransactionEventRequest</td><td>2. The OCTT responds with aTransactionEventResponse</td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of the connector.Note(s):- This step needs to be executed when the Charging Station has a permanently attached cable on the Charging Station side.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td colspan="2">Manual Action: Reconnect the EV and EVSE on EV side.Note(s):- If the Charging Station has a permanently attached cable on the Charging Station side, then this step needs to be executed before the configured EVConnectionTimeout expires.</td></tr><tr><td>5. The Charging Station sends aTransactionEventRequest</td><td>6. The OCTT responds with aTransactionEventResponse</td></tr><tr><td colspan="2">Note(s): Optionally the Charging Station can send a StatusNotificationRequest or NotifyEventRequest with status Available</td></tr><tr><td>Test case name</td><td>Disconnect cable on EV-side - Suspend transaction - Fixed cable connection timeout</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: TransactionRequest
+- triggerReason must be EVCommunicationLost
+- transactionInfo.chargingState must be Idle
+- eventType must be Updated
+* Step 3:
+Message: StatusNotificationRequest
+- connectorStatus Available
+Message: NotifyEventRequest
+- eventData[0].trigger Delta
+- eventData[0].actualValue "Available"
+- eventData[0].component.name "Connector"
+- eventData[0].variable.name "AvailabilityState"
+* Step 5:
+Message: TransactionRequest
+- triggerReason must be EVConnectTimeout
+If <Configured TxCtrlr.TxStopPoint> contains Authorized then
+eventType must be Ended
+transactionInfo.stoppedReason must be Timeout
+else if <Configured TxCtrlr.TxStopPoint> contains ParkingBayOccupancy then
+eventType must be Updated</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 158. Test Case Id: TC_E_28_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Check Transaction status - TransactionId unknown</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_28_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E14</td></tr><tr><td>Requirement(s)</td><td colspan="2">E14.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the status of a transaction and to find out whether there are queued transaction-related messages, using the GetTransactionStatusRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to handle receiving a GetTransactionStatusRequest for an unknown transactionId.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetTransactionStatusResponse</td><td>1. The OCTT sends a GetTransactionStatusRequest with transactionId <Randomly generated transactionId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: GetTransactionStatusResponse - ongoingIndicator must be false - messagesInQueue must be false</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 159. Test Case Id: TC_E_29_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Check Transaction status - Transaction with id ongoing - with message in queue</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_29_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E14</td></tr><tr><td>Requirement(s)</td><td colspan="2">E14.FR.02,E14.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the status of a transaction and to find out whether there are queued transaction-related messages, using the GetTransactionStatusRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly respond to a GetTransactionStatusRequest with a transactionId, while there is a message queued belonging to an ongoing transaction with the requested id.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+SampleDataTxUpdatedMeasurands is <Configured transaction_update_metricvalues_MEASURands>
+SampleDataTxUpdatedInterval is <Configured transaction_update_metricvalues_interval>
+OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + 60.0
+RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration>
+RetryBackOffRandomRange is 0
+Note:
+<Configured RetryBackOffWaitMinimum_duration> must be greater than <Configured Transaction MeterValues interval></td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State Is EnergyTransferStarted</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td></td><td>1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td></td><td>2. The OCTT waits a number of seconds equal to <Configured RetryBackOffWaitMinimum_duration>, before accepting a reconnection attempt from the Charging Station.</td></tr><tr><td>4. The Charging Station responds with a GetTransactionStatusResponse</td><td>3. The OCTT sends a GetTransactionStatusRequest with transactionId <Generated transactionId from Before>
+Note:
+This step will be executed the moment the WebSocket connection is restored.</td></tr><tr><td>5. The Charging Stations sends a TransactionEventRequest
+Note(s):
+- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionEventRequest messages</td><td>6. The OCTT responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 4:
+Message: GetTransactionStatusResponse
+- ongoingIndicator must be true
+- messagesInQueue must be true
+* Step 5:
+Message: TransactionEventRequest
+- eventType must be Updated
+- meterValues must be present.
+- offline must be true</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 160. Test Case Id: TC_E_30_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Check Transaction status - Transaction with id ongoing - without message in queue</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_30_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E14</td></tr><tr><td>Requirement(s)</td><td colspan="2">E14.FR.02,E14.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the status of a transaction and to find out whether there are queued transaction-related messages, using the GetTransactionStatusRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly respond to a GetTransactionStatusRequest with a transactionId, while there is NO message queued belonging to an ongoing transaction with the requested id.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetTransactionStatusResponse</td><td>1. The OCTT sends a GetTransactionStatusRequest with transactionId <Generated transactionId from Before></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: GetTransactionStatusResponse - ongoingIndicator must be true - messagesInQueue must be false</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 161. Test Case Id: TC_E_31_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Check Transaction status - Transaction with id ended - with message in queue</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_31_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E14</td></tr><tr><td>Requirement(s)</td><td colspan="2">E14.FR.03,E14.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the status of a transaction and to find out whether there are queued transaction-related messages, using the GetTransactionStatusRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly respond to a GetTransactionStatusRequest with a transactionId, while there is a message queued belonging to an ended transaction with the requested id.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The following combination of conditions are NOT true:
+- No local authorization methods are supported AND
+- TxStopPoint mutability is false and only contains Authorized AND
+- TxCtrl. 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.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+SampledDataTxUpdatedMeasurands is <Configured transaction_update_metricvalues-measurands>
+SampledDataTxUpdatedInterval is <Configured transaction_update_metricvalues_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</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="10">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td></td><td>The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Present the same idToken as used to start the transaction.</td></tr><tr><td colspan="2">Notes(s): Only if configured scenario is local</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE.</td></tr><tr><td colspan="2">Manual Action: Drive EV out of parking bay. (Only needed if TxStopPoint is ParkingBayOccupancy)</td></tr><tr><td colspan="2">Notes(s): The tool will wait for <Configured Transaction Duration> seconds</td></tr><tr><td></td><td>The OCTT accepts reconnection attempt from the Charging Station.</td></tr><tr><td>2. The Charging Station responds with a GetTransactionStatusResponse</td><td>1. The OCTT sends a GetTransactionStatusRequest with transactionId <Generated transactionId from Before>
+Note: This step will be executed the moment the WebSocket connection is restored.</td></tr><tr><td>3. The Charging Stations sends a TransactionEventRequest
+Note(s):
+- The Charging Station will empty its Transaction message queue. This will contain all TransactionEventRequest messages from the Transaction.</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>Test case name</td><td>Check Transaction status - Transaction with id ended - with message in queue</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message: GetTransactionStatusResponse
+- ongoingIndicator must be false
+- messagesInQueue must be true
+* Step 3:
+Message: TransactionEventRequest
+The tool validations from the reusable states need to be used to verify whether all required
+TransactionEventRequests have been received.
+From StopAuthorized through ParkingBayUnoccupied</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 162. Test Case Id: TC_E_32_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Check Transaction status - Transaction with id ended - without message in queue</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_32_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E14</td></tr><tr><td>Requirement(s)</td><td colspan="2">E14.FR.03,E14.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the status of a transaction and to find out whether there are queued transaction-related messages, using the GetTransactionStatusRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly respond to a GetTransactionStatusRequest with a transactionId, while there is NO message queued belonging to an ended transaction with the requested id.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted, ParkingBayUnoccupied</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetTransactionStatusResponse</td><td>1. The OCTT sends a GetTransactionStatusRequest with transactionId <Generated transactionId from Before></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: GetTransactionStatusResponse - ongoingIndicator must be false - messagesInQueue must be false</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 163. Test Case Id: TC_E_33_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Check Transaction status - Without transactionId - with message in queue</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_33_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E14</td></tr><tr><td>Requirement(s)</td><td colspan="2">E14.FR.06,E14.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the status of a transaction and to find out whether there are queued transaction-related messages, using the GetTransactionStatusRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly respond to a GetTransactionStatusRequest without a transactionId, while there is a message queued.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+SampledDataTxUpdatedMeasurands is <Configured transaction_update_metricvalues_MEASURands>
+SampledDataTxUpdatedInterval is <Configured transaction_update_metricvalues_interval>
+OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + 60.0
+RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration>
+RetryBackOffRandomRange is 0
+Note:
+<Configured RetryBackOffWaitMinimum_duration> must be greater than <Configured Transaction MeterValues interval></td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td></td><td>1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td></td><td>2. The OCTT waits a number of seconds equal to <Configured RetryBackOffWaitMinimum_duration>, before accepting a reconnection attempt from the Charging Station.</td></tr><tr><td>4. The Charging Station responds with a GetTransactionStatusResponse</td><td>3. The OCTT sends a GetTransactionStatusRequest with transactionId omitted
+Note:
+This step will be executed the moment the WebSocket connection is restored.</td></tr><tr><td>5. The Charging Stations sends a TransactionEventRequest
+Note(s):
+- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionEventRequest messages</td><td>6. The OCTT responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 4:
+Message: GetTransactionStatusResponse
+- ongoingIndicator must be omitted
+- messagesInQueue must be true
+* Step 5:
+Message: TransactionEventRequest
+- eventType must be Updated
+- meterValues must be present.
+- offline must be true</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 164. Test Case Id: TC_E_34_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Check Transaction status - Without transactionId - without message in queue</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_34_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E14</td></tr><tr><td>Requirement(s)</td><td colspan="2">E14.FR.06,E14.FR.08</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the status of a transaction and to find out whether there are queued transaction-related messages, using the GetTransactionStatusRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly respond to a GetTransactionStatusRequest without a transactionId, while there is NO message queued.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetTransactionStatusResponse</td><td>1. The OCTT sends a GetTransactionStatusRequest with transactionId omitted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: GetTransactionStatusResponse - ongoingIndicator must be omitted - messagesInQueue must be false</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 165. Test Case Id: TC_E_40_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Offline Behaviour - Connection loss during transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_40_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E11</td></tr><tr><td>Requirement(s)</td><td colspan="2">E11.FR.01,E11.FR.02,E11.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station queues TransactionEvent messages to inform the CSMS that a transaction occurred while the Charging Station was Offline.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to queue TransactionEvent messages while it is offline.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:
+SampledDataTxUpdatedMeasurands is <Configured transaction_update_metricvalues_MEASURands>
+SampledDataTxUpdatedInterval is <Configured transaction_update_metricvalues_interval>
+SampledDataEnabled is true
+OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + 60.0
+RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration>
+RetryBackOffRandomRange is 0
+Note:
+<Configured RetryBackOffWaitMinimum_duration> must be greater than <Configured TransactionMeterValues interval></td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td></td><td>1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td></td><td>2. The OCTT waits a number of seconds equal to <Configured RetryBackOffWaitMinimum_duration>, before accepting a reconnection attempt from the Charging Station.</td></tr><tr><td>3. The Charging Stations sends a TransactionRequest
+Note(s):
+- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionEventRequest messages</td><td>4. The OCTT responds with a TransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3:
+All messages: TransactionRequest
+-eventType must be Updated
+-meterValues must be present.
+-offline must be true</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 166. Test Case Id: TC_E_41_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retry sending transaction message when failed - Max retry count reached</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_41_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E13</td></tr><tr><td>Requirement(s)</td><td colspan="2">E13.FR.01,E13.FR.02,E13.FR.03,E13.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">There are situations/issues why a CSMS might not accept a transaction related message, or does not reply within the MessageTimeout. Most are error scenarios. When something like this happens, the Charging Station SHALL retry the messages a couple of times.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to resend TransactionEvent messages until the max retry count is reached, when the CSMS does not reply.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:MessageAttemptsTransactionEvent is <Configured message Attempts transaction event> (Must be > 1)MessageAttemptIntervalTransactionEvent is <Configured message Attempts transaction event interval></td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is AuthorizedState is EVConnectedPreSession</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note(s):Step 1, 2, 3, & 4 are optional</td></tr><tr><td>1. The Charging Stations sends aTransactionEventRequest with:- triggerReason SignedDataReceived</td><td>2. The OCTT responds with aTransactionEventResponse</td></tr><tr><td>3. The Charging Stations sends aTransactionEventRequest with:- triggerReason ChargingStateChanged- chargingState SuspendedEVSE</td><td>4. The OCTT responds with aTransactionEventResponse</td></tr><tr><td colspan="2">Note(s):Step 5 is repeated for the configured number of times</td></tr><tr><td>5. The Charging Stations sends aTransactionEventRequest</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:- triggerReason SignedDataReceived* Step 3:- triggerReason ChargingStateChanged- chargingState SuspendedEVSE* Step 5:- Needs to be sent a number of times equal to <Configured message Attempts transaction event> with aninterval of (<Configured message Attempts transaction event interval> * the number of preceding transmissions of this same message) + OCPPCommCtrl.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).</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 167. Test Case Id: TC_E_50_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retry sending transaction message when failed - Max retry count reached - CallError</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_50_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E13</td></tr><tr><td>Requirement(s)</td><td colspan="2">E13.FR.01,E13.FR.02,E13.FR.03,E13.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">There are situations/issues why a CSMS might not accept a transaction related message, or does not reply within the MessageTimeout. Most are error scenarios. When something like this happens, the Charging Station SHALL retry the messages a couple of times.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to resend TransactionEvent messages until the max retry count is reached, when the CSMS does not reply.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:MessageAttemptsTransactionEvent is <Configured message Attempts transaction event> (Must be > 1)MessageAttemptIntervalTransactionEvent is <Configured message Attempts transaction event interval></td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is AuthorizedState is EVConnectedPreSession</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note(s):Step 1, 2, 3, & 4 are optional</td></tr><tr><td>1. The Charging Stations sends aTransactionEventRequest with:- triggerReason SignedDataReceived</td><td>2. The OCTT responds with aTransactionEventResponse</td></tr><tr><td>3. The Charging Stations sends aTransactionEventRequest with:- triggerReason ChargingStateChanged- chargingState SuspendedEVSE</td><td>4. The OCTT responds with aTransactionEventResponse</td></tr><tr><td colspan="2">Note(s):Step 5 is repeated for the configured number of times</td></tr><tr><td>5. The Charging Stations sends aTransactionEventRequest</td><td>6. The OCTT responds with aCallError witherrorCode InternalError</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:- triggerReason SignedDataReceived* Step 3:- triggerReason ChargingStateChanged- chargingState SuspendedEVSE* Step 5:- Needs to be sent a number of times equal to <Configured message Attempts transaction event> with aninterval of the <Configured message Attempts transaction event interval> multiplied by the number ofpreceding transmissions of this same message.- 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).</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 168. Test Case Id: TC_E_42_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retry sending transaction message when failed - Success before reaching the max retry count</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_42_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E13</td></tr><tr><td>Requirement(s)</td><td colspan="2">E13.FR.01,E13.FR.02,E13.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">There are situations/issues why a CSMS might not accept a transaction related message, or does not reply within the MessageTimeout. Most are error scenarios. When something like this happens, the Charging Station SHALL retry the messages a couple of times.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to resend TransactionEvent messages when the CSMS does not reply and stops resending after getting a response before the max retry count is reached.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:MessageAttemptsTransactionEvent is <Configured message Attempts transaction event> (Must be > 2)MessageAttemptIntervalTransactionEvent is <Configured message Attempts transaction event interval></td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is AuthorizedState is EVConnectedPreSession</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note(s):Step 1, 2, 3, & 4 are optional</td></tr><tr><td>1. The Charging Stations sends aTransactionEventRequest with:- triggerReason DataReceived</td><td>2. The OCTT responds with aTransactionResponse</td></tr><tr><td>3. The Charging Stations sends aTransactionEventRequest with:- triggerReason ChargingStateChanged- chargingState SuspendedEVSE</td><td>4. The OCTT responds with aTransactionResponse</td></tr><tr><td colspan="2">Note(s):The tool will ignore the first request and only respond to the second request</td></tr><tr><td>5. The Charging Stations sends aTransactionEventRequest</td><td>6. The OCTT responds with aTransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:- triggerReason SignedDataReceived* Step 3:- triggerReason ChargingStateChanged- chargingState SuspendedEVSE* 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) + OCPPCommCtrl.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).</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 169. Test Case Id: TC_E_51_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retry sending transaction message when failed - Success before reaching the max retry count - CallError</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_51_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E13</td></tr><tr><td>Requirement(s)</td><td colspan="2">E13.FR.01,E13.FR.02,E13.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">There are situations/issues why a CSMS might not accept a transaction related message, or does not reply within the MessageTimeout. Most are error scenarios. When something like this happens, the Charging Station SHALL retry the messages a couple of times.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to resend TransactionEvent messages when the CSMS does not reply and stops resending after getting a response before the max retry count is reached.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:MessageAttemptsTransactionEvent is <Configured message Attempts transaction event> (Must be > 2)MessageAttemptIntervalTransactionEvent is <Configured message Attempts transaction event interval></td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is AuthorizedState is EVConnectedPreSession</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note(s): Step 1, 2, 3, & 4 are optional</td></tr><tr><td>1. The Charging Stations sends aTransactionRequest with:- triggerReason SignedDataReceived</td><td>2. The OCTT responds with aTransactionResponse</td></tr><tr><td>3. The Charging Stations sends aTransactionRequest with:- triggerReason ChargingStateChanged- chargingState SuspendedEVSE</td><td>4. The OCTT responds with aTransactionResponse</td></tr><tr><td colspan="2">Note(s): The tool will send a CallError with errorCode InternalError to all requests except for the second request, there a TransactionEventResponse is send</td></tr><tr><td>5. The Charging Stations sends aTransactionRequest</td><td>6. The OCTT responds with aTransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:- triggerReason SignedDataReceived* Step 3:- triggerReason ChargingStateChanged- chargingState SuspendedEVSE* 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) +OCPPCommCtrl.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).</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 170. Test Case Id: TC_E_43_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Offline Behaviour - Transaction during offline period</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_43_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E12</td></tr><tr><td>Requirement(s)</td><td colspan="2">E12.FR.01,E12.FR.02,E12.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station queues TransactionEvent messages to inform the CSMS that a transaction occurred while the Charging Station was Offline.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to queue TransactionEvent messages while it was offline.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State TransactionEventsInQueueEnded</td></tr><tr><td>2. The Charging Stations sends aTransactionRequestNote(s):- The Charging Station will empty its Transactionmessage queue. This will contain one or moreTransactionEventRequest messages</td><td>3. The OCTT responds with aTransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:All messages: TransactionRequest-offline must be trueOne of the messages: TransactionRequest-eventType StartedOne of the messages: TransactionRequest-eventType Ended</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 171. Test Case Id: TC_E_44_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Offline Behaviour - Stop transaction during offline period</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_44_CS</td></tr><tr><td>Use case ld(s)</td><td colspan="2">E08</td></tr><tr><td>Requirement(s)</td><td colspan="2">E08.FR.01,E08.FR.04,E08.FR.05,E08.FR.06,E08.FR.07,E08.FR.08</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station queues TransactionEvent messages to inform the CSMS that a transaction occurred while the Charging Station was Offline.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to queue TransactionEvent messages when the transaction stopped while the Charging Station was offline.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:OfflineThreshold is <Configured RetryBackOffWaitMinimum_duration> + 60.0RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum_duration>RetryBackOffRandomRange is 0Note:<Configured RetryBackOffWaitMinimum_duration should be long enough to execute manual tasks></td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td></td><td>1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Present the same idToken as used to start the transaction.</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE.</td></tr><tr><td colspan="2">Manual Action: Drive EV out of parking bay. (Only needed if TxStopPoint is ParkingBayOccupancy)</td></tr><tr><td></td><td>2. The OCTT accepts the reconnection attempt from the Charging Station.</td></tr><tr><td>3. The Charging Stations sends aTransactionRequestNote(s):- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionEventRequest messages</td><td>4. The OCTT responds with aTransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3:All messages: TransactionEventRequest- offline must be trueOne of the messages: TransactionRequest-eventType Ended</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 172. Test Case Id: TC_E_45_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Offline Behaviour - Stop transaction during offline period - Same GroupId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_45_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E08</td></tr><tr><td>Requirement(s)</td><td colspan="2">E08.FR.02,E08.FR.04,E08.FR.05,E08.FR.06,E08.FR.07,E08.FR.08</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station queues TransactionEvent messages to inform the CSMS that a transaction occurred while the Charging Station was Offline.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to queue TransactionEvent messages when the transaction stopped by an idToken with the same groupldToken, while the Charging Station was offline.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Authorization cache OR Local Authorization List.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">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></td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid idtoken fields2> with <Configured GroupldToken>
+IdTokenLocalAuthList for <Configured valid idtoken fields2> with <Configured GroupldToken></td></tr><tr><td colspan="2">Reusable State(s):
+State is Authorized with <Configured GroupldToken>
+Then proceed to state EnergyTransferStarted</td></tr><tr><td rowspan="7">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td></td><td>1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Present <Configured valid idtoken fields2>.</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE.</td></tr><tr><td colspan="2">Manual Action: Drive EV out of parking bay. (Only needed if TxStopPoint is ParkingBayOccupancy)</td></tr><tr><td></td><td>2. The OCTT accepts the reconnection attempt from the Charging Station.</td></tr><tr><td>3. The Charging Stations sends a TransactionEventRequest
+Note(s):
+- The Charging Station will empty its Transaction message queue. This will contain one or more TransactionEventRequest messages</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3:
+All messages: TransactionEventRequest
+- offline must be true
+One of the messages: TransactionEventRequest
+- eventType Ended</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+NOTE If the Charging Station supports ISO15118, this testcase needs to be executed using EIM.
+
+Table 173. Test Case Id: TC_E_46_CS
+
+<table><tr><td>Test case name</td><td colspan="2">End of charging process 15118</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_46_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E15</td></tr><tr><td>Requirement(s)</td><td colspan="2">E15.FR.04, E15.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">After receiving a SessionStopReq(Terminate) message from the EV, the Charging Station informs the CSMS that the authorization of the charging session has been stopped (by the EV). Depending on TxStopPoint this will also end the transaction.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to inform the CSMS that authorization of the charging session has been stopped (by the EV) and depending on TxStopPoint end the transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note: The Charging Station receives a SessionStopReq(Terminate) message from the EV.</td></tr><tr><td>1. The Charging Station sends aTransactionEventRequest</td><td>2. The OCTT responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: TransactionEventRequestIf <Configured TxStopPoint> contains "Authorized" or "PowerPathClosed" or "EnergyTransfer":- eventType is Ended-triggerReason is StopAuthorized- transactionInfo.stoppedReason is StoppedByEV- transactionInfo.chargingState is EVConnectedIf <Configured TxStopPoint> does not contain "Authorized" or "PowerPathClosed" or "EnergyTransfer":- eventType is Updated-triggerReason = StopAuthorized- transactionInfo.chargingState is EVConnected</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+# 2.7. F Remote Control
+
+Table 174. Test Case Id: TC_F_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote start transaction - Cable plugin first</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F01</td></tr><tr><td>Requirement(s)</td><td colspan="2">F01.FR.03, F01.FR.04, F01.FR.05, F01.FR.13, F01.FR.17, F01.FR.19, F02.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first connect the EV and EVSE OR wait for/trigger a RequestStartTransactionRequest. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to start a charging session when the EV driver first connects the EV and EVSE, before receiving a RequestStartTransactionRequest message.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT have a cable lock, which prevents the EV driver to connect the EV and EVSE before authorization.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl_DISABLERemoteAuthorization is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized (remote)</td></tr><tr><td colspan="2">2. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 175. Test Case Id: TC_F_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote start transaction - Remote start first -authorizeRemoteStart is true</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F02</td></tr><tr><td>Requirement(s)</td><td colspan="2">F02.FR.01, F01.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first wait for/trigger a RequestStartTransactionRequest OR connect the EV and EVSE. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to start a charging session when the Charging Stations receives a RequestStartTransactionRequest message (while AuthorizationRemoteStart is true), before the EV driver connects the EV and EVSE (within the connectionTimeout). The Charging Station has to authorize beforehand like a local action to start a transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">-AuthEnabled is NOT implemented with mutability ReadOnly and the value set to false AND -AuthorizationRemoteStart is NOT implemented with mutability ReadOnly and the value set to false</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl AUTHEnabled is true (If implemented AND ReadWrite)
+AuthCtrl_DISABLERemoteAuthorization is false (If implemented)
+AuthorizationRemoteStart is true (If ReadWrite)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is ParkingBayOccupied (Optional state)</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized (remote)</td></tr><tr><td colspan="2">2. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 176. Test Case Id: TC_F_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote start transaction - Remote start first -authorizeRemoteStart is false</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F02</td></tr><tr><td>Requirement(s)</td><td colspan="2">F02.FR.01, F01.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first wait for/trigger a RequestStartTransactionRequest OR connect the EV and EVSE. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to start a charging session when the Charging Stations receives a RequestStartTransactionRequest message (while AuthorizationRemoteStart is false), before the EV driver connects the EV and EVSE (within the connectionTimeout). The Charging station does NOT have to authorize beforehand like a local action to start a transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">AuthorizationRemoteStart is NOT implemented with mutability ReadOnly and the value set to true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl_DISABLERemoteAuthorization is false (If implemented)
+AuthorizationRemoteStart is false (If ReadWrite)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is ParkingBayOccupied (Optional state)</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized (remote)</td></tr><tr><td colspan="2">2. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 177. Test Case Id: TC_F_04_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote start transaction - Remote start first - Cable plugin timeout</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F02, E03</td></tr><tr><td>Requirement(s)</td><td colspan="2">F02.FR.01, E03.FR.01, E03.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first wait for/trigger a RequestStartTransactionRequest OR connect the EV and EVSE. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to deauthorize the transaction after the EVConnectionTimeout has been reached.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports TxCtrl.TxStartPoint ParkingBayOccupancy OR Authorized.</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+- TxCtrl.EVConnectionTimeOut is <Configured ev_connection_timeout>
+- AuthCtrl.AuthEnabled is true (If implemented AND ReadWrite)
+AuthCtrl.DisableRemoteAuthorization is false (If implemented)
+- TxCtrl.TxStartPoint is ParkingBayOccupancy OR Authorized</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is Authorized (remote)</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>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</td><td>2. The OCTT responds with a TransactionEventResponse</td></tr><tr><td colspan="2">Note(s): Optionally the Charging Station can send a StatusNotificationRequest or NotifyEventRequest with status Available</td></tr><tr><td colspan="2">3. Execute Reusable State Authorized (remote)
+Note(s):
+- This step is executed to verify if the EVSE is actually ready to start another charging session.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: TransactionEventRequest
+-triggerReason must be EVConnectTimeout
+-eventType must be Ended</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 178. Test Case Id: TC_F_05_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote unlock Connector - With ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_05_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F05</td></tr><tr><td>Requirement(s)</td><td colspan="2">F05.FR.01, F05.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an UnlockConnectorRequest to the charging station. It sometimes happens that a connector of a Charging Station socket does not unlock correctly. This happens most of the time when there is tension on the charging cable. This means the driver cannot unplug his charging cable from the Charging Station. To help a driver, the CSO can send a UnlockConnectorRequest to the Charging Station. The Charging Station will then try to unlock the connector again.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to ignore the UnlockConnectorRequest whith an ongoing transaction as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has a connector lock.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: Transaction is ongoing on <Configured Connector> State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UnlockConnectorResponse</td><td>1. The OCTT sends a UnlockConnectorRequest with evseld <Configured evseld> connectorId <Configured connectorId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message UnlockConnectorResponse - status OngoingAuthorizedTransaction</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 179. Test Case Id: TC_F_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote unlock Connector - Without ongoing transaction - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_06_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F05</td></tr><tr><td>Requirement(s)</td><td colspan="2">F05.FR.01, F05.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an UnlockConnectorRequest to the charging station. It sometimes happens that a connector of a Charging Station socket does not unlock correctly. This happens most of the time when there is tension on the charging cable. This means the driver cannot unplug his charging cable from the Charging Station. To help a driver, the CSO can send a UnlockConnectorRequest to the Charging Station. The Charging Station will then try to unlock the connector again.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to successfully unlock a connector without ongoing transaction as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has a connector lock.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UnlockConnectorResponse</td><td>1. The OCTT sends a UnlockConnectorRequest with evseld <Configured evseld> connectorId <Configured connectorId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message UnlockConnectorResponse - status Unlocked</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 180. Test Case Id: TC_F_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote unlock Connector - Without ongoing transaction - No cable connected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F05</td></tr><tr><td>Requirement(s)</td><td colspan="2">F05.FR.01, F05.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an UnlockConnectorRequest to the charging station. It sometimes happens that a connector of a Charging Station socket does not unlock correctly. This happens most of the time when there is tension on the charging cable. This means the driver cannot unplug his charging cable from the Charging Station. To help a driver, the CSO can send a UnlockConnectorRequest to the Charging Station. The Charging Station will then try to unlock the connector again.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Margin Station is able to perform the remote unlock connector mechanism and report the result without ongoing transaction while no cable is connected as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has a connector lock.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: No cable connected at <Configured Connector></td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UnlockConnectorResponse</td><td>1. The OCTT sends a UnlockConnectorRequest with evseld <Configured evseld> connectorId <Configured connectorId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message UnlockConnectorResponse - status Unlocked</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 181. Test Case Id: TC_F_08_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote stop transaction - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_08_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F03</td></tr><tr><td>Requirement(s)</td><td colspan="2">F03.FR.02, F03.FR.03, F03.FR.07, F03.FR.09</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to stop a charging session remotely by sending a RequestStopTransactionRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to stop a charging session when it receives a RequestStopTransactionRequest message.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State StopAuthorized (remote)</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 182. Test Case Id: TC_F_09_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote stop transaction - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_09_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F03</td></tr><tr><td>Requirement(s)</td><td colspan="2">F03.FR.08</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to stop a charging session remotely by sending a RequestStopTransactionRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station will reject a RequestStopTransactionRequest message, if it contains a transactionId that cannot be matched to an active transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a RequestStopTransactionResponse</td><td>1. The OCTT sends a RequestStopTransactionRequest with transactionId <Different transactionId than provided by the Charging Station in TransactionEventRequest></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: RequestStopTransactionResponse - status must be Rejected</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 183. Test Case Id: TC_F_10_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote unlock Connector - Without ongoing transaction - UnknownConnector</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_10_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F05</td></tr><tr><td>Requirement(s)</td><td colspan="2">F05.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an UnlockConnectorRequest to the charging station. It sometimes happens that a connector of a Charging Station socket does not unlock correctly. This happens most of the time when there is tension on the charging cable. This means the driver cannot unplug his charging cable from the Charging Station. To help a driver, the CSO can send a UnlockConnectorRequest to the Charging Station. The Charging Station will then try to unlock the connector again.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond with a UnlockConnectorRequest with status UnknownConnector when the requested connector is unknown as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has a connector lock.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UnlockConnectorResponse</td><td>1. The OCTT sends a UnlockConnectorRequest with evseld <Configured evseld> connectorId 999</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message UnlockConnectorResponse - status UnknownConnector</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 184. Test Case Id: TC_F_11_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - MeterValues - Specific EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_11_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.02,F06.FR.04,F06.FR.05,F06.FR.06,F06.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a MeterValuesRequest message for a specific EVSE, after receiving a TriggerMessageRequest message.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending MeterValues triggered by a TriggerMessageRequest.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequestWith requestedMessage MeterValuesevse.id<Configured evseld></td></tr><tr><td>3. The Charging Station sends aMeterValuesRequest</td><td>4. The OCTT responds with a MeterValuesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: TriggerMessageResponse- status must be Accepted* Step 3:Message: MeterValuesRequest- evseld must be<Configured evseld>- meterValue[0].sampledValue[0].context must be Trigger</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 185. Test Case Id: TC_F_12_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - MeterValues - All EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_12_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.04,F06.FR.05,F06.FR.06,F06.FR.10,F06.FR.11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a MeterValuesRequest message for all EVSE, after receiving a TriggerMessageRequest message.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending MeterValues triggered by a TriggerMessageRequest.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequestWith requestedMessage MeterValuesevse is omitted</td></tr><tr><td>3. The Charging Station sends aMeterValuesRequestNote(s):- This step needs to be executed for every EVSE.</td><td>4. The OCTT responds with a MeterValuesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: TriggerMessageResponse-status must be Accepted* Step 3:Message: MeterValuesRequest-meterValue[0].sampledValue[0].context must be Trigger</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 186. Test Case Id: TC_F_13_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - TransactionEvent - Specific EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_13_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.02,F06.FR.04,F06.FR.05,F06.FR.07,F06.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a TransactionRequest message for a specific EVSE, after receiving a TriggerMessageRequest message.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending TransactionEvents triggered by a TriggerMessageRequest.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequest With requestedMessage TransactionEvent evse.id <Configured evseld></td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: TriggerMessageResponse - status must be Accepted * Step 3: Message: TransactionEventRequest - evse.id must be omitted or <Configured evseld> - triggerReason must be Trigger - transactionInfo.chargingState must be Charging - meterValue must be present - meterValue[0].sampledValue[0].context must be Trigger</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 187. Test Case Id: TC_F_14_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - TransactionEvent - All EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_14_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.04,F06.FR.05,F06.FR.07,F06.FR.10,F06.FR.11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a TransactionRequest message for all EVSE, after receiving a TriggerMessageRequest message.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending TransactionEvents triggered by a TriggerMessageRequest.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted for all EVSE</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequestWith requestedMessage TransactionEventevse is omitted</td></tr><tr><td>3. The Charging Station sends aTransactionRequestNote(s):- This step needs to be executed for every EVSE.</td><td>4. The OCTT responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: TriggerMessageResponse-status must be Accepted* Step 3:Message: TransactionRequest- evse.id must be <Configured evseld>- triggerReason must be Trigger- transactionInfo.chargingState must be Charging-meterValue must be present-meterValue[0].sampledValue[0].context must be Trigger</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 188. Test Case Id: TC_F_15_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - LogStatusNotification - Idle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_15_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.04,F06.FR.05,F06.FR.10,F06.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a LogStatusNotificationRequest with status Idle, after receiving a TriggerMessageRequest while NOT uploading a log file.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending LogStatusNotifications triggered by a TriggerMessageRequest.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequestWith requestedMessage LogStatusNotification</td></tr><tr><td>3. The Charging Station sends a LogStatusNotificationRequest</td><td>4. The OCTT responds with aLogStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: TriggerMessageResponse-status must be Accepted* Step 3:Message: LogStatusNotificationRequest-status must be Idle</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 189. Test Case Id: TC_F_16_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - LogStatusNotification - Uploading</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_16_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.04,F06.FR.05,F06.FR.10,F06.FR.14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a LogStatusNotificationRequest with status Uploading, after receiving a TriggerMessageRequest while uploading a log file.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending LogStatusNotifications triggered by a TriggerMessageRequest.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aGetLogResponse</td><td>1. The OCTT sends a GetLogRequestWith logType DiagnosticsLoglogremoteLocation is <Configured log_location></td></tr><tr><td>3. The Charging Station sends aLogStatusNotificationRequest</td><td>4. The OCTT responds with aLogStatusNotificationResponse</td></tr><tr><td>6. The Charging Station responds with aTriggerMessageResponse</td><td>5. The OCTT sends a TriggerMessageRequestWith requestedMessage LogStatusNotification</td></tr><tr><td>7. The Charging Station sends aLogStatusNotificationRequest</td><td>8. The OCTT responds with aLogStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: GetLogResponse*- status must be Accepted* Step 3:Message: LogStatusNotificationRequest*- status must be Uploading* Step 6:Message: TriggerMessageResponse*- status must be Accepted* Step 7:Message: LogStatusNotificationRequest*- status must be Uploading</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 190. Test Case Id: TC_F_17_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - FirmwareStatusNotification - Specific EVSE not relevant</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_17_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.03,F06.FR.04,F06.FR.05,F06.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a FirmwareStatusNotificationRequest, after receiving a TriggerMessageRequest even when the CSMS an evseld which is not relevant for the requestedMessage FirmwareStatusNotification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending FirmwareStatusNotifications triggered by a TriggerMessageRequest.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequest With requestedMessage FirmwareStatusNotification evse.id is <Configured evseld></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequest</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: TriggerMessageResponse - status must be Accepted * Step 3: Message: FirmwareStatusNotificationRequest - status must be Idle</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 191. Test Case Id: TC_F_18_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - FirmwareStatusNotification - Idle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_18_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.04,F06.FR.05,F06.FR.10,F06.FR.16,L01.FR.25</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a FirmwareStatusNotificationRequest with status Idle, after receiving a TriggerMessageRequest while NOT downloading a firmware file.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending FirmwareStatusNotifications triggered by a TriggerMessageRequest.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequestWith requestedMessage FirmwareStatusNotification</td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequest</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: TriggerMessageResponse-status must be Accepted* Step 3:Message: FirmwareStatusNotificationRequest-status must be Idle</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 192. Test Case Id: TC_F_19_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - FirmwareStatusNotification - Downloading</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_19_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.04,F06.FR.05,F06.FR.10,L01.FR.26</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a FirmwareStatusNotificationRequest with status Downloading, after receiving a TriggerMessageRequest while downloading a firmware file.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending FirmwareStatusNotifications triggered by a TriggerMessageRequest.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponse</td><td>1. The OCTT sends a UpdateFirmwareRequest firmware.location is <Configured firmware_location> firmware.retrieveDateTime is <Current dateTime - 2 hours> firmware.installDateTime is omitted firmware/signingCertificate is <Configured signingCertificate> firmware!' signature is <Configured signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequest</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>6. The Charging Station responds with a TriggerMessageResponse</td><td>5. The OCTT sends a TriggerMessageRequest With requestedMessage FirmwareStatusNotification</td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequest</td><td>8. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: UpdateFirmwareResponse - status must be Accepted * Step 3: Message: FirmwareStatusNotificationRequest - status must be Downloading * Step 6: Message: TriggerMessageResponse - status must be Accepted * Step 7: Message: FirmwareStatusNotificationRequest - status must be Downloading</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 193. Test Case Id: TC_F_20_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - Heartbeat</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_20_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.04,F06.FR.05,F06.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a HeartbeatRequest, after receiving a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending Heartbeats triggered by a TriggerMessageRequest.</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequest With requestedMessage Heartbeat</td></tr><tr><td>3. The Charging Station sends a HeartbeatRequest</td><td>4. The OCTT responds with a HeartbeatResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: TriggerMessageResponse - status must be Accepted</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 194. Test Case Id: TC_F_23_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - StatusNotification - Specific EVSE - Available</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_23_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.02,F06.FR.04,F06.FR.05,F06.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a StatusNotificationRequest message for a specific available EVSE/Connector, after receiving a TriggerMessageRequest message.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending StatusNotifications triggered by a TriggerMessageRequest.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequestWith requestedMessage StatusNotificationevse.id<Configured evseld>evseconnectorId<Configured connectorId></td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of the connector.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: TriggerMessageResponse- status must be Accepted* Step 3:Message: StatusNotificationRequest- connectorStatus AvailableMessage: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Available"- eventData[0].component.name "Connector"- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 195. Test Case Id: TC_F_24_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - StatusNotification - Specific EVSE - Occupied</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_24_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.02,F06.FR.04,F06.FR.05,F06.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send a StatusNotificationRequest message for a specific occupied EVSE/Connector, after receiving a TriggerMessageRequest message.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending StatusNotifications triggered by a TriggerMessageRequest.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequestWith requestedMessage StatusNotificationevse.id<Configured evseld>evseconnectorId<Configured connectorId></td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of the connector.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: TriggerMessageResponse- status must be Accepted* Step 3:Message: StatusNotificationRequest- connectorStatus OccupiedMessage: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Occupied"- eventData[0].component.name "Connector"- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 196. Test Case Id: TC_F_26_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - BootNotification - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_26_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.04,F06.FR.05,F06.FR.17</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station rejects resending a BootNotificationRequest, when it has already received an accepted on a previously sent BootNotification, after receiving a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports sending BootNotification triggered by a TriggerMessageRequest.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequestWith requestedMessage BootNotification</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: TriggerMessageResponse-status must be Rejected</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 197. Test Case Id: TC_F_27_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - NotImplemented</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_27_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.08</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to report it has not implemented sending a SignCombinedCertificateRequest, after receiving a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station does NOT support sending SignCombinedCertificates triggered by a TriggerMessageRequest.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequest With requestedMessage SignCombinedCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: TriggerMessageResponse - status must be NotImplemented</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+# 2.8. G Availability
+
+Table 198. Test Case Id: TC_G_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Connector status Notification - Available to Occupied</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G01, N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">G01.FR.01, N07.FR.19</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">A Charging Station sends a notification to the CSMS to inform the CSMS about a Connector status change. This can be done in two ways. Via a StatusNotificationRequest or a NotifyEventRequest from the device model.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to report that its connector is Occupied.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVConnectedPreSession</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 199. Test Case Id: TC_G_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Connector status Notification - Occupied to Available</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G01, N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">G01.FR.01, N07.FR.19</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">A Charging Station sends a notification to the CSMS to inform the CSMS about a Connector status change. This can be done in two ways. Via a StatusNotificationRequest or a NotifyEventRequest from the device model.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to report that its connector is Available_.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE.</td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of the connector.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3:
+Message: StatusNotificationRequest
+- connectorStatus Available
+Message: NotifyEventRequest
+-eventData[0].trigger Delta
+-eventData[0].actualValue "Available"
+-eventData[0].component.name "Connector"
+-eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 200. Test Case Id: TC_G_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability EVSE - Operative to inoperative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">G03.FR.01, G03.FR.02, G03.FR.04, G03.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Operative to Inoperative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Unavailable for <Configured evseld></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- A message to report the state of a connector has been received for all connectors belonging to the specified EVSE.</td></tr></table>
+
+Table 201. Test Case Id: TC_G_04_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability EVSE - Inoperative to operative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">G03.FR.01, G03.FR.02, G03.FR.04, G03.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Inoperative to Operative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Unavailable for <Configured evseld></td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Operative and evse.id <Configured evseld></td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of all connectors belonging to the specified EVSE (and optionally also from the EVSE itself).</td><td>4. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message ChangeAvailabilityResponse- status Accepted* Step 3:Message: StatusNotificationRequest- connectorStatus Available- evseld <Configured evseld>Message: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Available"- eventData[0].component.name "EVSE" / Connector-eventData[0].component.evse.id <Configured evseld>- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:- A message to report the state of a connector has been received for all connectors belonging to the specified EVSE.</td></tr></table>
+
+Table 202. Test Case Id: TC_G_05_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Charging Station - Operative to inoperative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_05_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G04</td></tr><tr><td>Requirement(s)</td><td colspan="2">G04.FR.01, G04.FR.02, G04.FR.03, G04.FR.05, G04.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to change the availability from operative to inoperative.A Charging Station is considered Operative when it is charging or ready for charging.A Charging Station is considered Inoperative when it does not allow any charging.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Unavailable</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 203. Test Case Id: TC_G_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Charging Station - Inoperative to operative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_06_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G04</td></tr><tr><td>Requirement(s)</td><td colspan="2">G04.FR.01, G04.FR.02, G04.FR.03, G04.FR.05, G04.FR.08</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to change the availability from imperative to operative.A Charging Station is considered Operative when it is charging or ready for charging.A Charging Station is considered Inoperative when it does not allow any charging.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is Unavailable</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Operative</td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of all its connectors (and optionally also the Charging Station itself and all EVSE).</td><td>4. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message ChangeAvailabilityResponse- status Accepted* Step 3:Message: StatusNotificationRequest- connectorStatus AvailableMessage: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Available"- eventData[0].component.name "ChargingStation" / EVSE / Connector-eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 204. Test Case Id: TC_G_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Connector - Operative to inoperative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">G03.FR.01, G03.FR.02, G03.FR.04, G03.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the Connectors of one EVSE from Operative to Inoperative. A Connector is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Unavailable for <Configured connectorld></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: - A message to report the state of the connector has been received.</td></tr></table>
+
+Table 205. Test Case Id: TC_G_08_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Connector - Inoperative to operative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_08_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">G03.FR.01, G03.FR.02, G03.FR.04, G03.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the Connectors from one EVSE from Inoperative to Operative. A Connector is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: Unavailable for <Configured connectorId></td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Operative and evse.id <Configured evseld> and evseconnectorId <Configured connectorId></td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of the connectors.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message ChangeAvailabilityResponse - status Accepted * Step 3: Message: StatusNotificationRequest - connectorStatus Available - evseld <Configured evseld> - connectorId <Configured connectorId> Message: NotifyEventRequest - eventData[0].trigger Delta - eventData[0].actualValue "Available" - eventData[0].component.name "Connector" - eventData[0].component.evse.id <Configured evseld> - eventData[0].component.evseconnectorId <Configured connectorId> - eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations: - A message to report the state of the connector has been received.</td></tr></table>
+
+Table 206. Test Case Id: TC_G_09_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability EVSE - Operative to operative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_09_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">G03.FR.01, G03.FR.02, G03.FR.03, G03.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Operative to Operative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability from Operative to Operative according to the mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Operativeand evse.id<Configured evseld></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message ChangeAvailabilityResponse-status Accepted</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 207. Test Case Id: TC_G_10_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability EVSE - Inoperative to inoperative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_10_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">G03.FR.01, G03.FR.02, G03.FR.03, G03.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Inoperative to Inoperative. An EVSE is considered Inoperative in status Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability from inoperative to inoperative according to the mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: State is Unavailable for <Configured evseld></td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Inoperative and evse.id <Configured evseld></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message ChangeAvailabilityResponse - status Accepted</td></tr><tr><td colspan="2">Post scenario validations: - A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 208. Test Case Id: TC_G_11_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability EVSE - With ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_11_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">G03.FR.01, G03.FR.02, G03.FR.04, G03.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Operative to Inoperative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability during a transaction according to the mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+State is EnergyTransferStarted</td></tr><tr><td rowspan="12">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Inoperative and evse.id <Configured evseld></td></tr><tr><td colspan="2">Note(s): Wait for <Configured Transaction Duration></td></tr><tr><td colspan="2">3. Execute Reusable State StopAuthorized</td></tr><tr><td>4. The Charging Station notifies the CSMS about the current state of the connectors of the configured evse.</td><td>5. The OCTT responds accordingly.</td></tr><tr><td colspan="2">6. Execute Reusable State EVConnectedPostSession</td></tr><tr><td>7. The Charging Station notifies the CSMS about the current state of the connectors of the configured evse.</td><td>8. The OCTT responds accordingly.</td></tr><tr><td colspan="2">9. Execute Reusable State EVDisconnected</td></tr><tr><td>10. The Charging Station notifies the CSMS about the current state of the connectors of the configured evse.</td><td>11. The OCTT responds accordingly.</td></tr><tr><td colspan="2">12. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td>13. The Charging Station notifies the CSMS about the current state of the connectors of the configured evse.</td><td>14. The OCTT responds accordingly.</td></tr><tr><td colspan="2">Note(s): Steps 4, 5, 7, 8, 10, 11, 13, and 14 will only be executed if the previous step ended the transaction</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message ChangeAvailabilityResponse
+- status Scheduled
+* Step 4, 7, 10, 13:
+Message: StatusNotificationRequest
+- connectorStatus Unavailable
+- evseld <Configured evseld>
+Message: NotifyEventRequest
+- eventData[0].trigger Delta
+- eventData[0].actualValue "Unavailable"
+- eventData[0].component.name "Connector"
+- eventData[0].component.evse.id <Configured evseld>
+- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:
+- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 209. Test Case Id: TC_G_12_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Charging Station - Operative to operative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_12_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G04</td></tr><tr><td>Requirement(s)</td><td colspan="2">G04.FR.01, G04.FR.02, G04.FR.03, G04.FR.04, G04.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to change the availability from inoperative to operative.A Charging Station is considered Operative when it is charging or ready for charging.A Charging Station is considered Inoperative when it does not allow any charging.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability from operative to operative according to the mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Operative</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message ChangeAvailabilityResponse-status Accepted</td></tr><tr><td colspan="2">Post scenario validations:- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 210. Test Case Id: TC_G_13_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Charging Station - Inoperative to inoperative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_13_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G04</td></tr><tr><td>Requirement(s)</td><td colspan="2">G04.FR.01, G04.FR.02, G04.FR.03, G04.FR.04, G04.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to change the availability from operative to inoperative.A Charging Station is considered Operative when it is charging or ready for charging.A Charging Station is considered Inoperative when it does not allow any charging.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability from Inoperative to Inoperative according to the mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:State is Unavailable</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Inoperative</td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message ChangeAvailabilityResponse-status Accepted* Step 3:Message: StatusNotificationRequest- connectorStatus UnavailableMessage: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Unavailable"- eventData[0].component.name "ChargingStation"- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 211. Test Case Id: TC_G_14_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Charging Station - With ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_14_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G04</td></tr><tr><td>Requirement(s)</td><td colspan="2">G04.FR.01, G04.FR.02, G04.FR.03, G04.FR.05, G04.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Operative to Inoperative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability during a transaction according to the mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:State is EnergyTransferStarted</td></tr><tr><td rowspan="13">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Inoperative</td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of the connectors of the EVSEs that do not have an active transaction.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td colspan="2">Note(s): Wait for <Configured Transaction Duration></td></tr><tr><td colspan="2">5. Execute Reusable State StopAuthorized</td></tr><tr><td>6. The Charging Station notifies the CSMS about the current state of the connectors of the configured evse.</td><td>7. The OCTT responds accordingly.</td></tr><tr><td colspan="2">8. Execute Reusable State EVConnectedPostSession</td></tr><tr><td>9. The Charging Station notifies the CSMS about the current state of the connectors of the configured evse.</td><td>10. The OCTT responds accordingly.</td></tr><tr><td colspan="2">11. Execute Reusable State EVDisconnected</td></tr><tr><td>12. The Charging Station notifies the CSMS about the current state of the connectors of the configured evse.</td><td>13. The OCTT responds accordingly.</td></tr><tr><td colspan="2">14. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td>15. The Charging Station notifies the CSMS about the current state of the connectors of the configured evse.</td><td>16. The OCTT responds accordingly.</td></tr><tr><td colspan="2">Note(s): Steps 6, 7, 9, 10, 12, 13, 15, and 16 will only be executed if the previous step ended the transaction</td></tr><tr><td>Test case name</td><td>Change Availability Charging Station - With ongoing transaction</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message ChangeAvailabilityResponse
+- status Scheduled
+* Step 7:
+Message: StatusNotificationRequest
+- connectorStatus Unavailable
+- evseld not 0
+- connectorId not 0
+Message: NotifyEventRequest
+- eventData[0].trigger Delta
+- eventData[0].actualValue "Unavailable"
+- eventData[0].component.name "Connector"
+- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td>Post scenario validations:
+- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 212. Test Case Id: TC_G_15_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Connector - Operative to operative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_15_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">G03.FR.01, G03.FR.02, G03.FR.03, G03.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Operative to Inoperative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability from Operative to Operative of one connector according to the mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Operativeand evse.id<Configured evseld>and evseconnectorld<Configured connectorId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message ChangeAvailabilityResponse- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 213. Test Case Id: TC_G_16_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Connector - Inoperative to inoperative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_16_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">G03.FR.01, G03.FR.02, G03.FR.03, G03.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Operative to Inoperative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability from inoperative to inoperative on one connector according to the mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:State is Unavailable</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Inoperativeand evse.id<Configured evseld>and evseconnectorld<Configured connectorId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message ChangeAvailabilityResponse- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 214. Test Case Id: TC_G_17_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Connector - With ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_17_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">G03.FR.01, G03.FR.02, G03.FR.04, G03.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Operative to Inoperative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform the change availability during a transaction according to the mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: State is EnergyTransferStarted</td></tr><tr><td rowspan="12">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Inoperative and evse.id <Configured evseld> and evseconnectorId <Configured connectorId></td></tr><tr><td colspan="2">Note(s): Wait for <Configured Transaction Duration></td></tr><tr><td colspan="2">3. Execute Reusable State StopAuthorized</td></tr><tr><td>4. The Charging Station notifies the CSMS about the current state of the connectors of the configured evse.</td><td>5. The OCTT responds accordingly.</td></tr><tr><td colspan="2">6. Execute Reusable State EVConnectedPostSession</td></tr><tr><td>7. The Charging Station notifies the CSMS about the current state of the connectors of the configured evse.</td><td>8. The OCTT responds accordingly.</td></tr><tr><td colspan="2">9. Execute Reusable State EVDisconnected</td></tr><tr><td>10. The Charging Station notifies the CSMS about the current state of the connectors of the configured evse.</td><td>11. The OCTT responds accordingly.</td></tr><tr><td colspan="2">12. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td>13. The Charging Station notifies the CSMS about the current state of the connectors of the configured evse.</td><td>14. The OCTT responds accordingly.</td></tr><tr><td colspan="2">Note(s): Steps 4, 5, 7, 8, 10, 11, 13, and 14 will only be executed if the previous step ended the transaction</td></tr><tr><td>Test case name</td><td>Change Availability Connector - With ongoing transaction</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message ChangeAvailabilityResponse
+- status Scheduled
+* Step 7:
+Message: StatusNotificationRequest
+- connectorStatus Unavailable
+- evseld <Configured evseld>
+- connectorId <Configured connectorId>
+Message: NotifyEventRequest
+- eventData[0].trigger Delta
+- eventData[0].actualValue "Unavailable"
+- eventData[0].component.name "Connector"
+- eventData[0].component.evse not omit
+- eventData[0].component.evse.id <Configured evseld>
+- eventData[0].component.evseconnectorId <Configured connectorId>
+- eventData[0].variable.name "AvailabilityState"</td></tr><tr><td>Post scenario validations:
+- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 215. Test Case Id: TC_G_18_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability EVSE - state persists across reboot</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_18_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">G03.FR.08. G01.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Operative to Inoperative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station sets the availability persistent across reboot/power loss as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: state is Unavailable</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Inoperative AND evse.id <Configured evseld></td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td colspan="2">5. Execute Reusable State Booted Note(s): -After booting the charging station should send the following status: Message: StatusNotificationRequest -connectorStatus Unavailable -evseld <Configured evseld> Message: NotifyEventRequest -eventData[0].trigger Delta -eventData[0].actualValue "Unavailable" -eventData[0].component.name "Connector" -eventData[0].component.evseld.id <Configured evseld> -eventData[0].variable.name "AvailabilityState"</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message ChangeAvailabilityResponse -status Accepted * Step 3: Message: StatusNotificationRequest -evseld not 0 -connectorid not 0 -connectorStatus Unavailable for evseld <Configured evseld> -connectorStatus Available for evseld not <Configured evseld> Message: NotifyEventRequest -eventData[0].actualValue Unavailable for evseld <Configured evseld> -eventData[0].actualValue Available for evseld not <Configured evseld></td></tr><tr><td colspan="2">Post scenario validations: -A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 216. Test Case Id: TC_G_19_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Connector - state persists across reboot</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_19_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">G03.FR.08</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the Connectors of one EVSE from Operative to Inoperative. A Connector is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station sets the availability persistent across reboot/power loss as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: state is Unavailable</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Booting</td></tr><tr><td>2. The Charging Station sends a BootNotificationRequest</td><td>3. The OCTT responds with a BootNotificationResponse.</td></tr><tr><td>4. The Charging Station reports the status of all its connectors.</td><td>5. The OCTT responds accordingly.</td></tr><tr><td>6. The Charging Station sends a SecurityEventNotificationRequest</td><td>7. The OCTT responds with a SecurityEventNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 4: Message: StatusNotificationRequest - evseld not 0 - connectorld not 0 - connectorStatus Unavailable for evseld <Configured evseld> and for connectorld <Configured Connectorld> - connectorStatus Available for evseld not <Configured evseld> and for connectorld <Configured Connectorld> Message: NotifyEventRequest - eventData[0].actualValue Unavailable for evseld <Configured evseld> and for connectorld <Configured Connectorld> - eventData[0].actualValue Available for evseld not <Configured evseld> and for connectorld <Configured Connectorld> * Step 6: Message: SecurityEventNotificationRequest - type "StartupOfTheDevice" or type "ResetOrReboot"</td></tr><tr><td colspan="2">Post scenario validations: - A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 217. Test Case Id: TC_G_20_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Connector status Notification - Lock Failure</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_20_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G05</td></tr><tr><td>Requirement(s)</td><td colspan="2">G05.FR.01, G05.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is prevented from starting a charge session at the Charging Station while the Connector is not locked properly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station does not start charging and notifies the CSMS when a connector is not locked properly as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- Charging Station has the ConnectorPlugRetentionLock component defined in its Device Model.
+- MonitoringLevel is set to a level that a connector lock event failure will be reported.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+State is EVConnectedPreSession
+Note(s):
+- Cable should not be fully plugged in so it cannot lock properly</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized</td></tr><tr><td>2. The Charging Station sends a NotifyEventRequest</td><td>3. The OCTT responds with a NotifyResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: NotifyEventRequest
+-eventData[0].trigger Delta
+-eventData[0].component.name "ConnectorPlugRetentionLock"
+-eventData[0].variable.name "Problem"
+-eventData[0].actualValue "true"</td></tr><tr><td colspan="2">Post scenario validations:
+- The charging station did not start charging</td></tr></table>
+
+Table 218. Test Case Id: TC_G_21_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Charging Station - state persists across reboot</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_21_CS</td></tr><tr><td>Use case ld(s)</td><td colspan="2">G04</td></tr><tr><td>Requirement(s)</td><td colspan="2">G04.FR.09</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability from Operative to Inoperative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station sets the availability persistent across reboot/power loss as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:State is Unavailable</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Booting</td></tr><tr><td>2. The Charging Station sends aBootNotificationRequest.</td><td>3. The OCTT responds with aBootNotificationResponse.</td></tr><tr><td>4. The Charging Station reports the status of all its connectors.</td><td>5. The OCTT responds accordingly.</td></tr><tr><td>6. The Charging Station sends aSecurityEventNotificationRequest</td><td>7. The OCTT responds with aSecurityEventNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 4:Message: StatusNotificationRequest- evseld not 0- connectorId not 0- connectorStatus UnavailableMessage: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Unavailable"- eventData[0].variable.name "AvailabilityState"* Step 6:Message: SecurityEventNotificationRequest-type "StartupOfTheDevice" or type "ResetOrReboot"</td></tr><tr><td colspan="2">Post scenario validations:- A message to report the state of a connector has been received for all connectors.</td></tr></table>
+
+# 2.9. H Reservation
+
+Table 219. Test Case Id: TC_H_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Accepted - Valid idToken</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S2), H03</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.15, H03.FR.01, H03.FR.09, H03.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve a specific EVSE for a specific IdToken by sending a ReserveNowRequest containing an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reserve a specific EVSE, until the EV Driver with the specified IdToken arrives.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrlr.ReservationAvailable is implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:ReservationCtrlr.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Reserved for <Configured evseld></td></tr><tr><td colspan="2">2. Execute Reusable State AuthorizedNote(s):- <Configured valid idToken fields> are used for the authorization.</td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:After authorization, connector status must change from Reserved to AvailableMessage: StatusNotificationRequest- evseld <configured evseld>- connectorId <configured connectorId>- connectorStatus must be AvailableMessage: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Available-eventData[0].component.name must be Connector-eventData[0].variable.name must be AvailabilityState- evse.id <configured evseld>- connector.id <configured connectorId></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 220. Test Case Id: TC_H_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Accepted - Different idToken</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S2), H03</td></tr><tr><td>Requirement(s)</td><td colspan="2">H03.FR.01, F01.FR.22</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve a specific EVSE for a specific IdToken by sending a ReserveNowRequest containing an evseld.Starting a transaction can be done in two ways (this is configurable by the OCTT; A. Using local authorization B. Using a RequestStartTransactionRequest</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station rejects all idToken, except the one specified for the reserved EVSE. EV is plugged in before authorization to check that station is able to handle this correctly. When TxStartPoint contains EVConnected this triggers starting of a transaction, but charging must not be allowed when idToken does not match reservation.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrlr.ReservationAvailable is implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:ReservationCtrlr.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is <Configured evseld> is Reserved for <Configured valid_idtoken1_idtoken>State is EVConnectedPreSession</td></tr><tr><td rowspan="4">Main A(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual action: Authorize with <Configured valid_idtoken2_idtoken>.</td></tr><tr><td colspan="2">Execute reusable state Authorized</td></tr><tr><td colspan="2">Note(s): The test is a PASS, if the OCTT does not receive an a TransactionEventRequest with chargingState = Charging within the configured messageTimeout.</td></tr><tr><td>Tool validations</td><td colspan="2">N/a</td></tr><tr><td rowspan="2">Main B(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a RequestStartTransactionResponse</td><td>1. The OCTT sends a RequestStartTransactionRequest with idToken.idToken<Configured valid_idtoken2_idtoken>idToken.type<Configured valid_idtoken2_type>evseld<Configured evseld></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: RequestStartTransactionResponse-status must be Rejected</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 221. Test Case Id: TC_H_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Occupied - EVSE Reserved</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S2)</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve a specific EVSE for a specific IdToken by sending a ReserveNowRequest containing an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond with status Occupied, when the requested EVSE is already reserved.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrl.ReservationAvailable is implemented with value true</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrl.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+<Configured evseld> is Reserved</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with evseld is <Configured evseld>
+idToken.idToken <Configured
+valid_idtoken2_idtoken>
+idToken.type <Configured valid_idtoken2_type></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: ReserveNowResponse
+- status must be Occupied</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 222. Test Case Id: TC_H_04_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Occupied - EVSE Occupied</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S2)</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve a specific EVSE for a specific IdToken by sending a ReserveNowRequest containing an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond with status Occupied, when the requested EVSE is occupied.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrl.ReservationAvailable is implemented with value true</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: ReservationCtrl.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State: State is EnergyTransferStarted</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with evseld is <Configured evseld> idToken.idToken <Configured valid_idtoken2_idtoken> idToken.type <Configured valid_idtoken2_type></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: ReserveNowResponse - status must be Occupied</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 223. Test Case Id: TC_H_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Unavailable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_06_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S2)</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve a specific EVSE for a specific IdToken by sending a ReserveNowRequest containing an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond with status Unavailable, when the requested EVSE is unavailable.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrl.ReservationAvailable is implemented with value true</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrl.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+<Configured evseld> is Unavailable</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with evseld is <Configured evseld>
+idToken.idToken <Configured
+valid_idtoken2_idtoken>
+idToken.type <Configured valid_idtoken2_type></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: ReserveNowResponse
+- status must be Unavailable</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 224. Test Case Id: TC_H_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Reservation Ended / not used</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S2), H04</td></tr><tr><td>Requirement(s)</td><td colspan="2">H04.FR.01,H04.FR.02,H04.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve a specific EVSE for a specific IdToken by sending a ReserveNowRequest containing an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to end the reservation, when the EV Driver with the specified IdToken arrives, does not arrive before the set expiryDateTime is reached.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrl.ReservationAvailable is implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:ReservationCtrl.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:<Configured evselD> is Reserved</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station notifies the CSMS about the status change of the connector.Note(s):- The OCTT expects that the Charging Station sets the availabilityState of the EVSE and corresponding connectors back to Available after the expiry time of 60 seconds is reached.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td>3. The Charging Station sends aReservationStatusUpdateRequest.</td><td>4. The OCTT responds with aReservationStatusUpdateResponse.</td></tr><tr><td colspan="2">5. Execute Reusable State AuthorizedNote(s):- <Configured valid idtoken fields2> are used for the authorization.</td></tr><tr><td colspan="2">6. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>Test case name</td><td>Reserve a specific EVSE - Reservation Ended / not used</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: StatusNotificationRequest
+- connectorStatus must be Available
+Message: NotifyEventRequest
+- eventData[0].trigger must be Delta
+- eventData[0].actualValue must be Available
+- eventData[0].component.name must be Connector
+- eventData[0].variable.name must be AvailabilityState
+(Reporting the AvailabilityState of the EVSE component itself is optional.)
+Message: NotifyEventRequest
+- eventData[0].trigger must be Delta
+- eventData[0].actualValue must be Available
+- eventData[0].component.name must be EVSE
+- eventData[0].variable.name must be AvailabilityState
+* Step 3:
+Message: ReservationStatusUpdateRequest
+- reservationId must be <Generated reservationId>
+- reservationUpdateStatus must be Expired</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 225. Test Case Id: TC_H_08_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve an unspecified EVSE - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_08_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S1), H03</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.04,H01.FR.07,H01.FR.15,H03.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an unspecified EVSE for a specific IdToken by sending a ReserveNowRequest without an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reserve an unspecified EVSE, until the EV Driver with the specified IdToken arrives.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The configuration variable ReservationCtrlr.ReservationAvailable is implemented with value true
+- The Charging Station has the configuration variable ReservationNonEvseSpecific implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrlr.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="5">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with evseld is Omitted
+idToken.idToken<Configured valid_idtoken_idtoken>
+idToken.type<Configured valid_idtoken_type></td></tr><tr><td>3. The Charging Station notifies the CSMS about the status change of the connector.
+Note(s):
+- If the Charging Station has only one EVSE, it sets the availabilityState of the EVSE and corresponding connectors to Reserved.
+- Reporting the AvailabilityState of the EVSE component itself is optional.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td colspan="2">3. Execute Reusable State Authorized
+Note(s):
+- <Configured valid idToken2 fields> are used for the authorization.</td></tr><tr><td colspan="2">4. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>Test case name</td><td>Reserve an unspecified EVSE - Accepted</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:Message: ReserveNowResponse- status must be Accepted* Step 3:Message: StatusNotificationRequest- connectorStatus must be Reserved- evseld must be <Configured evseld> - connectorld must be <Configured connectorId>Message: NotifyEventRequest- trigger must be Delta-actualValue must be "Reserved"- component.name must be "Connector"- evse.id must be <Configured evseld> - evesconnectorld must be <Configured connectorId> - variable.name must be "AvailabilityState"(Optional)Message: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Available-eventData[0].component.name must be EVSE-eventData[0].variable.name must be AvailabilityState</td></tr><tr><td>Post scenario validations:N/a</td></tr></table>
+
+Table 226. Test Case Id: TC_H_09_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve an unspecified EVSE - Occupied - EVSE Reserved</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_09_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S1)</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an unspecified EVSE for a specific IdToken by sending a ReserveNowRequest without an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond with status Occupied, when all EVSE are already reserved.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The configuration variable ReservationCtrlr.ReservationAvailable is implemented with value true
+- The Charging Station has the configuration variable ReservationNonEvseSpecific implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrlr.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+All EVSE are Reserved</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with evseld is Omitted
+idToken.idToken<Configured valid_idtoken_idtoken>
+idToken.type<Configured valid_idtoken_type></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: ReserveNowResponse
+- status must be Occupied</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 227. Test Case Id: TC_H_10_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve an unspecified EVSE - Occupied - EVSE Occupied</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_10_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S1)</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an unspecified EVSE for a specific IdToken by sending a ReserveNowRequest without an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond with status Occupied, when all EVSE are occupied.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The configuration variable ReservationCtrlr.ReservationAvailable is implemented with value true
+- The Charging Station has the configuration variable ReservationNonEvseSpecific implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrlr.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted for all EVSE</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with evseld is Omitted
+idToken.idToken<Configured valid_idtoken_idtoken>
+idToken.type<Configured valid_idtoken_type>
+expiryDateTime<Configured expiryDateTime></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: ReserveNowResponse
+- status must be Occupied</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 228. Test Case Id: TC_H_12_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve an unspecified EVSE - Unavailable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_12_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S1)</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an unspecified EVSE for a specific IdToken by sending a ReserveNowRequest without an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond with status Unavailable, when all EVSE are unavailable.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The configuration variable ReservationCtrlr.ReservationAvailable is implemented with value true
+- The Charging Station has the configuration variable ReservationNonEvseSpecific implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrlr.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+Charging Station is Unavailable</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with evseld is Omitted
+idToken.idToken<Configured valid_idtoken_idtoken>
+idToken.type<Configured valid_idtoken_type></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: ReserveNowResponse
+- status must be Unavailable</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 229. Test Case Id: TC_H_13_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve an unspecified EVSE - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_13_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S1)</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.19</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an unspecified EVSE for a specific IdToken by sending a ReserveNowRequest without an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond with status Rejected, when it does not support reserving an unspecified EVSE.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The configuration variable ReservationCtrlr.ReservationAvailable is implemented with value true
+- The Charging Station does NOT have the configuration variable ReservationNonEvseSpecific implemented OR the Charging Station does have it implemented with value false</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrlr.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with evseld is Omitted
+idToken.idToken<Configured valid_idtoken_idtoken>
+idToken.type<Configured valid_idtoken_type></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: ReserveNowResponse
+- status must be Rejected</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 230. Test Case Id: TC_H_14_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve an unspecified EVSE - Amount of EVSEs available equals the amount of reservations</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_14_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S1)</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.20</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an unspecified EVSE for a specific IdToken by sending a ReserveNowRequest without an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to set all available EVSE to reserved, when the amount of EVSEs available equals the amount of reservations.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The configuration variable ReservationCtrl.ReservationAvailable is implemented with value true
+- The Charging Station has the configuration variable ReservationNonEvseSpecific implemented with value true</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrl.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with evseld is Omitted idToken is <A different idToken for every reservation being made>
+Note(s):
+- This step will be executed the amount of times equal to the amount of EVSE the Charging Station has.</td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of all its connectors (and optionally also the state of all EVSE).</td><td>4. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: ReserveNowResponse
+- status must be Accepted
+* Step 3:
+Message: StatusNotificationRequest
+- connectorStatus must be Reserved
+Message: NotifyEventRequest
+-eventData[0].trigger must be Delta
+-eventData[0].actualValue must be Reserved
+-eventData[0].component.name must be Connector
+-eventData[0].variable.name must be AvailabilityState (Optional)
+Message: NotifyEventRequest
+-eventData[0].trigger must be Delta
+-eventData[0].actualValue must be Reserved
+-eventData[0].component.name must be EVSE
+-eventData[0].variable.name must be AvailabilityState</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 231. Test Case Id: TC_H_15_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a connector with a specific type - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_15_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S3), H03</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.06,H01.FR.09,H01.FR.15,H03.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an EVSE with a connector with a specific type for a specific IdToken by sending a ReserveNowRequest with a connectorType.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reserve an EVSE with a connector with a specific type, until the EV Driver with the specified IdToken arrives.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The configuration variable ReservationCtrlr.ReservationAvailable is implemented with value true
+- The Charging Station supports the reservation of a specific connector type.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrlr.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="5">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with connectorType is <Configured connectorType>
+idToken.idToken <Configured valid_idtoken_idtoken>
+idToken.type <Configured valid_idtoken_type></td></tr><tr><td>3. The Charging Station notifies the CSMS about the status change of the connector.
+Note(s):
+- If the Charging Station has only one available connector of the specified connectorType, it sets the availabilityState of the corresponding EVSE and all connectors of the specified type to Reserved.
+AND If the EVSE has more connector(s) with a different connectorType, the Charging Station must set these other connector(s) to Unavailable.
+- Reporting the AvailabilityState of the EVSE component itself is optional.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td colspan="2">5. Execute Reusable State Authorized
+Note(s):
+- <Configured valid idToken fields> are used for the authorization.</td></tr><tr><td colspan="2">6. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>Test case name</td><td>Reserve a connector with a specific type - Success</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:Message: ReserveNowResponse- status must be Accepted* Step 3:Message: StatusNotificationRequest- connectorStatus must be Reserved- evseld must be-configured evseld*- connectorld must be-configured connectorId*- Message: NotifyEventRequest- trigger must be Delta-actualValue must be "Reserved"- component.name must be "Connector"- evse.id must be-configured evseld>- eyesconnectorld must be-configured connectorId>- variable.name must be "AvailabilityState"(Optional)Message: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Available-eventData[0].component.name must be EVSE-eventData[0].variable.name must be AvailabilityState</td></tr><tr><td>Post scenario validations:N/a</td></tr></table>
+
+Table 232. Test Case Id: TC_H_16_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a connector with a specific type - Amount of available connectors of a type equals the amount of reservations</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_16_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S3)</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an EVSE with a connector with a specific type for a specific IdToken by sending a ReserveNowRequest with a connectorType.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reserve an EVSE with a connector with a specific type, until the EV Driver with the specified IdToken arrives.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The configuration variable ReservationCtrl.ReservationAvailable is implemented with value true
+- The Charging Station supports the reservation of a specific connector type.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrl.ReservationEnabled is true (If implemented)
+All EVSEs should be reserved</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with connectorType is <Configured connectorType>
+idToken.idToken <Configured valid_idtoken_idtoken>
+idToken.type <Configured valid_idtoken_type></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: ReserveNowResponse
+- status must be Occupied</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 233. Test Case Id: TC_H_17_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Cancel reservation of an EVSE - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_17_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H02</td></tr><tr><td>Requirement(s)</td><td colspan="2">H02.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to cancel a reservation by sending a CancelReservationRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to cancel a reservation when receiving a CancelReservationRequest from the CSMS.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrlr.ReservationAvailable is implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:ReservationCtrlr.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:<Configured evseld> is Reserved</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a CancelReservationResponse</td><td>1. The OCTT sends a CancelReservationRequest with reservationId is <Generated reservationId></td></tr><tr><td>3. The Charging Station notifies the CSMS about the status change of the connector.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: CancelReservationResponse- status must be Accepted* Step 3:Message: StatusNotificationRequest- connectorStatus must be Available- evseld must be <Configured evseld>- connectorId must be <Configured connectorId>Message: NotifyEventRequest- trigger must be Delta- actualValue must be "Available"- component.name must be "Connector"- evse.id must be <Configured evseld>- eyesconnectorId must be <Configured connectorId>- variable.name must be "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 234. Test Case Id: TC_H_18_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Cancel reservation of an EVSE - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_18_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H02</td></tr><tr><td>Requirement(s)</td><td colspan="2">H02.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to cancel a reservation by sending a CancelReservationRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reject a CancelReservationRequest, when there is no matching reservationId.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrl.ReservationAvailable is implemented with value true</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: ReservationCtrl.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a CancelReservationResponse</td><td>1. The OCTT sends a CancelReservationRequest with reservationId is 1</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: CancelReservationResponse - status must be Rejected</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 235. Test Case Id: TC_H_19_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Use a reserved EVSE with GroupId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_19_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01, H03</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.15,H03.FR.04,H03.FR.08</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an EVSE for a specific GroupIdToken by sending a ReserveNowRequest containing a groupIdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to accept an idToken with the same GroupIdToken as the idToken specified for the reservation.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrl.ReservationAvailable is implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrl.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with evseld is <Configured evseld>
+idToken.idToken <Configured valid_idtoken_idtoken>
+idToken.type <Configured valid_idtoken_type>
+groupIdToken.idToken is <Configured groupIdToken></td></tr><tr><td>3. The Charging Station notifies the CSMS about the status change of the connector.
+Note(s):
+- The OCTT expects that the Charging Station sets the availabilityState of the EVSE and corresponding connectors to Reserved.
+- Reporting the AvailabilityState of the EVSE component itself is optional.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td colspan="2">3. Execute Reusable State Authorized
+Note(s):
+- <Configured valid idtoken fields2> AND <Configured groupIdToken fields> are used for the authorization.</td></tr><tr><td colspan="2">4. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>Test case name</td><td>Reserve a specific EVSE - Use a reserved EVSE with Groupld</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:Message: ReserveNowResponse- status must be Accepted* Step 3:Message: StatusNotificationRequest- connectorStatus must be Reserved- evseld must be <Configured evseld> - connectorId must be <Configured connectorId>Message: NotifyEventRequest- trigger must be Delta-actualValue must be "Reserved"- component.name must be "Connector"- evse.id must be <Configured evseld>- evesconnectorId must be <Configured connectorId>- variable.name must be "AvailabilityState"(Optional)Message: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Reserved-eventData[0].component.name must be EVSE-eventData[0].variable.name must be AvailabilityState</td></tr><tr><td>Post scenario validations:N/a</td></tr></table>
+
+Table 236. Test Case Id: TC_H_21_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Charging Station cancels reservation when Unavailable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_21_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.17</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station will cancel reservations, when the EVSE specified for a reservation is set to an inoperative state.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station cancels the reservation, when the availability of the EVSE specified for the reservation is set to Inoperative.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrl.ReservationAvailable is implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:ReservationCtrl.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:<Configured evseld> is Reserved</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="8">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Inoperative and evse.id<Configured evseld></td></tr><tr><td>3. The Charging Station notifies the CSMS about the status change of the connector.Note(s):- This step needs to be executed for all connectors of the specified EVSE.- Reporting the AvailabilityState of the EVSE itself is optional.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td>5. The Charging Station sends a ReservationStatusUpdateRequest.</td><td>6. The OCTT responds with a ReservationStatusUpdateResponse.</td></tr><tr><td>8. The Charging Station responds with a ChangeAvailabilityResponse</td><td>7. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Operative and evse.id<Configured evseld></td></tr><tr><td>9. The Charging Station notifies the CSMS about the status change of the connector.Note(s):- This step needs to be executed for all connectors of the specified EVSE.- Reporting the AvailabilityState of the EVSE itself is optional.</td><td>10. The OCTT responds accordingly.</td></tr><tr><td colspan="2">11. Execute Reusable State AuthorizedNote(s):- <Configured valid idtoken fields2> are used for the authorization.</td></tr><tr><td colspan="2">12. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>Test case name</td><td>Charging Station cancels reservation when Unavailable</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:Message ChangeAvailabilityResponse- status Accepted* Step 3:Message: StatusNotificationRequest- connectorStatus must be UnavailableMessage: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Unavailable-eventData[0].component.name must be Connector-eventData[0].variable.name must be AvailabilityState(Reporting the AvailabilityState of the EVSE component itself is optional.)Message: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Unavailable-eventData[0].component.name must be EVSE-eventData[0].variable.name must be AvailabilityState* Step 5:Message: ReservationStatusUpdateRequest-reservationId must be <Generated reservationId>- reservationUpdateStatus must be Removed* Step 8:Message ChangeAvailabilityResponse-status Accepted* Step 9:Message: StatusNotificationRequest- connectorStatus must be AvailableMessage: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Available-eventData[0].component.name must be Connector-eventData[0].variable.name must be AvailabilityState(Reporting the AvailabilityState of the EVSE component itself is optional.)Message: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Available-eventData[0].component.name must be EVSE-eventData[0].variable.name must be AvailabilityState</td></tr><tr><td>Post scenario validations:N/a</td></tr></table>
+
+Table 237. Test Case Id: TC_H_22_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Configured to Reject</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_22_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve a specific EVSE for a specific IdToken by sending a ReserveNowRequest containing an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly respond when it is configured not to accept reservations.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrl.ReservationAvailable is implemented with value false</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrl.ReservationEnabled is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: ReserveNowResponse
+- status Rejected</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 238. Test Case Id: TC_H_23_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Replace reservation</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_23_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01</td></tr><tr><td>Requirement(s)</td><td colspan="2">H01.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve a specific EVSE for a specific IdToken by sending a ReserveNowRequest containing an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to replace a reservation of a specific EVSE, until the EV Driver with the specified IdToken arrives.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrl.ReservationAvailable is implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrl.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+A reservation is valid on <Configured evseld> with <Configured valid_idtoken></td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with id <Configured reservationId>
+evseld is <Configured evseld>
+idToken.idToken <Configured
+valid_idtoken_idtoken2>
+idToken.type <Configured valid_idtoken_type2></td></tr><tr><td colspan="2">3. Execute Reusable State Authorized
+Note(s):
+- <Configured valid idToken2 fields> are used for the authorization.</td></tr><tr><td colspan="2">4. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:
+Message: ReserveNowResponse
+- status must be Accepted
+* Step 3:
+Message: StatusNotificationRequest
+- connectorStatus must be Reserved
+- evseld must be <Specified evseld>
+- connectorld must be <Configured connectorId>
+Message: NotifyEventRequest
+- trigger must be Delta
+- actualValue must be "Reserved"
+- component.name must be "Connector"
+- evse.id must be <Specified evseld>
+- evesconnectorld must be <Configured connectorId>
+- variable.name must be "AvailabilityState"
+(Optional)
+Message: NotifyEventRequest
+- eventData[0].trigger must be Delta
+- eventData[0].actualValue must be Reserved
+- eventData[0].component.name must be EVSE
+- eventData[0].variable.name must be AvailabilityState</td></tr></table>
+
+Table 239. Test Case Id: TC_H_24_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve an unspecified EVSE - GroupIdToken</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_24_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H03</td></tr><tr><td>Requirement(s)</td><td colspan="2">H03.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve a specific EVSE for a specific IdToken by sending a ReserveNowRequest containing an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reserve a unspecific EVSE, until the EV Driver with the specified groupIdToken arrives.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configuration variable ReservationCtrlr.ReservationAvailable is implemented with value true</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+ReservationCtrlr.ReservationEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with idToken.idToken is <Configured valid_idtoken>
+groupIdToken.idToken is <Configured
+group_idtoken></td></tr><tr><td>3. The Charging Station notifies the CSMS about the status change of the connector. Note(s):
+- The OCTT expects that the Charging Station sets the availabilityState of the EVSE and corresponding connectors to Reserved.
+- Reporting the AvailabilityState of the EVSE component itself is optional.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td colspan="2">5. Execute Reusable State Authorized Note(s):
+- <Configured valid_idtoken2> is used for the authorization.</td></tr><tr><td colspan="2">6. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:
+Message: ReserveNowResponse
+-status must be Accepted
+* Step 3:
+Message: StatusNotificationRequest
+- connectorStatus must be Reserved
+Message: NotifyEventRequest
+-eventData[0].trigger must be Delta
+-eventData[0].actualValue must be Reserved
+-eventData[0].component.name must be Connector
+-eventData[0].variable.name must be AvailabilityState
+(Optional)
+Message: NotifyEventRequest
+-eventData[0].trigger must be Delta
+-eventData[0].actualValue must be Reserved
+-eventData[0].component.name must be EVSE
+-eventData[0].variable.name must be AvailabilityState</td></tr></table>
+
+# 2.10. I Tariff and Cost
+
+Table 240. Test Case Id: TC_I_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Show EV Driver running total cost during charging - costUpdatedRequest</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">I02</td></tr><tr><td>Requirement(s)</td><td colspan="2">I02.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">While a transaction is ongoing, the driver wants to know how much the running total cost is, updated at a relevant interval.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly display the running total cost as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Tariff Information</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EVConnectedPreSession</td></tr><tr><td rowspan="8">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with - idTokenInfo.status Accepted - idTokenInfo.personalMessage(content <Configured Cost></td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest Note(s): - This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy</td><td>4. The OCTT responds with a TransactionEventResponse with - idTokenInfo.status Accepted</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>6. The Charging Station sends an TransactionEventRequest</td><td>7. The OCTT responds with an TransactionEventResponse with - updatedPersonalMessage(content <Configured Cost></td></tr><tr><td>9. The Charging Station responds with a CostUpdatedResponse</td><td>8. The OCTT sends a CostUpdatedRequest with - totalCost <Configured Cost2> - transactionId <Configured transactionId></td></tr><tr><td colspan="2">Note(s): Step 6, 7, 8, and 9 are repeated n times</td></tr><tr><td>Test case name</td><td>Show EV Driver running total cost during charging - costUpdatedRequest</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+MessageauthorizeRequest
+- idToken.idToken<Configured valid_idtoken_idtoken>
+- idToken.type<Configured valid_idtoken_type>
+* Step 3:
+MessageTransactionEventRequest
+- triggerReason Authorized
+- idToken.idToken<Configured valid_idtoken_idtoken>
+- idToken.type<Configured valid_idtoken_type>
+if transaction was already started
+- eventType Updated
+else
+- eventType Started</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 241. Test Case Id: TC_I_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Show EV Driver Final Total Cost After Charging</td></tr><tr><td>Test case Id</td><td colspan="2">TC_I_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">I03</td></tr><tr><td>Requirement(s)</td><td colspan="2">I03.FR.01, I03.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">While a transaction is ongoing, the driver wants to know how much the running total cost is, updated at a relevant interval.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly display the total cost as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Tariff Information</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="6">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken</td></tr><tr><td colspan="2">1. Execute Reusable State StopAuthorized Note: IF Message TransactionEventRequest - eventType Ended THEN Message TransactionEventResponse - totalCost <Generated Cost></td></tr><tr><td colspan="2">2. Execute Reusable State EVConnectedPostSession Note: IF Message TransactionEventRequest - eventType Ended THEN Message TransactionEventResponse - totalCost <Generated Cost></td></tr><tr><td colspan="2">3. Execute Reusable State EVDisconnected Note: IF Message TransactionEventRequest - eventType Ended THEN Message TransactionEventResponse - totalCost <Generated Cost></td></tr><tr><td colspan="2">4. Execute Reusable State ParkingBayUnoccupied Note: IF Message TransactionEventRequest - eventType Ended THEN Message TransactionEventResponse - totalCost <Generated Cost></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 242. Test Case Id: TC_I_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Show EV Driver running total cost during charging - transactionResponse</td></tr><tr><td>Test case Id</td><td colspan="2">TC_I_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">I02</td></tr><tr><td>Requirement(s)</td><td colspan="2">I02.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">While a transaction is ongoing, the driver wants to know how much the running total cost is, updated at a relevant interval.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly display the running total cost as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Tariff Information</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EVConnectedPreSession</td></tr><tr><td rowspan="8">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with - idTokenInfo.status Accepted - idTokenInfo.personalMessage(content <Configured Cost></td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest Note(s): - This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy</td><td>4. The OCTT responds with a TransactionEventResponse with - idTokenInfo.status Accepted</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>6. The Charging Station sends an TransactionEventRequest</td><td>7. The OCTT responds with an TransactionEventResponse with - updatedPersonalMessage(content <Configured Cost></td></tr><tr><td>9. The Charging Station responds with a TransactionEventResponse</td><td>8. The OCTT sends a TransactionEventRequest with - totalCost <Configured Cost2> - transactionId <Configured transactionId></td></tr><tr><td colspan="2">Note(s): Step 6, 7, 8, and 9 are repeated n times</td></tr><tr><td>Test case name</td><td>Show EV Driver running total cost during charging - transactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+MessageauthorizeRequest
+- idToken.idToken<Configured valid_idtoken_idtoken>
+- idToken.type<Configured valid_idtoken_type>
+* Step 3:
+Message TransactionEventRequest
+- triggerReason Authorized
+- idToken.idToken<Configured valid_idtoken_idtoken>
+- idToken.type<Configured valid_idtoken_type>
+if transaction was already started
+- eventType Updated
+else
+- eventType Started</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+# 2.11. J MeterValues
+
+Table 243. Test Case Id: TC_J_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clock-aligned Meter Values - No transaction ongoing</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_01_CS</td></tr><tr><td>Use case ld(s)</td><td colspan="2">J01</td></tr><tr><td>Requirement(s)</td><td colspan="2">J01.FR.01,J01.FR.02,J01.FR.03,J01.FR.06,J01.FR.07,J01.FR.08,J01.FR.14,J01.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send clock-aligned Meter Values, when it is configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has an energy meter.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:AlignedDataInterval is <Configured clock-aligned Meter Values interval></td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station notifies the CSMS about its measured Meter Values.Note(s):- The Meter Value messages do NOT need to be send/received at the exact specified interval. The configured measurands must be measured at the configured interval.- Multiple Meter Value messages may be sent 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 (connectorId=0)- The OCTT will end the testcase after it has received three Meter Value messages.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* 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"></td></tr><tr><td colspan="2">Post scenario validations: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 (evseld=0). But the timestamp of these messages must all be the same.></td></tr></table>
+
+Table 244. Test Case Id: TC_J_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clock-aligned Meter Values - Transaction ongoing</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J01</td></tr><tr><td>Requirement(s)</td><td colspan="2">J01.FR.01,J01.FR.02,J01.FR.03,J01.FR.06,J01.FR.07,J01.FR.08,J01.FR.14,J01.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send clock-aligned Meter Values, while a transaction is ongoing, when it is configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has an energy meter.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+AlignedDataInterval is <Configured clock-aligned Meter Values interval>
+AlignedDataSendDuringIdle is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note(s):
+- The Charging Station can follow Steps 1 and 2 or Steps 3 and 4</td></tr><tr><td>1. The Charging Station notifies the CSMS about its measured Meter Values.
+Note(s):
+- During a transaction the MeterValueRequest can still be used to report meter values for the main power meter (evseld=0) and idle EVSEs
+- The Meter Value messages do NOT need to be send/received at the exact specified interval. The configured measurands must be measured at the configured interval.
+- Multiple Meter Value messages may be sent per configured interval, in case the amount of measured data is too much for one message.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td colspan="2">3. The Charging Station sends a TransactionEventRequest
+Note(s):
+- During a transaction the meter values for the configured EVSE with the ongoing transaction should be transmitted using the TransactionEventRequest.
+- The TransactionEventRequest messages do NOT need to be send/received at the exact specified interval. The configured measurands must be measured at the configured interval.
+- Multiple TransactionEventRequest messages may be sent per configured interval, in case the amount of measured data is too much for one message.
+- The OCTT will end the testcase after it has the <Configured transaction duration> is reached.</td></tr><tr><td>Test case name</td><td>Clock-aligned Meter Values - Transaction ongoing</td></tr><tr><td rowspan="2">Tool validations</td><td>Note: The following steps do not need to be sent in a specific order. * Step 1: Message: MeterValuesRequest -meterValue[0].sampledValue[0].context must be Sample.Circle -meterValue[0].sampledValue must contain <An element per configured measurand at the AlignedDataMeasurands. The measurand field may be omitted when the measurand is "Energy.Active.Importantly"> * Step 3: Message: TransactionEventRequest - triggerReason must be MeterValueClock -metervalue[0].sampledValue[0].context must be Sample.Circle -metervalue[0].sampledValue must contain <An element per configured measurand at the AlignedDataMeasurands. The measurand field may be omitted when the measurand is "Energy.Active.Importantly"></td></tr><tr><td>Post scenario validations: Message: TransactionEventRequest - timestamp <The intervals between the timestamps of the received TransactionEventRequest messages must equal the configured value at AlignedDataInterval. However it is allowed to send multiple Meter Value messages per configured interval, in case the amount of measured data is too much for one message. But the timestamp of these messages must all be the same.> 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, in case the amount of measured data is too much for one message. But the timestamp of these messages must all be the same.></td></tr></table>
+
+Table 245. Test Case Id: TC_J_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clock-aligned Meter Values - EventType Ended</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J01 & (E06,E07,E08,E09,E10,E12)</td></tr><tr><td>Requirement(s)</td><td colspan="2">J01.FR.01,J01.FR.02,J01.FR.03,J01.FR.06,J01.FR.07,J01.FR.08,J01.FR.14,J01.FR.15 & E06.FR.11,E06.FR.17,E07.FR.08,E07.FR.13,E08.FR.09,E09.FR.05,E10.FR.04,E12.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send clock-aligned Meter Values when a transaction ends at the TransactionRequest with eventType is Ended, when it is configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has an energy meter.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:
+AlignedDataTxEnabledInterval is <Configured clock_aligned_tx_ended_meter_values_interval>
+SampledDataTxEnabledMeasurands is empty string
+AlignedDataSendDuringIdle is false (If implemented)</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State ParkingBayUnoccupied
+Note(s):
+- This step will be executed after the <Configured transaction duration> is reached.
+- This causes the transaction to stop.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- The TransactionEventRequest containing eventType Ended contains the MeterValue field.
+- The MeterValue must contain <An element per data collection moment indicated by
+AlignedDataTxEnabledInterval. The OCTT will not validate this.>
+- timestamp <The intervals between the timestamps of the received Meter Value messages must equal the
+configured value at AlignedDataTxEnabledInterval>.
+- sampledValue[0].context must be Sample.Clock
+- sampledValue must contain <An element per configured measurand at the
+AlignedDataTxEnabledMeasurands. The measurand field may be omitted when the measurand is
+"Energy.Active.ImportantlyRegister"></td></tr></table>
+
+Table 246. Test Case Id: TC_J_04_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clock-aligned Meter Values - Signed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J01</td></tr><tr><td>Requirement(s)</td><td colspan="2">J01.FR.21</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send signed clock-aligned Meter Values when a transaction ends at the TransactionRequest with eventType is Ended, when it is configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has an energy meter.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+AlignedDataTxEndInterval is <Configured clock-aligned_tx_ended_meter_values_interval>
+AlignedDataSendDuringIdle is false (If implemented)
+AlignedDataSignReadings is true</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State ParkingBayUnoccupied
+Note(s):
+- This step will be executed after the <Configured transaction duration> is reached.
+- This causes the transaction to stop.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- The TransactionEventRequest containing eventType Ended contains the MeterValue field.
+- The MeterValue should contain <An element per data collection moment indicated by
+AlignedDataTxEndInterval. The OCTT will not validate this.>
+- timestamp <The intervals between the timestamps of the received Meter Value messages should equal the
+configured value at AlignedDataTxEndInterval>.
+- sampledValue[0].context should be Sample.Circle
+- sampledValue should contain <An element per configured measurand at the
+AlignedDataTxEndMeasuredMeasurands. The measurand field may be omitted when the measurand is
+"Energy.Active.Import.Register">
+- sampledValue.signedMeterValue should not be omitted
+- sampledValue.signedMeterValue.PublicKey should exist and depending on the value of
+OCPPCommCtrlr.PublicKeyWithSignedMeterValue, should be either "", or a valid public key</td></tr></table>
+
+Table 247. Test Case Id: TC_J_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clock-aligned Meter Values - No Meter Values during transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_06_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to only send clock-aligned Meter Values when there is no ongoing transaction, when it is configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station has an energy meter.
+- The configuration variable AlignedDataSendDuringIdle is implemented.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+AlignedDataInterval is set to <Configured clock-aligned Meter Values interval>
+AlignedDataSendDuringIdle is set to true</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station notifies the CSMS about its measured Meter Values.
+Note(s):
+- The Meter Value messages do NOT need to be send/received at the exact specified interval. The configured measurands must be measured at the configured interval.
+- Multiple Meter Value messages may be sent 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 (evseld=0)</td><td>2. The OCTT responds accordingly.</td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>4. The Charging Station notifies the CSMS about its measured Meter Values.
+Note(s):
+- The Meter Value messages should not be send/received at the exact specified interval.</td><td>5. The OCTT responds accordingly.</td></tr><tr><td colspan="2">6. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">Note(s):
+- This step will be executed after the <Configured clock-aligned Meter Values interval + 5 seconds> is reached.</td></tr><tr><td></td><td>7. The Charging Station notifies the CSMS about its measured Meter Values.Note(s):- The Meter Value messages do NOT need to be send/received at the exact specified interval. The configured measurands must be measured at the configured interval.- Multiple Meter Value messages may be sent 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 (evseld=0)</td><td>8. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1 & 7:Message: MeterValuesRequest-sampledValue[0].context must be Sample.Circle-sampledValue must contain <An element per configured measurand at the AlignedDataMeasurands. The measurand field may be omitted when the measurand is "Energy.Active.Importantly"</td></tr><tr><td colspan="2">Post scenario validations: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 (evseld=0). But the timestamp of these messages must all be the same.> - The Charging Station did not send any message to report Meter Values to the OCTT, during the time the transaction was active at step 3 and 4. This means none of the following; MeterValuesRequest OR TransactionEventRequest containing the MeterValue field.</td></tr></table>
+
+Table 248. Test Case Id: TC_J_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Sampled Meter Values - EventType Started - EVSE known</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J02 & (E01,E02,E03,E09,E04,E05)</td></tr><tr><td>Requirement(s)</td><td colspan="2">J02.FR.01,J02.FR.02,J02.FR.03,J02.FR.04,J02.FR.10,E01.FR.09,E02.FR.09,E03.FR.07,E04.FR.05,E05.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send sampled Meter Values when a transaction starts and the EVSE is known, at the TransactionRequest with eventType is Started, when it is configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station has an energy meter.
+- The Charging Station does NOT have the following configuration; TxStartPoint contains ParkingBayOccupancy</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+TxStartPoint contains EVConnected Note: TxStartPoint contains EVConnected, Authorized,
+PowerPathClosed, EnergyTransfer AND/OR DataSigned (At least one of these values must be set).</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is ParkingBayOccupied</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">2. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- The TransactionEventRequest containing eventType Started contains the MeterValue field.
+- 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.Importantly"</td></tr></table>
+
+Table 249. Test Case Id: TC_J_08_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Sampled Meter Values - Context Transaction.Begin - EVSE not known</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_08_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J02 & (E01,E02,E03,E09,E04,E05)</td></tr><tr><td>Requirement(s)</td><td colspan="2">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</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">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.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station has an energy meter.
+- The Charging Station does NOT have the following configuration; TxStartPoint does NOT contain ParkingBayOccupancy OR Authorized.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+TxStartPoint contains Authorized
+Note: TxStartPoint contains Authorized AND/OR ParkingBayOccupancy (At least one of these values must be set).</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">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.ImportantlyRegister"></td></tr></table>
+
+Table 250. Test Case Id: TC_J_09_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Sampled Meter Values - EventType Updated</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_09_CS</td></tr><tr><td>Use case ld(s)</td><td colspan="2">J02 & (E01,E02,E03,E09,E04,E05)</td></tr><tr><td>Requirement(s)</td><td colspan="2">J02.FR.01, J02.FR.02, J02.FR.03, J02.FR.04, J02.FR.10, J02.FR.11, J02.FR.14, E02.FR.10, E02.FR.11, E03.FR.08, E03.FR.09, E04.FR.06, E04.FR.09, E11.FR.03, E11.FR.06, E12.FR.03, E12.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send sampled Meter Values during the transaction, at the TransactionRequest with eventType is Updated, when it is configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has an energy meter.</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+SampleDataTxUpdatedInterval is <Configured sampled Meter Values Updated interval></td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The Charging Station sends a TransactionEventRequest
+Note(s):
+- The TransactionRequest messages do NOT need to be send/received at the exact specified interval. The configured measurands must be measured at the configured interval.
+- Multiple TransactionRequest messages may be sent per configured interval, in case the amount of measured data is too much for one message.
+- The OCTT will end the testcase after it has the <Configured transaction duration> is reached..</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: TransactionRequest
+- triggerReason must be MeterValuePeriodic
+- sampledValue[0].context must be Sample.Periodic
+- sampledValue must contain <An element per configured measurand at the SampleDataTxUpdatedMeasurands. The measurand field may be omitted when the measurand is "Energy.Active.Import.Register"></td></tr><tr><td colspan="2">Post scenario validations:
+-timestamp <The intervals between the timestamps of the received TransactionRequest messages must equal the configured value at SampleDataTxUpdatedInterval. However it is allowed to send multiple Meter Value messages per configured interval, in case the amount of measured data is too much for one message. But the timestamp of these messages must all be the same.></td></tr></table>
+
+Table 251. Test Case Id: TC_J_10_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Sampled Meter Values - EventType Ended</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_10_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J02 & (E06,E07,E08,E09,E10,E12)</td></tr><tr><td>Requirement(s)</td><td colspan="2">J02.FR.01,J02.FR.02,J02.FR.03,J02.FR.04,J02.FR.10,E06.FR.11,E06.FR.17,E07.FR.08,E07.FR.13,E08.FR.09,E09.FR.05,E10.FR.04,E12.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send sampled Meter Values when a transaction ends at the TransactionEventRequest with eventType is Ended, when it is configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has an energy meter.</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+SampleDataTxEndInterval is <Configured sampled_tx_end_meter_values_interval>
+AlignedDataTxEndMeasuredurands is empty string</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">Note(s):
+- This step will be executed after the <Configured transaction duration> is reached.
+- This causes the transaction to stop.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- The TransactionEventRequest containing eventType Ended contains the MeterValue field.
+- The MeterValue must contain <An element per data collection moment indicated by SampleDataTxEndInterval. The OCTT will not validate this.>
+- timestamp <The intervals between the timestamps of the received Meter Value messages must equal the configured value at SampleDataTxEndInterval>.
+- sampledValue[0].context must be Sample.Periodic AND one must have Transaction.End
+- sampledValue must contain <An element per configured measurand at the SampleDataTxEndMeasuredurands. The measurand field may be omitted when the measurand is "Energy.Active.Importantly Register"></td></tr></table>
+
+Table 252. Test Case Id: TC_J_11_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Sampled Meter Values - Signed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_11_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J02</td></tr><tr><td>Requirement(s)</td><td colspan="2">J02.FR.21</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send sampled Meter Values when a transaction ends at the TransactionEventRequest with eventType is Ended, when it is configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station has an energy meter.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:
+SampleDataTxEndInterval is <Configured sampled_tx_ended_meter_values_interval>
+SampleDataSignReadings is true</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State ParkingBayUnoccupied
+Note(s):
+- This step will be executed after the <Configured transaction duration> is reached.
+- This causes the transaction to stop.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- The TransactionEventRequest containing eventType Ended contains the MeterValue field.
+- The MeterValue must contain <An element per data collection moment indicated by SampleDataTxEndPeriodInterval. The OCTT will not validate this.>
+- timestamp <The intervals between the timestamps of the received Meter Value messages must equal the configured value at SampleDataTxEndPeriodInterval.>
+- sampledValue[0].context must be Sample.Periodic AND one must have Transaction.End
+- sampledValue must contain <An element per configured measurand at the SampleDataTxEndPeriodMeasurands. The measurand field may be omitted when the measurand is "Energy.Active.Import.Register">
+- sampledValue_signedMeterValue should not be omitted
+- sampledValue_signedMeterValue.PublicKey should exist and depending on the value of OCPPCommCtrl.PublicKeyWithSignedMeterValue, should be either "", or a valid public key</td></tr></table>
+
+# 2.12. K SmartCharging
+
+Table 253. Test Case Id: TC_K_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - TxDefaultProfile - Specific EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.07, K01.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to accept and successfully change to the TxDefaultProfile charging profile sent by the CSMS on a specific EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with evseld<Configured evseld> AND chargingProfile.id<Configured chargingProfileId> AND chargingProfile.chargingProfilePurpose TxDefaultProfile chargingProfile.chargingSchedule.duration<Configured duration> chargingProfile.chargingSchedule.chargingRateUnit<Configured chargingRateUnit> chargingProfile.chargingSchedule.chargingSchedul ePeriod.startPeriod 0 chargingProfile.chargingSchedule.chargingSchedul ePeriod制约if unit is A then 6(A) else 6000(W) chargingProfile.chargingSchedule.chargingSchedul ePeriod.numberPhases<Configured numberPhases></td></tr><tr><td>4. The Charging Station responds with a GetChargingProfilesResponse</td><td>3. The OCTT sends a GetChargingProfilesRequest with chargingProfile.chargingProfileId<Configured chargingProfileId> requestId<Generated requestId></td></tr><tr><td>5. The Charging Station sends a ReportChargingProfilesRequest</td><td>6. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 5 then step 5 and 6 will be repeated</td></tr><tr><td>Test case name</td><td>Set Charging Profile - TxDefaultProfile - Specific EVSE</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message SetChargingProfileResponse
+- status Accepted
+* Step 4:
+Message GetChargingProfilesResponse
+- status Accepted
+* Step 5:
+Message ReportChargingProfilesRequest
+- requestId <Generated requestId>
+- evseld <Configured EVSEId>*
+- chargingProfile <Configured ChargingProfile></td></tr><tr><td>Post scenario validations:
+- The same profile is reported as send in step 1</td></tr></table>
+
+Table 254. Test Case Id: TC_K_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - TxProfile without ongoing transaction on the specified EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.04, K01.FR.07, K01.FR.09</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to accept and successfully change to the a TxProfile charging profile, without ongoing transaction, sent by the CSMS on a specific EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with evseld <Configured evseld> AND chargingProfile.id <Configured chargingProfileId> AND chargingProfile.chargingProfilePurpose TxProfile AND chargingProfile_transactionId UNKNOWN-TRANSACTION-ID</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message SetChargingProfileResponse - status Rejected</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 255. Test Case Id: TC_K_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - ChargingStationMaxProfile</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to accept and successfully change to the ChargingStationMaxProfile sent by the CSMS on a specific EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest withchargingProfile.id<Configured chargingProfileId>ANDchargingProfile.chargingProfilePurposeChargingStationMaxProfile ANDchargingProfile.chargingProfileKind Absolute ANDchargingProfile.chargingSchedule.duration<Configured duration>ANDchargingProfile.chargingSchedule.chargingRateUnit<Configured chargingRateUnit>ANDchargingProfile.chargingSchedule.chargingSchedul ePeriod.startPeriod 0 ANDchargingProfile.chargingSchedule.chargingSchedul ePeriodlimit if unit is A then 6(A) else 6000(W) ANDchargingProfile.chargingSchedule.chargingSchedul ePeriod.numberPhases<Configured numberPhases>ANDEVSEId 0</td></tr><tr><td>4. The Charging Station responds with a GetChargingProfilesResponse</td><td>3. The OCTT sends a GetChargingProfilesRequest withchargingProfile.chargingProfileId<ConfiguredchargingProfileId>requestId<Generated requestId></td></tr><tr><td>5. The Charging Station sends a ReportChargingProfilesRequest</td><td>6. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 5 then step 5 and 6 will be repeated</td></tr><tr><td>Test case name</td><td>Set Charging Profile - ChargingStationMaxProfile</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message SetChargingProfileResponse
+- status Accepted
+* Step 4:
+Message GetChargingProfilesResponse
+- status Accepted
+* Step 5:
+Message ReportChargingProfilesRequest
+- requestId <Generated requestId>
+- Evseld 0
+- chargingProfile <Generated chargingProfile></td></tr><tr><td>Post scenario validations:
+- The same profile is reported as send in step 1</td></tr></table>
+
+Table 256. Test Case Id: TC_K_04_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Replace charging profile - With chargingProfileId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to accept and successfully change to the ChargingStationMaxProfile sent by the CSMS on a specific EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A chargeprofile with <Generated chargingProfileId> AND limit 6.0/6000.0 AND ChargingProfilePurposeTxDefaultProfile is configured</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest withchargingProfile.id <Configured chargingProfileId>chargingProfile.chargingProfilePurposeTxDefaultProfilechargingProfile.chargingSchedule.chargingSchedul ePeriodlimit 10.0/10000.0</td></tr><tr><td>4. The Charging Station responds with a GetChargingProfilesResponse</td><td>3. The OCTT sends a GetChargingProfilesRequest withchargingProfile.chargingProfileId <Configured chargingProfileId></td></tr><tr><td>5. The Charging Station sends a ReportChargingProfilesRequest</td><td>6. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 5 then step 5 and 6 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetChargingProfileResponse-status Accepted* Step 4:Message GetChargingProfilesResponse-status Accepted* Step 5:Message ReportChargingProfilesRequest-requestId Same Id as in the GetChargingProfilesRequest in step 3-EVSEId <Configured EVSEId>- chargingProfile <ChargingProfile set in step 1></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 257. Test Case Id: TC_K_05_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Charging Profile - With chargingProfileId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_05_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K10</td></tr><tr><td>Requirement(s)</td><td colspan="2">K10.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">If the CSMS wishes to clear some or all of the charging profiles that were previously sent to the Charging Station, then the CSMS sends a ClearChargingProfileRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to accept the request and clear a specific charging profile sent with only a chargingProfileId by the CSMS as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A chargingprofile with <Configured chargingProfileId> is configured</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ClearChargingProfileResponse</td><td>1. The OCTT sends a ClearChargingProfileRequest with chargingProfileId <Configured chargingProfileId></td></tr><tr><td>4. The Charging Station responds with a GetChargingProfilesResponse</td><td>3. The OCTT sends a GetChargingProfilesRequest with chargingProfile.chargingProfileId<Configured chargingProfileId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message ClearChargingProfileResponse-status Accepted* Step 4:Message GetChargingProfilesResponse-status NoProfiles</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 258. Test Case Id: TC_K_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Charging Profile - With stackLevel/purpose combination for one profile</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_06_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K10</td></tr><tr><td>Requirement(s)</td><td colspan="2">K10.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">If the CSMS wishes to clear some or all of the charging profiles that were previously sent to the Charging Station, then the CSMS sends a ClearChargingProfileRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to accept the request and clear a charging profile sent with a stackLevel/purpose combination by the CSMS as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: A chargingprofile with <Configured chargingProfilePurpose> AND <Configured stackLevel> is configured</td></tr><tr><td colspan="2">Charging State: EnergyTransferStarted</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ClearChargingProfileResponse</td><td>1. The OCTT sends a ClearChargingProfileRequest with chargingProfileCriteria.chargingProfilePurpose <Configured chargingProfilePurpose> AND chargingProfileCriteria.stackLevel <Configured stackLevel></td></tr><tr><td>4. The Charging Station responds with a GetChargingProfilesResponse</td><td>3. The OCTT sends a GetChargingProfilesRequest with chargingProfile.chargingProfilePurpose <Configured chargingProfilePurpose> AND chargingProfile.stackLevel <Configured stackLevel></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message ClearChargingProfileResponse - status Accepted * Step 4: Message GetChargingProfilesResponse - status NoProfiles</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 259. Test Case Id: TC_K_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Charging Profile - With unknown stackLevel/purpose combination</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K10</td></tr><tr><td>Requirement(s)</td><td colspan="2">K10.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">If the CSMS wishes to clear some or all of the charging profiles that were previously sent to the Charging Station, then the CSMS sends a ClearChargingProfileRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to deny the request to clear a specific charging profile when an unknown chargingProfileId and unknown stackLevel/purpose combination is sent by the CSMS as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: A chargingprofile with ChargingProfilePurpose TxDefaultProfile AND StackLevel 1 is configured</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ClearChargingProfileResponse</td><td>1. The OCTT sends a ClearChargingProfileRequest with chargingProfileCriteria.chargingProfilePurpose ChargingStationMaxProfile AND chargingProfileCriteria.stackLevel 0</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message ClearChargingProfileResponse - status Unknown</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 260. Test Case Id: TC_K_08_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Charging Profile - Without previous charging profile</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_08_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K10</td></tr><tr><td>Requirement(s)</td><td colspan="2">K10.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">If the CSMS wishes to clear some or all of the charging profiles that were previously sent to the Charging Station, then the CSMS sends a ClearChargingProfileRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to deny the request to clear a specific charging profile when no charging profiles are configured as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ClearChargingProfileResponse</td><td>1. The OCTT sends a ClearChargingProfileRequest with chargingProfileId <Generated chargingProfileId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message ClearChargingProfileResponse - status Unknown</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 261. Test Case Id: TC_K_09_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Charging Profile - Clearing a TxDefaultProfile - With ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_09_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K10</td></tr><tr><td>Requirement(s)</td><td colspan="2">K10.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">If the CSMS wishes to clear some or all of the charging profiles that were previously sent to the Charging Station, then the CSMS sends a ClearChargingProfileRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to accept the request and clear a TxDefaultProfile by the CSMS as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:SmartChargingCtrl.LimitChangeSignificance is 1.0</td></tr><tr><td colspan="2">Memory State:SetChargingProfile withChargingProfile 1:chargingProfilePurpose is TxDefaultProfilechargingProfileKind should be AbsolutestackLevel should be 0evseld <Configured evseld>validFrom <currentDateTime - <Configured max time deviation> seconds>validTo <currentDateTime + <Configured max time deviation> + 401 seconds>startSchedule <currentDateTime>numberPhases <Configured numberPhases>ChargingSchedule:duration 400 + <Configured max time deviation>chargingRateUnit <Configured chargingRateUnit>Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.startPeriod 0, limit 6</td></tr><tr><td colspan="2">Charging State:State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aGetCompositeScheduleResponse</td><td>1. The OCTT sends aGetCompositeScheduleRequest withevseld is <Configured evseld></td></tr><tr><td>4. The Charging Station responds with aClearChargingProfileResponse</td><td>3. The OCTT sends a ClearChargingProfileRequest withchargingProfileCriteria.chargingProfilePurposeTxDefaultProfile</td></tr><tr><td>5. The Charging Station responds with aGetCompositeScheduleResponse</td><td>6. The OCTT sends aGetCompositeScheduleRequestwith evseld <Configured evseld>duration is 300chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td>Test case name</td><td>Clear Charging Profile - Clearing a TxDefaultProfile - With ongoing transaction</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+(Message: GetCompositeScheduleResponse)
+status Accepted
+evseld <Configured evseld>
+ChargingSchedule:
+duration 300
+chargingRateUnit <Configured chargingRateUnit>
+Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.
+Note: The period of time between sending the second SetChargingProfileRequest and the scheduleStart from the GetCompositeScheduleResponse is called x:
+startPeriod 0, limit <Local limit of Charging Station (Validation passes if value is 6>
+* Step 4:
+(Message: ClearChargingProfileResponse)
+status is Accepted
+* Step 5:
+(Message: GetCompositeScheduleResponse)
+status Accepted
+evseld <Configured evseld>
+ChargingSchedule:
+duration 300
+chargingRateUnit <Configured chargingRateUnit>
+Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.
+Note: The period of time between sending the second SetChargingProfileRequest and the scheduleStart from the GetCompositeSchedule Response is called x:
+startPeriod 0, limit <Local limit of Charging Station (Validation passes if value is NOT 6></td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 262. Test Case Id: TC_K_10_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - TxDefaultProfile - All EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_10_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.07, K01.FR.14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to accept and successfully change to the TxDefaultProfile charging profile sent by the CSMS for all EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with evseld 0 AND chargingProfile.id <Configured chargingProfileId> AND chargingProfile.chargingProfilePurpose TxDefaultProfile chargingProfile.chargingSchedule.duration <Configured duration> chargingProfile.chargingSchedule.chargingRateUnit <Configured chargingRateUnit> chargingProfile.chargingSchedule.chargingSchedul ePeriod.startPeriod 0 chargingProfile.chargingSchedule.chargingSchedul ePeriod制约6.0 chargingProfile.chargingSchedule.chargingSchedul ePeriod.numberPhases <Configured numberPhases></td></tr><tr><td>4. The Charging Station responds with a GetChargingProfilesResponse</td><td>3. The OCTT sends a GetChargingProfilesRequest with chargingProfile.chargingProfileId <Configured chargingProfileId> requestId <Generated requestId></td></tr><tr><td>5. The Charging Station sends a ReportChargingProfilesRequest</td><td>6. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 5 then step 5 and 6 will be repeated</td></tr><tr><td>Test case name</td><td>Set Charging Profile - TxDefaultProfile - All EVSE</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message SetChargingProfileResponse
+- status Accepted
+* Step 4:
+Message GetChargingProfilesResponse
+- status Accepted
+* Step 5:
+Message ReportChargingProfilesRequest
+- requestId <Generated requestId>
+- EVSEld 0
+- tbc false
+- chargingProfile <Configured chargingProfile></td></tr><tr><td>Post scenario validations:
+- The same profile is reported as send in step 1</td></tr></table>
+
+Table 263. Test Case Id: TC_K_11_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - Unable to set TxProfile on all EVSE at once</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_11_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.04, K01.FR.16</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to deny a TxProfile when sent to all EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with evseld 0 AND chargingProfile.id<Configured chargingProfileId>ANDchargingProfile.chargingProfilePurpose TxProfile</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetChargingProfileResponse-status Rejected</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 264. Test Case Id: TC_K_12_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - ChargerRateUnit Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_12_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.26</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to deny a chargeProfile when the given ChargerRateUnit is not known by the charger as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2"></td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: This testcase can only be tested when one of the 2 chargingRateUnits is not supported.</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with chargingProfile.id <Configured chargingProfileId> AND chargingProfile.chargingSchedule.chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message SetChargingProfileResponse - status Rejected</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 265. Test Case Id: TC_K_13_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - Persistent over reboot</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_13_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.27</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to save a chargingProfile persistent over reboot as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with evseld<Configured evseld>ANDchargingProfile.id<Configured chargingProfileId>ANDchargingProfile.chargingProfilePurposeTxDefaultProfilechargingProfile.chargingSchedule.duration<Configured duration>chargingProfile.chargingSchedule.chargingRateUnit<Configured chargingRateUnit>chargingProfile.chargingSchedule.chargingSchedul ePeriod.startPeriod 0chargingProfile.chargingSchedule.chargingSchedul ePeriod limit if unit is A then 6(A) else 6000(W)chargingProfile.chargingSchedule.chargingSchedul ePeriod.numberPhases<Configured numberPhases></td></tr><tr><td colspan="2">3. Execute Reusable State Booted</td></tr><tr><td>5. The Charging Station responds with a GetChargingProfilesResponse</td><td>4. The OCTT sends a GetChargingProfilesRequest with chargingProfile.chargingProfileId<Configured chargingProfileId></td></tr><tr><td>6. The Charging Station sends a ReportChargingProfilesRequest</td><td>7. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 6 then step 6 and 7 will be repeated</td></tr><tr><td>Test case name</td><td>Set Charging Profile - Persistent over reboot</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message SetChargingProfileResponse
+- status Accepted
+* Step 5:
+Message GetChargingProfilesResponse
+- status Accepted
+* Step 6:
+Message ReportChargingProfilesRequest
+- requestId Same Id as in the GetChargingProfilesRequest in step 4
+- EVSEld <Configured EVSEld>
+- chargingProfile <Configured chargingProfile></td></tr><tr><td>Post scenario validations:
+- The same profile is reported as send in step 1</td></tr></table>
+
+Table 266. Test Case Id: TC_K_14_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - Unexisting EVSEid</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_14_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.28</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to reject a chargingProfile when the provided EVSEid is unknown as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with evseld <EVSECount + 1></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message SetChargingProfileResponse - status Rejected</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 267. Test Case Id: TC_K_15_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - Not Supported</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_15_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.29</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to raise a callerror when it does not support smart charging as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging station does not support smart charging</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with RPC Framework: CALLERROR: NotSupported.</td><td>1. The OCTT sends a SetChargingProfileRequest with chargingProfile.id <Configured chargingProfileId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">- N/a</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 268. Test Case Id: TC_K_16_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - Unknown transactionId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_16_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.33</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to reject a charge profile when an unknown transactionId is provided as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with evseld <Configured evseld> AND chargingProfile.id <Configured chargingProfileId> AND chargingProfile.chargingProfilePurpose TxProfile AND chargingProfile_transactionId UNKNOWN-TRANSACTION-ID</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message SetChargingProfileResponse - status Rejected</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 269. Test Case Id: TC_K_19_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - ChargingProfileKind is Recurring</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_19_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.40</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to accept and successfully change to the Recurring ChargingProfileKind sent by the CSMS as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with chargingProfile.chargingProfileKind Recurring chargingProfile.recurrencyKind <Configured ReccurrencyKind></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message SetChargingProfileResponse - status Accepted</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 270. Test Case Id: TC_K_21_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - ValidFrom</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_21_CS</td></tr><tr><td>Use case ld(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.36</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to impose charging limits by setting a charging profile that becomes valid after a certain date/time using the SetChargingProfileRequest message.It is only tested on EVSE #1, because mechanism is the same regardless of EVSE.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station activates a set charging profile after the ValidFrom is reached.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with chargingProfile.chargingProfilePurpose is TxDefaultProfilechargingProfile.chargingProfileKind is Relative evseld <configured evseld>chargingProfile.validFrom <current dateTime + 300 seconds>chargingProfile.validTo is absent chargingProfile.chargingSchedule[0].startSchedule is absent chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].numberPhases <Configured numberPhases>chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].startPeriod 0If <Configured chargingRateUnit> is A:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 6If <Configured chargingRateUnit> is W:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 6000</td></tr><tr><td>4. The Charging Station responds with a GetCompositeScheduleResponse</td><td>3. The OCTT sends aGetCompositeScheduleRequestwith evseld <configured evseld>duration is 400chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td>Test case name</td><td>Set Charging Profile - ValidFrom</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+(Message: SetChargingProfileResponse)
+status is Accepted
+* Step 4:
+(Message: GetCompositeScheduleResponse)
+status Accepted
+schedule.evseld <configured evseld>
+schedule.chargingRateUnit <Configured chargingRateUnit>
+schedule.duration 400
+schedule.chargingSchedulePeriod[0].startPeriod 0, schedule.chargingSchedulePeriod[1].startPeriod (300 - x),
+schedule.chargingSchedulePeriod[1].limit 6.0
+Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.
+Note: The period of time between sending the second SetChargingProfileRequest and the scheduleStart from the GetCompositeScheduleResponse is called x:</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 271. Test Case Id: TC_K_22_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - ValidTo</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_22_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.37</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to impose charging limits by setting a charging profile using the SetChargingProfileRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station deactivates a set charging profile after the ValidTo has passed.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with chargingProfile.chargingProfilePurpose is TxDefaultProfilechargingProfile.chargingProfileKind is Absolute evseld 0chargingProfile.validFrom <current dateTime-<Configured max time deviation> seconds>chargingProfile.validTo <current dateTime + 300 seconds>chargingProfile.chargingSchedule[0].startSchedule<current dateTime>chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].numberPhases <Configured numberPhases>chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].startPeriod 0If <Configured chargingRateUnit> is A:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 6If <Configured chargingRateUnit> is W:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 6000</td></tr><tr><td>4. The Charging Station responds with a GetCompositeScheduleResponse</td><td>3. The OCTT sends aGetCompositeScheduleRequestwith evseld iduration is 400chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td colspan="2">Note(s):- Steps 3 and 4 are repeated for i=0,1,...,nr. of configured EVSEs</td></tr><tr><td>Test case name</td><td>Set Charging Profile - ValidTo</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+(Message: SetChargingProfileResponse)
+status is Accepted
+* Step 4:
+(Message: GetCompositeScheduleResponse)
+status Accepted
+evseld <requested evseld>
+chargingRateUnit <Configured chargingRateUnit>
+ChargingSchedule:
+duration 400
+chargingRateUnit <Configured chargingRateUnit>
+Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.
+Note: The period of time between sending the second SetChargingProfileRequest and the scheduleStart from the GetCompositeScheduleResponse is called x:
+startPeriod 0, limit 6 (for evse 0 the limit is multiplied by the nr. of EVSE)+ startPeriod (300-x), limit <Local limit of Charging Station (This is not validated)></td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 272. Test Case Id: TC_K_23_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - StartSchedule</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_23_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.30</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to impose charging limits by setting a charging profile using the SetChargingProfileRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station activates a set charging profile after the StartSchedule has passed.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with chargingProfile.chargingProfilePurpose is TxDefaultProfilechargingProfile.chargingProfileKind is Absolute evseld<configured evseld>chargingProfile.validFrom<current dateTime-<Configured max time deviation>+50 seconds>chargingProfile.validTo<current dateTime+<Configured max time deviation>+400 seconds>chargingProfile.chargingSchedule[0].startSchedule<current dateTime-<Configured max time deviation>+60 seconds>chargingProfile.chargingSchedule[0].chargingSchedulePeriod[].numberPhases<Configured numberPhases>chargingProfile.chargingSchedule[0].chargingSchedulePeriod[].startPeriod 0If<Configured chargingRateUnit>is A:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[].limit 6If<Configured chargingRateUnit>is W:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[].limit 6000</td></tr><tr><td>4. The Charging Station responds with a GetCompositeScheduleResponse</td><td>3. The OCTT sends aGetCompositeScheduleRequestwith evseld<Configured evseld>duration is 300chargingRateUnit<Configured chargingRateUnit></td></tr><tr><td>Test case name</td><td>Set Charging Profile - StartSchedule</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+(Message: SetChargingProfileResponse)
+status is Accepted
+* Step 4:
+(Message: GetCompositeScheduleResponse)
+status Accepted
+evseld <Configured evseld>
+ChargingSchedule:
+duration 300
+chargingRateUnit <Configured chargingRateUnit>
+Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.
+Note: The period of time between sending the second SetChargingProfileRequest and the scheduleStart from the GetCompositeScheduleResponse is called x:
+startPeriod 0, limit <Local limit of Charging Station (This is not validated)>
+startPeriod (60 - x), limit 6</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 273. Test Case Id: TC_K_24_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Charging Profile - With stackLevel/purpose combination for multiple profiles</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_24_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K10</td></tr><tr><td>Requirement(s)</td><td colspan="2">K10.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">If the CSMS wishes to clear some or all of the charging profiles that were previously sent to the Charging Station, then the CSMS sends a ClearChargingProfileRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to accept the request and clear charging profiles sent with a stackLevel/purpose combination by the CSMS as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station needs to have 2 or more EVSE.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A chargingprofile with <Configured chargingProfilePurpose> AND <Configured stackLevel> is configured for evseld 1.A chargingprofile with <Configured chargingProfilePurpose> AND <Configured stackLevel> is configured for evseld 2.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ClearChargingProfileResponse</td><td>1. The OCTT sends a ClearChargingProfileRequest with chargingProfileCriteria.chargingProfilePurpose<Configured chargingProfilePurpose> AND chargingProfileCriteria.stackLevel<Configured stackLevel></td></tr><tr><td>4. The Charging Station responds with a GetChargingProfilesResponse</td><td>3. The OCTT sends a GetChargingProfilesRequest with chargingProfile.chargingProfilePurpose<Configured chargingProfilePurpose> AND chargingProfile.stackLevel<Configured stackLevel></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message ClearChargingProfileResponse-status Accepted* Step 4:Message GetChargingProfilesResponse-status NoProfiles</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 274. Test Case Id: TC_K_28_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - TxDefaultProfile with transaction ongoing</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_28_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.32</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sets a default schedule for a currently ongoing transaction.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS and Charging Station are able to exchange messages to set a default schedule for a currently ongoing transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:SmartChargingCtrl.LimitChangeSignificance is 1.0</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with chargingProfile.chargingProfilePurpose is TxDefaultProfilechargingProfile.chargingProfileKind is Absolute chargingProfile.chargingSchedule[0].duration is 300 evseld<Configured evseld>chargingProfile.validFrom <current dateTime-<Configured max time deviation> seconds>chargingProfile.validTo <current dateTime+<Configured max time deviation> + 300 seconds>chargingProfile.chargingSchedule[0].startSchedule<current dateTime-<Configured max time deviation> seconds>chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].numberPhases<Configured numberPhases>chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].startPeriod 0If<Configured chargingRateUnit>is A:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 6If<Configured chargingRateUnit>is W:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 6000</td></tr><tr><td>4. The Charging Station responds with a GetCompositeScheduleResponse</td><td>3. The OCTT sends aGetCompositeScheduleRequestwith evseld<Configured evseld>duration is 300chargingRateUnit<Configured chargingRateUnit></td></tr><tr><td>Test case name</td><td>Set Charging Profile - TxDefaultProfile with transaction ongoing</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+(Message: SetChargingProfileResponse)
+status is Accepted
+* Step 4:
+(Message: GetCompositeScheduleResponse)
+status Accepted
+evseld <Configured evseld>
+ChargingSchedule:
+duration 300
+chargingRateUnit <Configured chargingRateUnit>
+Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.
+Note: The period of time between sending the second SetChargingProfileRequest and the scheduleStart from the GetCompositeScheduleResponse is called x:
+startPeriod 0, limit <6/6000></td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 275. Test Case Id: TC_K_29_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - Evseld 0</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_29_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.02, K09.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to successfully report the charging profile(s) requested as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: Charging station has a charging profile with <Generated Id1> AND chargingProfilePurpose ChargingStationMaxProfile configured on the charging statation. Charging station has a second charge profile with <Generated Id2> AND chargingProfilePurpose TxDefaultProfile configured on <Configured evseld>.</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetChargingProfilesResponse</td><td>1. The OCTT sends a GetChargingProfilesRequest with evseld 0</td></tr><tr><td>3. The Charging Station sends a ReportChargingProfilesRequest</td><td>4. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s): - If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message GetChargingProfilesResponse - status Accepted * Step 3: Message ReportChargingProfilesRequest - requestId <Generated requestId> - chargingProfile <Generated ChargingProfile1> with chargingProfilePurpose ChargingStationMaxProfile</td></tr><tr><td colspan="2">Post scenario validations: - All report message have been received</td></tr></table>
+
+Table 276. Test Case Id: TC_K_30_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - Evseld > 0</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_30_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.02, K09.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to successfully report the charging profile(s) requested for a specific EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Charging station has a charging profile with <Generated Id1> AND ChargingStationMaxProfile configured on the charging station.Charging station has a second charge profile with <Generated Id2> AND TxDefaultProfile configured on<Configured evseld>.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aGetChargingProfilesResponse</td><td>1. The OCTT sends a GetChargingProfilesRequest withevseld<Configured evseld></td></tr><tr><td>3. The Charging Station sends aReportChargingProfilesRequest</td><td>4. The OCTT responds with aReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetChargingProfilesResponse*- status Accepted*- Step 3:Message ReportChargingProfilesRequest- requestId<Generated requestId>- chargingProfile<Generated ChargingProfile></td></tr><tr><td colspan="2">Post scenario validations:- All report message have been received</td></tr></table>
+
+Table 277. Test Case Id: TC_K_31_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - No Evseld</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_31_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.02, K09.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to successfully report all installed charging profiles requested as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Charging station has a charging profile with <Generated Id1> AND ChargingStationMaxProfile configured on the charging station.Charging station has a second charge profile with <Generated Id2> AND TxDefaultProfile configured on EVSEId <Configured evseld>.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aGetChargingProfilesResponse</td><td>1. The OCTT sends a GetChargingProfilesRequest with:requestId Generated requestId</td></tr><tr><td>3. The Charging Station sends aReportChargingProfilesRequest</td><td>4. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetChargingProfilesResponse*- status Accepted*- Step 3:Message ReportChargingProfilesRequest*- requestId <Generated requestId>- chargingProfiles <Configured ChargingProfiles></td></tr><tr><td colspan="2">Post scenario validations:- All report message have been received</td></tr></table>
+
+Table 278. Test Case Id: TC_K_32_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - chargingProfileId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_32_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.01, K09.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to successfully report a specific charging profile requested as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Charging station has a charging profile with<Generated Id1> AND ChargingStationMaxProfile configured on the charging station.Charging station has a second charge profile with<Generated Id2> AND TxDefaultProfile configured on EVSEId<Configured evseld>.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aGetChargingProfilesResponse</td><td>1. The OCTT sends a GetChargingProfilesRequest withchargingProfileId<Generated Id1></td></tr><tr><td>3. The Charging Station sends aReportChargingProfilesRequest</td><td>4. The OCTT responds with aReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetChargingProfilesResponse-status Accepted* Step 3:Message ReportChargingProfilesRequest-requestId Generated Id1-chargingProfile<Configured chargingProfile></td></tr><tr><td colspan="2">Post scenario validations:- All report message have been received</td></tr></table>
+
+Table 279. Test Case Id: TC_K_33_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - Evseld > 0 + stackLevel</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_33_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.02, K09.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to successfully report a charging profile with specific stackLevel requested for a specific EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Charging station has a charging profile with<Generated Id1> AND ChargingStationMaxProfile AND<Configured stackLevel> configured on the station.Charging station has a second charge profile with<Generated Id2> AND TxDefaultProfile AND<Configured stackLevel2> configured on<Configured evseld>.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aGetChargingProfilesResponse</td><td>1. The OCTT sends a GetChargingProfilesRequest withevseld<Configured evseld> ANDchargingProfile.stackLevel<Configured stackLevel></td></tr><tr><td>3. The Charging Station sends aReportChargingProfilesRequest</td><td>4. The OCTT responds with aReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetChargingProfilesResponse-status Accepted* Step 3:Message ReportChargingProfilesRequest-requestId Generated Id1-chargingProfile<Configured ChargingProfile></td></tr><tr><td colspan="2">Post scenario validations:- All report message have been received</td></tr></table>
+
+Table 280. Test Case Id: TC_K_34_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - EvseId > 0 + chargingLimitSource</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_34_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.02, K09.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to successfully report a charging profile with specific chargingLimitSource requested for a specific EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: <Configured chargingLimitSource> should be CSO AND <Configured chargingLimitSource2> should have no existing profiles AND Charging station has a charging profile with: - id <Generated Id1> - chargingProfilePurpose TxDefaultProfile - stackLevel <Configured StackLevel + 1></td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetChargingProfilesResponse</td><td>1. The OCTT sends a GetChargingProfilesRequest with evseId <Configured evseId> AND chargingProfile.chargingLimitSource <Configured chargingLimitSource></td></tr><tr><td>3. The Charging Station sends a ReportChargingProfilesRequest</td><td>4. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s): - If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr><tr><td>6. The Charging Station responds with a GetChargingProfilesResponse</td><td>5. The OCTT sends a GetChargingProfilesRequest with evseId <Configured evseId> AND chargingProfile.chargingLimitSource <Configured chargingLimitSource2></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message GetChargingProfilesResponse - status Accepted * Step 3: Message ReportChargingProfilesRequest - requestId Generated Id1 - chargingProfile <ChargingProfile> * Step 6: Message GetChargingProfilesResponse - status NoProfiles</td></tr><tr><td colspan="2">Post scenario validations: - All report message have been received</td></tr></table>
+
+Table 281. Test Case Id: TC_K_35_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - Evseld > 0 + chargingProfilePurpose</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_35_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.02, K09.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to successfully report a charging profile with specific chargingProfilePurpose requested for a specific EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: Charging station has a charge profile with <Generated Id1> AND ChargingStationMaxProfile configured on the charging station. Charging station has a second charge profile with <Generated Id2> AND TxDefaultProfile configured on <Configured evseld>.</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetChargingProfilesResponse</td><td>1. The OCTT sends a GetChargingProfilesRequest with evseld <Configured evseld> AND chargingProfile.chargingProfilePurpose <Configured chargingProfilePurpose></td></tr><tr><td>3. The Charging Station sends a ReportChargingProfilesRequest</td><td>4. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s): - If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message GetChargingProfilesResponse - status Accepted * Step 3: Message ReportChargingProfilesRequest - requestId Generated Id1 - ChargingProfile <Configured ChargingProfile></td></tr><tr><td colspan="2">Post scenario validations: - All report message have been received</td></tr></table>
+
+Table 282. Test Case Id: TC_K_36_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - Evseld > 0 + chargingProfilePurpose + stackLevel</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_36_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.02, K09.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to successfully report a charging profile with specific chargingProfilePurpose and stackLevel requested for a specific EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: Charging station has a charge profile with <Generated Id1> AND ChargingStationMaxProfile AND <Configured stackLevel> configured on the charging station. Charging station has a second charge profile with <Generated Id2> AND TxDefaultProfile AND <Configured stackLevel> configured on <Configured evseld>.</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetChargingProfilesResponse</td><td>1. The OCTT sends a GetChargingProfilesRequest with evseld <Configured evseld> AND chargingProfile.chargingProfilePurpose <TxDefaultProfile> AND chargingProfile.stackLevel <Configured stackLevel></td></tr><tr><td>3. The Charging Station sends a ReportChargingProfilesRequest</td><td>4. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s): - If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message GetChargingProfilesResponse - status Accepted * Step 3: Message ReportChargingProfilesRequest - requestId Generated Id1 - ChargingProfile <Configured ChargingProfile></td></tr><tr><td colspan="2">Post scenario validations: - All report message have been received</td></tr></table>
+
+Table 283. Test Case Id: TC_K_60_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - TxProfile with ongoing transaction on the specified EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_60_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.04, K01.FR.07, K01.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sets a TxProfile on a specific EVSE for a currently ongoing transaction.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to exchange messages to set a TxProfile on a specific EVSE for a currently ongoing transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station must support the GetChargingProfiles feature.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with chargingProfile.chargingProfilePurpose is TxProfilechargingProfile transactionId is <transactionIdreturned by Charging Station in before>chargingProfile.chargingProfileKind is Relative evseld <Configured evseld>chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].numberPhases <Configured numberPhases>chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].startPeriod 0If <Configured chargingRateUnit> is A:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 6If <Configured chargingRateUnit> is W:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 6000</td></tr><tr><td>4. The Charging Station responds with a GetChargingProfilesResponse</td><td>3. The OCTT sends a GetChargingProfilesRequest with chargingProfile.chargingProfileId <Used chargingProfiled at step 1></td></tr><tr><td>5. The Charging Station sends a ReportChargingProfilesRequest</td><td>6. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:(Message: SetChargingProfileResponse)status is Accepted* Step 4:(Message: GetChargingProfilesResponse)status is Accepted* Step 5:(Message: ReportChargingProfilesRequest)chargingProfile <The Charging Profile set at step 1></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 284. Test Case Id: TC_K_37_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote start transaction with charging profile - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_37_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K05,F01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K05.FR.03, E01.FR.02,F01.FR.10,F01.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sets a TxProfile on a specific EVSE inside a RequestStartTransactionRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to set a TxProfile on a specific EVSE when receiving one in a RequestStartTransactionRequest message.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station must support the GetChargingProfiles feature.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aRequestStartTransactionResponse</td><td>1. The OCTT sends aRequestStartTransactionRequestwith idToken.idToken<Configuredvalid_idtoken_idtoken>idToken.type<Configured valid_idtoken_type>evseld<Configured evseld>chargingProfile.chargingProfilePurpose is TxProfilechargingProfile transactionId is omitted.chargingProfile.chargingProfileKind is RelativechargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].numberPhases<ConfigurednumberPhases>chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].startPeriod 0If<Configured chargingRateUnit>is A:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 6If<Configured chargingRateUnit>is W:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 6000</td></tr><tr><td>3. The Charging Station sends an AuthorizationRequestNote(s):- This step needs to be executed whenAuthCtrl AUTHRemoteStart is true, unless(AuthEnabled is implemented with mutabilityReadOnly AND the value is set to false) ORthe idToken is cached.In case the idToken is used for a reservation, sendingthe AuthorizationRequest message is optional.</td><td>4. The OCTT responds with an AuthorizationResponsewith idTokenInfo.status Accepted</td></tr><tr><td rowspan="4"></td><td>5. The Charging Station sends a TransactionEventRequest Note(s): - This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy or (EVConnected, in the case this testcase was initiated from state EVConnectedPreSession.)</td><td>6. The OCTT responds with a TransactionEventResponse Note(s): - The first TransactionEventRequest sent after authorization contains the idToken field. The TransactionEventResponse of this request message contains idTokenInfo with status Accepted</td></tr><tr><td colspan="2">7. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>9. The Charging Station responds with a GetChargingProfilesResponse</td><td>8. The OCTT sends a GetChargingProfilesRequest with chargingProfile.chargingProfileId <Used chargingProfileId at step 1></td></tr><tr><td>10. The Charging Station sends a ReportChargingProfilesRequest</td><td>11. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: RequestStartTransactionResponse - status must be Accepted If the transaction has already been started, so if TxStartPoint contains ParkingBayOccupancy OR (<Configured TxStartPoint> contains EVConnected AND State pre reusable state execution was EVConnectedPreSession) then - transactionId must be <Provided transactionId in first TransactionEventRequest> * Step 3: Message:authorizeRequest - idToken.idToken <Configured valid_idtoken_idtoken> - idToken.type <Configured valid_idtoken_type> * Step 5: Message: TransactionEventRequest - triggerReason must be RemoteStart - transactionInforemoteStartId must be present. * Step 9: (Message: GetChargingProfilesResponse) status is Accepted * Step 10: (Message: ReportChargingProfilesRequest) chargingProfile <The Charging Profile set at step 1></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 285. Test Case Id: TC_K_38_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote start transaction with charging profile - Ignore chargingProfile</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_38_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F01</td></tr><tr><td>Requirement(s)</td><td colspan="2">F01.FR.12,F01.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sets a TxProfile on a specific EVSE inside a RequestStartTransactionRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to ignore a TxProfile on a specific EVSE when receiving one in a RequestStartTransactionRequest message, when it does not support Smart Charging.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station does NOT support Smart Charging.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aRequestStartTransactionResponse</td><td>1. The OCTT sends aRequestStartTransactionRequestwith idToken.idToken<Configuredvalid_idtoken_idtoken>idToken.type<Configured valid_idtoken_type>evseld<Configured evseld>chargingProfile.chargingProfilePurpose is TxProfilechargingProfile transactionId is omitted.chargingProfile.chargingProfileKind is RelativechargingProfile.chargingSchedule.chargingSchedul ePeriod[0].numberPhases<ConfigurednumberPhases>chargingProfile.chargingSchedule.chargingSchedul ePeriod[0].startPeriod 0If<Configured chargingRateUnit>is A:chargingProfile.chargingSchedule.chargingSchedul ePeriod[0].limit 6If<Configured chargingRateUnit>is W:chargingProfile.chargingSchedule.chargingSchedul ePeriod[0].limit 6000</td></tr><tr><td>3. The Charging Station sends an AuthorizationRequestNote(s):- This step needs to be executed whenAuthCtrl+AuthorizeRemoteStart is true, unless(AuthEnabled is implemented with mutabilityReadOnly AND the value is set to false) ORthe idToken is cached.In case the idToken is used for a reservation, sending the AuthorizationRequest message is optional.</td><td>4. The OCTT responds with an AuthorizationResponsewith idTokenInfo.status Accepted</td></tr><tr><td rowspan="2"></td><td>5. The Charging Station sends a TransactionRequest Note(s): - This step needs to be executed when TxStartPoint contains Authorized OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy or (EVConnected, in the case this testcase was initiated from state EVConnectedPreSession.)</td><td>6. The OCTT responds with a TransactionResponse Note(s): - The first TransactionRequest sent after authorization contains the idToken field. The TransactionResponse of this request message contains idTokenInfo with status Accepted</td></tr><tr><td colspan="2">7. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: RequestStartTransactionResponse - status must be Accepted If the transaction has already been started, so if TxStartPoint contains ParkingBayOccupancy OR (TxStartPoint contains EVConnected AND State pre reusable state execution was EVConnectedPreSession) then - transactionId must be <Provided transactionId in first TransactionRequest> * Step 3: Message: InvalidateRequest - idToken.idToken <Configured valid_idtoken_idtoken> - idToken.type <Configured valid_idtoken_type> * Step 5: Message: TransactionRequest - triggerReason must be RemoteStart - transactionInforemoteStartld must be present.</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 286. Test Case Id: TC_K_39_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Composite Schedule - No ChargingProfile installed on Charging Station</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_39_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K08</td></tr><tr><td>Requirement(s)</td><td colspan="2">K08.FR.02, K08.FR.03,K08.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS requests a composite schedule which is a combination of local limits and the prevailing Charging Profiles of the different chargingProfilePurposes and stack levels.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to calculate a correct composite schedule and provide this to the CSMS on request.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetCompositeScheduleResponse</td><td>1. The OCTT sends a GetCompositeScheduleRequest with evseld 0 duration is 300 chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: (Message: GetCompositeScheduleResponse) status Accepted evseld 0 duration is 300 chargingRateUnit <Configured chargingRateUnit> startPeriod 0</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 287. Test Case Id: TC_K_40_CS
+
+<table><tr><td>Test case name</td><td>Get Composite Schedule - Stacking ChargingProfiles</td></tr><tr><td>Test case Id</td><td>TC_K_40_CS</td></tr><tr><td>Use case Id(s)</td><td>K08</td></tr><tr><td>Requirement(s)</td><td>K08.FR.02,K08.FR.06</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>The CSMS requests a composite schedule which is a combination of local limits and the prevailing Charging Profiles of the different chargingProfilePurposes and stack levels.</td></tr><tr><td>Purpose</td><td>To verify if the Charging Station is able to calculate a correct composite schedule and provide this to the CSMS on request.</td></tr><tr><td>Prerequisite(s)</td><td>- ChargingProfileEntries.maxLimit must be > 1
+- The configuration variable ChargingProfileMaxStackLevel must be > 0
+- The configuration variable PeriodsPerSchedule must be > 2</td></tr><tr><td rowspan="25">Before (Preparations)</td><td>Configuration State:
+N/a</td></tr><tr><td>Memory State:
+SetChargingProfile with ChargingProfile 1:
+chargingProfilePurpose is TxDefaultProfile
+chargingProfileKind should be Absolute
+stackLevel should be 0
+evseld <Configured evseld></td></tr><tr><td>validFrom <currentDateTime - <Configured max time deviation> seconds></td></tr><tr><td>validTo <currentDateTime + <Configured max time deviation> + 401 seconds></td></tr><tr><td>startSchedule <currentDateTime - <Configured max time deviation> seconds></td></tr><tr><td>numberPhases <Configured numberPhases></td></tr><tr><td>ChargingSchedule:
+duration 400 + <Configured max time deviation></td></tr><tr><td>chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td>Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.</td></tr><tr><td>startPeriod 0, limit 6</td></tr><tr><td>startPeriod 100, limit 8</td></tr><tr><td>startPeriod 200, limit 10</td></tr><tr><td>ChargingProfile 2:
+chargingProfilePurpose is TxDefaultProfile</td></tr><tr><td>chargingProfileKind should be Absolute
+stackLevel should be 1</td></tr><tr><td>evseld <Configured evseld></td></tr><tr><td>validFrom <currentDateTime - <Configured max time deviation> seconds></td></tr><tr><td>validTo <currentDateTime + <Configured max time deviation> + 401 seconds></td></tr><tr><td>startSchedule <currentDateTime - <Configured max time deviation> seconds></td></tr><tr><td>numberPhases <Configured numberPhases></td></tr><tr><td>ChargingSchedule:
+duration 150 + <Configured max time deviation></td></tr><tr><td>chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td>Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.</td></tr><tr><td>startPeriod 0, limit 7</td></tr><tr><td>startPeriod 100, limit 9</td></tr><tr><td>Reusable State(s):
+N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Get Composite Schedule - Stacking ChargingProfiles</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetCompositeScheduleResponse</td><td>1. The OCTT sends a GetCompositeScheduleRequest with evseld <Configured evseld> duration is 350 chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: (Message: GetCompositeScheduleResponse) status Accepted evseld <Configured evseld> ChargingSchedule: duration 350 chargingRateUnit <Configured chargingRateUnit> Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000. Note: The period of time between sending the second SetChargingProfileRequest and the scheduleStart from the GetCompositeScheduleResponse is called x: startPeriod _0, limit 7 startPeriod (100 - x), limit 9 startPeriod (150 - x), limit 8 startPeriod (200 - x), limit 10</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 288. Test Case Id: TC_K_41_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Composite Schedule - Combining chargingProfilePurposes</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_41_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K08</td></tr><tr><td>Requirement(s)</td><td colspan="2">K08.FR.02,K08.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS requests a composite schedule which is a combination of local limits and the prevailing Charging Profiles of the different chargingProfilePurposes and stack levels.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to calculate a correct composite schedule and provide this to the CSMS on request.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- ChargingProfileEntries.maxLimit must be > 2
+- The configuration variable PeriodsPerSchedule must be > 2</td></tr><tr><td rowspan="4">Before (Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+SetChargingProfile with ChargingProfile 1:
+chargingProfilePurpose is ChargingStationMaxProfile
+chargingProfileKind should be Absolute
+stackLevel should be 0
+evseld 0
+startSchedule <currentDateTime - <Configured max time deviation> seconds>
+numberPhases <Configured numberPhases>
+ChargingSchedule:
+duration 86400
+chargingRateUnit <Configured chargingRateUnit>
+Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.
+startPeriod 0, limit 10</td></tr><tr><td>ChargingProfile 2:
+chargingProfilePurpose is TxDefaultProfile
+chargingProfileKind should be Absolute
+stackLevel should be 0
+evseld <Configured evseld>
+validFrom <currentDateTime - <Configured max time deviation> seconds>
+validTo <currentDateTime + <Configured max time deviation> + 401 seconds>
+startSchedule <currentDateTime - <Configured max time deviation> seconds>
+numberPhases <Configured numberPhases>
+ChargingSchedule:
+duration 300
+chargingRateUnit <Configured chargingRateUnit>
+Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.
+startPeriod 0,60,120,180,260, limit 6,10,8,15,8</td><td>ChargingProfile 3:
+chargingProfilePurpose is TxProfile
+chargingProfileKind should be Absolute
+stackLevel should be 0
+evseld <Configured evseld>
+validFrom <currentDateTime - <Configured max time deviation> seconds>
+validTo <currentDateTime + <Configured max time deviation> + 401 seconds>
+startSchedule <currentDateTime - <Configured max time deviation> seconds>
+numberPhases <Configured numberPhases>
+ChargingSchedule:
+duration 260
+chargingRateUnit <Configured chargingRateUnit>
+Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.
+startPeriod 0,50,140,200,240, limit 8,11,16,6,12</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetCompositeScheduleResponse</td><td>1. The OCTT sends a GetCompositeScheduleRequest with evseld <Configured evseld>
+duration is 400
+chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td>Test case name</td><td>Get Composite Schedule - Combining chargingProfilePurposes</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+(Message: GetCompositeScheduleResponse)
+status Accepted
+evseld <Configured evseld>
+ChargingSchedule:
+duration 400
+chargingRateUnit <Configured chargingRateUnit>
+Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.
+Note: The period of time between sending the second SetChargingProfileRequest and the scheduleStart from the GetCompositeScheduleResponse is called x:
+startPeriod 0, limit 8
+startPeriod (50 - x), limit 10
+startPeriod (200 - x), limit 6
+startPeriod (240 - x), limit 10</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 289. Test Case Id: TC_K_42_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Composite Schedule - chargingRateUnit not supported</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_42_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K08</td></tr><tr><td>Requirement(s)</td><td colspan="2">K08.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS requests a composite schedule which is a combination of local limits and the prevailing Charging Profiles of the different chargingProfilePurposes and stack levels.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reject a GetCompositeScheduleRequest when it asks for a not supported chargingRateUnit.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station does NOT support one of the chargingRateUnits; A or W.
+- The OCTT chargingRateUnit configuration field contains the NOT supported chargingRateUnit.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetCompositeScheduleResponse</td><td>1. The OCTT sends a GetCompositeScheduleRequest with evseld 0
+duration is 300 chargingRateUnit <Configured unsupported chargingRateUnit></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+(Message: GetCompositeScheduleResponse)
+status Rejected
+schedule is omitted</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 290. Test Case Id: TC_K_47_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Composite Schedule - Unknown EVSEId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_47_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K08</td></tr><tr><td>Requirement(s)</td><td colspan="2">K08.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS requests a composite schedule which is a combination of local limits and the prevailing Charging Profiles of the different chargingProfilePurposes and stack levels.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reject a GetCompositeScheduleRequest when it asks for composite schedule for a unknown evseld.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetCompositeScheduleResponse</td><td>1. The OCTT sends a GetCompositeScheduleRequest with evseld <Configured number of evse> + 1 duration is 300 chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: (Message: GetCompositeScheduleResponse) status Rejected schedule is omitted</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 291. Test Case Id: TC_K_52_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set External Charging Limit (not on a transaction) - ChargingStationExternalConstraints in report</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_52_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K12</td></tr><tr><td>Requirement(s)</td><td colspan="2">K12.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">A charging schedule or charging limit has been set by an external system on the Charging Station. Such a charging limit is represented by a charging profile with purpose ChargingStatioExternalConstraints.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the charging station is able to correctly report an external charging limit as ChargingStationExternalConstraints.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+An external charging limit has been submitted to Charging Station.</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetChargingProfilesResponse</td><td>1. The OCTT sends a GetChargingProfilesRequest with chargingProfile.chargingProfilePurpose ChargingStationExternalConstraints</td></tr><tr><td>3. The Charging Station sends a ReportChargingProfilesRequest</td><td>4. The OCTT responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s):
+- If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message GetChargingProfilesResponse
+- status Accepted
+* Step 3:
+Message ReportChargingProfilesRequest
+- requestId Same id as in the request in step 1
+- chargingProfile.chargingProfilePurpose ChargingStationExternalConstraints</td></tr><tr><td colspan="2">Post scenario validations:
+- All report messages have been received and at least one ChargingStationExternalConstraints is returned.</td></tr></table>
+
+Table 292. Test Case Id: TC_K_53_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Charging with load leveling based on High Level Communication - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_53_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K15</td></tr><tr><td>Requirement(s)</td><td colspan="2">K15.FR.01,K15.FR.06,K15.FR.09,K15.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">ISO15118-1 E1 AC Charging with load leveling based on High Level Communication, and E4 DC charging with load leveling based on High Level Communication.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform load leveling when it receives charging needs from the EV.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is Authorized (local) State is EVConnectedPreSession</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State RenegotiateChargingLimits</td></tr><tr><td>Tool validations</td><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 293. Test Case Id: TC_K_54_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Charging with load leveling based on High Level Communication - No SASchedule (rejected)</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_54_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K15, K17</td></tr><tr><td>Requirement(s)</td><td colspan="2">K15.FR.01,K17.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">ISO15118-1 E1 AC Charging with load leveling based on High Level Communication, and E4 DC charging with load leveling based on High Level Communication.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to handle a Rejected status from the CSMS in response to providing the EV charging needs.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is Authorized (local)State is EVConnectedPreSession</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends aNotifyEVChargingNeedsRequest.</td><td>2. The OCTT responds with aNotifyEVChargingNeedsResponse.With status Rejected</td></tr><tr><td>3. The Charging Station sends aNotifyEVChargingScheduleRequest.Note(s):- This step is optional. The Charging Station will only send it when the EV returns a charging profile.</td><td>4. The OCTT responds with aNotifyEVChargingScheduleResponse.With status Accepted</td></tr><tr><td>5. The Charging Station sends aTransactionEventRequest.</td><td>6. The OCTT responds with aTransactionEventResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:(Message: NotifyEVChargingNeedsRequest)evseld<Configured evseld>* Step 3:(Message: NotifyEVChargingScheduleRequest)evseld<Configured evseld>* Step 5:Message: TransactionEventRequest-triggerReason must be ChargingStateChanged- transactionInfo.chargingState must be Charging</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 294. Test Case Id: TC_K_56_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Charging with load leveling based on High Level Communication - Offline</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_56_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K15,K17</td></tr><tr><td>Requirement(s)</td><td colspan="2">K15.FR.15,K17.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">ISO15118-1 E1 AC Charging with load leveling based on High Level Communication, and E4 DC charging with load leveling based on High Level Communication.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform load leveling when it receives charging needs from the EV and it is offline.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:RetryBackOffWaitMinimum is <Configured RetryBackOffWaitMinimum></td></tr><tr><td colspan="2">Memory State:SetChargingProfile withChargingProfile:chargingProfilePurpose is TxDefaultProfilechargingProfileKind should be AbsolutestackLevel should be 0evseld <Configured evseld>validFrom <currentDateTime - <Configured max time deviation> seconds>validTo <currentDateTime + <Configured max time deviation> + 401 seconds>startSchedule <currentDateTime - <Configured max time deviation> seconds>numberPhases <Configured numberPhases>ChargingSchedule:duration 400chargingRateUnit <Configured chargingRateUnit>Note: If <Configured chargingRateUnit> is W, then the limit field will be multiplied by 1000.startPeriod 0, limit 6</td></tr><tr><td colspan="2">Reusable State(s):State is Authorized (local)State is EVConnectedPreSession</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td></td><td>1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td></td><td>2. The OCTT accepts the reconnection attempt from the Charging Station, after 90 seconds.</td></tr><tr><td>3. The Charging Station sends aNotifyEVChargingScheduleRequest.Note(s):- This step is optional.- It is allowed to execute this step either before or after the TransactionEventRequest from step 5.</td><td>4. The OCTT responds with aNotifyEVChargingScheduleResponse.With status Accepted</td></tr><tr><td>5. The Charging Station sends aTransactionEventRequest.</td><td>6. The OCTT responds with aTransactionEventResponse.</td></tr><tr><td>Test case name</td><td>Charging with load leveling based on High Level Communication - Offline</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 3:
+(Message: NotifyEVChargingScheduleRequest)
+evseld <Configured evseld>
+* Step 5:
+Message: TransactionEventRequest
+- triggerReason must be ChargingStateChanged
+- transactionInfo.chargingState must be Charging
+- offline true</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 295. Test Case Id: TC_K_57_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Renegotiating a Charging Schedule - Initiated by EV</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_57_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K17</td></tr><tr><td>Requirement(s)</td><td colspan="2">K17.FR.01,K17.FR.06,K17.FR.09,K17.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The EV signals the Charging Station that it wants to renegotiate and it provides new charging needs, which the Charging Station sends to the CSMS. Based on this and other parameters, the CSMS calculates a new charging schedule and sends it via SetChargingProfileRequest to Charging Station, which communicates it to the EV.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform load leveling when it receives a renegotiate request from the EV.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is Authorized (local)State is EVConnectedPreSessionState is RenegotiateChargingLimits</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends aNotifyEVChargingNeedsRequest.</td><td>2. The OCTT responds with aNotifyEVChargingNeedsResponse.With status Accepted</td></tr><tr><td>4. The Charging Station responds with aSetChargingProfileResponse</td><td>3. The OCTT sends a SetChargingProfileRequest with chargingProfile.chargingProfilePurposeTxProfilechargingProfile transactionId<ProvidedtransactionId from before>chargingProfile.chargingSchedule[0].chargingRateUnit<Configured chargingRateUnit>Note: If<Configured chargingRateUnit>is W, then the limit field will be multiplied by 1000.chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].startPeriod 0,chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 15</td></tr><tr><td>5. The Charging Station sends aNotifyEVChargingScheduleRequest.Note(s):- This step is optional. The Charging Station will only send it when the EV returns a charging profile.</td><td>6. The OCTT responds with aNotifyEVChargingScheduleResponse.With status Accepted</td></tr><tr><td>7. The Charging Station sends aTransactionEventRequest.Note(s):- This step is optional. But the Charging Station will probably send it, otherwise it would not have renegotiated.</td><td>8. The OCTT responds with aTransactionEventResponse.</td></tr><tr><td>Test case name</td><td>Renegotiating a Charging Schedule - Initiated by EV</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+(Message: NotifyEVChargingNeedsRequest)
+evseld <Configured evseld>
+* Step 4:
+(Message: SetChargingProfileResponse)
+status Accepted
+* Step 5:
+(Message: NotifyEVChargingScheduleRequest)
+evseld <Configured evseld>
+* Step 7:
+Message: TransactionEventRequest
+- triggerReason must be ChargingRateChanged</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 296. Test Case Id: TC_K_58_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Renegotiating a Charging Schedule - Initiated by CSMS</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_58_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K17</td></tr><tr><td>Requirement(s)</td><td colspan="2">K17.FR.01,K17.FR.06,K17.FR.09,K17.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The EV signals the Charging Station that it wants to renegotiate and it provides new charging needs, which the Charging Station sends to the CSMS. Based on this and other parameters, the CSMS calculates a new charging schedule and sends it via SetChargingProfileRequest to Charging Station, which communicates it to the EV.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to perform load leveling when it receives a renegotiate request from the CSMS.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is Authorized (local)State is EVConnectedPreSessionState is RenegotiateChargingLimits</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with chargingProfile.chargingProfilePurposeTxProfilechargingProfile transactionId<ProvidedtransactionId from before>chargingProfile.chargingSchedule[0].chargingRateUnit<Configured chargingRateUnit>chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].startPeriod 0If<Configured chargingRateUnit>is W:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 8000Else:chargingProfile.chargingSchedule[0].chargingSchedulePeriod[0].limit 8</td></tr><tr><td>3. The Charging Station sends a NotifyEVChargingScheduleRequest.Note(s):- This step is optional. The Charging Station will only send it when the EV returns a charging profile.</td><td>4. The OCTT responds with a NotifyEVChargingScheduleResponse.With status Accepted</td></tr><tr><td>5. The Charging Station sends a TransactionEventRequest.Note(s):- This step is optional. But the Charging Station will send it, when it was charging above a limit of 8/8000.</td><td>6. The OCTT responds with a TransactionEventResponse.</td></tr><tr><td>Test case name</td><td>Renegotiating a Charging Schedule - Initiated by CSMS</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+(Message: NotifyEVChargingNeedsRequest)
+evseld <Configured evseld>
+* Step 4:
+(Message: SetChargingProfileResponse)
+status Accepted
+* Step 5:
+(Message: NotifyEVChargingScheduleRequest)
+evseld <Configured evseld>
+* Step 7:
+Message: TransactionEventRequest
+- triggerReason must be ChargingRateChanged</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+# 2.13. L Firmware Management
+
+Table 297. Test Case Id: TC_L_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - Installation successful</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">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,L01.FR.23</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to securely download and install a new firmware.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s), indicated by the configuration variable FileTransferProtocols.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponse</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours> firmware.location <Configured firmware_location> firmware.retrieveDateTime <Current DateTime - 2 hours> firmware/signingCertificate <Configured signingCertificate> firmware!' signature <Configured signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequestWith status Downloading</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>5. The Charging Station sends a FirmwareStatusNotificationRequestWith status Downloaded</td><td>6. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequestWith status SignatureVerified</td><td>8. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>9. The Charging Station notifies the CSMS about the current state of all connectors.Note(s):- This step is optional. The Charging Station may wants to set its connectors to Unavailable, before proceeding installing the new firmware.</td><td>10. The OCTT responds accordingly.</td></tr><tr><td></td><td colspan="2">11. Execute Reusable State RebootBeforeFirmwareInstallationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware installation.</td></tr><tr><td></td><td>12. The Charging Station sends a FirmwareStatusNotificationRequest With status Installing Note(s): - This step only needs to be executed if the Charging Station did NOT reboot before firmware installation, at step 11.</td><td>13. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td colspan="2">14. Execute Reusable State RebootBeforeFirmwareActivation Note: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.</td></tr><tr><td></td><td colspan="2">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.</td></tr><tr><td></td><td colspan="2">Note: Step 16 through 21 can be send in a different order.</td></tr><tr><td></td><td>16. The Charging Station notifies the CSMS about the current state of all connectors. 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.</td><td>17. The OCTT responds accordingly.</td></tr><tr><td></td><td>18. The Charging Station sends a FirmwareStatusNotificationRequest With status Installed</td><td>19. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td>20. The Charging Station sends a SecurityEventNotificationRequest With type FirmwareUpdated</td><td>21. The OCTT responds with a SecurityEventNotificationResponse</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Secure Firmware Update - Installation successful</td></tr><tr><td>Tool validations</td><td>* 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 UnavailableOrMessage: 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 AvailableOrMessage: 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</td></tr><tr><td></td><td>Post scenario validations:N/a</td></tr></table>
+
+Table 298. Test Case Id: TC_L_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - InstallScheduled</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">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,L01.FR.23</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able securely download a new firmware and schedule its installation.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">-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.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aUpdateFirmwareResponse</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.location<Configuredfirmware_location>firmware.retrieveDateTime<Current DateTime-2hours>firmware/signingCertificate<ConfiguredsigningCertificate>firmwaresignature<Configured signature>firmware.installDateTime<Current DateTime+<Configured Install Offset Period>></td></tr><tr><td>3. The Charging Station sends aFirmwareStatusNotificationRequestWith status Downloading</td><td>4. The OCTT responds with aFirmwareStatusNotificationResponse</td></tr><tr><td>5. The Charging Station sends aFirmwareStatusNotificationRequestWith status Downloaded</td><td>6. The OCTT responds with aFirmwareStatusNotificationResponse</td></tr><tr><td>7. The Charging Station sends aFirmwareStatusNotificationRequestWith status SignatureVerified</td><td>8. The OCTT responds with aFirmwareStatusNotificationResponse</td></tr><tr><td>9. The Charging Station sends aFirmwareStatusNotificationRequestWith status InstallScheduledNote(s):- The Charging Station will start installing the firmware after the set installDateTime is reached.</td><td>10. The OCTT responds with aFirmwareStatusNotificationResponse</td></tr><tr><td>11. The Charging Station notifies the CSMS about the current state of all connectors.Note(s):- This step is optional. The Charging Station may wants to set its connectors to Unavailable, before proceeding installing the new firmware.</td><td>12. The OCTT responds accordingly.</td></tr><tr><td></td><td colspan="2">13. Execute Reusable State RebootBeforeFirmwareInstallationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware installation.</td></tr><tr><td></td><td>14. The Charging Station sends a FirmwareStatusNotificationRequest With status InstallingNote(s): - This step only needs to be executed if the Charging Station did NOT reboot before firmware installation, at step 13.</td><td>15. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td colspan="2">16. Execute Reusable State RebootBeforeFirmwareActivationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.</td></tr><tr><td></td><td colspan="2">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.</td></tr><tr><td></td><td colspan="2">Note: Step 18 through 23 can be send in a different order.</td></tr><tr><td></td><td>18. The Charging Station notifies the CSMS about the current state of all connectors.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.</td><td>19. The OCTT responds accordingly.</td></tr><tr><td></td><td>20. The Charging Station sends a FirmwareStatusNotificationRequest With status Installed</td><td>21. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td>22. The Charging Station sends a SecurityEventNotificationRequest With type FirmwareUpdated</td><td>23. The OCTT responds with a SecurityEventNotificationResponse</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Secure Firmware Update - InstallScheduled</td></tr><tr><td>Tool validations</td><td>* 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 UnavailableOrMessage: 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 AvailableOrMessage: 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</td></tr><tr><td></td><td>Post scenario validations:N/a</td></tr></table>
+
+Table 299. Test Case Id: TC_L_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - DownloadScheduled</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">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,L01.FR.23</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to schedule securely downloading a new firmware.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">-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.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponse</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours>firmware.location <Configured firmware_location>firmware.retrieveDateTime <Current DateTime + <Configured Download Offset Period>>firmware/signingCertificate <Configured signingCertificate>firmware!' signature <Configured signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequestWith status DownloadScheduledNote(s):- The Charging Station will start downloading the firmware after the set retrieveDateTime is reached.</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>5. The Charging Station sends a FirmwareStatusNotificationRequestWith status Downloading</td><td>6. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequestWith status Downloaded</td><td>8. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>9. The Charging Station sends a FirmwareStatusNotificationRequestWith status SignatureVerified</td><td>10. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>11. The Charging Station notifies the CSMS about the current state of all connectors.Note(s):- This step is optional. The Charging Station may wants to set its connectors to Unavailable, before proceeding installing the new firmware.</td><td>12. The OCTT responds accordingly.</td></tr><tr><td></td><td colspan="2">13. Execute Reusable State RebootBeforeFirmwareInstallationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware installation.</td></tr><tr><td></td><td>14. The Charging Station sends a FirmwareStatusNotificationRequest With status InstallingNote(s): - This step only needs to be executed if the Charging Station did NOT reboot before firmware installation, at step 13.</td><td>15. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td colspan="2">16. Execute Reusable State RebootBeforeFirmwareActivationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.</td></tr><tr><td></td><td colspan="2">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.</td></tr><tr><td></td><td colspan="2">Note: Step 18 through 23 can be send in a different order.</td></tr><tr><td></td><td>18. The Charging Station notifies the CSMS about the current state of all connectors.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.</td><td>19. The OCTT responds accordingly.</td></tr><tr><td></td><td>20. The Charging Station sends a FirmwareStatusNotificationRequest With status Installed</td><td>21. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td>22. The Charging Station sends a SecurityEventNotificationRequest With type FirmwareUpdated</td><td>23. The OCTT responds with a SecurityEventNotificationResponse</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Secure Firmware Update - DownloadScheduled</td></tr><tr><td>Tool validations</td><td>* 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 UnavailableOrMessage: 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 AvailableOrMessage: 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</td></tr><tr><td></td><td>Post scenario validations:N/a</td></tr></table>
+
+Table 300. Test Case Id: TC_L_05_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - InvalidCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_05_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.02,L01.FR.10,L01.FR.20,L01.FR.21,L01.FR.22</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to identify it receiving an invalid signing certificate and report this to the CSMS.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:<Generated Invalid Firmware SigningCertificate> should be a trusted certificate and not be the same as the<Configured Valid Firmware SigningCertificate></td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponse</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours>firmware.location <Configured firmware_location>firmware.retrieveDateTime <Current DateTime - 2 hours>firmware/signingCertificate <Generated invalid firmware signingCertificate>firmware!' signature <Configured signature></td></tr><tr><td>3. The Charging Station sends a SecurityEventNotificationRequest. With type InvalidFirmwareSigningCertificate</td><td>4. The OCTT responds with aSecurityEventNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message UpdateFirmwareResponse*- status InvalidCertificate OR RevokedCertificate* Step 3:Message SecurityEventNotificationRequest-type InvalidFirmwareSigningCertificate</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 301. Test Case Id: TC_L_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - InvalidSignature</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_06_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.03,L01.FR.04,L01.FR.10,L01.FR.20</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to identify if the signature is invalid and report this to the CSMS.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">A file server has been setup according to the (by the Charging Station) supported file transfer protocol(s), indicated by the configuration variable FileTransferProtocols.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:<Configured invalid firmware signature> should be a real signature</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponse</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours>firmware.location <Configured firmware_location>firmware.retrieveDateTime <Current DateTime - 2 hours>firmware/signingCertificate <Configured signingCertificate>firmwaresignature <Configured invalid firmware signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequest.With status Downloading</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>5. The Charging Station sends a FirmwareStatusNotificationRequest.With status Downloaded</td><td>6. The OCTT responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequest.With status InvalidSignature</td><td>8. The OCTT responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>9. The Charging Station sends a SecurityEventNotificationRequest.With type InvalidFirmwareSignature</td><td>10. The OCTT responds with a SecurityEventNotificationResponse.</td></tr><tr><td>Test case name</td><td>Secure Firmware Update - InvalidSignature</td></tr><tr><td rowspan="2">Tool validations</td><td>* 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</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 302. Test Case Id: TC_L_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - DownloadFailed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.10,L01.FR.20</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to report to the CSMS when it is unable to download the new firmware.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">-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.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponse</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime<Current DateTime-2 hours>firmware.location<Configured firmware location> + "_does.not Exist"firmware.retrieveDateTime_<Current DateTime-2 hours>firmware/signingCertificate<ConfiguredsigningCertificate>firmware!' signature<Configured signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequest.With status DownloadingNote(s):- This step is optional. The Charging Station may immediately identify downloading the firmware is not possible.</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>5. The Charging Station sends a FirmwareStatusNotificationRequest.With status DownloadFailed</td><td>6. The OCTT responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message UpdateFirmwareResponse*- status Accepted* Step 3:Message FirmwareStatusNotificationRequest*- status Downloading* Step 5:Message FirmwareStatusNotificationRequest*- status DownloadFailed</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 303. Test Case Id: TC_L_08_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - InstallVerificationFailed or InstallationFailed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_08_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.10,L01.FR.12,L01.FR.20</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to report to the CSMS when the firmware verification fails.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- 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.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:<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</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponse</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours>firmware.location <Configured invalid firmware location>firmware.retrieveDateTime <Current DateTime + <Current DateTime - 2 hours>>firmware/signingCertificate <Configured invalid firmware signingCertificate>firmwaresignature <Configured invalid firmware signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequestWith status Downloading</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>5. The Charging Station sends a FirmwareStatusNotificationRequestWith status Downloaded</td><td>6. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequestWith status SignatureVerified</td><td>8. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>9. The Charging Station notifies the CSMS about the current state of all connectors.Note(s):- This step is optional. The Charging Station may wants to set its connectors to Unavailable, before proceeding installing the new firmware.</td><td>10. The OCTT responds accordingly.</td></tr><tr><td></td><td colspan="2">11. Execute Reusable State RebootBeforeFirmwareInstallationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware installation.</td></tr><tr><td></td><td>12. The Charging Station sends a FirmwareStatusNotificationRequest With status Installing Note(s): - This step only needs to be executed if the Charging Station did NOT reboot before firmware installation, at step 11.</td><td>13. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td rowspan="3"></td><td colspan="2">Note: Step 14 through 17 can be send in a different order.</td></tr><tr><td>14. The Charging Station notifies the CSMS about the current state of all connectors. 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.</td><td>15. The OCTT responds accordingly.</td></tr><tr><td>16. The Charging Station sends a FirmwareStatusNotificationRequest With status InstallVerificationFailed or InstallationFailed</td><td>17. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>Test case name</td><td>Secure Firmware Update - InstallVerificationFailed or InstallationFailed</td></tr><tr><td>Tool validations</td><td>* 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 UnavailableOrMessage: 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 AvailableOrMessage: 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</td></tr><tr><td></td><td>Post scenario validations:N/a</td></tr></table>
+
+Table 304. Test Case Id: TC_L_10_CS
+
+<table><tr><td>Test case name</td><td>Secure Firmware Update - AcceptedCanceled</td></tr><tr><td>Test case Id</td><td>TC_L_10_CS</td></tr><tr><td>Use case Id(s)</td><td>L01</td></tr><tr><td>Requirement(s)</td><td>L01.FR.01,L01.FR.10,L01.FR.20,L01.FR.24</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td>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.</td></tr><tr><td>Prerequisite(s)</td><td>-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.</td></tr><tr><td colspan="2"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td>Configuration State:N/a</td></tr><tr><td>Memory State:N/a</td></tr><tr><td>Reusable State(s):N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - AcceptedCanceled</td></tr><tr><td rowspan="8">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a Update Firmware Response With status Accepted</td><td>1. The OCTT sends a Update FirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours> firmware.location <Configured firmware_location> firmware.retrieveDateTime <Current DateTime - 2 hours> firmware/signingCertificate <Configured signingCertificate> firmwaresignature <Configured signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequest With status Downloading</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>6. The Charging Station responds with a Update Firmware Response With status AcceptedCanceled</td><td>5. The OCTT sends a Update FirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours> firmware.location <Configured firmware_location> firmware.retrieveDateTime <Current DateTime - 2 hours> firmware/signingCertificate <Configured signingCertificate> firmwaresignature <Configured signature></td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequest With status Downloading</td><td>8. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>9. The Charging Station sends a FirmwareStatusNotificationRequest With status Downloaded</td><td>10. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>11. The Charging Station sends a FirmwareStatusNotificationRequest With status SignatureVerified</td><td>12. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>13. The Charging Station notifies the CSMS about the current state of all connectors.Note(s): - This step is optional. The Charging Station may wants to set its connectors to Unavailable, before proceeding installing the new firmware.</td><td>14. The OCTT responds accordingly.</td></tr><tr><td></td><td colspan="2">15. Execute Reusable State RebootBeforeFirmwareInstallationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware installation.</td></tr><tr><td></td><td>16. The Charging Station sends a FirmwareStatusNotificationRequest With status InstallingNote(s): - This step only needs to be executed if the Charging Station did NOT reboot before firmware installation, at step 15.</td><td>17. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td colspan="2">18. Execute Reusable State RebootBeforeFirmwareActivationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.</td></tr><tr><td rowspan="5"></td><td colspan="2">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.</td></tr><tr><td colspan="2">Note: Step 20 through 25 can be send in a different order.</td></tr><tr><td>20. The Charging Station notifies the CSMS about the current state of all connectors.
+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.</td><td>21. The OCTT responds accordingly.</td></tr><tr><td>22. The Charging Station sends a FirmwareStatusNotificationRequest With status Installed</td><td>23. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>24. The Charging Station sends a SecurityEventNotificationRequest With type FirmwareUpdated</td><td>25. The OCTT responds with a SecurityEventNotificationResponse</td></tr><tr><td>Test case name</td><td>Secure Firmware Update - AcceptedCanceled</td></tr><tr><td>Tool validations</td><td>* 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 UnavailableOrMessage: 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 AvailableOrMessage: 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</td></tr><tr><td></td><td>Post scenario validations:N/a</td></tr></table>
+
+Table 305. Test Case Id: TC_L_11_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - Unable to cancel</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_11_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.10,L01.FR.20,L01.FR.27</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reject a firmware update request when it is unable to cancel an ongoing firmware update.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">-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.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponseWith status Accepted</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours> firmware.location <Configured firmware_location> firmware.retrieveDateTime <Current DateTime - 2 hours> firmware/signingCertificate <Configured signingCertificate> firmware!' signature <Configured signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequestWith status Downloading</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>6. The Charging Station responds with a UpdateFirmwareResponseWith status Rejected</td><td>5. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours> firmware.location <Configured firmware_location> firmware.retrieveDateTime <Current DateTime - 2 hours> firmware!' signature <Configured signingCertificate> firmware!' signature <Configured signature></td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequestWith status Downloaded</td><td>8. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>9. The Charging Station sends a FirmwareStatusNotificationRequestWith status SignatureVerified</td><td>10. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>11. The Charging Station notifies the CSMS about the current state of all connectors.Note(s):- This step is optional. The Charging Station may wants to set its connectors to Unavailable, before proceeding installing the new firmware.</td><td>12. The OCTT responds accordingly.</td></tr><tr><td></td><td colspan="2">13. Execute Reusable State RebootBeforeFirmwareInstallationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware installation.</td></tr><tr><td></td><td>14. The Charging Station sends a FirmwareStatusNotificationRequest With status InstallingNote(s): - This step only needs to be executed if the Charging Station did NOT reboot before firmware installation, at step 13.</td><td>15. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td colspan="2">16. Execute Reusable State RebootBeforeFirmwareActivationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.</td></tr><tr><td></td><td colspan="2">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.</td></tr><tr><td></td><td colspan="2">Note: Step 18 through 23 can be send in a different order.</td></tr><tr><td></td><td>18. The Charging Station notifies the CSMS about the current state of all connectors.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.</td><td>19. The OCTT responds accordingly.</td></tr><tr><td></td><td>20. The Charging Station sends a FirmwareStatusNotificationRequest With status Installed</td><td>21. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td>22. The Charging Station sends a SecurityEventNotificationRequest With type FirmwareUpdated</td><td>23. The OCTT responds with a SecurityEventNotificationResponse</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Secure Firmware Update - Unable to cancel</td></tr><tr><td>Tool validations</td><td>* 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 UnavailableOrMessage: 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 AvailableOrMessage: 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</td></tr><tr><td></td><td>Post scenario validations:N/a</td></tr></table>
+
+Table 306. Test Case Id: TC_L_12_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - Unable to download/install firmware with ongoing transaction -AllowNewSessionsPendingFirmwareUpdate is true</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_12_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.06,L01.FR.07,L01.FR.10,L01.FR.20</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">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.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">-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.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:AllowNewSessionsPendingFirmwareUpdate is true (If implemented)</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted for <Configured connectorId></td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponseWith status Accepted</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours> firmware.location <Configured firmware_location>firmware.retrieveDateTime <Current DateTime - 2 hours>firmware/signingCertificate <Configured signingCertificate>firmware!' signature <Configured signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequestWith status DownloadScheduled</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td colspan="2">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.</td></tr><tr><td colspan="2">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.</td></tr><tr><td colspan="2">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).</td></tr><tr><td rowspan="4"></td><td>8. The Charging Station sends a FirmwareStatusNotificationRequest With status Downloading</td><td>9. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>10. The Charging Station sends a FirmwareStatusNotificationRequest With status Downloaded</td><td>11. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>12. The Charging Station sends a FirmwareStatusNotificationRequest With status SignatureVerified</td><td>13. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>14. The Charging Station notifies the CSMS about the current state of all connectors.Note(s):- This step is optional. The Charging Station may wants to set its connectors to Unavailable, before proceeding installing the new firmware.</td><td>15. The OCTT responds accordingly.</td></tr><tr><td></td><td colspan="2">16. Execute Reusable State RebootBeforeFirmwareInstallationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware installation.</td></tr><tr><td></td><td>17. The Charging Station sends a FirmwareStatusNotificationRequest With status InstallingNote(s):- This step only needs to be executed if the Charging Station did NOT reboot before firmware installation, at step 16.</td><td>18. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td colspan="2">19. Execute Reusable State RebootBeforeFirmwareActivationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.</td></tr><tr><td rowspan="5"></td><td colspan="2">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.</td></tr><tr><td colspan="2">Note: Step 21 through 26 can be send in a different order.</td></tr><tr><td>21. The Charging Station notifies the CSMS about the current state of all connectors.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.</td><td>22. The OCTT responds accordingly.</td></tr><tr><td>23. The Charging Station sends a FirmwareStatusNotificationRequestWith status Installed</td><td>24. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>25. The Charging Station sends aSecurityEventNotificationRequestWith type FirmwareUpdated</td><td>26. The OCTT responds with a SecurityEventNotificationResponse</td></tr><tr><td>Test case name</td><td>Secure Firmware Update - Unable to download/install firmware with ongoing transaction -AllowNewSessionsPendingFirmwareUpdate is true</td></tr><tr><td>Tool validations</td><td>* 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 UnavailableOrMessage: 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 AvailableOrMessage: 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</td></tr><tr><td></td><td>Post scenario validations:N/a</td></tr></table>
+
+Table 307. Test Case Id: TC_L_13_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - Unable to download/install firmware with ongoing transaction -AllowNewSessionsPendingFirmwareUpdate is false</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_13_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.06,L01.FR.07,L01.FR.10,L01.FR.20</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">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.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">-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.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:AllowNewSessionsPendingFirmwareUpdate is false</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponseWith status Accepted</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours> firmware.location <Configured firmware_location> firmware.retrieveDateTime <Current DateTime - 2 hours> firmware/signingCertificate <Configured signingCertificate> firmwaresignature <Configured signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequestWith status DownloadScheduledNote: 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.</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>5. The Charging Station notifies the CSMS about the current state of its Available connector(s).Note(s):- This step needs to be executed for all connectors with AvailabilityState Available.</td><td>6. The OCTT responds accordingly.</td></tr><tr><td colspan="2">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).</td></tr><tr><td rowspan="4"></td><td>8. The Charging Station sends a FirmwareStatusNotificationRequest With status Downloading</td><td>9. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>10. The Charging Station sends a FirmwareStatusNotificationRequest With status Downloaded</td><td>11. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>12. The Charging Station sends a FirmwareStatusNotificationRequest With status SignatureVerified</td><td>13. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>14. The Charging Station notifies the CSMS about the current state of all connectors.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.</td><td>15. The OCTT responds accordingly.</td></tr><tr><td></td><td colspan="2">16. Execute Reusable State RebootBeforeFirmwareInstallationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware installation.</td></tr><tr><td></td><td>17. The Charging Station sends a FirmwareStatusNotificationRequest With status InstallingNote(s):- This step only needs to be executed if the Charging Station did NOT reboot before firmware installation, at step 16.</td><td>18. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td colspan="2">19. Execute Reusable State RebootBeforeFirmwareActivationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.</td></tr><tr><td rowspan="5"></td><td colspan="2">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.</td></tr><tr><td colspan="2">Note: Step 21 through 26 can be send in a different order.</td></tr><tr><td>21. The Charging Station notifies the CSMS about the current state of all connectors.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.</td><td>22. The OCTT responds accordingly.</td></tr><tr><td>23. The Charging Station sends a FirmwareStatusNotificationRequestWith status Installed</td><td>24. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>25. The Charging Station sends aSecurityEventNotificationRequestWith type FirmwareUpdated</td><td>26. The OCTT responds with a SecurityEventNotificationResponse</td></tr><tr><td>Test case name</td><td>Secure Firmware Update - Unable to download/install firmware with ongoing transaction -AllowNewSessionsPendingFirmwareUpdate is false</td></tr><tr><td>Tool validations</td><td>* Step 2:Message UpdateFirmwareResponse- status Accepted* Step 3:Message FirmwareStatusNotificationRequest- status DownloadScheduled* Step 5:Message: StatusNotificationRequest- connectorStatus UnavailableOrMessage: 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 UnavailableOrMessage: 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 AvailableOrMessage: 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</td></tr><tr><td></td><td>Post scenario validations:N/a</td></tr></table>
+
+Table 308. Test Case Id: TC_L_14_CS
+
+<table><tr><td>Test case name</td><td>Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -AllowNewSessionsPendingFirmwareUpdate is true</td></tr><tr><td>Test case Id</td><td>TC_L_14_CS</td></tr><tr><td>Use case Id(s)</td><td>L01</td></tr><tr><td>Requirement(s)</td><td>L01.FR.01,L01.FR.06,L01.FR.07,L01.FR.10,L01.FR.20</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>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 transaction(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.</td></tr><tr><td>Purpose</td><td>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.</td></tr><tr><td>Prerequisite(s)</td><td>-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.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td>Configuration State:AllowNewSessionsPendingFirmwareUpdate is true (If implemented)</td></tr><tr><td>Memory State:N/a</td></tr><tr><td>Reusable State(s):State is EnergyTransferStarted for EVSEld 1 and ConnectorId 1</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -AllowNewSessionsPendingFirmwareUpdate is true</td></tr><tr><td rowspan="10">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponseWith status Accepted</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours> firmware.location <Configured firmware_location> firmware.retrieveDateTime <Current DateTime - 2 hours> firmware signingCertificate <Configured signingCertificate> firmware!' signature <Configured signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequestWith status Downloading</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>5. The Charging Station sends a FirmwareStatusNotificationRequestWith status Downloaded</td><td>6. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequestWith status SignatureVerified</td><td>8. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>9. The Charging Station sends a FirmwareStatusNotificationRequestWith status InstallScheduled or status InstallingNote(s):- InstallScheduled only applies when Charging Station is not able to install while a transaction is active.</td><td>10. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td colspan="2">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.</td></tr><tr><td colspan="2">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.</td></tr><tr><td colspan="2">12. Execute Reusable State ParkingBayUnoccupied for <Configured connectorld>Note(s):- The Charging Station will proceed to this end state. This will cause the first transaction to stop.</td></tr><tr><td colspan="2">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).</td></tr><tr><td></td><td>14. The Charging Station notifies the CSMS about the current state of all connectors.Note(s):- This step is optional. The Charging Station may want to set its connectors to Unavailable, before proceeding installing the new firmware.</td><td>15. The OCTT responds accordingly.</td></tr><tr><td></td><td colspan="2">16. Execute Reusable State RebootBeforeFirmwareInstallationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware installation.</td></tr><tr><td></td><td>17. The Charging Station sends a FirmwareStatusNotificationRequest With status InstallingNote(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).</td><td>18. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td colspan="2">19. Execute Reusable State RebootBeforeFirmwareActivationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.</td></tr><tr><td></td><td colspan="2">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.</td></tr><tr><td></td><td colspan="2">Note: Step 21 through 26 can be sent in a different order.</td></tr><tr><td></td><td>21. The Charging Station notifies the CSMS about the current state of all connectors.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.</td><td>22. The OCTT responds accordingly.</td></tr><tr><td></td><td>23. The Charging Station sends a FirmwareStatusNotificationRequest With status Installed</td><td>24. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td>25. The Charging Station sends a SecurityEventNotificationRequest With type FirmwareUpdated</td><td>26. The OCTT responds with a SecurityEventNotificationResponse</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -AllowNewSessionsPendingFirmwareUpdate is true</td></tr><tr><td>Tool validations</td><td>* 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 UnavailableOrMessage: 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 AvailableOrMessage: 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</td></tr><tr><td></td><td>Post scenario validations:N/a</td></tr></table>
+
+Table 309. Test Case Id: TC_L_15_CS
+
+<table><tr><td>Test case name</td><td>Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -AllowNewSessionsPendingFirmwareUpdate is false</td></tr><tr><td>Test case Id</td><td>TC_L_15_CS</td></tr><tr><td>Use case Id(s)</td><td>L01</td></tr><tr><td>Requirement(s)</td><td>L01.FR.01,L01.FR.06,L01.FR.07,L01.FR.10,L01.FR.20</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>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 transaction(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.</td></tr><tr><td>Purpose</td><td>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.</td></tr><tr><td>Prerequisite(s)</td><td>-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.</td></tr><tr><td colspan="2"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td>Configuration State:AllowNewSessionsPendingFirmwareUpdate is false</td></tr><tr><td>Memory State:N/a</td></tr><tr><td>Reusable State(s):State is EnergyTransferStarted</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -AllowNewSessionsPendingFirmwareUpdate is false</td></tr><tr><td rowspan="8">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponseWith status Accepted</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours> firmware.location <Configured firmware_location> firmware.retrieveDateTime <Current DateTime - 2 hours> firmware signingCertificate <Configured signingCertificate> firmware(signature <Configured signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequest With status Downloading</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>5. The Charging Station sends a FirmwareStatusNotificationRequest With status Downloaded</td><td>6. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequest With status SignatureVerified</td><td>8. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>9. The Charging Station sends a FirmwareStatusNotificationRequest With status InstallScheduled or status Installing 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.</td><td>10. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>11. The Charging Station notifies the CSMS that its Available connector(s) have been set to Unavailable. Note(s): - This step needs to be executed for all connectors with AvailabilityState Available.</td><td>12. The OCTT responds accordingly.</td></tr><tr><td colspan="2">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.</td></tr><tr><td></td><td colspan="2">13. Execute Reusable State ParkingBayUnoccupied for <Configured connectorld>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).</td></tr><tr><td></td><td>14. The Charging Station notifies the CSMS about the current state of all connectors. Note(s): - This step is optional. The Charging Station may want to set its last connector to Unavailable, before proceeding installing the new firmware.</td><td>15. The OCTT responds accordingly.</td></tr><tr><td></td><td colspan="2">16. Execute Reusable State RebootBeforeFirmwareInstallationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware installation.</td></tr><tr><td></td><td>17. The Charging Station sends a FirmwareStatusNotificationRequest With status InstallingNote(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).</td><td>18. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td colspan="2">19. Execute Reusable State RebootBeforeFirmwareActivationNote: This step only needs to be executed if the Charging Station needs to reboot before firmware activation.</td></tr><tr><td></td><td colspan="2">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.</td></tr><tr><td></td><td colspan="2">Note: Step 21 through 26 can be sent in a different order.</td></tr><tr><td></td><td>21. The Charging Station notifies the CSMS about the current state of all connectors.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.</td><td>22. The OCTT responds accordingly.</td></tr><tr><td></td><td>23. The Charging Station sends a FirmwareStatusNotificationRequest With status Installed</td><td>24. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td></td><td>25. The Charging Station sends a SecurityEventNotificationRequest With type FirmwareUpdated</td><td>26. The OCTT responds with a SecurityEventNotificationResponse</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Secure Firmware Update - Unable to install and activate firmware with ongoing transaction -AllowNewSessionsPendingFirmwareUpdate is false</td></tr><tr><td>Tool validations</td><td>* 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 UnavailableOrMessage: 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 UnavailableOrMessage: 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 AvailableOrMessage: 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</td></tr><tr><td></td><td>Post scenario validations:N/a</td></tr></table>
+
+Table 310. Test Case Id: TC_L_16_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - Able to update firmware with ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_16_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.06,L01.FR.10,L01.FR.20</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to securely download and install a new firmware, while a transaction is ongoing.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">-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.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="9">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponse</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours>firmware.location <Configured firmware_location>firmware.retrieveDateTime <Current DateTime - 2 hours>firmware/signingCertificate <ConfiguredsigningCertificate>firmware!' signature <Configured signature></td></tr><tr><td>3. The Charging Station sends a FirmwareStatusNotificationRequest.With status Downloading</td><td>4. The OCTT responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>5. The Charging Station sends a FirmwareStatusNotificationRequest.With status Downloaded</td><td>6. The OCTT responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequest.With status SignatureVerified</td><td>8. The OCTT responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>9. The Charging Station sends a FirmwareStatusNotificationRequest.With status Installing</td><td>10. The OCTT responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td colspan="2">11. The OCTT waits for the Charging Station to reconnect.Note: The Charging Station reconnects to reestablish the protocol version handshake.</td></tr><tr><td>12. The Charging Station sends a FirmwareStatusNotificationRequest.With status Installed</td><td>13. The OCTT responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>14. The Charging Station sends a SecurityEventNotificationRequestWith type FirmwareUpdated</td><td>15. The OCTT responds with aSecurityEventNotificationResponse</td></tr><tr><td>Test case name</td><td>Secure Firmware Update - Able to update firmware with ongoing transaction</td></tr><tr><td rowspan="2">Tool validations</td><td>* 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</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 311. Test Case Id: TC_L_18_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - Missing firmware signing certificate and signature</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_18_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is not accepting a non-secure firmware update request, when supporting secure firmware update.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a UpdateFirmwareResponse</td><td>1. The OCTT sends a UpdateFirmwareRequest with firmware.installDateTime <Current DateTime - 2 hours>firmware.location <Configured firmware_location>firmware.retrieveDateTime <Current DateTime - 2 hours>firmware/signingCertificate is omittedfirmware(signature is omitted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message UpdateFirmwareResponse-status Rejected OR InvalidCertificate</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+# 2.14. M ISO 15118 CertificateManagement
+
+Table 312. Test Case Id: TC_M_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - CSMSRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.01,M05.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to install a new CSMSRootCertificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Security Profile 2 or 3.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">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.</td></tr><tr><td colspan="2">2. Execute Reusable State GetInstalledCertificates for certificateType CSMSRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 313. Test Case Id: TC_M_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - ManufacturerRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.01,M05.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to install a new ManufacturerRootCertificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports signed firmware updates.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State CertificateInstalled for certificateType ManufacturerRootCertificate</td></tr><tr><td colspan="2">2. Execute Reusable State GetInstalledCertificates for certificateType ManufacturerRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 314. Test Case Id: TC_M_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - V2GRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.01,M05.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to install a new V2GRootCertificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports ISO 15118.
+- The Charging Station does NOT have the following configuration; AdditionalRootCertificateCheck is implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State CertificateInstalled for certificateType V2GRootCertificate</td></tr><tr><td colspan="2">2. Execute Reusable State GetInstalledCertificates for certificateType V2GRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 315. Test Case Id: TC_M_04_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - MORootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.01,M05.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to install a new MORootCertificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports ISO 15118.
+- The Charging Station does NOT have the following configuration; AdditionalRootCertificateCheck is implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State CertificateInstalled for certificateType MORootCertificate</td></tr><tr><td colspan="2">2. Execute Reusable State GetInstalledCertificates for certificateType MORootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 316. Test Case Id: TC_M_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - Rejected - Certificate invalid</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.01,M05.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reject an invalid certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Security Profile 2 or 3.
+- The Charging Station does NOT have the following configuration; AdditionalRootCertificateCheck is implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a InstallCertificateResponse</td><td>1. The OCTT sends a InstallCertificateRequest with certificateType is CSMSRootCertificate certificate is <Generated Expired Certificate></td></tr><tr><td>4. The Charging Station responds with a GetInstalledCertificatesResponse</td><td>3. The OCTT sends a GetInstalledCertificatesRequest with certificateType is CSMSRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: InstallCertificateResponse
+- status must be Rejected
+* Step 4:
+Message: GetInstalledCertificatesResponse
+- status must be Accepted
+- certificateDataChain must NOT contain an entry with following values:
+Note: Order does not matter.
+- certificateType is CSMSRootCertificate
+- certificateData contains <HashData from configured new CSMS Root certificate></td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 317. Test Case Id: TC_M_09_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - AdditionalRootCertificateCheck - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_09_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.10,M05.FR.11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reject installing a new CSMSRootCertificate that is not signed by the old CSMSRootCertificate, while additional security measures for installing a root certificate is active.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Security Profile 2 or 3.
+- The Charging Station has the configuration variable AdditionalRootCertificateCheck implemented with value true</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a InstallCertificateResponse</td><td>1. The OCTT sends a InstallCertificateRequest with certificateType is CSMSRootCertificate certificate is <Configured CSMSRootCertificate> Note(s): - CSMSRootCertificate must have not been signed by old certificate.</td></tr><tr><td>4. The Charging Station responds with a GetInstalledCertificatesResponse</td><td>3. The OCTT sends a GetInstalledCertificatesRequest with certificateType is CSMSRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: InstallCertificateResponse - status must be Rejected * Step 4: Message: GetInstalledCertificatesResponse - status must be Accepted - certificateDataChain must contain one entry with following values: - certificateType is CSMSRootCertificate - certificateData contains <Data from configured old CSMS Root certificate></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 318. Test Case Id: TC_M_30_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - AdditionalRootCertificateCheck - Reconnect using new CSMS Root - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_30_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reconnect to the CSMS, while using a new CSMS Root certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Security Profile 2 or 3. - The Charging Station has the configuration variable AdditionalRootCertificateCheck implemented with value true
+- The at the OCTT configured new CSMSRootCertificate must be signed by the old CSMS Root certificate.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+CertificatesInstalled for certificateType CSMSRootCertificate and certificate <Configured new CSMS Root certificate 2>
+If security profile 3 is enabled, then:
+RenewChargingStationCertificate for certificateType ChargingStationCertificate</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="5">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type OnIdle</td></tr><tr><td>4. During the TLS handshake the Charging Station validates the CSMS certificate.
+Note(s):
+- This connection attempt must succeed.</td><td>3. During the TLS handshake the OCTT provides a CSMS certificate which is signed by the <Configured new CSMS Root certificate></td></tr><tr><td colspan="2">5. Execute Reusable State Booted</td></tr><tr><td>7. The Charging Station responds with a GetInstalledCertificatesResponse</td><td>6. The OCTT sends a GetInstalledCertificatesRequest with certificateType is CSMSRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message ResetResponse
+- status Accepted
+* Step 7:
+Message: GetInstalledCertificatesResponse
+- status must be Accepted
+- certificateDataChain must NOT contain an entry with following values:
+- certificateType is CSMSRootCertificate
+- certificateData contains <Data from configured old CSMS Root certificate></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 319. Test Case Id: TC_M_31_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - AdditionalRootCertificateCheck - Reconnect using new CSMS Root - Fallback mechanism</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_31_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to reconnect to the CSMS using the old CSMS Root certificate, when validating the CSMS certificate using the new CSMS Root certificate fails.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Security Profile 2 or 3. - The Charging Station has the configuration variable AdditionalRootCertificateCheck implemented with value true
+- The at the OCTT configured new CSMSRootCertificate must be signed by the old CSMS Root certificate.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+CertificatesInstalled for certificateType CSMSRootCertificate and certificate <Configured (new) CSMS Root certificate 2></td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="6">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type OnIdle</td></tr><tr><td>4. During the TLS handshake the Charging Station validates the CSMS certificate.
+Note(s):
+- This connection attempt fails, because the Charging Station will use the new CSMS Root certificate to validate the CSMS certificate.</td><td>3. During the TLS handshake the OCTT provides a CSMS certificate which is signed by the <Configured old CSMS Root certificate></td></tr><tr><td>5. The Charging Station re-validates the CSMS certificate.
+Note(s):
+- This connection attempt succeeds, because the Charging Station will now use the old CSMS Root certificate to validate the CSMS certificate.</td><td></td></tr><tr><td colspan="2">6. Execute Reusable State Booted</td></tr><tr><td>8. The Charging Station responds with a GetInstalledCertificatesResponse</td><td>7. The OCTT sends a GetInstalledCertificatesRequest with certificateType is CSMSRootCertificate</td></tr><tr><td>Test case name</td><td>Install CA certificate - AdditionalRootCertificateCheck - Reconnect using new CSMS Root - Fallback mechanism</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message ResetResponse
+- status Accepted
+* Step 8:
+Message: GetInstalledCertificatesResponse
+- status must be Accepted
+- certificateDataChain must contain an entry with following values:
+- certificateType is CSMSRootCertificate
+- certificateData contains <Data from configured old CSMS Root certificate></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 320. Test Case Id: TC_M_12_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - CSMSRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_12_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01,M03.FR.03,M03.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to provide the hashData from all stored CSMSRootCertificates.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Security Profile 2 or 3.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: CertificateInstalled from certificateType CSMSRootCertificate</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates for certificateType CSMSRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 321. Test Case Id: TC_M_13_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - ManufacturerRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_13_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01,M03.FR.03,M03.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to provide the hashData from all stored ManufacturerRootCertificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports signed firmware updates.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: CertificateInstalled from certificateType ManufacturerRootCertificate</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates for certificateType ManufacturerRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 322. Test Case Id: TC_M_14_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - V2GRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_14_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01,M03.FR.03,M03.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to provide the hashData from all stored V2GRootCertificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports ISO 15118.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: CertificateInstalled from certificateType V2GRootCertificate</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates for certificateType V2GRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 323. Test Case Id: TC_M_15_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - V2GCertificateChain</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_15_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01,M03.FR.03,M03.FR.04,M03.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to provide the hashData from all stored certificates that are part of a V2GCertificateChain.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports ISO 15118.
+- The Charging Station has atleast one V2GCertificateChain installed.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates for certificateType V2GCertificateChain</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: GetInstalledCertificatesResponse
+- status must be Accepted
+- certificateHashDataChain must contain an entry with following values:
+Note: Order does not matter.
+- certificateType is V2GCertificateChain
+- certificateHashData uses the childCertificateHashData field</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 324. Test Case Id: TC_M_16_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - MORootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_16_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01,M03.FR.03,M03.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to provide the hashData from all stored MORootCertificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports ISO 15118.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: CertificateInstalled from certificateType MORootCertificate</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates for certificateType MORootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 325. Test Case Id: TC_M_17_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - CSMSRootCertificate & ManufacturerRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_17_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01,M03.FR.03,M03.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to provide the hashData from all stored CSMSRootCertificates and ManufacturerRootCertificates</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Security Profile 2 or 3.
+- The Charging Station supports signed firmware updates.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+CertificateInstalled from certificateType CSMSRootCertificate
+CertificateInstalled from certificateType ManufacturerRootCertificate</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates for certificateType CSMSRootCertificate AND ManufacturerRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 326. Test Case Id: TC_M_18_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - All certificateTypes</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_18_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01,M03.FR.03,M03.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to provide the hashData from all stored certificates</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Security Profile 2 or 3.
+- The Charging Station supports signed firmware updates.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+CertificateInstalled from certificateType CSMSRootCertificate
+CertificateInstalled from certificateType ManufacturerRootCertificate</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetInstalledCertificatesResponse</td><td>1. The OCTT sends a GetInstalledCertificatesRequest
+With certificateType is omitted.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: GetInstalledCertificatesResponse
+- status must be Accepted
+- certificateHashDataChain must contain the following two entries with following values:
+Note: Order does not matter.
+Entry 1:
+- certificateHashDataChain[0].certificatuType is CSMSRootCertificate
+- certificateHashDataChain[0].certificatuData contains <HashData from configured new CSMS Root certificate>
+Entry 2:
+- certificateHashDataChain[1].certificatuType is ManufacturerRootCertificate
+- certificateHashDataChain[1].certificatuData contains <HashData from configured new Manufacturer Root certificate></td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 327. Test Case Id: TC_M_19_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - No matching certificate found</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_19_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01,M03.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond that it did not find any certificate of the requested certificateType.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station does not have a MORootCertificate installed, or it must be possible to remove it.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:OCTT checks to make sure that no MORootCertificate is installed via GetInstalledCertificates. If an MORootCertificate exists it removes it via DeleteCertificate.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetInstalledCertificatesResponse</td><td>1. The OCTT sends a GetInstalledCertificatesRequestWith certificateType is MORootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: GetInstalledCertificatesResponse-status must be NotFound- certificateHashDataChain must be omitted.</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 328. Test Case Id: TC_M_20_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Delete a certificate from a Charging Station - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_20_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M04</td></tr><tr><td>Requirement(s)</td><td colspan="2">M04.FR.01,M04.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to delete an installed certificate using the DeleteCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to delete an installed certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Security Profile 2 or 3.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):GetInstalledCertificates with certificateType CSMSRootCertificateCertificateInstalled with certificateType CSMSRootCertificate (When no certificate is returned at GetInstalledCertificates)</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates with certificateType CSMSRootCertificate</td></tr><tr><td>3. The Charging Station responds with a DeleteCertificateResponse</td><td>2. The OCTT sends a DeleteCertificateRequest with certificateData contains <Returned certificateHashData at step 1></td></tr><tr><td colspan="2">4. Execute Reusable State GetInstalledCertificates with certificateType CSMSRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:- Certificate that is going to be deleted is present.* Step 3:Message: DeleteCertificateResponse-status must be Accepted* Step 4:- Certificate that should be deleted is not present anymore.</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 329. Test Case Id: TC_M_22_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Delete a certificate from a Charging Station - No matching certificate found</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_22_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M04</td></tr><tr><td>Requirement(s)</td><td colspan="2">M04.FR.01,M04.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to delete an installed certificate using the DeleteCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond that no certificate is installed that matches the provided certificateHashData.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Security Profile 2 or 3.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates with certificateType CSMSRootCertificate.</td></tr><tr><td>3. The Charging Station responds with a DeleteCertificateResponse</td><td>2. The OCTT sends a DeleteCertificateRequest with certificateHashData is <certificateHashData from unknown certificate></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3: Message: DeleteCertificateResponse - status must be NotFound</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 330. Test Case Id: TC_M_23_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Delete a certificate from a Charging Station - Unable to delete the Charging Station Certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_23_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M04</td></tr><tr><td>Requirement(s)</td><td colspan="2">M04.FR.01,M04.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to delete an installed certificate using the DeleteCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station does NOT allow the deletion of the Charging Station certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports Security Profile 3.
+- A valid CSMSRootCertificate is installed on the Charging Station.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+RenewChargingStationCertificate for certificateType ChargingStationCertificate</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates with certificateType omitted.</td></tr><tr><td>3. The Charging Station responds with a DeleteCertificateResponse</td><td>2. The OCTT sends a DeleteCertificateRequest with certificateHashData is <certificateHashData from the generated ChargingStationCertificate at before.></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3:
+Message: DeleteCertificateResponse
+- status must be NotFound OR Failed</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 331. Test Case Id: TC_M_24_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Station Certificate status - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_24_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M06</td></tr><tr><td>Requirement(s)</td><td colspan="2">M06.FR.06,M06.FR.07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is able to request the CSMS to get the status of a (V2G) Charging Station certificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to request the status of a (V2G) Charging Station certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports ISO 15118.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:CertificateInstalled from certificateType V2GRootCertificateCertificateInstalled from certificateType MORootCertificateRenewV2GChargingStationCertificate</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends aGetCertificateStatusRequest</td><td>2. The OCTT responds with aGetCertificateStatusResponsewith status AcceptedocspResult <OCSPResponse class as defined in IETF RFC 6960. DER encoded (as defined in IETF RFC 6960), and then base64 encoded.></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 332. Test Case Id: TC_M_25_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Station Certificate status - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_25_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M06</td></tr><tr><td>Requirement(s)</td><td colspan="2">M06.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is able to request the CSMS to get the status of a (V2G) Charging Station certificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to handle receiving a rejected status after requesting the status of a (V2G) Charging Station certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports ISO 15118.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:CertificatesInstalled from certificateType V2GRootCertificateCertificatesInstalled from certificateType MORootCertificateRenewV2GChargingStationCertificate</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends aGetCertificateStatusRequest</td><td>2. The OCTT responds with aGetCertificateStatusResponsewith status FailedocspResult is omitted.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 333. Test Case Id: TC_M_26_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Certificate Installation EV - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_26_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M01</td></tr><tr><td>Requirement(s)</td><td colspan="2">M01.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The EV initiates installing a new certificate. The Charging Station forwards the request for a new certificate to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to forward the request to the CSMS.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports ISO 15118.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:-The test case calls SendISO15118AuthorizationMethod method with parameter PnC in order to inform the EV emulator about the expected authorization method.-The test case calls SendInstallISO15118CertificateMethod method in order to trigger the EV emulator to initiate installing a new certificate.</td></tr><tr><td colspan="2">Memory State:CertificatesInstalled from certificateType V2GRootCertificateCertificatesInstalled from certificateType MORootCertificate</td></tr><tr><td colspan="2">Reusable State(s):State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends aGet15118EVCertificateRequest</td><td>2. The OCTT responds with aGet15118EVCertificateResponsewith status AcceptedexiResponse <Raw CertificateInstallationResresponse for the EV, Base64 encoded.></td></tr><tr><td>3. The Charging Station sends an AuthorizationRequest</td><td>4. The OCTT responds with an AuthorizationResponsewith status Accepted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: Get15118EVCertificateRequest- action must be Install</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 334. Test Case Id: TC_M_27_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Certificate Installation EV - Failed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_27_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The EV initiates installing a new certificate. The Charging Station forwards the request for a new certificate to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to handle receiving a Failed status.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports ISO 15118.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:-The test case calls SendISO15118AuthorizationMethod method with parameter PnC in order to inform the EV emulator about the expected authorization method.-The test case calls SendInstallISO15118CertificateMethod method in order to trigger the EV emulator to initiate installing a new certificate.</td></tr><tr><td colspan="2">Memory State:CertificateInstalled from certificateType V2GRootCertificateCertificateInstalled from certificateType MORootCertificate</td></tr><tr><td colspan="2">Reusable State(s):State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends aGet15118EVCertificateRequest</td><td>2. The OCTT responds with aGet15118EVCertificateResponsewith status FailedexiResponse is omitted</td></tr><tr><td></td><td>3. If an AuthorizationRequest is received, the testcase will FAIL and the OCTT reports why it failed.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: Get15118EVCertificateRequest- action must be Install</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 335. Test Case Id: TC_M_28_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Certificate Update EV - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_28_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M02</td></tr><tr><td>Requirement(s)</td><td colspan="2">M02.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The EV initiates updating the existing certificate. The Charging Station forwards the update request to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to forward the request to the CSMS.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports ISO 15118.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:ISO15118Ctrlr.ContractCertificateInstallationEnabled is true-The test case calls Send/ISO15118AuthorizationMethod method with parameter PnC in order to inform the EV emulator about the expected authorization method.-The test case calls SendInstall/ISO15118CertificateMethod method in order to trigger the EV emulator to initiate installing a new certificate.</td></tr><tr><td colspan="2">Memory State:CertificateInstalled from certificateType V2GRootCertificateCertificateInstalled from certificateType MORootCertificate</td></tr><tr><td colspan="2">Reusable State(s):State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends aGet15118EVCertificateRequest</td><td>2. The OCTT responds with aGet15118EVCertificateResponsewith status AcceptedexiResponse <Raw CertificateInstallationResresponse for the EV, Base64 encoded.></td></tr><tr><td>3. The Charging Station sends an AuthorizationRequest</td><td>4. The OCTT responds with an AuthorizationResponsewith status Accepted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: Get15118EVCertificateRequest- action must be Update</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 336. Test Case Id: TC_M_29_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Certificate Update EV - Failed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_29_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M02</td></tr><tr><td>Requirement(s)</td><td colspan="2">M02.FR.01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The EV initiates updating the existing certificate. The Charging Station forwards the update request to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to forward the request to the CSMS.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station supports ISO 15118.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:ISO15118Ctrlr.ContractCertificateInstallationEnabled is true-The test case calls SendISO15118AuthorizationMethod method with parameter PnC in order to inform the EV emulator about the expected authorization method.-The test case calls SendInstallISO15118CertificateMethod method in order to trigger the EV emulator to initiate installing a new certificate.</td></tr><tr><td colspan="2">Memory State:CertificateInstalled from certificateType V2GRootCertificateCertificateInstalled from certificateType MORootCertificate</td></tr><tr><td colspan="2">Reusable State(s):State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends aGet15118EVCertificateRequest</td><td>2. The OCTT responds with aGet15118EVCertificateResponsewith status FailedexiResponse is omitted.</td></tr><tr><td></td><td>3. If an AuthorizationRequest is received, the testcase will FAIL and the OCTT reports why it failed.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: Get15118EVCertificateRequest- action must be Update</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+# 2.15. N Diagnostics
+
+Table 337. Test Case Id: TC_N_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Monitoring Report - with monitoringCriteria</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N02.FR.01, N02.FR.03,N02.FR.04, N02.FR.05, N02.FR.06, N02.FR.09, N02.FR.12, N02.FR.13, N02.FR.14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a report of all monitors that match the given monitoringCriteria: Threshold, Delta or Periodic.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports reporting of monitoring via monitoringCriteria. Starting with ThresholdMonitoring and then extending the set to check that combinations are handled properly.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="91">Before(Preparations)</td><td colspan="2" rowspan="81">Configuration State:The following monitors (on arbitrary variables) must be present as 'hard-wired' or 'preconfigured' or must have been configured by CSMS:- LowerThreshold- UpperThreshold-Delta- Periodic- PeriodicClockAligned</td></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr></tr><tr><td colspan="2">Step 7 and 8 are repeated as often as needed to report all configuration variables.</td></tr><tr><td colspan="2">Step 7 and 8 are repeated as often as needed to report all configuration variables.</td></tr><tr><td colspan="2">Step 7 and 8 are repeated as often as needed to report all configuration variables.</td></tr><tr><td colspan="2">Step 7 and 8 are repeated as often as needed to report all configuration variables.</td></tr><tr><td colspan="2">Step 7 and 8 are repeated as often as needed to report all configuration variables.</td></tr><tr><td colspan="2">Step 7and 8 are repeated as often as needed to report all configuration variables.</td></tr><tr><td colspan="2">Step 7 and 8 are repeated as often as needed to report all configuration variables.</td></tr><tr><td colspan="2">Step 7 and 8 are repeated as often as needed to report all configuration variables.</td></tr><tr><td colspan="2">Step 7 and 8 are repeated as often as needed to report all configuration variables.</td></tr><tr><td colspan="2">Step 7 and 8 are repeated as often as need to report all configuration variables.</td></tr><tr><td>Test case name</td><td>Get Monitoring Report - with monitoringCriteria</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:Message: GetMonitoringReportResponse- status = Accepted- statusInfo is absent or statusInforeasonCode = "NoError"* Step 3:Message: NotifyMonitoringReportRequest- requestId = <Generated requestId>generatedAt = <timestamp at charging station> - seqNo = 0-monitor variableMonitoring.type = UpperThreshold or LowerThresholdWhile tbc = trueMessage: NotifyMonitoringReportRequest- seqNo is incremented by 1-monitor variableMonitoring.type = UpperThreshold or LowerThreshold* Step 6:Message: GetMonitoringReportResponse- status = Accepted- statusInfo is absent or statusInfo_reasonCode = "NoError"* Step 7:Message: NotifyMonitoringReportRequest- requestId = <Generated requestId>generatedAt = <timestamp at charging station> - seqNo = 0-monitor variableMonitoring.type = UpperThreshold, LowerThreshold or DeltaWhile tbc = trueMessage: NotifyMonitoringReportRequest- seqNo is incremented by 1-monitor variableMonitoring.type = UpperThreshold, LowerThreshold or Delta* Step 10:Message: GetMonitoringReportResponse- status = Accepted- statusInfo is absent or statusInfo_reasonCode = "NoError"* Step 11:Message: NotifyMonitoringReportRequest- requestId = <Generated requestId>generatedAt = <timestamp at charging station> - seqNo = 0-monitor variableMonitoring.type = Delta, Periodic or PeriodicClockAlignedWhile tbc = trueMessage: NotifyMonitoringReportRequest- seqNo is incremented by 1-monitor variableMonitoring.type = Delta, Periodic or PeriodicClockAligned</td></tr><tr><td>Post scenario validations:N/A</td></tr></table>
+
+Table 338. Test Case Id: TC_N_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Monitoring Report - with component/variable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N02.FR.01, N02.FR.03,N02.FR.04, N02.FR.05, N02.FR.08, N02.FR.09</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a report of monitors that match the given list of components and variables.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports reporting of monitoring via for a given list of components and optionally with variables.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a Note: these are required variables for which a monitor can be expected to exist or it can be configured.</td></tr><tr><td colspan="2">Memory State:The following monitors must be present as 'hard-wired' or 'preconfigured' or must have been configured by CSMS:- Component "ChargingStation", variable "AvailabilityState", monitor type Delta"- Component "EVSE",<Configured evseld>, variable "AvailabilityState", monitor type Delta</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:GetMonitoringReportResponse</td><td>1. OCTT sends GetMonitoringReportRequest with:- requestId = <Generated requestId>- monitoringCriteria is omitted-componentVariable[0].component.name = "ChargingStation"- componentVariable[0].component.name = "AvailabilityState"- componentVariable[1].component.name = "EVSE"- componentVariable[1].component.eve.sid = <Configured evseld>_Note: requesting AvailabilityState fromChargingStation and all monitors from Configured EVSE</td></tr><tr><td>3. Charging Station responds with:NotifyMonitoringReportRequest</td><td>4. OCTT sends NotifyMonitoringReportResponse</td></tr><tr><td colspan="2">Step 3 and 4 are repeated as often as needed to report all configuration variables.</td></tr><tr><td rowspan="4">Tool validations</td><td colspan="2">* Step 2:
+Message: GetMonitoringReportResponse
+- status = Accepted
+- statusInfo is absent or statusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">* Step 3:
+Message: NotifyMonitoringReportRequest
+- requestId = <Generated requestId>
+-generatedAt = <timestamp at charging station>
+- seqNo = 0
+-if monitor(variable = "AvailabilityState" then monitor variableMonitoring.type = Delta
+Note: fore EVSE #1 we request all monitors. There may be other monitors besides AvailabilityState.</td></tr><tr><td>While tbc = true</td><td>Message: NotifyMonitoringReportRequest
+- seqNo is incremented by 1
+-monitor(variable = "AvailabilityState"
+-monitor(variableMonitoring.type = Delta
+-monitor.parent_name = ChargingStation or EVSE</td></tr><tr><td colspan="2">Post scenario validations:
+Check that a monitor for AvailabilityState of type Delta is reported for both ChargingStation and CConfigured EVSE. If other monitors are present on Configured EVSE, then they will also be reported.</td></tr></table>
+
+Table 339. Test Case Id: TC_N_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Monitoring Report - with component criteria and component/variable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N02.FR.01, N02.FR.03,N02.FR.04, N02.FR.05, N02.FR.09, N02.FR.10, N02.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a report of monitors that match both the component criteria and the given list of components and variables.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports reporting of monitoring for both the component criteria and a given list of components and optionally with variables.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:The following monitors must be present as 'hard-wired' or 'preconfigured' or must have been configured by CSMS:- Component "ChargingStation", variable "Power", monitor type Periodic- Component "EVSE", evse <Configured evseld>, variable "AvailabilityState", monitor type DeltaNote: these are required variables for which a monitor can be expected to exist or it can be configured.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:GetMonitoringReportResponse</td><td>1. OCTT sends GetMonitoringReportRequest with:- requestId = <Generated requestId> - monitoringCriteria is ThresholdMonitoring - componentVariable[0].component.name = "ChargingStation" - componentVariable[0].variable.name = "AvailabilityState" - componentVariable[1].component.name = "EVSE" - componentVariable[1].component.evse.id = <Configured evseld> - componentVariable[1].variable.name = "AvailabilityState" Note: requesting AvailabilityState from ChargingStation and Configured EVSE, but filtered to _ThresholdMonitoring_.</td></tr><tr><td rowspan="3"></td><td>4. Charging Station responds with:GetMonitoringReportResponse</td><td>3. OCTT sends GetMonitoringReportRequest with:- requestId = <Generated requestId> - monitoringCriteria is DeltaMonitoring - componentVariable[0].component.name = "ChargingStation" - componentVariable[0].component.name = "AvailabilityState" - componentVariable[1].component.name = "EVSE" - componentVariable[1].component.evse.id = <Configured evseld> - componentVariable[1].component.name = "AvailabilityState" Note: requesting AvailabilityState from ChargingStation and Configured EVSE, but filtered to _Delta_.</td></tr><tr><td>5. Charging Station responds with:NotifyMonitoringReportRequest</td><td>6. OCTT sends NotifyMonitoringReportResponse</td></tr><tr><td colspan="2">Step 5 and 6 are repeated as often as needed to report all configuration variables.</td></tr><tr><td>Test case name</td><td>Get Monitoring Report - with component criteria and component/variable</td></tr><tr><td rowspan="3">Tool validations</td><td>* Step 2:
+Message: GetMonitoringReportResponse
+- status = EmptyResultSet
+- statusInfo is absent or statusInforeasonCode = "NotFound"
+* Step 4:
+Message: GetMonitoringReportResponse
+- status = Accepted
+- statusInfo is absent or statusInforeasonCode = "NoError"
+* Step 5:
+Message: NotifyMonitoringReportRequest
+- requestId = <Generated requestId>
+-generatedAt = <timestamp at charging station>
+- seqNo = 0
+-monitor variableMonitoring.type = Delta</td></tr><tr><td>While tbc = true
+Message: NotifyMonitoringReportRequest
+-seqNo is incremented by 1
+-monitor variableMonitoring.type = Delta</td></tr><tr><td>Post scenario validations:
+Check that nothing is reported for requestId = <Generated requestId1> and a monitor for AvailabilityState of type Delta is reported for both ChargingStation and EVSE #1 for requestId = <Generated requestId2>.</td></tr></table>
+
+NOTE
+
+Test Case Id: TC_N_04_CS
+
+Since MonitoringCriterionEnum is defined as enumeration, this will most likely already be caught by the JSON parser.
+
+<table><tr><td>Test case name</td><td colspan="2">Get Monitoring Report - for unknown component criteria</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N02.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS sends a GetMonitoringReport with an invalid value in monitoringCriteria.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station returns a NotSupported return code in response to an invalid value for monitoringCriteria.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. Charging Station responds with: GetMonitoringReportResponse</td><td>2. OCTT sends GetMonitoringReportRequest with: - requestId = <Generated requestId> - monitoringCriteria = {DeltaMonitoring, <Configured Unsupported monitoringCriteria>} - *componentVariable is absent</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1
+Message: GetMonitoringReportResponse
+- status = NotSupported
+- statusInfo is absent or statusInforeasonCode = "UnsupportedParam" or statusInforeasonCode = "InvalidValue"</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 340. Test Case Id: TC_N_05_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Monitoring Base - success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_05_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N03.FR.01, N03.FR.03, N03.FR.04, N03.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS sends a SetMonitoringBaseRequest for All, FactoryDefault and HardWiredOnly.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports all three monitoring base types.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:SetMonitoringBaseResponse</td><td>1. OCTT sends SetMonitoringBaseRequest with:- monitoringBase = All</td></tr><tr><td>4. Charging Station responds with:SetMonitoringBaseResponse</td><td>3. OCTT sends SetMonitoringBaseRequest with:- monitoringBase = FactoryDefault</td></tr><tr><td>6. Charging Station responds with:SetMonitoringBaseResponse</td><td>5. OCTT sends SetMonitoringBaseRequest with:- monitoringBase = HardWiredOnly</td></tr><tr><td rowspan="4">Tool validations</td><td colspan="2">* Step 2Message: SetMonitoringBaseResponse-status = Accepted-statusInfo is absent or statusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">* Step 4Message: SetMonitoringBaseResponse-status = Accepted-statusInfo is absent or statusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">* Step 6Message: SetMonitoringBaseResponse-status = Accepted-statusInfo is absent or statusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 341. Test Case Id: TC_N_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Monitoring Base - test removal custom monitors</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_06_CS</td></tr><tr><td>Use case ld(s)</td><td colspan="2">N03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N03.FR.01, N03.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS sends a SetMonitoringBaseRequest for HardWiredOnly.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station removes custom monitors when selecting a monitoring base, as specified explicitly in N03.FR.05 and less formally in the remark of the use case N03.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:The following monitor must be present as 'preconfigured' or custom monitor configured by CSMS:- Component "ChargingStation", variable "AvailabilityState", monitor type DeltaIf it exists as a hardwired monitor, then the test will fail, because the test checks that it is removed when reverting back to only hardwired monitors.Note: this is a required variable for which a monitor can be expected to exist or it can be configured.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Check that monitor AvailabilityState exists.</td></tr><tr><td>2. Charging Station responds with:GetMonitoringReportResponse</td><td>1. OCTT sends GetMonitoringReportRequest with:- requestId = <Generated requestId> - monitoringCriteria is absent - componentVariable[0].component.name = "ChargingStation" - componentVariable[0].variable.name = "AvailabilityState"</td></tr><tr><td>3. Charging Station responds with:NotifyMonitoringReportRequest</td><td>4. OCTT sends NotifyMonitoringReportResponse</td></tr><tr><td>6. Charging Station responds with:SetMonitoringBaseResponse</td><td>5. OCTT sends SetMonitoringBaseRequest with: - monitoringBase = HardWiredOnly</td></tr><tr><td colspan="2">Check that monitor AvailabilityState has been removed.</td></tr><tr><td>8. Charging Station responds with:GetMonitoringReportResponse</td><td>7. OCTT sends GetMonitoringReportRequest with:- requestId = <Generated requestId> - monitoringCriteria is absent - componentVariable[0].component.name = "ChargingStation" - componentVariable[0].variable.name = "AvailabilityState"</td></tr><tr><td>Test case name</td><td>Set Monitoring Base - test removal custom monitors</td></tr><tr><td rowspan="4">Tool validations</td><td>* Step 2
+Message: GetMonitoringReportResponse
+- status = Accepted
+- statusInfo is absent or statusInforeasonCode = "NoError"</td></tr><tr><td>* Step 3:
+Message: NotifyMonitoringReportRequest
+- requestId = <Generated requestId>
+-generatedAt = <timestamp at charging station>
+- seqNo = 0
+-tbc is absent or tbc = false
+-monitor variableMonitoring.type = Delta
+-monitor_component.name = "ChargingStation"
+-monitor(variable.name = "AvailabilityState"</td></tr><tr><td>* Step 6
+Message: SetMonitoringBaseResponse
+- status = Accepted
+-statusInfo is absent or statusInforeasonCode = "NoError"</td></tr><tr><td>* Step 8
+Message: GetMonitoringReportResponse
+- status = EmptyResultSet
+-statusInfo is absent or statusInforeasonCode = "NotFound"</td></tr></table>
+
+NOTE
+
+Test Case Id: TC_N_07_CS
+
+Since MonitoringBaseEnumType is defined as enumeration, this will most likely already be caught by the JSON parser.
+
+<table><tr><td>Test case name</td><td colspan="2">Set Monitoring Base - for unknown base type</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N03.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS send a SetMonitoringBase with an invalid value in monitoringBase.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station returns a NotSupported return code in response to an invalid value for monitoringBase.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with: SetMonitoringBaseResponse</td><td>1. OCTT sends SetMonitoringBaseRequest with: - monitoringBase = <Configured unsupported_monitoringBase></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2
+Message: SetMonitoringBaseResponse
+- status = NotSupported
+- statusInfo is absent or statusInforeasonCode = "UnsupportedParam" or statusInforeasonCode = "InvalidValue"</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 342. Test Case Id: TC_N_08_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - one setMonitoringData element</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_08_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.01, N04.FR.02, N04.FR.08, N04.FR.11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS sends a request to activate a monitor on a single variable.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports setting of a monitor on a variable.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:This test case activates a monitor on the following variable:- Component "EVSE", evse "1", variable "AvailabilityState", monitor type DeltaIt assumes, that no monitor is active on this variable prior to the test.Note: this is a required variable for which a monitor can be expected to exist or it can be configured.Note 2: Any other component/variable combination that supports monitoring could also be used for this test case.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:SetVariableMonitoringResponse</td><td>Install monitor1. OCTT sends SetVariableMonitoringRequest with:- setMonitoringData.value = 1- setMonitoringData.type = Delta- setMonitoringData.severity = 8-setMonitoringData:EveSe.id =<Configured evseld>- setMonitoringData:EveSe.id ="AvailabilityState"</td></tr><tr><td>4. Charging Station responds with:GetMonitoringReportResponse</td><td>Verify monitor is installed3. OCTT sends GetMonitoringReportRequest with:- requestId =<Generated requestId>- monitoringCriteria is absent-componentVariable[0].component.name = "EVSE"- componentVariable[0].component.evse.id =<Configured evseld>- componentVariable[0].variable.name ="AvailabilityState"</td></tr><tr><td>5. Charging Station responds with:NotifyMonitoringReportRequest</td><td>6. OCTT sends NotifyMonitoringReportResponse</td></tr><tr><td>Test case name</td><td>Set Variable Monitoring - one setMonitoringData element</td></tr><tr><td rowspan="4">Tool validations</td><td>* Step 2:
+Message: SetVariableMonitoringResponse with:
+setMonitoringResult = {
+- status = Accepted
+- type = Delta
+- severity = 8
+- component.name = "EVSE"
+- component.evse.id = <Configured evseld>
+- variable.name = "AvailabilityState"
+- statusInfo is absent or statusInforeasonCode = "NoError" }</td></tr><tr><td>* Step 4:
+Message: GetMonitoringReportResponse
+- status = Accepted
+- statusInfo is absent or statusInforeasonCode = "NoError"</td></tr><tr><td>* Step 5:
+Message: NotifyMonitoringReportRequest
+- requestId = <Generated requestId>
+- monitor(variableMonitoring.type = Delta
+- monitor.elementname = "EVSE"
+- monitor.elementevse.id = <Configured evseld>
+- monitor(variable.name = "AvailabilityState"</td></tr><tr><td>Post scenario validations:</td></tr></table>
+
+Table 343. Test Case Id: TC_N_09_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Multiple elements on different component and variable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_09_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.01, N04.FR.02, N04.FR.08, N04.FR.11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS sends a request to activate monitors on different variables.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports setting of multiple monitors on different variables.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:This test case activates monitors on the following variables:- Component "EVSE", evse "1", variable "AvailabilityState", monitor type Delta- Component "ChargingStation", variable "AvailabilityState", monitor type DeltaIt assumes, that no monitor is active on these variables prior to the test.Note: these are required variables for which a monitor can be expected to exist or it can be configured.Note 2: Any other component/variable combination that supports monitoring could also be used for this testcase.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:SetVariableMonitoringResponse</td><td>Install monitors1. OCTT sends SetVariableMonitoringRequest with:- setMonitoringData[0].value = 1-setMonitoringData[0].type = Delta-setMonitoringData[0].severity = <Configured severity>setMonitoringData[0].component.name = "EVSE"- setMonitoringData[0].component.evse.id =<Configured evseld>- setMonitoringData[0].variable.name = "AvailabilityState"- setMonitoringData[1].value = 1-setMonitoringData[1].type = Delta-setMonitoringData[1].severity = <Configured severity>- setMonitoringData[1].component.name = "ChargingStation"- setMonitoringData[1].variable.name ="AvailabilityState"</td></tr><tr><td rowspan="3"></td><td>4. Charging Station responds with:GetMonitoringReportResponse</td><td>Verify monitors are installed3. OCTT sends GetMonitoringReportRequest with:- requestId = <Generated requestId> - monitoringCriteria is absent- componentVariable[0].component.name = "EVSE"- componentVariable[0].component.evse.id = 1 - componentVariable[0].variable.name = "AvailabilityState" - componentVariable[1].component.name = "ChargingStation"- componentVariable[1].variable.name = "AvailabilityState"</td></tr><tr><td>5. Charging Station responds with:NotifyMonitoringReportRequest</td><td>6. OCTT sends NotifyMonitoringReportResponse</td></tr><tr><td colspan="2">Step 5 and 6 may be repeated if the result is not sent in one report message.</td></tr><tr><td rowspan="3">Tool validations</td><td colspan="2">* Step 2:Message: SetVariableMonitoringResponse with:setMonitoringResult[1]- id = <id of new monitor>- status = Accepted-type = Delta-severity = 8-component.name = "EVSE"- component.evse.id = <Configured evseld>- variable.name = "AvailabilityState"- statusInfo is absent or statusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">setMonitoringResult[2]- id = <id of new monitor>- status = Accepted-type = Delta-severity = 8-component.name = "ChargingStation"- variable.name = "AvailabilityState"- statusInfo is absent or statusInforeasonCode = "NoError"* Step 4:Message: GetMonitoringReportResponse-status = Accepted-statusInfo is absent or statusInfo_reasonCode = "NoError"* Step 5:Message: NotifyMonitoringReportRequest-requestId = <Generated requestId>- generatedAt = <timestamp at charging station>- seqNo = 0</td></tr><tr><td>while tbc is true</td><td>Expect NotifyMonitoringReportRequest- seqNo is incremented by 1</td></tr></table>
+
+Table 344. Test Case Id: TC_N_10_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Multiple monitors on the same component and variable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_10_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.01, N04.FR.02, N04.FR.08, N04.FR.11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS sets multiple monitors on the same component/variable combination.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station supports multiple monitors on the same component/variable combination.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:This test case activates two monitors on the following variable:- Component "EVSE", evse "1", variable "AvailabilityState", monitor type DeltaNote: it does not make any practical sense to install two_Delta monitors on the same variable with different severity, because a Delta monitor on a non-numeric variable is triggered by any change. However, the specification allows for it, therefore we use this variable, because it must exist.If the variable "Power" can be monitored on an EVSE, then it is much more realistic to use that with a combination of two different UpperThresholds and severities...</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:SetVariableMonitoringResponse</td><td>Install monitors1. OCTT sends SetVariableMonitoringRequest with:- setMonitoringData[0].value = 1-setMonitoringData[0].type = Delta-setMonitoringData[0].severity = 8-setMonitoringData[0].component.name = "EVSE"- setMonitoringData[0].component.evse.id =<Configured evseld>- setMonitoringData[0].variable.name = "AvailabilityState"- setMonitoringData[1].value = 1-setMonitoringData[1].type = Delta-setMonitoringData[1].severity = 7-setMonitoringData[1].component.name = "EVSE"- setMonitoringData[1].component.evse.id =<Configured evseld>- setMonitoringData[1].variable.name = "AvailabilityState"</td></tr><tr><td>Test case name</td><td>Set Variable Monitoring - Multiple monitors on the same component and variable</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message: SetVariableMonitoringResponse with (in arbitrary order):
+setMonitoringResult[1] = {
+- id = <id of new monitor>
+- status = Accepted
+- type = Delta
+- severity = 8
+- component.name = "EVSE"
+- component.evse.id = <Configured evseld>
+- variable.name = "AvailabilityState"
+- statusInfo is absent or statusInforeasonCode = "NoError"
+}
+setMonitoringResult[2] = {
+- id = <id of new monitor>
+- status = Accepted
+- type = Delta
+- severity = 7
+- component.name = "EVSE"
+- component.evse.id = <Configured evseld>
+- variable.name = "AvailabilityState"
+- statusInfo is absent or statusInfo_reasonCode = "NoError"
+}</td></tr><tr><td>Post scenario validations:
+N/A</td></tr></table>
+
+Table 345. Test Case Id: TC_N_11_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Unknown component</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_11_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS tries to set a monitor on an unknown component.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station checks whether a component exists.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:This test case activates a monitor on an existing component on non-existing evse and then on a non-existing component "NonExistent":- Component "EVSE", evse "99", variable "AvailabilityState", monitor type Delta- Component "NonExistent", variable "Power", monitor type UpperThresholdNote: this assumes, that EVSE #99 does not exist.The response to the "NonExistent" component can be either UnknownComponent or UnknownVariable, because both will not exist.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:SetVariableMonitoringResponse</td><td>Install monitors1. OCTT sends SetVariableMonitoringRequest with:setMonitoringData[1] = { - setMonitoringData[0].value = 1 - setMonitoringData[0].type = Delta - setMonitoringData[0].severity = <Configured severity> - setMonitoringData[0].component.name = "EVSE" - setMonitoringData[0].component.evse.id = 99 - setMonitoringData[0].variable.name = "AvailabilityState" }setMonitoringData[2] = { - setMonitoringData[1].value = 1234.0 - setMonitoringData[1].type = UpperThreshold - setMonitoringData[1].severity = <Configured severity> - setMonitoringData[1].component.name = "NonExistent" - setMonitoringData[1].variable.name = "Power" }</td></tr><tr><td>Test case name</td><td>Set Variable Monitoring - Unknown component</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message: SetVariableMonitoringResponse with (in arbitrary order):
+- id is absent
+- status = UnknownComponent or Rejected
+- type = Delta
+- severity = <Configured severity>
+- component.name = "EVSE"
+- component.evse.id = 99
+- variable.name = "AvailabilityState"
+- statusInfo is absent or statusInforeasonCode = "UnknownEVSE" or statusInfo = "NotFound"
+- id is absent
+- status = UnknownComponent (UnknownVariable will also be allowed, but is less accurate)
+- type = UpperThreshold
+- severity = <Configured severity>
+- component.name = "NonExistent"
+- variable.name = "AvailabilityState"
+- statusInfo is absent or statusInfo_reasonCode = "NotFound"</td></tr><tr><td>Post scenario validations:
+N/A</td></tr></table>
+
+Table 346. Test Case Id: TC_N_12_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Value out of range - Delta monitor</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_12_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS tries to set a delta monitor with a value that is out of range.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station checks that value is within range of variable.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.
+This test case assumes the following component exists and can be monitored:
+- Component "EVSE", evse "1", variable "AvailabilityState", monitor type Delta
+Note: Variable_AvailabilityState is mandatory for an EVSE and it is likely (but not guaranteed), that it can be monitored._</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:
+SetVariableMonitoringResponse</td><td>Install monitors
+1. OCTT sends SetVariableMonitoringRequest with:
+- setMonitoringData[0].value = -1
+- setMonitoringData[0].type = Delta
+- setMonitoringData[0].severity = <Configured severity>
+- setMonitoringData[0].component.name = "EVSE"
+- setMonitoringData[0].component.evse.id = <Configured evseld>
+- setMonitoringData[0].variable.name = "AvailabilityState"</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: SetVariableMonitoringResponse with (in arbitrary order):
+setMonitoringResult = {
+- id is absent
+- status = Rejected
+- type = Delta
+-severity = <Configured severity>
+-component.name = "EVSE"
+-component.evse.id = <Configured evseld>
+-variable.name = "AvailabilityState"
+-statusInfo is absent or statusInforeasonCode = "ValueOutOfRange" or statusInforeasonCode = "ValuePositiveOnly"</td></tr><tr><td colspan="2">Post scenario validations:
+N/A</td></tr></table>
+
+Table 347. Test Case Id: TC_N_13_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Value out of range - Threshold monitor</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_13_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS tries to set a threshold monitor with a value that is out of range.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station checks that value is within range of variable.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.This test case assumes the<Configured threshold monitor component variable>component.value existsand can be monitored and has variableCharacteristics.maxLimit < <Configured threshold monitor value>+ Note:Variable_Power(maxLimit) is mandatory for an EVSE, but the actual value not, but it is likely (but notguaranteed), that it can be monitored._</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:SetVariableMonitoringResponse</td><td>Install monitors1. OCTT sends SetVariableMonitoringRequest with:- setMonitoringData[0].value = <Configured thresholdmonitor value>- setMonitoringData[0].type = UpperThreshold- setMonitoringData[0].severity = <Configuredseverity>- setMonitoringData[0].component.name =<Configured threshold monitor component variable>- setMonitoringData[0].component.evse.id =<Configured evseId>- setMonitoringData[0].variable.name = <Configuredthreshold monitor component variable></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: SetVariableMonitoringResponse with (in arbitrary order):setMonitoringResult = {id is absentstatus = Rejected-type = UpperThresholdseverity = <Configured severity>- component.name = <Configured threshold monitor component variable>- component.evse.id = <Configured evseId>- variable.name = <Configured threshold monitor component variable>- statusInfo is absent or statusInfoReasonCode = "ValueOfRange"}</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 348. Test Case Id: TC_N_15_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Duplicate Variable type/severity combination</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_15_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS sets multiple monitors on the same component/variable combination with same severity and type.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station rejects multiple monitors on the same component/variable combination when having the same severity and type.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:This test case activates two monitors on the following variable:- Component "EVSE", evse "1", variable "AvailabilityState", monitor type Delta+ Note: it does not make any practical sense to install two_Delta monitors on the same variable with different severity, because a Delta monitor on a non-numeric variable is triggered by any change. However, the specification allows for it, therefore we use this variable, because it must exist.If the variable "Power" can be monitored on an EVSE, then it is much more realistic to use that with a combination of two different UpperThresholds and severities._</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. Charging Station responds with:SetVariableMonitoringResponse</td><td>Install monitors with same severity and of type_Delta1. OCTT sends SetVariableMonitoringRequest with:- setMonitoringData[0].value = 1- setMonitoringData[0].type = Delta- setMonitoringData[0].severity = <Configured severity> - setMonitoringData[0].component.name = "EVSE"- setMonitoringData[0].component.evse.id = <Configured evseId> - setMonitoringData[0].variable.name = "AvailabilityState"- setMonitoringData[1].value = 1- setMonitoringData[1].type = Delta- setMonitoringData[1].severity = <Configured severity> - setMonitoringData[1].component.name = "EVSE"- setMonitoringData[1].component.evse.id = <Configured evseId> - setMonitoringData[1].variable.name = "AvailabilityState"</td></tr><tr><td>Test case name</td><td>Set Variable Monitoring - Duplicate Variable type/severity combination</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message: SetVariableMonitoringResponse with (in arbitrary order):
+setMonitoringResult[1] = {
+- id = <id of new monitor>
+- status = Accepted
+- type = Delta
+- severity = <Configured severity>
+- component.name = "EVSE"
+- component.evse.id = <Configured evseld>
+- variable.name = "AvailabilityState"
+- statusInfo is absent or statusInforeasonCode = "NoError"
+}
+setMonitoringResult[2] = {
+- status = Duplicate
+- type = Delta
+- severity = <Configured severity>
+- component.name = "EVSE"
+- component.evse.id = <Configured evseld>
+- variable.name = "AvailabilityState"
+- statusInfo is absent or statusInforeasonCode = "InvalidValue"
+}</td></tr><tr><td>Post scenario validations:
+N/A</td></tr></table>
+
+Table 349. Test Case Id: TC_N_16_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Monitoring Level - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_16_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N05</td></tr><tr><td>Requirement(s)</td><td colspan="2">N05.FR.01, N05.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS sets a monitoring level after which only monitors with lower or equal level are reported.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station accepts monitoring message and correctly filters events.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:This test case activates a monitor on the following variable:- Component "EVSE", variable "AvailabilityState", monitor type Delta, severity 8It assumes that no monitor is active on this variable at start of the test.</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Set a monitoring level that suppresses the notification</td></tr><tr><td>2. Charging Station responds with:SetMonitoringLevelResponse</td><td>1. OCTT sends:SetMonitoringLevelRequest with:severity = 7</td></tr><tr><td>4 Charging Station does NOT sendNotifyEventRequest for configured EVSE</td><td>3. Plugin cable to configured EVSE to make it_Occupied and test that notification is suppressed._</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: SetMonitoringLevelResponse with:status = AcceptedstatusInfo is absent or statusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">Post scenario validations:Verify that no event notification is sent for the configured EVSE.</td></tr></table>
+
+Table 350. Test Case Id: TC_N_17_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Monitoring Level - Out of range</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_17_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N05</td></tr><tr><td>Requirement(s)</td><td colspan="2">N05.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS sets a monitoring level with an out of range value.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station rejects monitoring message with out of range severity.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>2. Charging Station responds with:SetMonitoringLevelResponse</td><td>1. OCTT sends:SetMonitoringLevelRequest with:severity = 10</td></tr><tr><td>4. Charging Station responds with:SetMonitoringLevelResponse</td><td>3. OCTT sends:SetMonitoringLevelRequest with:severity = -1</td></tr><tr><td rowspan="3">Tool validations</td><td colspan="2">* Step 2:Message: SetMonitoringLevelResponse with:- status = Rejected- statusInfo is absent or statusInforeasonCode = "ValueOutOfRange" or statusInforeasonCode = "ValueTooHigh"</td></tr><tr><td colspan="2">* Step 4:Message: SetMonitoringLevelResponse with:- status = Rejected- statusInfo is absent or statusInforeasonCode = "ValueOutOfRange" or statusInforeasonCode = "ValueTooLow"</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 351. Test Case Id: TC_N_18_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Monitoring - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_18_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N06</td></tr><tr><td>Requirement(s)</td><td colspan="2">N06.FR.01, N06.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS clears a monitor that is identified by its id.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station clears the monitor.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:- Component "ChargingStation", variable "AvailabilityState"- Component "EVSE", variable "AvailabilityState"</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>2. Charging Station responds with:ClearVariableMonitoringResponse</td><td>1. OCTT sends:ClearVariableMonitoringRequest with:- id = {ID1, ID2}</td></tr><tr><td>4. Charging Station responds with:GetMonitoringReportResponse</td><td>Verify monitors are cleared3. OCTT sends GetMonitoringReportRequest with:- requestId = <Generated requestId>- monitoringCriteria is absent- componentVariable[0].component.name = "ChargingStation"- componentVariable[0].variable.name = "AvailabilityState"- componentVariable[1].component.name = "EVSE"- componentVariable[1].component.evse.id = 1- componentVariable[1].variable.name = "AvailabilityState"</td></tr><tr><td rowspan="3">Tool validations</td><td colspan="2">* Step 2:Message: ClearVariableMonitoringResponse with (in arbitrary order):clearMonitoringResult[1]:- status = Accepted-id = <ID1>- statusInfo is absent or statusInforeasonCode = "NoError"clearMonitoringResult[2]:- status = Accepted-id = <ID2>- statusInfo is absent or statusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">* Step 4:Message: GetMonitoringReportResponse with:- status = EmptyResultSetstatusInfo is absent or statusInforeasonCode = "NotFound"</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 352. Test Case Id: TC_N_19_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Monitoring - Not found</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_19_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N06</td></tr><tr><td>Requirement(s)</td><td colspan="2">N06.FR.02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">CSMS clears a monitor that does not exist.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station responds with NotFound result.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:OCTT Sends a GetMonitoringReportRequest, the CS then reports all existing monitors if it has any. If any monitors exist the tool will take the highest id number and add 1, if no monitors are reported a preconfigured number is used.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td colspan="2">This test uses a monitor id, that is expected not to exist.</td></tr><tr><td>2. Charging Station responds with:ClearVariableMonitoringResponse</td><td>1. OCTT sends:ClearVariableMonitoringRequest with:- id monitor id from the Preparations</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: ClearVariableMonitoringResponse with:clearMonitoringResult:- status = NotFound-id = 123456-statusInfo is absent or statusInforeasonCode = "NotFound"</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 353. Test Case Id: TC_N_20_CS
+
+<table><tr><td>Test case name</td><td>Alert Event - Threshold value exceeded</td></tr><tr><td>Test case Id</td><td>TC_N_20_CS</td></tr><tr><td>Use case Id(s)</td><td>N07</td></tr><tr><td>Requirement(s)</td><td>N07.FR.06, N07.FR.07, N07.FR.16, N07.FR.17</td></tr><tr><td>System under test</td><td>Charging Station</td></tr><tr><td>Description</td><td>A monitored variable exceeds a threshold monitor and causes a NotifyEventRequest message to be sent.</td></tr><tr><td>Purpose</td><td>To test that Charging Station supports threshold monitors</td></tr><tr><td>Prerequisite(s)</td><td>Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="2"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td>Configuration State:N/a</td></tr><tr><td>Memory State:This test requires the Monitoring Base to be set to All.- SetMonitoringBaseRequest with monitoringBase = All.Furthermore this test requires the existence of a LowerThreshold and UpperThreshold monitor on a(numerical) variable. Since it is not mandated which variables are required to be monitored, this test usedthe variable "Power" of component "EVSE".- setMonitoringData[0].value = <Configured threshold monitor value>- setMonitoringData[0].type = UpperThreshold- setMonitoringData[0].severity = <Configured severity>- setMonitoringData[0].component.name = <Configured threshold monitor component variable>- setMonitoringData[0].component.evse.id = <Configured evseld>- setMonitoringData[0].variable.name = <Configured threshold monitor component variable>Notes:- If componentVariable is set to "Power" or "Current", the value is set to the configured maxLimit 100.0- Take a threshold that can easily be exceeded.</td></tr><tr><td>Reusable State(s): N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Alert Event - Threshold value exceeded</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EnergyTransferStarted or manually trigger the monitor.Notes: If componentVariable is set to "Power" or "Current" EnergyTransferStarted will trigger the monitor. If another componentvariable is chosen a manual action is needed to trigger the monitor.</td></tr><tr><td>2. Charging Station sends a NotifyEventRequest with:- Power exceeding upper threshold</td><td>3. OCTT responds with a NotifyEventResponse</td></tr><tr><td>5. Charging Station responds with a SetVariableMonitoringResponse with:- status Accepted</td><td>4. OCTT sends a SetVariableMonitoringRequest with:- type LowerThreshold- component.name <Configured threshold monitor component variable> - component.evse.id <configured evseld> - variable.name <Configured threshold monitor component variable> - value <Configured threshold monitor2 value> Notes:- If componentVariable is set to "Power" or "Current", the value is set to the configured maxLimit 10.0 - Take a threshold that won't be exceeded.</td></tr><tr><td colspan="2">6. Execute Reusable State StopAuthorized or manually trigger the second monitor.Notes: If componentVariable is set to "Power" or "Current" EnergyTransferStarted will trigger the monitor. If another componentvariable is chosen a manual action is needed to trigger the monitor.</td></tr><tr><td>7. Charging Station sends:NotifyEventRequest for 2 events:- Returning below upper threshold (cleared)- Dropping below lower threshold</td><td>8. OCTT responds:NotifyEventResponse</td></tr><tr><td colspan="2">Notes: Steps 2, 3, 7, and 8 may be repeated if the data is sent using two requests instead of one.Depending on the configuration the Charging Station may also send other notifications during step 4 and 9.</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2: Message: NotifyEventRequest with:- generatedAt = <time of generation at Charging Station>- seqNo = 0and an eventData element with:- eventId = <id1>- timestamp = <time of event at Charging Station>- trigger = Alerting- actualValue = <current power> (must be > <Configured threshold monitor value>)- cleared is absent or cleared = false- transactionld = <transaction id> (delivery of power is always in transaction)- variableMonitoringld = <monitor id1>- component.name = <Configured threshold monitor component variable>- component.evse.id = <Configured evseld>- variable.name = <Configured threshold monitor component variable>Other eventData elements can be ignored.</td></tr><tr><td>Test case name</td><td>Alert Event - Threshold value exceeded</td></tr><tr><td></td><td>* Step 7: Message: NotifyEventRequest with:
+-generatedAt = <time of generation at Charging Station>
+-seqNo = 0
+and an eventData element with:
+- eventId = <id2>
+-timestamp = <time of event at Charging Station>
+-trigger = Alerting
+-actualValue = <current power> (must be <=<Configured threshold monitor value>)
+-cleared is true
+-transactionId = <transaction id> (delivery of power is always in transaction)
+-variableMonitoringId = <monitor id1>
+-eventNotificationType = CustomMonitor
+-component.name = <Configured threshold monitor component variable>
+-component.evse.id = <Configured evseId>
+-variable.name = <Configured threshold monitor component variable>
+and an eventData element with:
+- eventId = <id3>
+-timestamp = <time of event at Charging Station>
+-trigger = Alerting
+-actualValue = <current power> (must be <=<Configured threshold monitor2 value>)
+-cleared is absent or cleared is false
+-transactionId = <transaction id> (delivery of power is always in transaction)
+-variableMonitoringId = <monitor id2>
+-eventNotificationType = CustomMonitor
+-component.name = <Configured threshold monitor component variable>
+-component.evse.id = <Configured evseId>
+-variable.name = <Configured threshold monitor component variable>
+Other eventData elements can be ignored. This can also be sent in two NotifyEventRequests, instead of one.</td></tr><tr><td></td><td>Post scenario validations:
+N/A</td></tr></table>
+
+Table 354. Test Case Id: TC_N_21_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Alert Event - Caused by hardwired trigger</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_21_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2"></td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">An event that is hardwired in the firmware is reported.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station reports this as a HardWiredNotification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.
+This test assumes the existence of a hardwired notification in the Charging Station. The OCPP specification does not mandate any hardwired notifications, so it is up to the tester to select a certain notification and cause it to trigger the sending of an NotifyEventRequest.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Tester triggers Charging Station to send a hardwired notification for component_X and variable Y._</td></tr><tr><td>1. Charging Station sends:
+NotifyEventRequest</td><td>2. OCTT responds:
+NotifyEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: NotifyEventRequest with:
+- generatedAt = <time of generation at Charging Station>
+- seqNo = 0
+and an eventData element with:
+- eventNotificationType = HardWiredNotification
+Other eventData elements are not relevant for this test.</td></tr><tr><td colspan="2">Post scenario validations:
+N/A</td></tr></table>
+
+Table 355. Test Case Id: TC_N_22_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Offline Notification - OfflineMonitoringEventQueuingSeverity set equal or lower than severityLevel of the monitor</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_22_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N07.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">Charging Station queues event notifications when offline.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station will queue event notifications with a severity equal or lower than OfflineMonitoringEventQueuingSeverity.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station is online at start of test for configuration. CS has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: SetConfiguration with: - component.name = "MonitoringCtrl" - variable.name = "OfflineQueuingSeverity" - attributeValue = <Configured Severity></td></tr><tr><td colspan="2">Memory State: Charging Station has a custom or predefined monitor on AvailabilityState for Configured EVSE with severity = <Configured severity></td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="7">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Take Charging Station offline.</td></tr><tr><td>2. Charging Station queues event notification for EVSE #1::AvailabilityState._</td><td>1. Plug a cable into EVSE #1 to generate an event notification for _AvailabilityState._</td></tr><tr><td colspan="2">Note(s): The tool will now wait for <Configured Transaction Duration> seconds</td></tr><tr><td colspan="2">Manual Action: Bring Charging Station back online.</td></tr><tr><td>3. Charging Station sends NotifyEventRequest</td><td>4. OCTT responds with NotifyEventResponse</td></tr><tr><td colspan="2">Steps 3 and 4 repeat for all queued events during the offline period</td></tr><tr><td rowspan="3">Tool validations</td><td colspan="2">* Step 1: no communication</td></tr><tr><td colspan="2">* Step 3: Validate that the following NotifyEventRequest message was received: with an eventData element with: - eventData[0].trigger = Delta - eventData[0].actualValue = "Occupied" - eventData[0].component.name = "EVSE" - eventData[0].component.evse.id = <Configured evseld> - eventData[0].variable.name = "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 356. Test Case Id: TC_N_23_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Offline Notification - OfflineMonitoringEventQueuingSeverity set higher than severityLevel of the monitor</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_23_CS</td></tr><tr><td>Use case ld(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N07.FR.04s</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">Charging Station does not queue event notifications when offline.</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station does not queue event notifications with a severity higher than OfflineMonitoringEventQueuingSeverity.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station is online at start of test for configuration.
+CS has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+SetConfiguration with:
+ - component.name = "MonitoringCtrl"
+ - variable.name = "OfflineQueuingSeverity"
+ - attributeValue = <Configured Severity></td></tr><tr><td colspan="2">Memory State:
+Charging Station has a custom or predefined monitor on AvailabilityState for Configured EVSE with severity = <Configured severity> + 1</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="13">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td>1. The Charging Station notifies the CSMS about the status change of the connector.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td colspan="2">Note(s): Step 3, 4, 5, 6, 7, and 8 need to be executed when TxStartPoint contains EVConnected OR ParkingBayOccupancy</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td colspan="2">Manual Action: Take Charging Station offline.</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE.</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td colspan="2">Note(s): The tool will now wait for <Configured Transaction Duration> seconds</td></tr><tr><td colspan="2">Manual Action: Bring Charging Station back online.</td></tr><tr><td>5. The Charging Station sends a TransactionEventRequest</td><td>6. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>7. The Charging Station sends a TransactionEventRequest</td><td>8. The OCTT responds with a TransactionEventResponse</td></tr><tr><td colspan="2">Note(s): The CS should not send a StatusNotificationRequest or NotifyEventRequest</td></tr><tr><td>Test case name</td><td>Offline Notification - OfflineMonitoringEventQueuingSeverity set higher than severityLevel of the monitor</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: StatusNotificationRequest
+- evseld <configured evseld>
+- connectorld <configured connectorld>
+- connectorStatus must be Occupied
+Message: NotifyEventRequest
+- eventData[0].trigger must be Delta
+- eventData[0].actualValue must be Occupied
+- eventData[0].component.name must be Connector
+- eventData[0].variable.name must be AvailabilityState
+- evse.id <configured evseld>
+- connector.id <configured connectorld></td></tr><tr><td>* Step 3:
+Message: TransactionEventRequest
+- triggerReason must be CablePluggedIn
+- transactionInfo.chargingState must be EVConnected</td></tr></table>
+
+Table 357. Test Case Id: TC_N_24_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Periodic event</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_24_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07, N08</td></tr><tr><td>Requirement(s)</td><td colspan="2">N07.FR.20, N08.FR.01, N08.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">Charging Station sends a periodic event .</td></tr><tr><td>Purpose</td><td colspan="2">To test that Charging Station sends periodic events</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has implemented device model monitoring and MonitoringCtrl::Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Set the monitor to generate a periodic event notification</td></tr><tr><td>2. Charging Station responds with SetVariableMonitoringResponse</td><td>1. OCTT sends SetVariableMonitoringRequest with:- setMonitoringData[0].value = <Configured ClockAligned MeterValues Interval> - setMonitoringData[0].type = Periodic - setMonitoringData[0].component.name = "EVSE" - setMonitoringData[0].component.evse.id = <Configured evseId> - setMonitoringData[0].variable.name = "AvailabilityState"</td></tr><tr><td>3. Charging Station generates NotifyEventRequest for EVSE #1::AvailabilityState_ every seconds.</td><td></td></tr><tr><td rowspan="3">Tool validations</td><td colspan="2">* Step 2:Message: SetVariableMonitoringResponse with:setMonitoringResult[0].status = AcceptedsetMonitoringResult[0].component.name = "EVSE"setMonitoringResult[0].component.evse.id = <Configured evseId>setMonitoringResult[0].variable.name = "AvailabilityState"setMonitoringResult[0].attributeStatusInfo is absent or attributeStatusInforeasonCode = "NoError"</td></tr><tr><td colspan="2">* Step 3:Message: a NotifyEventRequest message every <Configured Clock Aligned MeterValues Interval> seconds with:with an eventData element with:- trigger = Periodic- component.name = "EVSE"- component.evse.id = 1- variable.name = "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 358. Test Case Id: TC_N_25_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve Log Information - Diagnostics Log - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_25_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N01.FR.01, N01.FR.02, N01.FR.04, N01.FR.07, N01.FR.08, N01.FR.09, N01.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers the functionality of getting log information from a Charging Station. The CSMS can request a Charging Station to upload a file with log information to a given location (URL). The format of this log file is not prescribed. The Charging Station successfully uploads a log file and gives information about the status of the upload by sending status notifications to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to successfully upload a log as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- Charging Station has log information available.
+- A diagnostics logging server has been setup supporting one of the file transfer protocols supported by the Charging Station (This is configured at the configuration variable FileTransferProtocols).</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetLogResponse</td><td>1. The OCTT sends a GetLogRequest with logType DiagnosticsLog</td></tr><tr><td>Note(s):
+- Charging Station is uploading log file</td><td></td></tr><tr><td>3. The Charging Station sends a LogStatusNotificationRequest</td><td>4. The OCTT responds with a LogStatusNotificationResponse</td></tr><tr><td>Note(s):
+- Log file is uploaded</td><td></td></tr><tr><td>5. The Charging Station sends a LogStatusNotificationRequest</td><td>6. The OCTT responds with a LogStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message GetLogResponse
+-status Accepted
+-filename not omitted AND not empty
+* Step 3:
+Message LogStatusNotificationRequest
+-status Uploading
+-requestId Same Id as the GetLogRequest
+* Step 5:
+Message LogStatusNotificationRequest
+-status Updated
+-requestId Same Id as the GetLogRequest</td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+Table 359. Test Case Id: TC_N_26_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve Log Information - Diagnostics Log - Upload failed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_26_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N01.FR.01, N01.FR.02, N01.FR.04, N01.FR.07, N01.FR.08, N01.FR.10, N01.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers the functionality of getting log information from a Charging Station. The CSMS can request a Charging Station to upload a file with log information to a given location (URL). The format of this log file is not prescribed. The Charging Station unsuccessfully uploads a log file and gives information about the status of the upload by sending status notifications to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to correctly communicate with the CSMS after failing to upload a log as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- Charging Station has log information available.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:The retry interval should be configured longer than the time it takes to attempt an upload.</td></tr><tr><td colspan="2">Memory State:Charging Station has log information available.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aGetLogResponse</td><td>1. The OCTT sends a GetLogRequest with-logType DiagnosticsLog-retries 3-retryInterval <Configured retryInterval></td></tr><tr><td>3. The Charging Station sends aLogStatusNotificationRequest</td><td>4. The OCTT responds with aLogStatusNotificationResponse</td></tr><tr><td>5. The Charging Station sends aLogStatusNotificationRequest</td><td>6. The OCTT responds with aLogStatusNotificationResponse</td></tr><tr><td colspan="2">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.</td></tr><tr><td>Test case name</td><td>Retrieve Log Information - Diagnostics Log - Upload failed</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message GetLogResponse
+- status Accepted
+* Step 3:
+Message LogStatusNotificationRequest
+- status Uploading
+- requestId Same Id as the GetLogRequest
+* Step 5:
+Message LogStatusNotificationRequest
+- status UploadFailure
+- requestId Same Id as the GetLogRequest
+OR Message LogStatusNotificationRequest
+- status BadMessage
+- requestId Same Id as the GetLogRequest
+OR Message LogStatusNotificationRequest
+- status PermissionDenied
+- requestId Same Id as the GetLogRequest
+OR Message LogStatusNotificationRequest
+- status NotSupportedOperation
+- requestId Same Id as the GetLogRequest
+* The time between the first LogStatusNotificationRequest Uploading and the last
+LogStatusNotificationRequest UploadFailure/BadMessage/PermissionDied/NotSupportedOperation
+equals (3 *<Configured retryInterval>)</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 360. Test Case Id: TC_N_27_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Customer Information - Accepted + data</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_27_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N09</td></tr><tr><td>Requirement(s)</td><td colspan="2">N09.FR.02, N09.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to retrieve IdToken customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station accepts the request and correctly sends the information as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station needs to support Local Authorization and either the Local Authorization List or Authorization Cache.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListCtrl.Enabled is set to true
+AuthCtrl.LocalPreAuthorize is set to true
+AuthCacheCtrl.Enabled is set to true</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields> (If implemented)
+IdTokenLocalAuthList for <Configured valid IdToken fields> (If implemented)</td></tr><tr><td colspan="2">Charging State:
+State is Authorized (local)
+State is ParkingBayUnoccupied</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a CustomerInformationResponse</td><td>1. The OCTT sends a CustomerInformationRequest with
+- report true
+-idToken</td></tr><tr><td>3. The Charging Station sends a NotifyCustomerInformationRequest</td><td>4. The OCTT responds with a NotifyCustomerInformationResponse .</td></tr><tr><td>Note(s):
+- If tbc is True at Step 3 then step 3 and 4 will be repeated</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message CustomerInformationResponse
+- status Accepted
+* Step 3:
+Message NotifyCustomerInformationRequest
+-data Not empty</td></tr><tr><td colspan="2">Post scenario validations:
+- All report parts have been received</td></tr></table>
+
+Table 361. Test Case Id: TC_N_28_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Customer Information - Accepted + no data</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_28_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N09</td></tr><tr><td>Requirement(s)</td><td colspan="2">N09.FR.02, N09.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to retrieve IdToken customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station accepts the request and correctly respond when it couldn't find the right information as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has no customer information available of <Configured valid idToken fields></td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:The CSMS requests the CS to clear the customerInformation for idToken <Configured valid idToken fields></td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aCustomerInformationResponse</td><td>1. The OCTT sends a CustomerInformationRequest with- report true-idToken <Configured valid idToken fields></td></tr><tr><td>3. The Charging Station sends aNotifyCustomerInformationRequest</td><td>4. The OCTT responds with aNotifyCustomerInformationResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message CustomerInformationResponse- status Accepted* Step 3:Message NotifyCustomerInformationRequest-tbc Not true</td></tr><tr><td colspan="2">Post scenario validations:- A message is sent indicating that no data is found</td></tr></table>
+
+Table 362. Test Case Id: TC_N_29_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Customer Information - Not Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_29_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N09</td></tr><tr><td>Requirement(s)</td><td colspan="2">N09.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to retrieve IdToken customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station correctly responds when it cannot process the request as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging station is in a state where it cannot process customer information requests</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aCustomerInformationResponse</td><td>1. The OCTT sends a CustomerInformationRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message CustomerInformationResponse-status Invalid</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 363. Test Case Id: TC_N_30_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Clear and report + data</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_30_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N10.FR.01, N10.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to clear (and retrieve) IdToken customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station accepts the request and removes all customer related data (except from LocalList) and sent notifies as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The Charging Station needs to support Local Authorization and either the Local Authorization List or Authorization Cache.
+- The Charging Station supports authorization methods other than NoAuthorization</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+LocalAuthListCtrl.Enabled is set to true
+AuthCtrl.LocalPreAuthorize is set to true
+AuthCacheCtrl.Enabled is set to true</td></tr><tr><td colspan="2">Memory State:
+IdTokenCached for <Configured valid IdToken fields> (If implemented)
+IdTokenLocalAuthList for <Configured valid IdToken fields> (If implemented)</td></tr><tr><td colspan="2">Charging State:
+State is Authorized (local)
+State is ParkingBayUnoccupied</td></tr><tr><td rowspan="7">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a
+CustomerInformationResponse</td><td>1. The OCTT sends a CustomerInformationRequest with
+- report true AND
+- clear true AND
+-idToken</td></tr><tr><td>3. The Charging Station sends a
+NotifyCustomerInformationRequest</td><td>4. The OCTT responds with a
+NotifyCustomerInformationResponse .</td></tr><tr><td>Note(s):
+- If tbc is True at Step 3 then step 3 and 4 will be repeated</td><td></td></tr><tr><td>6. The Charging Station responds with a
+CustomerInformationResponse</td><td>5. The OCTT sends a CustomerInformationRequest with
+- report true AND
+-idToken</td></tr><tr><td>7. The Charging Station sends a
+NotifyCustomerInformationRequest</td><td>8. The OCTT responds with a
+NotifyCustomerInformationResponse .</td></tr><tr><td>Note(s):
+- Step is optional and only expected when status is
+Accepted at Step 6</td><td></td></tr><tr><td>Test case name</td><td>Clear Customer Information - Clear and report + data</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message CustomerInformationResponse
+- status Accepted
+* Step 3:
+Message NotifyCustomerInformationRequest
+- data Not empty
+* Step 8:*
+Message NotifyCustomerInformationRequest
+- tbc Not true</td></tr><tr><td>Post scenario validations:
+- All report parts have been received</td></tr></table>
+
+Table 364. Test Case Id: TC_N_31_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Clear and report + no data</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_31_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N10.FR.01, N10.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to clear (and retrieve) IdToken customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station accepts the request and correctly respond when it couldn't find the right information as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has no customer information available of <Configured valid idToken fields></td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aCustomerInformationResponse</td><td>1. The OCTT sends a CustomerInformationRequest with - report true AND - clear true AND - idToken <Configured valid idToken fields></td></tr><tr><td>3. The Charging Station sends aNotifyCustomerInformationRequest</td><td>4. The OCTT responds with a NotifyCustomerInformationResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message CustomerInformationResponse- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:- A message is send indicating that no data is found</td></tr></table>
+
+Table 365. Test Case Id: TC_N_32_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Clear and no report</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_32_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N10.FR.01, N10.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to clear (and retrieve) IdToken customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station accepts the request and removes all customer related data (except from LocalList) and sent one notify as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has no customer information available of <Configured valid idToken fields></td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a CustomerInformationResponse</td><td>1. The OCTT sends a CustomerInformationRequest with
+- report false AND
+- clear true AND
+-idToken <Configured valid idToken fields></td></tr><tr><td>3. The Charging Station sends a NotifyCustomerInformationRequest</td><td>4. The OCTT responds with a NotifyCustomerInformationResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message CustomerInformationResponse
+- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+-A message is send indicating that the data is cleared</td></tr></table>
+
+Table 366. Test Case Id: TC_N_62_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Clear and report - customerIdentifier</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_62_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N10.FR.01, N10.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to clear (and retrieve) raw customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station accepts the request and removes all customer related data (except from LocalList) and sent notifies as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station needs to support retrieving / deleting CustomerInformation - CustomerIdentifier.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:The tester needs manually store the<Configured CustomerIdentifiers>at the Charging Station.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aCustomerInformationResponse</td><td>1. The OCTT sends a CustomerInformationRequest with- report true AND- clear true AND-customerIdentifier <Configured customerIdentifiers></td></tr><tr><td>3. The Charging Station sends aNotifyCustomerInformationRequest</td><td>4. The OCTT responds with aNotifyCustomerInformationResponse</td></tr><tr><td>Note(s):- If tbc is True at Step 3 then step 3 and 4 will be repeated</td><td></td></tr><tr><td>6. The Charging Station responds with aCustomerInformationResponse</td><td>5. The OCTT sends a CustomerInformationRequest with- report true AND- clear false AND-customerIdentifier <Configured customerIdentifiers></td></tr><tr><td>7. The Charging Station sends aNotifyCustomerInformationRequest</td><td>8. The OCTT responds with aNotifyCustomerInformationResponse</td></tr><tr><td>Note(s):- If tbc is True at Step 7 then step 7 and 8 will be repeated</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message CustomerInformationResponse-status Accepted* Step 3:Message NotifyCustomerInformationRequest-data Not empty* Step 6:Message CustomerInformationResponse-status Accepted* Step 7:Message NotifyCustomerInformationRequest-data empty</td></tr><tr><td colspan="2">Post scenario validations:- All report parts have been received</td></tr></table>
+
+Table 367. Test Case Id: TC_N_63_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Clear and report - customerCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_63_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N10.FR.09</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to clear (and retrieve) customer certificate information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.
+Note: The only customer certificate that could exist in a charging station is a PnC contract certificate, which should not remain in the charging station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station accepts the request and removes all customer related data and sent notifies as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station needs to support retrieving / deleting CustomerInformation - CustomerCertificate.</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+Execute Reusable State EVConnectedPreSession Execute Reusable State Authorized15118 Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td rowspan="7">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a CustomerInformationResponse</td><td>1. The OCTT sends a CustomerInformationRequest with
+- report true AND
+- clear true AND
+- customerCertificate customer information used in the transaction</td></tr><tr><td>3. The Charging Station sends a NotifyCustomerInformationRequest</td><td>4. The OCTT responds with a NotifyCustomerInformationResponse</td></tr><tr><td>Note(s):
+- If tbc is True at Step 3 then step 3 and 4 will be repeated</td><td></td></tr><tr><td>6. The Charging Station responds with a CustomerInformationResponse</td><td>5. The OCTT sends a CustomerInformationRequest with
+- report true AND
+- clear false AND
+- customerCertificate customer information used in the transaction</td></tr><tr><td>7. The Charging Station sends a NotifyCustomerInformationRequest</td><td>8. The OCTT responds with a NotifyCustomerInformationResponse</td></tr><tr><td>Note(s):
+- If tbc is True at Step 7 then step 7 and 8 will be repeated</td><td></td></tr><tr><td>Test case name</td><td>Clear Customer Information - Clear and report - customerCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:Message CustomerInformationResponse- status Accepted* Step 3:Message NotifyCustomerInformationRequest-data empty or Not empty if a customer certificate exists* Step 6:Message CustomerInformationResponse-status Accepted* Step 7:Message NotifyCustomerInformationRequest-data empty</td></tr><tr><td>Post scenario validations:- All report parts have been received</td></tr></table>
+
+Table 368. Test Case Id: TC_N_33_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Invalid</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_33_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N10.FR.01, N10.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to clear (and retrieve) IdToken customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station rejects the request when it cannot process as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging station is in a state where it cannot process customer information requests</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aCustomerInformationResponse</td><td>1. The OCTT sends a CustomerInformationRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message CustomerInformationResponse-status Invalid</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 369. Test Case Id: TC_N_34_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve Log Information - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_34_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N01.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers the functionality of getting log information from a Charging Station. The CSMS can request a Charging Station to upload a file with log information to a given location (URL). The format of this log file is not prescribed. The Charging Station successfully uploads a log file and gives information about the status of the upload by sending status notifications to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to reject the request when no information is available as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">This testcase can only be executed if it is possible to have no log information available at the Charging Station.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aGetLogResponse</td><td>1. The OCTT sends a GetLogRequestwith logType<Configured logType></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetLogResponse-status Rejected</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 370. Test Case Id: TC_N_35_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve Log Information - Security Log - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_35_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N01.FR.01, N01.FR.02, N01.FR.03, N01.FR.07, N01.FR.08, N01.FR.09, N01.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers the functionality of getting log information from a Charging Station. The CSMS can request a Charging Station to upload a file with log information to a given location (URL). The format of this log file is not prescribed. The Charging Station successfully uploads a log file and gives information about the status of the upload by sending status notifications to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to successfully upload a log as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Charging Station has log information available.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aGetLogResponse</td><td>1. The OCTT sends a GetLogRequestwith logType SecurityLog</td></tr><tr><td>Note(s):- Charging Station is uploading log file</td><td></td></tr><tr><td>3. The Charging Station sends aLogStatusNotificationRequest</td><td>4. The OCTT responds with aLogStatusNotificationResponse.</td></tr><tr><td>Note(s):- Log file is uploaded</td><td></td></tr><tr><td>5. The Charging Station sends aLogStatusNotificationRequest</td><td>6. The OCTT responds with aLogStatusNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetLogResponse*- status Accepted*- Step 3:Message LogStatusNotificationRequest*- status Uploading*- requestId Same Id as the GetLogRequest*- Step 5:Message LogStatusNotificationRequest*- status Uploaded*- requestId Same Id as the GetLogRequest</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 371. Test Case Id: TC_N_36_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve Log Information - Second Request</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_36_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N01.FR.01, N01.FR.02, N01.FR.03, N01.FR.07, N01.FR.08, N01.FR.09, N01.FR.12, N01.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case covers the functionality of getting log information from a Charging Station. The CSMS can request a Charging Station to upload a file with log information to a given location (URL). The format of this log file is not prescribed. The Charging Station successfully uploads a log file and gives information about the status of the upload by sending status notifications to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to successfully start/cancel a upload on a second request as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports cancelling an ongoing log file upload.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Charging Station has log information available of<Configured logType>.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="11">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aGetLogResponse</td><td>1. The OCTT sends a GetLogRequestwith logType<Configured logType></td></tr><tr><td>Note(s):- Charging Station is uploading log file</td><td></td></tr><tr><td>3. The Charging Station sends aLogStatusNotificationRequest</td><td>4. The OCTT responds with aLogStatusNotificationResponse.</td></tr><tr><td>Note(s):- Charging Station cancels uploading the first log file</td><td></td></tr><tr><td>6. The Charging Station responds with aGetLogResponse</td><td>5. The OCTT sends a GetLogRequestwith logType<Configured logType></td></tr><tr><td>7. The Charging Station sends aLogStatusNotificationRequest</td><td>8. The OCTT responds with aLogStatusNotificationResponse.</td></tr><tr><td>Note(s):- Charging Station is uploading log file</td><td></td></tr><tr><td>9. The Charging Station sends aLogStatusNotificationRequest</td><td>10. The OCTT responds with aLogStatusNotificationResponse.</td></tr><tr><td>Note(s):- Log file is uploaded</td><td></td></tr><tr><td>11. The Charging Station sends aLogStatusNotificationRequest</td><td>12. The OCTT responds with aLogStatusNotificationResponse.</td></tr><tr><td>Test case name</td><td>Retrieve Log Information - Second Request</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message GetLogResponse
+- status Accepted
+* Step 3:
+Message LogStatusNotificationRequest
+- status Uploading
+- requestId Same Id as the GetLogRequest
+* Step 6:
+Message GetLogResponse
+- status AcceptedCanceled
+* Step 7:
+Message LogStatusNotificationRequest
+- status AcceptedCanceled
+* Step 9:
+Message LogStatusNotificationRequest
+- status Uploading
+- requestId Same Id as the GetLogRequest
+* Step 11:
+Message LogStatusNotificationRequest
+- status Uploaded
+- requestId Same Id as the GetLogRequest</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 372. Test Case Id: TC_N_37_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Unknown Variable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_37_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to set monitoring triggers on Variables. Multiple triggers can be set for upper or lower thresholds, delta changes or periodic reporting.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to correctly respond to the request when an unknown variable is sent as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station supports Monitoring</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetVariableMonitoringResponse</td><td>1. The OCTT sends a SetVariableMonitoringRequest with setMonitoringData.type Delta setMonitoringData(variable.name unknownVariable setMonitoringData.elementname EVSE</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message SetVariableMonitoringResponse - setMonitoringResult[0].status UnknownVariable - setMonitoringResult[0].type Delta - setMonitoringResult[0].severity <Configured severity> - setMonitoringResult[0].component.name EVSE - setMonitoringResult[0].variable.name unknownVariable</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 373. Test Case Id: TC_N_38_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Not supported MonitorType</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_38_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to set monitoring triggers on Variables. Multiple triggers can be set for upper or lower thresholds, delta changes or periodic reporting.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to correctly respond to the request when a not supported monitortype is sent as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- Charging Station supports Monitoring.
+- Charging station does not support one or more variableMonitoringTypes.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetVariableMonitoringResponse</td><td>1. The OCTT sends a SetVariableMonitoringRequest with setVariableData *setMonitoringData.type
+UpperThreshold
+setMonitoringData(variable.name AvailabilityState
+setMonitoringData.element.name EVSE</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message SetVariableMonitoringResponse
+- setMonitoringResult[0].status UnsupportedMonitorType or Rejected
+- setMonitoringResult[0].type UpperThreshold
+- setMonitoringResult[0].component.name EVSE
+- setMonitoringResult[0].variable.name AvailabilityState</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 374. Test Case Id: TC_N_39_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Component/Variable combination does NOT correspond</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_39_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.16</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to set monitoring triggers on Variables. Multiple triggers can be set for upper or lower thresholds, delta changes or periodic reporting.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to correctly respond to the request when a Component/Variable combination which does NOT correspond is sent as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station supports Monitoring</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Variable monitor is already set with component.name = EVSE, variable.name = AvailabilityState, type = Delta</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetVariableMonitoringResponse</td><td>1. The OCTT sends a SetVariableMonitoringRequest withsetMonitoringData.type UpperThresholdsetMonitoringData(variable.name PowersetMonitoringData.parameter.nameChargingStation</td></tr><tr><td>4. The Charging Station responds with aGetMonitoringReportResponse</td><td>3. The OCTT sends a GetMonitoringReportRequest with- requestId <Generated requestId></td></tr><tr><td>5. The Charging Station sends aNotifyMonitoringReportRequest</td><td>6. The OCTT responds with aNotifyMonitoringReportResponse .</td></tr><tr><td>Note(s):- If tbc is True at Step 3 then step 3 and 4 will be repeated</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetVariableMonitoringResponse-setMonitoringResult[0].status Rejected-setMonitoringResult[0].type UpperThreshold-setMonitoringResult[0].severity <Configured severity>- setMonitoringResult[0].component.name ChargingStation-setMonitoringResult[0].variable.name Power* Step 4:Message GetMonitoringReportResponse-status Accepted* Step 5:Message NotifyMonitoringReportRequest-monitor_component EVSE-monitor_variable AvailabilityState</td></tr><tr><td colspan="2">Post scenario validations:- All report parts have been received</td></tr></table>
+
+Table 375. Test Case Id: TC_N_40_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Replace Variable Monitor</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_40_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.12</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to set monitoring triggers on Variables. Multiple triggers can be set for upper or lower thresholds, delta changes or periodic reporting.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to correctly replace an existing variable monitor as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station supports Monitoring</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Variable monitor is set for Delta with severity 5</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetVariableMonitoringResponse</td><td>1. The OCTT sends a SetVariableMonitoringRequest withsetMonitoringData.id<GeneratedvariableMonitoringId>ANDsetMonitoringData.type Delta setMonitoringData.severity 4</td></tr><tr><td>4. The Charging Station responds with a GetMonitoringReportResponse</td><td>3. The OCTT sends a GetMonitoringReportRequest with- requestId<Generated requestId>componentVariable.parent.name EVSE-componentVariable.parent.evse.id evseld-componentVariable.parent.name AvailabilityState-monitorCriteria DeltaMonitoring_</td></tr><tr><td>5. The Charging Station sends a NotifyMonitoringReportRequest</td><td>6. The OCTT responds with a NotifyMonitoringReportResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetVariableMonitoringResponse-setMonitoringResult[0].status Accepted-setMonitoringResult[0].type Delta-setMonitoringResult[0].component.name EVSE-setMonitoringResult[0].variable.name AvailabilityState* Step 4:Message GetMonitoringReportResponse-status Accepted* Step 5:Message NotifyMonitoringReportRequest-monitor.parent.name EVSE-monitor.parent.name AvailabilityState-monitor.parent.matrix.severity 4</td></tr><tr><td colspan="2">Post scenario validations:- All report parts have been received</td></tr></table>
+
+Table 376. Test Case Id: TC_N_41_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Return to FactoryDefault</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_41_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N03.FR.04, N04.FR.15</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to overrule a preconfigured monitor by a custom monitor. When monitoringBase is set to FactoryDefault the preconfigured monitor must return.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to correctly restore monitors to FactoryDefault.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station supports Monitoring</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A preconfigured monitor exists with id <Preconfigured monitor id> for component EVSE and variable AvailabilityState and type = Delta and severity = <Preconfigured severity></td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetVariableMonitoringResponse</td><td>1. The OCTT sends a SetVariableMonitoringRequest withsetMonitoringData.id <Preconfigured monitor id>ANDsetMonitoringData.type DeltasetMonitoringData.severity <Preconfigured severity> + 1</td></tr><tr><td>4. The Charging Station responds with a GetMonitoringReportResponse</td><td>3. The OCTT sends a GetMonitoringReportRequest with- requestId <Generated requestId> - id <Preconfigured monitor id> - componentVariable.parent.nameEVSE - componentVariable.parent.evse.id evseld - componentVariable.parent.name AvailabilityState - monitoringCriteria DeltaMonitoring</td></tr><tr><td>5. The Charging Station sends a NotifyMonitoringReportRequest</td><td>6. The OCTT responds with a NotifyMonitoringReportResponse .</td></tr><tr><td>8. The Charging Station responds with a SetMonitoringBaseResponse with - status Accepted</td><td>7. The OCTT sends a SetMonitoringBaseRequest with- monitoringBase FactoryDefault</td></tr><tr><td>10. The Charging Station responds with a GetMonitoringReportResponse</td><td>9. The OCTT sends a GetMonitoringReportRequest with- requestId <Generated requestId> - id <Preconfigured monitor id> - componentVariable.parent.nameEVSE - componentVariable.parent.evse.id evseld - componentVariable.parent.name AvailabilityState - monitoringCriteria DeltaMonitoring</td></tr><tr><td>11. The Charging Station sends a NotifyMonitoringReportRequest</td><td>12. The OCTT responds with a NotifyMonitoringReportResponse .</td></tr><tr><td>Test case name</td><td>Set Variable Monitoring - Return to FactoryDefault</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:Message SetVariableMonitoringResponse-setMonitoringResult[0].status Accepted-setMonitoringResult[0].type Delta-setMonitoringResult[0].component.name EVSE-setMonitoringResult[0].variable.name AvailabilityState* Step 4:Message GetMonitoringReportResponse-status Accepted* Step 5:Message NotifyMonitoringReportRequest-monitor_component.name EVSE-monitor_variable.name AvailabilityState-monitor_variableMonitoring.id <Preconfigured id>monitor_variableMonitoring.severity <Preconfigured severity> + 1* Step 11:Message NotifyMonitoringReportRequest-monitor_component.name EVSE-monitor_variable.name AvailabilityState-monitor_variableMonitoring.id <Preconfigured id>monitor_variableMonitoring.severity <Preconfigured severity></td></tr><tr><td>Post scenario validations:- All report parts have been received</td></tr></table>
+
+Table 377. Test Case Id: TC_N_43_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - First SetMonitoringData and third SetMonitoringData are valid, but the second contains an out of range value</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_43_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to set monitoring triggers on Variables. Multiple triggers can be set for upper or lower thresholds, delta changes or periodic reporting.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to correctly respond when one of requested variable monitor data is out of range replace as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station supports Monitoring</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetVariableMonitoringResponse</td><td>1. The OCTT sends a SetVariableMonitoringRequest with - setMonitoringData.element.name = <Configured threshold monitor component variable> - setMonitoringData_variable.name = <Configured threshold monitor component variable> - setMonitoringData[0].value = <Configured threshold monitor value> - setMonitoringData[0].type = UpperThreshold - setMonitoringData[1].value = -1.0 - setMonitoringData[1].type = Delta - setMonitoringData[2].value = <Configured threshold monitor2 value> - setMonitoringData[2].type = LowerThreshold</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: SetVariableMonitoringResponse with (in arbitrary order): setMonitoringResult[1] = { - status = Accepted - type = UpperThreshold - statusInfo is absent or statusInforeasonCode = "NoError" } setMonitoringResult[2] = { - status = Rejected - type = Delta - statusInfo is absent or statusInforeasonCode = "NoError" } setMonitoringResult[3] = { - status = Accepted - type = LowerThreshold - statusInfo is absent or statusInforeasonCode = "NoError" }</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 378. Test Case Id: TC_N_44_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Monitoring - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_44_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N06</td></tr><tr><td>Requirement(s)</td><td colspan="2">N06.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">A monitoring setting can be cleared (removed) by sending a ClearVariableMonitoringRequest with the id of the monitoring setting.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to correctly respond on a request to clear a monitor that cannot be cleared as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station supports Monitoring, Charging Station has hard-coded monitor(s)</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+OCTT Sends a GetMonitoringReportRequest, the CS then reports all existing monitors if it has any. These monitors should be hard-coded and the first Id is used fot the TC.</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a
+ClearVariableMonitoringResponse</td><td>1. The OCTT sends a
+ClearVariableMonitoringRequest with
+id monitor id from the Preparations</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message ClearVariableMonitoringResponse
+- clearMonitoringResult[0].status Rejected</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 379. Test Case Id: TC_N_45_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Alert Event - Delta value exceeded</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_45_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N07.FR.06, N07.FR.07, N07.FR.18, N07.FR.19</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is correctly communicating when a delta value has exceeded as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+Variable monitor is configured with:
+- setMonitoringData:Eve_id = <Configured threshold monitor component variable>
+- setMonitoringData:Eve_id = <Configured EVSEId>
+- setMonitoringData:Eve_id = <Configured threshold monitor value>
+- setMonitoringData:Eve_id = Delta
+- setMonitoringData:Eve_id = <Configured delta monitor component variable>
+Notes: If componentVariable is set to "Power" or "Current", the value is set to 100.0</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: If componentVariable is set to "Power" or "Current" EnergyTransferStarted will trigger the monitor. If another componentvariable is chosen a manual action is needed to trigger the monitor.</td></tr><tr><td colspan="2">1. Execute Reusable State EnergyTransferStarted or manually trigger the monitor.</td></tr><tr><td>2. The Charging Station sends a NotifyEventRequest</td><td>3. The OCTT responds with a NotifyEventResponse .</td></tr><tr><td colspan="2">Note(s):
+- If tbc is True at Step 2 then step 1 and 3 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message NotifyEventRequest
+-eventData[0].trigger Delta
+-eventData[0].component.name <Configured threshold monitor component variable>
+-eventData[0].variable.name <Configured threshold monitor component variable>
+-eventData[0].variableMonitoringld <Configured variableMonitoringld></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 380. Test Case Id: TC_N_47_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Monitoring report - Report all</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_47_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N02.FR.01, N02.FR.11</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to send a report about configured monitoring settings per component and variable. Optionally, this list can be filtered on monitoringCriteria and componentVariables.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to correctly report all monitoring data as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: The following monitors must be present as 'hard-wired' or 'preconfigured' or must have been configured by CSMS: - Component "ChargingStation", variable "AvailabilityState", monitor type Delta" - Component "EVSE", Configured evse, variable "AvailabilityState", monitor type Delta</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetMonitoringReportResponse</td><td>1. The OCTT sends a GetMonitoringReportRequest with monitoringCriteria omitted AND componentVariable omitted.</td></tr><tr><td>3. The Charging Station sends a NotifyMonitoringReportRequest</td><td>4. The OCTT responds with a NotifyMonitoringReportResponse .</td></tr><tr><td colspan="2">Note(s): - If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3: Message: NotifyMonitoringReportRequest - requestId = <Generated requestId> While tbc = true , Message: NotifyMonitoringReportRequest - monitor(variable = "AvailabilityState" - monitor variableMonitoring.type = Delta - monitor_component_name = ChargingStation or EVSE</td></tr><tr><td colspan="2">Post scenario validations: - All reports have been received</td></tr></table>
+
+Table 381. Test Case Id: TC_N_48_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Alert Event - Variable monitoring on write only</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_48_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N07.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to correctly omit the actualField when a variablemonitor has been set to write only as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station should be able to set a monitor on SecurityCtrl.BasicAuthPassword and should be able to use security profile 1 or 2</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:Security profile 1 or 2 is configured</td></tr><tr><td colspan="2">Memory State:A Delta variableMonitoring setting has been set on a SecurityCtrl.BasicAuthPassword</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetVariablesResponse .</td><td>1. The OCTT sends a SetVariablesRequest with component.name = SecurityCtrlvariable.name = BasicAuthPasswordattributeValue = <Generated password with same length as the configured basicAuthPassword></td></tr><tr><td colspan="2">3. Execute Reusable State Booted.Notes: This step only needs to be executed when SetVariablesResponse status is RebootRequired.</td></tr><tr><td>4. The Charging station sends a NotifyEventRequest</td><td>5. The OCTT responds with a NotifyEventResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetVariablesResponse- status must be Accepted or RebootRequired* Step 4:Message NotifyEventRequest-eventData[0].actualValue must be an empty string</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 382. Test Case Id: TC_N_61_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Alert Event - Variable monitoring on numeric</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_61_CS</td></tr><tr><td>Use case ld(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N07.FR.10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to correctly respond when a nomeric Delta monitor is matched and exceeded, as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station should be able to set a monitor on OCPPCommCtrlr.OfflineThreshold</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A Delta variableMonitoring setting has been set on a OCPPCommCtrlr.OfflineThreshold</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetVariablesResponse.</td><td>1. The OCTT sends a SetVariablesRequest with component.name = OCPPCommCtrlr variable.name = OfflineThreshold attributeValue = Current Threshold + 1</td></tr><tr><td colspan="2">3. Execute Reusable State Booted.Notes: This step only needs to be executed when SetVariablesResponse status is RebootRequired.</td></tr><tr><td colspan="2">Notes: The CS should not send a NotifyEvent as the delta monitor was not exceeded.</td></tr><tr><td>5. The Charging Station responds with a SetVariablesResponse.</td><td>4. The OCTT sends a SetVariablesRequest with component.name = OCPPCommCtrlr variable.name = OfflineThreshold attributeValue = Current Threshold + 2</td></tr><tr><td colspan="2">6. Execute Reusable State Booted.Notes: This step only needs to be executed when SetVariablesResponse status is RebootRequired.</td></tr><tr><td>7. The Charging station sends a NotifyEventRequest</td><td>8. The OCTT responds with a NotifyEventResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetVariablesResponse- status must be Accepted or RebootRequired+ * Step 5:Message SetVariablesResponse- status must be Accepted or RebootRequired+ * Step 7:Message NotifyEventRequest-eventData[0].actualValue must be Current Threshold + 2</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 383. Test Case Id: TC_N_51_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Replace Variable Monitor</td><td></td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_51_CS</td><td></td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07</td><td></td></tr><tr><td>Requirement(s)</td><td colspan="2">N07.FR.11</td><td></td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td><td></td></tr><tr><td>Description</td><td colspan="2">NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td><td></td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to correctly check if the current value exceeds the new threshold as described at the OCPP specification.</td><td></td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station supports Monitoring</td><td></td></tr><tr><td colspan="3"></td><td></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td><td></td></tr><tr><td colspan="2">Memory State: Variable monitor is already set with: setMonitoringData:Eve.s.id AND setMonitoringData.type UpperThreshold AND setMonitoringData variable.name AND Notes: If componentVariable is set to "Power" or "Current", the value is set to the configured maxLimit -1</td><td></td></tr><tr><td colspan="2">Charging State: N/a</td><td></td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td><td></td></tr><tr><td colspan="2">Notes: If componentVariable is set to "Power" or "Current" EnergyTransferStarted will trigger the monitor. If another componentvariable is chosen a manual action is needed to trigger the monitor.</td><td></td></tr><tr><td colspan="2">1. Execute Reusable State EnergyTransferStarted or manually trigger the monitor.</td><td></td></tr><tr><td>3. The Charging Station responds with a SetVariableMonitoringResponse</td><td colspan="2">2. The OCTT sends a SetVariableMonitoringRequest with setMonitoringData:Eve.s.id AND setMonitoringData.type UpperThreshold and setMonitoringData variable.name AND setMonitoringData variable.name AND setMonitoringData type UpperThreshold setMonitoringData variable.name AND setMonitoringData type UpperThreshold setMonitoringData variable.name AND setMonitoringData type UpperThreshold setMonitoringData variable.name AND setMonitoringData type UpperThreshold setMonitoringData variable.name AND setMonitoringData type UpperThreshold setMonitoringData variable.name AND setMonitoringData type UpperThreshold setMonitoringData variable.name AND setMonitoringData type UpperThreshold setMonitoringData variable.name AND setMonitoringData type UpperThreshold setMonitoringData variable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.nameAND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND setMonitoringData type UpperThreshold setMonitoringData varialable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type Lower Threshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitorING Data type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.nameAND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold set-monitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData data type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name And set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitorData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData variable name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThresholdsetMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoring Data type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.name AND set-monitoringData type LowerThreshold setMonitoringData variable.eve.s.id AND set-monitoringData variable is set to "Power" or "Current", the value is set to 0.0</td></tr><tr><td>4. The Charging station sends a NotifyEventRequest</td><td>5. The OCTT responds with a NotifyEventResponse .</td><td></td></tr></table>
+
+<table><tr><td>Test case name</td><td>Set Variable Monitoring - Replace Variable Monitor</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 3:
+Message SetVariableMonitoringResponse
+- setMonitoringResult[0].status Accepted
+- setMonitoringResult[0].type UpperThreshold
+- setMonitoringResult[0].severity <Configured severity>
+- setMonitoringResult[0].component.name <Configured threshold monitor component variable>
+- setMonitoringResult[0].variable.name <Configured threshold monitor component variable>
+* Step 4:
+Message NotifyEventRequest
+- eventData[0].trigger Alerting
+- eventData[0].actualValue > <Configured threshold monitor value></td></tr><tr><td>Post scenario validations:
+- All report parts have been received</td></tr></table>
+
+Table 384. Test Case Id: TC_N_52_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Removing a VariableMonitor</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_52_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N07.FR.12</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to correctly communicate when a threshold has been exceeded and the applicable monitor is removed as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station supports Monitoring</td></tr><tr><td rowspan="4">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td>Memory State:Variable monitor is already set with:setMonitoringData:Eve.s.id ANDsetMonitoringData:Eve.s.id ANDsetMonitoringData:Eve.s.id ANDsetMonitoringData:Eve.s.id ANDsetMonitoringData:Eve.s.id ANDsetMonitoringData:Eve.s.id ANDsetMonitoringData:Eve.s.id ANDsetMonitoringData:Eve.s.id ANDsetMonitoringData:Eve.s.id ANDsetMonitoringData:Eve.s.id ANDsetMonitoringData:Eve.s.id ANDsetMonitoringData:Eve.s.id ANDsetMonitoringData:Eve.s.id ANDsetMonitoringData:X</td><td></td></tr><tr><td colspan="2">Notes: If componentVariable is set to "Power" or "Current", the value is set to 0.0</td></tr><tr><td colspan="2">Charging State:Execute Reusable State EnergyTransferStarted or manually trigger the monitor.Notes: If componentVariable is set to "Power" or "Current" EnergyTransferStarted will trigger the monitor. If another componentvariable is chosen a manual action is needed to trigger the monitor.</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ClearVariableMonitoringResponse</td><td>1. The OCTT sends a ClearVariableMonitoringRequest with id<Configured variableMonitoringId></td></tr><tr><td>4. The Charging Station responds with a GetMonitoringReportResponse</td><td>3. The OCTT sends a GetMonitoringReportRequest with componentVariablecomponent<Configured threshold monitor component variable>componentVariable.value<Configured threshold monitor variable>monitoringCriteria ThresholdMonitoring</td></tr><tr><td colspan="2">5. Execute Reusable State StopAuthorized or manually trigger the monitor.Notes: If componentVariable is set to "Power" or "Current" EnergyTransferStarted will trigger the monitor. If another componentvariable is chosen a manual action is needed to trigger the monitor.</td></tr><tr><td>6. The Charging Station should not send a request for the cleared monitor</td><td></td></tr><tr><td rowspan="4">Tool validations</td><td colspan="2">* Step 2:Message ClearVariableMonitoringResponse-clearMonitoringResult[0].status Accepted AND-clearMonitoringResult[0].id<Configured variableMonitoringId></td></tr><tr><td colspan="2">* Step 4:Message GetMonitoringReportResponse-getMonitoringResult[0].status EmptyResultSet</td></tr><tr><td colspan="2">* Step 6:- No NotifyEventRequest with variableMonitoringId<Configured variableMonitoringId> is send</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 385. Test Case Id: TC_N_53_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Alert Event - Persistent over reboot</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_53_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N07.FR.13</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is able to save the variableMonitor data persistent across reboot as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Variable monitor is already set with:setMonitoringData.elementname<Configured threshold monitor component variable> ANDsetMonitoringData_elementevse_id<Configured EVSEId> ANDsetMonitoringData_value<Configured threshold monitor value> ANDsetMonitoringData_type UpperThreshold ANDsetMonitoringData_variable.name<Configured threshold monitor component variable></td></tr><tr><td colspan="2">Charging State:Execute Reusable State Booted</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aGetMonitoringReportResponse</td><td>1. The OCTT sends a GetMonitoringReportRequest withmonitoringCriteria ThresholdMonitoring</td></tr><tr><td>3. The Charging Station sends aNotifyMonitoringReportRequest</td><td>4. The OCTT responds with aNotifyMonitoringReportResponse .</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3:Message NotifyMonitoringReportRequest- requestId <The Id of the request> AND-monitorvariableMonitoring.id<Received monitorId from set monitor> - monitor variableMonitoring.typeUpperThreshold</td></tr><tr><td colspan="2">Post scenario validations:- All reports have been received</td></tr></table>
+
+Table 386. Test Case Id: TC_N_56_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Alert Event - Delta value NOT numeric exceeded</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_56_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N07.FR.06, N07.FR.07, N07.FR.18, N07.FR.19</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging station is correctly communicating when a delta value has exceeded as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Variable monitor is configured with:component.evse.id<Configured EVSEId>component.name EVSEseverity<Configured severity>Type Deltavalue 1.0variable.name AvailabilityState</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Make sure the configured delta value has been exceeded</td></tr><tr><td>1. The Charging Station sends a NotifyEventRequest</td><td>2. The OCTT responds with a NotifyEventResponse .</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 1 then step 1 and 2 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message NotifyEventRequest-eventData[0].trigger Delta-eventData[0].component.name EVSE-eventData[0].variable.name AvailabilityState-eventData[0].variableMonitoringId monitoringId of monitor set in Memory State</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+# 2.16. O Display Message
+
+Table 387. Test Case Id: TC_O_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_12</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display additional messages according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest withmessage.id<Generated displayMessageId>messagepriority<Configured priority></td></tr><tr><td colspan="2">Note(s):- The display message is displayed as configured</td></tr><tr><td>4. The Charging Station responds with a GetDisplayMessagesResponse</td><td>3. The OCTT sends a GetDisplayMessagesRequest withid<Generated displayMessageId>requestId<Generated requestId></td></tr><tr><td>5. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>6. The OCTT responds with aNotifyDisplayMessagesResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetDisplayMessageResponse-status Accepted* Step 4:Message GetDisplayMessagesResponse-status Accepted* Step 5:Message NotifyDisplayMessagesRequest-requestId<RequestId sent in step 3>- id<Generated id>- priority<Configured Priority>- message.format<Configured format>- message(content<Configured content></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 388. Test Case Id: TC_O_02_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get all Display Messages - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_02_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">003</td></tr><tr><td>Requirement(s)</td><td colspan="2">003_FR_01, 003_FR_02, 003_FR_03, 003_FR_04, 003_FR_05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request all the installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to send the requested DisplayMessages according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:At least 1 display message is configured.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetDisplayMessagesResponse</td><td>1. The OCTT sends a GetDisplayMessagesRequestrequestId <Generated requestId></td></tr><tr><td>3. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>4. The OCTT responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td>Note(s):- If tbc is True at Step 3 then step 3 and 4 will be repeated</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetDisplayMessagesResponse-status Accepted* Step 3:Message NotifyDisplayMessagesRequest-requestId <Generated requestId></td></tr><tr><td colspan="2">Post scenario validations:- All messages have been received</td></tr></table>
+
+Table 389. Test Case Id: TC_O_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get all Display Messages - No DisplayMessages configured</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">003</td></tr><tr><td>Requirement(s)</td><td colspan="2">003_FR_06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request all the installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is responding according to the DisplayMessage mechanism as described in the OCPP specification when no Display Messages are configured.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetDisplayMessagesResponse</td><td>1. The OCTT sends a GetDisplayMessagesRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetDisplayMessagesResponse-status Unknown</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 390. Test Case Id: TC_O_04_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Display Message - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">005</td></tr><tr><td>Requirement(s)</td><td colspan="2">005_FR_01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can remove a specific message, configured via OCPP in a Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to remove a specific message requested by the CSMS according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A message with <Generated displayMessageId> is configured.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ClearDisplayMessageResponse</td><td>1. The OCTT sends a ClearDisplayMessageRequest with id <Generated displayMessageId></td></tr><tr><td>4. The Charging Station responds with a GetDisplayMessagesResponse</td><td>3. The OCTT sends a GetDisplayMessagesRequest with id <Generated displayMessageId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message ClearDisplayMessageResponse-status Accepted* Step 4:Message:GetDisplayMessagesResponse-status must be Unknown</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 391. Test Case Id: TC_O_05_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Display Message - Unknown Key</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_05_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">005</td></tr><tr><td>Requirement(s)</td><td colspan="2">005_FR_02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can remove a specific message, configured via OCPP in a Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond according the mechanism as described in the OCPP specification when no message is configured with the specified id.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ClearDisplayMessageResponse</td><td>1. The OCTT sends a ClearDisplayMessageRequest with id <Generated displayMessageId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message ClearDisplayMessageResponse - status Unknown</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 392. Test Case Id: TC_O_06_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Specific transaction - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_06_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">002</td></tr><tr><td>Requirement(s)</td><td colspan="2">002.FR.02, 002_FR_14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can set a message to be displayed on a Charging Station for a specific transaction. Depending on the given parameters the message shall be displayed a certain way on the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display the message correctly according the mechanism as described in the OCPP specification when a transaction is ongoing.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:State is EnergyTransferStarted</td></tr><tr><td rowspan="9">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest withmessage.id<Generated displayMessageId>ANDmessage_transactionId<Configured transactionId>ANDmessagepriority<Configured Priority</td></tr><tr><td colspan="2">Note(s):- The display message is displayed as configured</td></tr><tr><td colspan="2">3. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">4. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">5. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">6. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">Note(s):- The display message is not displayed anymore</td></tr><tr><td>8. The Charging Station responds with a GetDisplayMessagesResponse</td><td>7. The OCTT sends a GetDisplayMessagesRequest withid<Generated displayMessageId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: SetDisplayMessageResponse-status must be Accepted* Step 8:Message: GetDisplayMessagesResponse-status must be Unknown</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 393. Test Case Id: TC_O_07_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get a Specific Display Message - Id</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_07_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">004</td></tr><tr><td>Requirement(s)</td><td colspan="2">004_FR_01, 004_FR_03, 004_FR_04, 004_FR_05, 004_FR_06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request specific installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Margin Station is able to respond the specific id message requested by the CSMS according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A display message with <Generated displayMessageId> is configured.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetDisplayMessagesResponse</td><td>1. The OCTT sends a GetDisplayMessagesRequest with id <Generated displayMessageId> requestId<Generated requestId></td></tr><tr><td>3. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>4. The OCTT responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td>Note(s):- If tbc is True at Step 3 then step 3 and 4 will be repeated</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetDisplayMessagesResponse-status Accepted* Step 3:Message NotifyDisplayMessagesRequest-requestId<Generated requestId></td></tr><tr><td colspan="2">Post scenario validations:- All messages have been received</td></tr></table>
+
+Table 394. Test Case Id: TC_O_08_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get a Specific Display Message - Priority</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_08_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">004</td></tr><tr><td>Requirement(s)</td><td colspan="2">004_FR_01, 004_FR_03, 004_FR_04, 004_FR_05, 004_FR_06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request specific installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Margin Station is able to respond the specific priority messages requested by the CSMS according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:At least 1 message with <Configured display_messagepriority> is configured</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetDisplayMessagesResponse</td><td>1. The OCTT sends a GetDisplayMessagesRequest with priority <Configured display_messagepriority>requestId <Generated requestId></td></tr><tr><td>3. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>4. The OCTT responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td>Note(s):- If tbc is True at Step 3 then step 3 and 4 will be repeated</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetDisplayMessagesResponse-status Accepted* Step 3:Message NotifyDisplayMessagesRequest-requestId <Generated requestId></td></tr><tr><td colspan="2">Post scenario validations:- All messages have been received</td></tr></table>
+
+Table 395. Test Case Id: TC_O_09_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get a Specific Display Message - State</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_09_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">004</td></tr><tr><td>Requirement(s)</td><td colspan="2">004_FR_01, 004_FR_03, 004_FR_04, 004_FR_05, 004_FR_06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request specific installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Margin Station is able to respond the specific state messages requested by the CSMS according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:At least 1 message with <Configured display_message_state> is configured</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetDisplayMessagesResponse</td><td>1. The OCTT sends a GetDisplayMessagesRequest with state <Configured display_message_state> requestId<Generated requestId></td></tr><tr><td>3. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>4. The OCTT responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td>Note(s):- If tbc is True at Step 3 then step 3 and 4 will be repeated</td><td></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetDisplayMessagesResponse-status Accepted* Step 3:Message NotifyDisplayMessagesRequest-requestId<Generated requestId></td></tr><tr><td colspan="2">Post scenario validations:- All messages have been received</td></tr></table>
+
+Table 396. Test Case Id: TC_O_10_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Specific transaction - UnknownTransaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_10_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">002</td></tr><tr><td>Requirement(s)</td><td colspan="2">002_FR_01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can set a message to be displayed on a Charging Station for a specific transaction. Depending on the given parameters the message shall be displayed a certain way on the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station responds correctly according the mechanism as described in the OCPP specification when a display message request is received for an unknown specific transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest withmessage.id<Generated displayMessageId>ANDmessage_transactionId<Generated transactionId>ANDmessage.priority<Configured Priority</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetDisplayMessageResponse-status UnknownTransaction</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 397. Test Case Id: TC_O_11_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get a Specific Display Message - Unknown parameters</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_11_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">004</td></tr><tr><td>Requirement(s)</td><td colspan="2">004_FR_02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request specific installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly according to the mechanism as described in the OCPP specification when the specific id message requested by the CSMS is unknown.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:One display message with <Generated displayMessageld> is configured.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetDisplayMessagesResponse</td><td>1. The OCTT sends a GetDisplayMessagesRequest with id <Other generated messageld></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetDisplayMessagesResponse-status Unknown</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 398. Test Case Id: TC_O_12_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Replace DisplayMessage</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_12_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">006</td></tr><tr><td>Requirement(s)</td><td colspan="2">006_FR_01</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can replace a DisplayMessage that is previously configured in a Charging Station. Replace the message content, but also all the given parameters with the new one.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charger Station is able to replace a display message according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: Display message configured with <Generated displayMessageId></td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest with message.id <Generated displayMessageId from set Display Message> message.priority <Configured Priority</td></tr><tr><td colspan="2">Note(s): - The display message is replaced by a new one.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message SetDisplayMessageResponse - status Accepted</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 399. Test Case Id: TC_O_13_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Display message at StartTime</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_13_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display additional messages with a certain start time according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest withmessage_id<Generated displayMessageId>messagepriority<Configured Prioritymessage.startDateTime<Current dateTime+60seconds></td></tr><tr><td>4. The Charging Station responds with aGetDisplayMessagesResponse</td><td>3. The OCTT sends a GetDisplayMessagesRequest withid<Generated displayMessageId></td></tr><tr><td>5. The Charging Station sends aNotifyDisplayMessagesRequest</td><td>6. The OCTT responds with aNotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 5 then step 5 and 6 will be repeated-Wait till 60 seconds are passed-The display message should be displayed after 60 seconds.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetDisplayMessageResponse-status Accepted* Step 4:Message GetDisplayMessagesResponse-status Accepted* Step 5:Message NotifyDisplayMessagesRequest-requestId<Generated requestId>- startDateTime<Should not be Omitted.></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 400. Test Case Id: TC_O_14_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Remove message after EndTime</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_14_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display additional messages with a certain end time according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest withmessage_id<Generated displayMessageId>messagepriority<Configured Prioritymessage.endDateTime<Current dateTime + 60 seconds></td></tr><tr><td>4. The Charging Station responds with a GetDisplayMessagesResponse</td><td>3. The OCTT sends a GetDisplayMessagesRequest withid<Generated displayMessageId></td></tr><tr><td>5. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>6. The OCTT responds with aNotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 5 then step 5 and 6 will be repeated-Wait till 60 seconds are passed-The display message is displayed and removed after 60 seconds.</td></tr><tr><td>8. The Charging Station responds with a GetDisplayMessagesResponse</td><td>7. The OCTT sends a GetDisplayMessagesRequest withid<Generated displayMessageId>requestId<Generated requestId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetDisplayMessageResponse-status Accepted* Step 4:Message GetDisplayMessagesResponse-status Accepted* Step 5:Message NotifyDisplayMessagesRequest-requestId<Generated requestId>- endDateTime<Should not be Omitted.* Step 8:Message GetDisplayMessagesResponse-status Unknown</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 401. Test Case Id: TC_O_15_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Language preference of the EV Driver</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_15_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_08</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to set the preferred language according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging station supports <Configured Language></td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State: State is EVConnectedPreSession</td></tr><tr><td rowspan="6">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present valid idToken which has a preferred language of <Configured language></td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Accepted idTokenInfo.language1 <Configured language></td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>5. The Charging Station responds with a SetDisplayMessageResponse</td><td>4. The OCTT sends a SetDisplayMessageRequest with message.id <Generated displayMessageld> message.priority <Configured Priority message.message_content <Configured Message></td></tr><tr><td colspan="2">Note(s): - The display message is displayed in the preferred language of the idToken as configured</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message AuthorizationRequest
+-idToken.idToken <Configured valid_idtoken_idtoken>
+-idToken.type <Configured valid_idtoken_type>
+* Step 5:
+Message SetDisplayMessageResponse
+-status Accepted</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 402. Test Case Id: TC_O_17_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - NotSupportedPriority</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_17_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_01, 002.FR.03</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly when the priority of the display messages is not supported according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging station should not support all priorities described in the OCPP specification</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest withmessage.id <Generated displayMessageId>message.priority <Configuredunsupported_display_messagepriority></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetDisplayMessageResponse-status NotSupportedPriority</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 403. Test Case Id: TC_O_18_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - NotSupportedState</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_18_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_02, 002.FR.04</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly when the state of the display messages is not supported according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging station should not support all states described in the OCPP specification</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest withmessage.id <Generated displayMessageId>message.state <Configuredunsupported_display_message_state></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetDisplayMessageResponse-status NotSupportedState</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 404. Test Case Id: TC_O_19_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - NotSupportedMessageFormat</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_19_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_03, 002.FR.05</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly when the message format of the display messages is not supported according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging station does not support all formats described in the OCPP specification</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest withmessage.id <Generated displayMessageId>Note(s):The message is send in an unsupported format</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetDisplayMessageResponse-status NotSupportedMessageFormat</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 405. Test Case Id: TC_O_20_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Persistent over reboot</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_20_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_10</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to store display messages persistent over reboot according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest withmessage.id<Generated displayMessageId>messagepriority<Configured Priority></td></tr><tr><td colspan="2">3. Execute Reusable State Booted</td></tr><tr><td>5. The Charging Station responds with a GetDisplayMessagesResponse</td><td>4. The OCTT sends a GetDisplayMessagesRequest withid<Generated displayMessageId>requestId<Generated requestId></td></tr><tr><td>6. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>7. The OCTT responds with aNotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 5 then step 5 and 6 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetDisplayMessageResponse*- status Accepted*- Step 5:Message GetDisplayMessagesResponse*- status Accepted*- Step 6:Message NotifyDisplayMessagesRequest- requestId<RequestId sent in step 4>- id<Generated id>- priority<Configured Priority>- message.format<Configured format>- message(content<Configured content></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 406. Test Case Id: TC_O_22_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Multiple In front priority</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_22_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_14</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display multiple additional messages with a "InFront" priority according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="8">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>messagepriority InFront</td></tr><tr><td>4. The Charging Station responds with a SetDisplayMessageResponse</td><td>3. The OCTT sends a SetDisplayMessageRequest with message.id <Generated displayMessage2Id>messagepriority InFront</td></tr><tr><td>6. The Charging Station responds with a GetDisplayMessagesResponse</td><td>5. The OCTT sends a GetDisplayMessagesRequest with id <Generated displayMessageId>requestId<Generated requestId></td></tr><tr><td>7. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>8. The OCTT responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td>10. The Charging Station responds with a GetDisplayMessagesResponse</td><td>9. The OCTT sends a GetDisplayMessagesRequest with id <Generated displayMessage2Id>requestId<Generated requestId></td></tr><tr><td>11. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>12. The OCTT responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 7 then step 7 and 8 will be repeated- If tbc is True at Step 11 then step 11 and 12 will be repeated- The display messages are displayed as configured according the priority</td></tr><tr><td>Test case name</td><td>Set Display Message - Multiple In front priority</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message SetDisplayMessageResponse
+- status Accepted
+* Step 4:
+Message SetDisplayMessageResponse
+- status Accepted
+* Step 6:
+Message GetDisplayMessagesResponse
+- status Accepted
+* Step 7:
+Message NotifyDisplayMessagesRequest
+- requestId <Generated requestId>
+* Step 10:
+Message GetDisplayMessagesResponse
+- status Accepted
+* Step 11:
+Message NotifyDisplayMessagesRequest
+- requestId <Generated requestId></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 407. Test Case Id: TC_O_24_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Second Alwaysfront priority</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_24_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_16</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display multiple additional messages with a "AlwaysFront" priority according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest with message.id<Generated displayMessageId>messagepriority<Configured Priority></td></tr><tr><td>4. The Charging Station responds with a SetDisplayMessageResponse</td><td>3. The OCTT sends a SetDisplayMessageRequest with message.id<Configured displayMessage2Id>messagepriority<Configured Priority></td></tr><tr><td>6. The Charging Station responds with a GetDisplayMessagesResponse</td><td>5. The OCTT sends a GetDisplayMessagesRequest with id<Generated displayMessageId>requestId<Generated requestId></td></tr><tr><td>8. The Charging Station responds with a GetDisplayMessagesResponse</td><td>7. The OCTT sends a GetDisplayMessagesRequest with id<Configured displayMessage2Id></td></tr><tr><td>9. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>10. The OCTT responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 7 then step 7 and 8 will be repeated- If tbc is True at Step 11 then step 11 and 12 will be repeated- The display messages are displayed as configured according the priority</td></tr><tr><td>Test case name</td><td>Set Display Message - Second Alwaysfront priority</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message SetDisplayMessageResponse
+- status Accepted
+* Step 4:
+Message SetDisplayMessageResponse
+- status Accepted
+* Step 6:
+Message GetDisplayMessagesResponse
+- status Unknown
+* Step 8:
+Message GetDisplayMessagesResponse
+- status Accepted
+* Step 9:
+Message NotifyDisplayMessagesRequest
+- requestId <Generated requestId></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 408. Test Case Id: TC_O_27_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Specific transaction - Display message at StartTime</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_27_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">002</td></tr><tr><td>Requirement(s)</td><td colspan="2">002_FR_06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can set a message to be displayed on a Charging Station for a specific transaction. Depending on the given parameters the message shall be displayed a certain way on the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display the message with a certain start time correctly according the mechanism as described in the OCPP specification when a transaction is ongoing.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:State is EnergyTransferStarted</td></tr><tr><td rowspan="9">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest with message.id<Generated displayMessageId>messagepriority<Configured Prioritymessage.startDateTime<Current dateTime + 60 seconds></td></tr><tr><td colspan="2">Note(s):- The display message is not yet displayed.- Waiting 60 seconds.- The display message is displayed after 60 seconds.</td></tr><tr><td colspan="2">3. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">4. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">5. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">6. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">Note(s):- The display message is not displayed anymore</td></tr><tr><td>8. The Charging Station responds with a GetDisplayMessagesResponse</td><td>7. The OCTT sends a GetDisplayMessagesRequest with id<Generated displayMessageId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetDisplayMessageResponse-status Accepted* Step 8:Message:GetDisplayMessagesResponse-status Unknown</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 409. Test Case Id: TC_O_28_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Specific transaction - Remove message after EndTime</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_28_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">002</td></tr><tr><td>Requirement(s)</td><td colspan="2">002_FR_07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display additional messages with a certain end time for a specific transaction according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>
+messagepriority <Configured Priority
+message.endDateTime <Current dateTime + 60
+seconds></td></tr><tr><td colspan="2">Note(s):
+- The display message should be displayed.
+- Waiting 60 seconds.
+- The display message is not being displayed anymore after 60 seconds.</td></tr><tr><td>4. The Charging Station responds with a GetDisplayMessagesResponse</td><td>3. The OCTT sends a GetDisplayMessagesRequest with id <Generated displayMessageId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message SetDisplayMessageResponse
+- status Accepted
+* Step 4:
+Message GetDisplayMessagesResponse
+- status Unknown</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 410. Test Case Id: TC_O_30_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Specific transaction - Multiple In front priority</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_30_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">002</td></tr><tr><td>Requirement(s)</td><td colspan="2">002_FR_16</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can set a message to be displayed on a Charging Station for a specific transaction. Depending on the given parameters the message shall be displayed a certain way on the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display multiple additional messages with a "InFront" priority for a specific transaction according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:State is EnergyTransferStarted</td></tr><tr><td rowspan="8">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest withmessage_id<Generated displayMessageId>ANDmessage_transactionId<Received transactionId>ANDmessagepriority InFront</td></tr><tr><td>4. The Charging Station responds with a SetDisplayMessageResponse</td><td>3. The OCTT sends a SetDisplayMessageRequest withmessage_id<Generated displayMessageId>ANDmessage_transactionId<Received transactionId>ANDmessagepriority InFront</td></tr><tr><td colspan="2">Note(s):- The display messages are displayed as configured</td></tr><tr><td>6. The Charging Station responds with a GetDisplayMessagesResponse</td><td>5. The OCTT sends a GetDisplayMessagesRequest withid<Generated displayMessageId>requestId<Generated requestId></td></tr><tr><td>7. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>8. The OCTT responds with aNotifyDisplayMessagesResponse.</td></tr><tr><td>10. The Charging Station responds with a GetDisplayMessagesResponse</td><td>9. The OCTT sends a GetDisplayMessagesRequest withid<Generated displayMessageId>requestId<Generated requestId></td></tr><tr><td>11. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>12. The OCTT responds with aNotifyDisplayMessagesResponse.</td></tr><tr><td rowspan="7"></td><td colspan="2">13. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">14. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">15. Execute Reusable State EVDisconnect</td></tr><tr><td colspan="2">16. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">Note(s):- The display messages are not displayed anymore</td></tr><tr><td>18. The Charging Station responds with a GetDisplayMessagesResponse</td><td>17. The OCTT sends a GetDisplayMessagesRequest with id <Generated displayMessageId></td></tr><tr><td>20. The Charging Station responds with a GetDisplayMessagesResponse</td><td>19. The OCTT sends a GetDisplayMessagesRequest with id <Configured displayMessage2Id></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetDisplayMessageResponse- status Accepted* Step 4:Message SetDisplayMessageResponse- status Accepted* Step 6:Message: GetDisplayMessagesResponse- status Accepted* Step 7:Message: NotifyDisplayMessagesRequest- requestId <Generated RequestId>- transactionId <Generated transactionId>- priority InFront-message content <Configured message>* Step 10:Message: GetDisplayMessagesResponse- status Accepted* Step 11:Message: NotifyDisplayMessagesRequest- requestId <Generated RequestId>- transactionId <Generated transactionId>- priority InFront-message content <Configured message with a " 2" extended to it.> * Step 18:Message: GetDisplayMessagesResponse- status Unknown* Step 20:Message: GetDisplayMessagesResponse- status Unknown</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 411. Test Case Id: TC_O_32_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Specific transaction - Second Alwaysfront priority</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_32_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">002</td></tr><tr><td>Requirement(s)</td><td colspan="2">002_FR_18</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can set a message to be displayed on a Charging Station for a specific transaction. Depending on the given parameters the message shall be displayed a certain way on the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display multiple additional messages with a "AlwaysFront" priority for a specific transaction according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:State is EnergyTransferStarted</td></tr><tr><td rowspan="12">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest withmessage.id <Generated displayMessageId>message_transactionId <Received transactionId>ANDmessage.priority AlwaysFront</td></tr><tr><td>4. The Charging Station responds with a SetDisplayMessageResponse</td><td>3. The OCTT sends a SetDisplayMessageRequest withmessage.id <Configured displayMessage2Id>message_transactionId <Received transactionId>ANDmessage.priority AlwaysFront</td></tr><tr><td>6. The Charging Station responds with a GetDisplayMessagesResponse</td><td>5. The OCTT sends a GetDisplayMessagesRequest withid <Generated displayMessageId></td></tr><tr><td>8. The Charging Station responds with a GetDisplayMessagesResponse</td><td>7. The OCTT sends a GetDisplayMessagesRequest withid <Generated displayMessageId>requestId<Generated requestId></td></tr><tr><td>9. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>10. The OCTT responds with aNotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">11. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">12. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">13. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">14. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">Note(s):- The display message is not displayed anymore</td></tr><tr><td>16. The Charging Station responds with aGetDisplayMessagesResponse</td><td>15. The OCTT sends a GetDisplayMessagesRequest withid <Generated displayMessageId></td></tr><tr><td>Test case name</td><td>Set Display Message - Specific transaction - Second Alwaysfront priority</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message SetDisplayMessageResponse
+- status Accepted
+* Step 4:
+Message SetDisplayMessageResponse
+- status Accepted
+* Step 6:
+Message GetDisplayMessagesResponse
+- status Unknown
+* Step 8:
+Message GetDisplayMessagesResponse
+- status Accepted
+* Step 9:
+Message: NotifyDisplayMessagesRequest
+- requestId <Generated RequestId>
+- transactionId <Generated transactionId>
+- priority AlwaysFront
+- message(content <Configured message with a "2" extended to it.>
+* Step 16:
+Message: GetDisplayMessagesResponse
+- status Unknown</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 412. Test Case Id: TC_O_33_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get a Specific Display Message - No DisplayMessages configured</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_33_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">004</td></tr><tr><td>Requirement(s)</td><td colspan="2">004_FR_07</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request specific installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly when a specific id message is requested by the CSMS but no messages are configured according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetDisplayMessagesResponse</td><td>1. The OCTT sends a GetDisplayMessagesRequest withid <Generated displayMessageId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetDisplayMessagesResponse-status Unknown</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 413. Test Case Id: TC_O_34_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get a Specific Display Message - Known Id, but not matching State</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_34_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">004</td></tr><tr><td>Requirement(s)</td><td colspan="2">004_FR_02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request specific installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly when a specific id message is requested by the CSMS but the requested State is different according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Configured display message state 1, must be different than display message state 2.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A display message is configured with <Generated displayMessageld> and <Configureddisplay_message_state></td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aGetDisplayMessagesResponse</td><td>1. The OCTT sends a GetDisplayMessagesRequest withid<Generated displayMessageld> ANDstate<Configured display_message_2_state></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetDisplayMessagesResponse-status Unknown</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 414. Test Case Id: TC_O_35_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Get a Specific Display Message - Known Id, but not matching Priority</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_35_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">004</td></tr><tr><td>Requirement(s)</td><td colspan="2">004_FR_02</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request specific installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to respond correctly when a specific id message is requested by the CSMS but the requested priority is different according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Configured display message priority 1, must be different than display message priority 2.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A display message is configured with <Generated displayMessageld> and <Configured priority></td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetDisplayMessagesResponse</td><td>1. The OCTT sends a GetDisplayMessagesRequest with id <Generated displayMessageld> AND state <Configured display_message_2priority></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message GetDisplayMessagesResponse-status Unknown</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 415. Test Case Id: TC_O_36_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - State Charging</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_36_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display specific messages while the chargingState is Charging according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="16">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>messagepriority <Configured Priority message.state Charging</td></tr><tr><td colspan="2">Note(s): The display message should NOT be displayed.</td></tr><tr><td colspan="2">3. Execute Reusable State ParkingBayOccupied</td></tr><tr><td colspan="2">4. Execute Reusable State Authorized</td></tr><tr><td colspan="2">5. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">6. Execute Reusable State EnergyTransferStarted</td></tr><tr><td colspan="2">Note(s): The display message should be displayed.</td></tr><tr><td colspan="2">7. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">8. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">9. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">10. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">Note(s): The display message should NOT be displayed.</td></tr><tr><td>12. The Charging Station responds with a GetDisplayMessagesResponse</td><td>11. The OCTT sends a GetDisplayMessagesRequest with id <Generated displayMessageId>requestId <Generated requestId></td></tr><tr><td>13. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>14. The OCTT responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s): If tbc is True at Step 15 then step 15 and 16 will be repeated</td></tr><tr><td>Test case name</td><td>Set Display Message - State Charging</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message SetDisplayMessageResponse
+- status Accepted
+* Step 12:
+Message GetDisplayMessagesResponse
+- status Accepted
+* Step 13:
+Message NotifyDisplayMessagesRequest
+- requestId <Generated requestId>
+- state Charging</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 416. Test Case Id: TC_O_37_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - State Idle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_37_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display specific messages while the chargingState is Idle according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="16">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>messagepriority <Configured Priority message.state Idle</td></tr><tr><td colspan="2">Note(s): The display message should be displayed.</td></tr><tr><td colspan="2">3. Execute Reusable State ParkingBayOccupied</td></tr><tr><td colspan="2">4. Execute Reusable State Authorized</td></tr><tr><td colspan="2">5. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">6. Execute Reusable State EnergyTransferStarted</td></tr><tr><td colspan="2">Note(s): The display message should NOT be displayed.</td></tr><tr><td colspan="2">7. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">8. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">9. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">10. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td colspan="2">Note(s): The display message should be displayed.</td></tr><tr><td>12. The Charging Station responds with a GetDisplayMessagesResponse</td><td>11. The OCTT sends a GetDisplayMessagesRequest with id <Generated displayMessageId>requestId <Generated requestId></td></tr><tr><td>13. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>14. The OCTT responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s): If tbc is True at Step 13 then step 13 and 14 will be repeated</td></tr><tr><td>Test case name</td><td>Set Display Message - State Idle</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message SetDisplayMessageResponse
+- status Accepted
+* Step 12:
+Message GetDisplayMessagesResponse
+- status Accepted
+* Step 13:
+Message NotifyDisplayMessagesRequest
+- requestId <Generated requestId>
+- state Idle</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 417. Test Case Id: TC_O_38_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - State Unavailable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_38_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display specific messages while the chargingState is Unavailable according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="11">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest withmessage.id<Generated displayMessageId>messagepriority<Configured Prioritymessage.state Unavailable</td></tr><tr><td colspan="2">Note(s): The display message should NOT be displayed.</td></tr><tr><td colspan="2">3. Execute Reusable State Unavailable</td></tr><tr><td colspan="2">Note(s): The display message should be displayed.</td></tr><tr><td>5. The Charging Station responds with a ChangeAvailabilityResponse</td><td>4. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Operative</td></tr><tr><td>6. The Charging Station notifies the CSMS about the current state of all its connectors (and optionally also the Charging Station itself and all EVSE).</td><td>7. The OCTT responds accordingly.</td></tr><tr><td colspan="2">Note(s): The display message should NOT be displayed.</td></tr><tr><td>9. The Charging Station responds with a GetDisplayMessagesResponse</td><td>8. The OCTT sends a GetDisplayMessagesRequest withid<Generated displayMessageId>requestId<Generated requestId></td></tr><tr><td>10. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>11. The OCTT responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s): If tbc is True at Step 10 then step 10 and 11 will be repeated</td></tr><tr><td>Test case name</td><td>Set Display Message - State Unavailable</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:Message SetDisplayMessageResponse- status Accepted* Step 5:Message ChangeAvailabilityResponse-status Accepted* Step 6:Message: StatusNotificationRequest- connectorStatus AvailableMessage: NotifyEventRequest-eventData[0].trigger Delta-eventData[0].actualValue "Available"- eventData[0].component.name "ChargingStation" / EVSE / Connector-eventData[0].variable.name "AvailabilityState"* Step 9:Message GetDisplayMessagesResponse-status Accepted* Step 10:Message NotifyDisplayMessagesRequest- requestId <Generated requestId>- state Unavailable</td></tr><tr><td>Post scenario validations:- N/a</td></tr></table>
+
+Table 418. Test Case Id: TC_O_39_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - State Faulted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_39_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the Charging Station is able to display specific messages while the chargingState is Faulted according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="10">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetDisplayMessageResponse</td><td>1. The OCTT sends a SetDisplayMessageRequest with message.id <Generated displayMessageId>messagepriority <Configured Prioritymessage.state <Configured State>message.message Faulted</td></tr><tr><td colspan="2">Note(s): The display message should NOT be displayed.</td></tr><tr><td colspan="2">Manual Action: Set the Charging Station to state Faulted.</td></tr><tr><td colspan="2">Note(s): The display message should be displayed now.</td></tr><tr><td colspan="2">Manual Action: Set the Charging Station back to state Available.</td></tr><tr><td colspan="2">Note(s): The display message should NOT be displayed anymore.</td></tr><tr><td>4. The Charging Station responds with a GetDisplayMessagesResponse</td><td>3. The OCTT sends a GetDisplayMessagesRequest with id <Generated displayMessageId>requestId <Generated requestId></td></tr><tr><td>5. The Charging Station sends a NotifyDisplayMessagesRequest</td><td>6. The OCTT responds with a NotifyDisplayMessagesResponse .</td></tr><tr><td colspan="2">Note(s): If tbc is True at Step 5 then step 5 and 6 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetDisplayMessageResponse-status Accepted* Step 4:Message GetDisplayMessagesResponse-status Accepted* Step 5:Message NotifyDisplayMessagesRequest-requestId <Generated requestId>- state Faulted</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+# 2.17. P DataTransfer
+
+Table 419. Test Case Id: TC_P_01_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Data Transfer to the Charging Station - Rejected / Unknown VendorId / Unknown MessageId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_P_01_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">P01</td></tr><tr><td>Requirement(s)</td><td colspan="2">P01.FR.05, P01.FR.06</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The DataTransfer message to send information for functions that are not supported by OCPP.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the Charging Station is able to handle receiving a DataTransferRequest, even if it does not support any vendor-specific implementations.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The configured vendorId should not be implemented and the configured msgageld should be unused.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a DataTransferResponse</td><td>1. The OCTT sends a DataTransferRequest with vendorId org.openchargealliance.octt msgageld <Configured msgageld></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: DataTransferResponse
+- status must be UnknownVendorId OR UnknownMessageId OR Rejected (Rejected will also be allowed, because there are implementers that like to just reject the message when the Charging Station does not support any vendor-specific features.</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 420. Test Case Id: TC_P_03_CS
+
+<table><tr><td>Test case name</td><td colspan="2">CustomData - Receive custom data</td></tr><tr><td>Test case Id</td><td colspan="2">TC_P_03_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N/a</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">Checks if the CS is able to receive custom data.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CS is able to handle receiving custom data.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with SetVariablesResponse</td><td>1. OCTT sends SetVariablesRequest with:- variable.name = "OfflineThreshold"- component.name = "OCPPCommCtrl"- attributeValue = "200"- attributeType is Actual</td></tr><tr><td>4. The Charging Station responds with GetVariablesResponse</td><td>3. OCTT sends GetVariablesRequest with:- variable.name = "OfflineThreshold"- component.name = "OCPPCommCtrl"- attributeType is Actual</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: SetVariablesResponse-setVariableResult[0].attributeStatus Accepted* Step 4:Message: GetVariablesResponse-getVariableResult[0].attributeStatus Accepted-getVariableResult[0].attributeType Actual or omitted-getVariableResult[0].attributeValue 200</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 421. Test Case Id: TC_P_04_CS
+
+<table><tr><td>Test case name</td><td colspan="2">Able to receive customData - ChargingProfile</td></tr><tr><td>Test case Id</td><td colspan="2">TC_P_04_CS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N/a</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">Checks if the CS is able to receive custom data.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CS is able to handle receive custom data in smart charging profiles.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The Charging Station supports Smart Charging</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest with evseld<Configured evseld>chargingProfile.id<Configured chargingProfileId>chargingProfile.chargingProfilePurpose TxDefaultProfilechargingProfile(customData<CustomData>chargingProfile.chargingSchedule.duration<Configured duration>chargingProfile.chargingSchedule.chargingRateUnit<Configured chargingRateUnit>chargingProfile.chargingSchedule.chargingSchedul ePeriod.startPeriod 0chargingProfile.chargingSchedule.chargingSchedul ePeriod制约if unit is A then 6(A) else 6000(W)chargingProfile.chargingSchedule.chargingSchedul ePeriod.numberPhases<Configured numberPhases>chargingProfile.chargingSchedule.chargingSchedul ePeriod.customData<CustomData></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message SetChargingProfileResponse- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+# 2.18. Reusable states
+
+Testcases can refer to a reusable state at the before or main stage. The steps described at the reusable state will be executed and then it will return to the testcase that called the reusable state.
+
+Table 422. Reusable State: Booting
+
+<table><tr><td>State</td><td colspan="2">Booting</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that it is still booting. The connection has not been setup yet.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ResetResponse</td><td>1. The OCTT sends a ResetRequest with type Immediate</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:
+Message: ResetResponse
+- status must be Accepted</td></tr><tr><td>Post condition</td><td colspan="2">State is Booting</td></tr></table>
+
+Table 423. Reusable State: Booted
+
+<table><tr><td>State</td><td colspan="2">Booted</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will reset or power cycle the Charging Station, depending on the testcase. The charging station ends in a state where it is booted back up and is in idle mode.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Power cycle the Charging Station.OR execute step 1 and 2, depending on the testcase.</td></tr><tr><td>2. The Charging Station responds with a ResetResponsewith status Accepted</td><td>1. The OCTT sends a ResetRequest</td></tr><tr><td>3. The Charging Station sends a BootNotificationRequest</td><td>4. The OCTT responds with a BootNotificationResponsewith status Accepted</td></tr><tr><td>5. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>6. The OCTT responds accordingly.</td></tr><tr><td>7 The Charging Station sends a SecurityEventNotificationRequest</td><td>8 The OCTT responds with a SecurityEventNotificationResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:Message: ResetResponse- status Accepted* Step 5:Message: StatusNotificationRequest- connectorStatus Available- evseld not 0- connectorId not 0Message: NotifyRequest-eventData[0].trigger Delta-eventData[0].actualValue "Available"- eventData[0].component.name "Connector"- eventData[0].variable.name "AvailabilityState"* Step 7:Message: SecurityEventNotificationRequest-type must be StartupOfTheDevice OR ResetOrReboot</td></tr><tr><td>Post condition</td><td colspan="2">State is Booted</td></tr></table>
+
+Table 424. Reusable State: Reserved
+
+<table><tr><td>State</td><td colspan="2">Reserved</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that one of its EVSE becomes reserved.</td></tr><tr><td></td><td></td><td></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ReserveNowResponse</td><td>1. The OCTT sends a ReserveNowRequest with evseld is <Specified evseld (Configured evseld as a default)>idToken.idToken <Specified valid_idtoken_idtoken (Configured idToken as a default)>idToken.type <Specified valid_idtoken_type></td></tr><tr><td>3. The Charging Station notifies the CSMS about the status change of the connector.Note(s):- The OCTT expects that the Charging Station sets the availabilityState of the EVSE and corresponding connectors to Reserved.- Reporting the AvailabilityState of the EVSEComponent itself is optional.</td><td>4. The OCTT responds accordingly.</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:Message: ReserveNowResponse-status must be Accepted* Step 3:Message: StatusNotificationRequest-evseld not 0- connectorId not 0- connectorStatus must be ReservedMessage: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Reserved-eventData[0].component.name must be Connector-eventData[0].evse.id not 0-eventData[0].evseconnectorld not 0-eventData[0].variable.name must be AvailabilityState(Optional)Message: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Reserved-eventData[0].component.name must be EVSE-eventData[0].variable.name must be AvailabilityState</td></tr><tr><td>Post condition</td><td colspan="2">State is Reserved</td></tr></table>
+
+Table 425. Reusable State: Unavailable
+
+<table><tr><td>State</td><td colspan="2">Unavailable</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that the Charging Station / EVSEs / connectors are set to AvailabilityState Unavailable.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a ChangeAvailabilityResponse</td><td>1. The OCTT sends a ChangeAvailabilityRequest with operationalStatus Inoperative evse.id <Specified evseld>evseconnectorId <Specified connectorId></td></tr><tr><td>3. The Charging Station notifies the CSMS about the current state of all connectors belonging to the specified component(s).</td><td>4. The OCTT responds accordingly.</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2: Message ChangeAvailabilityResponse - status Accepted * Step 3: Message: StatusNotificationRequest - connectorStatus Unavailable - evseld <Specified evseld> - connectorId <Specified connectorId> Message: NotifyEventRequest - eventData[0].trigger Delta - eventData[0].actualValue "Unavailable" - eventData[0].component.name "ChargingStation" / EVSE / Connector - eventData[0].variable.name "AvailabilityState"</td></tr><tr><td>Post condition</td><td colspan="2">State is Reserved</td></tr></table>
+
+Table 426. Reusable State: ParkingBayOccupied
+
+<table><tr><td>State</td><td colspan="2">ParkingBayOccupied</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that the EV entered the parking bay. The execution of this State is optional. Because there may not be a parking bay occupancy sensor OR the Charging Station is being tested with a test plug or EV simulator.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action:Drive EV into parking bay.Note(s):- This State is optional (Even when TxStartPoint contains ParkingBayOccupancy).</td></tr><tr><td>1. The Charging Station sends aTransactionEventRequestNote(s):- This step needs to be executed when TxStartPoint contains ParkingBayOccupancy AND the EV entered the parking bay.</td><td>2. The OCTT responds with aTransactionEventResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1:Message: TransactionEventRequest- triggerReason must be EVDetected</td></tr><tr><td>Post condition</td><td colspan="2">State is ParkingBayOccupied</td></tr></table>
+
+Table 427. Reusable State: EVConnectedPreSession
+
+<table><tr><td>State</td><td colspan="2">EVConnectedPreSession</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that the EV and EVSE are connected.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):If State is NOT ParkingBayOccupied then execute Reusable State ParkingBayOccupied</td></tr><tr><td rowspan="4">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td>1. The Charging Station notifies the CSMS about the status change of the connector.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td>3. The Charging Station sends a TransactionRequestNote(s):- This step needs to be executed when TxStartPoint contains EVConnected OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy OR Authorized</td><td>4. The OCTT responds with a TransactionResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1:Message: StatusNotificationRequest- evseld<configured evseld>- connectorId<configured connectorId>- connectorStatus must be OccupiedMessage: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Occupied-eventData[0].component.name must be Connector-eventData[0].variable.name must be AvailabilityState- evse.id<configured evseld>- connector.id<configured connectorId>* Step 3:Message: TransactionEventRequest-eventType started if TxStartPoint is EVConnected or PowerPathClosed and State is Authorized, else updated-triggerReason must be CablePluggedIn or ChargingStateChanged or RemoteStart- transactionInfo.chargingState must be EVConnected or SuspendedEVSE or Charging if State is Authorized- evse.id<configured evseld>- connector.id<configured connectorId></td></tr><tr><td>Post condition</td><td colspan="2">State is EVConnectedPreSession</td></tr></table>
+
+Table 428. Reusable State: Authorized
+
+<table><tr><td>State</td><td colspan="2">Authorized</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that the transaction is authorized. This can be done in two ways (The default way is configurable at OCTT. This will be used when the calling testcase does not define which one to use.):A. Using local authorizationB. Using a RequestStartTransactionRequest</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):If State is NOT ParkingBayOccupied OR EVConnectedPreSession, then execute Reusable State ParkingBayOccupied</td></tr><tr><td rowspan="4">Main A(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present idToken.</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequestNote(s):- This step needs to be executed, unless (AuthEnabledis implemented with mutability ReadOnly AND thevalue is set to false) ORa start button as described at Use case C02 is used(This must be configured at the OCTT) ORthe idToken is cached.In case the idToken is used for a reservation, sendingthe AuthorizationRequest message is optional.</td><td>2. The OCTT responds with an AuthorizationResponsewith idTokenInfo.status Accepted</td></tr><tr><td>3. The Charging Station sends aTransactionEventRequestNote(s):- This step needs to be executed when TxStartPointcontains Authorized OR the transaction alreadystarted. So in the case TxStartPoint containsParkingBayOccupancy or (EVConnected, in the casethis testcase was initiated from stateEVConnectedPreSession.)</td><td>4. The OCTT responds with aTransactionEventResponseNote(s):- The first TransactionEventRequest sent afterauthorization contains the idToken field, unless aStart button was used to start the transaction. In casethere is an idToken used, theTransactionEventResponse of this request messagecontains idTokenInfowith status Accepted</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1:Message: AuthorizationRequest-idToken.idToken<Configured valid_idtoken_idtoken>- idToken.type<Configured valid_idtoken_type>* Step 3:Message: TransactionEventRequest- triggerReason must be Authorized-idToken.idToken<Configured valid_idtoken_idtoken>- idToken.type<Configured valid_idtoken_type></td></tr><tr><td rowspan="5">Main B(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aRequestStartTransactionResponse</td><td>1. The OCTT sends aRequestStartTransactionRequestwith idToken.idToken<Configuredvalid_idtoken_idtoken>idToken.type<Configured valid_idtoken_type>evseld<Configured evseld></td></tr><tr><td>3. The Charging Station sends an AuthorizationRequestNote(s):- This step needs to be executed whenAuthCtrl+AuthorizeRemoteStart is true, unless(AuthEnabled is implemented with mutabilityReadOnly AND the value is set to false) ORthe idToken is cached.In case the idToken is used for a reservation, sendingthe AuthorizationRequest message is optional.</td><td>4. The OCTT responds with an AuthorizationResponsewith idTokenInfo.status Accepted</td></tr><tr><td>5. The Charging Station sends aStatusNotificationRequest with:connectorStatus Occupied</td><td>6. The OCTT responds with aStatusNotificationResponse</td></tr><tr><td>7. The Charging Station sends aTransactionEventRequestNote(s):- This step needs to be executed when TxStartPointcontains Authorized OR the transaction alreadystarted. So in the case TxStartPoint containsParkingBayOccupancy or (EVConnected, in the casethis testcase was initiated from stateEVConnectedPreSession.)</td><td>8. The OCTT responds with aTransactionEventResponseNote(s):- The first TransactionEventRequest sent afterauthorization contains the idToken field. TheTransactionEventResponse of this request messagecontains idTokenInfowith status Accepted</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:Message: RequestStartTransactionResponse-status must be AcceptedIf the transaction has already been started, so if TxStartPoint contains ParkingBayOccupancy OR(<Configured TxStartPoint> contains EVConnected AND State pre reusable state execution wasEVConnectedPreSession) then交易Id must be<Provided transactionId in first TransactionEventRequest>* Step 3:Message: AuthorizationRequest-idToken.idToken<Configured valid_idtoken_idtoken>- idToken.type<Configured valid_idtoken_type>* Step 5:Message: TransactionEventRequest-eventType Started if TxStartPoint is Authorized or PowerPathClosed and and State isEVConnectedPreSession, else updated-triggerReason must be RemoteStart- transactionInforemoteStartId must be present.- idToken.idToken<Configured valid_idtoken_idtoken>- idToken.type<Configured valid_idtoken_type></td></tr><tr><td>Post condition</td><td colspan="2">State is Authorized</td></tr></table>
+
+Table 429. Reusable State: Authorized15118
+
+<table><tr><td>State</td><td colspan="2">Authorized15118</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that the transaction is authorized. This can be done in two ways based on the value of the Authorization Method config variable:
+A. EIM, using a valid id token
+B. PnC, plug and charge</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="3">Main
+(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Present idToken if configured authorization method is EIM</td></tr><tr><td>1. The Charging Station sends an AuthorizationRequest
+Note(s):
+-The test case should be robust enough to also handle a GetCertificateStatusRequest and then expect the AuthorizationRequest.</td><td>2. The OCTT responds with an AuthorizationResponse with idTokenInfo.status Accepted</td></tr></table>
+
+Table 430. Reusable State: EnergyTransferStarted
+
+<table><tr><td>State</td><td colspan="2">EnergyTransferStarted</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that the Charging Station is transferring energy between the EV and EVSE.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): If State is NOT Authorized then execute Reusable State Authorized If EVConnected is true, then proceed to part 2 Else proceed to part 1.</td></tr><tr><td rowspan="4">Main (Part 1) (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td>1. The Charging Station notifies the CSMS about the status change of the connector.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest Note(s): - This step needs to be executed when TxStartPoint contains EVConnected OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy OR Authorized</td><td>4. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1: Message: StatusNotificationRequest - connectorStatus must be Occupied Message: NotifyEventRequest - eventData[0].trigger must be Delta - eventData[0].actualValue must be Occupied - eventData[0].component.name must be Connector - eventData[0].variable.name must be AvailabilityState * Step 3: Message: TransactionEventRequest - triggerReason must be CablePluggedIn - transactionInfo.chargingState must be EVConnected</td></tr><tr><td rowspan="4">Main (Part 2)(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>5. The Charging Station sends aTransactionEventRequestNote(s):- This step only needs to be executed whenTxStartPoint contains DataSigned AND the transaction was not already started. So in the caseTxStartPoint also contains ParkingBayOccupancy OR EVConnected OR Authorized</td><td>6. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>7. The Charging Station sends aTransactionEventRequestNote(s):- This step only needs to be executed whenTxStartPoint contains PowerPathClosed AND the transaction was not already started. So in the caseTxStartPoint also contains ParkingBayOccupancy OR EVConnected OR Authorized OR DataSigned</td><td>8. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>9. The Charging Station sends aTransactionEventRequestNote(s):- This step needs to be executed when TxStartPoint contains EnergyTransfer OR the transaction already started. So in the case TxStartPoint contains ParkingBayOccupancy OR EVConnected OR Authorized OR DataSigned OR PowerPathClosed</td><td>10. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 5:Message: TransactionEventRequest- triggerReason must be SignedDataReceived* Step 7:Message: TransactionEventRequest-triggerReason must be ChargingStateChanged- transactionInfo.chargingState must be SuspendedEVSE* Step 9:Message: TransactionEventRequest-triggerReason must be ChargingStateChanged- transactionInfo.chargingState must be Charging</td></tr><tr><td>Post condition</td><td colspan="2">State is EnergyTransferStartedEVCconnected is true</td></tr></table>
+
+Table 431. Reusable State: EnergyTransferSuspended
+
+<table><tr><td>State</td><td colspan="2">EnergyTransferSuspended</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that it is in a state where the energy transfer is suspended by the EV.</td></tr><tr><td>Prerequisite</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): If State is NOT EnergyTransferStarted then execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="4">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Notes(s): The tool will wait for <Configured Transaction Duration> seconds</td></tr><tr><td colspan="2">Manual Action: The EV suspends the energy transfer.</td></tr><tr><td>1. The Charging Station sends a TransactionRequest Note(s): - This step needs to be executed unless the transaction was already stopped. So in the case TxStopPoint contains _EnergyTransfer</td><td>2. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1: Message: TransactionRequest - 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</td></tr><tr><td>Post condition</td><td colspan="2">State is EnergyTransferSuspended</td></tr></table>
+
+Table 432. Reusable State: StopAuthorized
+
+<table><tr><td>State</td><td colspan="2">StopAuthorized</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that it is in a state where the charging session is authorized to stop. This can be done in two ways (Configurable at OCTT):A. Using local authorizationB. Using a RequestStopTransactionRequest</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):If State is NOT EnergyTransferStarted then execute Reusable State EnergyTransferStartedNote: The OCTT will wait a number of seconds equal to the configured TransactionDuration>, before proceeding to the Main stage.</td></tr><tr><td rowspan="6">Main A(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Notes(s): The tool will wait for <Configured Transaction Duration> seconds</td></tr><tr><td colspan="2">Manual Action: Present the same idToken as used to start the transaction.</td></tr><tr><td>1. The Charging Station sends aTransactionEventRequest</td><td>2. The OCTT responds with aTransactionEventResponseWith idTokenInfo.status is Accepted</td></tr><tr><td colspan="2">Note(s): This step is optional</td></tr><tr><td>3. The Charging Station sends aTransactionEventRequest</td><td>4. The OCTT responds with aTransactionEventResponseWith idTokenInfo.status is Accepted</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1:Message: TransactionRequest- triggerReason must be StopAuthorized-idToken omit OR - idToken.idToken <Configured valid_idtoken_idtoken> AND-idToken.type <Configured valid_idtoken_type>* Step 3:Message: TransactionRequest-triggerReason must be ChargingStateChanged- transactionInfo.chargingState must be EVConnected-eventType must be Ended- transactionInfo.stoppedReason must be Local or omitted</td></tr><tr><td rowspan="3">Main B(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with aRequestStopTransactionResponse</td><td>1. The OCTT sends aRequestStopTransactionRequestwith transactionld<transactionId provided by theCharging Station in TransactionRequest></td></tr><tr><td>3. The Charging Station sends aTransactionEventRequest</td><td>4. The OCTT responds with aTransactionEventResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:Message: RequestStopTransactionResponse-status must be Accepted* Step 3:Message: TransactionRequest-triggerReason must be RemoteStop</td></tr><tr><td>State</td><td>StopAuthorized</td></tr><tr><td>Post condition</td><td>State is StopAuthorized</td></tr></table>
+
+Table 433. Reusable State: EVConnectedPostSession
+
+<table><tr><td>State</td><td colspan="2">EVConnectedPostSession</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that energy transfer has been stopped and the transaction is NOT authorized to resume energy transfer without re-authorization.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):If State is NOT StopAuthorized then execute Reusable State StopAuthorized</td></tr><tr><td rowspan="3">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends aTransactionRequestNote(s):- This step needs to be executed when the transactionhas NOT been ended already. So in the caseTxStopPoint contains Authorized ORPowerPathClosed</td><td>2. The OCTT responds with aTransactionResponse</td></tr><tr><td>3. The Charging Station sends aTransactionRequestNote(s):- This step only needs to be executed whenTxStopPoint contains DataSigned AND thetransaction has NOT been ended already. So in thecase TxStopPoint contains Authorized OREnergyTransfer OR PowerPathClosed</td><td>4. The OCTT responds with aTransactionResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1:Message: TransactionRequest- triggerReason must be ChargingStateChanged- transactionInfo.chargingState must be EVConnected* Step 3:Message: TransactionRequest- triggerReason must be SignedDataReceived</td></tr><tr><td>Post condition</td><td colspan="2">State is EVConnectedPostSession</td></tr></table>
+
+Table 434. Reusable State: EVDisconnected
+
+<table><tr><td>State</td><td colspan="2">EVDisconnected</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that the EV and EVSE are disconnected, after the charging session is authorized to stop.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):If State is NOT EVConnectedPostSession then execute Reusable State EVConnectedPostSession</td></tr><tr><td rowspan="4">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE.</td></tr><tr><td>1. The Charging Station notifies the CSMS about the status change of the connector.</td><td>2. The OCTT responds accordingly.</td></tr><tr><td>3. The Charging Station sends aTransactionEventRequestNote(s):- This step needs to be executed when the transaction has NOT been ended already. So in the caseTxStopPoint contains Authorized OR EnergyTransferOR PowerPathClosed OR DataSigned</td><td>4. The OCTT responds with aTransactionResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1:Message: StatusNotificationRequest- connectorStatus must be Available- evseld must be <configured evseld>- connectorId must be <configured connectorId>Message: NotifyEventRequest-eventData[0].trigger must be Delta-eventData[0].actualValue must be Available-eventData[0].component.name must be Connector-eventData[0].variable.name must be AvailabilityState-eventData[0].component.evse.id must be <configured evseld>- eventData[0].component.evseconnectorId must be <configured connectorId>* Step 3:Message: TransactionEventRequest-triggerReason must be EVCommunicationLost- transactionInfo.chargingState must be Idle</td></tr><tr><td>Post condition</td><td colspan="2">State is EVDisconnected</td></tr></table>
+
+Table 435. Reusable State: ParkingBayUnoccupied
+
+<table><tr><td>State</td><td colspan="2">ParkingBayUnoccupied</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that the EV left the parking bay, after a charging session has taken place.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+If State is NOT EVDisconnected then execute Reusable State EVDisconnected</td></tr><tr><td rowspan="3">Main
+(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Drive EV out of parking bay.</td></tr><tr><td>1. The Charging Station sends a TransactionRequest
+Note(s):
+- This step needs to be executed when TxStopPoint contains ParkingBayOccupancy AND the transaction has NOT been ended already. So in the case TxStopPoint contains Authorized OR EnergyTransfer OR PowerPathClosed OR DataSigned OR EVConnected.</td><td>2. The OCTT responds with a TransactionResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1:
+Message: TransactionRequest
+- triggerReason must be EVDeparted
+- If the OCTT is configured to stop transactions using a RequestStopTransactionRequest message then transactionInfo.stoppedReason must be Remote
+Else transactionInfo.stoppedReason must be Local
+-eventType must be Ended</td></tr><tr><td>Post condition</td><td colspan="2">State is ParkingBayUnoccupied</td></tr></table>
+
+Table 436. Reusable State: StartOfflineTransaction
+
+<table><tr><td>State</td><td colspan="2">StartOfflineTransaction</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will start a transaction while the Charging Station is offline.</td></tr><tr><td>Prerequisite</td><td colspan="2"></td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="6">Main
+(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Drive EV into parking bay.</td></tr><tr><td colspan="2">Manual Action: Present idToken.</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td colspan="2">2. The OCTT accepts reconnection attempt from the Charging Station.</td></tr><tr><td>Tool validations</td><td colspan="2">N/a</td></tr><tr><td>Post condition</td><td colspan="2">N/a</td></tr></table>
+
+Table 437. Reusable State: RenegotiateChargingLimits
+
+<table><tr><td>State</td><td colspan="2">RenegotiateChargingLimits</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">...</td></tr><tr><td>Prerequisite</td><td colspan="2"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="8">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Renegotiate EV Charging Limits</td></tr><tr><td>1. The Charging Station sends aNotifyEVChargingNeedsRequest withevseld <Configured evseld></td><td>2. The OCTT responds with aNotifyEVChargingNeedsResponse withstatus Accepted</td></tr><tr><td>4. The Charging Station responds with aSetChargingProfileResponse withstatus Accepted</td><td>3. The OCTT sends a SetChargingProfileRequest withchargingProfile:.chargingProfilePurpose TxProfile:.transactionld <Provided transactionId from before>chargingProfile.chargingSchedule[0].:duration 300:chargingRateUnit <Configured chargingRateUnit>Note: If <Configured chargingRateUnit> is W, then thelimit field will be multiplied by 1000:.chargingSchedulePeriod[0].startPeriod 0If <Configured chargingRateUnit> is W:.chargingSchedulePeriod[0].limit 10000else: .chargingSchedulePeriod[0].limit 10</td></tr><tr><td>5. The Charging Station sends aNotifyEVChargingScheduleRequest withevseld <Configured evseld></td><td>6. The OCTT responds with aNotifyEVChargingScheduleResponse withstatus Accepted</td></tr><tr><td colspan="2">Note: Steps 5 and 6 are optional. The Charging Station will only send a NotifyEVChargingScheduleRequestwhen the EV returns a charging profile.</td></tr><tr><td>7. The Charging Station sends aTransactionEventRequest</td><td>8. The OCTT responds with aTransactionEventResponse</td></tr><tr><td colspan="2">Note: Steps 7 and 8 are optional, but can also repeat until chargingState is Charging.</td></tr><tr><td>State</td><td>RenegotiateChargingLimits</td></tr><tr><td>Tool validations</td><td>* Step 1:
+Message: NotifyEVChargingNeedsRequest)
+- evseld <Configured evseld>
+- if chargingNeeds.requestedEnergyTransfer is DC:
+- chargingNeeds.dcChargingParameters should not be omitted
+- else:
+- chargingNeeds.acChargingParameters should not be omitted
+* Step 4:
+Message: SetChargingProfileResponse)
+- status Accepted
+* Step 5:
+Message: NotifyEVChargingScheduleRequest)
+- evseld <Configured evseld>
+* Step 7:
+Message: TransactionEventRequest
+- triggerReason must be ChargingStateChanged
+- transactionInfo.chargingState must be Charging</td></tr><tr><td>Post condition</td><td>N/a</td></tr></table>
+
+Table 438. Reusable State: GetInstalledCertificates
+
+<table><tr><td>State</td><td colspan="2">GetInstalledCertificates</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The DATA from installed certificates of the specified type will be retrieved from the Charging Station</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a GetInstalledCertificatesResponse</td><td>1. The OCTT sends a GetInstalledCertificatesRequest With certificateType is <Specified certificateType></td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:
+Message: GetInstalledCertificatesResponse
+- status must be Accepted
+- certificateDataChain must contain an entry with following values:
+Note: Order does not matter.
+- certificateDataChain[0].certificateType is <Specified certificateType>
+- certificateDataChain[0].certificateData contains <Data from the configured certificate of the specified certificateType></td></tr><tr><td>Post condition</td><td colspan="2">Certificate of the specified certificateType is retrieved from the Charging Station.</td></tr></table>
+
+Table 439. Reusable State: RebootBeforeFirmwareInstallation
+
+<table><tr><td>State</td><td colspan="2">RebootBeforeFirmwareInstallation</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station needs to reboot before firmware installation.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends a FirmwareStatusNotificationRequestWith status InstallRebooting</td><td>2. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td colspan="2">Note: The steps 3 through 8 are only executed if the bootloader is able to communicate OCPP.</td></tr><tr><td>3. The Charging Station sends a BootNotificationRequest</td><td>4. The OCTT responds with a BootNotificationResponse with status Accepted</td></tr><tr><td>5. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>6. The OCTT responds accordingly.</td></tr><tr><td>7. The Charging Station sends a FirmwareStatusNotificationRequestWith status Installing</td><td>8. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message FirmwareStatusNotificationRequest - status InstallRebooting * Step 3:Message BootNotificationRequest - reason FirmwareUpdate * Step 7:Message FirmwareStatusNotificationRequest - status Installing</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 440. Reusable State: RebootBeforeFirmwareActivation
+
+<table><tr><td>State</td><td colspan="2">RebootBeforeFirmwareActivation</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The Charging Station needs to reboot before firmware activation.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The Charging Station sends a FirmwareStatusNotificationRequest With status InstallRebooting Note(s): - This step is optional. However it is recommended to notify the CSMS before rebooting the Charging Station to activate the new firmware.</td><td>2. The OCTT responds with a FirmwareStatusNotificationResponse</td></tr><tr><td>3. The Charging Station sends a BootNotificationRequest</td><td>4. The OCTT responds with a BootNotificationResponse with status Accepted</td></tr><tr><td>5. The Charging Station notifies the CSMS about the current state of all connectors.</td><td>6. The OCTT responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message FirmwareStatusNotificationRequest - status InstallRebooting * Step 3: Message BootNotificationRequest - reason FirmwareUpdate</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+# 2.19. Memory states
+
+Table 441. Memory State: TransactionEventsInQueueEnded
+
+<table><tr><td>State</td><td colspan="2">TransactionEventsInQueueEnded</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This state will prepare the Charging Station, so that there will be TransactionEventRequests stored in its queue from an ended Transaction.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: OfflineTxForUnknownIdEnabled is true (If implemented)</td></tr><tr><td colspan="2">Memory State: IdTokenCached for <Configured valid IdToken fields> (If implemented) IdTokenLocalAuthList for <Configured valid IdToken fields> (If implemented)</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="9">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. The OCTT closes the WebSocket connection AND does not accept a reconnect.</td></tr><tr><td colspan="2">Manual Action: Drive EV into parking bay.</td></tr><tr><td colspan="2">Manual Action: Connect the EV and EVSE.</td></tr><tr><td colspan="2">Manual Action: Present idToken.</td></tr><tr><td colspan="2">Manual Action: Present the same idToken as used to start the transaction.</td></tr><tr><td colspan="2">Manual Action: Disconnect the EV and EVSE.</td></tr><tr><td colspan="2">Manual Action: Drive EV out of parking bay.</td></tr><tr><td colspan="2">2. The OCTT accepts reconnection attempt from the Charging Station.</td></tr><tr><td>Tool validations</td><td colspan="2">N/a</td></tr><tr><td>Post condition</td><td colspan="2">TransactionRequest messages are stored in the queue of the Charging Station.</td></tr></table>
+
+Table 442. Memory State: CertificateInstalled
+
+<table><tr><td>State</td><td colspan="2">CertificateInstalled</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">A pre configured certificate of the specified certificateType will be installed.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a InstallCertificateResponse</td><td>1. The OCTT sends a InstallCertificateRequestwith certificateType is <Specified certificateType> certificate is <Corresponding certificate></td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:Message: InstallCertificateResponse- status must be Accepted</td></tr><tr><td>Post condition</td><td colspan="2">Certificate of the specified certificateType is stored at the Charging Station.</td></tr></table>
+
+Table 443. Memory State: IdTokenCached
+
+<table><tr><td>State</td><td colspan="2">IdTokenCached</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">An idToken is stored in the Authorization Cache of the Charging Station.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State ParkingBayoccupied</td></tr><tr><td colspan="2">2. Execute Reusable State Authorized</td></tr><tr><td rowspan="4">Main A (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note(s): In case idToken is Accepted</td></tr><tr><td colspan="2">3. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">4. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td>Tool validations</td><td colspan="2">N/a</td></tr><tr><td rowspan="5">Main B (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note(s): In case idToken is not Accepted</td></tr><tr><td>3. The Charging Station sends a TransactionEventRequest</td><td>4. The OCTT responds with a TransactionResponse</td></tr><tr><td colspan="2">Note(s): Steps 3 and 4 are optional depending on the TxStartPoint</td></tr><tr><td colspan="2">5. Execute Reusable State ParkingBayUnoccupied</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 3: Message: TransactionEventRequest - triggerReason must be EVConnectionLost - transactionInfo.chargingState must be Idle</td></tr><tr><td>Post condition</td><td colspan="2">N/a</td></tr></table>
+
+Table 444. Memory State: IdTokenLocalAuthList
+
+<table><tr><td>State</td><td colspan="2">IdTokenLocalAuthList</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">An valid idToken is stored in the Local Authorization List of the Charging Station.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a SendLocalListResponse</td><td>1. The OCTT sends a SendLocalListRequest with updateType Full localAuthorizationList[0].idToken.idToken<Configured valid_idtoken_idtoken>localAuthorizationList[0].idToken.type<Configured valid_idtoken_type></td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2: (Message: SendLocalListResponse) status is Accepted</td></tr><tr><td>Post condition</td><td colspan="2">N/a</td></tr></table>
+
+Table 445. Memory State: SetChargingProfile
+
+<table><tr><td>State</td><td colspan="2">SetChargingProfile</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">This will store a Charging Profile at the Charging Station.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a
+SetChargingProfileResponse</td><td>1. The OCTT sends a SetChargingProfileRequest
+with chargingProfile<Provided chargingProfile></td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:
+(Message: SetChargingProfileResponse)
+status is Accepted</td></tr><tr><td>Post condition</td><td colspan="2">N/a</td></tr></table>
+
+Table 446. Memory State: RenewChargingStationCertificate
+
+<table><tr><td>State</td><td colspan="2">RenewChargingStationCertificate</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The ChargingStationCertificate is renewed using A02/A03</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequestWith requestedMessageSignChargingStationCertificate</td></tr><tr><td>3 The Charging Station sends a SignCertificateRequest</td><td>4. The OCTT responds with a SignCertificateResponseWith status Accepted</td></tr><tr><td>6. The Charging Station responds with a CertificateSignedResponse</td><td>5. The OCTT sends a CertificateSignedRequestWith certificateChain <Certificate generated from the received CSR from step 3 and signed by the provided CSMS Root certificate> certificateType ChargingStationCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: TriggerMessageResponse- status must be Accepted* Step 3:Message: SignCertificateRequest-csr must contain <An CSR that meets the following requirements:When using RSA or DSA the key must be at least 2048 bits long.and when using elliptic curve cryptography the key must be at least 224 bits long.The received CSR must be transmitted as described in RFC 2986 and then encoded in Privacy-Enhanced Mail (PEM) format.* Step 6:Message: CertificateSignedResponse-status must be Accepted</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 447. Memory State: RenewV2GChargingStationCertificate
+
+<table><tr><td>State</td><td colspan="2">RenewV2GChargingStationCertificate</td></tr><tr><td>System under test</td><td colspan="2">Charging Station</td></tr><tr><td>Description</td><td colspan="2">The V2G ChargingStationCertificate is renewed using A02/A03</td></tr><tr><td></td><td></td><td></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:ISO15118Ctrl.V2GCertificateInstallationEnabled is true if implementedISO15118Ctrl.CountryName is NL if implementedISO15118Ctrl.OrganizationName is configured vendorId if implementedOCTT will check all configured ISO15118Ctrl.Secld's using a GetBaseReportRequest</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The Charging Station responds with a TriggerMessageResponse</td><td>1. The OCTT sends a TriggerMessageRequestWith requestedMessage SignV2GCertificateEVSE EVSE (having an seccld) returned in theGetReportResponse or omitted in case none is available</td></tr><tr><td>3 The Charging Station sends a SignCertificateRequest</td><td>4. The OCTT responds with aSignCertificateResponseWith status Accepted</td></tr><tr><td>6. The Charging Station responds with a CertificateSignedResponse</td><td>5. The OCTT sends a CertificateSignedRequestWith certificateChain <Certificate generated from therereceived CSR from step 3 and signed by SubCA2 orSubCA (if SubCA2 does not exist) certificate from theprovided V2G certificate chain>certificateType V2GCertificate</td></tr><tr><td colspan="2">Note(s): Steps 1, 2, 3, 4, 5, and 6 are repeated for all returned secclds</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: TriggerMessageResponse- status must be Accepted* Step 3:Message: SignCertificateRequest-csr must contain <An CSR that meets the following requirements:The key must be at least 256 bits long.The received CSR must be transmitted as described in RFC 2986 and then encoded in Privacy-Enhanced Mail(PEM) format.>The certificate can only be an ECDSA certificate (ISO15118 cannot be used with RSA).If an seccld is found thecsr should contain the seccld in the CN.* Step 6:Message: CertificateSignedResponse-status must be Accepted</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+# 3. Test Cases Charging Station Management System
+
+# 3.1. General pre/post conditions & tool validations
+
+General conditions-validations are overruled by testcase specific conditions/validations, unless specifically stated otherwise.
+
+# General pre conditions:
+
+The following pre conditions apply to all test cases, unless explicitly mentioned otherwise.
+
+- The Configuration variable TxCtrlr.TxStartPoint is "EVConnected,Authorized"
+- The Configuration variable TxCtrl.TxStopPoint is "EVConnected"
+- The Configuration variable AuthCtrl.AuthEnabled is true
+- The Configuration variable AuthCtrl.AuthorizeRemoteStart is false
+- The Configuration variable AdditionalRootCertificateCheck is false
+- The Configuration variable AllowNewSessionsPendingFirmwareUpdate is false
+- The Configuration variable AlignedDataSendDuringIdle is false
+
+# General tool rules/validations:
+
+- The list of ChargingSchedulePeriod elements in a chargingSchedule SHALL be ordered by increasing values of ChargingSchedulePeriod.startPeriod. This means the list is in chronological order.
+- The CSMS SHALL NOT set phaseToUse in a SetChargingProfileRequest when numberPhases is other than 1.
+
+# 3.2. A Security
+
+Table 448. Test Case Id: TC_A_01_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Basic Authentication - Valid username/password combination</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A00, B01</td></tr><tr><td>Requirement(s)</td><td colspan="2">A00.FR.204, B01.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Charging Station uses Basic authentication to authenticate itself to the CSMS, when using security profile 1 or 2.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to validate the (valid) Basic authentication credentials provided by the Charging Station at the connection request.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS supports security profile 1 and/or 2</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:The CSMS must have a password configured that equals the configured BasicAuthPassword at the OCTT.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a HTTP upgrade request with an Authorization header, containing a username/password combination.Note(s):- The Authorization header is formatted as follows:AUTHORIZATION: Basic<Base64 encoded<Configured ChargingStationId><ConfiguredBasicAuthPassword>)</td><td>2. The CSMS validates the username/password combination AND upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td>3. The OCTT sends a BootNotificationRequest</td><td>4. The CSMS responds with aBootNotificationResponse</td></tr><tr><td>5. The OCTT notifies the CSMS about the current state of all connectors.</td><td>6. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 4:Message: BootNotificationResponse-status must be Accepted</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 449. Test Case Id: TC_A_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Basic Authentication -Username does not equal ChargingStationId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A00</td></tr><tr><td>Requirement(s)</td><td colspan="2">A00.FR.204</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Charging Station uses Basic authentication to authenticate itself to the CSMS, when using security profile 1 or 2.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to validate the (invalid) Basic authentication credentials provided by the Charging Station at the connection request.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS supports security profile 1 and/or 2</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a HTTP upgrade request with an Authorization header, containing a username/password combination.Note(s):- The Authorization header is formatted as follows:AUTHORIZATION: Basic<Base64 encoded<Configured ChargingStationId> +Invalid:<Configured basicAuthPassword>)</td><td>2. The CSMS validates the username/password combination AND rejects the connection upgrade request.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 450. Test Case Id: TC_A_03_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Basic Authentication - Invalid password</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_03_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A00</td></tr><tr><td>Requirement(s)</td><td colspan="2">A00.FR.204</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Charging Station uses Basic authentication to authenticate itself to the CSMS, when using security profile 1 or 2.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to validate the (invalid) Basic authentication credentials provided by the Charging Station at the connection request.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS supports security profile 1 and/or 2</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a HTTP upgrade request with an Authorization header, containing a username/password combination.Note(s):- The Authorization header is formatted as follows:AUTHORIZATION: Basic <Base64 encoded(<Configured ChargingStationId>:<randomly chosen identifierString with a sufficiently high entropy,consisting of minimum 16 and maximum 40 characters (alpha-numeric characters and the special characters allowed by identifierString)>)]</td><td>2. The CSMS validates the username/password combination AND rejects the connection upgrade request.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 451. Test Case Id: TC_A_04_CSMS
+
+<table><tr><td>Test case name</td><td>TLS - server-side certificate - Valid certificate</td></tr><tr><td>Test case Id</td><td>TC_A_04_CSMS</td></tr><tr><td>Use case Id(s)</td><td>A00</td></tr><tr><td>Requirement(s)</td><td>A00.FR.306,A00.FR.307,A00.FR.312,A00.FR.318,A00.FR.321,A00.FR.502,A00.FR.503,A00.FR.507,A00.FR.508,A00.FR.510</td></tr><tr><td>System under test</td><td>CSMS</td></tr><tr><td>Description</td><td>The CSMS uses a server-side certificate to identify itself to the Charging Station, when using security profile 2 or 3.</td></tr><tr><td>Purpose</td><td>To verify whether the CSMS is able to provide a valid server certificate and setup a secured WebSocket connection.</td></tr><tr><td>Prerequisite(s)</td><td>The CSMS supports security profile 2 and/or 3</td></tr><tr><td colspan="2"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td>Configuration State: N/a</td></tr><tr><td>Memory State: N/a</td></tr><tr><td>Reusable State(s): N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">TLS - server-side certificate - Valid certificate</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT terminates the connection and initiates a TLS handshake and sends a Client Hello to the CSMS.</td><td>2. The CSMS responds with a Server Hello With the <Configured server certificate></td></tr><tr><td>3. The OCTT performs the following actions:
+Send client certificate
+Client Key Exchange
+Certificate verify
+Change Cipher Spec
+Finished
+Note(s):
+- The client certificate is only sent when the CSMS uses security profile 3.</td><td>4. The CSMS performs the following actions:
+Change Cipher Spec
+Finished</td></tr><tr><td>5. The OCTT sends a HTTP upgrade request to the CSMS
+Note(s):
+- The HTTP request only contains a username/password combination when the CSMS uses security profile 2.</td><td>6. The CSMS upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td>7. The OCTT sends a BootNotificationRequest with reason PowerUp
+chargingStation.model <Configured model>
+chargingStation.vendorName <Configured vendorName></td><td>8. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>9. The OCTT notifies the CSMS about the current state of all connectors.
+Message: StatusNotificationRequest
+- connectorStatus Available
+Message: NotifyEventRequest
+- trigger Delta
+-actualValue "Available"
+-component.name "Connector"
+-variable.name "AvailabilityState"</td><td>10. The CSMS responds accordingly.</td></tr><tr><td>Test case name</td><td>TLS - server-side certificate - Valid certificate</td></tr><tr><td rowspan="3">Tool validations</td><td>* Step 3:
+The OCTT validates the following before finishing the TLS handshake:
+- The CSMS must use TLS version 1.2 or above
+At least the following set of cipher suites must be supported:
+TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+AND
+TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
+AND
+TLS_RSA_WITH_AES_128_GCM_SHA256
+AND
+TLS_RSA_WITH_AES_256_GCM_SHA384
+- When using RSA or DSA the key must be at least 2048 bits long.
+and when using elliptic curve cryptography the key must be at least 224 bits long.
+- The received server side certificate must be transmitted in the X.509 format encoded in Privacy-Enhanced Mail (PEM) format.
+- The certificate must include a serial number.
+- The subject field of the certificate must contain a commonName RDN which consists of the FQDN of the endpoint of the server.
+NOTE: If one of the above validations fails, the OCTT can still proceed with the next steps of the testcase (if it is able to), but the testcase will FAIL and the OCTT reports why it failed.</td></tr><tr><td>* Step 8:
+Message: BootNotificationResponse
+with status Accepted</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 452. Test Case Id: TC_A_06_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">TLS - server-side certificate - TLS version too low</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_06_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A00</td></tr><tr><td>Requirement(s)</td><td colspan="2">A00.FR.314,A00.FR.315,A00.FR.409,A00.FR.416,A00.FR.417,A00.FR.418</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS uses a server-side certificate to identify itself to the Charging Station, when using security profile 2 or 3.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to terminate the connection when it notices the used TLS version is lower than 1.2.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS supports security profile 2 and/or 3</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="6">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT terminates the connection and initiates a TLS handshake with a TLS version lower than 1.2 and sends a Client Hello to the CSMS.</td><td>2. The CSMS notices that the TLS version is lower than 1.2 and terminates the connection.</td></tr><tr><td>3. The OCTT initiates a TLS handshake with TLS version 1.2 or higher and sends a Client Hello to the CSMS.</td><td>4. The CSMS responds with a Server Hello With the <Configured server certificate></td></tr><tr><td>5. The OCTT performs the following actions: Send client certificate Client Key Exchange Certificate verify Change Cipher Spec Finished Note(s): - The client certificate is only sent when the CSMS uses security profile 3.</td><td>6. The CSMS performs the following actions: Change Cipher Spec Finished</td></tr><tr><td>7. The OCTT sends a HTTP upgrade request to the CSMS Note(s): - The HTTP request only contains a username/password combination when the CSMS uses security profile 2.</td><td>8. The CSMS upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td>9. The OCTT sends a BootNotificationRequest with reason PowerUp chargingStation.model <Configured model> chargingStation.vendorName <Configured vendorName></td><td>10. The CSMS responds with a BootNotificationResponse</td></tr><tr><td></td><td>11. The OCTT notifies the CSMS about the current state of all connectors.</td><td rowspan="8">12. The CSMS responds accordingly.</td></tr><tr><td></td><td>Message: StatusNotificationRequest</td></tr><tr><td></td><td>- connectorStatus Available</td></tr><tr><td></td><td>Message: NotifyEventRequest</td></tr><tr><td></td><td>- trigger Delta</td></tr><tr><td></td><td>-actualValue "Available"</td></tr><tr><td></td><td>-component.name "Connector"</td></tr><tr><td></td><td>-variable.name "AvailabilityState"</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 10:
+Message: BootNotificationResponse
+-status Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 453. Test Case Id: TC_A_07_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">TLS - Client-side certificate - valid certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_07_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A00</td></tr><tr><td>Requirement(s)</td><td colspan="2">A00.FR.409,A00.FR.410,A00.FR.415,A00.FR.416,A00.FR.421</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Charging Station uses a client-side certificate to identify itself to the CSMS, when using security profile 3.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to receive a client certificate provided by a Charging Station and setup a secured WebSocket connection.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS supports security profile 3</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="6">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT terminates the connection and initiates a TLS handshake and sends a Client Hello to the CSMS.</td><td>2. The CSMS responds with a Server Hello With the <Configured server certificate></td></tr><tr><td>3. The OCTT performs the following actions: Send <Configured client certificate> Client Key Exchange Certificate verify Change Cipher Spec Finished</td><td>4. The CSMS performs the following actions: Change Cipher Spec Finished</td></tr><tr><td>5. The OCTT sends a HTTP upgrade request to the CSMS</td><td>6. The CSMS upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td>7. The OCTT sends a BootNotificationRequest with reason PowerUp chargingStation.model <Configured model> chargingStation.vendorName <Configured vendorName></td><td>8. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>9. The OCTT notifies the CSMS about the current state of all connectors. Message: StatusNotificationRequest - connectorStatus Available Message: NotifyEventRequest - trigger Delta -actualValue "Available" - component.name "Connector" - variable.name "AvailabilityState"</td><td>10. The CSMS responds accordingly.</td></tr><tr><td>Test case name</td><td>TLS - Client-side certificate - valid certificate</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 3:
+The OCTT validates the following before finishing the TLS handshake:
+- The CSMS must use TLS version 1.2 or above
+At least the following set of cipher suites must be supported:
+TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+AND
+TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
+AND
+TLS_RSA_WITH_AES_128_GCM_SHA256
+AND
+TLS_RSA_WITH_AES_256_GCM_SHA384
+* Step 8:
+Message: BootNotificationResponse
+with status Accepted</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 454. Test Case Id: TC_A_08_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">TLS - Client-side certificate - Invalid certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_08_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A00</td></tr><tr><td>Requirement(s)</td><td colspan="2">A00.FR.405,A00.FR.407,A00.FR.409,A00.FR.410</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Charging Station uses a client-side certificate to identify itself to the CSMS, when using security profile 3.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to terminate the connection when the received client certificate is invalid.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The CSMS supports security profile 3
+- This testcase can be executed multiple times, using different kinds of invalid certificates:
+Unknown certificate
+expired certificate
+certificate with commonName that does not equal the serial number of the Charging Station.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="7">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT initiates a TLS handshake and sends a Client Hello to the CSMS.</td><td>2. The CSMS responds with a Server Hello With a server certificate</td></tr><tr><td>3. The OCTT performs the following actions:
+Send <Configured invalid client certificate>
+Client Key Exchange
+Certificate verify
+Change Cipher Spec
+Finished</td><td>4. The CSMS deems the client certificate invalid and terminates the connection.</td></tr><tr><td>5. The OCTT initiates a TLS handshake and sends a Client Hello to the CSMS.</td><td>6. The CSMS responds with a Server Hello With a server certificate</td></tr><tr><td>7. The OCTT performs the following actions:
+Send <Configured client certificate>
+Client Key Exchange
+Certificate verify
+Change Cipher Spec
+Finished</td><td>8. The CSMS performs the following actions:
+Change Cipher Spec
+Finished</td></tr><tr><td>9. The OCTT sends a HTTP upgrade request to the CSMS</td><td>10. The CSMS upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td>11. The OCTT sends a BootNotificationRequest with reason PowerUp
+chargingStation.model <Configured model>
+chargingStation.vendorName <Configured vendorName></td><td>12. The CSMS responds with a BootNotificationResponse</td></tr><tr><td></td><td>13. The OCTT notifies the CSMS about the current state of all connectorsMessage: StatusNotificationRequest- connectorStatus AvailableMessage: NotifyEventRequest- trigger Delta-actualValue "Available"- component.name "Connector"- variable.name "AvailabilityState"</td><td>14. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 12:Message: BootNotificationResponsewith status Accepted</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 455. Test Case Id: TC_A_09_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Password for HTTP Basic Authentication - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_09_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A01</td></tr><tr><td>Requirement(s)</td><td colspan="2">A01.FR.02, A01.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case defines how to use the BasicAuthPassword, the password used to authenticate Charging Stations in security profile 1 (Basic Authentication) and security profile 2 (TLS with Basic Authentication)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to successfully set the new BasicAuthPassword and only accepts the new credentials as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS supports security profile 1 and/or 2</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetVariablesResponse with status Accepted</td><td>1. The CSMS sends a SetVariablesRequest with:
+setVariableData[1]:
+- variable.name = "BasicAuthPassword"
+- component.name = "SecurityCtrl"
+- attributeValue = "<NewPassword>"</td></tr><tr><td></td><td>3. The OCTT sends a HTTP upgrade request with an Authorization header, containing a username/password combination (with the new BasicAuthPassword).
+Note(s):
+- The Authorization header is formatted as follows:
+AUTHORIZATION: Basic <Base64 encoded(<Configured ChargingStationId>:<NEW BasicAuthPassword>)</td><td>4. The CSMS validates the username/password combination AND upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td></td><td>5. The OCTT sends a BootNotificationRequest</td><td>6. The CSMS responds with a
+BootNotificationResponse</td></tr><tr><td></td><td>7. The OCTT notifies the CSMS about the current state of all connectors.</td><td>8. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: SetVariableRequest
+- variable.name = "BasicAuthPassword"
+- component.name = "SecurityCtrl"
+* Step 6:
+Message: BootNotificationResponse
+- status must be Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 456. Test Case Id: TC_A_10_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Password for HTTP Basic Authentication - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_10_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A01</td></tr><tr><td>Requirement(s)</td><td colspan="2">A01.FR.02, A01.FR.04, A01.FR.05</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case defines how to use the BasicAuthPassword, the password used to authenticate Charging Stations in security profile 1 (Basic Authentication) and security profile 2 (TLS with Basic Authentication)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS keeps accepting the old credentials and keeps communication when the new BasicAuthPassword is rejected as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS supports security profile 1 and/or 2</td></tr><tr><td></td><td></td><td></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetVariablesResponse with status Rejected</td><td>1. The CSMS sends a SetVariablesRequest with:
+setVariableData[1]:
+- variable.name = "BasicAuthPassword"
+- component.name = "SecurityCtrl"
+- attributeValue = "<NewPassword>"</td></tr><tr><td></td><td>3. The OCTT sends a HTTP upgrade request with an Authorization header, containing a username/password combination (with the old BasicAuthPassword).
+Note(s):
+- The Authorization header is formatted as follows:
+AUTHORIZATION: Basic <Base64 encoded(<Configured ChargingStationId>:<OLD Configured BasicAuthPassword>)</td><td>4. The CSMS validates the username/password combination AND upgrades the connection to a (secured) WebSocket connection.</td></tr><tr><td></td><td>5. The OCTT sends a BootNotificationRequest</td><td>6. The CSMS responds with a
+BootNotificationResponse</td></tr><tr><td></td><td>7. The OCTT notifies the CSMS about the current state of all connectors.</td><td>8. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: SetVariableRequest
+- variable.name = "BasicAuthPassword"
+- component.name = "SecurityCtrl"
+* Step 6:
+Message: BootNotificationResponse
+- status must be Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 457. Test Case Id: TC_A_11_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Certificate by request of CSMS - Success - Charging Station Certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_11_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A02 & F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">A02.FR.11, A02.FR.14 & F06.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to update its charging station certificate using the TriggerMessageRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to update its Charging Station Certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS supports security profile 3</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State RenewChargingStationCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 458. Test Case Id: TC_A_12_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Certificate by request of CSMS - Success - V2G Certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_12_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A02 & F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">A02.FR.11 & F06.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to update its charging station certificate using the TriggerMessageRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to update its V2G Certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS supports ISO 15118.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a TriggerMessageResponse With status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>3 The OCTT sends a SignCertificateRequest With csv Generated CSR based on: -<Configured Country> -<Configured Organization> -<Configured OrganizationalUnit> certificateType V2GCertificate</td><td>4. The CSMS responds with a SignCertificateResponse</td></tr><tr><td>6. The OCTT responds with a CertificateSignedResponse With status Accepted</td><td>5. The CSMS sends a CertificateSignedRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: TriggerMessageRequest - requestedMessage SignV2GCertificate * Step 4: Message: SignCertificateResponse - status Accepted * Step 5: Message: CertificateSignedRequest - certificateChain <Certificate generated from the received CSR from step 3 and signed by the V2G Root or SubCA certificate from the configured V2G certificate chain>NOTE: The OCTT will validate the certificate, but if the following validation fail, the testcase will NOT FAIL, because generating the certificate is probably not be done by the CSMS.- The key must be at least 224 bits long.- The received certificate must be transmitted in the X.509 format encoded in Privacy-Enhanced Mail (PEM) format.</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 459. Test Case Id: TC_A_13_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Certificate by request of CSMS - Success - Combined Certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_13_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A02</td></tr><tr><td>Requirement(s)</td><td colspan="2">A02.FR.11</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to update its charging station certificate using the TriggerMessageRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to update a its combined V2G / Charging Station Certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The CSMS supports security profile 3
+- The CSMS supports ISO 15118.</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a TriggerMessageResponse
+With status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>3 The OCTT sends a SignCertificateRequest
+With dst <Configured CSR></td><td>4. The CSMS responds with a SignCertificateResponse</td></tr><tr><td>6. The OCTT responds with a CertificateSignedResponse
+With status Accepted</td><td>5. The CSMS sends a CertificateSignedRequest</td></tr><tr><td rowspan="4">Tool validations</td><td colspan="2">* Step 1:
+Message: TriggerMessageRequest
+- requestedMessage SignCombinedCertificate
+* Step 4:
+Message: SignCertificateResponse
+- status Accepted
+* Step 5:
+Message: CertificateSignedRequest
+- certificateChain <Certificate generated from the received CSR from step 3 and signed by the V2G Root or SubCA certificate from the configured V2G certificate chain></td></tr><tr><td colspan="2">NOTE: The OCTT will validate the certificate, but if the following validation fail, the testcase will NOT FAIL, because generating the certificate is probably not be done by the CSMS.</td></tr><tr><td colspan="2">- The key must be at least 224 bits long.
+- The received certificate must be transmitted in the X.509 format encoded in Privacy-Enhanced Mail (PEM) format.
+- The certificate must include a serial number.
+- The subject field of the certificate must contain a commonName RDN which consists of the unique serial number of the Charging Station.</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 460. Test Case Id: TC_A_14_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Update Charging Station Certificate by request of CSMS - Invalid certificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_14_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to update its charging station certificate using the TriggerMessageRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station rejecting the new Charging Station certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS supports security profile 3</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a TriggerMessageResponse With status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>3 The OCTT sends a SignCertificateRequest With csv <Configured CSR> certificateType ChargingStationCertificate</td><td>4. The CSMS responds with a SignCertificateResponse</td></tr><tr><td>6. The OCTT responds with a CertificateSignedResponse With status Rejected</td><td>5. The CSMS sends a CertificateSignedRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: TriggerMessageRequest - requestedMessage SignChargingStationCertificate * Step 4: Message: SignCertificateResponse - status Accepted</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 461. Test Case Id: TC_A_19_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Upgrade Charging Station Security Profile - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_A_19_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">A05</td></tr><tr><td>Requirement(s)</td><td colspan="2">A05.FR.04, A05.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS updates the connection details on the Charging Station, to increase the security profile level.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to set a new network connection profile at one of the by the Charging Station defined configuration slots with a higher security profile than currently configured.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- Security profile must be set to 1 or 2.- If Security profile is set to 1, then a trusted certificate must be installed.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:If configured <Security profile> is 2, then RenewChargingStationCertificate</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="10">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to set a new NetworkConnectionProfile with a security profile level one higher than currently configured</td></tr><tr><td>2. The OCTT responds with aSetNetworkProfileResponseWith status Accepted</td><td>1. The CSMS sends a SetNetworkProfileRequest</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to change the NetworkConfigurationPriority to one that contains the configurationSlot of the new NetworkConnectionProfile from step 1</td></tr><tr><td>4. The OCTT responds with a SetVariablesResponsewith status Accepted</td><td>3. The CSMS sends a SetVariablesRequest</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to reboot the Charging Station</td></tr><tr><td>6. The OCTT responds with a ResetResponsewith status Accepted</td><td>5. The CSMS sends a ResetRequest</td></tr><tr><td>7. The OCTT reconnects to the CSMS with security profile is <Configured securityProfile + 1></td><td>8. The CSMS accepts the connection attempt.</td></tr><tr><td colspan="2">9. Execute Reusable State Booted</td></tr><tr><td>10. The OCTT reconnects to the CSMS with security profile is <Configured securityProfile></td><td>11. The CSMS shall not accept the connection attempt.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetNetworkProfileRequest- connectionData.messageTimeout <Configured messageTimeout>- connectionData.ocppCsmsUrl <Configured ocppCsmsUrl>- connectionData.ocpptInterface <Configured ocpptInterface>- connectionData.ocppTransport JSON- connectionData.ocppVersion OCPP20- connectionData.securityProfile <Configured securityProfile + 1>* Step 3:Message SetVariablesRequestsetVariableData:- variable.name = "NetworkConfigurationPriority"- component.name = "OCPPCommCtrl"- attributeValue = <contains configurationSlot provided at step 1></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+# 3.3. B Provisioning
+
+Table 462. Test Case Id: TC_B_01_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Cold Boot Charging Station - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B01</td></tr><tr><td>Requirement(s)</td><td colspan="2">B01.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The booting mechanism allows a Charging Station to provide some general information about the Charging Station to the CSMS on startup AND it allows the Charging Station to request whether it is allowed to start sending other OCPP messages.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to accept the communications of a registered Charging Station.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Booted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 463. Test Case Id: TC_B_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Cold Boot Charging Station - Pending</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B02</td></tr><tr><td>Requirement(s)</td><td colspan="2">B02.FR.01, B02.FR.06</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The booting mechanism allows a Charging Station to provide some general information about the Charging Station to the CSMS on startup AND it allows the Charging Station to request whether it is allowed to start sending other OCPP messages. The CSMS may respond to the BootNotificationRequest with status Pending. The Pending status can indicate that the CSMS wants to retrieve or set certain information on the Charging Station before it will accept the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to accept the communications of a registered Charging Station.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS is configured to first respond to a BootNotificationRequest with status Pending.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a BootNotificationRequest with reason PowerUpchargingStation.model<Configured model>chargingStationvendorName<ConfiguredvendorName></td><td>2. The CSMS responds with a BootNotificationResponse</td></tr><tr><td colspan="2">Note(s):- If the interval in the BootNotificationResponse equals 0, the OCTT will wait<Configured heartbeatInterval>seconds, before sending another BootNotificationRequest.- If the interval in the BootNotificationResponse > 0, the OCTT will wait<Interval provided at the BootNotificationResponse> seconds, before sending another BootNotificationRequest.- During this interval, the CSMS may send messages to retrieve information from the Charging Station (as described in use cases B06, B07, B08) or change its configuration by SetVariablesRequest (as described in use case B05). The OCTT will respond to these messages.</td></tr><tr><td>3. The OCTT sends a BootNotificationRequest with reason PowerUpchargingStation.model<Configured model>chargingStationvendorName<ConfiguredvendorName></td><td>4. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>5. The OCTT notifies the CSMS about the current state of all connectors.Message: StatusNotificationRequestwith connectorStatus AvailableMessage: NotifyEventRequestwith trigger DeltaactualValue "Available"component.name "Connector"variable.name "AvailabilityState"</td><td>6. The CSMS responds accordingly.</td></tr><tr><td>Test case name</td><td>Cold Boot Charging Station - Pending</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message: BootNotificationResponse
+- status Pending
+* Step 3:
+Message: BootNotificationResponse
+- status Accepted</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 464. Test Case Id: TC_B_30_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Cold Boot Charging Station - Pending/Rejected - SecurityError</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_30_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B02/B03</td></tr><tr><td>Requirement(s)</td><td colspan="2">B02.FR.09, B03.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The booting mechanism allows a Charging Station to provide some general information about the Charging Station to the CSMS on startup AND it allows the Charging Station to request whether it is allowed to start sending other OCPP messages. The CSMS may respond to the BootNotificationRequest with status Pending or Rejected. During this state, the Charging Station is not allowed to send RPC Framework: CALL message that is NOT a BootNotificationRequest or in case of status Pending, a message triggered by one of the following messages: TriggerMessageRequest, GetBaseReportRequest, GetReportRequest.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to handle unauthorized messages from the Charging Station by responding with a SecurityError.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS is configured to first respond to a BootNotificationRequest with status Pending or Rejected.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a BootNotificationRequest with reason PowerUpchargingStation.model<Configured model>chargingStationvendorName<Configured vendorName></td><td>2. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of all connectors.Message: StatusNotificationRequestwith connectorStatus AvailableMessage: NotifyEventRequestwith trigger DeltaactualValue "Available"component.name "Connector"variable.name "AvailabilityState"</td><td>4. The CSMS responds with RPC Framework:CALLERROR: SecurityError.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: BootNotificationResponse-status Pending OR Rejected</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 465. Test Case Id: TC_B_31_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Cold Boot Charging Station - Pending/Rejected - TriggerMessage</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_31_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B02, F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The booting mechanism allows a Charging Station to provide some general information about the Charging Station to the CSMS on startup AND it allows the Charging Station to request whether it is allowed to start sending other OCPP messages.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to send a TriggerMessageRequest to trigger a BootNotificationRequest, before the interval expired.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS is configured to first respond to a BootNotificationRequest with status Pending or Rejected.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a BootNotificationRequest with reason PowerUpchargingStation.model<Configured model>chargingStationvendorName<Configured vendorName></td><td>2. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>4. The OCTT responds with a TriggerMessageResponse with status Accepted</td><td>3. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>5. The OCTT sends a BootNotificationRequest with reason TriggeredchargingStation.model<Configured model>chargingStationvendorName<Configured vendorName></td><td>6. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>7. The OCTT notifies the CSMS about the current state of all connectors.Message: StatusNotificationRequestwith connectorStatus AvailableMessage: NotifyEventRequestwith trigger DeltaactualValue "Available"component.name "Connector"variable.name "AvailabilityState"</td><td>8. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: BootNotificationResponse- status Pending OR Rejected* Step 3:Message: TriggerMessageRequest- requestedMessage BootNotification* Step 6:Message: BootNotificationResponse- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 466. Test Case Id: TC_B_06_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Variables - single value</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_06_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B06</td></tr><tr><td>Requirement(s)</td><td colspan="2">B06.FR.01, B06.FR.02, B06.FR.03, B06.FR.04, B06.FR.10, B06.FR.11</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">Get the value of two of the required variables of OCPPCommCtrl</td></tr><tr><td>Purpose</td><td colspan="2">To test getting single value using GetVariablesRequest for one of the mandatory component/variable combinations that must exist in the DM implementation.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. OCTT responds with: GetVariablesResponse</td><td>1. Manually request CSMS to get data for: - OCPPCommCtrl.OfflineThreshold</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: GetVariablesRequest with (in arbitrary order) getVariableData[0]: - attributeType is at least absent or attributeType = Actual, but Target, MinSet, and MaxSet are also allowed - variable.name = "OfflineThreshold" - component.name = "OCPPCommCtrl"</td></tr><tr><td colspan="2">Post scenario validations: Manually validate that CSMS has correctly read the requested variables.</td></tr></table>
+
+Table 467. Test Case Id: TC_B_07_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Variables - multiple values</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_07_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B06</td></tr><tr><td>Requirement(s)</td><td colspan="2">B06.FR.01, B06.FR.02, B06.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">Get the value of two of the required variables of OCPPCommCtrlr</td></tr><tr><td>Purpose</td><td colspan="2">To test getting multiple values using GetVariablesRequest for one of the mandatory component/variable combinations that must exist in the DM implementation.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. OCTT responds with:GetVariablesResponse</td><td>1. Manually request CSMS to get data for:- OCPPCommCtrlrOfflineThreshold- AuthCtrlr授权RemoteStart</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: GetVariablesRequest with (in arbitrary order)getVariableData[0]:- attributeType is at least absent or attributeType = Actual, but Target, MinSet, and MaxSet are also allowed - variable.name = "OfflineThreshold"- component.name = "OCPPCommCtrlr"getVariableData[1]:- attributeType is at least absent or attributeType = Actual, but Target, MinSet, and MaxSet are also allowed - variable.name = "AuthorizationRemoteStart"- component.name = "AuthCtrlr"</td></tr><tr><td colspan="2">Post scenario validations:Manually validate that CSMS has correctly read the requested variables.</td></tr></table>
+
+Table 468. Test Case Id: TC_B_08_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Variables - limit to maximum number of values</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_08_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B06</td></tr><tr><td>Requirement(s)</td><td colspan="2">B06.FR.05</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">Do not request more variables than supported by MaxItemsPerMessageGetVariables.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS does not request more variables than the Charging Station reported to support in the variable MaxItemsPerMessageGetVariables.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:Configure (using getVariablesRequest) Component.VariableInstanceDeviceDataCtrl.ItemsPerMessage.GetVariables at value 4.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. OCTT responds with GetVariablesResponse with a list of 4 GetVariableResultType items and a GetVariableResponse with 1 GetVariableResultType item.</td><td>1. Manually request CSMS for 5 variables:- DeviceDataCtrl.ItemsPerMessage[ GetReport]- DeviceDataCtrl.ItemsPerMessage[ GetVariables]- DeviceDataCtrl BytesPerMessage[ GetReport]- DeviceDataCtrl BytesPerMessage[ GetVariables]- AuthCtrl.AuthorizeRemoteStart</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: GetVariablesRequest for 4 variables and a GetVariablesRequest for 1 variable (in arbitrary order):for component.name = "DeviceDataCtrl" - variable.name = "ItemsPerMessage" with variable.instance = "GetReport"- variable.name = "ItemsPerMessage" with variable.instance = "GetVariables"- variable.name = "BytesPerMessage" with variable.instance = "GetReport"- variable.name = "BytesPerMessage" with variable.instance = "GetVariables"and for component.name = "AuthCtrl"- variable.name = "AuthorizeRemoteStart"</td></tr><tr><td colspan="2">Post scenario validations:OCTT validates that not more than ItemsPerMessageGetVariables elements are requested in oneGetVariablesRequest message by CSMS.</td></tr></table>
+
+Table 469. Test Case Id: TC_B_09_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variables - single value</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_09_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B05</td></tr><tr><td>Requirement(s)</td><td colspan="2">B05.FR.01, B05.FR.02, B05.FR.03, B05.FR.10, B05.FR.12</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">Set the value of one of the required variables of OCPPCommCtrlr</td></tr><tr><td>Purpose</td><td colspan="2">To test setting a single value using SetVariablesRequest for one of the mandatory component/variable combinations that must exist in the DM implementation.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. OCTT responds with:SetVariablesResponse</td><td>1. Manually request CSMS to set data for:- OCPPCommCtrlr.OfflineThreshold</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: SetVariablesRequest with (in arbitrary order):setVariableData[1]:- variable.name = "OfflineThreshold"- component.name = "OCPPCommCtrl"- attributeValue = "123"- attributeType is absent or attributeType = Actual</td></tr><tr><td colspan="2">Post scenario validations:Manually validate that CSMS has correctly set the requested variables.</td></tr></table>
+
+Table 470. Test Case Id: TC_B_10_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variables - multiple values</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_10_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B05</td></tr><tr><td>Requirement(s)</td><td colspan="2">B05.FR.01, B05.FR.02, B05.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">Set the value of two of the required variables of OCPPCommCtrlr</td></tr><tr><td>Purpose</td><td colspan="2">To test setting multiple values using SetVariablesRequest for one of the mandatory component/variable combinations that must exist in the DM implementation.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. OCTT responds with:SetVariablesResponse</td><td>1. Manually request CSMS to set data for:- OCPPCommCtrlrOfflineThreshold- AuthCtrlr.AuthorizeRemoteStart+</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:Message: SetVariablesRequest with (in arbitrary order):setVariableData[1]:- variable.name = "OfflineThreshold"- component.name = "OCPPCommCtrlr"- attributeValue = "123"- attributeType is absent or attributeType = ActualsetVariableData[2]:- variable.name = "AuthorizeRemoteStart"- component.name = "AuthCtrlr"- attributeValue = "false"- attributeType is absent or attributeType = Actual</td><td></td></tr><tr><td colspan="2">Post scenario validations:Manually validate that CSMS has correctly set the requested variables.</td></tr></table>
+
+Table 471. Test Case Id: TC_B_12_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Base Report - ConfigurationInventory</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_12_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B07</td></tr><tr><td>Requirement(s)</td><td colspan="2">B07.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a ConfigurationInventory base report.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports the ConfigurationInventory base report.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. OCTT responds with:GetBaseReportResponse</td><td>1. Manually instruct CSMS to retrieve aConfigurationInventory report.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: GetBaseReportRequest with:- requestId has integer value >= 0-reportBase = ConfigurationInventory</td></tr><tr><td colspan="2">Post scenario validations:CSMS receives all NotifyReportRequest message for this requestId and is able to show the result ofconfiguration inventory to an operator.</td></tr></table>
+
+Table 472. Test Case Id: TC_B_13_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Base Report - FullInventory</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_13_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B07</td></tr><tr><td>Requirement(s)</td><td colspan="2">B07.FR.08</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a FullInventory base report.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports the FullInventory base report.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. OCTT responds with:GetBaseReportResponse</td><td>1. Manually instruct CSMS to retrieve a FullInventory report.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:GetBaseReportRequest with:- requestId has integer value >= 0-reportBase = FullInventory</td></tr><tr><td colspan="2">Post scenario validations:CSMS receives all NotifyReportRequest message for this requestId and is able to show the result of full inventory to an operator.</td></tr></table>
+
+Table 473. Test Case Id: TC_B_14_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Base Report - SummaryInventory</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_14_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B07</td></tr><tr><td>Requirement(s)</td><td colspan="2">B07.FR.09</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a SummaryInventory base report.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports the SummaryInventory base report.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">CSMS implementation supports the optional SummaryInventory report</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. OCTT responds with:GetBaseReportResponse</td><td>1. Manually instruct CSMS to retrieve aSummaryInventory report.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:GetBaseReportRequest with:- requestId has integer value >= 0-reportBase = SummaryInventory</td></tr><tr><td colspan="2">Post scenario validations:CSMS receives all NotifyReportRequest message for this requestId and is able to show the result ofsummary inventory to an operator.</td></tr></table>
+
+Table 474. Test Case Id: TC_B_18_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Custom Report - with componentCriteria and component/variables</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_18_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B08</td></tr><tr><td>Requirement(s)</td><td colspan="2">B08.FR.01, B08.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a report of components that match both the component criteria and the given list of components and variables.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports requesting a report for both the component criteria and a given list of components and optionally with variables and that it handles an empty result set.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. OCTT responds with:GetReportResponse withstatus EmptyResultSet</td><td>1. Manually instruct CSMS to get the value of:- EVSE #1::AvailabilityState-from all Problem components</td></tr><tr><td>4. OCTT responds with:GetReportResponse withstatus Accepted</td><td>3. Manually instruct CSMS to get the value of:- EVSE #1::AvailabilityState-from all Available components</td></tr><tr><td>5. OCTT responds with:NotifyReportRequest</td><td>6. CSMS sends NotifyReportResponse</td></tr><tr><td rowspan="3">Tool validations</td><td colspan="2">* Step 1:Message: GetReportRequest-componentCriteria = Problem-componentVariable[0].component.name = "EVSE"- componentVariable[0].component.evse.id = 1-componentVariable[0].variable.name = "AvailabilityState"</td></tr><tr><td colspan="2">* Step 3:Message: GetReportRequest-componentCriteria is Available-componentVariable[0].component.name = "EVSE"- componentVariable[0].component.evse.id = 1-componentVariable[0].variable.name = "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 475. Test Case Id: TC_B_20_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Charging Station - Without ongoing transaction - OnIdle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_20_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B11</td></tr><tr><td>Requirement(s)</td><td colspan="2">B11.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can request the Charging Station to reset itself by sending a ResetRequest without any ongoing transaction. This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to reboot the Charging Station with type _OnIdle</td></tr><tr><td>2. The OCTT responds with a ResetResponse with status Accepted</td><td>1. The CSMS sends a ResetRequest</td></tr><tr><td>3. The OCTT sends a BootNotificationRequest</td><td>4. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>5. The OCTT notifies the CSMS about the current state of all connectors. Message: StatusNotificationRequest - connectorStatus Available Message: NotifyEventRequest - trigger Delta -actualValue "Available" - component.name "Connector" - variable.name "AvailabilityState"</td><td>6. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 4: Message BootNotificationResponse - status Accepted</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 476. Test Case Id: TC_B_21_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Charging Station - With Ongoing Transaction - OnIdle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_21_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B12</td></tr><tr><td>Requirement(s)</td><td colspan="2">B12.FR.01, B12.FR.03, E07.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can remotely request the Charging Station to reset itself by sending a ResetRequest during a transaction. When ResetRequest "Onidle" is send the charging stations schedules a reboot after all transactions are stopped.
+This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="7">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to reboot the Charging Station with status OnIdle</td></tr><tr><td>2. The OCTT responds with a ResetResponse with status Scheduled</td><td>1. The CSMS sends a ResetRequest with status OnIdle</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest.
+- eventType Updated
+- triggerReason StopAuthorized
+- transactionInfo.chargingState EVConnected
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type></td><td>4. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest.
+- eventType Ended
+- triggerReason EVCommunicationLost
+- transactionInfo.chargingState Idle
+- transactionInfo.stoppedReason EVDisconnected</td><td>6. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td>7. The OCTT sends a BootNotificationRequest with reason ScheduledReset</td><td>8. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>9. The OCTT notifies the CSMS about the current state of all connectors.
+Message: StatusNotificationRequest
+- connectorStatus Available
+Message: NotifyEventRequest
+- trigger Delta
+-actualValue "Available"
+-component.name "Connector"
+-variable.name "AvailabilityState"</td><td>10. The CSMS responds accordingly.</td></tr><tr><td>Test case name</td><td>Reset Charging Station - With Ongoing Transaction - OnIdle</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message ResetRequest
+- type OnIdle
+* Step 8:
+Message BootNotificationResponse
+- status Accepted</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 477. Test Case Id: TC_B_22_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Charging Station - With Ongoing Transaction - Immediate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_22_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B12</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can remotely request the Charging Station to reset itself by sending a ResetRequest during a transaction. When ResetRequest "Immediate" is send the charging stations will try to stop all transactions before rebooting.
+This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to reboot the Charging Station with status Immediate</td></tr><tr><td>2. The OCTT responds with a ResetResponse with status Accepted</td><td>1. The CSMS sends a ResetRequest with status Immediate</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest.
+- eventType Ended
+- triggerReason ResetCommand
+- transactionInfo.chargingState EVConnected
+- transactionInfo.stoppedReason ImmediateReset
+- idToken is omitted</td><td>4. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td>5. The OCTT sends a BootNotificationRequest with reason RemoteReset</td><td>6. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>7. The OCTT notifies the CSMS about the current state of all connectors.
+For <Configured connectorId>:
+Message: StatusNotificationRequest
+- connectorStatus Occupied
+Message: NotifyEventRequest
+- trigger Delta
+-actualValue "Occupied"
+- component.name "Connector"
+- variable.name "AvailabilityState"
+For <Other connector(s)>:
+Message: StatusNotificationRequest
+- connectorStatus Available
+Message: NotifyEventRequest
+- trigger Delta
+-actualValue "Available"
+- component.name "Connector"
+- variable.name "AvailabilityState"</td><td>8. The CSMS responds accordingly.</td></tr><tr><td>Test case name</td><td>Reset Charging Station - With Ongoing Transaction - Immediate</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message ResetRequest
+- type Immediate
+* Step 6:
+Message BootNotificationResponse
+- status Accepted</td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 478. Test Case Id: TC_B_25_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset EVSE - Without ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_25_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B11</td></tr><tr><td>Requirement(s)</td><td colspan="2">B11.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can request the Charging Station to reset an EVSE by sending a ResetRequest without any ongoing transaction. This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to reboot an EVSE with status OnIdle</td></tr><tr><td>2. The OCTT responds with a ResetResponse with status Accepted</td><td>1. The CSMS sends a ResetRequest with status OnIdle and evselD <Configured evseld></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message ResetRequest - type OnIdle - evseld <Configured evseld></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 479. Test Case Id: TC_B_26_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset EVSE - With Ongoing Transaction - OnIdle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_26_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B12</td></tr><tr><td>Requirement(s)</td><td colspan="2">B12.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can remotely request the Charging Station to reset an EVSE by sending a ResetRequest during a transaction. When ResetRequest "OnIdle" is send the charging stations schedules a reboot after all transactions are stopped.
+This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="5">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to reboot the charging EVSE with status OnIdle</td></tr><tr><td>2. The OCTT responds with a ResetResponse with status Scheduled</td><td>1. The CSMS sends a ResetRequest with status OnIdle and evselD <Configured evseld></td></tr><tr><td>3. The OCTT sends a TransactionEventRequest.
+- eventType Updated
+- triggerReason StopAuthorized
+- transactionInfo.chargingState EVConnected
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type></td><td>4. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest.
+- eventType Ended
+- triggerReason EVCommunicationLost
+- transactionInfo.chargingState Idle
+- transactionInfo.stoppedReason EVDisconnected</td><td>6. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message ResetRequest
+-type OnIdle
+-evseld <Configured evseld></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 480. Test Case Id: TC_B_27_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset EVSE - With Ongoing Transaction - Immediate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_27_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B12</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS can remotely request the Charging Station to reset an EVSE by sending a ResetRequest during a transaction. When ResetRequest "Immediate" is send the charging stations will try to stop all transactions before rebooting.This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the reset mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to reboot the charging EVSE with status Immediate</td></tr><tr><td>2. The OCTT responds with a ResetResponse with status Accepted</td><td>1. The CSMS sends a ResetRequest with status Immediate and evseld<Configured evseld></td></tr><tr><td>3. The OCTT sends a TransactionEventRequest.- eventType Ended-triggerReason ResetCommand- transactionInfo.chargingState EVConnected- transactionInfo.stoppedReason ImmediateReset</td><td>4. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message ResetRequest-type Immediate- evseld<Configured evseld></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 481. Test Case Id: TC_B_42_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set new NetworkConnectionProfile - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_42_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B09</td></tr><tr><td>Requirement(s)</td><td colspan="2">B09.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS updates the connection details on the Charging Station. For instance in preparation of a migration to a new CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to set a new network connection profile at one of the by the Charging Station defined configuration slots.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aSetNetworkProfileResponseWith status Accepted</td><td>1. The CSMS sends a SetNetworkProfileRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetNetworkProfileRequest- configurationSlot is <Configured configurationSlot>connectionData.messageTimeout <Configured messageTimeout> -connectionData.ocppCsmsUrl<Configured ocppCsmsUrl> -connectionData.ocpplInterface <Configured ocplInterface> -connectionData.ocppTransport JSON -connectionData.ocppVersion OCPP20 -connectionData.securityProfile <Configured securityProfile></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 482. Test Case Id: TC_B_44_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set new NetworkConnectionProfile - Failed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_B_44_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">B09</td></tr><tr><td>Requirement(s)</td><td colspan="2">B09.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS updates the connection details on the Charging Station. For instance in preparation of a migration to a new CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station responding with status Failed, when setting a new network connection profile at one of the by the Charging Station defined configuration slots.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetNetworkProfileResponse With status Failed</td><td>1. The CSMS sends a SetNetworkProfileRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+# 3.4. C Authorization
+
+Table 483. Test Case Id: TC_C_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - Authorization Invalid/Unknown</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C01, C04, C06</td></tr><tr><td>Requirement(s)</td><td colspan="2">C01.FR.07 OR C04.FR.01 OR C06.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">When a Charging Station needs to charge an EV, it needs to authorize the EV Driver first at the CSMS before the charging can be started or stopped.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to report that an idToken is NOT valid.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest with idToken.idToken<Configured invalid_idtoken_idtoken>idToken.type<Configured invalid_idtoken_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message:AuthorizationResponse-idTokenInfo.status Invalid or Unknown</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 484. Test Case Id: TC_C_06_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - AuthorizationBlocked</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_06_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C01</td></tr><tr><td>Requirement(s)</td><td colspan="2">C01.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">When a Charging Station needs to charge an EV, it needs to authorize the EV Driver first at the CSMS before the charging can be started or stopped.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to report that an idToken is Linked.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:The IdToken configured as Linked at the OCTT, must be set as Linked at the CSMS.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest with idToken.idToken<Configured blocked_idtoken_idtoken>idToken.type<Configured blocked_idtoken_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message:AuthorizationResponse-idTokenInfo.status Linked or Invalid</td></tr><tr><td colspan="2">Post scenario validations:</td></tr></table>
+
+Table 485. Test Case Id: TC_C_07_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - Authorization Expired</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_07_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C01</td></tr><tr><td>Requirement(s)</td><td colspan="2">C01.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">When a Charging Station needs to charge an EV, it needs to authorize the EV Driver first at the CSMS before the charging can be started or stopped.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to report that an idToken is Expired.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:The IdToken configured as Expired at the OCTT, must be set as Expired at the CSMS.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest with idToken.idToken<Configured expired_idtoken_idtoken>idToken.type<Configured expired_idtoken_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message:AuthorizationResponse-idTokenInfo.status Expired or Invalid</td></tr><tr><td colspan="2">Post scenario validations:</td></tr></table>
+
+Table 486. Test Case Id: TC_C_08_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_08_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as no InvalidateRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to respond correctly when an idToken which has status "Accepted" in the charging stations cache is presented according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: State is EVConnectedPreSession</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest with - triggerReason Authorized - idToken <Valid id token configured in Authorization Cache> - eventType Updated Note(s): - TxStartPoint contains ParkingBayOccupancy</td><td>2. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message TransactionEventResponse - idTokenInfo.status Accepted</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 487. Test Case Id: TC_C_20_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization through authorization cache - Invalid</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_20_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C12</td></tr><tr><td>Requirement(s)</td><td colspan="2">C12_FR_03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken. This enables the EV Driver to Online start a transaction by using the Authorization Cache in which the Charging Station can respond faster, as no InvalidateRequest is being sent.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to respond correctly when an idToken, which has status "Invalid" in the charging stations cache but not in the CSMS, is presented according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: State is EVConnectedPreSession</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest with - triggerReason Authorized - idToken.idToken <Configured invalid_idtoken_idtoken> - idToken.type <Configured invalid_idtoken_type> - eventType Updated Note(s): - TxStartPoint contains ParkingBayOccupancy</td><td>2. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message TransactionEventResponse - idTokenInfo.status Invalid or Unknown</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 488. Test Case Id: TC_C_37_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Authorization Data in Authorization Cache - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_37_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C11</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the Charging Station autonomously stores a record of previously presented identifiers that have been successfully authorized by the CSMS in the Authorization Cache. (Successfully meaning: a response received on a message containing an IdToken)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to clear all identifiers from the Authorization Cache according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a ClearCacheResponse with status Accepted</td><td>1. The CSMS sends a ClearCacheRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">- N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 489. Test Case Id: TC_C_38_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Authorization Data in Authorization Cache - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_38_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C11</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the Charging Station autonomously stores a record of previously presented identifiers that have been successfully authorized by the CSMS in the Authorization Cache. (Successfully meaning: a response received on a message containing an IdToken)</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to clear all identifiers from the Authorization Cache according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a ClearCacheResponse with status Rejected</td><td>1. The CSMS sends a ClearCacheRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">- N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 490. Test Case Id: TC_C_39_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization by GroupId - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_39_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C09</td></tr><tr><td>Requirement(s)</td><td colspan="2">C09_FR_02, C09_FR_03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how a Charging Station can authorize an action for an EV Driver based on GroupId information. This could for example be used if 2 people regularly use the same EV: they can use their own IdToken (e.g. RFID card), and can deauthorize transactions that were started with the other idToken (with the same GroupId).</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to correctly handle the Authorization of idTokens with the same GroupId according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Two valid idTokens with the same GroupId are configured</td></tr><tr><td colspan="2">Reusable State(s):state is EVConnectedPreSession</td></tr><tr><td rowspan="8">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest with idToken.idToken<Configured valid_idtoken2_idtoken>idToken.type<Configured valid_idtoken2_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest with - triggerReason Authorized-idToken.idToken<Configured valid_idtoken_idtoken> - idToken.type<Configured valid_idtoken_type>if transaction was already started - eventType Updated else - eventType Started</td><td>4. The CSMS responds with a TransactionEventResponse</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>6. The OCTT sends an AuthorizationRequest with idToken.idToken<Configured valid_idtoken2_idtoken> idToken.type<Configured valid_idtoken2_type></td><td>7. The CSMS responds with an AuthorizationResponse</td></tr><tr><td>8. The OCTT sends a TransactionEventRequest with - triggerReason StopAuthorized-idToken.idToken<Configured valid_idtoken2_idtoken> - idToken.type<Configured valid_idtoken2_type> - eventType Updated</td><td>9. The CSMS responds with a TransactionEventResponse</td></tr><tr><td colspan="2">10. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">11. Execute Reusable State EVDisconnected</td></tr><tr><td>Test case name</td><td>Authorization by Groupld - Success</td></tr><tr><td>Tool validations</td><td>* Step 2:
+Message AuthorizationResponse
+- idTokenInfo.status Accepted
+- idTokenInfo.groupIdToken.idToken <Configured groupIdToken>
+* Step 4:
+Message TransactionEventResponse
+- idTokenInfo.status Accepted
+- idTokenInfo.groupIdToken.idToken <Configured groupIdToken>
+* Step 7:
+Message AuthorizationResponse
+- idTokenInfo.status Accepted
+- idTokenInfo.groupIdToken.idToken <Configured groupIdToken>
+* Step 9:
+Message TransactionEventResponse
+- idTokenInfo.status Accepted
+- idTokenInfo.groupIdToken.idToken <Configured groupIdToken></td></tr><tr><td></td><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 491. Test Case Id: TC_C_40_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization by Groupid - Success with Local Authorization List</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_40_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C09</td></tr><tr><td>Requirement(s)</td><td colspan="2">C09_FR_02, C09_FR_03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how a Charging Station can authorize an action for an EV Driver based on Groupld information. This could for example be used if 2 people regularly use the same EV: they can use their own IdToken (e.g. RFID card), and can deauthorize transactions that were started with the other idToken (with the same GroupId).</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to correctly handle the Authorization of idTokens with the same GroupId which are located in the Local Authorization List according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- N/a</td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+Two valid idTokens with same GroupId are configured</td></tr><tr><td colspan="2">Reusable State(s):
+state is EVConnectedPreSession</td></tr><tr><td rowspan="6">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest with
+- triggerReason Authorized
+- idToken.idToken <Configured
+valid_idtoken_idtoken> (with a configured GroupId)
+which is configured in the local Authorization List
+- idToken.type <Configured valid_idtoken_type> (with a configured GroupId) which is configured in the
+local Authorization List
+If transaction was already started
+- eventType Updated
+else
+- eventType Started</td><td>2. The CSMS responds with a
+TransactionEventResponse</td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest with
+- triggerReason StopAuthorized
+- idToken.idToken <Configured
+valid_idtoken2_idtoken> (with same configured
+GroupId) which is configured in the local
+Authorization List>
+- idToken.type <Configured valid_idtoken2_type>
+- eventType Updated</td><td>6. The CSMS responds with a
+TransactionEventResponse</td></tr><tr><td colspan="2">7. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">8. Execute Reusable State EVDisconnect</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message TransactionEventResponse
+- idTokenInfo.status Accepted
+- idTokenInfo.groupIdToken.idToken <Configured groupIdToken>
+* Step 6:
+Message TransactionEventResponse
+- idTokenInfo.status Accepted
+- idTokenInfo.groupIdToken.idToken <Configured groupIdToken></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 492. Test Case Id: TC_C_43_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization by GroupId - Invalid status with Local Authorization List</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_43_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C09</td></tr><tr><td>Requirement(s)</td><td colspan="2">C09_FR_02, C09_FR_03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how a Charging Station can authorize an action for an EV Driver based on GroupId information. This could for example be used if 2 people regularly use the same EV: they can use their own IdToken (e.g. RFID card), and can deauthorize transactions that were started with the other idToken (with the same GroupId).</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to correctly handle the Authorization of idTokens with the same GroupId which are located in the Local Authorization List according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Two known valid idTokens with same GroupId are configured.</td></tr><tr><td colspan="2">Reusable State(s):state is EVConnectedPreSession</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest with - triggerReason Authorized-idToken.idToken<Configured valid_idtoken_idtoken> - idToken.type<Configured valid_idtoken_type>if transaction was already started - eventType Updated else - eventType Started</td><td>2. The CSMS responds with a TransactionResponse</td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>4. The OCTT sends an AuthorizationRequest with - idToken.idToken<Configured valid_idtoken2_idtoken> - idToken.type<Configured valid_idtoken2_type></td><td>5. The CSMS responds with an AuthorizationResponse</td></tr><tr><td>6. The OCTT sends a TransactionEventRequest with - triggerReason StopAuthorized-idToken.idToken<Configured valid_idtoken2_idtoken> - idToken.type<Configured valid_idtoken2_type> - eventType Updated</td><td>7. The CSMS responds with a TransactionResponse</td></tr><tr><td colspan="2">8. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">9. Execute Reusable State EVDisconnected</td></tr><tr><td>Test case name</td><td>Authorization by Groupld - Invalid status with Local Authorization List</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message TransactionEventResponse
+- idTokenInfo.status Accepted
+- idTokenInfo.groupIdToken.idToken <Configured groupIdToken>
+* Step 5:
+Message ActivateResponse
+- idTokenInfo.status Accepted
+- idTokenInfo.groupIdToken.idToken <Configured groupIdToken>
+* Step 7:
+Message TransactionEventResponse
+- idTokenInfo.status Accepted
+- idTokenInfo.groupIdToken.idToken <Configured groupIdToken></td></tr><tr><td>Post scenario validations:
+- N/a</td></tr></table>
+
+Table 493. Test Case Id: TC_C_47_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop Transaction with a Master Pass - With UI - All transactions</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_47_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C16</td></tr><tr><td>Requirement(s)</td><td colspan="2">C16_FR_01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how somebody with a Master Pass (User) can stop (selected) ongoing transactions, so the cable becomes unlocked. This Master Pass can be configured in: MasterPassGroupId. This could for example be usefull for Law Enforcement officials.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to correctly respond on a request to stop all transactions when an idToken which has the MasterPass as GroupId is used and the user has selected to stop all transactions in the User Interface according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+An idToken with the MastersPass as GroupId is configured</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted for EVSE 1 with idToken valid idToken
+State is EnergyTransferStarted for EVSE 2 with idToken valid idToken2</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest with idToken.idToken <Configured
+masterpass_idtoken_idtoken>
+idToken.type <Configured masterpass_idtoken_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest with - transactionInfo.stoppedReason MasterPass
+-idToken.idToken <Configured
+masterpass_idtoken_idtoken>
+-idToken.type <Configured
+masterpass_idtoken_type>
+-eventType Ended
+for both EVSE</td><td>4. The CSMS responds with a
+TransactionEventResponse for both EVSE</td></tr></table>
+
+Table 494. Test Case Id: TC_C_48_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop Transaction with a Master Pass - With UI - With UI - Specific transactions</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_48_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C16</td></tr><tr><td>Requirement(s)</td><td colspan="2">C16_FR_01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how somebody with a Master Pass (User) can stop (selected) ongoing transactions, so the cable becomes unlocked. This Master Pass can be configured in: MasterPassGroupId. This could for example be useful for Law Enforcement officials.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to correctly respond on a request to stop a transaction when an idToken which has the MasterPass as GroupId is used and the user has selected to stop one transaction in the User Interface according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:An idToken with the MastersPass as GroupId is configured</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted for all EVSE</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest withidToken.idToken<Configured valid_idtoken_idtoken>idToken.type<Configured valid_idtoken_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest with- transactionInfo.stoppedReason MasterPass-idToken.idToken<Configuredmasterpass_idtoken_idtoken>- idToken.type<Configuredmasterpass_idtoken_type>- eventType Ended</td><td>4. The CSMS responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message AuthorizationResponse-idTokenInfo.status Accepted-idTokenInfo.groupldToken.idToken<Configured masterPassGroupId>* Step 4:Message TransactionEventResponse-idTokenInfo.status Accepted-idTokenInfo.groupldToken.idToken<Configured masterPassGroupId></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 495. Test Case Id: TC_C_49_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop Transaction with a Master Pass - Without UI</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_49_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C16</td></tr><tr><td>Requirement(s)</td><td colspan="2">C16_FR_02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how somebody with a Master Pass (User) can stop (selected) ongoing transactions, so the cable becomes unlocked. This Master Pass can be configured in: MasterPassGroupld. This could for example be usefull for Law Enforcement officials.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to correctly respond on a request to stop all transactions when an idToken which has the MasterPass as Groupld is used and the Charging Station does not have a User Interface according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+An idToken with the MastersPass as Groupld is configured</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted for EVSE 1 with idToken valid idToken
+State is EnergyTransferStarted for EVSE 2 with idToken valid idToken2</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest with idToken.idToken <Configured
+masterpass_idtoken_idtoken>
+idToken.type <Configured masterpass_idtoken_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest with - transactionInfo.stoppedReason MasterPass - idToken.idToken <Configured
+valid_idtoken_idtoken>
+-idToken.type <Configured valid_idtoken_type>
+-eventType Ended for both EVSE</td><td>4. The CSMS responds with a TransactionEventResponse for both EVSE</td></tr></table>
+
+Table 496. Test Case Id: TC_C_50_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization using Contract Certificates 15118 - Online - Local contract certificate validation - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_50_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C07</td></tr><tr><td>Requirement(s)</td><td colspan="2">C07.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is able to authorize with contract certificates when it supports ISO 15118.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to validate the certificate hash data and the provided eMAID.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The configured eMAID is known by the CSMS as valid.- The contract certificate is valid.- iso15118CertificateHashData has a responder URL that points to an OCSP service for OCTT.- CSMS does not have a cached OCSP response for the contract certificate.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EVConnectedPreSession</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequestWith idToken.idToken<Configuredvalid_idtoken_idtoken>idToken.type<Configured valid_idtoken_type>iso15118CertificateHashData contains<hashes fromconfigured (V2G) certificate chain</td><td>2. The CSMS sends an OCSP request to responderURL of iso15118CertificateHashData to checkvalidity</td></tr><tr><td>3. The OCTT OCSP service responds that certificate isvalid.</td><td>4. The CSMS responds with a AuthorizationResponse</td></tr><tr><td>5. The OCTT sends a TransactionEventRequestWith triggerReason Authorized</td><td>6. The CSMS responds with aTransactionEventResponse</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:CSMS sends an OCSP request for iso15118CertificateHashData* Step 3:OCTT checks that received request for iso15118CertificateHashData is valid* Step 4: Message: AuthorizationResponse-idTokenInfo.status Accepted-certificatessustertected* Step 4:Message: TransactionEventResponse-idTokenInfo.status Accepted</td><td></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 497. Test Case Id: TC_C_51_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization using Contract Certificates 15118 - Online - Local contract certificate validation - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_51_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C07</td></tr><tr><td>Requirement(s)</td><td colspan="2">C07.FR.16</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is able to authorize with contract certificates when it supports ISO 15118.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to validate the certificate hash data and the provided eMAID.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The configured eMAID is known by the CSMS as valid.
+- The contract certificate is revoked.
+- iso15118CertificateHashData has a responder URL that points to an OCSP service for OCTT.
+- CSMS does not have a cached OCSP response for the contract certificate.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest
+With idToken.idToken <Configured
+valid_idtoken_idtoken>
+idToken.type <Configured valid_idtoken_type>
+iso15118CertificateHashData contains <hashes from
+configured (V2G) certificate chain</td><td>2. The CSMS sends an OCSP request to responder
+URL of iso15118CertificateHashData to check
+validity</td></tr><tr><td>3. The OCTT OCSP service responds that certificate is
+valid.</td><td>4. The CSMS responds with aauthorizeResponse</td></tr></table>
+
+Table 498. Test Case Id: TC_C_52_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Authorization using Contract Certificates 15118 - Online - Central contract certificate validation - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_C_52_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">C07</td></tr><tr><td>Requirement(s)</td><td colspan="2">C07.FR.04,C07.FR.05</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is able to authorize with contract certificates when it supports ISO 15118.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to validate the provided certificate and eMAID. The field iso15118CertificateHashData is not provided to force CSMS to calculate certificate hash data for the OCSP request.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- The configured eMAID is known by the CSMS as valid.
+- The configured contract certificate is signed by the configured V2GRoot or MORoot certificate at the CSMS.
+- Contract certificate has a responder URL that points to an OCSP service for OCTT. - CSMS does not have a cached OCSP response for the contract certificate.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EVConnectedPreSession</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest With idToken.idToken <Configured valid_idtoken_idtoken>
+idToken.type <Configured valid_idtoken_type>
+iso15118CertificateHashData is absent certificate is <Configured contract_certificate></td><td>2. The CSMS sends an OCSP request to responder URL of certificate to check validity</td></tr><tr><td>3. The OCTT OCSP service responds that certificate is valid.</td><td>4. The CSMS responds with a AuthorizationResponse</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest With triggerReason Authorized</td><td>6. The CSMS responds with a TransactionEventResponse</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: CSMS sends an OCSP request for certificate
+* Step 3: OCTT checks that received request for certificate is valid
+* Step 4: Message: AuthorizationResponse
+-idTokenInfo.status Accepted
+-certificateStatus Accepted
+* Step 6: Message: TransactionEventResponse
+-idTokenInfo.status Accepted</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+# 3.5. D Local Authorization List Management
+
+Table 499. Test Case Id: TC_D_01_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Send Local Authorization List - Full</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D01</td></tr><tr><td>Requirement(s)</td><td colspan="2">D01_FR_01, D01_FR_06, D01_FR_18</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a Local Authorization List which a Charging Station can use for the authorization ofTokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a Full Local Authorization List according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2 The OCTT responds with aGetLocalListVersionResponse withversionNumber 1</td><td>1. The CSMS sends a GetLocalListVersionRequest</td></tr><tr><td colspan="2">Note(s): This step is optional</td></tr><tr><td>4 The OCTT responds with aSendLocalListResponse withstatus Accepted</td><td>3. The CSMS sends a SendLocalListRequest</td></tr><tr><td colspan="2">Note(s): If the Local Authorization List is too big for one message, step 1 and 2 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SendLocalListRequest-upupdateType Full-versionNumber <Bigger than 0>-localAuthorizationList <Not empty></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 500. Test Case Id: TC_D_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Send Local Authorization List - Differential Update</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D01</td></tr><tr><td>Requirement(s)</td><td colspan="2">D01_FR_01, D01_FR_06, D01_FR_18</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a Local Authorization List which a Charging Station can use for the authorization of idTokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a Differential Local Authorization List according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to send a Local Authorization list to the Charging Station with type Differential and some idTokens in the message</td></tr><tr><td>2 The OCTT responds with a GetLocalListVersionResponse with versionNumber 1</td><td>1. The CSMS sends a GetLocalListVersionRequest</td></tr><tr><td>4 The OCTT responds with a SendLocalListResponse with status Accepted</td><td>3. The CSMS sends a SendLocalListRequest</td></tr><tr><td colspan="2">Note(s): If the Local Authorization List is too big for one message, step 1 and 2 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message SendLocalListRequest - upgradeType Differential - versionNumber <Bigger than currently configured in OCTT> - localAuthorizationList <Not empty></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 501. Test Case Id: TC_D_03_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Send Local Authorization List - Differential Remove</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_03_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D01</td></tr><tr><td>Requirement(s)</td><td colspan="2">D01_FR_01, D01_FR_06, D01_FR_18, D01_FR_17</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a Local Authorization List which a Charging Station can use for the authorization of idTokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a Differential Local Authorization List with data without idToken according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to send a Local Authorization list to the Charging Station with type Differential and AuthorizationData elements without idTokenInfo in the message</td></tr><tr><td>2 The OCTT responds with a SendLocalListResponse with status Accepted</td><td>1. The CSMS sends a SendLocalListRequest</td></tr><tr><td colspan="2">Note(s): If the Local Authorization List is too big for one message, step 1 and 2 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SendLocalListRequest-updateType Differential-versionNumber<Bigger than currently configured in OCTT>-localAuthorizationList<AuthorizationData elements without idTokenInfo></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 502. Test Case Id: TC_D_04_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Send Local Authorization List - Full with empy list</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_04_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D01</td></tr><tr><td>Requirement(s)</td><td colspan="2">D01_FR_01, D01_FR_06, D01_FR_18</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a Local Authorization List which a Charging Station can use for the authorization ofTokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a Full Local Authorization List without data according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to send a Local Authorization list to the Charging Station with type full and without AuthorizationData elements in the message</td></tr><tr><td>2 The OCTT responds with a SendLocalListResponse withstatus Accepted</td><td>1. The CSMS sends a SendLocalListRequest</td></tr><tr><td colspan="2">Note(s): If the Local Authorization List is too big for one message, step 1 and 2 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SendLocalListRequest-updateType Full-localAuthorizationList<Empty></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 503. Test Case Id: TC_D_08_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Local List Version - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_08_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station for the version number of the Local Authorization List by sending a GetLocalListVersionRequest.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Local Authorization List version according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to get a Local Authorization list version</td></tr><tr><td>2 The OCTT responds with a GetLocalListVersionResponse with versionNumber <Configured versionNumber></td><td>1. The CSMS sends a GetLocalListVersionRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">- N/a</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 504. Test Case Id: TC_D_09_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Local List Version - No list available</td></tr><tr><td>Test case Id</td><td colspan="2">TC_D_09_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">D02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station for the version number of the Local Authorization List by sending a GetLocalListVersionRequest.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Local Authorization List version according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to get a Local Authorization list version</td></tr><tr><td>2 The OCTT responds with a GetLocalListVersionResponse with versionNumber 0</td><td>1. The CSMS sends a GetLocalListVersionRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">- N/a</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+# 3.6. E Transactions
+
+Table 505. Test Case Id: TC_E_01_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - PowerPathClosed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S5)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.05</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that starts a transaction when the power path has been closed.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest With idToken.idToken <Configured valid_idtoken_idtoken> idToken.type <Configured valid_idtoken_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td>3. The OCTT notifies the CSMS about the status change of the connector. Message: StatusNotificationRequest - connectorStatus is Occupied Message: NotifyEventRequest - trigger is Delta - actualValue is Occupied - component.name is Connector - variable.name is AvailabilityState</td><td>4. The CSMS responds accordingly.</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest With eventType is Started triggerReason is ChargingStateChanged idToken.idToken <Configured valid_idtoken_idtoken> idToken.type <Configured valid_idtoken_type> evse.id is <Configured evseld> evseconnectorId is <Configured connectorId> transactionInfo.chargingState is SuspendedEVSE</td><td>6. The CSMS responds with a TransactionEventResponse</td></tr><tr><td>7. The OCTT sends a TransactionEventRequest With eventType is Updated triggerReason is ChargingStateChanged transactionInfo.chargingState is Charging</td><td>8. The CSMS responds with a TransactionEventResponse</td></tr><tr><td>Test case name</td><td>Start transaction options - PowerPathClosed</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message:authorizeResponse
+- idTokenInfo.status must be Accepted
+* Step 6:
+Message:TransactionEventResponse
+- idTokenInfo.status must be Accepted</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 506. Test Case Id: TC_E_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - EnergyTransfer</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S6)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.06</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that starts a transaction when the energy transfer starts.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest With idToken.idToken <Configured valid_idtoken_idtoken> idToken.type <Configured valid_idtoken_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td>3. The OCTT notifies the CSMS about the status change of the connector. Message: StatusNotificationRequest - connectorStatus is Occupied Message: NotifyEventRequest - trigger is Delta - actualValue is Occupied - component.name is Connector - variable.name is AvailabilityState</td><td>4. The CSMS responds accordingly.</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest With/eventType is Started triggerReason is ChargingStateChanged idToken.idToken <Configured valid_idtoken_idtoken> idToken.type <Configured valid_idtoken_type> evse.id is <Configured evseld> evseconnectorId is <Configured connectorId> transactionInfo.chargingState is Charging</td><td>6. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: AuthorizationResponse - idTokenInfo.status must be Accepted * Step 6: Message: TransactionEventResponse - idTokenInfo.status must be Accepted</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 507. Test Case Id: TC_E_03_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - Cable plugin first - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_03_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E02</td></tr><tr><td>Requirement(s)</td><td colspan="2">E02.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first connect the EV and EVSE OR present a form of identification. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that is able to start a charging session when the EV driver first connects the EV and EVSE, before authorization.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EVConnectedPreSession</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized</td></tr><tr><td colspan="2">2. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 508. Test Case Id: TC_E_04_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - Authorization first - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_04_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E03</td></tr><tr><td>Requirement(s)</td><td colspan="2">E03.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first connect the EV and EVSE OR present a form of identification. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that is able to start a charging session when the EV driver first presents a form of identification, before connecting the EV and EVSE.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized</td></tr><tr><td colspan="2">2. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 509. Test Case Id: TC_E_39_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - Deauthorized - timeout</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_39_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E03, E06</td></tr><tr><td>Requirement(s)</td><td colspan="2">E03.FR.04, E03.FR.05, E06.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first connect the EV and EVSE OR present a form of identification. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that deauthorizeizes the transaction after the EVConnectionTimeout has expired.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is Authorized</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest With triggerReason is EVConnectTimeout transactionInfo.stoppedReason is Timeout eventType is Ended Note(s): - This step will be executed after the _<Configured EV connection timeout> expires...</td><td>2. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 510. Test Case Id: TC_E_14_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - EVDisconnected - Charging Station side</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_14_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S2)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that stops a transaction when the EV and EVSE are disconnected at the Charging Station side.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EVConnectedPostSession</td></tr><tr><td rowspan="2">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVDisconnected</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 511. Test Case Id: TC_E_20_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - EVDisconnected - EV side (able to charge IEC 61851-1 EV)</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_20_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S2), E10</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that stops a transaction when the EV and EVSE are disconnected at the EV side.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferSuspended</td></tr><tr><td rowspan="2">Main
+(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVDisconnected</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 512. Test Case Id: TC_E_15_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - StopAuthorized - Local</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_15_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S3)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that stops a transaction when the EV driver locally stops the transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest With triggerReason is StopAuthorized transactionInfo.stoppedReason is Local eventType is Ended</td><td>2. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 513. Test Case Id: TC_E_21_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - StopAuthorized - Remote</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_21_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S3) AND F03</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.03,F03.FR.01,F03.FR.09, F03.FR.10</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that stops a transaction when it receives a RequestStopTransactionRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to request the Charging Station to stop the ongoing transaction.</td></tr><tr><td>2. The OCTT responds with aRequestStopTransactionResponsewith status Accepted</td><td>1. The CSMS sends aRequestStopTransactionRequest</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest.with triggerReason is RemoteStoptransactionInfo.stoppedReason is RemoteeventType is Ended</td><td>4. The CSMS responds with aTransactionEventResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: RequestStopTransactionRequest- transactionId must equal <transactionId provided by the OCTT in before state.></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 514. Test Case Id: TC_E_09_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - EVConnected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_09_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S2)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that starts a transaction when the EV and EVSE are connected.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT notifies the CSMS about the status change of the connector.Message: StatusNotificationRequest- connectorStatus is OccupiedMessage: NotifyEventRequest- trigger is Delta- actualValue is Occupied- component.name is Connector- variable.name is AvailabilityState</td><td>2. The CSMS responds accordingly.</td></tr><tr><td>3. The OCTT sends a TransactionEventRequestWith/eventType is StartedtriggerReason is CablePluggedInevse.id is <Configured evseld>evseconnectorId is <Configured connectorId>transactionInfo.chargingState is EVConnected</td><td>4. The CSMS responds with a TransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 515. Test Case Id: TC_E_10_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - Authorized - Local</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_10_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S3)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that starts a transaction when the EV and EVSE are connected.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequestWith idToken.idToken <Configuredvalid_idtoken_idtoken>idToken.type <Configured valid_idtoken_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td>3. The OCTT sends a TransactionEventRequestWith eventType is StartedtriggerReason is AuthorizedidToken.idToken <Configured valid_idtoken_idtoken>idToken.type <Configured valid_idtoken_type></td><td>4. The CSMS responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: AuthorizationResponse-idTokenInfo.status must be Accepted* Step 4:Message: TransactionEventResponse-idTokenInfo.status must be Accepted</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 516. Test Case Id: TC_E_11_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - DataSigned</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_11_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S4)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that starts a transaction when the signed meter values are received.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest With idToken.idToken <Configured valid_idtoken_idtoken> idToken.type <Configured valid_idtoken_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td>3. The OCTT notifies the CSMS about the status change of the connector. Message: StatusNotificationRequest - connectorStatus is Occupied Message: NotifyEventRequest - trigger is Delta - actualValue is Occupied - component.name is Connector - variable.name is AvailabilityState</td><td>4. The CSMS responds accordingly.</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest With/eventType is Started triggerReason is SignedDataReceived idToken.idToken <Configured valid_idtoken_idtoken> idToken.type <Configured valid_idtoken_type> evse.id is <Configured evseld> evseconnectorId is <Configured connectorId> meterValue is provided with the following values: sampledValue.value is 0.0 sampledValue.context is Transaction.Begin sampledValue-signedMeterValue is <Generated SignedMeterValueType></td><td>6. The CSMS responds with a TransactionEventResponse</td></tr><tr><td>7. The OCTT sends a TransactionEventRequest With eventType is Updated triggerReason is ChargingStateChanged transactionInfo.chargingState is Charging</td><td>8. The CSMS responds with a TransactionEventResponse</td></tr><tr><td>Test case name</td><td>Start transaction options - DataSigned</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+Message:authorizeResponse
+- idTokenInfo.status must be Accepted
+* Step 6:
+Message:TransactionEventResponse
+- idTokenInfo.status must be Accepted</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 517. Test Case Id: TC_E_12_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Start transaction options - ParkingBayOccupied</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_12_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01(S1)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that starts a transaction when the EV and EVSE are connected.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest With eventType is Started triggerReason is EVDetected</td><td>2. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 518. Test Case Id: TC_E_38_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Local start transaction - EV not ready</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_38_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first connect the EV and EVSE OR present a form of identification. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that reports an EV is not ready to start the energy transfer (yet).</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is Authorized</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVConnectedPreSession</td></tr><tr><td>2. The OCTT sends a TransactionEventRequest With triggerReason is ChargingStateChanged transactionInfo.chargingState is SuspendedEV eventType is Updated</td><td>3. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 519. Test Case Id: TC_E_07_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - PowerPathClosed - Local stop</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_07_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S5)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.06</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that stops a transaction when it is locally stopped by an EV driver.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest With triggerReason is StopAuthorized transactionInfo.stoppedReason is Local eventType is Ended</td><td>2. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 520. Test Case Id: TC_E_08_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - EnergyTransfer stopped - StopAuthorized</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_08_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S6)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that stops a transaction when the energy transfer stopped normally.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is StopAuthorized</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest With triggerReason is ChargingStateChanged transactionInfo.chargingState is EVConnected transactionInfo.stoppedReason is Local eventType is Ended</td><td>2. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 521. Test Case Id: TC_E_16_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - Deauthorized - Invalid idToken</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_16_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S3)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.04,E01.FR.11,E01.FR.12</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that stops a transaction when the transaction gets deauthorized by the status from the idTokenInfo at a TransactionResponse message and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionRequest With triggerReason is Authorized idToken.idToken <Configured invalid_idtoken_idtoken> idToken.type <Configured invalid_idtoken_type> eventType is Started</td><td>2. The CSMS responds with a TransactionResponse</td></tr><tr><td>3. The OCTT sends a TransactionRequest With eventType Ended triggerReason Deauthorized transactionInfo.stoppedReason DeAuthorized</td><td>4. The CSMS responds with a TransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: TransactionResponse - idTokenInfo.status must be Invalid or Unknown+</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 522. Test Case Id: TC_E_17_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - Deauthorized - EV side disconnect</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_17_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S3)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the start options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that stops a transaction when the transaction gets deauthorized by a connection loss from the EV side and it has been configured to do so.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferSuspended</td></tr><tr><td rowspan="2">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest triggerReason must be EVCommunicationLost transactionInfo.chargingState must be Idle transactionInfo.stoppedReason must be EVDisconnected eventType must be Ended</td><td>2. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 523. Test Case Id: TC_E_22_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - EnergyTransfer stopped - SuspendedEV</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_22_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S6)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that stops a transaction when the energy transfer stopped by the EV.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest With triggerReason is ChargingStateChanged transactionInfo.chargingState is SuspendedEV transactionInfo.stoppedReason is StoppedByEV eventType is Ended</td><td>2. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 524. Test Case Id: TC_E_19_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Stop transaction options - ParkingBayUnoccupied</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_19_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E06(S1)</td></tr><tr><td>Requirement(s)</td><td colspan="2">E06.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x has a flexible transaction mechanism that allows the transaction start and stop points to be configured differently. This test covers one of the stop options.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that stops a transaction when the EV left the parking bay.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EVDisconnected</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest With triggerReason is EVDeparted transactionInfo.stoppedReason is Local eventType is Ended</td><td>2. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 525. Test Case Id: TC_E_26_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Disconnect cable on EV-side - Suspend transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_26_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E10</td></tr><tr><td>Requirement(s)</td><td colspan="2">E10.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Charging Station can behave in several different ways when the cable is disconnected at the EV side, based on its configuration. This test case tests one of the possible configuration settings.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS can handle a Charging Station that suspends the transaction when the EV and EVSE are disconnected at the EV side AND is able restart the energy transfer after reconnecting the EV and EVSE.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferSuspended</td></tr><tr><td rowspan="5">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequestWith triggerReason is EVCommunicationLosttransactionInfo.chargingState is IdleeventType is Updated</td><td>2. The CSMS responds with aTransactionEventResponse</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of the connector.Message: StatusNotificationRequest- connectorStatus Available- evseld <Configured evseld> - connectorId <Configured connectorId>Message: NotifyEventRequest- trigger Delta-actualValue "Available"- component.name "Connector"- component.evse.id <Configured evseld>- component.evseconnectorid <ConfiguredconnectorId>- variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td>5. The OCTT sends a TransactionEventRequestWith triggerReason is CablePluggedIntransactionInfo.chargingState is EVConnectedeventType is Updated</td><td>6. The CSMS responds with aTransactionEventResponse</td></tr><tr><td>7. The OCTT sends a TransactionEventRequestWith triggerReason is ChargingStateChangedtransactionInfo.chargingState is ChargingeventType is Updated</td><td>8. The CSMS responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 526. Test Case Id: TC_E_29_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Check Transaction status - Transaction with id ongoing - with message in queue</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_29_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E14</td></tr><tr><td>Requirement(s)</td><td colspan="2">E14.FR.02,E14.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the status of a transaction and to find out whether there are queued transaction-related messages, using the GetTransactionStatusRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the status of queued TransactionEventRequest messages from a specific transaction by sending a GetTransactionStatusRequest with a transactionId. The OCTT will respond that there are message(s) queued belonging to the ongoing transaction with the requested id.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT closes the WebSocket connection.</td><td></td></tr><tr><td>2. The OCTT waits a number of seconds equal to _<Configured Transaction Duration>, then it will reconnect to the CSMS._</td><td></td></tr><tr><td>4. The OCTT responds with a GetTransactionStatusResponse With ongoingIndicator is true messagesInQueue is true</td><td>3. The CSMS sends a GetTransactionStatusRequest</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest With eventType is Updated meterValues is present. offline is true</td><td>6. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3: Message: GetTransactionStatusRequest - transactionId <Generated transactionId from Before></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 527. Test Case Id: TC_E_30_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Check Transaction status - Transaction with id ongoing - without message in queue</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_30_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E14</td></tr><tr><td>Requirement(s)</td><td colspan="2">E14.FR.02,E14.FR.05</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the status of a transaction and to find out whether there are queued transaction-related messages, using the GetTransactionStatusRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the status of queued TransactionEventRequest messages from a specific transaction by sending a GetTransactionStatusRequest with a transactionId. The OCTT will respond that there is NO message queued belonging to the ongoing transaction with the requested id.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a GetTransactionStatusResponse With ongoingIndicator is true messagesInQueue is false</td><td>1. The CSMS sends a GetTransactionStatusRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: GetTransactionStatusRequest - transactionId must be <Generated transactionId from Before></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 528. Test Case Id: TC_E_31_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Check Transaction status - Transaction with id ended - with message in queue</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_31_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E14</td></tr><tr><td>Requirement(s)</td><td colspan="2">E14.FR.03,E14.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the status of a transaction and to find out whether there are queued transaction-related messages, using the GetTransactionStatusRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the status of queued TransactionRequest messages from a specific transaction by sending a GetTransactionStatusRequest with a transactionId. The OCTT will respond that there are message(s) queued belonging to an ended transaction with the requested id.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="7">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT closes the WebSocket connection.</td><td></td></tr><tr><td>2. The OCTT waits a number of seconds equal to _<Configured Transaction duration>, then it will reconnect to the CSMS._</td><td></td></tr><tr><td>3. The OCTT sends a StatusNotificationRequest With evseld is <Configured evseld> connectorId is <Configured connectorId> connectorStatus is Available</td><td>4. The CSMS responds with a StatusNotificationResponse</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest With eventType is Ended offline is true triggerReason is EVCommunicationLost transactionInfo.chargingState is Idle seqNo <Skipping two sequence number values></td><td>6. The CSMS responds with a TransactionEventResponse</td></tr><tr><td>8. The OCTT responds with a GetTransactionStatusResponse With ongoingIndicator is false messagesInQueue is true</td><td>7. The CSMS sends a GetTransactionStatusRequest</td></tr><tr><td>9. The OCTT sends a TransactionRequest With triggerReason is StopAuthorized eventType is Updated offline is true seqNo <This is the first of the two skipped values></td><td>10. The CSMS responds with a TransactionEventResponse</td></tr><tr><td>11. The OCTT sends a TransactionEventRequestWith triggerReason is ChargingStateChanged transactionInfo.chargingState is EVConnected eventType is Updated offline is true seqNo <This is the second of the two skipped values></td><td>12. The CSMS responds with a TransactionResponse</td><td rowspan="2">Tool validations</td></tr><tr><td colspan="2">* Step 5: Message: GetTransactionStatusRequest - transactionId <Generated transactionId from Before></td></tr></table>
+
+Table 529. Test Case Id: TC_E_33_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Check Transaction status - Without transactionId - with message in queue</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_33_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E14</td></tr><tr><td>Requirement(s)</td><td colspan="2">E14.FR.06,E14.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the status of a transaction and to find out whether there are queued transaction-related messages, using the GetTransactionStatusRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the status of queued TransactionEventRequest messages by sending a GetTransactionStatusRequest without a transactionId. The OCTT will respond that there are message(s) queued.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT closes the WebSocket connection.</td><td></td></tr><tr><td>2. The OCTT waits a number of seconds equal to _<Configured Transaction Duration>, then it will reconnect to the CSMS._</td><td></td></tr><tr><td>4. The OCTT responds with a GetTransactionStatusResponse With ongoingIndicator is omitted messagesInQueue is true</td><td>3. The CSMS sends a GetTransactionStatusRequest</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest With eventType is Updated meterValues is present offline is true</td><td>6. The CSMS responds with a TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3: Message: GetTransactionStatusRequest - transactionId must be omitted.</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 530. Test Case Id: TC_E_34_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Check Transaction status - Without transactionId - without message in queue</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_34_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E14</td></tr><tr><td>Requirement(s)</td><td colspan="2">E14.FR.06,E14.FR.08</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the status of a transaction and to find out whether there are queued transaction-related messages, using the GetTransactionStatusRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the status of queued TransactionEventRequest messages by sending a GetTransactionStatusRequest without a transactionId. The OCTT will respond that there are NO message(s) queued.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a GetTransactionStatusResponse With ongoingIndicator is omitted. messagesInQueue is false</td><td>1. The CSMS sends a GetTransactionStatusRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: GetTransactionStatusRequest - transactionId must be omitted.</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 531. Test Case Id: TC_E_53_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset Sequence Number - CSMS accepting seqNo = 0 at start of transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_E_53_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">E01</td></tr><tr><td>Requirement(s)</td><td colspan="2">E01.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.0.1 Edition 2 recommends that seqNo starts at 0 for every transaction. CSMS must therefore be robust to a seqNo that is not continuously increasing, but that restarts for new transactions. Since a TransactionEventRequest cannot be rejected, this can only be detected by either the complete absence of a TransactionEventResponse from CSMS or an otherwise misbehaving CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS accepts that a new transactions starts with a seqNo = 0.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EnergyTransferStarted Note(s): New transaction will use seqNo 0 for the first TransactionEventRequest.</td></tr><tr><td colspan="2">2. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted Note(s): New transaction will use seqNo 0 for the first TransactionEventRequest.</td></tr><tr><td colspan="2">4. Execute Reusable State EVDisconnected</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: CSMS accepts the message TransactionEventRequest with eventType = Started and seqNo = 0 and answers with a TransactionEventResponse message.</td></tr><tr><td colspan="2">* Step 3: CSMS accepts the message TransactionEventRequest with eventType = Started and seqNo = 0 and answers with a TransactionEventResponse message.</td></tr></table>
+
+# 3.7. F Remote Control
+
+Table 532. Test Case Id: TC_F_01_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote start transaction - Cable plugin first</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first connect the EV and EVSE OR wait for/trigger a RequestStartTransactionRequest. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that is starts a charging session when the EV driver first connects the EV and EVSE, before receiving a RequestStartTransactionRequest message.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EVConnectedPreSession</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to request the Charging Station to start a transaction.</td></tr><tr><td>2. The OCTT responds with a RequestStartTransactionResponse with status Accepted transactionId is <Generated transactionId></td><td>1. The CSMS sends a RequestStartTransactionRequest</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest. with triggerReason is RemoteStart transactionInforemoteStartId is <By CSMS provided remoteStartID> eventType is Updated</td><td>4. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted (State is Authorized and _EVConnected = true)</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: RequestStartTransactionRequest - idToken.idToken <Configured valid_idtoken_idtoken> - idToken.type <Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 533. Test Case Id: TC_F_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote start transaction - Remote start first -authorizeRemoteStart is true</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F02</td></tr><tr><td>Requirement(s)</td><td colspan="2">F02.FR.01, F01.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first wait for/trigger a RequestStartTransactionRequest OR connect the EV and EVSE. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that starts a charging session when the Charging Stations receives a RequestStartTransactionRequest message (while AuthorizationRemoteStart is true), before the EV driver connects the EV and EVSE (within the connectionTimeout). The Charging Station has to authorize beforehand like a local action to start a transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">AuthEnabled is NOT implemented with mutability ReadOnly and the value set to false</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to request the Charging Station to start a transaction.</td></tr><tr><td>2. The OCTT responds with aRequestStartTransactionResponsewith status AcceptedtransactionId is omitted.</td><td>1. The CSMS sends aRequestStartTransactionRequest</td></tr><tr><td>3. The OCTT sends a AuthorizationRequest.with idToken.idToken<Configuredvalid_idtoken_idtoken>idToken.type<Configured valid_idtoken_type></td><td>4. The CSMS responds with a AuthorizationResponse.</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest.with triggerReason is RemoteStarttransactionInforemoteStartId is <By OCTT generatedremoteStartID>eventType is Started</td><td>6. The CSMS responds with aTransactionEventResponse.</td></tr><tr><td colspan="2">7. Execute Reusable State EnergyTransferStarted (State is Authorized and _EVConnected = false)</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: RequestStartTransactionRequest-idToken.idToken<Configured valid_idtoken_idtoken>-idToken.type<Configured valid_idtoken_type>*Step 4:Message:authorizeResponse-idTokenInfo.status must be Accepted</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 534. Test Case Id: TC_F_03_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote start transaction - Remote start first -authorizeRemoteStart is false</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_03_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F02</td></tr><tr><td>Requirement(s)</td><td colspan="2">F02.FR.01, F01.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first wait for/trigger a RequestStartTransactionRequest OR connect the EV and EVSE. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that starts a charging session when the Charging Stations receives a RequestStartTransactionRequest message (while AuthorizationRemoteStart is false), before the EV driver connects the EV and EVSE (within the connectionTimeout). The Charging station does NOT have to authorize beforehand like a local action to start a transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="5">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to request the Charging Station to start a transaction.</td></tr><tr><td>2. The OCTT responds with a
+RequestStartTransactionResponse
+with status Accepted
+transactionId is omitted.</td><td>1. The CSMS sends a
+RequestStartTransactionRequest</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest.
+with triggerReason is RemoteStart
+transactionInforemoteStartId is <By OCTT generated
+remoteStartID>
+eventType is Started</td><td>4. The CSMS responds with a
+TransactionEventResponse.</td></tr><tr><td colspan="2">5. Execute Reusable State EnergyTransferStarted (State is Authorized andEVConnected = false)</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: RequestStartTransactionRequest
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 535. Test Case Id: TC_F_04_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote start transaction - Remote start first - Cable plugin timeout</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_04_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F02, E03</td></tr><tr><td>Requirement(s)</td><td colspan="2">E03.FR.04, E03.FR.05</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">OCPP 2.x.x allows an EV driver to either first wait for/trigger a RequestStartTransactionRequest OR connect the EV and EVSE. Both sequences will result in being able to charge.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that deauthorized the transaction after the EVConnectionTimeout has been reached.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to request the Charging Station to start a transaction.</td></tr><tr><td>2. The OCTT responds with a RequestStartTransactionResponse with status Accepted transactionId is omitted.</td><td>1. The CSMS sends a RequestStartTransactionRequest</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest. with triggerReason is RemoteStart transactionInforemoteStartId is <By OCTT generated remoteStartID> eventType is Started</td><td>4. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest. with triggerReason is EVConnectTimeout eventType is Updated Note(s): - This step will be executed after the_<Configured Transaction Duration> has been reached_.</td><td>6. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: RequestStartTransactionRequest - idToken.idToken<Configured valid_idtoken_idtoken> - idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 536. Test Case Id: TC_F_06_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote unlock Connector - Without ongoing transaction - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_06_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F05</td></tr><tr><td>Requirement(s)</td><td colspan="2">n/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an UnlockConnectorRequest to the charging station. It sometimes happens that a connector of a Charging Station socket does not unlock correctly. This happens most of the time when there is tension on the charging cable. This means the driver cannot unplug his charging cable from the Charging Station. To help a driver, the CSO can send a UnlockConnectorRequest to the Charging Station. The Charging Station will then try to unlock the connector again.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the remote unlock connector mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2"></td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a UnlockConnectorResponse with status Unlocked</td><td>1. The CSMS sends a UnlockConnectorRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message UnlockConnectorRequest
+- evseld <Configured evseld>
+- connectorld <Configured connectorld></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 537. Test Case Id: TC_F_11_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - MeterValues - Specific EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_11_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.01,F06.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to trigger the Charging Station to send a MeterValuesRequest for a specific EVSE, using a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a TriggerMessageResponse with status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>3. The OCTT sends a MeterValuesRequest With evseld<Configured evseld>meterValue[0].sampledValue.context Trigger</td><td>4. The CSMS responds with a MeterValuesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: TriggerMessageRequest- requestedMessage must be MeterValues- evse.id must be<Configured evseld></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 538. Test Case Id: TC_F_12_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - MeterValues - All EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_12_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to trigger the Charging Station to send a MeterValuesRequest for all EVSE, using a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+TriggerMessageResponse
+with status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>3. The OCTT sends a MeterValuesRequest
+With evseld omitted
+meterValue[0].sampledValue.context Trigger
+Note(s):
+- This step will be executed for every EVSE.</td><td>4. The CSMS responds with a MeterValuesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message: TriggerMessageRequest
+- requestedMessage must be MeterValues</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 539. Test Case Id: TC_F_13_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - TransactionEvent - Specific EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_13_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.01,F06.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to trigger the Charging Station to send a TransactionRequest for a specific EVSE, using a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aTriggerMessageResponsewith status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>3. The OCTT sends a TransactionRequestWith evse.id<Configured evseld>triggerReason TriggertransactionInfo.chargingState ChargingmeterValue is presentmeterValue[0].sampledValue.context Trigger</td><td>4. The CSMS responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: TriggerMessageRequest- requestedMessage must be TransactionEvent- evse.id must be<Configured evseld></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 540. Test Case Id: TC_F_14_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - TransactionEvent - All EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_14_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to trigger the Charging Station to send a TransactionRequest for all EVSE, using a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a TriggerMessageResponsewith status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>3. The OCTT sends a TransactionRequestWith evse.id omittedtriggerReason TriggertransactionInfo.chargingState ChargimgeterValue is presentmeterValue[0].sampledValue.context TriggerNote(s):- This step will be executed for every EVSE.</td><td>4. The CSMS responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: TriggerMessageRequest- requestedMessage must be TransactionEvent</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 541. Test Case Id: TC_F_15_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - LogStatusNotification - Idle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_15_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to trigger the Charging Station to send a LogStatusNotificationRequest, using a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a TriggerMessageResponsewith status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>3. The OCTT sends a LogStatusNotificationRequestwith status Idle</td><td>4. The CSMS responds with aLogStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: TriggerMessageRequest- requestedMessage must be LogStatusNotification</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 542. Test Case Id: TC_F_18_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - FirmwareStatusNotification - Idle</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_18_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to trigger the Charging Station to send a FirmwareStatusNotificationRequest, using a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a TriggerMessageResponsewith status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>3. The OCTT sends a FirmwareStatusNotificationRequestwith status Idle</td><td>4. The CSMS responds with a FirmwareStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: TriggerMessageRequest- requestedMessage must be FirmwareStatusNotification</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 543. Test Case Id: TC_F_20_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - Heartbeat</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_20_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to trigger the Charging Station to send a HeartbeatRequest, using a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a TriggerMessageResponse with status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>3. The OCTT sends a HeartbeatRequest</td><td>4. The CSMS responds with a HeartbeatResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: TriggerMessageRequest - requestedMessage must be Heartbeat</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 544. Test Case Id: TC_F_23_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - StatusNotification - Specific EVSE - Available</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_23_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.01,F06.FR.02,F06.FR.13</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to trigger the Charging Station to send a StatusNotificationRequest for a specific available EVSE, using a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a TriggerMessageResponse with status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of the connector. Message: StatusNotificationRequest- connectorStatus Available- evseld<Configured evseld>- connectorId<Configured connectorId>Message: NotifyEventRequest- trigger Delta-actualValue "Available"- component.name "Connector"- component.evse.id<Configured evseld>- component.evseconnectorid<Configured connectorId>- variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: TriggerMessageRequest- requestedMessage must be StatusNotification- evse.id must be<Configured evseld></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 545. Test Case Id: TC_F_24_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - StatusNotification - Specific EVSE - Occupied</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_24_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.01,F06.FR.02,F06.FR.13</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to trigger the Charging Station to send a StatusNotificationRequest for a specific occupied EVSE, using a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT notifies the CSMS about the current state of the connector.Message: StatusNotificationRequest- connectorStatus Occupied- evseld<Configured evseld>- connectorId<Configured connectorId>Message: NotifyEventRequest- trigger Delta-actualValue "Occupied"- component.name "Connector"- component.evse.id<Configured evseld>- component.evseconnectorid<Configured connectorId>- variable.name "AvailabilityState"</td><td>2. The CSMS responds accordingly.</td></tr><tr><td>4. The OCTT responds with a TriggerMessageResponsewith status Accepted</td><td>3. The CSMS sends a TriggerMessageRequest</td></tr><tr><td>5. The OCTT notifies the CSMS about the current state of the connector.Message: StatusNotificationRequest- connectorStatus Occupied- evseld<Configured evseld>- connectorId<Configured connectorId>Message: NotifyEventRequest- trigger Delta-actualValue "Occupied"- component.name "Connector"- component.evse.id<Configured evseld>- component.evseconnectorid<Configured connectorId>- variable.name "AvailabilityState"</td><td>6. The CSMS responds accordingly.</td></tr><tr><td>Test case name</td><td>Trigger message - StatusNotification - Specific EVSE - Occupied</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: TriggerMessageRequest
+- requestedMessage must be StatusNotification
+- evse.id must be <Configured evseld></td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 546. Test Case Id: TC_F_27_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Trigger message - NotImplemented</td></tr><tr><td>Test case Id</td><td colspan="2">TC_F_27_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">F06</td></tr><tr><td>Requirement(s)</td><td colspan="2">F06.FR.08</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station that does not support the requested message value from a TriggerMessageRequest.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a TriggerMessageResponsewith status NotImplemented</td><td>1. The CSMS sends a TriggerMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+# 3.8. G Availability
+
+Table 547. Test Case Id: TC_G_03_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability EVSE - Operative to inoperative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_03_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Operative to Inoperative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the change availability mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Unavailable for <Configured evseld></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 548. Test Case Id: TC_G_04_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability EVSE - Inoperative to operative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_04_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Inoperative to Operative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the change availability mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: Unavailable for <Configured evseld></td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to change the availability of an EVSE to Operative.</td></tr><tr><td>2. The OCTT responds with a ChangeAvailabilityResponse with status Accepted</td><td>1. The CSMS sends a ChangeAvailabilityRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of all connectors belonging to the specified EVSE (and optionally also from the EVSE itself). Message: StatusNotificationRequest - connectorStatus Available - evseld <Configured evseld> Message: NotifyEventRequest - trigger Delta - actualValue "Available" - component.name "EVSE" / Connector - component.evse.id <Configured evseld> - variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message ChangeAvailabilityRequest - operationalStatus Operative - evse.id <Configured evseld> - connectorId omit</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 549. Test Case Id: TC_G_05_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Charging Station - Operative to inoperative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_05_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to change the availability from operative to inoperative.A Charging Station is considered Operative when it is charging or ready for charging.A Charging Station is considered Inoperative when it does not allow any charging.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the change availability mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action:Request the CSMS to change the availability of the Charging Station to Inoperative.</td></tr><tr><td>2. The OCTT responds with a ChangeAvailabilityResponse with status Accepted</td><td>1. The CSMS sends a ChangeAvailabilityRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of all connectorsMessage:StatusNotificationRequest- connectorStatus UnavailableMessage:NotifyEventRequest- trigger Delta-actualValue "Unavailable"- component.name "Connector"- variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message ChangeAvailabilityRequest- operationalStatus Inoperative- evseld omit- connectorId omit</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 550. Test Case Id: TC_G_06_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Charging Station - Inoperative to operative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_06_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to change the availability from inoperative to operative.A Charging Station is considered Operative when it is charging or ready for charging.A Charging Station is considered Inoperative when it does not allow any charging.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the change availability mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):Charging Station set to Unavailable (Original status was Available)</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to change the availability of the Charging Station to Inoperative.</td></tr><tr><td>2. The OCTT responds with a ChangeAvailabilityResponse with status Accepted</td><td>1. The CSMS sends a ChangeAvailabilityRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of all connectors.Message: StatusNotificationRequest- connectorStatus AvailableMessage: NotifyEventRequest- trigger Delta-actualValue "Available"- component.name "Connector"- variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message ChangeAvailabilityRequest- operationalStatus Operative- evseld omit- connectorId omit</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 551. Test Case Id: TC_G_07_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Connector - Operative to inoperative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_07_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the Connectors of one EVSE from Operative to Inoperative. A Connector is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the change availability mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to change the availability of a Connector to Inoperative.</td></tr><tr><td>2. The OCTT responds with a ChangeAvailabilityResponse with status Accepted</td><td>1. The CSMS sends a ChangeAvailabilityRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of the connector. Message: StatusNotificationRequest - connectorStatus Unavailable - evseld <Configured evseld> - connectorId <Configured connectorId> Message: NotifyEventRequest - trigger Delta -actualValue "Unavailable" - component.name "Connector" - component.evse.id <Configured evseld> - component.evseconnectorid <Configured connectorId> - variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message ChangeAvailabilityRequest - operationalStatus Inoperative - evse.id <Configured evseld> - evseconnectorld <Configured connectorId></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 552. Test Case Id: TC_G_08_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Connector - Inoperative to operative</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_08_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the Connectors from one EVSE from Inoperative to Operative. A Connector is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform the change availability mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: Unavailable for <Configured connectorId></td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to change the availability of a Connector to Operative.</td></tr><tr><td>2. The OCTT responds with a ChangeAvailabilityResponse with status Accepted</td><td>1. The CSMS sends a ChangeAvailabilityRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of the connector. Message: StatusNotificationRequest - connectorStatus Available - evseld <Configured evseld> - connectorId <Configured connectorId> Message: NotifyEventRequest - trigger Delta -actualValue "Available" - component.name "Connector" - component.evse.id <Configured evseld> - component.evseconnectorid <Configured connectorId> - variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message ChangeAvailabilityRequest - operationalStatus Operative - evse.id <Configured evseld> - evseconnectorId <Configured connectorId></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 553. Test Case Id: TC_G_11_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability EVSE - With ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_11_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Operative to Inoperative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a change availability request during a transaction according to the mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State: State is EnergyTransferStarted</td></tr><tr><td rowspan="8">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note(s): Request the CSMS to change the availability to inoperative</td></tr><tr><td>2. The OCTT responds with a ChangeAvailabilityResponse with status Scheduled</td><td>1. The CSMS sends a ChangeAvailabilityRequest</td></tr><tr><td colspan="2">Note(s): Wait for <Configured Transaction Duration></td></tr><tr><td colspan="2">3. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">4. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">5. Execute Reusable State EVDisconnected</td></tr><tr><td>6. The OCTT notifies the CSMS about the current state of all connectors with Message: StatusNotificationRequest - connectorStatus Unavailable - evseld <Configured evseld> OR Message: NotifyEventRequest - trigger Delta -actualValue "Unavailable" - component.name "Connector" - component.evse.id <Configured evseld> - variable.name "AvailabilityState"</td><td>7. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message ChangeAvailabilityRequest - operationalStatus Inoperative - evse.id <Configured evseld> - connectorId omit</td></tr><tr><td colspan="2">Post scenario validations: - A respond to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 554. Test Case Id: TC_G_14_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Charging Station - With ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_14_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Operative to Inoperative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a change availability request during a transaction according to the mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State:State is EnergyTransferStarted</td></tr><tr><td rowspan="9">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note(s): Request the CSMS to change the availability of the station to inoperative</td></tr><tr><td>2. The OCTT responds with a ChangeAvailabilityResponse with status Scheduled</td><td>1. The CSMS sends a ChangeAvailabilityRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of all unoccupied connectors with Message: StatusNotificationRequest- connectorStatus Unavailable</td><td>4. The CSMS responds accordingly.</td></tr><tr><td colspan="2">Note(s): Wait for <Configured Transaction Duration></td></tr><tr><td colspan="2">5. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">6. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">7. Execute Reusable State EVDisconnected</td></tr><tr><td>8. The OCTT notifies the CSMS about the current state of the configured connector with Message: StatusNotificationRequest- connectorStatus Unavailable</td><td>9. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message ChangeAvailabilityRequest-operationalStatus Inoperative- evseld omit- connectorId omit</td></tr><tr><td colspan="2">Post scenario validations:- A respond to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 555. Test Case Id: TC_G_17_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Change Availability Connector - With ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_17_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs from Operative to Inoperative. An EVSE is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a change availability request during a transaction according to the mechanism as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State: State is EnergyTransferStarted</td></tr><tr><td rowspan="8">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note(s): Request the CSMS to change the availability of one connector to inoperative</td></tr><tr><td>2. The OCTT responds with a ChangeAvailabilityResponse with status Scheduled</td><td>1. The CSMS sends a ChangeAvailabilityRequest</td></tr><tr><td colspan="2">Note(s): Wait for <Configured Transaction Duration></td></tr><tr><td colspan="2">3. Execute Reusable State StopAuthorized</td></tr><tr><td colspan="2">4. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">5. Execute Reusable State EVDisconnected</td></tr><tr><td>6. The OCTT notifies the CSMS about the current state of all connectors with Message: StatusNotificationRequest - connectorStatus Unavailable - evseld <Configured evseld> - connectorId <Configured connectorId></td><td>7. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message ChangeAvailabilityRequest - operationalStatus Inoperative - evse.id <Configured evseld> - evseconnectorId <Configured connectorId></td></tr><tr><td colspan="2">Post scenario validations: - A respond to report the state of a connector has been received for all connectors.</td></tr></table>
+
+Table 556. Test Case Id: TC_G_20_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Connector status Notification - Lock Failure</td></tr><tr><td>Test case Id</td><td colspan="2">TC_G_20_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">G05</td></tr><tr><td>Requirement(s)</td><td colspan="2">G05.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the EV Driver is prevented from starting a charge session at the Charging Station while the Connector is not locked properly.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS responds on a notifyeventrequest as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a NotifyEventRequest with-eventData trigger Delta-eventData.elementname"ConnectorPlugRetentionLock"- eventData variable.name "Problem"- eventDataactualValue "true"</td><td>2. The CSMS responds with a NotifyEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+# 3.9. H Reservation
+
+Table 557. Test Case Id: TC_H_01_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Accepted - Valid idToken</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S2), H03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve a specific EVSE for a specific IdToken by sending a ReserveNowRequest containing an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to reserve a specific EVSE, until the EV Driver with the specified IdToken arrives.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Reserved for <Configured evseld></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 558. Test Case Id: TC_H_07_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Reservation Ended / not used</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_07_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S2), H04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve a specific EVSE for a specific IdToken by sending a ReserveNowRequest containing an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a reservation that is canceled by the Charging Station, because the EV driver did not arrive before the set expiryDateTime was reached.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="6">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send a ReserveNowRequest for a specific EVSE.</td></tr><tr><td>2. The OCTT responds with a ReserveNowResponse With status Accepted</td><td>1. The CSMS sends a ReserveNowRequest with expiryDateTime current time + <configured transaction duration></td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of the connector(s) of the configured EVSE Message: StatusNotificationRequest with connectorStatus Reserved Message: NotifyEventRequest with trigger Delta actualValue "Reserved" component.name "Connector" variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td>5. The OCTT notifies the CSMS about the current state of the connector(s) of the configured EVSE Message: StatusNotificationRequest with connectorStatus Available Message: NotifyEventRequest with trigger Delta actualValue "Available" component.name "Connector" variable.name "AvailabilityState" Note(s): - The OCTT waits until the provided expiryDateTime from step 1 expires before executing this step.</td><td>6. The CSMS responds accordingly.</td></tr><tr><td>7. The OCTT sends a ReservationStatusUpdateRequest With reservationUpdateStatus Expired reservationId <id received at step 1></td><td>8. The CSMS responds with a ReservationStatusUpdateResponse</td></tr><tr><td>Test case name</td><td>Reserve a specific EVSE - Reservation Ended / not used</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: ReserveNowRequest
+- evseld must be <Configured evseld>
+- connectorType must be omitted
+-idToken.idToken <Configured valid_idtoken_idtoken>
+-idToken.type <Configured valid_idtoken_type></td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 559. Test Case Id: TC_H_08_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve an unspecified EVSE - Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_08_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S1), H03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an unspecified EVSE for a specific IdToken by sending a ReserveNowRequest without an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to reserve an unspecified EVSE, until the EV Driver with the specified IdToken arrives.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send a ReserveNowRequest for an unspecified EVSE.</td></tr><tr><td>2. The OCTT responds with a ReserveNowResponse with status Accepted</td><td>1. The CSMS sends a ReserveNowRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of the connector(s) of the configured EVSE Message: StatusNotificationRequest with connectorStatus Reserved Message: NotifyEventRequest with trigger Delta actualValue "Reserved" component.name "Connector" variable.name "AvailabilityState" Note(s): - The OCTT will execute this step, if it is configured with only one EVSE.</td><td>4. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: ReserveNowRequest - evseld must be omitted - connectorType must be omitted - idToken.idToken <Configured valid_idtoken_idtoken> - idToken.type <Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 560. Test Case Id: TC_H_14_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve an unspecified EVSE - Amount of EVSEs available equals the amount of reservations</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_14_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S1)</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an unspecified EVSE for a specific IdToken by sending a ReserveNowRequest without an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle that the Charging Station sets all available EVSE to reserved, when the amount of EVSEs available equals the amount of reservations.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send a ReserveNowRequest for an unspecified EVSE.</td></tr><tr><td>2. The OCTT responds with a ReserveNowResponse with status Accepted</td><td>1. The CSMS sends a ReserveNowRequest Note(s): - This step needs to executed time the amount of EVSE configured for the OCTT.</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of all connectors Message: StatusNotificationRequest with connectorStatus Reserved Message: NotifyEventRequest with trigger Delta actualValue "Reserved" component.name "Connector" variable.name "AvailabilityState" Note(s): - This step will be executed after the last ReserveNowRequest has been sent from step 1.</td><td>4. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: ReserveNowRequest - evseld must be omitted - connectorType must be omitted - idToken.idToken <Configured valid_idtoken_idtoken> - idToken.type <Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 561. Test Case Id: TC_H_15_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a connector with a specific type - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_15_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01(S3), H03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an EVSE with a connector with a specific type for a specific IdToken by sending a ReserveNowRequest with a connectorType.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to reserve an EVSE with a connector with a specific type, until the EV Driver with the specified IdToken arrives.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send a ReserveNowRequest for a specific ConnectorType.</td></tr><tr><td>2. The OCTT responds with a ReserveNowResponseWith status Accepted</td><td>1. The CSMS sends a ReserveNowRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of the connectorMessage: StatusNotificationRequestwith connectorStatus ReservedMessage: NotifyEventRequestwith trigger DeltaactualValue "Reserved"component.name "Connector"variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: ReserveNowRequest- evseld must be omitted- connectorType must be <Configured connectorType>- idToken.idToken <Configured valid_idtoken_idtoken>- idToken.type <Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 562. Test Case Id: TC_H_17_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Cancel reservation of an EVSE - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_17_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to cancel a reservation by sending a CancelReservationRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to cancel a reservation, by sending a CancelReservationRequest</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="11">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send a ReserveNowRequest for a specific EVSE.</td></tr><tr><td>2. The OCTT responds with a ReserveNowResponse with status Accepted</td><td>1. The CSMS sends a ReserveNowRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of the connector(s) of the configured EVSE</td><td rowspan="3">4. The CSMS responds accordingly.</td></tr><tr><td>Message: StatusNotificationRequestwith connectorStatus Reserved</td></tr><tr><td>Message: NotifyEventRequestwith trigger DeltaactualValue "Reserved"component.name "Connector"variable.name "AvailabilityState"</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send a CancelReservationRequest for the reservation created at step 1.</td></tr><tr><td>6. The OCTT responds with aCancelReservationResponseWith status Accepted</td><td>5. The CSMS sends a CancelReservationRequest</td></tr><tr><td>7. The OCTT notifies the CSMS about the current state of the connector(s) of the configured EVSE</td><td rowspan="3">8. The CSMS responds accordingly.</td></tr><tr><td>Message: StatusNotificationRequestwith connectorStatus Available</td></tr><tr><td>Message: NotifyEventRequestwith trigger DeltaactualValue "Available"component.name "Connector"variable.name "AvailabilityState"</td></tr></table>
+
+<table><tr><td>Test case name</td><td>Cancel reservation of an EVSE - Success</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: ReserveNowRequest
+- evseld must be <Configured evseld>
+- connectorType must be omitted
+- idToken.idToken <Configured valid_idtoken_idtoken>
+- idToken.type <Configured valid_idtoken_type>
+* Step 5:
+Message: CancelReservationRequest
+- reservationId must be equal to the id provided at step 1</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 563. Test Case Id: TC_H_19_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Use a reserved EVSE with Groupld</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_19_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01, H03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve an EVSE for a specific group by sending a ReserveNowRequest containing a groupIdToken.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station create a reservation for a specific group, by sending a ReserveNowRequest with a groupIdToken</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send a ReserveNowRequest with a groupIdToken for a specific EVSE.</td></tr><tr><td>2. The OCTT responds with a ReserveNowResponse With status Accepted</td><td>1. The CSMS sends a ReserveNowRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of the connector(s) of the configured EVSE Message: StatusNotificationRequest with connectorStatus Reserved Message: NotifyEventRequest with trigger Delta actualValue "Reserved" component.name "Connector" variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: ReserveNowRequest- evseld must be <Configured evseld> - connectorType must be omitted - groupIdToken must be provided - idToken.idToken <Configured valid_idtoken_idtoken> - idToken.type <Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 564. Test Case Id: TC_H_20_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Charging Station cancels reservation when Faulted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_20_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Charging Station will cancel reservations, when the EVSE specified for a reservation is set to an inoperative state.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle it when the reservation is canceled when the availability state of the EVSE specified for the reservation is set to Faulted by the OCTT.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send a ReserveNowRequest for a specific EVSE.</td></tr><tr><td>2. The OCTT responds with a ReserveNowResponseWith status Accepted</td><td>1. The CSMS sends a ReserveNowRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of the connector(s) of the configured EVSEMessage: StatusNotificationRequestwith connectorStatus ReservedMessage: NotifyEventRequestwith trigger DeltaactualValue "Reserved"component.name "Connector"variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td>5. The OCTT notifies the CSMS about the current state of the connector(s) of the configured EVSEMessage: StatusNotificationRequestwith connectorStatus FaultedMessage: NotifyEventRequestwith trigger DeltaactualValue "Faulted"component.name "Connector"variable.name "AvailabilityState"</td><td>6. The CSMS responds accordingly.</td></tr><tr><td>7. The OCTT sends aReservationStatusUpdateRequestWith reservationUpdateStatus RemovedreservationId <id received at step 1></td><td>8. The CSMS responds with aReservationStatusUpdateResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: ReserveNowRequest- evseld must be <Configured evseld>- connectorType must be omitted-idToken.idToken<Configured valid_idtoken_idtoken>- idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 565. Test Case Id: TC_H_22_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reserve a specific EVSE - Configured to Reject</td></tr><tr><td>Test case Id</td><td colspan="2">TC_H_22_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">H01</td></tr><tr><td>Requirement(s)</td><td colspan="2"></td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to reserve a specific EVSE for a specific IdToken by sending a ReserveNowRequest containing an evseld.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to correctly read the respond from a charging station when it is configured not to accept reservations.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a ReserveNowResponse with - status Rejected</td><td>1. The CSMS sends a ReserveNowRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+# 3.10. I Tariff and Cost
+
+Table 566. Test Case Id: TC_L_01_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Show EV Driver running total cost during charging - costUpdatedRequest</td></tr><tr><td>Test case Id</td><td colspan="2">TC_1_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">I02</td></tr><tr><td>Requirement(s)</td><td colspan="2">I02.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">While a transaction is ongoing, the driver wants to know how much the running total cost is, updated at a relevant interval.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to correctly send the running total cost as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="7">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest with idToken.idToken <Configured valid_idtoken_idtoken> idToken.type <Configured valid_idtoken_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest with - triggerReason Authorized - idToken.idToken <Configured valid_idtoken_idtoken> - idToken.type <Configured valid_idtoken_type> - eventType Updated</td><td>4. The CSMS responds with a TransactionEventResponse</td></tr><tr><td colspan="2">5. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">6. Execute Reusable State EnergyTransferStarted</td></tr><tr><td>7. The OCTT sends a TransactionEventRequest With triggerReason is MeterValuePeriodic eventType is Updated timestamp <The intervals between the timestamps of the received Meter Value messages equals the configured sampled Meter Values interval>.sampledValue.context is Sample.PeriodicNote(s): - This step will be executed every <Configured sampled Meter Values interval> - The OCTT will end the testcase after two MeterValues.</td><td>8. The OCTT responds with a TransactionEventResponse</td></tr><tr><td>10. The OCTT responds with a CostUpdatedResponse</td><td>9. The CSMS sends a CostUpdatedRequest Note(s): - This step will be executed after every TransactionEventResponse, if the message did not contain a totalCost.</td></tr><tr><td>Test case name</td><td>Show EV Driver running total cost during charging - costUpdatedRequest</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+MessageauthorizeResponse
+-idTokenInfo.status Accepted
+* Step 4:
+Message TransactionEventResponse
+-idTokenInfo.status Accepted
+-totalCost <Optional>
+* Step 7:
+Message (Optional) CostUpdatedRequest
+- transactionId <Generated TransactionId></td></tr><tr><td>Post scenario validations:
+-N/a</td></tr></table>
+
+Table 567. Test Case Id: TC_I_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Show EV Driver Final Total Cost After Charging</td></tr><tr><td>Test case Id</td><td colspan="2">TC_I_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">I03</td></tr><tr><td>Requirement(s)</td><td colspan="2">I03.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">While a transaction is ongoing, the driver wants to know how much the running total cost is, updated at a relevant interval.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to correctly send the total cost as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">- N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): state is EVConnectedPostSession</td></tr><tr><td rowspan="8">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT notifies the CSMS about the current state of the configured connector.</td><td rowspan="6">2. The CSMS responds accordingly.</td></tr><tr><td>Message: StatusNotificationRequest - connectorStatus Available</td></tr><tr><td>Message: NotifyEventRequest - trigger Delta</td></tr><tr><td>- actualValue "Available"</td></tr><tr><td>- component.name "Connector"</td></tr><tr><td>- variable.name "AvailabilityState"</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest with - triggerReason EVCommunicationLost - eventType Ended - transactionInfo.chargingState Idle - transactionInfo.stoppedReason EVDisconnected</td><td>4. The CSMS responds with a TransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 4: Message TransactionEventResponse - totalCost <Not omitted></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+# 3.11. J MeterValues
+
+Table 568. Test Case Id: TC_J_01_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clock-aligned Meter Values - No transaction ongoing</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J01</td></tr><tr><td>Requirement(s)</td><td colspan="2">J01.FR.18</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station sending clock-aligned Meter Values, when there is no ongoing transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT notifies the CSMS about its measured Meter Values.</td><td>2. The CSMS responds accordingly.</td></tr><tr><td colspan="2">Message: MeterValuesRequest - timestamp <The intervals between the timestamps of the received Meter Value messages equals the _<Configured clock-aligned Meter Values interval>. -sampledValue.context is Sample.Clock Message: NotifyEventRequest - timestamp <The intervals between the timestamps of the received Meter Value messages equals the _<Configured clock-aligned Meter Values interval>. - trigger is Periodic - component.name is FiscalMetering Note(s): - This step will be executed every _<Configured clock-aligned Meter Values interval> - This step will be executed for evseld=0 and all configured EVSE. - The OCTT will end the testcase after it has send three Meter Value messages.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 569. Test Case Id: TC_J_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clock-aligned Meter Values - Transaction ongoing</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J01</td></tr><tr><td>Requirement(s)</td><td colspan="2">J01.FR.18</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station sending clock-aligned Meter Values, when there is an ongoing transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted for <Configured evseld></td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT notifies the CSMS about its measured Meter Values.Note: MeterValuesRequest-timestamp <The intervals between the timestamps of the received Meter Value messages equals the configured clock-aligned Meter Values interval>.-sampledValue.context is Sample.ClockMessage: NotifyEventRequest-timestamp <The intervals between the timestamps of the received Meter Value messages equals the configured clock-aligned Meter Values interval>.- trigger is Periodic-component.name is FiscalMeteringNote(s):- This step will be executed every _<Configured clock-aligned Meter Values interval>- This step will be executed for evseld=0 and all configured idle EVSE.</td><td>2. The CSMS responds accordingly.</td></tr><tr><td>3. The OCTT sends a TransactionEventRequestWith triggerReason is MeterValueClockeventType is Updatedtimestamp <The intervals between the timestamps of the received Meter Value messages equals the configured clock-aligned Meter Values interval>.sampledValue.context is Sample.CircleNote(s):- This step will be executed every _<Configured clock-aligned Meter Values interval>- The OCTT will end the testcase after the <Configured transaction duration> is reached._</td><td>4. The CSMS responds with a TransactionEventResponse</td></tr><tr><td>Test case name</td><td>Clock-aligned Meter Values - Transaction ongoing</td></tr><tr><td rowspan="2">Tool validations</td><td>N/a</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 570. Test Case Id: TC_J_03_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clock-aligned Meter Values - EventType Ended</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_03_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J01</td></tr><tr><td>Requirement(s)</td><td colspan="2">J01.FR.18</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station sending clock-aligned Meter Values, when a transaction ends.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">- The TransactionEventRequest containing eventType Ended contains the MeterValue field.
+- timestamp <The intervals between the timestamps of the received Meter Value messages equals the configured value at configured clock-aligned Tx ended Meter Values interval>.
+- sampledValue.context is Sample.Clock AND the last one has Transaction.End</td></tr><tr><td colspan="2">Note(s):
+- This step will be executed after the <Configured transaction duration> is reached..
+- This causes the transaction to stop.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 571. Test Case Id: TC_J_04_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clock-aligned Meter Values - Signed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_04_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J01</td></tr><tr><td>Requirement(s)</td><td colspan="2">J01.FR.21</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station sending clock-aligned Meter Values, when a transaction ends.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">- The TransactionEventRequest containing eventType Ended contains the MeterValue field.
+- timestamp <The intervals between the timestamps of the received Meter Value messages equals the configured value at configured clock-aligned Tx ended Meter Values interval>.
+- sampledValue.context is Sample.Clock AND the last one has Transaction.End
+- sampledValue-signedMeterValue is <Generated SignedMeterValueType></td></tr><tr><td colspan="2">Note(s):
+- This step will be executed after the_<Configured transaction duration> is reached_.
+- This causes the transaction to stop.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 572. Test Case Id: TC_J_07_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Sampled Meter Values - EventType Started - EVSE known</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_07_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J02</td></tr><tr><td>Requirement(s)</td><td colspan="2">J02.FR.19</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station sending start sampled Meter Values, when a transaction starts.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">- The TransactionRequest contains the MeterValue field.</td></tr><tr><td colspan="2">- sampledValue.context is Transaction.Begin</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 573. Test Case Id: TC_J_08_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Sampled Meter Values - Context Transaction.Begin - EVSE not known</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_08_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J02</td></tr><tr><td>Requirement(s)</td><td colspan="2">J02.FR.19</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station sending start sampled Meter Values, when a transaction starts.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="6">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State Authorized</td></tr><tr><td colspan="2">2. Execute Reusable State EVConnectedPreSession</td></tr><tr><td colspan="2">- The TransactionRequest contains the MeterValue field.</td></tr><tr><td colspan="2">- sampledValue.context is Transaction.Begin</td></tr><tr><td colspan="2">3. Execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 574. Test Case Id: TC_J_09_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Sampled Meter Values - EventType Updated</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_09_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J02</td></tr><tr><td>Requirement(s)</td><td colspan="2">J02.FR.19</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station sending sampled Meter Values, when there is an ongoing transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequestWith triggerReason is MeterValuePeriodiceventType is Updatedtimestamp <The intervals between the timestamps of the received Meter Value messages equals the configured sampled Meter Values interval>.sampledValue.context is Sample.PeriodicNote(s):-- This step will be executed every <Configuredsampled Meter Values interval>- The OCTT will end the testcase after threeMeterValues.</td><td>2. The CSMS responds with aTransactionResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 575. Test Case Id: TC_J_10_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Sampled Meter Values - EventType Ended</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_10_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J02</td></tr><tr><td>Requirement(s)</td><td colspan="2">J02.FR.19</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station sending sampled Meter Values, when a transaction ends.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">- The TransactionEventRequest containing eventType Ended contains the MeterValue field.
+- timestamp <The intervals between the timestamps of the received Meter Value messages equals the configured value at configured clock-aligned Tx ended Meter Values interval>.
+- sampledValue.context is Sample.Periodic AND the last one has Transaction.End</td></tr><tr><td colspan="2">Note(s):
+- This step will be executed after the <Configured transaction duration> is reached..
+- This causes the transaction to stop.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 576. Test Case Id: TC_J_11_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Sampled Meter Values - Signed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_J_11_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">J02</td></tr><tr><td>Requirement(s)</td><td colspan="2">J02.FR.21</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">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.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station sending sampled Meter Values, when a transaction ends.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State EVDisconnected</td></tr><tr><td colspan="2">- The TransactionEventRequest containing eventType Ended contains the MeterValue field. - timestamp <The intervals between the timestamps of the received Meter Value messages equals the configured value at configured clock-aligned Tx ended Meter Values interval>. -sampledValue.context is Sample.Periodic AND the last one has Transaction.End -sampledValuesignedMeterValue is <Generated SignedMeterValueType></td></tr><tr><td colspan="2">Note(s): - This step will be executed after the_<Configured transaction duration> is reached._ - This causes the transaction to stop.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+# 3.12. K SmartCharging
+
+Table 577. Test Case Id: TC_K_01_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - TxDefaultProfile - Specific EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.31</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a TxDefaultProfile charging profile for a specific EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetChargingProfileResponse with status Accepted</td><td>1. The CSMS sends a SetChargingProfileRequest with- chargingProfile.id<Configured chargingProfileId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetChargingProfileRequestevseld<Configured evseld> ANDchargingProfile.stackLevel<Configured stackLevel> ANDchargingProfile.chargingProfilePurpose TxDefaultProfile ANDchargingProfile.chargingProfileKind Absolute ANDchargingProfile.validFrom now ANDchargingProfile.validTo now +<Configured Charging Schedule Duration> ANDchargingProfile.chargingSchedule.startSchedule now ANDchargingProfile.chargingSchedule.chargingRateUnit<Configured chargingRateUnit> ANDchargingProfile.chargingSchedule.duration<Configured duration> ANDchargingProfile.chargingSchedule.chargingSchedulePeriod.startPeriod<Configured startPeriod> ANDchargingProfile.chargingSchedule.chargingSchedulePeriod limit 6.0 or 6000.0 ANDchargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases<Configured numberPhases>where<Configured numberPhases> not 3 ORchargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases<Configured numberPhases>or<omit> where<Configured numberPhases>3</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 578. Test Case Id: TC_K_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - TxProfile without ongoing transaction on the specified EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a TxProfile and read the charger's feedback while no transaction is ongoing for a specific EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">If the CSMS supports sending a TxProfile while there is no transaction ongoing.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetChargingProfileResponse with status Rejected</td><td>1. The CSMS sends a SetChargingProfileRequest -chargingProfile.id <Configured chargingProfileId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetChargingProfileRequest- evseld <Configured evseld> AND-chargingProfile.chargingProfilePurpose TxProfile AND-chargingProfile.stackLevel <Configured stackLevel> AND-chargingProfile.chargingProfileKind Relative AND-chargingProfile.chargingSchedule.chargingRateUnit <Configured chargingRateUnit> AND-chargingProfile.chargingSchedule.chargingSchedulePeriod.startPeriod 0 AND-chargingProfile.chargingSchedule.chargingSchedulePeriodlimit 7.0 or 7000.0 AND-chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases>where <Configured numberPhases> not 3 OR-chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases>or <omit> where <Configured numberPhases> 3</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 579. Test Case Id: TC_K_03_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - ChargingStationMaxProfile</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_03_CSMS</td></tr><tr><td>Use case ld(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.31, K01.FR.38</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a ChargingStationMaxProfile charging profile as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetChargingProfileResponse with status Accepted</td><td>1. The CSMS sends a SetChargingProfileRequest -chargingProfile.id<Configured chargingProfileId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetChargingProfileRequestevseld 0 ANDchargingProfile.stackLevel<Configured stackLevel>ANDchargingProfile.chargingProfilePurpose ChargingStationMaxProfile_ ANDchargingProfile.chargingProfileKind Absolute OR RelativechargingProfile.chargingSchedule.chargingRateUnit<Configured ChargingRateUnit>chargingProfile.chargingSchedule.duration<Configured duration>chargingProfile.chargingSchedule.chargingSchedulePeriod.startPeriod 0chargingProfile.chargingSchedule.chargingSchedulePeriod limit 8.0 or 8000.0chargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases<Configured numberPhases>where<Configured numberPhases>not 3 ORchargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases<Configured numberPhases>or<omit> where<Configured numberPhases>3chargingProfile.validFrom<Not omitted>chargingProfile.validTo<Not omitted>chargingProfile.chargingSchedule.startSchedule<Not omitted></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 580. Test Case Id: TC_K_04_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Replace charging profile - With chargingProfileId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_04_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">n/a</td></tr><tr><td>Requirement(s)</td><td colspan="2">n/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to replace a charging profile with the same ProfileKind, Purpose, and stackLevel, but a different limit.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetChargingProfileResponse with status Accepted</td><td>1. The CSMS sends a SetChargingProfileRequest with chargingProfile.chargingSchedule.chargingSchedul ePeriodlimit 8.0 or 8000.0</td></tr><tr><td>4. The OCTT responds with a SetChargingProfileResponse with status Accepted</td><td>3. The CSMS sends a SetChargingProfileRequest with chargingProfile.chargingSchedule.chargingSchedul ePeriod limit 6.0 or 6000.0</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3: Message SetChargingProfileRequest chargingProfile.id <same id for both chargingProfiles></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 581. Test Case Id: TC_K_05_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Charging Profile - With chargingProfileId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_05_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K10</td></tr><tr><td>Requirement(s)</td><td colspan="2">K10.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">If the CSMS wishes to clear some or all of the charging profiles that were previously sent to the Charging Station, then the CSMS sends a ClearChargingProfileRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the charging station to clear a specific charging profile (not TxDefault) with only a chargingProfileId as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:CSMS sends a GetChargingProfilesRequestOCTT responds with a GetChargingProfilesResponse with status AcceptedOCTT sends a ReportChargingProfilesRequestCSMS responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aClearChargingProfileResponse withstatus Accepted</td><td>1. The CSMS sends a ClearChargingProfileRequestwithchargingProfileId<Generated chargingProfileId>ANDchargingProfileCriteria omit</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 582. Test Case Id: TC_K_06_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Charging Profile - With stackLevel/purpose combination for one profile</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_06_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K10</td></tr><tr><td>Requirement(s)</td><td colspan="2">K10.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">If the CSMS wishes to clear some or all of the charging profiles that were previously sent to the Charging Station, then the CSMS sends a ClearChargingProfileRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the charging station to clear a specific charging profile with a stackLevel/purpose combination for a chargingProfileId as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a ClearChargingProfileResponse with status Accepted</td><td>1. The CSMS sends a ClearChargingProfileRequest with chargingProfilePurpose TxDefaultProfile AND evseld <Configured evseld> AND stackLevel <Configured stackLevel></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message ClearChargingProfileRequest chargingProfileCriteria.chargingProfilePurpose TxDefaultProfile AND chargingProfileCriteria.stackLevel <Configured stackLevel> AND chargingProfileCriteria.evseld <Configured evseld></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 583. Test Case Id: TC_K_08_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Charging Profile - Without previous charging profile</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_08_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">If the CSMS wishes to clear some or all of the charging profiles that were previously sent to the Charging Station, then the CSMS sends a ClearChargingProfileRequest to the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the charging station to clear a specific charging profile with a chargingProfileId and stackLevel/purpose combination while the Charging stations does not accept as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a ClearChargingProfileResponse with status Unknown</td><td>1. The CSMS sends a ClearChargingProfileRequest with chargingProfilePurpose TxDefaultProfile AND evseld <Configured evseld> AND stackLevel <Configured stackLevel></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message ClearChargingProfileRequest chargingProfilePurpose TxDefaultProfile AND evseld <Configured evseld> AND stackLevel <Configured stackLevel></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 584. Test Case Id: TC_K_10_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - TxDefaultProfile - All EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_10_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.31</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a TxDefaultProfile charging profile for all EVSE as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetChargingProfileResponse with status Accepted</td><td>1. The CSMS sends a SetChargingProfileRequest with - chargingProfile.id <Configured chargingProfileId></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetChargingProfileRequestevseld 0 ANDchargingProfile.stackLevel <Configured stackLevel> ANDchargingProfile.chargingProfilePurpose TxDefaultProfile ANDchargingProfile.chargingProfileKind Absolute ANDchargingProfile.validFrom <Not omitted> ANDchargingProfile.validTo <Not omitted> ANDchargingProfile.chargingSchedule.startSchedule <Not omitted> ANDchargingProfile.chargingSchedule.chargingRateUnit <Configured ChargingRateUnit> ANDchargingProfile.chargingSchedule.chargingSchedulePeriod.startPeriod 0 ANDchargingProfile.chargingSchedule.duration <Configured duration>chargingProfile.chargingSchedule.chargingSchedulePeriod limit 6.0 or 6000.0 ANDchargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases>where <Configured numberPhases> not 3 ORchargingProfile.chargingSchedule.chargingSchedulePeriod.numberPhases <Configured numberPhases>or <omit> where <Configured numberPhases> 3</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 585. Test Case Id: TC_K_15_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - Not Supported</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_15_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a Profile, while the charging station does not support chargingprofiles, and read the response as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with RPC Framework:CALLERROR: NotSupported.</td><td>1. The CSMS sends a SetChargingProfileRequest with:evseld<Configured evseld> ANDchargingProfile.stackLevel<Configured stackLevel>ANDchargingProfile.chargingProfilePurposeTxDefaultProfile ANDchargingProfile.chargingProfileKind Absolute ANDchargingProfile.validFrom<Not omitted> ANDchargingProfile.validTo<Not omitted> ANDchargingProfile.chargingSchedule.startSchedule<Not omitted> ANDchargingProfile.chargingSchedule.chargingRateUnit<Configured ChargingRateUnit> ANDchargingProfile.chargingSchedule.chargingSchedul ePeriod.startPeriod 0 ANDchargingProfile.chargingSchedule.duration<Configured duration>chargingProfile.chargingSchedule.chargingSchedul ePeriod limit 6.0 or 6000.0 ANDchargingProfile.chargingSchedule.chargingSchedul ePeriod.numberPhases<Configured numberPhases></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">-N/a</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 586. Test Case Id: TC_K_19_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - ChargingProfileKind is Recurring</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_19_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a Profile with a concurrencyKind specified as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetChargingProfileResponse with - status Accepted</td><td>1. The CSMS sends a SetChargingProfileRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetChargingProfileRequest- evseld <Configured evseld> AND- chargingProfile.stackLevel <Configured stackLevel> AND- chargingProfile.chargingProfilePurpose TxDefaultProfile AND- chargingProfile.chargingSchedule.chargingSchedulePeriod.startPeriod 0 AND- chargingProfile.chargingProfileKind Recurring AND- chargingProfile.recurrencyKind <Configured concurrencyKind></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 587. Test Case Id: TC_K_29_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - Evseld 0</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_29_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request charging profiles installed on the charging station itself and read in the reports as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:EnergyTransferStarted</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aGetChargingProfilesResponse with- status Accepted</td><td>1. The CSMS sends a GetChargingProfilesRequest with- evseld 0</td></tr><tr><td>3. The OCTT sends aReportChargingProfilesRequest with- requestId <Received requestId></td><td>4. The CSMS responds with a ReportChargingProfilesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetChargingProfilesRequest- evseld 0 AND- chargingProfile.chargingProfilePurpose <Configured chargingProfilePurpose></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 588. Test Case Id: TC_K_30_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - Evseld > 0</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_30_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request charging profiles installed on a specific EVSE and read in the reports as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a GetChargingProfilesResponse with - status Accepted</td><td>1. The CSMS sends a GetChargingProfilesRequest</td></tr><tr><td>3. The OCTT sends a ReportChargingProfilesRequest with - requestId <Received requestId></td><td>4. The CSMS responds with a ReportChargingProfilesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message GetChargingProfilesRequest - evseld <Configured evseld></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 589. Test Case Id: TC_K_31_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - No Evseld</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_31_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request all charging profiles installed on a charger and read in the reports as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aGetChargingProfilesResponse with- status Accepted</td><td>1. The CSMS sends a GetChargingProfilesRequest with- requestId <Received requestId></td></tr><tr><td>3. The OCTT sends aReportChargingProfilesRequest with- requestId <Received requestId> AND- tbc true AND- evseld i</td><td>4. The CSMS responds with a ReportChargingProfilesResponse</td></tr><tr><td colspan="2">Note(s):- Step 3 and 4 are repeated for every evse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetChargingProfilesRequest- evseld omit</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 590. Test Case Id: TC_K_32_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - chargingProfileId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_32_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request a specific charging profile and read in the reports as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aGetChargingProfilesResponse with- status Accepted</td><td>1. The CSMS sends a GetChargingProfilesRequest -chargingProfileId <Received chargingProfileId></td></tr><tr><td>3. The OCTT sends aReportChargingProfilesRequest with- requestId Generated Id</td><td>4. The CSMS responds with a ReportChargingProfilesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetChargingProfilesRequest- chargingProfileId <received chargingProfileId> AND- requestId <Generated Id></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 591. Test Case Id: TC_K_33_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - Evseld > 0 + stackLevel</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_33_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request charging profiles with a specific stackLevel installed on a specific EVSE and read in the reports as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aGetChargingProfilesResponse with- status Accepted</td><td>1. The CSMS sends a GetChargingProfilesRequest</td></tr><tr><td>3. The OCTT sends aReportChargingProfilesRequest with- requestId Generated Id</td><td>4. The CSMS responds with a ReportChargingProfilesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetChargingProfilesRequest- evseld<Configured evseld> AND- chargingProfile.stackLevel<Configured stackLevel></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 592. Test Case Id: TC_K_34_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - Evseld > 0 + chargingLimitSource</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_34_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request charging profiles with a specific chargingLimitSource installed on a specific EVSE and read in the reports as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aGetChargingProfilesResponse with- status Accepted</td><td>1. The CSMS sends a GetChargingProfilesRequest</td></tr><tr><td>3. The OCTT sends aReportChargingProfilesRequest with- requestId Generated Id</td><td>4. The CSMS responds with aReportChargingProfilesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetChargingProfilesRequest- evseld<Configured evseld> AND-chargingProfile.chargingLimitSource<Configured chargingLimitSource></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 593. Test Case Id: TC_K_35_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - Evseld > 0 + chargingProfilePurpose</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_35_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request charging profiles with a specific chargingProfilePurpose installed on a specific EVSE and read in the reports as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aGetChargingProfilesResponse with- status Accepted</td><td>1. The CSMS sends a GetChargingProfilesRequest</td></tr><tr><td>3. The OCTT sends aReportChargingProfilesRequest with- requestId Generated Id</td><td>4. The CSMS responds with aReportChargingProfilesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetChargingProfilesRequest- evseld<Configured evseld> AND- chargingProfile.chargingProfilePurpose<Configured chargingProfilePurpose></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 594. Test Case Id: TC_K_36_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Profile - Evseld > 0 + chargingProfilePurpose + stackLevel</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_36_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K09</td></tr><tr><td>Requirement(s)</td><td colspan="2">K09.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request charging profiles with a specific chargingProfilePurpose AND stackLevel installed on a specific EVSE and read in the reports as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+GetChargingProfilesResponse with
+- status Accepted</td><td>1. The CSMS sends a GetChargingProfilesRequest</td></tr><tr><td>3. The OCTT sends a
+ReportChargingProfilesRequest with
+- requestId Generated Id</td><td>4. The CSMS responds with a
+ReportChargingProfilesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message GetChargingProfilesRequest
+- evseld <Configured evseld> AND
+- chargingProfile.chargingProfilePurpose <Configured chargingProfilePurpose> -
+chargingProfile.stackLevel <Configured stackLevel></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 595. Test Case Id: TC_K_60_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - TxProfile with ongoing transaction on the specified EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_60_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K01.FR.03, K01.FR.31</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sets a TxProfile on a specific EVSE for a currently ongoing transaction.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to exchange messages to set a TxProfile on a specific EVSE for a currently ongoing transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetChargingProfileResponse With status is Accepted</td><td>1. The CSMS sends a SetChargingProfileRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: (Message: SetChargingProfileRequest) ChargingProfilePurpose is TxProfile AND evseld is <Configured evseld> AND transactionId <Generated transactionId></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 596. Test Case Id: TC_K_37_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Remote start transaction with charging profile - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_37_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K05,F01</td></tr><tr><td>Requirement(s)</td><td colspan="2">K05.FR.02,F01.FR.08,F01.FR.09,F01.FR.11</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sets a TxProfile on a specific EVSE inside a RequestStartTransactionRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to set a TxProfile on a specific EVSE in a RequestStartTransactionRequest message.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aRequestStartTransactionResponseWith status Accepted</td><td>1. The CSMS sends aRequestStartTransactionRequest</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest With triggerReason RemoteStarttransactionInforemoteStartId is present.</td><td>4. The CSMS responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: RequestStartTransactionRequestwith idToken.idToken<Configured valid_idtoken_idtoken>idToken.type<Configured valid_idtoken_type>idToken.idToken<Configured valid idToken>idToken.type<Configured valid idToken type>evseld<Configured evseld>chargingProfile contains:chargingProfile.chargingProfilePurpose is TxProfilechargingProfile_transactionId is omittedchargingProfile.chargingProfileKind is Relative</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 597. Test Case Id: TC_K_43_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Composite Schedule - Specific EVSE</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_43_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K08</td></tr><tr><td>Requirement(s)</td><td colspan="2">K08.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS requests a composite schedule which is a combination of local limits and the prevailing Charging Profiles of the different chargingProfilePurposes and stack levels.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to calculate request a composite schedule from the Charging Station for a specific EVSE.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a GetCompositeScheduleResponse With status Accepted schedule.evseld 1 schedule.duration is 300 schedule.chargingRateUnit <Specified chargingRateUnit from step 1> schedule.chargingSchedulePeriod[0].startPeriod 0 Note: Multiply limit by 1000 if chargingRateUnit is W schedule.chargingSchedulePeriod[0].limit 10</td><td>1. The CSMS sends a GetCompositeScheduleRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: (Message: GetCompositeScheduleRequest) evseld 1 duration is <Configured duration> chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 598. Test Case Id: TC_K_44_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Composite Schedule - Charging Station</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_44_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K08</td></tr><tr><td>Requirement(s)</td><td colspan="2">K08.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS requests a composite schedule which is a combination of local limits and the prevailing Charging Profiles of the different chargingProfilePurposes and stack levels.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to calculate request a composite schedule from the Charging Station.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a GetCompositeScheduleResponse With status Accepted schedule.evseld 0 schedule.duration is 300 schedule.chargingRateUnit <Specified chargingRateUnit from step 1> schedule.chargingSchedulePeriod[0].startPeriod 0 Note: Multiply limit by 1000 if chargingRateUnit is W schedule.chargingSchedulePeriod[0].limit 10</td><td>1. The CSMS sends a GetCompositeScheduleRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: (Message: GetCompositeScheduleRequest) evseld 0 duration is <Configured duration> chargingRateUnit <Configured chargingRateUnit></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 599. Test Case Id: TC_K_48_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set / Update External Charging Limit (not on a transaction)</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_48_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K12</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">A charging schedule or charging limit can be imposed by an external system on the Charging Station for new transactions or on the grid connection. An External Control System sends a charging limit to a Charging Station. This limit is then sent to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to receive the request from a charging station and respond correctly as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a NotifyChargingLimitRequest with
+- chargingLimit.chargingLimitSource EMS</td><td>2. The CSMS responds with a NotifyChargingLimitResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">- N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 600. Test Case Id: TC_K_50_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset / release external charging limit - Without ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_50_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K13</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">A charging schedule or charging limit can be removed by an external system on the Charging Station. An external control system sends a signal to release a previously imposed charging limit to a Charging Station. The Charging Station notifies the CSMS about this.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to receive the notify from a charging station and respond correctly as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a ClearedChargingLimitRequest with - chargingLimitSource EMS</td><td>2. The CSMS responds with a ClearedChargingLimitResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">- N/a</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 601. Test Case Id: TC_K_51_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Reset / release external charging limit - With ongoing transaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_51_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K13</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">A charging schedule or charging limit can be removed by an external system on the Charging Station. An external control system sends a signal to release a previously imposed charging limit to a Charging Station. The Charging Station notifies the CSMS about this.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to receive the notify from a charging station and respond correctly as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a ClearedChargingLimitRequest with
+- chargingLimitSource EMS</td><td>2. The CSMS responds with a
+ClearedChargingLimitResponse</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest with
+-eventType Updated
+- triggerReason ChargingRateChanged</td><td>4. The CSMS responds with a
+TransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">- N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 602. Test Case Id: TC_K_52_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set / Update External Charging Limit (not on a transaction) - ChargingStationExternalConstraints in report</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_52_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K12</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">A charging schedule or charging limit can be removed by an external system on the Charging Station. An external control system sends a signal to release a previously imposed charging limit to a Charging Station. The Charging Station notifies the CSMS about this.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to correctly receive the report when a charging limit has been externally changed in a charging station as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+GetChargingProfilesResponse with
+- status Accepted</td><td>1. The CSMS sends a GetChargingProfilesRequest</td></tr><tr><td>3. The OCTT sends a
+ReportChargingProfilesRequest with
+- requestId Generated Id
+- chargingProfile.chargingProfilePurpose
+ChargingStationExternalConstraints</td><td>4. The CSMS responds with a
+ReportChargingProfilesResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 603. Test Case Id: TC_K_53_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Charging with load leveling based on High Level Communication - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_53_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K15</td></tr><tr><td>Requirement(s)</td><td colspan="2">K15.FR.02,K15.FR.03,K15.FR.05,K15.FR.07,K15.FR.11</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">ISO15118-1 E1 AC Charging with load leveling based on High Level Communication, and E4 DC charging with load leveling based on High Level Communication.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to perform load leveling when it receives the EV charging needs from the Charging Station.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is Authorized State is EVConnectedPreSession</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Execute reusable state ISO15118SmartCharging</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">- N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 604. Test Case Id: TC_K_55_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Charging with load leveling based on High Level Communication - EV charging profile exceeds limits</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_55_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K15,K16,K17</td></tr><tr><td>Requirement(s)</td><td colspan="2">K15.FR.12,K15.FR.13,K16.FR.07,K16.FR.08,K17.FR.12,K17.FR.13</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">ISO15118-1 E1 AC Charging with load leveling based on High Level Communication, and E4 DC charging with load leveling based on High Level Communication.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to renegotiate when it receives the EV charging schedule which exceeds the profile limits.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is AuthorizedState is EVConnectedPreSession</td></tr><tr><td rowspan="8">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends aNotifyEVChargingNeedsRequest.With evseld<Configured evseld>maxScheduleTuples & chargingNeeds<Configured values from mock EV></td><td>2. The CSMS responds with aNotifyEVChargingNeedsResponse.</td></tr><tr><td>4. The OCTT responds with aSetChargingProfileResponseWith status Accepted</td><td>3. The CSMS sends a SetChargingProfileRequest</td></tr><tr><td>5. The OCTT sends aNotifyEVChargingScheduleRequest.With evseld<Configured evseld>chargingSchedule<ChargingSchedule that exceeds the limits of the chargingSchedule provided at step 3.></td><td>6. The CSMS responds with aNotifyEVChargingScheduleResponse.</td></tr><tr><td>7. The OCTT sends a TransactionEventRequest.With triggerReason ChargingStateChanged transactionInfo.chargingState Charging</td><td>8. The CSMS responds with aTransactionEventResponse.</td></tr><tr><td>10. The OCTT responds with aSetChargingProfileResponseWith status Accepted</td><td>9. The CSMS sends a SetChargingProfileRequest</td></tr><tr><td>11. The OCTT sends aNotifyEVChargingScheduleRequest.With evseld<Configured evseld>chargingSchedule<ChargingSchedule provided at step 9></td><td>12. The CSMS responds with aNotifyEVChargingScheduleResponse.</td></tr><tr><td>13. The OCTT sends a TransactionEventRequest.With triggerReason ChargingRateChanged</td><td>14. The CSMS responds with aTransactionEventResponse.</td></tr><tr><td>Test case name</td><td>Charging with load leveling based on High Level Communication - EV charging profile exceeds limits</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+(Message: NotifyEVChargingNeedsResponse)
+status Accepted
+* Step 3:
+(Message: SetChargingProfileRequest)
+evseld <Configured evseld>
+chargingProfilePurpose TxProfile
+transactionld <Provided transactionId from before>
+* Step 6:
+(Message: NotifyEVChargingScheduleResponse)
+status Rejected
+* Step 9:
+(Message: SetChargingProfileRequest)
+evseld <Configured evseld>
+chargingProfilePurpose TxProfile
+transactionld <Provided transactionId from before>
+* Step 12:
+(Message: NotifyEVChargingScheduleResponse)
+status Accepted</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 605. Test Case Id: TC_K_57_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Renegotiating a Charging Schedule - Initiated by EV</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_57_CSMS</td></tr><tr><td>Use case ld(s)</td><td colspan="2">K17</td></tr><tr><td>Requirement(s)</td><td colspan="2">K17.FR.02,K17.FR.03,K17.FR.05,K17.FR.07,K17.FR.11</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The EV signals the Charging Station that it wants to renegotiate and it provides new charging needs, which the Charging Station sends to the CSMS. Based on this and other parameters, the CSMS calculates a new charging schedule and sends it via SetChargingProfileRequest to Charging Station, which communicates it to the EV.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to renegotiate when the EV signals the Charging Station that it wants to renegotiate and it provides new charging needs, which the Charging Station sends to the CSMS.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is Authorized AND EVConnectedPreSession AND ISO15118SmartCharging</td></tr><tr><td rowspan="6">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a NotifyEVChargingNeedsRequest. With evseld<Configured evseld> maxScheduleTuples & chargingNeeds<Configured values from mock EV></td><td>2. The CSMS responds with a NotifyEVChargingNeedsResponse.</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest. With triggerReason ChargingRateChanged</td><td>4. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td>6. The OCTT responds with a SetChargingProfileResponse With status Accepted</td><td>5. The CSMS sends a SetChargingProfileRequest Note(s): - If NotifyEVChargingNeedsResponseStatus was Processing, the OCTT will wait 60 seconds for the request</td></tr><tr><td>7. The OCTT sends a NotifyEVChargingScheduleRequest. With evseld<Configured evseld> chargingSchedule<ChargingSchedule provided at step 5></td><td>8. The CSMS responds with a NotifyEVChargingScheduleResponse.</td></tr><tr><td>9. The OCTT sends a TransactionEventRequest. With triggerReason ChargingRateChanged></td><td>10. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td>Test case name</td><td>Renegotiating a Charging Schedule - Initiated by EV</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 2:
+(Message: NotifyEVChargingNeedsResponse)
+status Accepted or Processing
+* Step 5:
+(Message: SetChargingProfileRequest)
+evseld <Configured evseld>
+chargingProfilePurpose TxProfile
+transactionld <Provided transactionId from before>
+* Step 8:
+(Message: NotifyEVChargingScheduleResponse)
+status Accepted</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 606. Test Case Id: TC_K_58_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Renegotiating a Charging Schedule - Initiated by CSMS</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_58_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K16</td></tr><tr><td>Requirement(s)</td><td colspan="2">K16.FR.06</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by the EV. The CSMS calculates a ChargingSchedule to stay within limits which MAY be imposed by an external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to renegotiate power/current drawn by the EV.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is Authorized AND EVConnectedPreSession AND ISO15118SmartCharging</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetChargingProfileResponse With status Accepted</td><td>1. The CSMS sends a SetChargingProfileRequest</td></tr><tr><td>3. The OCTT sends a NotifyEVChargingScheduleRequest. With evseld <Configured evseld> chargingSchedule <ChargingSchedule provided at step 3></td><td>4. The CSMS responds with a NotifyEVChargingScheduleResponse.</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest. With triggerReason ChargingRateChanged</td><td>6. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: (Message: SetChargingProfileRequest) evseld <Configured evseld> chargingProfilePurpose TxProfile transactionId <Provided transactionId from before> * Step 4: (Message: NotifyEVChargingScheduleResponse) status Accepted</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 607. Test Case Id: TC_K_59_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Renegotiating a Charging Schedule - Initiated by CSMS - Send NotifyEVChargingNeeds</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_59_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">K16</td></tr><tr><td>Requirement(s)</td><td colspan="2">K16.FR.12</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by the EV. The CSMS calculates a ChargingSchedule to stay within limits which MAY be imposed by an external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Stations resending the charging needs of the EV.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): State is Authorized AND EVConnectedPreSession AND ISO15118SmartCharging</td></tr><tr><td rowspan="6">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetChargingProfileResponse With status Accepted</td><td>1. The CSMS sends a SetChargingProfileRequest</td></tr><tr><td>3. The OCTT sends a NotifyEVChargingNeedsRequest. With evseld <Configured evseld> maxScheduleTuples & chargingNeeds <Configured values from mock EV></td><td>4. The CSMS responds with a NotifyEVChargingNeedsResponse.</td></tr><tr><td>6. The OCTT responds with a SetChargingProfileResponse With status Accepted</td><td>5. The CSMS sends a SetChargingProfileRequest Note(s): - If NotifyEVChargingNeedsResponseStatus was Processing, the OCTT will wait 60 seconds for the request</td></tr><tr><td>7. The OCTT sends a NotifyEVChargingScheduleRequest. With evseld <Configured evseld> chargingSchedule <ChargingSchedule provided at step 3></td><td>8. The CSMS responds with a NotifyEVChargingScheduleResponse.</td></tr><tr><td>9. The OCTT sends a TransactionEventRequest. With triggerReason ChargingRateChanged</td><td>10. The CSMS responds with a TransactionEventResponse.</td></tr><tr><td>Test case name</td><td>Renegotiating a Charging Schedule - Initiated by CSMS - Send NotifyEVChargingNeeds</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+(Message: SetChargingProfileRequest)
+evseld <Configured evseld>
+chargingProfilePurpose TxProfile
+transactionld <Provided transactionId from before>
+* Step 4:
+(Message: NotifyEVChargingNeedsResponse)
+status Accepted or Processing
+* Step 5:
+(Message: SetChargingProfileRequest)
+evseld <Configured evseld>
+chargingProfilePurpose TxProfile
+transactionld <Provided transactionId from before>
+* Step 8:
+(Message: NotifyEVChargingScheduleResponse)
+status Accepted</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 608. Test Case Id: TC_K_70_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Charging Profile - Multiple Profiles</td></tr><tr><td>Test case Id</td><td colspan="2">TC_K_70_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">n/a</td></tr><tr><td>Requirement(s)</td><td colspan="2">n/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time. The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to set a charging profile with the same ProfileKind, Purpose, and limit, but with a different stackLevel.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetChargingProfileResponse with status Accepted</td><td>1. The CSMS sends a SetChargingProfileRequest with stackLevel <Configured stackLevel1></td></tr><tr><td>4. The OCTT responds with a SetChargingProfileResponse with status Accepted</td><td>3. The CSMS sends a SetChargingProfileRequest with stackLevel <Configured stackLevel2></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 3: Message SetChargingProfileRequest chargingProfile.id <different id for both chargingProfiles> chargingProfile.stackLevel <different stackLevel for both chargingProfiles></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+# 3.13. L Firmware Management
+
+Table 609. Test Case Id: TC_L_01_CSMS
+
+<table><tr><td>Test case name</td><td>Secure Firmware Update - Installation successful</td></tr><tr><td>Test case Id</td><td>TC_L_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td>L01</td></tr><tr><td>Requirement(s)</td><td>L01.FR.01,L01.FR.11,L01.FR.15</td></tr><tr><td>System under test</td><td>CSMS</td></tr><tr><td>Description</td><td>The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td>To verify if the CSMS is able to request the Charging Station to securely download and install a new firmware.</td></tr><tr><td>Prerequisite(s)</td><td>N/a</td></tr><tr><td colspan="2"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td>Configuration State:N/a</td></tr><tr><td>Memory State:N/a</td></tr><tr><td>Reusable State(s):N/a</td></tr></table>
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - Installation successful</td></tr><tr><td rowspan="10">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a UpdateFirmwareResponse With status Accepted</td><td>1. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>3. The OCTT sends a FirmwareStatusNotificationRequest. With status Downloading</td><td>4. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>5. The OCTT sends a FirmwareStatusNotificationRequest. With status Downloaded</td><td>6. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>7. The OCTT sends a FirmwareStatusNotificationRequest. With status SignatureVerified</td><td>8. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>9. The OCTT sends a FirmwareStatusNotificationRequest. With status Installing</td><td>10. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>11. The OCTT sends a FirmwareStatusNotificationRequest. With status InstallRebooting</td><td>12. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>13. The OCTT sends a BootNotificationRequest With reason FirmwareUpdate</td><td>14. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>15. The OCTT notifies the CSMS about the current state of all connectors. Message: StatusNotificationRequest connectorStatus Available Message: NotifyEventRequest trigger Delta actualValue "Available" component.name "Connector" variable.name "AvailabilityState"</td><td>16. The CSMS responds accordingly.</td></tr><tr><td>17. The OCTT sends a FirmwareStatusNotificationRequest. With status Installed</td><td>18. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message UpdateFirmwareRequest
+- firmware signingCertificate <Configured signingCertificate>
+- firmware signature <Configured signature>
+* Step 14:
+Message BootNotificationResponse
+- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 610. Test Case Id: TC_L_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - InstallScheduled</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.11,L01.FR.15</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to securely download a new firmware and install it</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS configuration firmware installDateTime needs to be set to a future dateTime.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="8">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aUpdateFirmwareResponseWith status Accepted</td><td>1. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>3. The OCTT sends aFirmwareStatusNotificationRequest.With status Downloading</td><td>4. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>5. The OCTT sends aFirmwareStatusNotificationRequest.With status Downloaded</td><td>6. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>7. The OCTT sends aFirmwareStatusNotificationRequest.With status SignatureVerified</td><td>8. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>9. The OCTT sends aFirmwareStatusNotificationRequest.With status InstallScheduled</td><td>10. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>11. The OCTT sends aFirmwareStatusNotificationRequest.With status InstallingNote(s):- This step will be executed after the giveninstallDateTime from step 1 has been reached.</td><td>12. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>13. The OCTT sends aFirmwareStatusNotificationRequest.With status InstallRebooting</td><td>14. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="3"></td><td>15. The OCTT sends a BootNotificationRequest With reason FirmwareUpdate</td><td>16. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>17. The OCTT notifies the CSMS about the current state of all connectors.
+Message: StatusNotificationRequest connectorStatus Available
+Message: NotifyEventRequest trigger Delta actualValue "Available"
+component.name "Connector"
+variable.name "AvailabilityState"</td><td>18. The CSMS responds accordingly.</td></tr><tr><td>19. The OCTT sends a FirmwareStatusNotificationRequest. With status Installed</td><td>20. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message UpdateFirmwareRequest
+-firmware.installDateTime <A dateTime in the future>
+* Step 16:
+Message BootNotificationResponse
+-status Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 611. Test Case Id: TC_L_03_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - DownloadScheduled</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_03_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.11,L01.FR.15</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to schedule securely downloading a new firmware.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS configuration firmware retrieveDateTime needs to be set to a future dateTime.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="8">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aUpdateFirmwareResponseWith status Accepted</td><td>1. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>3. The OCTT sends aFirmwareStatusNotificationRequest.With status DownloadScheduled</td><td>4. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>5. The OCTT sends aFirmwareStatusNotificationRequest.With status DownloadingNote(s):- This step will be executed after the given retrieveDateTime from step 1 has been reached.</td><td>6. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>7. The OCTT sends aFirmwareStatusNotificationRequest.With status Downloaded</td><td>8. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>9. The OCTT sends aFirmwareStatusNotificationRequest.With status SignatureVerified</td><td>10. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>11. The OCTT sends aFirmwareStatusNotificationRequest.With status Installing</td><td>12. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>13. The OCTT sends aFirmwareStatusNotificationRequest.With status InstallRebooting</td><td>14. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="3"></td><td>15. The OCTT sends a BootNotificationRequest With reason FirmwareUpdate</td><td>16. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>17. The OCTT notifies the CSMS about the current state of all connectors.
+Message: StatusNotificationRequest connectorStatus Available
+Message: NotifyEventRequest trigger Delta actualValue "Available"
+component.name "Connector"
+variable.name "AvailabilityState"</td><td>18. The CSMS responds accordingly.</td></tr><tr><td>19. The OCTT sends a FirmwareStatusNotificationRequest. With status Installed</td><td>20. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message UpdateFirmwareRequest
+-firmware.retrieveDateTime <A dateTime in the future>
+* Step 16:
+Message BootNotificationResponse
+-status Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 612. Test Case Id: TC_L_04_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - RevokedCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_04_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station reporting the firmware signing certificate is revoked.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aUpdateFirmwareResponseWith status RevokedCertificate</td><td>1. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 613. Test Case Id: TC_L_05_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - InvalidCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_05_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station reporting the firmware signing certificate is invalid.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aUpdateFirmwareResponseWith status InvalidCertificate</td><td>1. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>3. The OCTT sends aSecurityEventNotificationRequestWith type is InvalidFirmwareSigningCertificate</td><td>4. The CSMS responds with aSecurityEventNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 614. Test Case Id: TC_L_06_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - InvalidSignature</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_06_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.11</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station reporting the signature is invalid.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aUpdateFirmwareResponseWith status Accepted</td><td>1. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>3. The OCTT sends aFirmwareStatusNotificationRequest.With status Downloading</td><td>4. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>5. The OCTT sends aFirmwareStatusNotificationRequest.With status Downloaded</td><td>6. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>7. The OCTT sends aFirmwareStatusNotificationRequest.With status InvalidSignature</td><td>8. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>9. The OCTT sends aSecurityEventNotificationRequestWith type is InvalidFirmwareSignature</td><td>10. The CSMS responds with aSecurityEventNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 615. Test Case Id: TC_L_07_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - DownloadFailed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_07_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.11</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station reporting it failed to download the firmware.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aUpdateFirmwareResponseWith status Accepted</td><td>1. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>3. The OCTT sends aFirmwareStatusNotificationRequest.With status Downloading</td><td>4. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>5. The OCTT sends aFirmwareStatusNotificationRequest.With status DownloadFailed</td><td>6. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 616. Test Case Id: TC_L_08_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - InstallVerificationFailed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_08_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.11</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station reporting the verification of the firmware failed during installation.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="7">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a UpdateFirmwareResponse With status Accepted</td><td>1. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>3. The OCTT sends a FirmwareStatusNotificationRequest. With status Downloading</td><td>4. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>5. The OCTT sends a FirmwareStatusNotificationRequest. With status Downloaded</td><td>6. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>7. The OCTT sends a FirmwareStatusNotificationRequest. With status SignatureVerified</td><td>8. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>9. The OCTT sends a FirmwareStatusNotificationRequest. With status Installing</td><td>10. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>11. The OCTT sends a FirmwareStatusNotificationRequest. With status InstallVerificationFailed</td><td>12. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 617. Test Case Id: TC_L_09_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - InstallationFailed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_09_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.11</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station reporting the installation of the firmware failed.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="10">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aUpdateFirmwareResponseWith status Accepted</td><td>1. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>3. The OCTT sends aFirmwareStatusNotificationRequest.With status Downloading</td><td>4. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>5. The OCTT sends aFirmwareStatusNotificationRequest.With status Downloaded</td><td>6. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>7. The OCTT sends aFirmwareStatusNotificationRequest.With status SignatureVerified</td><td>8. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>9. The OCTT sends aFirmwareStatusNotificationRequest.With status Installing</td><td>10. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>11. The OCTT sends aFirmwareStatusNotificationRequest.With status InstallRebooting</td><td>12. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>13. The OCTT sends a BootNotificationRequestWith reason FirmwareUpdate</td><td>14. The CSMS responds with aBootNotificationResponse</td></tr><tr><td>15. The OCTT notifies the CSMS about the current state of all connectors.Message: StatusNotificationRequestconnectorStatus AvailableMessage: NotifyEventRequesttrigger DeltaactualValue "Available"component.name "Connector"variable.name "AvailabilityState"</td><td>16. The CSMS responds accordingly.</td></tr><tr><td>17. The OCTT sends aFirmwareStatusNotificationRequest.With status InstallationFailed</td><td>18. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>Test case name</td><td>Secure Firmware Update - InstallationFailed</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 14:
+Message BootNotificationResponse
+- status Accepted</td></tr><tr><td>Post scenario validations:
+N/a</td></tr></table>
+
+Table 618. Test Case Id: TC_L_10_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - AcceptedCanceled</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_10_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.11,L01.FR.24</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station reporting an ongoing installation of a firmware was canceled and it is now starting the new firmware update.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS is able to request a new firmware update, while there is already one ongoing on the Charging Station.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="9">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aUpdateFirmwareResponseWith status Accepted</td><td>1. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>3. The OCTT sends aFirmwareStatusNotificationRequest.With status Downloading</td><td>4. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>6. The OCTT responds with aUpdateFirmwareResponseWith status AcceptedCanceled</td><td>5. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>7. The OCTT sends aFirmwareStatusNotificationRequest.With status Downloading</td><td>8. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>9. The OCTT sends aFirmwareStatusNotificationRequest.With status Downloaded</td><td>10. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>11. The OCTT sends aFirmwareStatusNotificationRequest.With status SignatureVerified</td><td>12. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>13. The OCTT sends aFirmwareStatusNotificationRequest.With status Installing</td><td>14. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>15. The OCTT sends aFirmwareStatusNotificationRequest.With status InstallRebooting</td><td>16. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="3"></td><td>17. The OCTT sends a BootNotificationRequest With reason FirmwareUpdate</td><td>18. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>19. The OCTT notifies the CSMS about the current state of all connectors.
+Message: StatusNotificationRequest connectorStatus Available
+Message: NotifyEventRequest trigger Delta actualValue "Available"
+component.name "Connector"
+variable.name "AvailabilityState"</td><td>20. The CSMS responds accordingly.</td></tr><tr><td>21. The OCTT sends a FirmwareStatusNotificationRequest. With status Installed</td><td>22. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 18:
+Message BootNotificationResponse
+- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 619. Test Case Id: TC_L_11_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - Unable to cancel</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_11_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.11,L01.FR.27</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station reporting the ongoing installation of a firmware cannot be canceled.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS is able to request a new firmware update, while there is already one ongoing on the Charging Station.</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="9">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a UpdateFirmwareResponse With status Accepted</td><td>1. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>3. The OCTT sends a FirmwareStatusNotificationRequest. With status Downloading</td><td>4. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>6. The OCTT responds with a UpdateFirmwareResponse With status Rejected</td><td>5. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>7. The OCTT sends a FirmwareStatusNotificationRequest. With status Downloaded</td><td>8. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>9. The OCTT sends a FirmwareStatusNotificationRequest. With status SignatureVerified</td><td>10. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>11. The OCTT sends a FirmwareStatusNotificationRequest. With status Installing</td><td>12. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>13. The OCTT sends a FirmwareStatusNotificationRequest. With status InstallRebooting</td><td>14. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>15. The OCTT sends a BootNotificationRequest With reason FirmwareUpdate</td><td>16. The CSMS responds with a BootNotificationResponse</td></tr><tr><td rowspan="2"></td><td>17. The OCTT notifies the CSMS about the current state of all connectorsMessage: StatusNotificationRequestconnectorStatus AvailableMessage: NotifyEventRequesttrigger DeltaactualValue "Available"component.name "Connector"variable.name "AvailabilityState"</td><td>18. The CSMS responds accordingly.</td></tr><tr><td>19. The OCTT sends a FirmwareStatusNotificationRequest.With status Installed</td><td>20. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 16:Message BootNotificationResponse- status Accepted</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 620. Test Case Id: TC_L_13_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Secure Firmware Update - Unable to download/install firmware with ongoing transaction -AllowNewSessionsPendingFirmwareUpdate is false</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_13_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L01</td></tr><tr><td>Requirement(s)</td><td colspan="2">L01.FR.01,L01.FR.11</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to securely download and install a new firmware by sending an UpdateFirmwareRequest with a signingCertificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station setting connectors to Unavailable while preparing a firmware update when there is a transaction ongoing.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS is able to request a new firmware update when there is a transaction ongoing on the Charging Station.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):State is EnergyTransferStarted</td></tr><tr><td rowspan="8">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aUpdateFirmwareResponseWith status Accepted</td><td>1. The CSMS sends a UpdateFirmwareRequest</td></tr><tr><td>3. The OCTT sends aFirmwareStatusNotificationRequest.With status DownloadScheduled</td><td>4. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td>5. The OCTT notifies the CSMS about the state change of all connectors that don't have a running transaction.Message: StatusNotificationRequestconnectorStatus UnavailableMessage: NotifyEventRequesttrigger DeltaactualValue "Unavailable"component.name "Connector"variable.name "AvailabilityState"</td><td>6. The CSMS responds accordingly.</td></tr><tr><td colspan="2">7. Execute Reusable State StopAuthorizedNote(s) Wait <configured transaction duration> before executing this step</td></tr><tr><td colspan="2">8. Execute Reusable State EVConnectedPostSession</td></tr><tr><td colspan="2">9. Execute Reusable State EVDisconnected</td></tr><tr><td>10. The OCTT sends aFirmwareStatusNotificationRequest.With status DownloadingNote(s):- This step will be executed after the given retrieveDateTime from step 1 has been reached.</td><td>11. The CSMS responds with aFirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="7"></td><td>12. The OCTT sends a FirmwareStatusNotificationRequest. With status Downloaded</td><td>13. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>14. The OCTT sends a FirmwareStatusNotificationRequest. With status SignatureVerified</td><td>15. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>16. The OCTT sends a FirmwareStatusNotificationRequest. With status Installing</td><td>17. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>18. The OCTT sends a FirmwareStatusNotificationRequest. With status InstallRebooting</td><td>19. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td>20. The OCTT sends a BootNotificationRequest With reason FirmwareUpdate</td><td>21. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>22. The OCTT notifies the CSMS about the current state of all connectors. Message: StatusNotificationRequest connectorStatus Available Message: NotifyEventRequest trigger Delta actualValue "Available" component.name "Connector" variable.name "AvailabilityState"</td><td>23. The CSMS responds accordingly.</td></tr><tr><td>24. The OCTT sends a FirmwareStatusNotificationRequest. With status Installed</td><td>25. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message UpdateFirmwareRequest - firmware signingCertificate <configured signingCertificate> * Step 19: Message BootNotificationResponse - status Accepted</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 621. Test Case Id: TC_L_17_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Publish Firmware - Published</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_17_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Local Controller downloads and publishes a firmware update at the specified URL. This allows the CSMS to send UpdateFirmwareRequests with the URI pointing to the Local Controller, to any Charging Station connected to the Local Controller. This allows the site to save bandwidth and data on the WAN interface.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to publish a firmware on the local controller as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="6">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a PublishFirmwareResponse with status Accepted</td><td>1. The CSMS sends a PublishFirmwareRequest</td></tr><tr><td>3. The OCTT sends a PublishFirmwareStatusNotificationRequest with status Downloading</td><td>4. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td>5. The OCTT sends a PublishFirmwareStatusNotificationRequest with status Downloaded</td><td>6. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td>7. The OCTT sends a PublishFirmwareStatusNotificationRequest with status ChecksumVerified</td><td>8. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td>9. The OCTT sends a PublishFirmwareStatusNotificationRequest with status Published AND location <Configured firmware_location></td><td>10. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message PublishFirmwareRequest - location <Configured firmware_location></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 622. Test Case Id: TC_L_24_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Publish Firmware - Download failed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_24_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Local Controller downloads and publishes a firmware update at the specified URL. This allows the CSMS to send UpdateFirmwareRequests with the URI pointing to the Local Controller, to any Charging Station connected to the Local Controller. This allows the site to save bandwidth and data on the WAN interface.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to publish a firmware on the local controller as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a PublishFirmwareResponse with status Accepted</td><td>1. The CSMS sends a PublishFirmwareRequest</td></tr><tr><td>3. The OCTT sends a PublishFirmwareStatusNotificationRequest with status Downloading</td><td>4. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td>5. The OCTT sends a PublishFirmwareStatusNotificationRequest with status DownloadFailed</td><td>6. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message PublishFirmwareRequest - location <Configured firmware_location></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 623. Test Case Id: TC_L_19_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Publish Firmware - Invalid Checksum</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_19_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Local Controller downloads and publishes a firmware update at the specified URL. This allows the CSMS to send UpdateFirmwareRequests with the URI pointing to the Local Controller, to any Charging Station connected to the Local Controller. This allows the site to save bandwidth and data on the WAN interface.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to publish a firmware on the local controller as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="5">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a PublishFirmwareResponse with status Accepted</td><td>1. The CSMS sends a PublishFirmwareRequest</td></tr><tr><td>3. The OCTT sends a PublishFirmwareStatusNotificationRequest with status Downloading</td><td>4. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td>5. The OCTT sends a PublishFirmwareStatusNotificationRequest with status Downloaded</td><td>6. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td>7. The OCTT sends a PublishFirmwareStatusNotificationRequest with status InvalidChecksum</td><td>8. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message PublishFirmwareRequest - location <Configured firmware_location></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 624. Test Case Id: TC_L_20_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Publish Firmware - PublishFailed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_20_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Local Controller downloads and publishes a firmware update at the specified URL. This allows the CSMS to send UpdateFirmwareRequests with the URI pointing to the Local Controller, to any Charging Station connected to the Local Controller. This allows the site to save bandwidth and data on the WAN interface.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to publish a firmware on the local controller as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="6">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a PublishFirmwareResponse with status Accepted</td><td>1. The CSMS sends a PublishFirmwareRequest</td></tr><tr><td>3. The OCTT sends a PublishFirmwareStatusNotificationRequest with status Downloading</td><td>4. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td>5. The OCTT sends a PublishFirmwareStatusNotificationRequest with status Downloaded</td><td>6. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td>7. The OCTT sends a PublishFirmwareStatusNotificationRequest with status ChecksumVerified</td><td>8. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td>9. The OCTT sends a PublishFirmwareStatusNotificationRequest with status PublishFailed</td><td>10. The CSMS responds with a PublishFirmwareStatusNotificationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message PublishFirmwareRequest - location <Configured firmware_location></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 625. Test Case Id: TC_L_21_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Unpublish Firmware - Unpublished</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_21_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">Stop serving a firmware update to connected Charging Stations.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to unpublished a firmware on the local controller as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a UnpublishFirmwareResponse with status Unpublished</td><td>1. The CSMS sends a UnpublishFirmwareRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">-N/a</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 626. Test Case Id: TC_L_22_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Unpublish Firmware - NoFirmware</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_22_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">Stop serving a firmware update to connected Charging Stations.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to unpublish a firmware on the local controller as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a UnpublishFirmwareResponse with status NoFirmware</td><td>1. The CSMS sends a UnpublishFirmwareRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">-N/a</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 627. Test Case Id: TC_L_23_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Unpublish Firmware - Download Ongoing</td></tr><tr><td>Test case Id</td><td colspan="2">TC_L_23_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">L04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">Stop serving a firmware update to connected Charging Stations.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to unpublish a firmware on the local controller as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a UnpublishFirmwareResponse with status DownloadOngoing</td><td>1. The CSMS sends a UnpublishFirmwareRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">-N/a</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+# 3.14. M ISO 15118 CertificateManagement
+
+Table 628. Test Case Id: TC_M_01_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - CSMSRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request a Charging Station to install a new CSMSRootCertificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State CertificateInstalled for certificateType CSMSRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N.a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 629. Test Case Id: TC_M_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - ManufacturerRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request a Charging Station to install a new ManufacturerRootCertificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State CertificateInstalled for certificateType ManufacturerRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 630. Test Case Id: TC_M_03_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - V2GRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_03_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request a Charging Station to install a new V2GRootCertificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State CertificateInstalled for certificateType V2GRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 631. Test Case Id: TC_M_04_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - MORootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_04_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request a Charging Station to install a new MORootCertificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State CertificateInstalled for certificateType MORootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 632. Test Case Id: TC_M_05_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Install CA certificate - Failed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_05_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M05</td></tr><tr><td>Requirement(s)</td><td colspan="2">M05.FR.01,M05.FR.03</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to install new Root CA certificates using the InstallCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a Charging Station reporting it failed to install the requested certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send an InstallCertificateRequest with certificateType CSMSRootCertificate.</td></tr><tr><td>2. The OCTT responds with a InstallCertificateResponse With status is Failed</td><td>1. The CSMS sends a InstallCertificateRequest</td></tr></table>
+
+Table 633. Test Case Id: TC_M_12_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - CSMSRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_12_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message. It supports all available hash algorithms, including SHA256, SHA384, and SHA512.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to retrieve the hashData from all CSMSRootCertificates stored at the Charging Station, using all available hash algorithms, including SHA256, SHA384, and SHA512.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="4">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates for certificateType CSMSRootCertificate. The OCTT responds with data hashed with SHA256.</td></tr><tr><td colspan="2">2. Execute Reusable State GetInstalledCertificates for certificateType CSMSRootCertificate. The OCTT responds with data hashed with SHA384.</td></tr><tr><td colspan="2">3. Execute Reusable State GetInstalledCertificates for certificateType CSMSRootCertificate. The OCTT responds with data hashed with SHA512.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 634. Test Case Id: TC_M_13_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - ManufacturerRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_13_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to retrieve the hashData from all ManufacturerRootCertificate stored at the Charging Station.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates for certificateType ManufacturerRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 635. Test Case Id: TC_M_14_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - V2GRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_14_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to retrieve the hashData from all V2GRootCertificate stored at the Charging Station.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates for certificateType V2GRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 636. Test Case Id: TC_M_15_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - V2GCertificateChain</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_15_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01,M03.FR.05</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to retrieve the DATA from all certificates that are part of a V2GCertificateChain stored at the Charging Station.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates for certificateType V2GCertificateChain</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 637. Test Case Id: TC_M_16_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - MORootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_16_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to retrieve the hashData from all MORootCertificate stored at the Charging Station.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates for certificateType MORootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 638. Test Case Id: TC_M_17_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - CSMSRootCertificate & ManufacturerRootCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_17_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to retrieve the DATA from all CSMSRootCertificates and ManufacturerRootCertificate stored at the Charging Station.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. Execute Reusable State GetInstalledCertificates for certificateType CSMSRootCertificate AND ManufacturerRootCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 639. Test Case Id: TC_M_18_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - All certificateTypes</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_18_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to retrieve the hashData from all Root CA and V2GCertificateChain certificates stored at the Charging Station.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send a GetInstalledCertificatesRequest without certificateType.</td></tr><tr><td>2. The OCTT responds with aGetInstalledCertificatesResponseWith status is AcceptedcertificateDataChain contains <The hashData of all certificates stored at the OCTT truststore></td><td>1. The CSMS sends aGetInstalledCertificatesRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: GetInstalledCertificatesRequest- certificateType is omitted</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 640. Test Case Id: TC_M_19_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve certificates from Charging Station - No matching certificate found</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_19_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M03</td></tr><tr><td>Requirement(s)</td><td colspan="2">M03.FR.01,M03.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to retrieve the certificates installed at the Charging Station using the GetInstalledCertificatesRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to handle a response from the Charging Station indicating it was not able to find a certificate for the requested criteria.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send a GetInstalledCertificatesRequest with certificateTypeManufacturerRootCertificate.</td></tr><tr><td>2. The OCTT responds with aGetInstalledCertificatesResponseWith status is NotFoundcertificateHashDataChain is omitted.</td><td>1. The CSMS sends aGetInstalledCertificatesRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: GetInstalledCertificatesRequest- certificateType is ManufacturerRootCertificate</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 641. Test Case Id: TC_M_20_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Delete a certificate from a Charging Station - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_20_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M04</td></tr><tr><td>Requirement(s)</td><td colspan="2">M04.FR.01,M04.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to delete an installed certificate using the DeleteCertificateRequest message, using all available hash algorithms, including SHA256, SHA384, and SHA512.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if CSMS is able to request a Charging Station to delete an installed certificate, using all available hash algorithms, including SHA256, SHA384, and SHA512.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="6">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">1. CertificateInstalled with certificateType CSMSRootCertificate.</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to send a DeleteCertificateRequest.</td></tr><tr><td>3. The OCTT responds with aGetInstalledCertificatesResponseWith status is AcceptedcertificateDataChain contains an entry with following values: certificateDataChain[0].certificatuetype is CSMSRootCertificate certificateDataChain[0].certificatuehashAlgorithm is SHA256</td><td>2. The CSMS sends aGetInstalledCertificatesRequest</td></tr><tr><td>5. The OCTT responds with aDeleteCertificateResponseWith status is Accepted</td><td>4. The CSMS sends a DeleteCertificateRequest</td></tr><tr><td colspan="2">Note(s):- Steps 1 - 5 will be repeated for each hash algorithm (SHA256, SHA384, SHA512).</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:Message: GetInstalledCertificatesRequest-certificateType contains CSMSRootCertificate OR is omitted.* Step 4:Message: DeleteCertificateRequest-certificateData is <Returned certificateHashData at Step 3>.</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 642. Test Case Id: TC_M_21_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Delete a certificate from a Charging Station - Failed</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_21_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M04</td></tr><tr><td>Requirement(s)</td><td colspan="2">M04.FR.01,M04.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS is able to request the Charging Station to delete an installed certificate using the DeleteCertificateRequest message.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if CSMS is able to handle a Charging Station that fails to delete an installed certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):CertificateInstalled with certificateType CSMSRootCertificate.</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to send a DeleteCertificateRequest.</td></tr><tr><td>2. The OCTT responds with aGetInstalledCertificatesResponseWith status is AcceptedcertificateDataChain contains an entry with following values: certificateDataChain[0].certificatuetype is CSMSRootCertificate certificateDataChain[0].certificatueha hashAlgorithm is SHA256</td><td>1. The CSMS sends aGetInstalledCertificatesRequest</td></tr><tr><td>4. The OCTT responds with aDeleteCertificateResponseWith status is Failed</td><td>3. The CSMS sends a DeleteCertificateRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: GetInstalledCertificatesRequest-certificateType contains CSMSRootCertificate OR is omitted.* Step 3:Message: DeleteCertificateRequest-certificateData contains <Returned certificateData at Step 2>.</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 643. Test Case Id: TC_M_24_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Charging Station Certificate status - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_24_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M06</td></tr><tr><td>Requirement(s)</td><td colspan="2">M06.FR.01,M06.FR.02,M06.FR.03,M06.FR.08,M06.FR.09</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The Charging Station is able to request the CSMS to get the status of a (V2G) Charging Station certificate.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to provide the status of a requested (V2G) Charging Station certificate.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends one or more subsequentGetCertificateStatusRequestsWith ocspRequestData contains <hashes from configured (V2G) certificate chain SubCA's></td><td>2. The CSMS responds with aGetCertificateStatusResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">Step 2:Message: GetCertificateStatusResponsestatus AcceptedocspResult <OCSPResponse class as defined in IETF RFC 6960. DER encoded (as defined in IETF RFC 6960), and then base64 encoded.></td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+Table 644. Test Case Id: TC_M_26_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Certificate Installation EV - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_26_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M01</td></tr><tr><td>Requirement(s)</td><td colspan="2">M01.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The EV initiates installing a new certificate. The Charging Station forwards the request for a new certificate to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to return the Raw CertificateInstallationRes response for the EV to the Charging Station.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a Get15118EVCertificateRequest With action Install</td><td>2. The CSMS responds with a Get15118EVCertificateResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: Get15118EVCertificateResponse - status Accepted - exiResponse <Raw CertificateInstallationRes response for the EV, Base64 encoded.></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+Table 645. Test Case Id: TC_M_28_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Certificate Update EV - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_M_28_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">M02</td></tr><tr><td>Requirement(s)</td><td colspan="2">M02.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The EV initiates updating the existing certificate. The Charging Station forwards the update request to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to return the Raw CertificateInstallationRes response for the EV to the Charging Station.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a Get15118EVCertificateRequest With action Update</td><td>2. The CSMS responds with a Get15118EVCertificateResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message: Get15118EVCertificateResponse - status Accepted - exiResponse <Raw CertificateInstallationRes response for the EV, Base64 encoded.></td></tr><tr><td colspan="2">Post scenario validations: N/a</td></tr></table>
+
+# 3.15. N Diagnostics
+
+Table 646. Test Case Id: TC_N_01_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Monitoring Report - with monitoringCriteria</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N02.FR.05, N02.FR.10</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a report of monitors that match the component criteria.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports requesting a monitoring report for the component criteria and that it handles an empty result set.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">CS has implemented device model monitoring and MonitoringCtrl.Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+CSMS requests ClearVariableMonitoring ItemsPerMessage from CS.</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="7">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manually instruct CSMS to get a report of monitors for:
+- all DeltaMonitoring</td></tr><tr><td>2. OCTT responds with:
+GetMonitoringReportResponse with:
+Status EmptyResultSet</td><td>1. CSMS sends GetMonitoringReportRequest</td></tr><tr><td colspan="2">Manually instruct CSMS to get a report of monitors for:
+- all ThresholdMonitoring</td></tr><tr><td>4. OCTT responds with:
+GetMonitoringReportResponse with:
+Status Accepted</td><td>3. CSMS sends GetMonitoringReportRequest</td></tr><tr><td>5. OCTT responds with:
+NotifyMonitoringReportRequest</td><td>6. CSMS sends NotifyMonitoringReportResponse</td></tr><tr><td colspan="2">Step 5 and 6 are repeated as often as needed to report all configuration variables.</td></tr><tr><td rowspan="3">Tool validations</td><td colspan="2">* Step 1:
+Message: GetMonitoringReportRequest
+- monitoringCriteria = DeltaMonitoring</td></tr><tr><td colspan="2">* Step 3:
+Message: GetMonitoringReportRequest
+- monitoringCriteria = ThresholdMonitoring</td></tr><tr><td colspan="2">Post scenario validations:
+Check that CSMS shows the Threshold monitors.</td></tr></table>
+
+Table 647. Test Case Id: TC_N_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Monitoring Report - with component/variable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N02.FR.05, N02.FR.10</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a report of monitors that match the the given list of components and variables.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports requesting a monitoring report for a given component and variable and that it handles an empty result set.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">CS has implemented device model monitoring and MonitoringCtrl.Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:CSMS requests ClearVariableMonitoring ItemsPerMessage from CS.</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manually instruct CSMS to get a report of monitors for:- the variable Power of ChargingStation</td></tr><tr><td>2. OCTT responds with:GetMonitoringReportResponse with:Status EmptyResultSet</td><td>1. CSMS sends GetMonitoringReportRequest</td></tr><tr><td colspan="2">Manually instruct CSMS to get a report of monitors for:- the variable AvailabilityState of EVSE #1.</td></tr><tr><td>4. OCTT responds with:GetMonitoringReportResponse with:Status Accepted</td><td>3. CSMS sends GetMonitoringReportRequest</td></tr><tr><td>5. OCTT responds with:NotifyMonitoringReportRequest</td><td>6. CSMS sends NotifyMonitoringReportResponse</td></tr><tr><td colspan="2">Step 5 and 6 are repeated as often as needed to report all configuration variables.</td></tr><tr><td rowspan="3">Tool validations</td><td colspan="2">* Step 1:Message: GetMonitoringReportRequest-componentVariable[0].component.name = "ChargingStation"- componentVariable[0].variable.name = "Power"</td></tr><tr><td colspan="2">* Step 3:Message: GetMonitoringReportRequest-componentVariable[1].component.name = "EVSE"- componentVariable[1].component.evse.id = 1-componentVariable[1].variable.name = "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:Check that CSMS shows the monitor for AvailabilityState for EVSE #1.</td></tr></table>
+
+Table 648. Test Case Id: TC_N_03_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Monitoring Report - with component criteria and component/variable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_03_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N02.FR.05, N02.FR.10</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a report of monitors that match both the component criteria and the given list of components and variables.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports requesting a monitoring report for both the component criteria and a given component and variable and that it handles an empty result set.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">CS has implemented device model monitoring and MonitoringCtrl.Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:CSMS requests ClearVariableMonitoring ItemsPerMessage from CS.</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manually instruct CSMS to get a report of monitors for:- all DeltaMonitoring- and the variable AvailabilityState for EVSE #1.</td></tr><tr><td>2. OCTT responds with:GetMonitoringReportResponse with:Status EmptyResultSet</td><td>1. CSMS sends GetMonitoringReportRequest</td></tr><tr><td colspan="2">Manually instruct CSMS to get a report of monitors for:- all ThresholdMonitoring- and the variable Power of ChargingStation.</td></tr><tr><td>4. OCTT responds with:GetMonitoringReportResponse with:Status Accepted</td><td>3. CSMS sends GetMonitoringReportRequest</td></tr><tr><td>5. OCTT responds with:NotifyMonitoringReportRequest</td><td>6. CSMS sends NotifyMonitoringReportResponse</td></tr><tr><td colspan="2">Step 5 and 6 are repeated as often as needed to report all configuration variables.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: GetMonitoringReportRequest-monitoringCriteria = DeltaMonitoring-componentVariable[0].component.name = "EVSE"- componentVariable[0].component.evse.id = <configured evseld>- componentVariable[0].variable.name = "AvailabilityState"* Step 3:Message: GetMonitoringReportRequest-monitoringCriteria = ThresholdMonitoring-componentVariable[0].component.name = "ChargingStation"- componentVariable[0].variable.name = "Power"</td></tr><tr><td colspan="2">Post scenario validations:Check that CSMS shows the Threshold monitors for Power for ChargingStation.</td></tr></table>
+
+Table 649. Test Case Id: TC_N_60_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Monitoring Report - with component criteria and list of components/variables</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_60_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N02.FR.05, N02.FR.10</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS requests a report of monitors that match both the component criteria and the given list of components and variables.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports requesting a monitoring report for both the component criteria and a given list of components and optionally with variables and that it handles an empty result set.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">CS has implemented device model monitoring and MonitoringCtrl.Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:CSMS requests ClearVariableMonitoring ItemsPerMessage from CS.</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manually instruct CSMS to get a report of monitors for:- all ThresholdMonitoring- and the variable Power of both ChargingStation and EVSE #1.</td></tr><tr><td>2. OCTT responds with:GetMonitoringReportResponse with:Status EmptyResultSet</td><td>1. CSMS sends GetMonitoringReportRequest</td></tr><tr><td colspan="2">Manually instruct CSMS to get a report of monitors for:- all DeltaMonitoring- and the variable AvailabilityState of both ChargingStation and EVSE #1.</td></tr><tr><td>4. OCTT responds with:GetMonitoringReportResponse with:Status Accepted</td><td>3. CSMS sends GetMonitoringReportRequest</td></tr><tr><td>5. OCTT responds with:NotifyMonitoringReportRequest</td><td>6. CSMS sends NotifyMonitoringReportResponse</td></tr><tr><td colspan="2">Step 5 and 6 are repeated as often as needed to report all configuration variables.</td></tr><tr><td>Test case name</td><td>Get Monitoring Report - with component criteria and list of components/variables</td></tr><tr><td rowspan="2">Tool validations</td><td>* Step 1:
+Message: GetMonitoringReportRequest
+- monitoringCriteria is DeltaMonitoring
+- componentVariable[0].component.name = "ChargingStation"
+- componentVariable[0].variable.name = "AvailabilityState"
+- componentVariable[1].component.name = "EVSE"
+- componentVariable[1].component.evse.id = <configured evseld>
+- componentVariable[1].variable.name = "AvailabilityState"
+* Step 3:
+Message: GetMonitoringReportRequest
+- monitoringCriteria = ThresholdMonitoring
+- componentVariable[0].component.name = "ChargingStation"
+- componentVariable[0].variable.name = "AvailabilityState"
+- componentVariable[1].component.name = "EVSE"
+- componentVariable[1].component.evse.id = <configured evseld>
+- componentVariable[1].variable.name = "AvailabilityState"</td></tr><tr><td>Post scenario validations:
+Check that CSMS shows the Delta monitors for AvailabilityState for both ChargingStation and EVSE #1.</td></tr></table>
+
+Table 650. Test Case Id: TC_N_05_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Monitoring Base - success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_05_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N03</td></tr><tr><td>Requirement(s)</td><td colspan="2">N03.FR.03, N03.FR.04, N03.FR.05</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS sends a SetMonitoringBaseRequest for All, FactoryDefault and HardWiredOnly.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports all three monitoring base types.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">CS has implemented device model monitoring and MonitoringCtrl.Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. OCTT responds with:SetMonitoringBaseResponse</td><td>Instruct CSMS to set a monitoring base of_All_.1. CSMS sends SetMonitoringBaseRequest</td></tr><tr><td>4. OCTT responds with:SetMonitoringBaseResponse</td><td>Instruct CSMS to set a monitoring base of_FactoryDefault_.3. OCTT sends SetMonitoringBaseRequest</td></tr><tr><td>6. The OCTT responds with:SetMonitoringBaseResponse</td><td>Instruct CSMS to set a monitoring base of_HardWiredOnly_.5. OCTT sends SetMonitoringBaseRequest</td></tr><tr><td rowspan="4">Tool validations</td><td colspan="2">* Step 1Message: SetMonitoringBaseRequest-monitoringBase = All</td></tr><tr><td colspan="2">* Step 3Message: SetMonitoringBaseRequest-monitoringBase = FactoryDefault</td></tr><tr><td colspan="2">* Step 6Message: SetMonitoringBaseRequest-monitoringBase = HardWiredOnly</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 651. Test Case Id: TC_N_08_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - One SetMonitoringData element</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_08_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.01, N04.FR.02, N04.FR.17</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS sends a request to activate monitoring on one variable.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports setting monitoring on one variable.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">CS has implemented device model monitoring and MonitoringCtrl.Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:This test case activates monitoring on the following variable:- Component "EVSE", evse <Configured evseld>, variable "AvailabilityState", monitor type DeltaIt assumes, that no monitor is active on this variable prior to the test.Note 1: this is a required variable for which a monitor can be expected to exist or it can be configured.Note 2: Any other component/variable combination that supports monitoring could also be used for this testcase.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. OCTT responds with:Message: SetVariableMonitoringResponse withsetMonitoringResult[0].status = Accepted</td><td>1. Request CSMS to install monitors on:- EVSE #<Configured evseld>, AvailabilityState, Delta,severity 8</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:1. CSMS sends SetVariableMonitoringRequest with:- setMonitoringData[0].value = 1, ← recommended value for Delta monitor- setMonitoringData[0].type = Delta,- setMonitoringData[0].severity = 8,- setMonitoringData[0].component.name = "EVSE"- setMonitoringData[0].component.evse.id = <Configured evseld>- setMonitoringData[0].variable.name = "AvailabilityState"</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 652. Test Case Id: TC_N_09_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Multiple elements on different component and variable</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_09_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N04</td></tr><tr><td>Requirement(s)</td><td colspan="2">N04.FR.01, N04.FR.02, N04.FR.17</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS sends a request to activate monitors on different variables.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports setting of multiple monitors on different variables.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">CS has implemented device model monitoring and MonitoringCtrl.Enabled = true.</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:This test case activates monitors on the following variables:- Component "EVSE", evse <Configured evseld>, variable "AvailabilityState", monitor type Delta- Component "ChargingStation", variable "AvailabilityState", monitor type DeltaIt assumes, that no monitor is active on these variables prior to the test.Note 1: these are required variables for which a monitor can be expected to exist or it can be configured.Note 2: Any other component/variable combination that supports monitoring could also be used for this test case.</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. OCTT responds with:Message: SetVariableMonitoringResponse withsetMonitoringResult[0].status = Accepted</td><td>1. Request CSMS to install monitors on:- EVSE #<Configured evseld>, AvailabilityState, Delta, severity 8- ChargingStation, AvailabilityState, Delta, severity 8</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1:1. CSMS sends SetVariableMonitoringRequest with:- setMonitoringData[0].value = 1, ← recommended value for Delta monitor- setMonitoringData[0].type = Delta,- setMonitoringData[0].severity = 8,- setMonitoringData[0].component.name = "EVSE"- setMonitoringData[0].component.evse.id = <Configured evseld>- setMonitoringData[0].variable.name = "AvailabilityState"- setMonitoringDate[1].value = 1,- setMonitoringDate[1].type = Delta,- setMonitoringDate[1].severity = 8,- setMonitoringDate[1].component.name = "ChargingStation"- setMonitoringDate[1].variable.name = "AvailabilityState"Post scenario validations:N/A</td></tr></table>
+
+Table 653. Test Case Id: TC_N_16_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Monitoring Level - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_16_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N05</td></tr><tr><td>Requirement(s)</td><td colspan="2">N05.FR.01</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS sets a monitoring level.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports setting of a monitoring level.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td>Main(Test scenario)</td><td>2. OCTT responds with:SetMonitoringLevelResponse withStatus is Accepted</td><td>1. Instruct CSMS to set a monitoring level withseverity = _4</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: SetMonitoringLevelRequest with:severity = 4</td></tr><tr><td colspan="2">Post scenario validations:N/A</td></tr></table>
+
+Table 654. Test Case Id: TC_N_17_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Monitoring Level - Out of range</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_17_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N05</td></tr><tr><td>Requirement(s)</td><td colspan="2">N05.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS sets a monitoring level.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS supports the rejection of setting of a monitoring level.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The OCTT will always reject the message, but normally this would only occur if the set severity level is out of range.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td>Main (Test scenario)</td><td>2. OCTT responds with: SetMonitoringLevelResponse with Status is Rejected</td><td>1. Instruct CSMS to set a monitoring level with severity = _4</td></tr></table>
+
+Table 655. Test Case Id: TC_N_18_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Monitoring - Too many elements</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_18_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N06</td></tr><tr><td>Requirement(s)</td><td colspan="2">N06.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">CSMS is requested to clear more monitors than allowed in one request.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS does not exceed the ItemsPerMessageClearVariableMonitoring amount of monitors in one request.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">CS has implemented device model monitoring and MonitoringCtrl.Enabled = true.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: This test requests the value of ItemsPerMessageClearVariableMonitoring and then instructs the CSMS to clear (at least) one more monitor than allowed by this value. This value is 'read-only', so it cannot be manipulated in the test. As a consequence, if the Charging Station supports more monitor ids in the list, than can be set by the CSMS, then this cannot be tested.</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>2. The OCTT responds with: GetVariablesResponse</td><td>1. Instruct CSMS to send GetVariablesRequest with: Component.name MonitoringCtrl Variable.name ItemsPerMessage Variable.instance ClearVariableMonitoring.</td></tr><tr><td>4. The OCTT responds with: ClearVariableMonitoringResponse</td><td>3. Instruct CSMS to clear more monitors than allowed in ItemsPerMessage. ClearVariableMonitoringRequest with a list of ids Note: these monitor ids do not have to exist.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message: Two or more ClearVariableMonitoringRequest, so that the maximum number of ItemsPerMessageClearVariableMonitoring ids is never exceeded. OCTT will reply with a ClearVariableMonitoringResponse for each ClearVariableMonitoringRequest, but the content of the responses is irrelevant for the test.</td></tr><tr><td colspan="2">Post scenario validations: N/A</td></tr></table>
+
+Table 656. Test Case Id: TC_N_24_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Variable Monitoring - Periodic event</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_24_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N08</td></tr><tr><td>Requirement(s)</td><td colspan="2">N08.FR.02</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">Charging Station sends a periodic NotifyEventRequest.</td></tr><tr><td>Purpose</td><td colspan="2">To test that CSMS returns a NotifyEventResponse.
+Note: this is identical to TC_N_21_CSMS, only with a periodic event.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="4">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Tester makes OCTT send a NotifyEventRequest message.</td></tr><tr><td>1. OCTT sends NotifyEventRequest message.</td><td>2. CSMS returns NotifyEventResponse message.</td></tr><tr><td colspan="2">Note(s):
+- Step 1 and 2 will be repeated n times</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: NotifyEventResponse with empty body.</td></tr><tr><td colspan="2">Post scenario validations:
+N/A</td></tr></table>
+
+Table 657. Test Case Id: TC_N_25_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve Log Information - Diagnostics Log - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_25_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers the functionality of getting log information from a Charging Station. The CSMS can request a Charging Station to upload a file with log information to a given location (URL). The format of this log file is not prescribed. The Charging Station successfully uploads a log file and gives information about the status of the upload by sending status notifications to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request a charging station to successfully upload a log as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">Charging Station has log information available.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a GetLogResponse with status Accepted</td><td>1. The CSMS sends a GetLogRequest</td></tr><tr><td>3. The OCTT sends a LogStatusNotificationRequest with - status Uploading - requestId Same Id as the GetLogRequest</td><td>4. The CSMS responds with a LogStatusNotificationResponse .</td></tr><tr><td>5. The OCTT sends a LogStatusNotificationRequest with - status Uploaded - requestId Same Id as the GetLogRequest</td><td>6. The CSMS responds with a LogStatusNotificationResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetLogRequest-logType DiagnosticsLog</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 658. Test Case Id: TC_N_27_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Customer Information - Accepted + data</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_27_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N09</td></tr><tr><td>Requirement(s)</td><td colspan="2">N09.FR.01, N09.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to retrieve IdToken customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS sends the request correctly and responds on the notifies as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aCustomerInformationResponsewith status Accepted</td><td>1. The CSMS sends a CustomerInformationRequest</td></tr><tr><td>3. The OCTT sends aNotifyCustomerInformationRequest</td><td>4. The CSMS responds with aNotifyCustomerInformationResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message CustomerInformationRequest- report true-idToken.idToken <Configured valid_idtoken_idtoken> - idToken.type <Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 659. Test Case Id: TC_N_28_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Customer Information - Accepted + no data</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_28_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N09</td></tr><tr><td>Requirement(s)</td><td colspan="2">N09.FR.01, N09.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to retrieve IdToken customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS sends the request correctly and responds on the notifies as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aCustomerInformationResponsewith status Accepted</td><td>1. The CSMS sends a CustomerInformationRequest</td></tr><tr><td>3. The OCTT sends aNotifyCustomerInformationRequest</td><td>4. The CSMS responds with aNotifyCustomerInformationResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message CustomerInformationRequest- report true-idToken.idToken <Configured valid_idtoken_idtoken> - idToken.type <Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 660. Test Case Id: TC_N_29_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Customer Information - Not Accepted</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_29_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N09</td></tr><tr><td>Requirement(s)</td><td colspan="2">N09.FR.01, N09.FR.04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to retrieve IdToken customer information, but the Charging Station rejects the request.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS sends the request correctly as described at the OCPP specification, and can handle the Charging Station rejecting the request.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aCustomerInformationResponsewith status Rejected</td><td>1. The CSMS sends a CustomerInformationRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message CustomerInformationRequest-report true-idToken.idToken<Configured valid_idtoken_idtoken>-idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 661. Test Case Id: TC_N_30_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Clear and report + data</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_30_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N10.FR.08</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to clear (and retrieve) IdToken customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS sends the request correctly and responds on the notifies as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+CustomerInformationResponse
+with status Accepted</td><td>1. The CSMS sends a CustomerInformationRequest</td></tr><tr><td>3. The OCTT sends a
+NotifyCustomerInformationRequest</td><td>4. The CSMS responds with a
+NotifyCustomerInformationResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message CustomerInformationRequest
+- report true
+- clear true
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+Table 662. Test Case Id: TC_N_31_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Clear and report + no data</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_31_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N10.FR.08</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to clear (and retrieve) IdToken customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS sends the request correctly and responds on the notifies as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+CustomerInformationResponse
+with status Accepted</td><td>1. The CSMS sends a CustomerInformationRequest</td></tr><tr><td>3. The OCTT sends a
+NotifyCustomerInformationRequest</td><td>4. The CSMS responds with a
+NotifyCustomerInformationResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message CustomerInformationRequest
+- report true
+- clear true
+-idToken.idToken<Configured valid_idtoken_idtoken>
+-idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:
+-N/a</td></tr></table>
+
+Table 663. Test Case Id: TC_N_32_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Clear and no report</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_32_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N10.FR.08</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to clear IdToken customer information, for example to be compliant with local privacy laws.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS sends the request correctly.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aCustomerInformationResponsewith status Accepted</td><td>1. The CSMS sends a CustomerInformationRequest</td></tr><tr><td>3. The OCTT sends aNotifyCustomerInformationRequest</td><td>4. The CSMS responds with aNotifyCustomerInformationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message CustomerInformationRequest- report false-clear true-idToken.idToken<Configured valid_idtoken_idtoken>- idToken.type<Configured valid_idtoken_type></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 664. Test Case Id: TC_N_62_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Clear and report - customerIdentifier</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_62_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N10.FR.08</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to clear (and retrieve) raw customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS sends the request correctly and responds on the notifies as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS supports retrieving / deleting CustomerInformation - CustomerIdentifier</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+CustomerInformationResponse
+with status Accepted</td><td>1. The CSMS sends a CustomerInformationRequest</td></tr><tr><td>3. The OCTT sends a
+NotifyCustomerInformationRequest</td><td>4. The CSMS responds with a
+NotifyCustomerInformationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message CustomerInformationRequest
+- report true
+- clear true
+- customerIdentifier "OpenChargeAlliance"</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 665. Test Case Id: TC_N_63_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Clear and report - customerCertificate</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_63_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N10.FR.08</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to clear (and retrieve) a customer certificate, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS sends the request correctly and responds on the notifies as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">The CSMS supports retrieving / deleting CustomerInformation - CustomerCertificate</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+CustomerInformationResponse
+with status Accepted</td><td>1. The CSMS sends a CustomerInformationRequest
+with specific hash data <customer certificate hash data>.</td></tr><tr><td>3. The OCTT sends a
+NotifyCustomerInformationRequest</td><td>4. The CSMS responds with a
+NotifyCustomerInformationResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message CustomerInformationRequest
+- report true
+- clear true
+- customerCertificate contains <customer certificate hash data></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 666. Test Case Id: TC_N_34_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve Log Information - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_34_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers the functionality of getting log information from a Charging Station. The CSMS can request a Charging Station to upload a file with log information to a given location (URL). The format of this log file is not prescribed. The Charging Station successfully uploads a log file and gives information about the status of the upload by sending status notifications to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request a charging station to successfully upload a log as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a GetLogResponse with status Rejected</td><td>1. The CSMS sends a GetLogRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 667. Test Case Id: TC_N_35_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve Log Information - Security Log - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_35_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N01</td></tr><tr><td>Requirement(s)</td><td colspan="2"></td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers the functionality of getting log information from a Charging Station. The CSMS can request a Charging Station to upload a file with log information to a given location (URL). The format of this log file is not prescribed. The Charging Station successfully uploads a log file and gives information about the status of the upload by sending status notifications to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request a charging station to successfully upload a log as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Charging Station has log information available.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a GetLogResponse with status Accepted</td><td>1. The CSMS sends a GetLogRequest</td></tr><tr><td>3. The OCTT sends a LogStatusNotificationRequest withstatus UploadingrequestId Same Id as the GetLogRequest</td><td>4. The CSMS responds with aLogStatusNotificationResponse .</td></tr><tr><td>5. The OCTT sends a LogStatusNotificationRequest withstatus UploadedrequestId Same Id as the GetLogRequest</td><td>6. The OCTT responds with aLogStatusNotificationResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetLogRequest-logType SecurityLog</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 668. Test Case Id: TC_N_36_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Retrieve Log Information - Second Request</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_36_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N01</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case covers the functionality of getting log information from a Charging Station. The CSMS can request a Charging Station to upload a file with log information to a given location (URL). The format of this log file is not prescribed. The Charging Station successfully uploads a log file and gives information about the status of the upload by sending status notifications to the CSMS.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request a second request while the charging station is uploading a log as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:Charging Station has log information available.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="7">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a GetLogResponse with status Accepted</td><td>1. The CSMS sends a GetLogRequest</td></tr><tr><td>3. The OCTT sends a LogStatusNotificationRequest withstatus UploadingrequestId Same Id as the GetLogRequest from Step1</td><td>4. The CSMS responds with aLogStatusNotificationResponse.</td></tr><tr><td>6. The OCTT responds with a GetLogResponse with status AcceptedCanceled</td><td>5. The CSMS sends a GetLogRequest</td></tr><tr><td>7. The OCTT sends a LogStatusNotificationRequest withstatus AcceptedCanceledrequestId Same Id as the GetLogRequest from Step1</td><td>8. The CSMS responds with aLogStatusNotificationResponse.</td></tr><tr><td>9. The OCTT sends a LogStatusNotificationRequest withstatus UploadingrequestId Same Id as the GetLogRequest from Step5</td><td>10. The CSMS responds with aLogStatusNotificationResponse.</td></tr><tr><td>11. The OCTT sends aLogStatusNotificationRequest withstatus UploadedrequestId Same Id as the GetLogRequest from Step5</td><td>12. The CSMS responds with aLogStatusNotificationResponse.</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 669. Test Case Id: TC_N_44_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Monitoring - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_44_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N06</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">A monitoring setting can be cleared (removed) by sending a ClearVariableMonitoringRequest with the id of the monitoring setting.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to correctly read the respond from a charging station on a request to clear a monitor that cannot be cleared as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+ClearVariableMonitoringResponse with
+clearMonitoringResult[0].status Rejected</td><td>1. The CSMS sends a
+ClearVariableMonitoringRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 670. Test Case Id: TC_N_46_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Customer Information - Update Local Authorization List</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_46_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N10</td></tr><tr><td>Requirement(s)</td><td colspan="2">N10.FR.02, N10.FR.08, D01.FR.01, D01.FR.06, D01.FR.18,</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The CSMS sends a message to the Charging Station to clear (and retrieve) raw customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS updates the local authorization list when custumor information, which was present in the local authorization list, has been removed as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A local authorization list with<Configured customerIdentifier> is configured.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aCustomerInformationResponsewith status Accepted</td><td>1. The CSMS sends a CustomerInformationRequest</td></tr><tr><td>3. The OCTT sends aNotifyCustomerInformationRequest</td><td>4. The CSMS responds with aNotifyCustomerInformationResponse .</td></tr><tr><td>6 The OCTT responds with aSendLocalListResponse withstatus Accepted</td><td>5. The CSMS sends a SendLocalListRequest</td></tr><tr><td colspan="2">Note(s): If the Local Authorization List is too big for one message, step 5 and 6 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message CustomerInformationRequest- report true AND-clear true AND-idToken.idToken<Configured valid_idtoken_idtoken>- idToken.type<Configured valid_idtoken_type>* Step 5:Message SendLocalListRequest-updateType Differential-versionNumber<Bigger than currently configured in OCTT>-localAuthorizationList<Not empty></td></tr><tr><td colspan="2">Post scenario validations:- All messages have been received</td></tr></table>
+
+Table 671. Test Case Id: TC_N_47_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get Monitoring report - Report all</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_47_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N02</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS requests the Charging Station to send a report about configured monitoring settings per component and variable. Optionally, this list can be filtered on monitoringCriteria and componentVariables.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a get monitor request omitting the monitoringCriteria and componentVariable as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aGetMonitoringReportResponse</td><td>1. The CSMS sends a GetMonitoringReportRequest</td></tr><tr><td>3. The OCTT sends aNotifyMonitoringReportRequest</td><td>4. The CSMS responds with aNotifyMonitoringReportResponse .</td></tr><tr><td colspan="2">Note(s):- If tbc is True at Step 3 then step 3 and 4 will be repeated</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetMonitoringReportRequest-monitoringCriteria omitted AND-componentVariable omitted.</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 672. Test Case Id: TC_N_48_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Alert Event - Variable monitoring on write only</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_48_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to read a request from a trigger from a variablemonitor which is write only as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a NotifyEventRequest with eventData的实际Value empty</td><td>2. The CSMS responds with a NotifyEventResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 673. Test Case Id: TC_N_49_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Alert Event - LowerThreshold/UpperThreshold cleared after reboot</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_49_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to read a request when a trigger is cleared after a reboot as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a NotifyEventRequest with eventData.cleared true</td><td>2. The CSMS responds with a NotifyEventResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 674. Test Case Id: TC_N_50_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Alert Event - Periodic Triggered</td></tr><tr><td>Test case Id</td><td colspan="2">TC_N_50_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N07</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to read a request when a trigger reason is periodic after a reboot as described at the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">n/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a NotifyEventRequest with eventData_trigger Periodic</td><td>2. The CSMS responds with a NotifyEventResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+# 3.16. O Display Message
+
+Table 675. Test Case Id: TC_0_01_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_01_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_04</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send the request according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to send a SetDisplayMessageRequest.</td></tr><tr><td>2. The OCTT responds with a SetDisplayMessageResponse with:status Accepted</td><td>1. The CSMS sends a SetDisplayMessageRequest with:state <Configured display message state></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetDisplayMessageRequest-message.id <Generated Id>- messagepriority <Configured Priority>- message.message.format <Configured Format>- message.state <Configured State></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 676. Test Case Id: TC_O_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get all Display Messages - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">003</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request all the installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send the request to get the DisplayMessages according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+A display message is configured.</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+GetDisplayMessagesResponse with
+status Accepted</td><td>1. The CSMS sends a GetDisplayMessagesRequest</td></tr><tr><td>3. The OCTT sends a
+NotifyDisplayMessagesRequest</td><td>4. The CSMS responds with a
+NotifyDisplayMessagesResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message GetDisplayMessagesRequest
+- requestId <Generated Id>
+- id <Omitted>
+- priority <Omitted>
+- state <Omitted></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 677. Test Case Id: TC_O_03_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get all Display Messages - No DisplayMessages configured</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_03_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">003</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request all the installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS can request to get all display messages according to the DisplayMessage mechanism as described in the OCPP specification when no messages are configured.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+GetDisplayMessagesResponse with
+status Unknown</td><td>1. The CSMS sends a GetDisplayMessagesRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message GetDisplayMessagesRequest
+- requestId <Generated request id></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 678. Test Case Id: TC_O_04_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Display Message - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_04_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">005</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can remove a specific message, configured via OCPP in a Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to clear a message according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: A display message is configured.</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Note: As a help method, a GetDisplayMessagesRequest is requested first for CSMS's that implemented their ClearDisplayMessage as a combined feature.</td></tr><tr><td>2. The OCTT responds with a ClearDisplayMessageResponse with status Accepted</td><td>1. The CSMS sends a ClearDisplayMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1: Message ClearDisplayMessageRequest - id <Generated Id from set display message></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 679. Test Case Id: TC_0_05_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Clear Display Message - Unknown Key</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_05_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">O05</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can remove a specific message, configured via OCPP in a Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request the Charging Station to clear a message according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">If the CSMS supports sending a ClearDisplayMessageRequest with an unknown id.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a ClearDisplayMessageResponse with status Unknown</td><td>1. The CSMS sends a ClearDisplayMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 680. Test Case Id: TC_0_06_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Specific transaction - Success</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_06_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">002</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can set a message to be displayed on a Charging Station for a specific transaction. Depending on the given parameters the message shall be displayed a certain way on the Charging Station.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a display message correctly according the mechanism as described in the OCPP specification for a specific transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:State is EnergyTransferStarted</td></tr><tr><td rowspan="4">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to send a display message for a specific transaction.</td></tr><tr><td>2. The OCTT responds with a SetDisplayMessageResponse with status Accepted</td><td>1. The CSMS sends a SetDisplayMessageRequest</td></tr><tr><td colspan="2">3. Execute Reusable State EVDisconnected</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetDisplayMessageRequest-message_transactionId Same ID as previously returned by the Charging Station AND-messagepriority<Configured Priority></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 681. Test Case Id: TC_O_07_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get a Specific Display Message - Id</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_07_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">004</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request specific installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request a specific id message from the charging station according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A display message is configured.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aGetDisplayMessagesResponse withstatus Accepted</td><td>1. The CSMS sends a GetDisplayMessagesRequest</td></tr><tr><td>3. The OCTT sends aNotifyDisplayMessagesRequest</td><td>4. The CSMS responds with aNotifyDisplayMessagesResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetDisplayMessagesRequest-id<Configured_Id> -priority<Umitted> -state<Umitted> -requestId<Generated Id></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 682. Test Case Id: TC_O_08_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get a Specific Display Message - Priority</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_08_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">004</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request specific installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request specific priority messages from the charging station according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A message with <Configured_Priority> is configured</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aGetDisplayMessagesResponse withstatus Accepted</td><td>1. The CSMS sends a GetDisplayMessagesRequest</td></tr><tr><td>3. The OCTT sends aNotifyDisplayMessagesRequest</td><td>4. The CSMS responds with aNotifyDisplayMessagesResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetDisplayMessagesRequest-priority-id-omitted-state-requestIdGenerated Id></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 683. Test Case Id: TC_O_09_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get a Specific Display Message - State</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_09_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">004</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request specific installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request specific state messages from the charging station according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A message with <Configured_State> is configured</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aGetDisplayMessagesResponse withstatus Accepted</td><td>1. The CSMS sends a GetDisplayMessagesRequest</td></tr><tr><td>3. The OCTT sends aNotifyDisplayMessagesRequest</td><td>4. The CSMS responds with aNotifyDisplayMessagesResponse .</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetDisplayMessagesRequest-state <Configured_State>- priority <Omitted>- id <Omitted>- requestedId <Generated Id></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 684. Test Case Id: TC_0_10_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Specific transaction - UnknownTransaction</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_10_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">002</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSMS can attempt to set a DisplayMessage for a transactionId that the CS does not know. The CS will respond with a SetDisplayMessageResponse status of UnknownTransaction.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a display message correctly according the mechanism as described in the OCPP specification for a specific transaction.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">If the CSMS supports sending a SetDisplayMessageRequest with a transactionId for a transaction that does not exist.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:State is EnergyTransferStarted</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to send a display message for a specific transaction.</td></tr><tr><td>2. The OCTT responds with aSetDisplayMessageResponse withstatus UnknownTransaction</td><td>1. The CSMS sends a SetDisplayMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetDisplayMessageRequest-message transactionId not omit AND-messagepriority<Configured Priority></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 685. Test Case Id: TC_O_11_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Get a Specific Display Message - Unknown parameters</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_11_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">004</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can request specific installed DisplayMessages configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request a specific id message from the charging station according to the mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">If the CSMS is able to send a GetDisplayMessage with an unknown id.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:A display message is configured.</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aGetDisplayMessagesResponse withstatus Unknown</td><td>1. The CSMS sends a GetDisplayMessagesRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message GetDisplayMessagesRequest-id<Adifferent generated Id>-requestId<Generated Id></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 686. Test Case Id: TC_0_12_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Replace DisplayMessage</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_12_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">006</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how a CSO can replace a DisplayMessage that is previously configured in a Charging Station. Replace the message content, but also all the given parameters with the new one.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to request to replace a display message according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: A display message is configured.</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="3">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: - Request the CSMS to sent a display message with the same id as already configured one</td></tr><tr><td>2. The OCTT responds with a SetDisplayMessageResponse with status Accepted</td><td>1. The CSMS sends a SetDisplayMessageRequest with: message.id <Configured_Id> messagepriority <Configured Priority></td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2: Message SetDisplayMessageRequest - message.id <Configured_Id> - messagepriority <Configured Priority></td></tr><tr><td colspan="2">Post scenario validations: - N/a</td></tr></table>
+
+Table 687. Test Case Id: TC_0_13_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Display message at StartTime</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_13_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_05</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send the request with aStartTime according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to send a SetDisplayMessageRequest with aStartTime.</td></tr><tr><td>2. The OCTT responds with aSetDisplayMessageResponse withstatus Accepted</td><td>1. The CSMS sends a SetDisplayMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetDisplayMessageRequest-message.id<Generated Id>- message.startDateTime<Configured startDateTime></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 688. Test Case Id: TC_0_14_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Remove message after EndTime</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_14_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">001_FR_05</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send the request with a endTime according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to send a SetDisplayMessageRequest with a endTime.</td></tr><tr><td>2. The OCTT responds with aSetDisplayMessageResponse withstatus Accepted</td><td>1. The CSMS sends a SetDisplayMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetDisplayMessageRequest-message.id<Generated Id>- message.endDateTime<Configured endDateTime></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 689. Test Case Id: TC_0_17_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - NotSupportedPriority</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_17_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a display message with a specific priority, on which the Charging station responds not supported, according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetDisplayMessageResponse with status NotSupportedPriority</td><td>1. The CSMS sends a SetDisplayMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetDisplayMessageRequest-message.id<Generated Id>- messagepriority<Configured priority></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 690. Test Case Id: TC_O_18_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - NotSupportedState</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_18_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a display message with a specific state, on which the Charging station responds not supported, according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetDisplayMessageResponse with status NotSupportedState</td><td>1. The CSMS sends a SetDisplayMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message SetDisplayMessageRequest
+- message.id <Generated Id>
+- message.state <Configured state></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 691. Test Case Id: TC_O_19_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - NotSupportedMessageFormat</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_19_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a display message with a specific MessageFormat, on which the Charging station responds not supported, according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Charging State: N/a</td></tr><tr><td rowspan="2">Main (Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a SetDisplayMessageResponse with status NotSupportedMessageFormat</td><td>1. The CSMS sends a SetDisplayMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message SetDisplayMessageRequest
+- message.id <Generated Id></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 692. Test Case Id: TC_0_25_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Send Specific state</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_25_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send a display messages with a "Charging" state according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Charging State:N/a</td></tr><tr><td rowspan="2">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with aSetDisplayMessageResponse withstatus Accepted</td><td>1. The CSMS sends a SetDisplayMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message SetDisplayMessageRequest-message.id<Configured_Id> - message.state<Configured State></td></tr><tr><td colspan="2">Post scenario validations:- N/a</td></tr></table>
+
+Table 693. Test Case Id: TC_0_26_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Rejected</td></tr><tr><td>Test case Id</td><td colspan="2">TC_0_26_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">001</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send the request according to the DisplayMessage mechanism as described in the OCPP specification which gets rejected.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="3">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to send a SetDisplayMessageRequest with a Normal Cycle priority.</td></tr><tr><td>2. The OCTT responds with a
+SetDisplayMessageResponse with
+status Rejected</td><td>1. The CSMS sends a SetDisplayMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message SetDisplayMessageRequest
+- message.id <Generated Id>
+- message.priority <Configured Priority></td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 694. Test Case Id: TC_0_27_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Specific transaction - Display message at StartTime</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_27_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">002</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send the request with astartTime for a specific transaction according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a1</td></tr><tr><td colspan="2">Charging State:
+State is EnergyTransferStarted</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+SetDisplayMessageResponse with
+status Accepted</td><td>1. The CSMS sends a SetDisplayMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message SetDisplayMessageRequest
+- message.id <Generated Id>
+- message.startDateTime <Configured startDateTime>
+- message_transactionId is present</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+Table 695. Test Case Id: TC_O_28_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Set Display Message - Specific transaction - Remove message after EndTime</td></tr><tr><td>Test case Id</td><td colspan="2">TC_O_28_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">002</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This test case describes how the CSMS can be requested to send an SetDisplayMessageRequest to the charging station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station. These messages are displayed additionally on a Charging Station and are not part of the firmware.</td></tr><tr><td>Purpose</td><td colspan="2">To verify if the CSMS is able to send the request with a endTime for a specific transaction according to the DisplayMessage mechanism as described in the OCPP specification.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Charging State:
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>2. The OCTT responds with a
+SetDisplayMessageResponse with
+status Accepted</td><td>1. The CSMS sends a SetDisplayMessageRequest</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:
+Message SetDisplayMessageRequest
+- message.id <Generated Id>
+- messagepriority <Configured Priority>
+- message.endDateTime <Configured endDateTime>
+- message.state <Configured State>
+- message_transactionId is present</td></tr><tr><td colspan="2">Post scenario validations:
+- N/a</td></tr></table>
+
+# 3.17. P DataTransfer
+
+Table 696. Test Case Id: TC_P_02_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">Data Transfer to the CSMS - Rejected / Unknown VendorId / Unknown MessageId</td></tr><tr><td>Test case Id</td><td colspan="2">TC_P_02_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">P02</td></tr><tr><td>Requirement(s)</td><td colspan="2">P02.FR.06, P02.FR.07</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The DataTransfer message to send information for functions that are not supported by OCPP.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to handle receiving a DataTransferRequest, even if it does not support any vendor-specific implementations.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+N/a</td></tr><tr><td rowspan="2">Main
+(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a DataTransferRequest with vendorId <Configured vendorId>
+messageId <Configured messageId></td><td>2. The CSMS responds with a DataTransferResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 2:
+Message: DataTransferResponse
+- status must be UnknownVendorId OR UnknownMessageId OR Rejected (Rejected will also be allowed, because there are implementers that like to just reject the message when the Charging Station does not support any vendor-specific features.</td></tr><tr><td colspan="2">Post scenario validations:
+N/a</td></tr></table>
+
+Table 697. Test Case Id: TC_P_03_CSMS
+
+<table><tr><td>Test case name</td><td colspan="2">CustomData - Receive custom data</td></tr><tr><td>Test case Id</td><td colspan="2">TC_P_03_CSMS</td></tr><tr><td>Use case Id(s)</td><td colspan="2">N/a</td></tr><tr><td>Requirement(s)</td><td colspan="2">N/a</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">Checks if the CSMS is able to receive custom data.</td></tr><tr><td>Purpose</td><td colspan="2">To verify whether the CSMS is able to handle receiving custom data.</td></tr><tr><td>Prerequisite(s)</td><td colspan="2">N/a</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a StatusNotificationRequest withcustomData <customData></td><td>2. The CSMS responds with aStatusNotificationResponse</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest withcustomData customData transactionInfo(customData <customData></td><td>4. The CSMS responds with aTransactionEventResponse</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">N/a</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
+
+# 3.18. Reusable states
+
+Testcases can refer to a reusable state at the before or main stage. The steps described at the reusable state will be executed and then it will return to the testcase that called the reusable state.
+
+Table 698. Reusable State: Booted
+
+<table><tr><td>State</td><td colspan="2">Booted</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This state will simulate that the Charging Station is completely power cycled. The OCTT end in a state where it is "booted" back up and is in idle mode.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a BootNotificationRequest with reason PowerUp chargingStation.model<Configured model>chargingStation.vendorName<Configured vendorName></td><td>2. The CSMS responds with a BootNotificationResponse</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of all connectors.Message: StatusNotificationRequest with connectorStatus AvailableMessage: NotifyEventRequest with trigger Delta actualValue "Available" component.name "Connector" variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:Message: BootNotificationResponse- status Accepted</td></tr><tr><td>Post condition</td><td colspan="2">State is Booted</td></tr></table>
+
+Table 699. Reusable State: Reserved
+
+<table><tr><td>State</td><td colspan="2">Reserved</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This state will simulate a reservation for a specified evse.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send a ReserveNowRequest for specific EVSE.</td></tr><tr><td>2. The OCTT responds with a ReserveNowResponseWith status Accepted</td><td>1. The CSMS sends a ReserveNowRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the currentstate of the connector(s) of the Specified EVSEMessage: StatusNotificationRequestwith connectorStatus ReservedMessage: NotifyEventRequestwith trigger DeltaactualValue "Reserved"component.name "Connector"variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1:Message: ReserveNowRequest- evseld must be <Specified evseld>- connectorType must be omitted-idToken.idToken <Configured valid_idtoken_idtoken>- idToken.type <Configured valid_idtoken_type></td></tr><tr><td>Post condition</td><td colspan="2">State is Reserved</td></tr></table>
+
+Table 700. Reusable State: Unavailable
+
+<table><tr><td>State</td><td colspan="2">Unavailable</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This state will simulate that Charging Station / EVSEs / connectors are set to AvailabilityState Unavailable.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="4">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to change the availability of the specified components to Inoperative.</td></tr><tr><td>2. The OCTT responds with a ChangeAvailabilityResponse with status Accepted</td><td>1. The CSMS sends a ChangeAvailabilityRequest</td></tr><tr><td>3. The OCTT notifies the CSMS about the current state of all connectors belonging to the specified EVSE (and optionally also from the EVSE itself). Message: StatusNotificationRequest - connectorStatus Unavailable Message: NotifyEventRequest - trigger Delta -actualValue "Unavailable" - component.name "ChargingStation" / EVSE / Connector - variable.name "AvailabilityState"</td><td>4. The CSMS responds accordingly.</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1:Message ChangeAvailabilityRequest - operationalStatus Inoperative - evse <Specified evseld> - connectorId omitted</td></tr><tr><td>Post condition</td><td colspan="2">State is Unavailable</td></tr></table>
+
+Table 701. Reusable State: EVConnectedPreSession
+
+<table><tr><td>State</td><td colspan="2">EVConnectedPreSession</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This state will simulate that the EV and EVSE of the simulated Charging Station are connected.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT notifies the CSMS about the status change of the connectorMessage: StatusNotificationRequest- connectorStatus is OccupiedMessage: NotifyEventRequest- trigger is Delta- actualValue is Occupied- component.name is Connector- variable.name is AvailabilityState</td><td>2. The CSMS responds accordingly.</td></tr><tr><td>3. The OCTT sends a TransactionEventRequestWith triggerReason is CablePluggedIntransactionInfo.chargingState is EVConnectedevse.id<Configured evseld>evseconnectorId<Configured connectorId>If State is Authorized theneventType is UpdatedelseeventType is Started</td><td>4. The CSMS responds with aTransactionResponse</td></tr><tr><td>Tool validations</td><td colspan="2">N/a</td></tr><tr><td>Post condition</td><td colspan="2">State is EVConnectedPreSession</td></tr></table>
+
+Table 702. Reusable State: Authorized
+
+<table><tr><td>State</td><td colspan="2">Authorized</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This state will simulate that the EV Driver is locally authorizing to start a transaction on the simulated Charging Station.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends an AuthorizationRequest With idToken.idToken <Configured valid_idtoken_idtoken> idToken.type <Configured valid_idtoken_type></td><td>2. The CSMS responds with an AuthorizationResponse</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest With triggerReason is Authorized idToken.idToken <Configured valid_idtoken_idtoken> idToken.type <Configured valid_idtoken_type> If State is EVConnectedPreSession then eventType is Updated else eventType is Started</td><td>4. The CSMS responds with a TransactionEventResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2: Message: AuthorizationResponse - idTokenInfo.status must be Accepted * Step 4: Message: TransactionEventResponse - idTokenInfo.status must be Accepted</td></tr><tr><td>Post condition</td><td colspan="2">State is Authorized</td></tr></table>
+
+Table 703. Reusable State: EnergyTransferStarted
+
+<table><tr><td>State</td><td colspan="2">EnergyTransferStarted</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This state will simulate that there is transferring energy between the EV and EVSE of the simulated Charging Station.</td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): If State is NOT Authorized then execute Reusable State Authorized If EVConnected is true, then proceed to part 2 Else proceed to part 1.</td></tr><tr><td rowspan="8">Main (Part 1) (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT notifies the CSMS about the status change of the connector.</td><td>2. The CSMS responds accordingly.</td></tr><tr><td>Message: StatusNotificationRequest - connectorStatus is Occupied</td><td rowspan="5">2. The CSMS responds accordingly.</td></tr><tr><td>Message: NotifyEventRequest - trigger is Delta</td></tr><tr><td>- actualValue is Occupied</td></tr><tr><td>- component.name is Connector</td></tr><tr><td>- variable.name is AvailabilityState</td></tr><tr><td>3. The OCTT sends a TransactionEventRequest With triggerReason is CablePluggedIn transactionInfo.chargingState is EVConnected evse.id <Configured evseld> evseconnectorId <Configured connectorId> eventType is Updated</td><td>4. The CSMS responds with a TransactionEventResponse</td></tr><tr><td>Tool validations</td><td colspan="2">N/a</td></tr><tr><td rowspan="2">Main (Part 2) (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>5. The OCTT sends a TransactionEventRequest With triggerReason is ChargingStateChanged transactionInfo.chargingState is Charging eventType is Updated</td><td>6. The CSMS responds with a TransactionEventResponse</td></tr><tr><td>Tool validations</td><td colspan="2">N/a</td></tr><tr><td>Post condition</td><td colspan="2">State is EnergyTransferStarted EVConnected is true</td></tr></table>
+
+Table 704. Reusable State: EnergyTransferSuspended
+
+<table><tr><td>State</td><td colspan="2">EnergyTransferSuspended</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This state will simulate that the Charging Station is in a state where the energy transfer is suspended by the EV.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+If State is NOT EnergyTransferStarted then execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="3">Main
+(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Notes(s): The tool will wait for <Configured Transaction Duration> seconds</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest
+With triggerReason is ChargingStateChanged
+transactionInfo.chargingState is SuspendedEV</td><td>2. The CSMS responds with a
+TransactionEventResponse</td></tr><tr><td>Tool validations</td><td colspan="2">N/a</td></tr><tr><td>Post condition</td><td colspan="2">State is EnergyTransferSuspended</td></tr></table>
+
+Table 705. Reusable State: StopAuthorized
+
+<table><tr><td>State</td><td colspan="2">StopAuthorized</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This state will simulate that the Charging Station is in a state where the charging session is authorized to stop.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before
+(Preparations)</td><td colspan="2">Configuration State:
+N/a</td></tr><tr><td colspan="2">Memory State:
+N/a</td></tr><tr><td colspan="2">Reusable State(s):
+If State is NOT EnergyTransferStarted then execute Reusable State EnergyTransferStarted</td></tr><tr><td rowspan="3">Main
+(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Notes(s): The tool will wait for <Configured Transaction Duration> seconds</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest
+With triggerReason is StopAuthorized
+eventType is Updated</td><td>2. The CSMS responds with a
+TransactionEventResponse</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 2:
+Message: TransactionEventResponse
+- idTokenInfo.status must be Accepted</td></tr><tr><td>Post condition</td><td colspan="2">State is StopAuthorized</td></tr></table>
+
+Table 706. Reusable State: EVConnectedPostSession
+
+<table><tr><td>State</td><td colspan="2">EVConnectedPostSession</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This state will simulate that the Charging Station is in a state where the energy transfer has been stopped and the transaction is NOT authorized to resume energy transfer without re-authorization.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): If State is NOT StopAuthorized then execute Reusable State StopAuthorized</td></tr><tr><td rowspan="2">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends a TransactionEventRequest With triggerReason is ChargingStateChanged transactionInfo.chargingState is EVConnected eventType is Updated</td><td>2. The CSMS responds with a TransactionResponse</td></tr><tr><td>Tool validations</td><td colspan="2">N/a</td></tr><tr><td>Post condition</td><td colspan="2">State is EVConnectedPostSession</td></tr></table>
+
+Table 707. Reusable State: EVDisconnected
+
+<table><tr><td>State</td><td colspan="2">EVDisconnected</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">This state will simulate that the EV and EVSE of the simulated Charging Station are disconnected, after the charging session is authorized to stop.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):If State is NOT EVConnectedPostSession then execute Reusable State EVConnectedPostSession</td></tr><tr><td rowspan="3">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT notifies the CSMS about the status change of the connector.Message: StatusNotificationRequest- connectorStatus is AvailableMessage: NotifyEventRequest- trigger is Delta- actualValue is Available- component.name is Connector- variable.name is AvailabilityState</td><td>2. The CSMS responds accordingly.</td></tr><tr><td>3. The OCTT sends a TransactionEventRequestWith triggerReason is EVCommunicationLost transactionInfo.chargingState is Idle transactionInfo.stoppedReason is EVDisconnected eventType is Ended</td><td>4. The CSMS responds with a TransactionResponse</td></tr><tr><td>Tool validations</td><td colspan="2">N/a</td></tr><tr><td>Post condition</td><td colspan="2">State is EVDisconnected</td></tr></table>
+
+Table 708. Reusable State: GetInstalledCertificates
+
+<table><tr><td>State</td><td colspan="2">GetInstalledCertificates</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The DATA from installed certificates of the specified type will be retrieved from the Charging Station</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before (Preparations)</td><td colspan="2">Configuration State: N/a</td></tr><tr><td colspan="2">Memory State: N/a</td></tr><tr><td colspan="2">Reusable State(s): N/a</td></tr><tr><td rowspan="3">Main (Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send a GetInstalledCertificatesRequest with certificateType <Specified certificateType></td></tr><tr><td>2. The OCTT responds with a GetInstalledCertificatesResponse With status is Accepted certificateDataChain contains an entry with following values: certificateDataChain[0].certificatetype is <Specified certificateType> certificateDataChain[0].certificatethData contains <Data from the configured certificate of the specified certificateType></td><td>1. The CSMS sends a GetInstalledCertificatesRequest</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1: Message: GetInstalledCertificatesRequest - certificateType must be <Specified certificateType></td></tr><tr><td>Post condition</td><td colspan="2">Certificate of the specified certificateType is retrieved from the Charging Station.</td></tr></table>
+
+Table 709. Reusable State: CertificateInstalled
+
+<table><tr><td>State</td><td colspan="2">CertificateInstalled</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">A pre configured certificate of the specified certificateType will be installed.</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="3">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Trigger the CSMS to send an InstallCertificateRequest with certificateType <Specified certificateType></td></tr><tr><td>2. The OCTT responds with aInstallCertificateResponseWith status is Accepted</td><td>1. The CSMS sends a InstallCertificateRequest</td></tr><tr><td>Tool validations</td><td colspan="2">* Step 1:Message: InstallCertificateRequest-certificateType must be <Specified certificateType>- certificate must be <The configured certificate of the specified certificateType>.</td></tr><tr><td>Post condition</td><td colspan="2">Certificate of the specified certificateType is stored at the Charging Station.</td></tr></table>
+
+Table 710. Reusable State: ISO15118SmartCharging
+
+<table><tr><td>State</td><td colspan="2">ISO15118SmartCharging</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="5">Main(Scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td>1. The OCTT sends aNotifyEVChargingNeedsRequest withevseld<Configured evseld>maxScheduleTuples & chargingNeeds<Configuredvalues from mock EV>+</td><td>2. The CSMS responds with aNotifyEVChargingNeedsResponse.</td></tr><tr><td>4. The OCTT responds with aSetChargingProfileResponse with:status Accepted</td><td>3. The CSMS sends a SetChargingProfileRequestNote(s):- If NotifyEVChargingNeedsResponseStatus wasProcessing, the OCTT will wait 60 seconds for therequest</td></tr><tr><td>5. The OCTT sends aNotifyEVChargingScheduleRequest withevseld<Configured evseld>chargingSchedule<ChargingSchedule provided atstep 3></td><td>6. The CSMS responds with aNotifyEVChargingScheduleResponse.</td></tr><tr><td>7. The OCTT sends a TransactionEventRequest withtriggerReason<ChargingStateChanged>transactionInfo.chargingState<Charging></td><td>8. The CSMS responds with aTransactionEventResponse.</td></tr><tr><td>State</td><td>ISO15118SmartCharging</td></tr><tr><td>Tool validations</td><td>* Step 2:
+Message: NotifyEVChargingNeedsResponse
+- Status Accepted or Processing
+* Step 3:
+Message: SetChargingProfileRequest
+- chargingProfilePurpose <TxProfile>
+- transactionId <Provided transactionId from before>
+* Step 4:
+Message: NotifyEVChargingScheduleResponse
+- status <Accepted></td></tr><tr><td>Post condition</td><td>N/a</td></tr></table>
+
+Table 711. Memory State: RenewChargingStationCertificate
+
+<table><tr><td>State</td><td colspan="2">RenewChargingStationCertificate</td></tr><tr><td>System under test</td><td colspan="2">CSMS</td></tr><tr><td>Description</td><td colspan="2">The ChargingStationCertificate is renewed using A02/A03</td></tr><tr><td colspan="3"></td></tr><tr><td rowspan="3">Before(Preparations)</td><td colspan="2">Configuration State:N/a</td></tr><tr><td colspan="2">Memory State:N/a</td></tr><tr><td colspan="2">Reusable State(s):N/a</td></tr><tr><td rowspan="5">Main(Test scenario)</td><td>Charging Station</td><td>CSMS</td></tr><tr><td colspan="2">Manual Action: Request the CSMS to send a Trigger Message Request with requestedMessageSignChargingStationCertificate</td></tr><tr><td>2. The OCTT sends a TriggerMessageResponse with status Accepted</td><td>1. The CSMS sends a TriggerMessageRequest With requestedMessageSignChargingStationCertificate</td></tr><tr><td>3 The OCTT sends a SignCertificateRequest</td><td>4. The CSMS responds with aSignCertificateResponsewith status Accepted</td></tr><tr><td>6. The OCTT sends a CertificateSignedResponsewith status Accepted</td><td>5. The CSMS sends a CertificateSignedRequestWith certificateChain <Certificate generated from thereceived CSR from step 3 and signed by theconfigured CSMS Root certificate>certificateType ChargingStationCertificate</td></tr><tr><td rowspan="2">Tool validations</td><td colspan="2">* Step 1:Message: TriggerMessageRequest- requestedMessage must be SignChargingStationCertificate* Step 4:Message: SignCertificateResponse- status must be Accepted* Step 5:Message: CertificateSignedRequest- certificateChain <Certificate generated from the received CSR from step 3 and signed by the configuredCSMS Root certificate>- certificateType must be ChargingStationCertificate</td></tr><tr><td colspan="2">Post scenario validations:N/a</td></tr></table>
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:AuthorizeRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "IdTokenEnumType": {
+ "description": "Enumeration of possible idToken types.\r\n",
+ "javaType": "IdTokenEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Central",
+ "eMAID",
+ "ISO14443",
+ "ISO15693",
+ "KeyCode",
+ "Local",
+ "MacAddress",
+ "NoAuthorization"
+ ]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalIdToken": {
+ "description": "This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "description": "This defines the type of the additionalIdToken. This is a custom type, so the implementation needs to be agreed upon by all involved parties.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "$ref": "#/definitions/IdTokenEnumType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "OCSPRequestDataType": {
+ "javaType": "OCSPRequestData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "Hashed value of the Issuer DN (Distinguished Name).\r\n\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "Hashed value of the issuers public key\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The serial number of the certificate.\r\n",
+ "type": "string",
+ "maxLength": 40
+ },
+ "responderURL": {
+ "description": "This contains the responder URL (Case insensitive). \r\n\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": [
+ "hashAlgorithm",
+ "issuerNameHash",
+ "issuerKeyHash",
+ "serialNumber",
+ "responderURL"
+ ]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "certificate": {
+ "description": "The X.509 certificated presented by EV and encoded in PEM format.\r\n",
+ "type": "string",
+ "maxLength": 5500
+ },
+ "iso15118CertificateHashData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/OCSPRequestDataType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ }
+ },
+ "required": ["idToken"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:AuthorizeResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "AuthorizationStatusEnumType": {
+ "description": "ID_ Token. Status. Authorization_ Status\r\nurn:x-oca:ocpp:uid:1:569372\r\nCurrent status of the ID Token.\r\n",
+ "javaType": "AuthorizationStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Blocked",
+ "ConcurrentTx",
+ "Expired",
+ "Invalid",
+ "NoCredit",
+ "NotAllowedTypeEVSE",
+ "NotAtThisLocation",
+ "NotAtThisTime",
+ "Unknown"
+ ]
+ },
+ "AuthorizeCertificateStatusEnumType": {
+ "description": "Certificate status information. \r\n- if all certificates are valid: return 'Accepted'.\r\n- if one of the certificates was revoked, return 'CertificateRevoked'.\r\n",
+ "javaType": "AuthorizeCertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "SignatureError",
+ "CertificateExpired",
+ "CertificateRevoked",
+ "NoCertificateAvailable",
+ "CertChainError",
+ "ContractCancelled"
+ ]
+ },
+ "IdTokenEnumType": {
+ "description": "Enumeration of possible idToken types.\r\n",
+ "javaType": "IdTokenEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Central",
+ "eMAID",
+ "ISO14443",
+ "ISO15693",
+ "KeyCode",
+ "Local",
+ "MacAddress",
+ "NoAuthorization"
+ ]
+ },
+ "MessageFormatEnumType": {
+ "description": "Message_ Content. Format. Message_ Format_ Code\r\nurn:x-enexis:ecdm:uid:1:570848\r\nFormat of the message.\r\n",
+ "javaType": "MessageFormatEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ASCII", "HTML", "URI", "UTF8"]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalIdToken": {
+ "description": "This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "description": "This defines the type of the additionalIdToken. This is a custom type, so the implementation needs to be agreed upon by all involved parties.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "IdTokenInfoType": {
+ "description": "ID_ Token\r\nurn:x-oca:ocpp:uid:2:233247\r\nContains status information about an identifier.\r\nIt is advised to not stop charging for a token that expires during charging, as ExpiryDate is only used for caching purposes. If ExpiryDate is not given, the status has no end date.\r\n",
+ "javaType": "IdTokenInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/AuthorizationStatusEnumType"
+ },
+ "cacheExpiryDateTime": {
+ "description": "ID_ Token. Expiry. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569373\r\nDate and Time after which the token must be considered invalid.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingPriority": {
+ "description": "Priority from a business point of view. Default priority is 0, The range is from -9 to 9. Higher values indicate a higher priority. The chargingPriority in <<transactioneventresponse,TransactionEventResponse>> overrules this one. \r\n",
+ "type": "integer"
+ },
+ "language1": {
+ "description": "ID_ Token. Language1. Language_ Code\r\nurn:x-oca:ocpp:uid:1:569374\r\nPreferred user interface language of identifier user. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "evseId": {
+ "description": "Only used when the IdToken is only valid for one or more specific EVSEs, not for the entire Charging Station.\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer"
+ },
+ "minItems": 1
+ },
+ "groupIdToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "language2": {
+ "description": "ID_ Token. Language2. Language_ Code\r\nurn:x-oca:ocpp:uid:1:569375\r\nSecond preferred user interface language of identifier user. Don’t use when language1 is omitted, has to be different from language1. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "personalMessage": {
+ "$ref": "#/definitions/MessageContentType"
+ }
+ },
+ "required": ["status"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "$ref": "#/definitions/IdTokenEnumType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "MessageContentType": {
+ "description": "Message_ Content\r\nurn:x-enexis:ecdm:uid:2:234490\r\nContains message details, for a message to be displayed on a Charging Station.\r\n\r\n",
+ "javaType": "MessageContent",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "format": {
+ "$ref": "#/definitions/MessageFormatEnumType"
+ },
+ "language": {
+ "description": "Message_ Content. Language. Language_ Code\r\nurn:x-enexis:ecdm:uid:1:570849\r\nMessage language identifier. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "content": {
+ "description": "Message_ Content. Content. Message\r\nurn:x-enexis:ecdm:uid:1:570852\r\nMessage contents.\r\n\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["format", "content"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "idTokenInfo": {
+ "$ref": "#/definitions/IdTokenInfoType"
+ },
+ "certificateStatus": {
+ "$ref": "#/definitions/AuthorizeCertificateStatusEnumType"
+ }
+ },
+ "required": ["idTokenInfo"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:BootNotificationRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "BootReasonEnumType": {
+ "description": "This contains the reason for sending this message to the CSMS.\r\n",
+ "javaType": "BootReasonEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ApplicationReset",
+ "FirmwareUpdate",
+ "LocalReset",
+ "PowerUp",
+ "RemoteReset",
+ "ScheduledReset",
+ "Triggered",
+ "Unknown",
+ "Watchdog"
+ ]
+ },
+ "ChargingStationType": {
+ "description": "Charge_ Point\r\nurn:x-oca:ocpp:uid:2:233122\r\nThe physical system where an Electrical Vehicle (EV) can be charged.\r\n",
+ "javaType": "ChargingStation",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "serialNumber": {
+ "description": "Device. Serial_ Number. Serial_ Number\r\nurn:x-oca:ocpp:uid:1:569324\r\nVendor-specific device identifier.\r\n",
+ "type": "string",
+ "maxLength": 25
+ },
+ "model": {
+ "description": "Device. Model. CI20_ Text\r\nurn:x-oca:ocpp:uid:1:569325\r\nDefines the model of the device.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "modem": {
+ "$ref": "#/definitions/ModemType"
+ },
+ "vendorName": {
+ "description": "Identifies the vendor (not necessarily in a unique manner).\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "firmwareVersion": {
+ "description": "This contains the firmware version of the Charging Station.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["model", "vendorName"]
+ },
+ "ModemType": {
+ "description": "Wireless_ Communication_ Module\r\nurn:x-oca:ocpp:uid:2:233306\r\nDefines parameters required for initiating and maintaining wireless communication with other devices.\r\n",
+ "javaType": "Modem",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "iccid": {
+ "description": "Wireless_ Communication_ Module. ICCID. CI20_ Text\r\nurn:x-oca:ocpp:uid:1:569327\r\nThis contains the ICCID of the modem’s SIM card.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "imsi": {
+ "description": "Wireless_ Communication_ Module. IMSI. CI20_ Text\r\nurn:x-oca:ocpp:uid:1:569328\r\nThis contains the IMSI of the modem’s SIM card.\r\n",
+ "type": "string",
+ "maxLength": 20
+ }
+ }
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "chargingStation": {
+ "$ref": "#/definitions/ChargingStationType"
+ },
+ "reason": {
+ "$ref": "#/definitions/BootReasonEnumType"
+ }
+ },
+ "required": ["reason", "chargingStation"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:BootNotificationResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "RegistrationStatusEnumType": {
+ "description": "This contains whether the Charging Station has been registered\r\nwithin the CSMS.\r\n",
+ "javaType": "RegistrationStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Pending", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "currentTime": {
+ "description": "This contains the CSMS’s current time.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "interval": {
+ "description": "When <<cmn_registrationstatusenumtype,Status>> is Accepted, this contains the heartbeat interval in seconds. If the CSMS returns something other than Accepted, the value of the interval field indicates the minimum wait time before sending a next BootNotification request.\r\n",
+ "type": "integer"
+ },
+ "status": {
+ "$ref": "#/definitions/RegistrationStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["currentTime", "interval", "status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:CancelReservationRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reservationId": {
+ "description": "Id of the reservation to cancel.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["reservationId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:CancelReservationResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "CancelReservationStatusEnumType": {
+ "description": "This indicates the success or failure of the canceling of a reservation by CSMS.\r\n",
+ "javaType": "CancelReservationStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/CancelReservationStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:CertificateSignedRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "CertificateSigningUseEnumType": {
+ "description": "Indicates the type of the signed certificate that is returned. When omitted the certificate is used for both the 15118 connection (if implemented) and the Charging Station to CSMS connection. This field is required when a typeOfCertificate was included in the <<signcertificaterequest,SignCertificateRequest>> that requested this certificate to be signed AND both the 15118 connection and the Charging Station connection are implemented.\r\n\r\n",
+ "javaType": "CertificateSigningUseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ChargingStationCertificate", "V2GCertificate"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "certificateChain": {
+ "description": "The signed PEM encoded X.509 certificate. This can also contain the necessary sub CA certificates. In that case, the order of the bundle should follow the certificate chain, starting from the leaf certificate.\r\n\r\nThe Configuration Variable <<configkey-max-certificate-chain-size,MaxCertificateChainSize>> can be used to limit the maximum size of this field.\r\n",
+ "type": "string",
+ "maxLength": 10000
+ },
+ "certificateType": {
+ "$ref": "#/definitions/CertificateSigningUseEnumType"
+ }
+ },
+ "required": ["certificateChain"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:CertificateSignedResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "CertificateSignedStatusEnumType": {
+ "description": "Returns whether certificate signing has been accepted, otherwise rejected.\r\n",
+ "javaType": "CertificateSignedStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/CertificateSignedStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ChangeAvailabilityRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "OperationalStatusEnumType": {
+ "description": "This contains the type of availability change that the Charging Station should perform.\r\n\r\n",
+ "javaType": "OperationalStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Inoperative", "Operative"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "operationalStatus": {
+ "$ref": "#/definitions/OperationalStatusEnumType"
+ }
+ },
+ "required": ["operationalStatus"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ChangeAvailabilityResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChangeAvailabilityStatusEnumType": {
+ "description": "This indicates whether the Charging Station is able to perform the availability change.\r\n",
+ "javaType": "ChangeAvailabilityStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Scheduled"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/ChangeAvailabilityStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ClearCacheRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ClearCacheResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ClearCacheStatusEnumType": {
+ "description": "Accepted if the Charging Station has executed the request, otherwise rejected.\r\n",
+ "javaType": "ClearCacheStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/ClearCacheStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ClearChargingProfileRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChargingProfilePurposeEnumType": {
+ "description": "Charging_ Profile. Charging_ Profile_ Purpose. Charging_ Profile_ Purpose_ Code\r\nurn:x-oca:ocpp:uid:1:569231\r\nSpecifies to purpose of the charging profiles that will be cleared, if they meet the other criteria in the request.\r\n",
+ "javaType": "ChargingProfilePurposeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ChargingStationExternalConstraints",
+ "ChargingStationMaxProfile",
+ "TxDefaultProfile",
+ "TxProfile"
+ ]
+ },
+ "ClearChargingProfileType": {
+ "description": "Charging_ Profile\r\nurn:x-oca:ocpp:uid:2:233255\r\nA ChargingProfile consists of a ChargingSchedule, describing the amount of power or current that can be delivered per time interval.\r\n",
+ "javaType": "ClearChargingProfile",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evseId": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nSpecifies the id of the EVSE for which to clear charging profiles. An evseId of zero (0) specifies the charging profile for the overall Charging Station. Absence of this parameter means the clearing applies to all charging profiles that match the other criteria in the request.\r\n\r\n",
+ "type": "integer"
+ },
+ "chargingProfilePurpose": {
+ "$ref": "#/definitions/ChargingProfilePurposeEnumType"
+ },
+ "stackLevel": {
+ "description": "Charging_ Profile. Stack_ Level. Counter\r\nurn:x-oca:ocpp:uid:1:569230\r\nSpecifies the stackLevel for which charging profiles will be cleared, if they meet the other criteria in the request.\r\n",
+ "type": "integer"
+ }
+ }
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "chargingProfileId": {
+ "description": "The Id of the charging profile to clear.\r\n",
+ "type": "integer"
+ },
+ "chargingProfileCriteria": {
+ "$ref": "#/definitions/ClearChargingProfileType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ClearChargingProfileResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ClearChargingProfileStatusEnumType": {
+ "description": "Indicates if the Charging Station was able to execute the request.\r\n",
+ "javaType": "ClearChargingProfileStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Unknown"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/ClearChargingProfileStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ClearDisplayMessageRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Id of the message that SHALL be removed from the Charging Station.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ClearDisplayMessageResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ClearMessageStatusEnumType": {
+ "description": "Returns whether the Charging Station has been able to remove the message.\r\n",
+ "javaType": "ClearMessageStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Unknown"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/ClearMessageStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ClearVariableMonitoringRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "List of the monitors to be cleared, identified by there Id.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer"
+ },
+ "minItems": 1
+ }
+ },
+ "required": ["id"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ClearVariableMonitoringResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ClearMonitoringStatusEnumType": {
+ "description": "Result of the clear request for this monitor, identified by its Id.\r\n\r\n",
+ "javaType": "ClearMonitoringStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotFound"]
+ },
+ "ClearMonitoringResultType": {
+ "javaType": "ClearMonitoringResult",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/ClearMonitoringStatusEnumType"
+ },
+ "id": {
+ "description": "Id of the monitor of which a clear was requested.\r\n\r\n",
+ "type": "integer"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status", "id"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "clearMonitoringResult": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ClearMonitoringResultType"
+ },
+ "minItems": 1
+ }
+ },
+ "required": ["clearMonitoringResult"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ClearedChargingLimitRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChargingLimitSourceEnumType": {
+ "description": "Source of the charging limit.\r\n",
+ "javaType": "ChargingLimitSourceEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["EMS", "Other", "SO", "CSO"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "chargingLimitSource": {
+ "$ref": "#/definitions/ChargingLimitSourceEnumType"
+ },
+ "evseId": {
+ "description": "EVSE Identifier.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["chargingLimitSource"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ClearedChargingLimitResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:CostUpdatedRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "totalCost": {
+ "description": "Current total cost, based on the information known by the CSMS, of the transaction including taxes. In the currency configured with the configuration Variable: [<<configkey-currency, Currency>>]\r\n\r\n",
+ "type": "number"
+ },
+ "transactionId": {
+ "description": "Transaction Id of the transaction the current cost are asked for.\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ }
+ },
+ "required": ["totalCost", "transactionId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:CostUpdatedResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:CustomerInformationRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "IdTokenEnumType": {
+ "description": "Enumeration of possible idToken types.\r\n",
+ "javaType": "IdTokenEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Central",
+ "eMAID",
+ "ISO14443",
+ "ISO15693",
+ "KeyCode",
+ "Local",
+ "MacAddress",
+ "NoAuthorization"
+ ]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalIdToken": {
+ "description": "This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "description": "This defines the type of the additionalIdToken. This is a custom type, so the implementation needs to be agreed upon by all involved parties.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "CertificateHashDataType": {
+ "javaType": "CertificateHashData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "Hashed value of the Issuer DN (Distinguished Name).\r\n\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "Hashed value of the issuers public key\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The serial number of the certificate.\r\n",
+ "type": "string",
+ "maxLength": 40
+ }
+ },
+ "required": ["hashAlgorithm", "issuerNameHash", "issuerKeyHash", "serialNumber"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "$ref": "#/definitions/IdTokenEnumType"
+ }
+ },
+ "required": ["idToken", "type"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "customerCertificate": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ },
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "requestId": {
+ "description": "The Id of the request.\r\n\r\n",
+ "type": "integer"
+ },
+ "report": {
+ "description": "Flag indicating whether the Charging Station should return NotifyCustomerInformationRequest messages containing information about the customer referred to.\r\n",
+ "type": "boolean"
+ },
+ "clear": {
+ "description": "Flag indicating whether the Charging Station should clear all information about the customer referred to.\r\n",
+ "type": "boolean"
+ },
+ "customerIdentifier": {
+ "description": "A (e.g. vendor specific) identifier of the customer this request refers to. This field contains a custom identifier other than IdToken and Certificate.\r\nOne of the possible identifiers (customerIdentifier, customerIdToken or customerCertificate) should be in the request message.\r\n",
+ "type": "string",
+ "maxLength": 64
+ }
+ },
+ "required": ["requestId", "report", "clear"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:CustomerInformationResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "CustomerInformationStatusEnumType": {
+ "description": "Indicates whether the request was accepted.\r\n",
+ "javaType": "CustomerInformationStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Invalid"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/CustomerInformationStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:DataTransferRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "messageId": {
+ "description": "May be used to indicate a specific message or implementation.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "data": {
+ "description": "Data without specified length or format. This needs to be decided by both parties (Open to implementation).\r\n"
+ },
+ "vendorId": {
+ "description": "This identifies the Vendor specific implementation\r\n\r\n",
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:DataTransferResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "DataTransferStatusEnumType": {
+ "description": "This indicates the success or failure of the data transfer.\r\n",
+ "javaType": "DataTransferStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "UnknownMessageId", "UnknownVendorId"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/DataTransferStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "data": {
+ "description": "Data without specified length or format, in response to request.\r\n"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:DeleteCertificateRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "CertificateHashDataType": {
+ "javaType": "CertificateHashData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "Hashed value of the Issuer DN (Distinguished Name).\r\n\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "Hashed value of the issuers public key\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The serial number of the certificate.\r\n",
+ "type": "string",
+ "maxLength": 40
+ }
+ },
+ "required": ["hashAlgorithm", "issuerNameHash", "issuerKeyHash", "serialNumber"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "certificateHashData": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ }
+ },
+ "required": ["certificateHashData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:DeleteCertificateResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "DeleteCertificateStatusEnumType": {
+ "description": "Charging Station indicates if it can process the request.\r\n",
+ "javaType": "DeleteCertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Failed", "NotFound"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/DeleteCertificateStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:FirmwareStatusNotificationRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "FirmwareStatusEnumType": {
+ "description": "This contains the progress status of the firmware installation.\r\n",
+ "javaType": "FirmwareStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Downloaded",
+ "DownloadFailed",
+ "Downloading",
+ "DownloadScheduled",
+ "DownloadPaused",
+ "Idle",
+ "InstallationFailed",
+ "Installing",
+ "Installed",
+ "InstallRebooting",
+ "InstallScheduled",
+ "InstallVerificationFailed",
+ "InvalidSignature",
+ "SignatureVerified"
+ ]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/FirmwareStatusEnumType"
+ },
+ "requestId": {
+ "description": "The request id that was provided in the\r\nUpdateFirmwareRequest that started this firmware update.\r\nThis field is mandatory, unless the message was triggered by a TriggerMessageRequest AND there is no firmware update ongoing.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:FirmwareStatusNotificationResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:Get15118EVCertificateRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "CertificateActionEnumType": {
+ "description": "Defines whether certificate needs to be installed or updated.\r\n",
+ "javaType": "CertificateActionEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Install", "Update"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "iso15118SchemaVersion": {
+ "description": "Schema version currently used for the 15118 session between EV and Charging Station. Needed for parsing of the EXI stream by the CSMS.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "action": {
+ "$ref": "#/definitions/CertificateActionEnumType"
+ },
+ "exiRequest": {
+ "description": "Raw CertificateInstallationReq request from EV, Base64 encoded.\r\n",
+ "type": "string",
+ "maxLength": 5600
+ }
+ },
+ "required": ["iso15118SchemaVersion", "action", "exiRequest"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:Get15118EVCertificateResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "Iso15118EVCertificateStatusEnumType": {
+ "description": "Indicates whether the message was processed properly.\r\n",
+ "javaType": "Iso15118EVCertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Failed"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/Iso15118EVCertificateStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "exiResponse": {
+ "description": "Raw CertificateInstallationRes response for the EV, Base64 encoded.\r\n",
+ "type": "string",
+ "maxLength": 5600
+ }
+ },
+ "required": ["status", "exiResponse"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetBaseReportRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ReportBaseEnumType": {
+ "description": "This field specifies the report base.\r\n",
+ "javaType": "ReportBaseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ConfigurationInventory", "FullInventory", "SummaryInventory"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "requestId": {
+ "description": "The Id of the request.\r\n",
+ "type": "integer"
+ },
+ "reportBase": {
+ "$ref": "#/definitions/ReportBaseEnumType"
+ }
+ },
+ "required": ["requestId", "reportBase"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetBaseReportResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GenericDeviceModelStatusEnumType": {
+ "description": "This indicates whether the Charging Station is able to accept this request.\r\n",
+ "javaType": "GenericDeviceModelStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotSupported", "EmptyResultSet"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GenericDeviceModelStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetCertificateStatusRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "OCSPRequestDataType": {
+ "javaType": "OCSPRequestData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "Hashed value of the Issuer DN (Distinguished Name).\r\n\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "Hashed value of the issuers public key\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The serial number of the certificate.\r\n",
+ "type": "string",
+ "maxLength": 40
+ },
+ "responderURL": {
+ "description": "This contains the responder URL (Case insensitive). \r\n\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": [
+ "hashAlgorithm",
+ "issuerNameHash",
+ "issuerKeyHash",
+ "serialNumber",
+ "responderURL"
+ ]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "ocspRequestData": {
+ "$ref": "#/definitions/OCSPRequestDataType"
+ }
+ },
+ "required": ["ocspRequestData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetCertificateStatusResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GetCertificateStatusEnumType": {
+ "description": "This indicates whether the charging station was able to retrieve the OCSP certificate status.\r\n",
+ "javaType": "GetCertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Failed"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GetCertificateStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "ocspResult": {
+ "description": "OCSPResponse class as defined in <<ref-ocpp_security_24, IETF RFC 6960>>. DER encoded (as defined in <<ref-ocpp_security_24, IETF RFC 6960>>), and then base64 encoded. MAY only be omitted when status is not Accepted.\r\n",
+ "type": "string",
+ "maxLength": 5500
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetChargingProfilesRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChargingLimitSourceEnumType": {
+ "javaType": "ChargingLimitSourceEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["EMS", "Other", "SO", "CSO"]
+ },
+ "ChargingProfilePurposeEnumType": {
+ "description": "Charging_ Profile. Charging_ Profile_ Purpose. Charging_ Profile_ Purpose_ Code\r\nurn:x-oca:ocpp:uid:1:569231\r\nDefines the purpose of the schedule transferred by this profile\r\n",
+ "javaType": "ChargingProfilePurposeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ChargingStationExternalConstraints",
+ "ChargingStationMaxProfile",
+ "TxDefaultProfile",
+ "TxProfile"
+ ]
+ },
+ "ChargingProfileCriterionType": {
+ "description": "Charging_ Profile\r\nurn:x-oca:ocpp:uid:2:233255\r\nA ChargingProfile consists of ChargingSchedule, describing the amount of power or current that can be delivered per time interval.\r\n",
+ "javaType": "ChargingProfileCriterion",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "chargingProfilePurpose": {
+ "$ref": "#/definitions/ChargingProfilePurposeEnumType"
+ },
+ "stackLevel": {
+ "description": "Charging_ Profile. Stack_ Level. Counter\r\nurn:x-oca:ocpp:uid:1:569230\r\nValue determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.\r\n",
+ "type": "integer"
+ },
+ "chargingProfileId": {
+ "description": "List of all the chargingProfileIds requested. Any ChargingProfile that matches one of these profiles will be reported. If omitted, the Charging Station SHALL not filter on chargingProfileId. This field SHALL NOT contain more ids than set in <<configkey-charging-profile-entries,ChargingProfileEntries.maxLimit>>\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer"
+ },
+ "minItems": 1
+ },
+ "chargingLimitSource": {
+ "description": "For which charging limit sources, charging profiles SHALL be reported. If omitted, the Charging Station SHALL not filter on chargingLimitSource.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingLimitSourceEnumType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ }
+ }
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "requestId": {
+ "description": "Reference identification that is to be used by the Charging Station in the <<reportchargingprofilesrequest, ReportChargingProfilesRequest>> when provided.\r\n",
+ "type": "integer"
+ },
+ "evseId": {
+ "description": "For which EVSE installed charging profiles SHALL be reported. If 0, only charging profiles installed on the Charging Station itself (the grid connection) SHALL be reported. If omitted, all installed charging profiles SHALL be reported.\r\n",
+ "type": "integer"
+ },
+ "chargingProfile": {
+ "$ref": "#/definitions/ChargingProfileCriterionType"
+ }
+ },
+ "required": ["requestId", "chargingProfile"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetChargingProfilesResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GetChargingProfileStatusEnumType": {
+ "description": "This indicates whether the Charging Station is able to process this request and will send <<reportchargingprofilesrequest, ReportChargingProfilesRequest>> messages.\r\n",
+ "javaType": "GetChargingProfileStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "NoProfiles"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GetChargingProfileStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetCompositeScheduleRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChargingRateUnitEnumType": {
+ "description": "Can be used to force a power or current profile.\r\n\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "duration": {
+ "description": "Length of the requested schedule in seconds.\r\n\r\n",
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "evseId": {
+ "description": "The ID of the EVSE for which the schedule is requested. When evseid=0, the Charging Station will calculate the expected consumption for the grid connection.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["duration", "evseId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetCompositeScheduleResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChargingRateUnitEnumType": {
+ "description": "The unit of measure Limit is\r\nexpressed in.\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "GenericStatusEnumType": {
+ "description": "The Charging Station will indicate if it was\r\nable to process the request\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "ChargingSchedulePeriodType": {
+ "description": "Charging_ Schedule_ Period\r\nurn:x-oca:ocpp:uid:2:233257\r\nCharging schedule period structure defines a time period in a charging schedule.\r\n",
+ "javaType": "ChargingSchedulePeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "startPeriod": {
+ "description": "Charging_ Schedule_ Period. Start_ Period. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569240\r\nStart of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.\r\n",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Charging_ Schedule_ Period. Limit. Measure\r\nurn:x-oca:ocpp:uid:1:569241\r\nCharging rate limit during the schedule period, in the applicable chargingRateUnit, for example in Amperes (A) or Watts (W). Accepts at most one digit fraction (e.g. 8.1).\r\n",
+ "type": "number"
+ },
+ "numberPhases": {
+ "description": "Charging_ Schedule_ Period. Number_ Phases. Counter\r\nurn:x-oca:ocpp:uid:1:569242\r\nThe number of phases that can be used for charging. If a number of phases is needed, numberPhases=3 will be assumed unless another number is given.\r\n",
+ "type": "integer"
+ },
+ "phaseToUse": {
+ "description": "Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true. It’s not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.\r\n\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["startPeriod", "limit"]
+ },
+ "CompositeScheduleType": {
+ "description": "Composite_ Schedule\r\nurn:x-oca:ocpp:uid:2:233362\r\n",
+ "javaType": "CompositeSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingSchedulePeriodType"
+ },
+ "minItems": 1
+ },
+ "evseId": {
+ "description": "The ID of the EVSE for which the\r\nschedule is requested. When evseid=0, the\r\nCharging Station calculated the expected\r\nconsumption for the grid connection.\r\n",
+ "type": "integer"
+ },
+ "duration": {
+ "description": "Duration of the schedule in seconds.\r\n",
+ "type": "integer"
+ },
+ "scheduleStart": {
+ "description": "Composite_ Schedule. Start. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569456\r\nDate and time at which the schedule becomes active. All time measurements within the schedule are relative to this timestamp.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ }
+ },
+ "required": [
+ "evseId",
+ "duration",
+ "scheduleStart",
+ "chargingRateUnit",
+ "chargingSchedulePeriod"
+ ]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "schedule": {
+ "$ref": "#/definitions/CompositeScheduleType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetDisplayMessagesRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "MessagePriorityEnumType": {
+ "description": "If provided the Charging Station shall return Display Messages with the given priority only.\r\n",
+ "javaType": "MessagePriorityEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["AlwaysFront", "InFront", "NormalCycle"]
+ },
+ "MessageStateEnumType": {
+ "description": "If provided the Charging Station shall return Display Messages with the given state only. \r\n",
+ "javaType": "MessageStateEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Charging", "Faulted", "Idle", "Unavailable"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "If provided the Charging Station shall return Display Messages of the given ids. This field SHALL NOT contain more ids than set in <<configkey-number-of-display-messages,NumberOfDisplayMessages.maxLimit>>\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer"
+ },
+ "minItems": 1
+ },
+ "requestId": {
+ "description": "The Id of this request.\r\n",
+ "type": "integer"
+ },
+ "priority": {
+ "$ref": "#/definitions/MessagePriorityEnumType"
+ },
+ "state": {
+ "$ref": "#/definitions/MessageStateEnumType"
+ }
+ },
+ "required": ["requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetDisplayMessagesResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GetDisplayMessagesStatusEnumType": {
+ "description": "Indicates if the Charging Station has Display Messages that match the request criteria in the <<getdisplaymessagesrequest,GetDisplayMessagesRequest>>\r\n",
+ "javaType": "GetDisplayMessagesStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Unknown"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GetDisplayMessagesStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetInstalledCertificateIdsRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GetCertificateIdUseEnumType": {
+ "javaType": "GetCertificateIdUseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "V2GRootCertificate",
+ "MORootCertificate",
+ "CSMSRootCertificate",
+ "V2GCertificateChain",
+ "ManufacturerRootCertificate"
+ ]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "certificateType": {
+ "description": "Indicates the type of certificates requested. When omitted, all certificate types are requested.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/GetCertificateIdUseEnumType"
+ },
+ "minItems": 1
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetInstalledCertificateIdsResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GetCertificateIdUseEnumType": {
+ "description": "Indicates the type of the requested certificate(s).\r\n",
+ "javaType": "GetCertificateIdUseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "V2GRootCertificate",
+ "MORootCertificate",
+ "CSMSRootCertificate",
+ "V2GCertificateChain",
+ "ManufacturerRootCertificate"
+ ]
+ },
+ "GetInstalledCertificateStatusEnumType": {
+ "description": "Charging Station indicates if it can process the request.\r\n",
+ "javaType": "GetInstalledCertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "NotFound"]
+ },
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "CertificateHashDataChainType": {
+ "javaType": "CertificateHashDataChain",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "certificateHashData": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ },
+ "certificateType": {
+ "$ref": "#/definitions/GetCertificateIdUseEnumType"
+ },
+ "childCertificateHashData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ }
+ },
+ "required": ["certificateType", "certificateHashData"]
+ },
+ "CertificateHashDataType": {
+ "javaType": "CertificateHashData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "Hashed value of the Issuer DN (Distinguished Name).\r\n\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "Hashed value of the issuers public key\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The serial number of the certificate.\r\n",
+ "type": "string",
+ "maxLength": 40
+ }
+ },
+ "required": ["hashAlgorithm", "issuerNameHash", "issuerKeyHash", "serialNumber"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GetInstalledCertificateStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "certificateHashDataChain": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CertificateHashDataChainType"
+ },
+ "minItems": 1
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetLocalListVersionRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetLocalListVersionResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "versionNumber": {
+ "description": "This contains the current version number of the local authorization list in the Charging Station.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["versionNumber"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetLogRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "LogEnumType": {
+ "description": "This contains the type of log file that the Charging Station\r\nshould send.\r\n",
+ "javaType": "LogEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["DiagnosticsLog", "SecurityLog"]
+ },
+ "LogParametersType": {
+ "description": "Log\r\nurn:x-enexis:ecdm:uid:2:233373\r\nGeneric class for the configuration of logging entries.\r\n",
+ "javaType": "LogParameters",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "remoteLocation": {
+ "description": "Log. Remote_ Location. URI\r\nurn:x-enexis:ecdm:uid:1:569484\r\nThe URL of the location at the remote system where the log should be stored.\r\n",
+ "type": "string",
+ "maxLength": 512
+ },
+ "oldestTimestamp": {
+ "description": "Log. Oldest_ Timestamp. Date_ Time\r\nurn:x-enexis:ecdm:uid:1:569477\r\nThis contains the date and time of the oldest logging information to include in the diagnostics.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "latestTimestamp": {
+ "description": "Log. Latest_ Timestamp. Date_ Time\r\nurn:x-enexis:ecdm:uid:1:569482\r\nThis contains the date and time of the latest logging information to include in the diagnostics.\r\n",
+ "type": "string",
+ "format": "date-time"
+ }
+ },
+ "required": ["remoteLocation"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "log": {
+ "$ref": "#/definitions/LogParametersType"
+ },
+ "logType": {
+ "$ref": "#/definitions/LogEnumType"
+ },
+ "requestId": {
+ "description": "The Id of this request\r\n",
+ "type": "integer"
+ },
+ "retries": {
+ "description": "This specifies how many times the Charging Station must try to upload the log before giving up. If this field is not present, it is left to Charging Station to decide how many times it wants to retry.\r\n",
+ "type": "integer"
+ },
+ "retryInterval": {
+ "description": "The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charging Station to decide how long to wait between attempts.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["logType", "requestId", "log"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetLogResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "LogStatusEnumType": {
+ "description": "This field indicates whether the Charging Station was able to accept the request.\r\n",
+ "javaType": "LogStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "AcceptedCanceled"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/LogStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "filename": {
+ "description": "This contains the name of the log file that will be uploaded. This field is not present when no logging information is available.\r\n",
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetMonitoringReportRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "MonitoringCriterionEnumType": {
+ "javaType": "MonitoringCriterionEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ThresholdMonitoring", "DeltaMonitoring", "PeriodicMonitoring"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "ComponentVariableType": {
+ "description": "Class to report components, variables and variable attributes and characteristics.\r\n",
+ "javaType": "ComponentVariable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ }
+ },
+ "required": ["component"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "componentVariable": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ComponentVariableType"
+ },
+ "minItems": 1
+ },
+ "requestId": {
+ "description": "The Id of the request.\r\n",
+ "type": "integer"
+ },
+ "monitoringCriteria": {
+ "description": "This field contains criteria for components for which a monitoring report is requested\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MonitoringCriterionEnumType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ }
+ },
+ "required": ["requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetMonitoringReportResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GenericDeviceModelStatusEnumType": {
+ "description": "This field indicates whether the Charging Station was able to accept the request.\r\n",
+ "javaType": "GenericDeviceModelStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotSupported", "EmptyResultSet"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GenericDeviceModelStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetReportRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ComponentCriterionEnumType": {
+ "javaType": "ComponentCriterionEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Active", "Available", "Enabled", "Problem"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "ComponentVariableType": {
+ "description": "Class to report components, variables and variable attributes and characteristics.\r\n",
+ "javaType": "ComponentVariable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ }
+ },
+ "required": ["component"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "componentVariable": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ComponentVariableType"
+ },
+ "minItems": 1
+ },
+ "requestId": {
+ "description": "The Id of the request.\r\n",
+ "type": "integer"
+ },
+ "componentCriteria": {
+ "description": "This field contains criteria for components for which a report is requested\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ComponentCriterionEnumType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ }
+ },
+ "required": ["requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetReportResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GenericDeviceModelStatusEnumType": {
+ "description": "This field indicates whether the Charging Station was able to accept the request.\r\n",
+ "javaType": "GenericDeviceModelStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotSupported", "EmptyResultSet"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GenericDeviceModelStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetTransactionStatusRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "transactionId": {
+ "description": "The Id of the transaction for which the status is requested.\r\n",
+ "type": "string",
+ "maxLength": 36
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetTransactionStatusResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "ongoingIndicator": {
+ "description": "Whether the transaction is still ongoing.\r\n",
+ "type": "boolean"
+ },
+ "messagesInQueue": {
+ "description": "Whether there are still message to be delivered.\r\n",
+ "type": "boolean"
+ }
+ },
+ "required": ["messagesInQueue"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetVariablesRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "AttributeEnumType": {
+ "description": "Attribute type for which value is requested. When absent, default Actual is assumed.\r\n",
+ "javaType": "AttributeEnum",
+ "type": "string",
+ "default": "Actual",
+ "additionalProperties": false,
+ "enum": ["Actual", "Target", "MinSet", "MaxSet"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "GetVariableDataType": {
+ "description": "Class to hold parameters for GetVariables request.\r\n",
+ "javaType": "GetVariableData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "attributeType": {
+ "$ref": "#/definitions/AttributeEnumType"
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ }
+ },
+ "required": ["component", "variable"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "getVariableData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/GetVariableDataType"
+ },
+ "minItems": 1
+ }
+ },
+ "required": ["getVariableData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:GetVariablesResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "AttributeEnumType": {
+ "description": "Attribute type for which value is requested. When absent, default Actual is assumed.\r\n",
+ "javaType": "AttributeEnum",
+ "type": "string",
+ "default": "Actual",
+ "additionalProperties": false,
+ "enum": ["Actual", "Target", "MinSet", "MaxSet"]
+ },
+ "GetVariableStatusEnumType": {
+ "description": "Result status of getting the variable.\r\n\r\n",
+ "javaType": "GetVariableStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Rejected",
+ "UnknownComponent",
+ "UnknownVariable",
+ "NotSupportedAttributeType"
+ ]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "GetVariableResultType": {
+ "description": "Class to hold results of GetVariables request.\r\n",
+ "javaType": "GetVariableResult",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "attributeStatusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "attributeStatus": {
+ "$ref": "#/definitions/GetVariableStatusEnumType"
+ },
+ "attributeType": {
+ "$ref": "#/definitions/AttributeEnumType"
+ },
+ "attributeValue": {
+ "description": "Value of requested attribute type of component-variable. This field can only be empty when the given status is NOT accepted.\r\n\r\nThe Configuration Variable <<configkey-reporting-value-size,ReportingValueSize>> can be used to limit GetVariableResult.attributeValue, VariableAttribute.value and EventData.actualValue. The max size of these values will always remain equal. \r\n\r\n",
+ "type": "string",
+ "maxLength": 2500
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ }
+ },
+ "required": ["attributeStatus", "component", "variable"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "getVariableResult": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/GetVariableResultType"
+ },
+ "minItems": 1
+ }
+ },
+ "required": ["getVariableResult"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:HeartbeatRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:HeartbeatResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "currentTime": {
+ "description": "Contains the current time of the CSMS.\r\n",
+ "type": "string",
+ "format": "date-time"
+ }
+ },
+ "required": ["currentTime"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:InstallCertificateRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "InstallCertificateUseEnumType": {
+ "description": "Indicates the certificate type that is sent.\r\n",
+ "javaType": "InstallCertificateUseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "V2GRootCertificate",
+ "MORootCertificate",
+ "CSMSRootCertificate",
+ "ManufacturerRootCertificate"
+ ]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "certificateType": {
+ "$ref": "#/definitions/InstallCertificateUseEnumType"
+ },
+ "certificate": {
+ "description": "A PEM encoded X.509 certificate.\r\n",
+ "type": "string",
+ "maxLength": 5500
+ }
+ },
+ "required": ["certificateType", "certificate"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:InstallCertificateResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "InstallCertificateStatusEnumType": {
+ "description": "Charging Station indicates if installation was successful.\r\n",
+ "javaType": "InstallCertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Failed"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/InstallCertificateStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:LogStatusNotificationRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "UploadLogStatusEnumType": {
+ "description": "This contains the status of the log upload.\r\n",
+ "javaType": "UploadLogStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "BadMessage",
+ "Idle",
+ "NotSupportedOperation",
+ "PermissionDenied",
+ "Uploaded",
+ "UploadFailure",
+ "Uploading",
+ "AcceptedCanceled"
+ ]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/UploadLogStatusEnumType"
+ },
+ "requestId": {
+ "description": "The request id that was provided in GetLogRequest that started this log upload. This field is mandatory,\r\nunless the message was triggered by a TriggerMessageRequest AND there is no log upload ongoing.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:LogStatusNotificationResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:MeterValuesRequest",
+ "description": "Request_ Body\r\nurn:x-enexis:ecdm:uid:2:234744\r\n",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "LocationEnumType": {
+ "description": "Sampled_ Value. Location. Location_ Code\r\nurn:x-oca:ocpp:uid:1:569265\r\nIndicates where the measured value has been sampled. Default = \"Outlet\"\r\n\r\n",
+ "javaType": "LocationEnum",
+ "type": "string",
+ "default": "Outlet",
+ "additionalProperties": false,
+ "enum": ["Body", "Cable", "EV", "Inlet", "Outlet"]
+ },
+ "MeasurandEnumType": {
+ "description": "Sampled_ Value. Measurand. Measurand_ Code\r\nurn:x-oca:ocpp:uid:1:569263\r\nType of measurement. Default = \"Energy.Active.Import.Register\"\r\n",
+ "javaType": "MeasurandEnum",
+ "type": "string",
+ "default": "Energy.Active.Import.Register",
+ "additionalProperties": false,
+ "enum": [
+ "Current.Export",
+ "Current.Import",
+ "Current.Offered",
+ "Energy.Active.Export.Register",
+ "Energy.Active.Import.Register",
+ "Energy.Reactive.Export.Register",
+ "Energy.Reactive.Import.Register",
+ "Energy.Active.Export.Interval",
+ "Energy.Active.Import.Interval",
+ "Energy.Active.Net",
+ "Energy.Reactive.Export.Interval",
+ "Energy.Reactive.Import.Interval",
+ "Energy.Reactive.Net",
+ "Energy.Apparent.Net",
+ "Energy.Apparent.Import",
+ "Energy.Apparent.Export",
+ "Frequency",
+ "Power.Active.Export",
+ "Power.Active.Import",
+ "Power.Factor",
+ "Power.Offered",
+ "Power.Reactive.Export",
+ "Power.Reactive.Import",
+ "SoC",
+ "Voltage"
+ ]
+ },
+ "PhaseEnumType": {
+ "description": "Sampled_ Value. Phase. Phase_ Code\r\nurn:x-oca:ocpp:uid:1:569264\r\nIndicates how the measured value is to be interpreted. For instance between L1 and neutral (L1-N) Please note that not all values of phase are applicable to all Measurands. When phase is absent, the measured value is interpreted as an overall value.\r\n",
+ "javaType": "PhaseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["L1", "L2", "L3", "N", "L1-N", "L2-N", "L3-N", "L1-L2", "L2-L3", "L3-L1"]
+ },
+ "ReadingContextEnumType": {
+ "description": "Sampled_ Value. Context. Reading_ Context_ Code\r\nurn:x-oca:ocpp:uid:1:569261\r\nType of detail value: start, end or sample. Default = \"Sample.Periodic\"\r\n",
+ "javaType": "ReadingContextEnum",
+ "type": "string",
+ "default": "Sample.Periodic",
+ "additionalProperties": false,
+ "enum": [
+ "Interruption.Begin",
+ "Interruption.End",
+ "Other",
+ "Sample.Clock",
+ "Sample.Periodic",
+ "Transaction.Begin",
+ "Transaction.End",
+ "Trigger"
+ ]
+ },
+ "MeterValueType": {
+ "description": "Meter_ Value\r\nurn:x-oca:ocpp:uid:2:233265\r\nCollection of one or more sampled values in MeterValuesRequest and TransactionEvent. All sampled values in a MeterValue are sampled at the same point in time.\r\n",
+ "javaType": "MeterValue",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "sampledValue": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SampledValueType"
+ },
+ "minItems": 1
+ },
+ "timestamp": {
+ "description": "Meter_ Value. Timestamp. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569259\r\nTimestamp for measured value(s).\r\n",
+ "type": "string",
+ "format": "date-time"
+ }
+ },
+ "required": ["timestamp", "sampledValue"]
+ },
+ "SampledValueType": {
+ "description": "Sampled_ Value\r\nurn:x-oca:ocpp:uid:2:233266\r\nSingle sampled value in MeterValues. Each value can be accompanied by optional fields.\r\n\r\nTo save on mobile data usage, default values of all of the optional fields are such that. The value without any additional fields will be interpreted, as a register reading of active import energy in Wh (Watt-hour) units.\r\n",
+ "javaType": "SampledValue",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "value": {
+ "description": "Sampled_ Value. Value. Measure\r\nurn:x-oca:ocpp:uid:1:569260\r\nIndicates the measured value.\r\n\r\n",
+ "type": "number"
+ },
+ "context": {
+ "$ref": "#/definitions/ReadingContextEnumType"
+ },
+ "measurand": {
+ "$ref": "#/definitions/MeasurandEnumType"
+ },
+ "phase": {
+ "$ref": "#/definitions/PhaseEnumType"
+ },
+ "location": {
+ "$ref": "#/definitions/LocationEnumType"
+ },
+ "signedMeterValue": {
+ "$ref": "#/definitions/SignedMeterValueType"
+ },
+ "unitOfMeasure": {
+ "$ref": "#/definitions/UnitOfMeasureType"
+ }
+ },
+ "required": ["value"]
+ },
+ "SignedMeterValueType": {
+ "description": "Represent a signed version of the meter value.\r\n",
+ "javaType": "SignedMeterValue",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "signedMeterData": {
+ "description": "Base64 encoded, contains the signed data which might contain more then just the meter value. It can contain information like timestamps, reference to a customer etc.\r\n",
+ "type": "string",
+ "maxLength": 2500
+ },
+ "signingMethod": {
+ "description": "Method used to create the digital signature.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "encodingMethod": {
+ "description": "Method used to encode the meter values before applying the digital signature algorithm.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "publicKey": {
+ "description": "Base64 encoded, sending depends on configuration variable _PublicKeyWithSignedMeterValue_.\r\n",
+ "type": "string",
+ "maxLength": 2500
+ }
+ },
+ "required": ["signedMeterData", "signingMethod", "encodingMethod", "publicKey"]
+ },
+ "UnitOfMeasureType": {
+ "description": "Represents a UnitOfMeasure with a multiplier\r\n",
+ "javaType": "UnitOfMeasure",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "unit": {
+ "description": "Unit of the value. Default = \"Wh\" if the (default) measurand is an \"Energy\" type.\r\nThis field SHALL use a value from the list Standardized Units of Measurements in Part 2 Appendices. \r\nIf an applicable unit is available in that list, otherwise a \"custom\" unit might be used.\r\n",
+ "type": "string",
+ "default": "Wh",
+ "maxLength": 20
+ },
+ "multiplier": {
+ "description": "Multiplier, this value represents the exponent to base 10. I.e. multiplier 3 means 10 raised to the 3rd power. Default is 0.\r\n",
+ "type": "integer",
+ "default": 0
+ }
+ }
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evseId": {
+ "description": "Request_ Body. EVSEID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:571101\r\nThis contains a number (>0) designating an EVSE of the Charging Station. ‘0’ (zero) is used to designate the main power meter.\r\n",
+ "type": "integer"
+ },
+ "meterValue": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MeterValueType"
+ },
+ "minItems": 1
+ }
+ },
+ "required": ["evseId", "meterValue"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:MeterValuesResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyChargingLimitRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChargingLimitSourceEnumType": {
+ "description": "Charging_ Limit. Charging_ Limit_ Source. Charging_ Limit_ Source_ Code\r\nurn:x-enexis:ecdm:uid:1:570845\r\nRepresents the source of the charging limit.\r\n",
+ "javaType": "ChargingLimitSourceEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["EMS", "Other", "SO", "CSO"]
+ },
+ "ChargingRateUnitEnumType": {
+ "description": "Charging_ Schedule. Charging_ Rate_ Unit. Charging_ Rate_ Unit_ Code\r\nurn:x-oca:ocpp:uid:1:569238\r\nThe unit of measure Limit is expressed in.\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "CostKindEnumType": {
+ "description": "Cost. Cost_ Kind. Cost_ Kind_ Code\r\nurn:x-oca:ocpp:uid:1:569243\r\nThe kind of cost referred to in the message element amount\r\n",
+ "javaType": "CostKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CarbonDioxideEmission", "RelativePricePercentage", "RenewableGenerationPercentage"]
+ },
+ "ChargingLimitType": {
+ "description": "Charging_ Limit\r\nurn:x-enexis:ecdm:uid:2:234489\r\n",
+ "javaType": "ChargingLimit",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "chargingLimitSource": {
+ "$ref": "#/definitions/ChargingLimitSourceEnumType"
+ },
+ "isGridCritical": {
+ "description": "Charging_ Limit. Is_ Grid_ Critical. Indicator\r\nurn:x-enexis:ecdm:uid:1:570847\r\nIndicates whether the charging limit is critical for the grid.\r\n",
+ "type": "boolean"
+ }
+ },
+ "required": ["chargingLimitSource"]
+ },
+ "ChargingSchedulePeriodType": {
+ "description": "Charging_ Schedule_ Period\r\nurn:x-oca:ocpp:uid:2:233257\r\nCharging schedule period structure defines a time period in a charging schedule.\r\n",
+ "javaType": "ChargingSchedulePeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "startPeriod": {
+ "description": "Charging_ Schedule_ Period. Start_ Period. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569240\r\nStart of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.\r\n",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Charging_ Schedule_ Period. Limit. Measure\r\nurn:x-oca:ocpp:uid:1:569241\r\nCharging rate limit during the schedule period, in the applicable chargingRateUnit, for example in Amperes (A) or Watts (W). Accepts at most one digit fraction (e.g. 8.1).\r\n",
+ "type": "number"
+ },
+ "numberPhases": {
+ "description": "Charging_ Schedule_ Period. Number_ Phases. Counter\r\nurn:x-oca:ocpp:uid:1:569242\r\nThe number of phases that can be used for charging. If a number of phases is needed, numberPhases=3 will be assumed unless another number is given.\r\n",
+ "type": "integer"
+ },
+ "phaseToUse": {
+ "description": "Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true. It’s not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.\r\n\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["startPeriod", "limit"]
+ },
+ "ChargingScheduleType": {
+ "description": "Charging_ Schedule\r\nurn:x-oca:ocpp:uid:2:233256\r\nCharging schedule structure defines a list of charging periods, as used in: GetCompositeSchedule.conf and ChargingProfile. \r\n",
+ "javaType": "ChargingSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identifies the ChargingSchedule.\r\n",
+ "type": "integer"
+ },
+ "startSchedule": {
+ "description": "Charging_ Schedule. Start_ Schedule. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569237\r\nStarting point of an absolute schedule. If absent the schedule will be relative to start of charging.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Charging_ Schedule. Duration. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569236\r\nDuration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction if chargingProfilePurpose = TxProfile.\r\n",
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingSchedulePeriodType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "minChargingRate": {
+ "description": "Charging_ Schedule. Min_ Charging_ Rate. Numeric\r\nurn:x-oca:ocpp:uid:1:569239\r\nMinimum charging rate supported by the EV. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates. Accepts at most one digit fraction (e.g. 8.1)\r\n",
+ "type": "number"
+ },
+ "salesTariff": {
+ "$ref": "#/definitions/SalesTariffType"
+ }
+ },
+ "required": ["id", "chargingRateUnit", "chargingSchedulePeriod"]
+ },
+ "ConsumptionCostType": {
+ "description": "Consumption_ Cost\r\nurn:x-oca:ocpp:uid:2:233259\r\n",
+ "javaType": "ConsumptionCost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "startValue": {
+ "description": "Consumption_ Cost. Start_ Value. Numeric\r\nurn:x-oca:ocpp:uid:1:569246\r\nThe lowest level of consumption that defines the starting point of this consumption block. The block interval extends to the start of the next interval.\r\n",
+ "type": "number"
+ },
+ "cost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ }
+ },
+ "required": ["startValue", "cost"]
+ },
+ "CostType": {
+ "description": "Cost\r\nurn:x-oca:ocpp:uid:2:233258\r\n",
+ "javaType": "Cost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "costKind": {
+ "$ref": "#/definitions/CostKindEnumType"
+ },
+ "amount": {
+ "description": "Cost. Amount. Amount\r\nurn:x-oca:ocpp:uid:1:569244\r\nThe estimated or actual cost per kWh\r\n",
+ "type": "integer"
+ },
+ "amountMultiplier": {
+ "description": "Cost. Amount_ Multiplier. Integer\r\nurn:x-oca:ocpp:uid:1:569245\r\nValues: -3..3, The amountMultiplier defines the exponent to base 10 (dec). The final value is determined by: amount * 10 ^ amountMultiplier\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["costKind", "amount"]
+ },
+ "RelativeTimeIntervalType": {
+ "description": "Relative_ Timer_ Interval\r\nurn:x-oca:ocpp:uid:2:233270\r\n",
+ "javaType": "RelativeTimeInterval",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "start": {
+ "description": "Relative_ Timer_ Interval. Start. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569279\r\nStart of the interval, in seconds from NOW.\r\n",
+ "type": "integer"
+ },
+ "duration": {
+ "description": "Relative_ Timer_ Interval. Duration. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569280\r\nDuration of the interval, in seconds.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["start"]
+ },
+ "SalesTariffEntryType": {
+ "description": "Sales_ Tariff_ Entry\r\nurn:x-oca:ocpp:uid:2:233271\r\n",
+ "javaType": "SalesTariffEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "relativeTimeInterval": {
+ "$ref": "#/definitions/RelativeTimeIntervalType"
+ },
+ "ePriceLevel": {
+ "description": "Sales_ Tariff_ Entry. E_ Price_ Level. Unsigned_ Integer\r\nurn:x-oca:ocpp:uid:1:569281\r\nDefines the price level of this SalesTariffEntry (referring to NumEPriceLevels). Small values for the EPriceLevel represent a cheaper TariffEntry. Large values for the EPriceLevel represent a more expensive TariffEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "consumptionCost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ConsumptionCostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ }
+ },
+ "required": ["relativeTimeInterval"]
+ },
+ "SalesTariffType": {
+ "description": "Sales_ Tariff\r\nurn:x-oca:ocpp:uid:2:233272\r\nNOTE: This dataType is based on dataTypes from <<ref-ISOIEC15118-2,ISO 15118-2>>.\r\n",
+ "javaType": "SalesTariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nSalesTariff identifier used to identify one sales tariff. An SAID remains a unique identifier for one schedule throughout a charging session.\r\n",
+ "type": "integer"
+ },
+ "salesTariffDescription": {
+ "description": "Sales_ Tariff. Sales. Tariff_ Description\r\nurn:x-oca:ocpp:uid:1:569283\r\nA human readable title/short description of the sales tariff e.g. for HMI display purposes.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numEPriceLevels": {
+ "description": "Sales_ Tariff. Num_ E_ Price_ Levels. Counter\r\nurn:x-oca:ocpp:uid:1:569284\r\nDefines the overall number of distinct price levels used across all provided SalesTariff elements.\r\n",
+ "type": "integer"
+ },
+ "salesTariffEntry": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SalesTariffEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ }
+ },
+ "required": ["id", "salesTariffEntry"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "chargingSchedule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingScheduleType"
+ },
+ "minItems": 1
+ },
+ "evseId": {
+ "description": "The charging schedule contained in this notification applies to an EVSE. evseId must be > 0.\r\n",
+ "type": "integer"
+ },
+ "chargingLimit": {
+ "$ref": "#/definitions/ChargingLimitType"
+ }
+ },
+ "required": ["chargingLimit"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyChargingLimitResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyCustomerInformationRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "data": {
+ "description": "(Part of) the requested data. No format specified in which the data is returned. Should be human readable.\r\n",
+ "type": "string",
+ "maxLength": 512
+ },
+ "tbc": {
+ "description": "“to be continued” indicator. Indicates whether another part of the monitoringData follows in an upcoming notifyMonitoringReportRequest message. Default value when omitted is false.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "seqNo": {
+ "description": "Sequence number of this message. First message starts at 0.\r\n",
+ "type": "integer"
+ },
+ "generatedAt": {
+ "description": " Timestamp of the moment this message was generated at the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "requestId": {
+ "description": "The Id of the request.\r\n\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["data", "seqNo", "generatedAt", "requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyCustomerInformationResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyDisplayMessagesRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "MessageFormatEnumType": {
+ "description": "Message_ Content. Format. Message_ Format_ Code\r\nurn:x-enexis:ecdm:uid:1:570848\r\nFormat of the message.\r\n",
+ "javaType": "MessageFormatEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ASCII", "HTML", "URI", "UTF8"]
+ },
+ "MessagePriorityEnumType": {
+ "description": "Message_ Info. Priority. Message_ Priority_ Code\r\nurn:x-enexis:ecdm:uid:1:569253\r\nWith what priority should this message be shown\r\n",
+ "javaType": "MessagePriorityEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["AlwaysFront", "InFront", "NormalCycle"]
+ },
+ "MessageStateEnumType": {
+ "description": "Message_ Info. State. Message_ State_ Code\r\nurn:x-enexis:ecdm:uid:1:569254\r\nDuring what state should this message be shown. When omitted this message should be shown in any state of the Charging Station.\r\n",
+ "javaType": "MessageStateEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Charging", "Faulted", "Idle", "Unavailable"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "MessageContentType": {
+ "description": "Message_ Content\r\nurn:x-enexis:ecdm:uid:2:234490\r\nContains message details, for a message to be displayed on a Charging Station.\r\n\r\n",
+ "javaType": "MessageContent",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "format": {
+ "$ref": "#/definitions/MessageFormatEnumType"
+ },
+ "language": {
+ "description": "Message_ Content. Language. Language_ Code\r\nurn:x-enexis:ecdm:uid:1:570849\r\nMessage language identifier. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "content": {
+ "description": "Message_ Content. Content. Message\r\nurn:x-enexis:ecdm:uid:1:570852\r\nMessage contents.\r\n\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["format", "content"]
+ },
+ "MessageInfoType": {
+ "description": "Message_ Info\r\nurn:x-enexis:ecdm:uid:2:233264\r\nContains message details, for a message to be displayed on a Charging Station.\r\n",
+ "javaType": "MessageInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "display": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nMaster resource identifier, unique within an exchange context. It is defined within the OCPP context as a positive Integer value (greater or equal to zero).\r\n",
+ "type": "integer"
+ },
+ "priority": {
+ "$ref": "#/definitions/MessagePriorityEnumType"
+ },
+ "state": {
+ "$ref": "#/definitions/MessageStateEnumType"
+ },
+ "startDateTime": {
+ "description": "Message_ Info. Start. Date_ Time\r\nurn:x-enexis:ecdm:uid:1:569256\r\nFrom what date-time should this message be shown. If omitted: directly.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "endDateTime": {
+ "description": "Message_ Info. End. Date_ Time\r\nurn:x-enexis:ecdm:uid:1:569257\r\nUntil what date-time should this message be shown, after this date/time this message SHALL be removed.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "transactionId": {
+ "description": "During which transaction shall this message be shown.\r\nMessage SHALL be removed by the Charging Station after transaction has\r\nended.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "message": {
+ "$ref": "#/definitions/MessageContentType"
+ }
+ },
+ "required": ["id", "priority", "message"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "messageInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MessageInfoType"
+ },
+ "minItems": 1
+ },
+ "requestId": {
+ "description": "The id of the <<getdisplaymessagesrequest,GetDisplayMessagesRequest>> that requested this message.\r\n",
+ "type": "integer"
+ },
+ "tbc": {
+ "description": "\"to be continued\" indicator. Indicates whether another part of the report follows in an upcoming NotifyDisplayMessagesRequest message. Default value when omitted is false.\r\n",
+ "type": "boolean",
+ "default": false
+ }
+ },
+ "required": ["requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyDisplayMessagesResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyEVChargingNeedsRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "EnergyTransferModeEnumType": {
+ "description": "Charging_ Needs. Requested. Energy_ Transfer_ Mode_ Code\r\nurn:x-oca:ocpp:uid:1:569209\r\nMode of energy transfer requested by the EV.\r\n",
+ "javaType": "EnergyTransferModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["DC", "AC_single_phase", "AC_two_phase", "AC_three_phase"]
+ },
+ "ACChargingParametersType": {
+ "description": "AC_ Charging_ Parameters\r\nurn:x-oca:ocpp:uid:2:233250\r\nEV AC charging parameters.\r\n\r\n",
+ "javaType": "ACChargingParameters",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "energyAmount": {
+ "description": "AC_ Charging_ Parameters. Energy_ Amount. Energy_ Amount\r\nurn:x-oca:ocpp:uid:1:569211\r\nAmount of energy requested (in Wh). This includes energy required for preconditioning.\r\n",
+ "type": "integer"
+ },
+ "evMinCurrent": {
+ "description": "AC_ Charging_ Parameters. EV_ Min. Current\r\nurn:x-oca:ocpp:uid:1:569212\r\nMinimum current (amps) supported by the electric vehicle (per phase).\r\n",
+ "type": "integer"
+ },
+ "evMaxCurrent": {
+ "description": "AC_ Charging_ Parameters. EV_ Max. Current\r\nurn:x-oca:ocpp:uid:1:569213\r\nMaximum current (amps) supported by the electric vehicle (per phase). Includes cable capacity.\r\n",
+ "type": "integer"
+ },
+ "evMaxVoltage": {
+ "description": "AC_ Charging_ Parameters. EV_ Max. Voltage\r\nurn:x-oca:ocpp:uid:1:569214\r\nMaximum voltage supported by the electric vehicle\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["energyAmount", "evMinCurrent", "evMaxCurrent", "evMaxVoltage"]
+ },
+ "ChargingNeedsType": {
+ "description": "Charging_ Needs\r\nurn:x-oca:ocpp:uid:2:233249\r\n",
+ "javaType": "ChargingNeeds",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "acChargingParameters": {
+ "$ref": "#/definitions/ACChargingParametersType"
+ },
+ "dcChargingParameters": {
+ "$ref": "#/definitions/DCChargingParametersType"
+ },
+ "requestedEnergyTransfer": {
+ "$ref": "#/definitions/EnergyTransferModeEnumType"
+ },
+ "departureTime": {
+ "description": "Charging_ Needs. Departure_ Time. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569223\r\nEstimated departure time of the EV.\r\n",
+ "type": "string",
+ "format": "date-time"
+ }
+ },
+ "required": ["requestedEnergyTransfer"]
+ },
+ "DCChargingParametersType": {
+ "description": "DC_ Charging_ Parameters\r\nurn:x-oca:ocpp:uid:2:233251\r\nEV DC charging parameters\r\n\r\n\r\n",
+ "javaType": "DCChargingParameters",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evMaxCurrent": {
+ "description": "DC_ Charging_ Parameters. EV_ Max. Current\r\nurn:x-oca:ocpp:uid:1:569215\r\nMaximum current (amps) supported by the electric vehicle. Includes cable capacity.\r\n",
+ "type": "integer"
+ },
+ "evMaxVoltage": {
+ "description": "DC_ Charging_ Parameters. EV_ Max. Voltage\r\nurn:x-oca:ocpp:uid:1:569216\r\nMaximum voltage supported by the electric vehicle\r\n",
+ "type": "integer"
+ },
+ "energyAmount": {
+ "description": "DC_ Charging_ Parameters. Energy_ Amount. Energy_ Amount\r\nurn:x-oca:ocpp:uid:1:569217\r\nAmount of energy requested (in Wh). This inludes energy required for preconditioning.\r\n",
+ "type": "integer"
+ },
+ "evMaxPower": {
+ "description": "DC_ Charging_ Parameters. EV_ Max. Power\r\nurn:x-oca:ocpp:uid:1:569218\r\nMaximum power (in W) supported by the electric vehicle. Required for DC charging.\r\n",
+ "type": "integer"
+ },
+ "stateOfCharge": {
+ "description": "DC_ Charging_ Parameters. State_ Of_ Charge. Numeric\r\nurn:x-oca:ocpp:uid:1:569219\r\nEnergy available in the battery (in percent of the battery capacity)\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "evEnergyCapacity": {
+ "description": "DC_ Charging_ Parameters. EV_ Energy_ Capacity. Numeric\r\nurn:x-oca:ocpp:uid:1:569220\r\nCapacity of the electric vehicle battery (in Wh)\r\n",
+ "type": "integer"
+ },
+ "fullSoC": {
+ "description": "DC_ Charging_ Parameters. Full_ SOC. Percentage\r\nurn:x-oca:ocpp:uid:1:569221\r\nPercentage of SoC at which the EV considers the battery fully charged. (possible values: 0 - 100)\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "bulkSoC": {
+ "description": "DC_ Charging_ Parameters. Bulk_ SOC. Percentage\r\nurn:x-oca:ocpp:uid:1:569222\r\nPercentage of SoC at which the EV considers a fast charging process to end. (possible values: 0 - 100)\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ }
+ },
+ "required": ["evMaxCurrent", "evMaxVoltage"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "maxScheduleTuples": {
+ "description": "Contains the maximum schedule tuples the car supports per schedule.\r\n",
+ "type": "integer"
+ },
+ "chargingNeeds": {
+ "$ref": "#/definitions/ChargingNeedsType"
+ },
+ "evseId": {
+ "description": "Defines the EVSE and connector to which the EV is connected. EvseId may not be 0.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["evseId", "chargingNeeds"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyEVChargingNeedsResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "NotifyEVChargingNeedsStatusEnumType": {
+ "description": "Returns whether the CSMS has been able to process the message successfully. It does not imply that the evChargingNeeds can be met with the current charging profile.\r\n",
+ "javaType": "NotifyEVChargingNeedsStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Processing"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/NotifyEVChargingNeedsStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyEVChargingScheduleRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChargingRateUnitEnumType": {
+ "description": "Charging_ Schedule. Charging_ Rate_ Unit. Charging_ Rate_ Unit_ Code\r\nurn:x-oca:ocpp:uid:1:569238\r\nThe unit of measure Limit is expressed in.\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "CostKindEnumType": {
+ "description": "Cost. Cost_ Kind. Cost_ Kind_ Code\r\nurn:x-oca:ocpp:uid:1:569243\r\nThe kind of cost referred to in the message element amount\r\n",
+ "javaType": "CostKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CarbonDioxideEmission", "RelativePricePercentage", "RenewableGenerationPercentage"]
+ },
+ "ChargingSchedulePeriodType": {
+ "description": "Charging_ Schedule_ Period\r\nurn:x-oca:ocpp:uid:2:233257\r\nCharging schedule period structure defines a time period in a charging schedule.\r\n",
+ "javaType": "ChargingSchedulePeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "startPeriod": {
+ "description": "Charging_ Schedule_ Period. Start_ Period. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569240\r\nStart of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.\r\n",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Charging_ Schedule_ Period. Limit. Measure\r\nurn:x-oca:ocpp:uid:1:569241\r\nCharging rate limit during the schedule period, in the applicable chargingRateUnit, for example in Amperes (A) or Watts (W). Accepts at most one digit fraction (e.g. 8.1).\r\n",
+ "type": "number"
+ },
+ "numberPhases": {
+ "description": "Charging_ Schedule_ Period. Number_ Phases. Counter\r\nurn:x-oca:ocpp:uid:1:569242\r\nThe number of phases that can be used for charging. If a number of phases is needed, numberPhases=3 will be assumed unless another number is given.\r\n",
+ "type": "integer"
+ },
+ "phaseToUse": {
+ "description": "Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true. It’s not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.\r\n\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["startPeriod", "limit"]
+ },
+ "ChargingScheduleType": {
+ "description": "Charging_ Schedule\r\nurn:x-oca:ocpp:uid:2:233256\r\nCharging schedule structure defines a list of charging periods, as used in: GetCompositeSchedule.conf and ChargingProfile. \r\n",
+ "javaType": "ChargingSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identifies the ChargingSchedule.\r\n",
+ "type": "integer"
+ },
+ "startSchedule": {
+ "description": "Charging_ Schedule. Start_ Schedule. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569237\r\nStarting point of an absolute schedule. If absent the schedule will be relative to start of charging.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Charging_ Schedule. Duration. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569236\r\nDuration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction if chargingProfilePurpose = TxProfile.\r\n",
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingSchedulePeriodType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "minChargingRate": {
+ "description": "Charging_ Schedule. Min_ Charging_ Rate. Numeric\r\nurn:x-oca:ocpp:uid:1:569239\r\nMinimum charging rate supported by the EV. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates. Accepts at most one digit fraction (e.g. 8.1)\r\n",
+ "type": "number"
+ },
+ "salesTariff": {
+ "$ref": "#/definitions/SalesTariffType"
+ }
+ },
+ "required": ["id", "chargingRateUnit", "chargingSchedulePeriod"]
+ },
+ "ConsumptionCostType": {
+ "description": "Consumption_ Cost\r\nurn:x-oca:ocpp:uid:2:233259\r\n",
+ "javaType": "ConsumptionCost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "startValue": {
+ "description": "Consumption_ Cost. Start_ Value. Numeric\r\nurn:x-oca:ocpp:uid:1:569246\r\nThe lowest level of consumption that defines the starting point of this consumption block. The block interval extends to the start of the next interval.\r\n",
+ "type": "number"
+ },
+ "cost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ }
+ },
+ "required": ["startValue", "cost"]
+ },
+ "CostType": {
+ "description": "Cost\r\nurn:x-oca:ocpp:uid:2:233258\r\n",
+ "javaType": "Cost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "costKind": {
+ "$ref": "#/definitions/CostKindEnumType"
+ },
+ "amount": {
+ "description": "Cost. Amount. Amount\r\nurn:x-oca:ocpp:uid:1:569244\r\nThe estimated or actual cost per kWh\r\n",
+ "type": "integer"
+ },
+ "amountMultiplier": {
+ "description": "Cost. Amount_ Multiplier. Integer\r\nurn:x-oca:ocpp:uid:1:569245\r\nValues: -3..3, The amountMultiplier defines the exponent to base 10 (dec). The final value is determined by: amount * 10 ^ amountMultiplier\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["costKind", "amount"]
+ },
+ "RelativeTimeIntervalType": {
+ "description": "Relative_ Timer_ Interval\r\nurn:x-oca:ocpp:uid:2:233270\r\n",
+ "javaType": "RelativeTimeInterval",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "start": {
+ "description": "Relative_ Timer_ Interval. Start. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569279\r\nStart of the interval, in seconds from NOW.\r\n",
+ "type": "integer"
+ },
+ "duration": {
+ "description": "Relative_ Timer_ Interval. Duration. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569280\r\nDuration of the interval, in seconds.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["start"]
+ },
+ "SalesTariffEntryType": {
+ "description": "Sales_ Tariff_ Entry\r\nurn:x-oca:ocpp:uid:2:233271\r\n",
+ "javaType": "SalesTariffEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "relativeTimeInterval": {
+ "$ref": "#/definitions/RelativeTimeIntervalType"
+ },
+ "ePriceLevel": {
+ "description": "Sales_ Tariff_ Entry. E_ Price_ Level. Unsigned_ Integer\r\nurn:x-oca:ocpp:uid:1:569281\r\nDefines the price level of this SalesTariffEntry (referring to NumEPriceLevels). Small values for the EPriceLevel represent a cheaper TariffEntry. Large values for the EPriceLevel represent a more expensive TariffEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "consumptionCost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ConsumptionCostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ }
+ },
+ "required": ["relativeTimeInterval"]
+ },
+ "SalesTariffType": {
+ "description": "Sales_ Tariff\r\nurn:x-oca:ocpp:uid:2:233272\r\nNOTE: This dataType is based on dataTypes from <<ref-ISOIEC15118-2,ISO 15118-2>>.\r\n",
+ "javaType": "SalesTariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nSalesTariff identifier used to identify one sales tariff. An SAID remains a unique identifier for one schedule throughout a charging session.\r\n",
+ "type": "integer"
+ },
+ "salesTariffDescription": {
+ "description": "Sales_ Tariff. Sales. Tariff_ Description\r\nurn:x-oca:ocpp:uid:1:569283\r\nA human readable title/short description of the sales tariff e.g. for HMI display purposes.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numEPriceLevels": {
+ "description": "Sales_ Tariff. Num_ E_ Price_ Levels. Counter\r\nurn:x-oca:ocpp:uid:1:569284\r\nDefines the overall number of distinct price levels used across all provided SalesTariff elements.\r\n",
+ "type": "integer"
+ },
+ "salesTariffEntry": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SalesTariffEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ }
+ },
+ "required": ["id", "salesTariffEntry"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "timeBase": {
+ "description": "Periods contained in the charging profile are relative to this point in time.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingSchedule": {
+ "$ref": "#/definitions/ChargingScheduleType"
+ },
+ "evseId": {
+ "description": "The charging schedule contained in this notification applies to an EVSE. EvseId must be > 0.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["timeBase", "evseId", "chargingSchedule"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyEVChargingScheduleResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GenericStatusEnumType": {
+ "description": "Returns whether the CSMS has been able to process the message successfully. It does not imply any approval of the charging schedule.\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyEventRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "EventNotificationEnumType": {
+ "description": "Specifies the event notification type of the message.\r\n\r\n",
+ "javaType": "EventNotificationEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["HardWiredNotification", "HardWiredMonitor", "PreconfiguredMonitor", "CustomMonitor"]
+ },
+ "EventTriggerEnumType": {
+ "description": "Type of monitor that triggered this event, e.g. exceeding a threshold value.\r\n\r\n",
+ "javaType": "EventTriggerEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Alerting", "Delta", "Periodic"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "EventDataType": {
+ "description": "Class to report an event notification for a component-variable.\r\n",
+ "javaType": "EventData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "eventId": {
+ "description": "Identifies the event. This field can be referred to as a cause by other events.\r\n\r\n",
+ "type": "integer"
+ },
+ "timestamp": {
+ "description": "Timestamp of the moment the report was generated.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "trigger": {
+ "$ref": "#/definitions/EventTriggerEnumType"
+ },
+ "cause": {
+ "description": "Refers to the Id of an event that is considered to be the cause for this event.\r\n\r\n",
+ "type": "integer"
+ },
+ "actualValue": {
+ "description": "Actual value (_attributeType_ Actual) of the variable.\r\n\r\nThe Configuration Variable <<configkey-reporting-value-size,ReportingValueSize>> can be used to limit GetVariableResult.attributeValue, VariableAttribute.value and EventData.actualValue. The max size of these values will always remain equal. \r\n\r\n",
+ "type": "string",
+ "maxLength": 2500
+ },
+ "techCode": {
+ "description": "Technical (error) code as reported by component.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "techInfo": {
+ "description": "Technical detail information as reported by component.\r\n",
+ "type": "string",
+ "maxLength": 500
+ },
+ "cleared": {
+ "description": "_Cleared_ is set to true to report the clearing of a monitored situation, i.e. a 'return to normal'. \r\n\r\n",
+ "type": "boolean"
+ },
+ "transactionId": {
+ "description": "If an event notification is linked to a specific transaction, this field can be used to specify its transactionId.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variableMonitoringId": {
+ "description": "Identifies the VariableMonitoring which triggered the event.\r\n",
+ "type": "integer"
+ },
+ "eventNotificationType": {
+ "$ref": "#/definitions/EventNotificationEnumType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ }
+ },
+ "required": [
+ "eventId",
+ "timestamp",
+ "trigger",
+ "actualValue",
+ "eventNotificationType",
+ "component",
+ "variable"
+ ]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "generatedAt": {
+ "description": "Timestamp of the moment this message was generated at the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "tbc": {
+ "description": "“to be continued” indicator. Indicates whether another part of the report follows in an upcoming notifyEventRequest message. Default value when omitted is false. \r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "seqNo": {
+ "description": "Sequence number of this message. First message starts at 0.\r\n",
+ "type": "integer"
+ },
+ "eventData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/EventDataType"
+ },
+ "minItems": 1
+ }
+ },
+ "required": ["generatedAt", "seqNo", "eventData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyEventResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyMonitoringReportRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "MonitorEnumType": {
+ "description": "The type of this monitor, e.g. a threshold, delta or periodic monitor. \r\n",
+ "javaType": "MonitorEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["UpperThreshold", "LowerThreshold", "Delta", "Periodic", "PeriodicClockAligned"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "MonitoringDataType": {
+ "description": "Class to hold parameters of SetVariableMonitoring request.\r\n",
+ "javaType": "MonitoringData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "variableMonitoring": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/VariableMonitoringType"
+ },
+ "minItems": 1
+ }
+ },
+ "required": ["component", "variable", "variableMonitoring"]
+ },
+ "VariableMonitoringType": {
+ "description": "A monitoring setting for a variable.\r\n",
+ "javaType": "VariableMonitoring",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identifies the monitor.\r\n",
+ "type": "integer"
+ },
+ "transaction": {
+ "description": "Monitor only active when a transaction is ongoing on a component relevant to this transaction. \r\n",
+ "type": "boolean"
+ },
+ "value": {
+ "description": "Value for threshold or delta monitoring.\r\nFor Periodic or PeriodicClockAligned this is the interval in seconds.\r\n",
+ "type": "number"
+ },
+ "type": {
+ "$ref": "#/definitions/MonitorEnumType"
+ },
+ "severity": {
+ "description": "The severity that will be assigned to an event that is triggered by this monitor. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.\r\n\r\nThe severity levels have the following meaning: +\r\n*0-Danger* +\r\nIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately. +\r\n*1-Hardware Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required. +\r\n*2-System Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required. +\r\n*3-Critical* +\r\nIndicates a critical error. Action is required. +\r\n*4-Error* +\r\nIndicates a non-urgent error. Action is required. +\r\n*5-Alert* +\r\nIndicates an alert event. Default severity for any type of monitoring event. +\r\n*6-Warning* +\r\nIndicates a warning event. Action may be required. +\r\n*7-Notice* +\r\nIndicates an unusual event. No immediate action is required. +\r\n*8-Informational* +\r\nIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required. +\r\n*9-Debug* +\r\nIndicates information useful to developers for debugging, not useful during operations.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id", "transaction", "value", "type", "severity"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "monitor": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MonitoringDataType"
+ },
+ "minItems": 1
+ },
+ "requestId": {
+ "description": "The id of the GetMonitoringRequest that requested this report.\r\n\r\n",
+ "type": "integer"
+ },
+ "tbc": {
+ "description": "“to be continued” indicator. Indicates whether another part of the monitoringData follows in an upcoming notifyMonitoringReportRequest message. Default value when omitted is false.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "seqNo": {
+ "description": "Sequence number of this message. First message starts at 0.\r\n",
+ "type": "integer"
+ },
+ "generatedAt": {
+ "description": "Timestamp of the moment this message was generated at the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ }
+ },
+ "required": ["requestId", "seqNo", "generatedAt"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyMonitoringReportResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyReportRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "AttributeEnumType": {
+ "description": "Attribute: Actual, MinSet, MaxSet, etc.\r\nDefaults to Actual if absent.\r\n",
+ "javaType": "AttributeEnum",
+ "type": "string",
+ "default": "Actual",
+ "additionalProperties": false,
+ "enum": ["Actual", "Target", "MinSet", "MaxSet"]
+ },
+ "DataEnumType": {
+ "description": "Data type of this variable.\r\n",
+ "javaType": "DataEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "string",
+ "decimal",
+ "integer",
+ "dateTime",
+ "boolean",
+ "OptionList",
+ "SequenceList",
+ "MemberList"
+ ]
+ },
+ "MutabilityEnumType": {
+ "description": "Defines the mutability of this attribute. Default is ReadWrite when omitted.\r\n",
+ "javaType": "MutabilityEnum",
+ "type": "string",
+ "default": "ReadWrite",
+ "additionalProperties": false,
+ "enum": ["ReadOnly", "WriteOnly", "ReadWrite"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "ReportDataType": {
+ "description": "Class to report components, variables and variable attributes and characteristics.\r\n",
+ "javaType": "ReportData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "variableAttribute": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/VariableAttributeType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ },
+ "variableCharacteristics": {
+ "$ref": "#/definitions/VariableCharacteristicsType"
+ }
+ },
+ "required": ["component", "variable", "variableAttribute"]
+ },
+ "VariableAttributeType": {
+ "description": "Attribute data of a variable.\r\n",
+ "javaType": "VariableAttribute",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "type": {
+ "$ref": "#/definitions/AttributeEnumType"
+ },
+ "value": {
+ "description": "Value of the attribute. May only be omitted when mutability is set to 'WriteOnly'.\r\n\r\nThe Configuration Variable <<configkey-reporting-value-size,ReportingValueSize>> can be used to limit GetVariableResult.attributeValue, VariableAttribute.value and EventData.actualValue. The max size of these values will always remain equal. \r\n",
+ "type": "string",
+ "maxLength": 2500
+ },
+ "mutability": {
+ "$ref": "#/definitions/MutabilityEnumType"
+ },
+ "persistent": {
+ "description": "If true, value will be persistent across system reboots or power down. Default when omitted is false.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "constant": {
+ "description": "If true, value that will never be changed by the Charging Station at runtime. Default when omitted is false.\r\n",
+ "type": "boolean",
+ "default": false
+ }
+ }
+ },
+ "VariableCharacteristicsType": {
+ "description": "Fixed read-only parameters of a variable.\r\n",
+ "javaType": "VariableCharacteristics",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "unit": {
+ "description": "Unit of the variable. When the transmitted value has a unit, this field SHALL be included.\r\n",
+ "type": "string",
+ "maxLength": 16
+ },
+ "dataType": {
+ "$ref": "#/definitions/DataEnumType"
+ },
+ "minLimit": {
+ "description": "Minimum possible value of this variable.\r\n",
+ "type": "number"
+ },
+ "maxLimit": {
+ "description": "Maximum possible value of this variable. When the datatype of this Variable is String, OptionList, SequenceList or MemberList, this field defines the maximum length of the (CSV) string.\r\n",
+ "type": "number"
+ },
+ "valuesList": {
+ "description": "Allowed values when variable is Option/Member/SequenceList. \r\n\r\n* OptionList: The (Actual) Variable value must be a single value from the reported (CSV) enumeration list.\r\n\r\n* MemberList: The (Actual) Variable value may be an (unordered) (sub-)set of the reported (CSV) valid values list.\r\n\r\n* SequenceList: The (Actual) Variable value may be an ordered (priority, etc) (sub-)set of the reported (CSV) valid values.\r\n\r\nThis is a comma separated list.\r\n\r\nThe Configuration Variable <<configkey-configuration-value-size,ConfigurationValueSize>> can be used to limit SetVariableData.attributeValue and VariableCharacteristics.valueList. The max size of these values will always remain equal. \r\n\r\n",
+ "type": "string",
+ "maxLength": 1000
+ },
+ "supportsMonitoring": {
+ "description": "Flag indicating if this variable supports monitoring. \r\n",
+ "type": "boolean"
+ }
+ },
+ "required": ["dataType", "supportsMonitoring"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "requestId": {
+ "description": "The id of the GetReportRequest or GetBaseReportRequest that requested this report\r\n",
+ "type": "integer"
+ },
+ "generatedAt": {
+ "description": "Timestamp of the moment this message was generated at the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "reportData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ReportDataType"
+ },
+ "minItems": 1
+ },
+ "tbc": {
+ "description": "“to be continued” indicator. Indicates whether another part of the report follows in an upcoming notifyReportRequest message. Default value when omitted is false.\r\n\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "seqNo": {
+ "description": "Sequence number of this message. First message starts at 0.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["requestId", "generatedAt", "seqNo"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:NotifyReportResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:PublishFirmwareRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "location": {
+ "description": "This contains a string containing a URI pointing to a\r\nlocation from which to retrieve the firmware.\r\n",
+ "type": "string",
+ "maxLength": 512
+ },
+ "retries": {
+ "description": "This specifies how many times Charging Station must try\r\nto download the firmware before giving up. If this field is not\r\npresent, it is left to Charging Station to decide how many times it wants to retry.\r\n",
+ "type": "integer"
+ },
+ "checksum": {
+ "description": "The MD5 checksum over the entire firmware file as a hexadecimal string of length 32. \r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "requestId": {
+ "description": "The Id of the request.\r\n",
+ "type": "integer"
+ },
+ "retryInterval": {
+ "description": "The interval in seconds\r\nafter which a retry may be\r\nattempted. If this field is not\r\npresent, it is left to Charging\r\nStation to decide how long to wait\r\nbetween attempts.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["location", "checksum", "requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:PublishFirmwareResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GenericStatusEnumType": {
+ "description": "Indicates whether the request was accepted.\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:PublishFirmwareStatusNotificationRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "PublishFirmwareStatusEnumType": {
+ "description": "This contains the progress status of the publishfirmware\r\ninstallation.\r\n",
+ "javaType": "PublishFirmwareStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Idle",
+ "DownloadScheduled",
+ "Downloading",
+ "Downloaded",
+ "Published",
+ "DownloadFailed",
+ "DownloadPaused",
+ "InvalidChecksum",
+ "ChecksumVerified",
+ "PublishFailed"
+ ]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/PublishFirmwareStatusEnumType"
+ },
+ "location": {
+ "description": "Required if status is Published. Can be multiple URI’s, if the Local Controller supports e.g. HTTP, HTTPS, and FTP.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "string",
+ "maxLength": 512
+ },
+ "minItems": 1
+ },
+ "requestId": {
+ "description": "The request id that was\r\nprovided in the\r\nPublishFirmwareRequest which\r\ntriggered this action.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:PublishFirmwareStatusNotificationResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ReportChargingProfilesRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChargingLimitSourceEnumType": {
+ "description": "Source that has installed this charging profile.\r\n",
+ "javaType": "ChargingLimitSourceEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["EMS", "Other", "SO", "CSO"]
+ },
+ "ChargingProfileKindEnumType": {
+ "description": "Charging_ Profile. Charging_ Profile_ Kind. Charging_ Profile_ Kind_ Code\r\nurn:x-oca:ocpp:uid:1:569232\r\nIndicates the kind of schedule.\r\n",
+ "javaType": "ChargingProfileKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Absolute", "Recurring", "Relative"]
+ },
+ "ChargingProfilePurposeEnumType": {
+ "description": "Charging_ Profile. Charging_ Profile_ Purpose. Charging_ Profile_ Purpose_ Code\r\nurn:x-oca:ocpp:uid:1:569231\r\nDefines the purpose of the schedule transferred by this profile\r\n",
+ "javaType": "ChargingProfilePurposeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ChargingStationExternalConstraints",
+ "ChargingStationMaxProfile",
+ "TxDefaultProfile",
+ "TxProfile"
+ ]
+ },
+ "ChargingRateUnitEnumType": {
+ "description": "Charging_ Schedule. Charging_ Rate_ Unit. Charging_ Rate_ Unit_ Code\r\nurn:x-oca:ocpp:uid:1:569238\r\nThe unit of measure Limit is expressed in.\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "CostKindEnumType": {
+ "description": "Cost. Cost_ Kind. Cost_ Kind_ Code\r\nurn:x-oca:ocpp:uid:1:569243\r\nThe kind of cost referred to in the message element amount\r\n",
+ "javaType": "CostKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CarbonDioxideEmission", "RelativePricePercentage", "RenewableGenerationPercentage"]
+ },
+ "RecurrencyKindEnumType": {
+ "description": "Charging_ Profile. Recurrency_ Kind. Recurrency_ Kind_ Code\r\nurn:x-oca:ocpp:uid:1:569233\r\nIndicates the start point of a recurrence.\r\n",
+ "javaType": "RecurrencyKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Daily", "Weekly"]
+ },
+ "ChargingProfileType": {
+ "description": "Charging_ Profile\r\nurn:x-oca:ocpp:uid:2:233255\r\nA ChargingProfile consists of ChargingSchedule, describing the amount of power or current that can be delivered per time interval.\r\n",
+ "javaType": "ChargingProfile",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nId of ChargingProfile.\r\n",
+ "type": "integer"
+ },
+ "stackLevel": {
+ "description": "Charging_ Profile. Stack_ Level. Counter\r\nurn:x-oca:ocpp:uid:1:569230\r\nValue determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.\r\n",
+ "type": "integer"
+ },
+ "chargingProfilePurpose": {
+ "$ref": "#/definitions/ChargingProfilePurposeEnumType"
+ },
+ "chargingProfileKind": {
+ "$ref": "#/definitions/ChargingProfileKindEnumType"
+ },
+ "recurrencyKind": {
+ "$ref": "#/definitions/RecurrencyKindEnumType"
+ },
+ "validFrom": {
+ "description": "Charging_ Profile. Valid_ From. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569234\r\nPoint in time at which the profile starts to be valid. If absent, the profile is valid as soon as it is received by the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "validTo": {
+ "description": "Charging_ Profile. Valid_ To. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569235\r\nPoint in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingSchedule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingScheduleType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "transactionId": {
+ "description": "SHALL only be included if ChargingProfilePurpose is set to TxProfile. The transactionId is used to match the profile to a specific transaction.\r\n",
+ "type": "string",
+ "maxLength": 36
+ }
+ },
+ "required": [
+ "id",
+ "stackLevel",
+ "chargingProfilePurpose",
+ "chargingProfileKind",
+ "chargingSchedule"
+ ]
+ },
+ "ChargingSchedulePeriodType": {
+ "description": "Charging_ Schedule_ Period\r\nurn:x-oca:ocpp:uid:2:233257\r\nCharging schedule period structure defines a time period in a charging schedule.\r\n",
+ "javaType": "ChargingSchedulePeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "startPeriod": {
+ "description": "Charging_ Schedule_ Period. Start_ Period. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569240\r\nStart of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.\r\n",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Charging_ Schedule_ Period. Limit. Measure\r\nurn:x-oca:ocpp:uid:1:569241\r\nCharging rate limit during the schedule period, in the applicable chargingRateUnit, for example in Amperes (A) or Watts (W). Accepts at most one digit fraction (e.g. 8.1).\r\n",
+ "type": "number"
+ },
+ "numberPhases": {
+ "description": "Charging_ Schedule_ Period. Number_ Phases. Counter\r\nurn:x-oca:ocpp:uid:1:569242\r\nThe number of phases that can be used for charging. If a number of phases is needed, numberPhases=3 will be assumed unless another number is given.\r\n",
+ "type": "integer"
+ },
+ "phaseToUse": {
+ "description": "Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true. It’s not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.\r\n\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["startPeriod", "limit"]
+ },
+ "ChargingScheduleType": {
+ "description": "Charging_ Schedule\r\nurn:x-oca:ocpp:uid:2:233256\r\nCharging schedule structure defines a list of charging periods, as used in: GetCompositeSchedule.conf and ChargingProfile. \r\n",
+ "javaType": "ChargingSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identifies the ChargingSchedule.\r\n",
+ "type": "integer"
+ },
+ "startSchedule": {
+ "description": "Charging_ Schedule. Start_ Schedule. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569237\r\nStarting point of an absolute schedule. If absent the schedule will be relative to start of charging.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Charging_ Schedule. Duration. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569236\r\nDuration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction if chargingProfilePurpose = TxProfile.\r\n",
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingSchedulePeriodType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "minChargingRate": {
+ "description": "Charging_ Schedule. Min_ Charging_ Rate. Numeric\r\nurn:x-oca:ocpp:uid:1:569239\r\nMinimum charging rate supported by the EV. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates. Accepts at most one digit fraction (e.g. 8.1)\r\n",
+ "type": "number"
+ },
+ "salesTariff": {
+ "$ref": "#/definitions/SalesTariffType"
+ }
+ },
+ "required": ["id", "chargingRateUnit", "chargingSchedulePeriod"]
+ },
+ "ConsumptionCostType": {
+ "description": "Consumption_ Cost\r\nurn:x-oca:ocpp:uid:2:233259\r\n",
+ "javaType": "ConsumptionCost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "startValue": {
+ "description": "Consumption_ Cost. Start_ Value. Numeric\r\nurn:x-oca:ocpp:uid:1:569246\r\nThe lowest level of consumption that defines the starting point of this consumption block. The block interval extends to the start of the next interval.\r\n",
+ "type": "number"
+ },
+ "cost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ }
+ },
+ "required": ["startValue", "cost"]
+ },
+ "CostType": {
+ "description": "Cost\r\nurn:x-oca:ocpp:uid:2:233258\r\n",
+ "javaType": "Cost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "costKind": {
+ "$ref": "#/definitions/CostKindEnumType"
+ },
+ "amount": {
+ "description": "Cost. Amount. Amount\r\nurn:x-oca:ocpp:uid:1:569244\r\nThe estimated or actual cost per kWh\r\n",
+ "type": "integer"
+ },
+ "amountMultiplier": {
+ "description": "Cost. Amount_ Multiplier. Integer\r\nurn:x-oca:ocpp:uid:1:569245\r\nValues: -3..3, The amountMultiplier defines the exponent to base 10 (dec). The final value is determined by: amount * 10 ^ amountMultiplier\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["costKind", "amount"]
+ },
+ "RelativeTimeIntervalType": {
+ "description": "Relative_ Timer_ Interval\r\nurn:x-oca:ocpp:uid:2:233270\r\n",
+ "javaType": "RelativeTimeInterval",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "start": {
+ "description": "Relative_ Timer_ Interval. Start. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569279\r\nStart of the interval, in seconds from NOW.\r\n",
+ "type": "integer"
+ },
+ "duration": {
+ "description": "Relative_ Timer_ Interval. Duration. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569280\r\nDuration of the interval, in seconds.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["start"]
+ },
+ "SalesTariffEntryType": {
+ "description": "Sales_ Tariff_ Entry\r\nurn:x-oca:ocpp:uid:2:233271\r\n",
+ "javaType": "SalesTariffEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "relativeTimeInterval": {
+ "$ref": "#/definitions/RelativeTimeIntervalType"
+ },
+ "ePriceLevel": {
+ "description": "Sales_ Tariff_ Entry. E_ Price_ Level. Unsigned_ Integer\r\nurn:x-oca:ocpp:uid:1:569281\r\nDefines the price level of this SalesTariffEntry (referring to NumEPriceLevels). Small values for the EPriceLevel represent a cheaper TariffEntry. Large values for the EPriceLevel represent a more expensive TariffEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "consumptionCost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ConsumptionCostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ }
+ },
+ "required": ["relativeTimeInterval"]
+ },
+ "SalesTariffType": {
+ "description": "Sales_ Tariff\r\nurn:x-oca:ocpp:uid:2:233272\r\nNOTE: This dataType is based on dataTypes from <<ref-ISOIEC15118-2,ISO 15118-2>>.\r\n",
+ "javaType": "SalesTariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nSalesTariff identifier used to identify one sales tariff. An SAID remains a unique identifier for one schedule throughout a charging session.\r\n",
+ "type": "integer"
+ },
+ "salesTariffDescription": {
+ "description": "Sales_ Tariff. Sales. Tariff_ Description\r\nurn:x-oca:ocpp:uid:1:569283\r\nA human readable title/short description of the sales tariff e.g. for HMI display purposes.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numEPriceLevels": {
+ "description": "Sales_ Tariff. Num_ E_ Price_ Levels. Counter\r\nurn:x-oca:ocpp:uid:1:569284\r\nDefines the overall number of distinct price levels used across all provided SalesTariff elements.\r\n",
+ "type": "integer"
+ },
+ "salesTariffEntry": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SalesTariffEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ }
+ },
+ "required": ["id", "salesTariffEntry"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "requestId": {
+ "description": "Id used to match the <<getchargingprofilesrequest, GetChargingProfilesRequest>> message with the resulting ReportChargingProfilesRequest messages. When the CSMS provided a requestId in the <<getchargingprofilesrequest, GetChargingProfilesRequest>>, this field SHALL contain the same value.\r\n",
+ "type": "integer"
+ },
+ "chargingLimitSource": {
+ "$ref": "#/definitions/ChargingLimitSourceEnumType"
+ },
+ "chargingProfile": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingProfileType"
+ },
+ "minItems": 1
+ },
+ "tbc": {
+ "description": "To Be Continued. Default value when omitted: false. false indicates that there are no further messages as part of this report.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "evseId": {
+ "description": "The evse to which the charging profile applies. If evseId = 0, the message contains an overall limit for the Charging Station.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["requestId", "chargingLimitSource", "evseId", "chargingProfile"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ReportChargingProfilesResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:RequestStartTransactionRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChargingProfileKindEnumType": {
+ "description": "Charging_ Profile. Charging_ Profile_ Kind. Charging_ Profile_ Kind_ Code\r\nurn:x-oca:ocpp:uid:1:569232\r\nIndicates the kind of schedule.\r\n",
+ "javaType": "ChargingProfileKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Absolute", "Recurring", "Relative"]
+ },
+ "ChargingProfilePurposeEnumType": {
+ "description": "Charging_ Profile. Charging_ Profile_ Purpose. Charging_ Profile_ Purpose_ Code\r\nurn:x-oca:ocpp:uid:1:569231\r\nDefines the purpose of the schedule transferred by this profile\r\n",
+ "javaType": "ChargingProfilePurposeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ChargingStationExternalConstraints",
+ "ChargingStationMaxProfile",
+ "TxDefaultProfile",
+ "TxProfile"
+ ]
+ },
+ "ChargingRateUnitEnumType": {
+ "description": "Charging_ Schedule. Charging_ Rate_ Unit. Charging_ Rate_ Unit_ Code\r\nurn:x-oca:ocpp:uid:1:569238\r\nThe unit of measure Limit is expressed in.\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "CostKindEnumType": {
+ "description": "Cost. Cost_ Kind. Cost_ Kind_ Code\r\nurn:x-oca:ocpp:uid:1:569243\r\nThe kind of cost referred to in the message element amount\r\n",
+ "javaType": "CostKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CarbonDioxideEmission", "RelativePricePercentage", "RenewableGenerationPercentage"]
+ },
+ "IdTokenEnumType": {
+ "description": "Enumeration of possible idToken types.\r\n",
+ "javaType": "IdTokenEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Central",
+ "eMAID",
+ "ISO14443",
+ "ISO15693",
+ "KeyCode",
+ "Local",
+ "MacAddress",
+ "NoAuthorization"
+ ]
+ },
+ "RecurrencyKindEnumType": {
+ "description": "Charging_ Profile. Recurrency_ Kind. Recurrency_ Kind_ Code\r\nurn:x-oca:ocpp:uid:1:569233\r\nIndicates the start point of a recurrence.\r\n",
+ "javaType": "RecurrencyKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Daily", "Weekly"]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalIdToken": {
+ "description": "This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "description": "This defines the type of the additionalIdToken. This is a custom type, so the implementation needs to be agreed upon by all involved parties.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "ChargingProfileType": {
+ "description": "Charging_ Profile\r\nurn:x-oca:ocpp:uid:2:233255\r\nA ChargingProfile consists of ChargingSchedule, describing the amount of power or current that can be delivered per time interval.\r\n",
+ "javaType": "ChargingProfile",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nId of ChargingProfile.\r\n",
+ "type": "integer"
+ },
+ "stackLevel": {
+ "description": "Charging_ Profile. Stack_ Level. Counter\r\nurn:x-oca:ocpp:uid:1:569230\r\nValue determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.\r\n",
+ "type": "integer"
+ },
+ "chargingProfilePurpose": {
+ "$ref": "#/definitions/ChargingProfilePurposeEnumType"
+ },
+ "chargingProfileKind": {
+ "$ref": "#/definitions/ChargingProfileKindEnumType"
+ },
+ "recurrencyKind": {
+ "$ref": "#/definitions/RecurrencyKindEnumType"
+ },
+ "validFrom": {
+ "description": "Charging_ Profile. Valid_ From. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569234\r\nPoint in time at which the profile starts to be valid. If absent, the profile is valid as soon as it is received by the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "validTo": {
+ "description": "Charging_ Profile. Valid_ To. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569235\r\nPoint in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingSchedule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingScheduleType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "transactionId": {
+ "description": "SHALL only be included if ChargingProfilePurpose is set to TxProfile. The transactionId is used to match the profile to a specific transaction.\r\n",
+ "type": "string",
+ "maxLength": 36
+ }
+ },
+ "required": [
+ "id",
+ "stackLevel",
+ "chargingProfilePurpose",
+ "chargingProfileKind",
+ "chargingSchedule"
+ ]
+ },
+ "ChargingSchedulePeriodType": {
+ "description": "Charging_ Schedule_ Period\r\nurn:x-oca:ocpp:uid:2:233257\r\nCharging schedule period structure defines a time period in a charging schedule.\r\n",
+ "javaType": "ChargingSchedulePeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "startPeriod": {
+ "description": "Charging_ Schedule_ Period. Start_ Period. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569240\r\nStart of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.\r\n",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Charging_ Schedule_ Period. Limit. Measure\r\nurn:x-oca:ocpp:uid:1:569241\r\nCharging rate limit during the schedule period, in the applicable chargingRateUnit, for example in Amperes (A) or Watts (W). Accepts at most one digit fraction (e.g. 8.1).\r\n",
+ "type": "number"
+ },
+ "numberPhases": {
+ "description": "Charging_ Schedule_ Period. Number_ Phases. Counter\r\nurn:x-oca:ocpp:uid:1:569242\r\nThe number of phases that can be used for charging. If a number of phases is needed, numberPhases=3 will be assumed unless another number is given.\r\n",
+ "type": "integer"
+ },
+ "phaseToUse": {
+ "description": "Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true. It’s not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.\r\n\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["startPeriod", "limit"]
+ },
+ "ChargingScheduleType": {
+ "description": "Charging_ Schedule\r\nurn:x-oca:ocpp:uid:2:233256\r\nCharging schedule structure defines a list of charging periods, as used in: GetCompositeSchedule.conf and ChargingProfile. \r\n",
+ "javaType": "ChargingSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identifies the ChargingSchedule.\r\n",
+ "type": "integer"
+ },
+ "startSchedule": {
+ "description": "Charging_ Schedule. Start_ Schedule. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569237\r\nStarting point of an absolute schedule. If absent the schedule will be relative to start of charging.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Charging_ Schedule. Duration. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569236\r\nDuration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction if chargingProfilePurpose = TxProfile.\r\n",
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingSchedulePeriodType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "minChargingRate": {
+ "description": "Charging_ Schedule. Min_ Charging_ Rate. Numeric\r\nurn:x-oca:ocpp:uid:1:569239\r\nMinimum charging rate supported by the EV. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates. Accepts at most one digit fraction (e.g. 8.1)\r\n",
+ "type": "number"
+ },
+ "salesTariff": {
+ "$ref": "#/definitions/SalesTariffType"
+ }
+ },
+ "required": ["id", "chargingRateUnit", "chargingSchedulePeriod"]
+ },
+ "ConsumptionCostType": {
+ "description": "Consumption_ Cost\r\nurn:x-oca:ocpp:uid:2:233259\r\n",
+ "javaType": "ConsumptionCost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "startValue": {
+ "description": "Consumption_ Cost. Start_ Value. Numeric\r\nurn:x-oca:ocpp:uid:1:569246\r\nThe lowest level of consumption that defines the starting point of this consumption block. The block interval extends to the start of the next interval.\r\n",
+ "type": "number"
+ },
+ "cost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ }
+ },
+ "required": ["startValue", "cost"]
+ },
+ "CostType": {
+ "description": "Cost\r\nurn:x-oca:ocpp:uid:2:233258\r\n",
+ "javaType": "Cost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "costKind": {
+ "$ref": "#/definitions/CostKindEnumType"
+ },
+ "amount": {
+ "description": "Cost. Amount. Amount\r\nurn:x-oca:ocpp:uid:1:569244\r\nThe estimated or actual cost per kWh\r\n",
+ "type": "integer"
+ },
+ "amountMultiplier": {
+ "description": "Cost. Amount_ Multiplier. Integer\r\nurn:x-oca:ocpp:uid:1:569245\r\nValues: -3..3, The amountMultiplier defines the exponent to base 10 (dec). The final value is determined by: amount * 10 ^ amountMultiplier\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["costKind", "amount"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "$ref": "#/definitions/IdTokenEnumType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "RelativeTimeIntervalType": {
+ "description": "Relative_ Timer_ Interval\r\nurn:x-oca:ocpp:uid:2:233270\r\n",
+ "javaType": "RelativeTimeInterval",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "start": {
+ "description": "Relative_ Timer_ Interval. Start. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569279\r\nStart of the interval, in seconds from NOW.\r\n",
+ "type": "integer"
+ },
+ "duration": {
+ "description": "Relative_ Timer_ Interval. Duration. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569280\r\nDuration of the interval, in seconds.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["start"]
+ },
+ "SalesTariffEntryType": {
+ "description": "Sales_ Tariff_ Entry\r\nurn:x-oca:ocpp:uid:2:233271\r\n",
+ "javaType": "SalesTariffEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "relativeTimeInterval": {
+ "$ref": "#/definitions/RelativeTimeIntervalType"
+ },
+ "ePriceLevel": {
+ "description": "Sales_ Tariff_ Entry. E_ Price_ Level. Unsigned_ Integer\r\nurn:x-oca:ocpp:uid:1:569281\r\nDefines the price level of this SalesTariffEntry (referring to NumEPriceLevels). Small values for the EPriceLevel represent a cheaper TariffEntry. Large values for the EPriceLevel represent a more expensive TariffEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "consumptionCost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ConsumptionCostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ }
+ },
+ "required": ["relativeTimeInterval"]
+ },
+ "SalesTariffType": {
+ "description": "Sales_ Tariff\r\nurn:x-oca:ocpp:uid:2:233272\r\nNOTE: This dataType is based on dataTypes from <<ref-ISOIEC15118-2,ISO 15118-2>>.\r\n",
+ "javaType": "SalesTariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nSalesTariff identifier used to identify one sales tariff. An SAID remains a unique identifier for one schedule throughout a charging session.\r\n",
+ "type": "integer"
+ },
+ "salesTariffDescription": {
+ "description": "Sales_ Tariff. Sales. Tariff_ Description\r\nurn:x-oca:ocpp:uid:1:569283\r\nA human readable title/short description of the sales tariff e.g. for HMI display purposes.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numEPriceLevels": {
+ "description": "Sales_ Tariff. Num_ E_ Price_ Levels. Counter\r\nurn:x-oca:ocpp:uid:1:569284\r\nDefines the overall number of distinct price levels used across all provided SalesTariff elements.\r\n",
+ "type": "integer"
+ },
+ "salesTariffEntry": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SalesTariffEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ }
+ },
+ "required": ["id", "salesTariffEntry"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evseId": {
+ "description": "Number of the EVSE on which to start the transaction. EvseId SHALL be > 0\r\n",
+ "type": "integer"
+ },
+ "groupIdToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "remoteStartId": {
+ "description": "Id given by the server to this start request. The Charging Station might return this in the <<transactioneventrequest, TransactionEventRequest>>, letting the server know which transaction was started for this request. Use to start a transaction.\r\n",
+ "type": "integer"
+ },
+ "chargingProfile": {
+ "$ref": "#/definitions/ChargingProfileType"
+ }
+ },
+ "required": ["remoteStartId", "idToken"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:RequestStartTransactionResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "RequestStartStopStatusEnumType": {
+ "description": "Status indicating whether the Charging Station accepts the request to start a transaction.\r\n",
+ "javaType": "RequestStartStopStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/RequestStartStopStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "transactionId": {
+ "description": "When the transaction was already started by the Charging Station before the RequestStartTransactionRequest was received, for example: cable plugged in first. This contains the transactionId of the already started transaction.\r\n",
+ "type": "string",
+ "maxLength": 36
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:RequestStopTransactionRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "transactionId": {
+ "description": "The identifier of the transaction which the Charging Station is requested to stop.\r\n",
+ "type": "string",
+ "maxLength": 36
+ }
+ },
+ "required": ["transactionId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:RequestStopTransactionResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "RequestStartStopStatusEnumType": {
+ "description": "Status indicating whether Charging Station accepts the request to stop a transaction.\r\n",
+ "javaType": "RequestStartStopStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/RequestStartStopStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ReservationStatusUpdateRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ReservationUpdateStatusEnumType": {
+ "description": "The updated reservation status.\r\n",
+ "javaType": "ReservationUpdateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Expired", "Removed"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reservationId": {
+ "description": "The ID of the reservation.\r\n",
+ "type": "integer"
+ },
+ "reservationUpdateStatus": {
+ "$ref": "#/definitions/ReservationUpdateStatusEnumType"
+ }
+ },
+ "required": ["reservationId", "reservationUpdateStatus"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ReservationStatusUpdateResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ReserveNowRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ConnectorEnumType": {
+ "description": "This field specifies the connector type.\r\n",
+ "javaType": "ConnectorEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "cCCS1",
+ "cCCS2",
+ "cG105",
+ "cTesla",
+ "cType1",
+ "cType2",
+ "s309-1P-16A",
+ "s309-1P-32A",
+ "s309-3P-16A",
+ "s309-3P-32A",
+ "sBS1361",
+ "sCEE-7-7",
+ "sType2",
+ "sType3",
+ "Other1PhMax16A",
+ "Other1PhOver16A",
+ "Other3Ph",
+ "Pan",
+ "wInductive",
+ "wResonant",
+ "Undetermined",
+ "Unknown"
+ ]
+ },
+ "IdTokenEnumType": {
+ "description": "Enumeration of possible idToken types.\r\n",
+ "javaType": "IdTokenEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Central",
+ "eMAID",
+ "ISO14443",
+ "ISO15693",
+ "KeyCode",
+ "Local",
+ "MacAddress",
+ "NoAuthorization"
+ ]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalIdToken": {
+ "description": "This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "description": "This defines the type of the additionalIdToken. This is a custom type, so the implementation needs to be agreed upon by all involved parties.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "$ref": "#/definitions/IdTokenEnumType"
+ }
+ },
+ "required": ["idToken", "type"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Id of reservation.\r\n",
+ "type": "integer"
+ },
+ "expiryDateTime": {
+ "description": "Date and time at which the reservation expires.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "connectorType": {
+ "$ref": "#/definitions/ConnectorEnumType"
+ },
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "evseId": {
+ "description": "This contains ID of the evse to be reserved.\r\n",
+ "type": "integer"
+ },
+ "groupIdToken": {
+ "$ref": "#/definitions/IdTokenType"
+ }
+ },
+ "required": ["id", "expiryDateTime", "idToken"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ReserveNowResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ReserveNowStatusEnumType": {
+ "description": "This indicates the success or failure of the reservation.\r\n",
+ "javaType": "ReserveNowStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Faulted", "Occupied", "Rejected", "Unavailable"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/ReserveNowStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ResetRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ResetEnumType": {
+ "description": "This contains the type of reset that the Charging Station or EVSE should perform.\r\n",
+ "javaType": "ResetEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Immediate", "OnIdle"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "type": {
+ "$ref": "#/definitions/ResetEnumType"
+ },
+ "evseId": {
+ "description": "This contains the ID of a specific EVSE that needs to be reset, instead of the entire Charging Station.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["type"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:ResetResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ResetStatusEnumType": {
+ "description": "This indicates whether the Charging Station is able to perform the reset.\r\n",
+ "javaType": "ResetStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Scheduled"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/ResetStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SecurityEventNotificationRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "type": {
+ "description": "Type of the security event. This value should be taken from the Security events list.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "timestamp": {
+ "description": "Date and time at which the event occurred.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "techInfo": {
+ "description": "Additional information about the occurred security event.\r\n",
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["type", "timestamp"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SecurityEventNotificationResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SendLocalListRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "AuthorizationStatusEnumType": {
+ "description": "ID_ Token. Status. Authorization_ Status\r\nurn:x-oca:ocpp:uid:1:569372\r\nCurrent status of the ID Token.\r\n",
+ "javaType": "AuthorizationStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Blocked",
+ "ConcurrentTx",
+ "Expired",
+ "Invalid",
+ "NoCredit",
+ "NotAllowedTypeEVSE",
+ "NotAtThisLocation",
+ "NotAtThisTime",
+ "Unknown"
+ ]
+ },
+ "IdTokenEnumType": {
+ "description": "Enumeration of possible idToken types.\r\n",
+ "javaType": "IdTokenEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Central",
+ "eMAID",
+ "ISO14443",
+ "ISO15693",
+ "KeyCode",
+ "Local",
+ "MacAddress",
+ "NoAuthorization"
+ ]
+ },
+ "MessageFormatEnumType": {
+ "description": "Message_ Content. Format. Message_ Format_ Code\r\nurn:x-enexis:ecdm:uid:1:570848\r\nFormat of the message.\r\n",
+ "javaType": "MessageFormatEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ASCII", "HTML", "URI", "UTF8"]
+ },
+ "UpdateEnumType": {
+ "description": "This contains the type of update (full or differential) of this request.\r\n",
+ "javaType": "UpdateEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Differential", "Full"]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalIdToken": {
+ "description": "This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "description": "This defines the type of the additionalIdToken. This is a custom type, so the implementation needs to be agreed upon by all involved parties.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "AuthorizationData": {
+ "description": "Contains the identifier to use for authorization.\r\n",
+ "javaType": "AuthorizationData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "idTokenInfo": {
+ "$ref": "#/definitions/IdTokenInfoType"
+ }
+ },
+ "required": ["idToken"]
+ },
+ "IdTokenInfoType": {
+ "description": "ID_ Token\r\nurn:x-oca:ocpp:uid:2:233247\r\nContains status information about an identifier.\r\nIt is advised to not stop charging for a token that expires during charging, as ExpiryDate is only used for caching purposes. If ExpiryDate is not given, the status has no end date.\r\n",
+ "javaType": "IdTokenInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/AuthorizationStatusEnumType"
+ },
+ "cacheExpiryDateTime": {
+ "description": "ID_ Token. Expiry. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569373\r\nDate and Time after which the token must be considered invalid.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingPriority": {
+ "description": "Priority from a business point of view. Default priority is 0, The range is from -9 to 9. Higher values indicate a higher priority. The chargingPriority in <<transactioneventresponse,TransactionEventResponse>> overrules this one. \r\n",
+ "type": "integer"
+ },
+ "language1": {
+ "description": "ID_ Token. Language1. Language_ Code\r\nurn:x-oca:ocpp:uid:1:569374\r\nPreferred user interface language of identifier user. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "evseId": {
+ "description": "Only used when the IdToken is only valid for one or more specific EVSEs, not for the entire Charging Station.\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer"
+ },
+ "minItems": 1
+ },
+ "groupIdToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "language2": {
+ "description": "ID_ Token. Language2. Language_ Code\r\nurn:x-oca:ocpp:uid:1:569375\r\nSecond preferred user interface language of identifier user. Don’t use when language1 is omitted, has to be different from language1. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "personalMessage": {
+ "$ref": "#/definitions/MessageContentType"
+ }
+ },
+ "required": ["status"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "$ref": "#/definitions/IdTokenEnumType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "MessageContentType": {
+ "description": "Message_ Content\r\nurn:x-enexis:ecdm:uid:2:234490\r\nContains message details, for a message to be displayed on a Charging Station.\r\n\r\n",
+ "javaType": "MessageContent",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "format": {
+ "$ref": "#/definitions/MessageFormatEnumType"
+ },
+ "language": {
+ "description": "Message_ Content. Language. Language_ Code\r\nurn:x-enexis:ecdm:uid:1:570849\r\nMessage language identifier. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "content": {
+ "description": "Message_ Content. Content. Message\r\nurn:x-enexis:ecdm:uid:1:570852\r\nMessage contents.\r\n\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["format", "content"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "localAuthorizationList": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AuthorizationData"
+ },
+ "minItems": 1
+ },
+ "versionNumber": {
+ "description": "In case of a full update this is the version number of the full list. In case of a differential update it is the version number of the list after the update has been applied.\r\n",
+ "type": "integer"
+ },
+ "updateType": {
+ "$ref": "#/definitions/UpdateEnumType"
+ }
+ },
+ "required": ["versionNumber", "updateType"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SendLocalListResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "SendLocalListStatusEnumType": {
+ "description": "This indicates whether the Charging Station has successfully received and applied the update of the Local Authorization List.\r\n",
+ "javaType": "SendLocalListStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Failed", "VersionMismatch"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/SendLocalListStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetChargingProfileRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChargingProfileKindEnumType": {
+ "description": "Charging_ Profile. Charging_ Profile_ Kind. Charging_ Profile_ Kind_ Code\r\nurn:x-oca:ocpp:uid:1:569232\r\nIndicates the kind of schedule.\r\n",
+ "javaType": "ChargingProfileKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Absolute", "Recurring", "Relative"]
+ },
+ "ChargingProfilePurposeEnumType": {
+ "description": "Charging_ Profile. Charging_ Profile_ Purpose. Charging_ Profile_ Purpose_ Code\r\nurn:x-oca:ocpp:uid:1:569231\r\nDefines the purpose of the schedule transferred by this profile\r\n",
+ "javaType": "ChargingProfilePurposeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ChargingStationExternalConstraints",
+ "ChargingStationMaxProfile",
+ "TxDefaultProfile",
+ "TxProfile"
+ ]
+ },
+ "ChargingRateUnitEnumType": {
+ "description": "Charging_ Schedule. Charging_ Rate_ Unit. Charging_ Rate_ Unit_ Code\r\nurn:x-oca:ocpp:uid:1:569238\r\nThe unit of measure Limit is expressed in.\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "CostKindEnumType": {
+ "description": "Cost. Cost_ Kind. Cost_ Kind_ Code\r\nurn:x-oca:ocpp:uid:1:569243\r\nThe kind of cost referred to in the message element amount\r\n",
+ "javaType": "CostKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CarbonDioxideEmission", "RelativePricePercentage", "RenewableGenerationPercentage"]
+ },
+ "RecurrencyKindEnumType": {
+ "description": "Charging_ Profile. Recurrency_ Kind. Recurrency_ Kind_ Code\r\nurn:x-oca:ocpp:uid:1:569233\r\nIndicates the start point of a recurrence.\r\n",
+ "javaType": "RecurrencyKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Daily", "Weekly"]
+ },
+ "ChargingProfileType": {
+ "description": "Charging_ Profile\r\nurn:x-oca:ocpp:uid:2:233255\r\nA ChargingProfile consists of ChargingSchedule, describing the amount of power or current that can be delivered per time interval.\r\n",
+ "javaType": "ChargingProfile",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nId of ChargingProfile.\r\n",
+ "type": "integer"
+ },
+ "stackLevel": {
+ "description": "Charging_ Profile. Stack_ Level. Counter\r\nurn:x-oca:ocpp:uid:1:569230\r\nValue determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.\r\n",
+ "type": "integer"
+ },
+ "chargingProfilePurpose": {
+ "$ref": "#/definitions/ChargingProfilePurposeEnumType"
+ },
+ "chargingProfileKind": {
+ "$ref": "#/definitions/ChargingProfileKindEnumType"
+ },
+ "recurrencyKind": {
+ "$ref": "#/definitions/RecurrencyKindEnumType"
+ },
+ "validFrom": {
+ "description": "Charging_ Profile. Valid_ From. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569234\r\nPoint in time at which the profile starts to be valid. If absent, the profile is valid as soon as it is received by the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "validTo": {
+ "description": "Charging_ Profile. Valid_ To. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569235\r\nPoint in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingSchedule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingScheduleType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "transactionId": {
+ "description": "SHALL only be included if ChargingProfilePurpose is set to TxProfile. The transactionId is used to match the profile to a specific transaction.\r\n",
+ "type": "string",
+ "maxLength": 36
+ }
+ },
+ "required": [
+ "id",
+ "stackLevel",
+ "chargingProfilePurpose",
+ "chargingProfileKind",
+ "chargingSchedule"
+ ]
+ },
+ "ChargingSchedulePeriodType": {
+ "description": "Charging_ Schedule_ Period\r\nurn:x-oca:ocpp:uid:2:233257\r\nCharging schedule period structure defines a time period in a charging schedule.\r\n",
+ "javaType": "ChargingSchedulePeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "startPeriod": {
+ "description": "Charging_ Schedule_ Period. Start_ Period. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569240\r\nStart of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.\r\n",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Charging_ Schedule_ Period. Limit. Measure\r\nurn:x-oca:ocpp:uid:1:569241\r\nCharging rate limit during the schedule period, in the applicable chargingRateUnit, for example in Amperes (A) or Watts (W). Accepts at most one digit fraction (e.g. 8.1).\r\n",
+ "type": "number"
+ },
+ "numberPhases": {
+ "description": "Charging_ Schedule_ Period. Number_ Phases. Counter\r\nurn:x-oca:ocpp:uid:1:569242\r\nThe number of phases that can be used for charging. If a number of phases is needed, numberPhases=3 will be assumed unless another number is given.\r\n",
+ "type": "integer"
+ },
+ "phaseToUse": {
+ "description": "Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true. It’s not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.\r\n\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["startPeriod", "limit"]
+ },
+ "ChargingScheduleType": {
+ "description": "Charging_ Schedule\r\nurn:x-oca:ocpp:uid:2:233256\r\nCharging schedule structure defines a list of charging periods, as used in: GetCompositeSchedule.conf and ChargingProfile. \r\n",
+ "javaType": "ChargingSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identifies the ChargingSchedule.\r\n",
+ "type": "integer"
+ },
+ "startSchedule": {
+ "description": "Charging_ Schedule. Start_ Schedule. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569237\r\nStarting point of an absolute schedule. If absent the schedule will be relative to start of charging.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Charging_ Schedule. Duration. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569236\r\nDuration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction if chargingProfilePurpose = TxProfile.\r\n",
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingSchedulePeriodType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "minChargingRate": {
+ "description": "Charging_ Schedule. Min_ Charging_ Rate. Numeric\r\nurn:x-oca:ocpp:uid:1:569239\r\nMinimum charging rate supported by the EV. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates. Accepts at most one digit fraction (e.g. 8.1)\r\n",
+ "type": "number"
+ },
+ "salesTariff": {
+ "$ref": "#/definitions/SalesTariffType"
+ }
+ },
+ "required": ["id", "chargingRateUnit", "chargingSchedulePeriod"]
+ },
+ "ConsumptionCostType": {
+ "description": "Consumption_ Cost\r\nurn:x-oca:ocpp:uid:2:233259\r\n",
+ "javaType": "ConsumptionCost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "startValue": {
+ "description": "Consumption_ Cost. Start_ Value. Numeric\r\nurn:x-oca:ocpp:uid:1:569246\r\nThe lowest level of consumption that defines the starting point of this consumption block. The block interval extends to the start of the next interval.\r\n",
+ "type": "number"
+ },
+ "cost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ }
+ },
+ "required": ["startValue", "cost"]
+ },
+ "CostType": {
+ "description": "Cost\r\nurn:x-oca:ocpp:uid:2:233258\r\n",
+ "javaType": "Cost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "costKind": {
+ "$ref": "#/definitions/CostKindEnumType"
+ },
+ "amount": {
+ "description": "Cost. Amount. Amount\r\nurn:x-oca:ocpp:uid:1:569244\r\nThe estimated or actual cost per kWh\r\n",
+ "type": "integer"
+ },
+ "amountMultiplier": {
+ "description": "Cost. Amount_ Multiplier. Integer\r\nurn:x-oca:ocpp:uid:1:569245\r\nValues: -3..3, The amountMultiplier defines the exponent to base 10 (dec). The final value is determined by: amount * 10 ^ amountMultiplier\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["costKind", "amount"]
+ },
+ "RelativeTimeIntervalType": {
+ "description": "Relative_ Timer_ Interval\r\nurn:x-oca:ocpp:uid:2:233270\r\n",
+ "javaType": "RelativeTimeInterval",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "start": {
+ "description": "Relative_ Timer_ Interval. Start. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569279\r\nStart of the interval, in seconds from NOW.\r\n",
+ "type": "integer"
+ },
+ "duration": {
+ "description": "Relative_ Timer_ Interval. Duration. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569280\r\nDuration of the interval, in seconds.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["start"]
+ },
+ "SalesTariffEntryType": {
+ "description": "Sales_ Tariff_ Entry\r\nurn:x-oca:ocpp:uid:2:233271\r\n",
+ "javaType": "SalesTariffEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "relativeTimeInterval": {
+ "$ref": "#/definitions/RelativeTimeIntervalType"
+ },
+ "ePriceLevel": {
+ "description": "Sales_ Tariff_ Entry. E_ Price_ Level. Unsigned_ Integer\r\nurn:x-oca:ocpp:uid:1:569281\r\nDefines the price level of this SalesTariffEntry (referring to NumEPriceLevels). Small values for the EPriceLevel represent a cheaper TariffEntry. Large values for the EPriceLevel represent a more expensive TariffEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "consumptionCost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ConsumptionCostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ }
+ },
+ "required": ["relativeTimeInterval"]
+ },
+ "SalesTariffType": {
+ "description": "Sales_ Tariff\r\nurn:x-oca:ocpp:uid:2:233272\r\nNOTE: This dataType is based on dataTypes from <<ref-ISOIEC15118-2,ISO 15118-2>>.\r\n",
+ "javaType": "SalesTariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nSalesTariff identifier used to identify one sales tariff. An SAID remains a unique identifier for one schedule throughout a charging session.\r\n",
+ "type": "integer"
+ },
+ "salesTariffDescription": {
+ "description": "Sales_ Tariff. Sales. Tariff_ Description\r\nurn:x-oca:ocpp:uid:1:569283\r\nA human readable title/short description of the sales tariff e.g. for HMI display purposes.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numEPriceLevels": {
+ "description": "Sales_ Tariff. Num_ E_ Price_ Levels. Counter\r\nurn:x-oca:ocpp:uid:1:569284\r\nDefines the overall number of distinct price levels used across all provided SalesTariff elements.\r\n",
+ "type": "integer"
+ },
+ "salesTariffEntry": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SalesTariffEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ }
+ },
+ "required": ["id", "salesTariffEntry"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evseId": {
+ "description": "For TxDefaultProfile an evseId=0 applies the profile to each individual evse. For ChargingStationMaxProfile and ChargingStationExternalConstraints an evseId=0 contains an overal limit for the whole Charging Station.\r\n",
+ "type": "integer"
+ },
+ "chargingProfile": {
+ "$ref": "#/definitions/ChargingProfileType"
+ }
+ },
+ "required": ["evseId", "chargingProfile"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetChargingProfileResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChargingProfileStatusEnumType": {
+ "description": "Returns whether the Charging Station has been able to process the message successfully. This does not guarantee the schedule will be followed to the letter. There might be other constraints the Charging Station may need to take into account.\r\n",
+ "javaType": "ChargingProfileStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/ChargingProfileStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetDisplayMessageRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "MessageFormatEnumType": {
+ "description": "Message_ Content. Format. Message_ Format_ Code\r\nurn:x-enexis:ecdm:uid:1:570848\r\nFormat of the message.\r\n",
+ "javaType": "MessageFormatEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ASCII", "HTML", "URI", "UTF8"]
+ },
+ "MessagePriorityEnumType": {
+ "description": "Message_ Info. Priority. Message_ Priority_ Code\r\nurn:x-enexis:ecdm:uid:1:569253\r\nWith what priority should this message be shown\r\n",
+ "javaType": "MessagePriorityEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["AlwaysFront", "InFront", "NormalCycle"]
+ },
+ "MessageStateEnumType": {
+ "description": "Message_ Info. State. Message_ State_ Code\r\nurn:x-enexis:ecdm:uid:1:569254\r\nDuring what state should this message be shown. When omitted this message should be shown in any state of the Charging Station.\r\n",
+ "javaType": "MessageStateEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Charging", "Faulted", "Idle", "Unavailable"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "MessageContentType": {
+ "description": "Message_ Content\r\nurn:x-enexis:ecdm:uid:2:234490\r\nContains message details, for a message to be displayed on a Charging Station.\r\n\r\n",
+ "javaType": "MessageContent",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "format": {
+ "$ref": "#/definitions/MessageFormatEnumType"
+ },
+ "language": {
+ "description": "Message_ Content. Language. Language_ Code\r\nurn:x-enexis:ecdm:uid:1:570849\r\nMessage language identifier. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "content": {
+ "description": "Message_ Content. Content. Message\r\nurn:x-enexis:ecdm:uid:1:570852\r\nMessage contents.\r\n\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["format", "content"]
+ },
+ "MessageInfoType": {
+ "description": "Message_ Info\r\nurn:x-enexis:ecdm:uid:2:233264\r\nContains message details, for a message to be displayed on a Charging Station.\r\n",
+ "javaType": "MessageInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "display": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nMaster resource identifier, unique within an exchange context. It is defined within the OCPP context as a positive Integer value (greater or equal to zero).\r\n",
+ "type": "integer"
+ },
+ "priority": {
+ "$ref": "#/definitions/MessagePriorityEnumType"
+ },
+ "state": {
+ "$ref": "#/definitions/MessageStateEnumType"
+ },
+ "startDateTime": {
+ "description": "Message_ Info. Start. Date_ Time\r\nurn:x-enexis:ecdm:uid:1:569256\r\nFrom what date-time should this message be shown. If omitted: directly.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "endDateTime": {
+ "description": "Message_ Info. End. Date_ Time\r\nurn:x-enexis:ecdm:uid:1:569257\r\nUntil what date-time should this message be shown, after this date/time this message SHALL be removed.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "transactionId": {
+ "description": "During which transaction shall this message be shown.\r\nMessage SHALL be removed by the Charging Station after transaction has\r\nended.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "message": {
+ "$ref": "#/definitions/MessageContentType"
+ }
+ },
+ "required": ["id", "priority", "message"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "message": {
+ "$ref": "#/definitions/MessageInfoType"
+ }
+ },
+ "required": ["message"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetDisplayMessageResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "DisplayMessageStatusEnumType": {
+ "description": "This indicates whether the Charging Station is able to display the message.\r\n",
+ "javaType": "DisplayMessageStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "NotSupportedMessageFormat",
+ "Rejected",
+ "NotSupportedPriority",
+ "NotSupportedState",
+ "UnknownTransaction"
+ ]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/DisplayMessageStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetMonitoringBaseRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "MonitoringBaseEnumType": {
+ "description": "Specify which monitoring base will be set\r\n",
+ "javaType": "MonitoringBaseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["All", "FactoryDefault", "HardWiredOnly"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "monitoringBase": {
+ "$ref": "#/definitions/MonitoringBaseEnumType"
+ }
+ },
+ "required": ["monitoringBase"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetMonitoringBaseResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GenericDeviceModelStatusEnumType": {
+ "description": "Indicates whether the Charging Station was able to accept the request.\r\n",
+ "javaType": "GenericDeviceModelStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotSupported", "EmptyResultSet"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GenericDeviceModelStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetMonitoringLevelRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "severity": {
+ "description": "The Charging Station SHALL only report events with a severity number lower than or equal to this severity.\r\nThe severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.\r\n\r\nThe severity levels have the following meaning: +\r\n*0-Danger* +\r\nIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately. +\r\n*1-Hardware Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required. +\r\n*2-System Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required. +\r\n*3-Critical* +\r\nIndicates a critical error. Action is required. +\r\n*4-Error* +\r\nIndicates a non-urgent error. Action is required. +\r\n*5-Alert* +\r\nIndicates an alert event. Default severity for any type of monitoring event. +\r\n*6-Warning* +\r\nIndicates a warning event. Action may be required. +\r\n*7-Notice* +\r\nIndicates an unusual event. No immediate action is required. +\r\n*8-Informational* +\r\nIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required. +\r\n*9-Debug* +\r\nIndicates information useful to developers for debugging, not useful during operations.\r\n\r\n\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["severity"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetMonitoringLevelResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GenericStatusEnumType": {
+ "description": "Indicates whether the Charging Station was able to accept the request.\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetNetworkProfileRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "APNAuthenticationEnumType": {
+ "description": "APN. APN_ Authentication. APN_ Authentication_ Code\r\nurn:x-oca:ocpp:uid:1:568828\r\nAuthentication method.\r\n",
+ "javaType": "APNAuthenticationEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CHAP", "NONE", "PAP", "AUTO"]
+ },
+ "OCPPInterfaceEnumType": {
+ "description": "Applicable Network Interface.\r\n",
+ "javaType": "OCPPInterfaceEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Wired0",
+ "Wired1",
+ "Wired2",
+ "Wired3",
+ "Wireless0",
+ "Wireless1",
+ "Wireless2",
+ "Wireless3"
+ ]
+ },
+ "OCPPTransportEnumType": {
+ "description": "Communication_ Function. OCPP_ Transport. OCPP_ Transport_ Code\r\nurn:x-oca:ocpp:uid:1:569356\r\nDefines the transport protocol (e.g. SOAP or JSON). Note: SOAP is not supported in OCPP 2.0, but is supported by other versions of OCPP.\r\n",
+ "javaType": "OCPPTransportEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["JSON", "SOAP"]
+ },
+ "OCPPVersionEnumType": {
+ "description": "Communication_ Function. OCPP_ Version. OCPP_ Version_ Code\r\nurn:x-oca:ocpp:uid:1:569355\r\nDefines the OCPP version used for this communication function.\r\n",
+ "javaType": "OCPPVersionEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["OCPP12", "OCPP15", "OCPP16", "OCPP20"]
+ },
+ "VPNEnumType": {
+ "description": "VPN. Type. VPN_ Code\r\nurn:x-oca:ocpp:uid:1:569277\r\nType of VPN\r\n",
+ "javaType": "VPNEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["IKEv2", "IPSec", "L2TP", "PPTP"]
+ },
+ "APNType": {
+ "description": "APN\r\nurn:x-oca:ocpp:uid:2:233134\r\nCollection of configuration data needed to make a data-connection over a cellular network.\r\n\r\nNOTE: When asking a GSM modem to dial in, it is possible to specify which mobile operator should be used. This can be done with the mobile country code (MCC) in combination with a mobile network code (MNC). Example: If your preferred network is Vodafone Netherlands, the MCC=204 and the MNC=04 which means the key PreferredNetwork = 20404 Some modems allows to specify a preferred network, which means, if this network is not available, a different network is used. If you specify UseOnlyPreferredNetwork and this network is not available, the modem will not dial in.\r\n",
+ "javaType": "APN",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "apn": {
+ "description": "APN. APN. URI\r\nurn:x-oca:ocpp:uid:1:568814\r\nThe Access Point Name as an URL.\r\n",
+ "type": "string",
+ "maxLength": 512
+ },
+ "apnUserName": {
+ "description": "APN. APN. User_ Name\r\nurn:x-oca:ocpp:uid:1:568818\r\nAPN username.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "apnPassword": {
+ "description": "APN. APN. Password\r\nurn:x-oca:ocpp:uid:1:568819\r\nAPN Password.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "simPin": {
+ "description": "APN. SIMPIN. PIN_ Code\r\nurn:x-oca:ocpp:uid:1:568821\r\nSIM card pin code.\r\n",
+ "type": "integer"
+ },
+ "preferredNetwork": {
+ "description": "APN. Preferred_ Network. Mobile_ Network_ ID\r\nurn:x-oca:ocpp:uid:1:568822\r\nPreferred network, written as MCC and MNC concatenated. See note.\r\n",
+ "type": "string",
+ "maxLength": 6
+ },
+ "useOnlyPreferredNetwork": {
+ "description": "APN. Use_ Only_ Preferred_ Network. Indicator\r\nurn:x-oca:ocpp:uid:1:568824\r\nDefault: false. Use only the preferred Network, do\r\nnot dial in when not available. See Note.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "apnAuthentication": {
+ "$ref": "#/definitions/APNAuthenticationEnumType"
+ }
+ },
+ "required": ["apn", "apnAuthentication"]
+ },
+ "NetworkConnectionProfileType": {
+ "description": "Communication_ Function\r\nurn:x-oca:ocpp:uid:2:233304\r\nThe NetworkConnectionProfile defines the functional and technical parameters of a communication link.\r\n",
+ "javaType": "NetworkConnectionProfile",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "apn": {
+ "$ref": "#/definitions/APNType"
+ },
+ "ocppVersion": {
+ "$ref": "#/definitions/OCPPVersionEnumType"
+ },
+ "ocppTransport": {
+ "$ref": "#/definitions/OCPPTransportEnumType"
+ },
+ "ocppCsmsUrl": {
+ "description": "Communication_ Function. OCPP_ Central_ System_ URL. URI\r\nurn:x-oca:ocpp:uid:1:569357\r\nURL of the CSMS(s) that this Charging Station communicates with.\r\n",
+ "type": "string",
+ "maxLength": 512
+ },
+ "messageTimeout": {
+ "description": "Duration in seconds before a message send by the Charging Station via this network connection times-out.\r\nThe best setting depends on the underlying network and response times of the CSMS.\r\nIf you are looking for a some guideline: use 30 seconds as a starting point.\r\n",
+ "type": "integer"
+ },
+ "securityProfile": {
+ "description": "This field specifies the security profile used when connecting to the CSMS with this NetworkConnectionProfile.\r\n",
+ "type": "integer"
+ },
+ "ocppInterface": {
+ "$ref": "#/definitions/OCPPInterfaceEnumType"
+ },
+ "vpn": {
+ "$ref": "#/definitions/VPNType"
+ }
+ },
+ "required": [
+ "ocppVersion",
+ "ocppTransport",
+ "ocppCsmsUrl",
+ "messageTimeout",
+ "securityProfile",
+ "ocppInterface"
+ ]
+ },
+ "VPNType": {
+ "description": "VPN\r\nurn:x-oca:ocpp:uid:2:233268\r\nVPN Configuration settings\r\n",
+ "javaType": "VPN",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "server": {
+ "description": "VPN. Server. URI\r\nurn:x-oca:ocpp:uid:1:569272\r\nVPN Server Address\r\n",
+ "type": "string",
+ "maxLength": 512
+ },
+ "user": {
+ "description": "VPN. User. User_ Name\r\nurn:x-oca:ocpp:uid:1:569273\r\nVPN User\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "group": {
+ "description": "VPN. Group. Group_ Name\r\nurn:x-oca:ocpp:uid:1:569274\r\nVPN group.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "password": {
+ "description": "VPN. Password. Password\r\nurn:x-oca:ocpp:uid:1:569275\r\nVPN Password.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "key": {
+ "description": "VPN. Key. VPN_ Key\r\nurn:x-oca:ocpp:uid:1:569276\r\nVPN shared secret.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "$ref": "#/definitions/VPNEnumType"
+ }
+ },
+ "required": ["server", "user", "password", "key", "type"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "configurationSlot": {
+ "description": "Slot in which the configuration should be stored.\r\n",
+ "type": "integer"
+ },
+ "connectionData": {
+ "$ref": "#/definitions/NetworkConnectionProfileType"
+ }
+ },
+ "required": ["configurationSlot", "connectionData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetNetworkProfileResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "SetNetworkProfileStatusEnumType": {
+ "description": "Result of operation.\r\n",
+ "javaType": "SetNetworkProfileStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Failed"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/SetNetworkProfileStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetVariableMonitoringRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "MonitorEnumType": {
+ "description": "The type of this monitor, e.g. a threshold, delta or periodic monitor. \r\n\r\n",
+ "javaType": "MonitorEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["UpperThreshold", "LowerThreshold", "Delta", "Periodic", "PeriodicClockAligned"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "SetMonitoringDataType": {
+ "description": "Class to hold parameters of SetVariableMonitoring request.\r\n",
+ "javaType": "SetMonitoringData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "An id SHALL only be given to replace an existing monitor. The Charging Station handles the generation of id's for new monitors.\r\n\r\n",
+ "type": "integer"
+ },
+ "transaction": {
+ "description": "Monitor only active when a transaction is ongoing on a component relevant to this transaction. Default = false.\r\n\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "value": {
+ "description": "Value for threshold or delta monitoring.\r\nFor Periodic or PeriodicClockAligned this is the interval in seconds.\r\n\r\n",
+ "type": "number"
+ },
+ "type": {
+ "$ref": "#/definitions/MonitorEnumType"
+ },
+ "severity": {
+ "description": "The severity that will be assigned to an event that is triggered by this monitor. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.\r\n\r\nThe severity levels have the following meaning: +\r\n*0-Danger* +\r\nIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately. +\r\n*1-Hardware Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required. +\r\n*2-System Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required. +\r\n*3-Critical* +\r\nIndicates a critical error. Action is required. +\r\n*4-Error* +\r\nIndicates a non-urgent error. Action is required. +\r\n*5-Alert* +\r\nIndicates an alert event. Default severity for any type of monitoring event. +\r\n*6-Warning* +\r\nIndicates a warning event. Action may be required. +\r\n*7-Notice* +\r\nIndicates an unusual event. No immediate action is required. +\r\n*8-Informational* +\r\nIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required. +\r\n*9-Debug* +\r\nIndicates information useful to developers for debugging, not useful during operations.\r\n\r\n",
+ "type": "integer"
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ }
+ },
+ "required": ["value", "type", "severity", "component", "variable"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "setMonitoringData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SetMonitoringDataType"
+ },
+ "minItems": 1
+ }
+ },
+ "required": ["setMonitoringData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetVariableMonitoringResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "MonitorEnumType": {
+ "description": "The type of this monitor, e.g. a threshold, delta or periodic monitor. \r\n\r\n",
+ "javaType": "MonitorEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["UpperThreshold", "LowerThreshold", "Delta", "Periodic", "PeriodicClockAligned"]
+ },
+ "SetMonitoringStatusEnumType": {
+ "description": "Status is OK if a value could be returned. Otherwise this will indicate the reason why a value could not be returned.\r\n",
+ "javaType": "SetMonitoringStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "UnknownComponent",
+ "UnknownVariable",
+ "UnsupportedMonitorType",
+ "Rejected",
+ "Duplicate"
+ ]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "SetMonitoringResultType": {
+ "description": "Class to hold result of SetVariableMonitoring request.\r\n",
+ "javaType": "SetMonitoringResult",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Id given to the VariableMonitor by the Charging Station. The Id is only returned when status is accepted. Installed VariableMonitors should have unique id's but the id's of removed Installed monitors should have unique id's but the id's of removed monitors MAY be reused.\r\n",
+ "type": "integer"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "status": {
+ "$ref": "#/definitions/SetMonitoringStatusEnumType"
+ },
+ "type": {
+ "$ref": "#/definitions/MonitorEnumType"
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "severity": {
+ "description": "The severity that will be assigned to an event that is triggered by this monitor. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.\r\n\r\nThe severity levels have the following meaning: +\r\n*0-Danger* +\r\nIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately. +\r\n*1-Hardware Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required. +\r\n*2-System Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required. +\r\n*3-Critical* +\r\nIndicates a critical error. Action is required. +\r\n*4-Error* +\r\nIndicates a non-urgent error. Action is required. +\r\n*5-Alert* +\r\nIndicates an alert event. Default severity for any type of monitoring event. +\r\n*6-Warning* +\r\nIndicates a warning event. Action may be required. +\r\n*7-Notice* +\r\nIndicates an unusual event. No immediate action is required. +\r\n*8-Informational* +\r\nIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required. +\r\n*9-Debug* +\r\nIndicates information useful to developers for debugging, not useful during operations.\r\n\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["status", "type", "severity", "component", "variable"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "setMonitoringResult": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SetMonitoringResultType"
+ },
+ "minItems": 1
+ }
+ },
+ "required": ["setMonitoringResult"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetVariablesRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "AttributeEnumType": {
+ "description": "Type of attribute: Actual, Target, MinSet, MaxSet. Default is Actual when omitted.\r\n",
+ "javaType": "AttributeEnum",
+ "type": "string",
+ "default": "Actual",
+ "additionalProperties": false,
+ "enum": ["Actual", "Target", "MinSet", "MaxSet"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "SetVariableDataType": {
+ "javaType": "SetVariableData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "attributeType": {
+ "$ref": "#/definitions/AttributeEnumType"
+ },
+ "attributeValue": {
+ "description": "Value to be assigned to attribute of variable.\r\n\r\nThe Configuration Variable <<configkey-configuration-value-size,ConfigurationValueSize>> can be used to limit SetVariableData.attributeValue and VariableCharacteristics.valueList. The max size of these values will always remain equal. \r\n",
+ "type": "string",
+ "maxLength": 1000
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ }
+ },
+ "required": ["attributeValue", "component", "variable"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "setVariableData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SetVariableDataType"
+ },
+ "minItems": 1
+ }
+ },
+ "required": ["setVariableData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SetVariablesResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "AttributeEnumType": {
+ "description": "Type of attribute: Actual, Target, MinSet, MaxSet. Default is Actual when omitted.\r\n",
+ "javaType": "AttributeEnum",
+ "type": "string",
+ "default": "Actual",
+ "additionalProperties": false,
+ "enum": ["Actual", "Target", "MinSet", "MaxSet"]
+ },
+ "SetVariableStatusEnumType": {
+ "description": "Result status of setting the variable.\r\n",
+ "javaType": "SetVariableStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Rejected",
+ "UnknownComponent",
+ "UnknownVariable",
+ "NotSupportedAttributeType",
+ "RebootRequired"
+ ]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "SetVariableResultType": {
+ "javaType": "SetVariableResult",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "attributeType": {
+ "$ref": "#/definitions/AttributeEnumType"
+ },
+ "attributeStatus": {
+ "$ref": "#/definitions/SetVariableStatusEnumType"
+ },
+ "attributeStatusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ }
+ },
+ "required": ["attributeStatus", "component", "variable"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["name"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "setVariableResult": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SetVariableResultType"
+ },
+ "minItems": 1
+ }
+ },
+ "required": ["setVariableResult"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SignCertificateRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "CertificateSigningUseEnumType": {
+ "description": "Indicates the type of certificate that is to be signed. When omitted the certificate is to be used for both the 15118 connection (if implemented) and the Charging Station to CSMS connection.\r\n\r\n",
+ "javaType": "CertificateSigningUseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ChargingStationCertificate", "V2GCertificate"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "csr": {
+ "description": "The Charging Station SHALL send the public key in form of a Certificate Signing Request (CSR) as described in RFC 2986 [22] and then PEM encoded, using the <<signcertificaterequest,SignCertificateRequest>> message.\r\n",
+ "type": "string",
+ "maxLength": 5500
+ },
+ "certificateType": {
+ "$ref": "#/definitions/CertificateSigningUseEnumType"
+ }
+ },
+ "required": ["csr"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:SignCertificateResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "GenericStatusEnumType": {
+ "description": "Specifies whether the CSMS can process the request.\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:StatusNotificationRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ConnectorStatusEnumType": {
+ "description": "This contains the current status of the Connector.\r\n",
+ "javaType": "ConnectorStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Available", "Occupied", "Reserved", "Unavailable", "Faulted"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "timestamp": {
+ "description": "The time for which the status is reported. If absent time of receipt of the message will be assumed.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "connectorStatus": {
+ "$ref": "#/definitions/ConnectorStatusEnumType"
+ },
+ "evseId": {
+ "description": "The id of the EVSE to which the connector belongs for which the the status is reported.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "The id of the connector within the EVSE for which the status is reported.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["timestamp", "connectorStatus", "evseId", "connectorId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:StatusNotificationResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:TransactionEventRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "ChargingStateEnumType": {
+ "description": "Transaction. State. Transaction_ State_ Code\r\nurn:x-oca:ocpp:uid:1:569419\r\nCurrent charging state, is required when state\r\nhas changed.\r\n",
+ "javaType": "ChargingStateEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Charging", "EVConnected", "SuspendedEV", "SuspendedEVSE", "Idle"]
+ },
+ "IdTokenEnumType": {
+ "description": "Enumeration of possible idToken types.\r\n",
+ "javaType": "IdTokenEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Central",
+ "eMAID",
+ "ISO14443",
+ "ISO15693",
+ "KeyCode",
+ "Local",
+ "MacAddress",
+ "NoAuthorization"
+ ]
+ },
+ "LocationEnumType": {
+ "description": "Sampled_ Value. Location. Location_ Code\r\nurn:x-oca:ocpp:uid:1:569265\r\nIndicates where the measured value has been sampled. Default = \"Outlet\"\r\n\r\n",
+ "javaType": "LocationEnum",
+ "type": "string",
+ "default": "Outlet",
+ "additionalProperties": false,
+ "enum": ["Body", "Cable", "EV", "Inlet", "Outlet"]
+ },
+ "MeasurandEnumType": {
+ "description": "Sampled_ Value. Measurand. Measurand_ Code\r\nurn:x-oca:ocpp:uid:1:569263\r\nType of measurement. Default = \"Energy.Active.Import.Register\"\r\n",
+ "javaType": "MeasurandEnum",
+ "type": "string",
+ "default": "Energy.Active.Import.Register",
+ "additionalProperties": false,
+ "enum": [
+ "Current.Export",
+ "Current.Import",
+ "Current.Offered",
+ "Energy.Active.Export.Register",
+ "Energy.Active.Import.Register",
+ "Energy.Reactive.Export.Register",
+ "Energy.Reactive.Import.Register",
+ "Energy.Active.Export.Interval",
+ "Energy.Active.Import.Interval",
+ "Energy.Active.Net",
+ "Energy.Reactive.Export.Interval",
+ "Energy.Reactive.Import.Interval",
+ "Energy.Reactive.Net",
+ "Energy.Apparent.Net",
+ "Energy.Apparent.Import",
+ "Energy.Apparent.Export",
+ "Frequency",
+ "Power.Active.Export",
+ "Power.Active.Import",
+ "Power.Factor",
+ "Power.Offered",
+ "Power.Reactive.Export",
+ "Power.Reactive.Import",
+ "SoC",
+ "Voltage"
+ ]
+ },
+ "PhaseEnumType": {
+ "description": "Sampled_ Value. Phase. Phase_ Code\r\nurn:x-oca:ocpp:uid:1:569264\r\nIndicates how the measured value is to be interpreted. For instance between L1 and neutral (L1-N) Please note that not all values of phase are applicable to all Measurands. When phase is absent, the measured value is interpreted as an overall value.\r\n",
+ "javaType": "PhaseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["L1", "L2", "L3", "N", "L1-N", "L2-N", "L3-N", "L1-L2", "L2-L3", "L3-L1"]
+ },
+ "ReadingContextEnumType": {
+ "description": "Sampled_ Value. Context. Reading_ Context_ Code\r\nurn:x-oca:ocpp:uid:1:569261\r\nType of detail value: start, end or sample. Default = \"Sample.Periodic\"\r\n",
+ "javaType": "ReadingContextEnum",
+ "type": "string",
+ "default": "Sample.Periodic",
+ "additionalProperties": false,
+ "enum": [
+ "Interruption.Begin",
+ "Interruption.End",
+ "Other",
+ "Sample.Clock",
+ "Sample.Periodic",
+ "Transaction.Begin",
+ "Transaction.End",
+ "Trigger"
+ ]
+ },
+ "ReasonEnumType": {
+ "description": "Transaction. Stopped_ Reason. EOT_ Reason_ Code\r\nurn:x-oca:ocpp:uid:1:569413\r\nThis contains the reason why the transaction was stopped. MAY only be omitted when Reason is \"Local\".\r\n",
+ "javaType": "ReasonEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "DeAuthorized",
+ "EmergencyStop",
+ "EnergyLimitReached",
+ "EVDisconnected",
+ "GroundFault",
+ "ImmediateReset",
+ "Local",
+ "LocalOutOfCredit",
+ "MasterPass",
+ "Other",
+ "OvercurrentFault",
+ "PowerLoss",
+ "PowerQuality",
+ "Reboot",
+ "Remote",
+ "SOCLimitReached",
+ "StoppedByEV",
+ "TimeLimitReached",
+ "Timeout"
+ ]
+ },
+ "TransactionEventEnumType": {
+ "description": "This contains the type of this event.\r\nThe first TransactionEvent of a transaction SHALL contain: \"Started\" The last TransactionEvent of a transaction SHALL contain: \"Ended\" All others SHALL contain: \"Updated\"\r\n",
+ "javaType": "TransactionEventEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Ended", "Started", "Updated"]
+ },
+ "TriggerReasonEnumType": {
+ "description": "Reason the Charging Station sends this message to the CSMS\r\n",
+ "javaType": "TriggerReasonEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Authorized",
+ "CablePluggedIn",
+ "ChargingRateChanged",
+ "ChargingStateChanged",
+ "Deauthorized",
+ "EnergyLimitReached",
+ "EVCommunicationLost",
+ "EVConnectTimeout",
+ "MeterValueClock",
+ "MeterValuePeriodic",
+ "TimeLimitReached",
+ "Trigger",
+ "UnlockCommand",
+ "StopAuthorized",
+ "EVDeparted",
+ "EVDetected",
+ "RemoteStop",
+ "RemoteStart",
+ "AbnormalCondition",
+ "SignedDataReceived",
+ "ResetCommand"
+ ]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalIdToken": {
+ "description": "This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "description": "This defines the type of the additionalIdToken. This is a custom type, so the implementation needs to be agreed upon by all involved parties.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "$ref": "#/definitions/IdTokenEnumType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "MeterValueType": {
+ "description": "Meter_ Value\r\nurn:x-oca:ocpp:uid:2:233265\r\nCollection of one or more sampled values in MeterValuesRequest and TransactionEvent. All sampled values in a MeterValue are sampled at the same point in time.\r\n",
+ "javaType": "MeterValue",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "sampledValue": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SampledValueType"
+ },
+ "minItems": 1
+ },
+ "timestamp": {
+ "description": "Meter_ Value. Timestamp. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569259\r\nTimestamp for measured value(s).\r\n",
+ "type": "string",
+ "format": "date-time"
+ }
+ },
+ "required": ["timestamp", "sampledValue"]
+ },
+ "SampledValueType": {
+ "description": "Sampled_ Value\r\nurn:x-oca:ocpp:uid:2:233266\r\nSingle sampled value in MeterValues. Each value can be accompanied by optional fields.\r\n\r\nTo save on mobile data usage, default values of all of the optional fields are such that. The value without any additional fields will be interpreted, as a register reading of active import energy in Wh (Watt-hour) units.\r\n",
+ "javaType": "SampledValue",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "value": {
+ "description": "Sampled_ Value. Value. Measure\r\nurn:x-oca:ocpp:uid:1:569260\r\nIndicates the measured value.\r\n\r\n",
+ "type": "number"
+ },
+ "context": {
+ "$ref": "#/definitions/ReadingContextEnumType"
+ },
+ "measurand": {
+ "$ref": "#/definitions/MeasurandEnumType"
+ },
+ "phase": {
+ "$ref": "#/definitions/PhaseEnumType"
+ },
+ "location": {
+ "$ref": "#/definitions/LocationEnumType"
+ },
+ "signedMeterValue": {
+ "$ref": "#/definitions/SignedMeterValueType"
+ },
+ "unitOfMeasure": {
+ "$ref": "#/definitions/UnitOfMeasureType"
+ }
+ },
+ "required": ["value"]
+ },
+ "SignedMeterValueType": {
+ "description": "Represent a signed version of the meter value.\r\n",
+ "javaType": "SignedMeterValue",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "signedMeterData": {
+ "description": "Base64 encoded, contains the signed data which might contain more then just the meter value. It can contain information like timestamps, reference to a customer etc.\r\n",
+ "type": "string",
+ "maxLength": 2500
+ },
+ "signingMethod": {
+ "description": "Method used to create the digital signature.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "encodingMethod": {
+ "description": "Method used to encode the meter values before applying the digital signature algorithm.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "publicKey": {
+ "description": "Base64 encoded, sending depends on configuration variable _PublicKeyWithSignedMeterValue_.\r\n",
+ "type": "string",
+ "maxLength": 2500
+ }
+ },
+ "required": ["signedMeterData", "signingMethod", "encodingMethod", "publicKey"]
+ },
+ "TransactionType": {
+ "description": "Transaction\r\nurn:x-oca:ocpp:uid:2:233318\r\n",
+ "javaType": "Transaction",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "transactionId": {
+ "description": "This contains the Id of the transaction.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "chargingState": {
+ "$ref": "#/definitions/ChargingStateEnumType"
+ },
+ "timeSpentCharging": {
+ "description": "Transaction. Time_ Spent_ Charging. Elapsed_ Time\r\nurn:x-oca:ocpp:uid:1:569415\r\nContains the total time that energy flowed from EVSE to EV during the transaction (in seconds). Note that timeSpentCharging is smaller or equal to the duration of the transaction.\r\n",
+ "type": "integer"
+ },
+ "stoppedReason": {
+ "$ref": "#/definitions/ReasonEnumType"
+ },
+ "remoteStartId": {
+ "description": "The ID given to remote start request (<<requeststarttransactionrequest, RequestStartTransactionRequest>>. This enables to CSMS to match the started transaction to the given start request.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["transactionId"]
+ },
+ "UnitOfMeasureType": {
+ "description": "Represents a UnitOfMeasure with a multiplier\r\n",
+ "javaType": "UnitOfMeasure",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "unit": {
+ "description": "Unit of the value. Default = \"Wh\" if the (default) measurand is an \"Energy\" type.\r\nThis field SHALL use a value from the list Standardized Units of Measurements in Part 2 Appendices. \r\nIf an applicable unit is available in that list, otherwise a \"custom\" unit might be used.\r\n",
+ "type": "string",
+ "default": "Wh",
+ "maxLength": 20
+ },
+ "multiplier": {
+ "description": "Multiplier, this value represents the exponent to base 10. I.e. multiplier 3 means 10 raised to the 3rd power. Default is 0.\r\n",
+ "type": "integer",
+ "default": 0
+ }
+ }
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "eventType": {
+ "$ref": "#/definitions/TransactionEventEnumType"
+ },
+ "meterValue": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MeterValueType"
+ },
+ "minItems": 1
+ },
+ "timestamp": {
+ "description": "The date and time at which this transaction event occurred.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "triggerReason": {
+ "$ref": "#/definitions/TriggerReasonEnumType"
+ },
+ "seqNo": {
+ "description": "Incremental sequence number, helps with determining if all messages of a transaction have been received.\r\n",
+ "type": "integer"
+ },
+ "offline": {
+ "description": "Indication that this transaction event happened when the Charging Station was offline. Default = false, meaning: the event occurred when the Charging Station was online.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "numberOfPhasesUsed": {
+ "description": "If the Charging Station is able to report the number of phases used, then it SHALL provide it. When omitted the CSMS may be able to determine the number of phases used via device management.\r\n",
+ "type": "integer"
+ },
+ "cableMaxCurrent": {
+ "description": "The maximum current of the connected cable in Ampere (A).\r\n",
+ "type": "integer"
+ },
+ "reservationId": {
+ "description": "This contains the Id of the reservation that terminates as a result of this transaction.\r\n",
+ "type": "integer"
+ },
+ "transactionInfo": {
+ "$ref": "#/definitions/TransactionType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ }
+ },
+ "required": ["eventType", "timestamp", "triggerReason", "seqNo", "transactionInfo"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:TransactionEventResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "AuthorizationStatusEnumType": {
+ "description": "ID_ Token. Status. Authorization_ Status\r\nurn:x-oca:ocpp:uid:1:569372\r\nCurrent status of the ID Token.\r\n",
+ "javaType": "AuthorizationStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Blocked",
+ "ConcurrentTx",
+ "Expired",
+ "Invalid",
+ "NoCredit",
+ "NotAllowedTypeEVSE",
+ "NotAtThisLocation",
+ "NotAtThisTime",
+ "Unknown"
+ ]
+ },
+ "IdTokenEnumType": {
+ "description": "Enumeration of possible idToken types.\r\n",
+ "javaType": "IdTokenEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Central",
+ "eMAID",
+ "ISO14443",
+ "ISO15693",
+ "KeyCode",
+ "Local",
+ "MacAddress",
+ "NoAuthorization"
+ ]
+ },
+ "MessageFormatEnumType": {
+ "description": "Message_ Content. Format. Message_ Format_ Code\r\nurn:x-enexis:ecdm:uid:1:570848\r\nFormat of the message.\r\n",
+ "javaType": "MessageFormatEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ASCII", "HTML", "URI", "UTF8"]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalIdToken": {
+ "description": "This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "description": "This defines the type of the additionalIdToken. This is a custom type, so the implementation needs to be agreed upon by all involved parties.\r\n",
+ "type": "string",
+ "maxLength": 50
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "IdTokenInfoType": {
+ "description": "ID_ Token\r\nurn:x-oca:ocpp:uid:2:233247\r\nContains status information about an identifier.\r\nIt is advised to not stop charging for a token that expires during charging, as ExpiryDate is only used for caching purposes. If ExpiryDate is not given, the status has no end date.\r\n",
+ "javaType": "IdTokenInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/AuthorizationStatusEnumType"
+ },
+ "cacheExpiryDateTime": {
+ "description": "ID_ Token. Expiry. Date_ Time\r\nurn:x-oca:ocpp:uid:1:569373\r\nDate and Time after which the token must be considered invalid.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingPriority": {
+ "description": "Priority from a business point of view. Default priority is 0, The range is from -9 to 9. Higher values indicate a higher priority. The chargingPriority in <<transactioneventresponse,TransactionEventResponse>> overrules this one. \r\n",
+ "type": "integer"
+ },
+ "language1": {
+ "description": "ID_ Token. Language1. Language_ Code\r\nurn:x-oca:ocpp:uid:1:569374\r\nPreferred user interface language of identifier user. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "evseId": {
+ "description": "Only used when the IdToken is only valid for one or more specific EVSEs, not for the entire Charging Station.\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer"
+ },
+ "minItems": 1
+ },
+ "groupIdToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "language2": {
+ "description": "ID_ Token. Language2. Language_ Code\r\nurn:x-oca:ocpp:uid:1:569375\r\nSecond preferred user interface language of identifier user. Don’t use when language1 is omitted, has to be different from language1. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "personalMessage": {
+ "$ref": "#/definitions/MessageContentType"
+ }
+ },
+ "required": ["status"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "type": {
+ "$ref": "#/definitions/IdTokenEnumType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "MessageContentType": {
+ "description": "Message_ Content\r\nurn:x-enexis:ecdm:uid:2:234490\r\nContains message details, for a message to be displayed on a Charging Station.\r\n\r\n",
+ "javaType": "MessageContent",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "format": {
+ "$ref": "#/definitions/MessageFormatEnumType"
+ },
+ "language": {
+ "description": "Message_ Content. Language. Language_ Code\r\nurn:x-enexis:ecdm:uid:1:570849\r\nMessage language identifier. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "content": {
+ "description": "Message_ Content. Content. Message\r\nurn:x-enexis:ecdm:uid:1:570852\r\nMessage contents.\r\n\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["format", "content"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "totalCost": {
+ "description": "SHALL only be sent when charging has ended. Final total cost of this transaction, including taxes. In the currency configured with the Configuration Variable: <<configkey-currency,`Currency`>>. When omitted, the transaction was NOT free. To indicate a free transaction, the CSMS SHALL send 0.00.\r\n\r\n",
+ "type": "number"
+ },
+ "chargingPriority": {
+ "description": "Priority from a business point of view. Default priority is 0, The range is from -9 to 9. Higher values indicate a higher priority. The chargingPriority in <<transactioneventresponse,TransactionEventResponse>> is temporarily, so it may not be set in the <<cmn_idtokeninfotype,IdTokenInfoType>> afterwards. Also the chargingPriority in <<transactioneventresponse,TransactionEventResponse>> overrules the one in <<cmn_idtokeninfotype,IdTokenInfoType>>. \r\n",
+ "type": "integer"
+ },
+ "idTokenInfo": {
+ "$ref": "#/definitions/IdTokenInfoType"
+ },
+ "updatedPersonalMessage": {
+ "$ref": "#/definitions/MessageContentType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:TriggerMessageRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "MessageTriggerEnumType": {
+ "description": "Type of message to be triggered.\r\n",
+ "javaType": "MessageTriggerEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "BootNotification",
+ "LogStatusNotification",
+ "FirmwareStatusNotification",
+ "Heartbeat",
+ "MeterValues",
+ "SignChargingStationCertificate",
+ "SignV2GCertificate",
+ "StatusNotification",
+ "TransactionEvent",
+ "SignCombinedCertificate",
+ "PublishFirmwareStatusNotification"
+ ]
+ },
+ "EVSEType": {
+ "description": "EVSE\r\nurn:x-oca:ocpp:uid:2:233123\r\nElectric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "id": {
+ "description": "Identified_ Object. MRID. Numeric_ Identifier\r\nurn:x-enexis:ecdm:uid:1:569198\r\nEVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["id"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "requestedMessage": {
+ "$ref": "#/definitions/MessageTriggerEnumType"
+ }
+ },
+ "required": ["requestedMessage"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:TriggerMessageResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "TriggerMessageStatusEnumType": {
+ "description": "Indicates whether the Charging Station will send the requested notification or not.\r\n",
+ "javaType": "TriggerMessageStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotImplemented"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/TriggerMessageStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:UnlockConnectorRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "evseId": {
+ "description": "This contains the identifier of the EVSE for which a connector needs to be unlocked.\r\n",
+ "type": "integer"
+ },
+ "connectorId": {
+ "description": "This contains the identifier of the connector that needs to be unlocked.\r\n",
+ "type": "integer"
+ }
+ },
+ "required": ["evseId", "connectorId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:UnlockConnectorResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "UnlockStatusEnumType": {
+ "description": "This indicates whether the Charging Station has unlocked the connector.\r\n",
+ "javaType": "UnlockStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Unlocked", "UnlockFailed", "OngoingAuthorizedTransaction", "UnknownConnector"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/UnlockStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:UnpublishFirmwareRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "checksum": {
+ "description": "The MD5 checksum over the entire firmware file as a hexadecimal string of length 32. \r\n",
+ "type": "string",
+ "maxLength": 32
+ }
+ },
+ "required": ["checksum"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:UnpublishFirmwareResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "UnpublishFirmwareStatusEnumType": {
+ "description": "Indicates whether the Local Controller succeeded in unpublishing the firmware.\r\n",
+ "javaType": "UnpublishFirmwareStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["DownloadOngoing", "NoFirmware", "Unpublished"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/UnpublishFirmwareStatusEnumType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:UpdateFirmwareRequest",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "FirmwareType": {
+ "description": "Firmware\r\nurn:x-enexis:ecdm:uid:2:233291\r\nRepresents a copy of the firmware that can be loaded/updated on the Charging Station.\r\n",
+ "javaType": "Firmware",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "location": {
+ "description": "Firmware. Location. URI\r\nurn:x-enexis:ecdm:uid:1:569460\r\nURI defining the origin of the firmware.\r\n",
+ "type": "string",
+ "maxLength": 512
+ },
+ "retrieveDateTime": {
+ "description": "Firmware. Retrieve. Date_ Time\r\nurn:x-enexis:ecdm:uid:1:569461\r\nDate and time at which the firmware shall be retrieved.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "installDateTime": {
+ "description": "Firmware. Install. Date_ Time\r\nurn:x-enexis:ecdm:uid:1:569462\r\nDate and time at which the firmware shall be installed.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "signingCertificate": {
+ "description": "Certificate with which the firmware was signed.\r\nPEM encoded X.509 certificate.\r\n",
+ "type": "string",
+ "maxLength": 5500
+ },
+ "signature": {
+ "description": "Firmware. Signature. Signature\r\nurn:x-enexis:ecdm:uid:1:569464\r\nBase64 encoded firmware signature.\r\n",
+ "type": "string",
+ "maxLength": 800
+ }
+ },
+ "required": ["location", "retrieveDateTime"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "retries": {
+ "description": "This specifies how many times Charging Station must try to download the firmware before giving up. If this field is not present, it is left to Charging Station to decide how many times it wants to retry.\r\n",
+ "type": "integer"
+ },
+ "retryInterval": {
+ "description": "The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charging Station to decide how long to wait between attempts.\r\n",
+ "type": "integer"
+ },
+ "requestId": {
+ "description": "The Id of this request\r\n",
+ "type": "integer"
+ },
+ "firmware": {
+ "$ref": "#/definitions/FirmwareType"
+ }
+ },
+ "required": ["requestId", "firmware"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2020:3:UpdateFirmwareResponse",
+ "comment": "OCPP 2.0.1 FINAL",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ },
+ "UpdateFirmwareStatusEnumType": {
+ "description": "This field indicates whether the Charging Station was able to accept the request.\r\n\r\n",
+ "javaType": "UpdateFirmwareStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Rejected",
+ "AcceptedCanceled",
+ "InvalidCertificate",
+ "RevokedCertificate"
+ ]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 512
+ }
+ },
+ "required": ["reasonCode"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ },
+ "status": {
+ "$ref": "#/definitions/UpdateFirmwareStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+# OCPP 2.0.1 (all files)
+
+This zip contains the latest version of all OCPP 2.0.1 Edition 3 specification parts for all parts of OCPP 2.0.1.
+
+| File | Date |
+| ------------------------------------------------ | ---------- |
+| OCPP-2.0.1_edition3_part0_introduction | 2024-05-06 |
+| OCPP-2.0.1_edition3_part1_architecture_topology | 2024-05-06 |
+| OCPP-2.0.1_edition3_part2_specification | 2024-05-06 |
+| OCPP-2.0.1_edition3_part2_appendices_v14 | 2024-05-06 |
+| OCPP-2.0.1_part3_JSON_schemas | 2020-03-31 |
+| OCPP-2.0.1_edition3_part4_ocpp-j-specification | 2024-05-06 |
+| OCPP-2.0.1_edition3_part5_certification_profiles | 2024-05-06 |
+| OCPP-2.0.1_edition3_part6-testcases | 2024-05-06 |
+| OCPP-2.0.1_edition3_errata_2025-09 | 2025-09-30 |
+| Appendices_CSV_v1.4 | 2024-05-06 |
+
+### Additional information
+
+For historical reasons not all documents have the same release date. OCPP 2.0.1 Edition 3 is the same as OCPP 2.0.1 Edition 2 including all errata up and until OCPP-2.0.1_edition2_errata_2024-04 (2024-04-30).
+
+The errata do not affect any schemas of OCPP messages. The 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 were 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 2.0.1 part 2 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.
+
+On 2025-09-30 the following documents were updated in the set:
+
+- OCPP-2.0.1_edition3_errata_2025-09 replaced OCPP-2.0.1_edition3_errata_2025-06 - this errata document contains all errata for all parts of OCPP 2.0.1 until 2025-09
+
+On 2025-07-08 the following documents were updated in the set:
+
+- OCPP-2.0.1_edition3_errata_2025-06 replaced OCPP-2.0.1_edition3_errata_2025-04 - this errata document contains all errata for all parts of OCPP 2.0.1 until 2025-06
+
+On 2025-04-30 the following documents were updated in the set:
+
+- OCPP-2.0.1_edition3_errata_2025-04 replaced OCPP-2.0.1_edition3_errata_2025-02 - this errata document contains all errata for all parts of OCPP 2.0.1 until 2025-04
+
+On 2025-03-06 the following documents were updated in the set:
+
+- OCPP-2.0.1_edition3_errata_2025-02 replaced OCPP-2.0.1_edition3_errata_2025-01 - this errata document contains all errata for all parts of OCPP 2.0.1 until 2025-02
+
+On 2025-01-23 the following documents were updated in the set:
+
+- OCPP-2.0.1_edition3_errata_2025-01 replaced OCPP-2.0.1_edition3_errata_2024-11 - this errata document contains all errata for all parts of OCPP 2.0.1 until 2025-01
+
+On 2024-11-28 the following documents were updated in the set:
+
+- OCPP-2.0.1_edition3_errata_2024-11 replaced OCPP-2.0.1_edition3_errata_2024-09 - this errata document contains all errata for all parts of OCPP 2.0.1 until 2024-11
+
+On 2024-09-25 the following documents were updated in the set:
+
+- OCPP-2.0.1_edition3_errata_2024-09 replaced OCPP-2.0.1_edition3_errata_2024-06 - this errata document contains all errata for all parts of OCPP 2.0.1 until 2024-09
+
+On 2024-06-27 the following documents were updated in the set:
+
+- OCPP-2.0.1_edition3_errata_2024-06 was added
+
+On 2024-05-06 the following documents were updated in the set:
+
+- All documents except the schemas were updated to the Edition 3 version.
+- OCPP-2.0.1_edition2_errata_2024-04 was removed
+
+On 2024-04-30 the following documents were updated in the set:
+
+- OCPP-2.0.1_edition2_errata_2024-04 replaced OCPP-2.0.1_edition2_errata_2024-02 - this errata document contains all errata for all parts of OCPP 2.0.1 until 2024-04
+
+On 2024-02-28 the following documents were updated in the set:
+
+- OCPP-2.0.1_edition2_errata_2024-02 replaced OCPP-2.0.1_edition2_errata_2023-12 - this errata document contains all errata for all parts of OCPP 2.0.1 until 2024-02
+
+On 2023-12-18 the following documents were updated in the set:
+
+- OCPP-2.0.1_edition2_errata_2023-12 - this errata document contains all errata for all parts of OCPP 2.0.1 until 2023-12
+
+On 2023-06-30 the following documents were added to the set:
+
+- OCPP-2.0.1_part2_edition2_errata - these are the errata applicable to OCPP 2.0.1 part 2 edition 2
+- OCPP-2.0.1_part5_certification_profiles - the certification profiles for Core & Advanced Security. The remaining certification profiles will be added in a later release of this part.
+- OCPP-2.0.1_part6_test_cases - the test cases for Core & Advanced Security that are used during certification. The test cases for the remaining certification profiles will be added in a later release of this part.
--- /dev/null
+additionalInfo.type;Description
+EVCCID;The EVCCID of EV is added as additionalInfo to an idToken for ISO 15118-20 sessions.
+ISO14443SubType;The subtype of an ISO 14443 RFID card. For example: 'VDE-AR-E-2532-100' (a secure variant of ISO 14443).
\ No newline at end of file
--- /dev/null
+additionalInfo.type;Description
+PspRef;Payment Service Provider reference id for payment session. Only use when PspRef is not in _idToken_.
+SessionRef;Payment session reference id from terminal (not the same as pspRef)
+MerchantRef;Merchant (CSO) reference id for payment session
+PaymentBrand;Brand of ad hoc payment card. See predefined list of values in table below.
+ReadingMethod;Contactless / Contact / Magstripe
+PaymentRecognition;Credit/debit card or digital wallet. See predefined list of values in table below.
+CardBin;Card first 6 digits
+CardLast4Digits;Card last 4 digits
+CardExpiryDate;The expiry date of the card. Format: YYYY/MM
+HashedCardNr;The hashed card number.
+WalletUserId;User ID for a digital wallet, e.g. Alipay.
--- /dev/null
+Value;Description
+EMS;Indicates that an Energy Management System has sent a charging limit.
+Other;Indicates that an external source, not being an EMS or system operator, has sent a charging limit.
+SO;Indicates that a System Operator (DSO or TSO) has sent a charging limit.
+CSO;Indicates that the CSO has set this charging profile.
--- /dev/null
+Component ; Description
+AlignedDataCtrlr; Logical Component responsible for configuration relating to the reporting of clock-aligned meter data.
+AuthCacheCtrlr; Logical Component responsible for configuration relating to the use of a local cache for authorization for Charging Station use.
+AuthCtrlr; Logical Component responsible for configuration relating to the use of authorization for Charging Station use.
+CHAdeMOCtrlr; A CHAdeMO Controller component communicates with an EV using the wired CANbus protocol to exchange information and control charging using the CHAdeMO protocol
+ClockCtrlr; Provides a means to configure management of time tracking by Charging Station.
+CustomizationCtrlr; Responsible for configuration relating to custom vendor-specific implementations, like the DataTransfer message and CustomData extensions or CustomTriggers.
+DeviceDataCtrlr; Logical Component responsible for configuration relating to the exchange and storage of Charging Station Device Model data.
+DisplayMessageCtrlr; Logical Component responsible for configuration relating to the display of messages to Charging Station users.
+ISO15118Ctrlr; Communicates with an EV to exchange information and control charging using the ISO 15118 protocol.
+LocalAuthListCtrlr; Logical Component responsible for configuration relating to the use of Local Authorization Lists for Charging Station use.
+MonitoringCtrlr; Logical Component responsible for configuration relating to the exchange of monitoring event data.
+OCPPCommCtrlr; Logical Component responsible for configuration relating to information exchange between Charging Station and CSMS.
+ReservationCtrlr; Logical Component responsible for configuration relating to reservations.
+SampledDataCtrlr; Logical Component responsible for configuration relating to the reporting of sampled meter data.
+SecurityCtrlr; Logical Component responsible for configuration relating to security of communications between Charging Station and CSMS.
+SmartChargingCtrlr; Logical Component responsible for configuration relating to smart charging.
+TariffCostCtrlr; Logical Component responsible for configuration relating to tariff and cost display.
+TxCtrlr; Logical Component responsible for configuration relating to transaction characteristics and behaviour.
+V2XChargingCtrlr;Responsible for configuration relating to V2X charging/discharging. This component exists on the EVSE tier hierarchy.
+DCDERCtrlr; Responsible for configuration relating to DER capabilities of the DC inverter of the EVSE in the Charging Station. The component is located at the EVSE level, since it represents the DER capabilities, also referred to as nameplate information, of the EVSE.
+ACDERCtrlr; Responsible for configuration relating to DER capabilities that the EVSE of the Charging Station can emulate by using ISO 15118-20 ChargeLoop messages to control the inverter in the EV. The component is located at the EVSE level, since it represents the DER capabilities of the EVSE.
+BatterySwapCtrlr; Responsible for configuration relating to Battery swapping.
+WebPaymentsCtrlr; Responsible for configuration of a dynamic QR code for ad hoc payments.
+;
+AccessBarrier; Allows physical access of vehicles to a charging site to be controlled.
+AcDcConverter; Provides a variable DC current source to force energy directly into an EV battery stack, under tight control of the EV's battery management system.
+AcPhaseSelector; Allows a specific AC phase to be selected (typically at EVSE tier) for single phase vehicle charging in order to lower overall (e.g. site) phase imbalance.
+Actuator; A general purpose electro-mechanical output system, with optional completion tracking sensing. Each output should use a Variable instance key indicating the nature of the output.
+AirCoolingSystem; Fans (or equivalent devices) used to provide cooling.
+AreaVentilation; Fans (or equivalent devices) used to ensure that EVs that require ventilation during charging
+BayOccupancySensor; Sensor (optical, ground loop, ultrasonic, etc.) to detect whether the associated parking/charging bay is physically vacant, or is occupied by a vehicle or other obstruction
+BeaconLighting; Beacon Lighting to help EV drivers to locate nearby charging places, and/or to determine charging availability state, usually by color variation.
+CableBreakawaySensor; A sensor that detects when a charging cable (captive or removable) has been forcibly pulled from the Charging Station.
+CaseAccessSensor; Reports when an access door/panel is open
+ChargingStation; The entire Charging Station as a logical entity
+ChargingStatusIndicator; The Charging Status Indicator, provides visible feedback to the user about the connection and charging status of an EVSE/Connector. This is commonly in the form of multi-colored lighting.
+ConnectedEV; ConnectedEV is a component that represents a connected vehicle for which data is received via an ISO 15118 or CHAdeMO interface. The generic information that is received, is represented as variables of ConnectedEV. Any protocol-specific information is represented in variables of the ISO15118Ctrlr or CHAdeMOCtrlr component.
+Connector; A means to connect an EV to a Charging Station with either a socket, an attached cable & inline connector, or any wireless power transfer device.
+ConnectorHolsterRelease; A mechanism present in a connector holster to prevent the connector from being removed inappropriately: typically unlocks connector after authorization.
+ConnectorHolsterSensor; A mechanism to report when a tethered cable connector has been removed from its normal stowage position. May be used for detection of connectors left un-holstered, and possible penalty billing.
+ConnectorPlugRetentionLock; Locking mechanism to retain an inserted plug, both to prevent on-load disconnection, and to prevent theft of charging cables
+ConnectorProtectionRelease; External protective mechanism (e.g. an external shutter or a connector holster lock mechanism) to prevent contact with conductors that may become 'live' under other failure modes
+Controller; An embedded logic controller
+ControlMetering; Energy, Power, Electricity meter, used to measure energy, current, voltages etc.
+CPPWMController; Control Pilot PWM Controller: provides and senses the IEC 61851-1 / SAE J1772 low voltage DC and PWM signalling between an EVSE and EV over a control pilot line.
+DataLink; Provides a communications link from a Charging Station to a CSMS. It may use fixed infrastructure, mobile telephony data services, WiFi, or other connectivity channels.
+Display; Provides information and feedback to the user.
+DistributionPanel; Defines the Distribution Panel, with it's fuses and connections to both Charging Stations and other Distribution Panel's.
+ElectricalFeed; Represents an incoming electrical connection to a Charging Station, that may be a grid/distribution network connection, of a connection to local power generation and/or storage. Each electrical feed can record the electrical and other characteristics of that feed, including power rating, fusing, upstream metering, etc. When a Charging Station has more than one electrical feed, it must represent which feed supplies each EVSE, and which feed supplies the house load of the Charging Station itself. Simple Charging Stations with only a single electrical feed may omit all electrical feed information, in which case it is inferred that all power is supplied from a single feed, and what would otherwise be ElectricalFeed data (Variables) may be reported as being associated with the ChargingStation component.
+ELVSupply; Represents the low voltage power supply (typically 12V DC and often other ELV voltages) that provides operating power for controllers, relays, and other electrical components.
+EmergencyStopSensor; An 'Emergency Stop' button that should be pressed by the user or other nearby persons if serious faulty behavior is observed (e.g. smoke/flames from EV or Charging Station).
+EnvironmentalLighting; Provides reporting/control of general illumination lighting in use at Charging Station.
+EVRetentionLock; A locking mechanism on the EV side as a safety measure to prevent it being disconnected while high currents are flowing.
+EVSE; The entire chain of components responsible for transporting energy from the incoming supply to the electric vehicle (or vice versa)
+ExternalTemperatureSensor; Reports ambient air temperature
+FiscalMetering; Provides energy transfer readings that are the basis for billing.
+FloodSensor; A sensor reporting whether the Charging Station is experiencing water ingress/pooling.
+GroundIsolationProtection; An Isolation Tester as part of their own self-test mechanisms, to confirm the isolation of floating circuitry when no Evs are connected
+Heater; Heater to ensure reliable operation in cold environments
+HumiditySensor; Reports relative air humidity
+LightSensor; Reports ambient light levels.
+LiquidCoolingSystem; A liquid based cooling system, typically used to cool the connector cables of very high power Charging Stations.
+LocalAvailabilitySensor; Accepts local signal inputs controlling whether new Charging Sessions can start and/or whether ongoing sessions should continue. Typically connected to a site/building power supply, to automatically report unavailability when closed.
+LocalController; The entire Local Controller as a logical entity
+LocalEnergyStorage; Energy storage
+OverCurrentProtection; Protects equipment by disconnecting the electrical supply when the current drawn (on any phase) exceeds the rated value to a substantial degree.
+OverCurrentProtectionRecloser; Recloser mechanism of an OverCurrentProtection to perform re-arm retries after a trip, or may be set for remotely controlled re-arming on command.
+PowerContactor; Switches on and off the power to the EV after all authorization and safety requirements have been met. May have secondary contacts to report closure state.
+RCD; A Residual Current Device (US: ground fault breaker) protects human life and/or downstream equipment by quickly detecting abnormal current flows (usually indicative in earth faults) in the Charging Station, cable, or EV during charging.
+RCDRecloser; A motorized recloser mechanism of an RCD that may be configured to perform re-arm retries after a trip, or may be set for remotely controlled re-arming on command.
+RealTimeClock; Represents realtime clock hardware that can maintain accurate date & time information in a Charging Station, even in the case of simultaneous CSMS uncontactability and power outages or resets.
+ShockSensor; Measures impact forces/accelerations experienced, indicative of possible damage.
+SpacesCountSignage; Electronic signage allowing a charging controller for a large charging facility to advertise counts of available spaces to passing traffic.
+Switch; A general purpose electromechanical input device, with optional remote defaulting/resetting of values. Each input should use a Variable instance key indicating the nature of the input.
+TemperatureSensor; Temperature sensor at a point inside the Charging Station, multiple sensing points for a single sensing controller. Multiple sensing points for a single sensing controller may be reported using distinct Variable instance keys.
+TiltSensor; Measures Tilt angle from normal reference position (normally 90 degree vertical).
+TokenReader; An authorization token reader (e.g. RFID)
+UpstreamProtectionTrigger; Circuitry designed to trigger the disconnection of power to the structure by an upstream protection device after a severe problem has been detected
+UIInput; A logical input mechanism (e.g. set of buttons) that is part of a UI whose use may be communicated to the CSMS (in near real time). May support momentary inputs ('Operated') or modal state ('Active'). Multiple input sources should use explicit Variable instance keys (where the input function is key name).
+VehicleIdSensor; Reports an identifier associated with a vehicle occupying a charging bay. The identifier may be a vehicle registration number via ANPR hardware, a VIN, or other local identifier of the vehicle based on medium range/active RFID, or any other relevant technology and result.
+
--- /dev/null
+Value;Description
+cCCS1;Combined Charging System 1 (captive cabled) a.k.a. Combo 1
+cCCS2;Combined Charging System 2 (captive cabled) a.k.a. Combo 2
+cChaoJi;ChaoJi (captive cabled) a.k.a. CHAdeMO 3.0
+cG105;JARI G105-1993 (captive cabled) a.k.a. CHAdeMO (captive cabled)
+cGBT-DC;GB/T 20234.3 DC connector (captive cabled)
+cLECCS;Light Equipment Combined Charging System IS17017 (captive cabled)
+cMCS;Megawatt Charging System (captive cabled)
+cNACS;North American Charging Standard J3400 (captive cabled)
+cNACS-CCS1;Tesla MagicDock with built-in NACS to CCS1 adapter (captive cabled)
+cCCS1-NACS;Omni Port with build-in CCS1 to NACS adapter (captive cabled)
+cTesla;Tesla Connector (captive cabled)
+cType1;IEC62196-2 Type 1 connector (captive cabled) a.k.a. J1772
+cType2;IEC62196-2 Type 2 connector (captive cabled) a.k.a. Mennekes connector
+cUltraChaoJi;Ultra-ChaoJi for megawatt charging (captive cabled)
+s309-1P-16A;16A 1 phase IEC60309 socket
+s309-1P-32A;32A 1 phase IEC60309 socket
+s309-3P-16A;16A 3 phase IEC60309 socket
+s309-3P-32A;32A 3 phase IEC60309 socket
+sBS1361;UK domestic socket a.k.a. 13Amp
+sCEE-7-7;CEE 7/7 16A socket. May represent 7/4 and 7/5 a.k.a Schuko
+sType1;IEC62196-2 Type 1 socket a.k.a. J1772
+sType2;IEC62196-2 Type 2 socket a.k.a. Mennekes connector
+sType3;IEC62196-2 Type 3 socket a.k.a. Scame
+wInductive;Wireless inductively coupled connection (generic)
+wResonant;Wireless resonant coupled connection (generic)
+Other1PhMax16A;Other single phase (domestic) sockets not mentioned above, rated at no more than 16A. CEE7/17, AS3112, NEMA 5-15, NEMA 5-20, JISC8303, TIS166, SI 32, CPCS-CCC, SEV1011, etc.
+Other1PhOver16A;Other single phase sockets not mentioned above (over 16A)
+Other3Ph;Other 3 phase sockets not mentioned above. NEMA14-30, NEMA14-50.
+Pan;Pantograph connector
+Undetermined;Yet to be determined (e.g. before plugged in)
+Unknown;Unknown/not determinable
\ No newline at end of file
--- /dev/null
+Specific Component;Variable;Instance;Required?;DataType;Unit;Description
+<generic>;ACCurrent;;no;decimal;A;RMS AC Current (in amperes). For 3-phase circuits, each phase (and optional neutral) is represented by a Variable instance equal to a value of the PhaseEnumType (e.g. L1,N). Unkeyed values reported for a Component declared to be multi-phase are assumed to be an average of all per-phase readings and written values are common per-phase settings. Example(s): ChargingStation: Total AC current consumption (all EVSE’s, ancillaries), EVSE: Total current consumed by EVSE: includes losses (AC->DC) and EVSE specific ancillaries (e.g. fans), ElectricalFeed: Inflow AC current on feed
+<generic>;Active;;no;boolean;;Component is in its non-resting / active state: e.g: On, Engaged, Locked. Some Components may have secondary functions that have corresponding Active Variables with an explicit Variable instance., Note: Monitoring of changes in the Active state of any Component can be specified by setting Delta monitoring on the boolean value with a delta values of 1. Setting/clearing an Active Variable activates/stops the associated functionality, where remotely controllable. Only components that are Available and Enabled can be in the Active state.
+<generic>;ACVoltage;;no;decimal;V;RMS AC Voltage (in volts). For 3-phase circuits, each phase (and optional neutral) is represented by a Variable instance equal to a value of the PhaseEnumType (e.g. L1,N). Unkeyed values reported for a Component declared to be multi-phase are assumed to be an average ofall per-phase readings and written values are common per-phase settings. Example(s): ElectricalFeed: Input Voltage
+<generic>;AllowReset;;no;boolean;;Component can be reset.
+<generic>;Angle;;no;decimal;Deg;Angle(s) relative to normal/design idle position. Multiple Variable instance values may be used to indicate angular position in multiple axes (e.g. Left-Right, Forward-Back).
+<generic>;Attempts;;no;integer;;Number of attempts (INCLUDING the original attempt) in the last successful or attempted, cycle of operation. Applies typically to self-monitoring motorized electro-mechanical equipment, etc. {Null}: Unknown, 0: Not Attempted/Not allowed, 1: Single attempt/No retries [allowed], 2-N: [up to] N tries [allowed]
+<generic>;Available;;no;boolean;;The Component exists and is locally configured/wired for use, but might not be (remotely) Enabled.
+<generic>;Certificate;;no;string;;Digital Certificate (in Base64 encoding)
+<generic>;Color;;no;string;;Standard 24 bit hexadecimal RGB values. Reg Green Blue color intensity, expressed as standard 24 bit hexadecimal RGB values: 3 00-FF (0-255), in order RRGGBB). E.g. 000000: Black, FF0000: Red, 00FF00: Green, 0000FF: Blue, FFFF00:Yellow, FFFFFF: White, 008000: Medium intensity green.
+<generic>;Complete;;no;boolean;;Component operation cycle has completed. Used only in event notifications, where it is always true.
+<generic>;ConnectedTime;;no;decimal;s;Time since logical connection established
+<generic>;Count;;no;integer;;General purpose integer count variable for Component state reporting
+<generic>;CurrentImbalance;;no;decimal;Percent;Percentage current imbalance in an AC three phase supply.
+<generic>;DataText;;no;string;;Text associated with a Component, e.g. a Display.
+<generic>;DateTime;;no;dateTime;;Point in time value, in [RFC3339] datetime format. Time zone optional.
+<generic>;DCCurrent;;no;decimal;A;DC Current (in amperes). May be an instantaneous measurement, or a period average, depending on context/equipment.
+<generic>;DCVoltage;;no;decimal;V;DC Voltage (volts). May be an instantaneous measurement, or a period average, depending on context/equipment.
+<generic>;ECVariant;;no;string;;Production series variants reflecting internal design changes or sub-component substitutions not affecting external functionality.
+<generic>;Enabled;;no;boolean;;The Component is Enabled for operation. For Available components that cannot be selectively (remotely) enabled / disabled, this value is always true. Note: Available cannot be false of Enabled is true, so during inventory reporting, Enabled=1 also logically states Available=true
+<generic>;Energy;;no;decimal;Wh, kWh;Energy quantity (in Wh) for reporting/configuring values related to stored energy (i.e. not transferred energy).
+<generic>;Entries;;no;integer;;General purpose variable for reporting/managing numbers of entries in repetitive data structures. maxLimit characteristic reports maximum possible entries.
+<generic>;Fallback;;no;boolean;;Component is operating in a fallback, or backup mode. In inventory reports, a Value of 1 for the maxLimit characteristic indicates that the component can enter a fallback state (i.e. a fallback mode is present).
+<generic>;FanSpeed;;no;decimal;RPM;Fan Speed (in RPM). A value of 0 represents stopped/stalled. An empty value indicates that fan speed cannot be read.
+<generic>;FirmwareVersion;;no;string;;Version number of firmware.
+<generic>;Force;;no;decimal;N;Reports (impact) force/ acceleration values (estimates) in one or more directions, in units of Newtons or “g”. Multiple force readings in different (orthogonal) dimensions may be reported using Variable instance values, such as Down, Right, Forward.
+<generic>;Formats;;no;MemberList;;List of message formats supported by this Charging Station. Possible values: ASCII, HTML, URI, UTF-8.
+<generic>;Frequency;;no;decimal;Hz;Frequency of AC power, signal, or component operation.
+<generic>;FuseRating;;no;decimal;A;Current rating of a fuse/breaker. Variable instances keyed by phase identifier (L1/L2/L3/N).
+<generic>;Height;;no;decimal;m;Height above(+)/below(-) reference level (ground level unless context demands otherwise).
+<generic>;Humidity;;no;decimal;RH;The relative humidity in %.
+<generic>;Hysteresis;;no;decimal;Percent;Specifies the width of a 'dead band' (as a percentage of the threshold) around the central value of a threshold setting (e.g. MinSet, MaxSet, monitor thresholds) to avoid repeated triggering when the measured quantity lies close to the threshold and is subject to small variations.
+<generic>;ICCID;;no;string;;ICCID (Integrated Circuit Card IDentifier) of mobile data SIM card.
+<generic>;Impedance;;no;decimal;Ohm;Impedance: Primary value is real (resistive only) impedance. Where a complex impedance is to be reported, the imaginary part (reactance) must be represented with a separate Variable instance value of 'reactance'. Reactance values are expressed at the (nominal) relevant operating frequency of the Component (e.g. 50/60Hz for mains electricity feed).
+<generic>;IMSI;;no;string;;IMSI (International Mobile Subscriber Identity) number of mobile data SIM card
+<generic>;Interval;;no;integer;s;Minimum Interval (in seconds) between (attempted) operations.
+<generic>;Length;;no;decimal;m;General Purpose linear distance measure.
+<generic>;Light;;no;decimal;lx;(Ambient) light level. The value is in Lux.
+<generic>;Manufacturer;;no;string;;Component Manufacturer name
+<generic>;Message;;no;string;;Specific stored message for display.
+<generic>;MinimumStatusDuration;;no;integer;s;Minimum duration that a Charging Station or EVSE status is stable before StatusNotificationRequest is sent to the CSMS.
+<generic>;Mode;;no;string;;Operating mode string from among valid options (communicated by OptionList, etc. during capability/configuration discovery).
+<generic>;Model;;no;string;;"Manufacturer's Model code/number of Component, including suffixes etc. to identify functional, regional or linguistic variation, but NOT engineering change level internal variation not affecting external behaviour, etc."
+<generic>;NetworkAddress;;no;string;;Current network address of a Component.
+<generic>;Operated;;no;boolean;;The Component operated in an instantaneous, transient, or immediately self-resetting pattern. Used only in event notifications, where it is always true.
+<generic>;OperatingTimes;;no;string;;Recurring operating times in iCalendar RRULE format.
+<generic>;Overload;;no;boolean;;Component is in Overload state.
+<generic>;Percent;;no;decimal;Percent;Generic dimensionless value reporting/setting value.
+<generic>;PhaseRotation;;no;OptionList;;The phase wiring of Component, relative to it's upstream feed Component/device. This variable describes the phase rotation of a Component relative to its parent Component, using a three letter string consisting of the letters: R, S, T and x. The letter 'R' can be identified as phase 1 (L1), 'S' as phase 2 (L2), 'T' as phase 3 (L3). The lower case 'x' is used to designate a phase that is not connected. An empty string means that phase rotation is not applicable or not known.
+<generic>;PostChargingTime;;no;decimal;s;Elapsed time in seconds since last substantive energy transfer
+<generic>;Power;;no;decimal;W, kW;Instantaneous (real) Power (measured/calculated, including power factor for AC). Where a component (e.g. AC to DC Power Converter) has multiple power measurements, the default (unkeyed) instance is “input” power.
+<generic>;Problem;;no;boolean;;Component itself has a 'Problem' condition that impacts in any significant way on its normal operation. By definition, 'Problem' state includes (logical OR) 'Fault' state. 'Problem' specifically INCLUDES inability to operate that is propagated (up/down/sideways) from any other associated/connected/containing/contained Component.
+<generic>;Protecting;;no;boolean;;Applies to 'sensor' type Components that have an associated protection capability, whereby they can disconnect power (e.g. using the main PowerContactor) if the sensed quantity is outside preset/configured limits. If Protecting is true, the Component is actively preventing/interrupting charging.
+<generic>;SerialNumber;;no;string;;Serial number of Component.
+<generic>;SignalStrength;;no;decimal;dBm;(Radio/Wired/Optical) data signal strength, in ASU (typically 0-31 or 99 for unknown). Or dbmW (typically -140 to -50).
+<generic>;State;;no;string;;A state code or name identifier string, to allow the internal state of components to be reported and/or controlled
+<generic>;StateOfCharge;;no;decimal;Percent;Energy Storage Device (e.g. battery) state of charge, expressed as a percentage of nominal design 0-100% operating range. Note: Values below or above 0-100% are possible and represent over discharged/charged states.
+<generic>;Storage;;no;integer;B;In bytes. Amount of storage occupied. Storage(maxLimit) specifies absolute limit Storage(MaxSet) restricts usage to specified Max, if supported.
+<generic>;SupplyPhases;;no;integer;;Number of alternating current phases connected/available. 1 or 3 for AC, 0 means DC (no alternating phases). Null value indicates that the number of phases (e.g. in use) is unknown.
+<generic>;Suspending;;no;boolean;;If Suspending is true, the Component can is currently suspending charging.
+<generic>;Suspension;;no;boolean;;Applies to 'sensor' type Components that have a charging suspension capability, typically for safety or equipment protection reasons. If Suspension is true, the component can suspend charging when the sensed quantity is outside preset/configured limits.
+<generic>;Temperature;;no;decimal;Celsius, Fahrenheit;Temperature(s) of component (in Celsius, by default). Components may have multiple indexed temperature sensors.
+<generic>;Time;;no;dateTime;;Point in time value, in ISO 8601 datetime format. Time zone optional.
+<generic>;Timeout;;no;decimal;s;Generic timeout value for Component operation (in seconds).
+<generic>;Tries;;no;integer;;Number of attempts done by a Component.
+<generic>;Tripped;;no;boolean;;Single-shot device requires explicit intervention to re-prime/activate to normal.
+<generic>;VendorName;;no;string;;Vendor or manufacturer of component.
+<generic>;VersionDate;;no;dateTime;;Version date of component in [RFC3339] format.
+<generic>;VersionNumber;;no;string;;Version number of hardware
+<generic>;VoltageImbalance;;no;decimal;Percent;Percentage voltage imbalance in three phase supply.
+<generic>;CommunicationParent;;no;string;;Points to a communication parent component (data flow source), to allow rendering the communication hierarchy in a UI.
+<generic>;ElectricalParent;;no;string;;Points to a electrical parent component (energy flow source), to allow rendering the electrical hierarchy in a UI.
+<generic>;LogicalParent;;no;string;;Points to a logical parent component, to allow rendering a comprehensive overview of the Charging Station components in a UI.
+<generic>;PhysicalParent;;no;string;;Points to a physical parent component (container), to allow rendering an overview of the Charging Station component locations in a UI.
+<generic>;Label;;no;string;;Specifies a non-unique label to be used in a hierarchy UI rendering, in place of the unique component name and instance, in case a duplicate label is needed.
+AlignedDataCtrlr;Available;;no;boolean;;If this variable reports a value of true, Clock-Aligned Data is supported.
+AlignedDataCtrlr;Enabled;;no;boolean;;If this variable reports a value of true, Clock-Aligned Data is enabled
+AlignedDataCtrlr;Interval;;yes;integer;s;Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the MeterValuesRequest or TransactionEventRequest message.
+AlignedDataCtrlr;Measurands;;yes;MemberList;;Clock-aligned measurand(s) to be included in MeterValuesRequest or TransactionEventRequest, every AlignedDataInterval seconds.
+AlignedDataCtrlr;SendDuringIdle;;no;boolean;;If set to true, the Charging Station SHALL NOT send clock aligned meter values when a transaction is ongoing.
+AlignedDataCtrlr;SignReadings;;no;boolean;;If set to true, the Charging Station SHALL include signed meter values in the SampledValueType in theTransactionEventRequest(Ended).
+AlignedDataCtrlr;SignUpdatedReadings;;no;boolean;;If set to true, the Charging Station SHALL include signed meter values in the SampledValueType in theTransactionEventRequest(Updated).
+AlignedDataCtrlr;TxEndedInterval;;yes;integer;s;Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the TransactionEventRequest (eventType = Ended) message.
+AlignedDataCtrlr;TxEndedMeasurands;;yes;MemberList;;Clock-aligned measurands to be included in the meterValues element of TransactionEventRequest (eventType = Ended), every SampledDataTxEndedInterval seconds from the start of the transaction.
+AlignedDataCtrlr;UpstreamInterval;;no;integer;s;Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the MeterValuesRequest message for location `Upstream` only.
+AlignedDataCtrlr;UpstreamMeasurands;;no;MemberList;;Clock-aligned measurand(s) to be included in MeterValuesReques for location `Upstream` only.
+AuthCacheCtrlr;Available;;no;boolean;;Authorization caching is available, but not necessarily enabled.
+AuthCacheCtrlr;Enabled;;no;boolean;;If set to true, Authorizaiton caching is enabled.
+AuthCacheCtrlr;LifeTime;;no;integer;;Indicates how long it takes until a token expires in the authorization cache since it is last used
+AuthCacheCtrlr;Policy;;no;OptionList;;Cache Entry Replacement Policy: least recently used, least frequently used, first in first out, other custom mechanism.
+AuthCacheCtrlr;Storage;;no;integer;B;Indicates the number of bytes currently used by the Authorization Cache. MaxLimit indicates the maximum number of bytes that can be used by the Authorization Cache.
+AuthCacheCtrlr;DisablePostAuthorize;;no;boolean;;When set to true this variable disables the behavior to request authorization for an idToken that is stored in the cache with a status other than Accepted, as stated in C10.FR.03 and C12.FR.05.
+AuthCtrlr;AdditionalInfoItemsPerMessage;;no;integer;;Maximum number of AdditionalInfo items that can be sent in one message.
+AuthCtrlr;AuthorizeRemoteStart;;yes;boolean;;Whether a remote request to start a transaction in the form of RequestStartTransactionRequest message should be authorized beforehand like a local action to start a transaction.
+AuthCtrlr;Enabled;;no;boolean;;If set to false, then no authorization is done before starting a transaction or when reading an idToken. If an idToken was provided, then it will be put in the idToken field of the TransactionEventRequest. If no idToken was provided, then idToken in TransactionEventRequest will be left empty and type is set to NoAuthorization.
+AuthCtrlr;LocalAuthorizeOffline;;yes;boolean;;Whether the Charging Station, when Offline, will start a transaction for locally-authorized identifiers
+AuthCtrlr;LocalPreAuthorize;;yes;boolean;;Whether the Charging Station, when online, will start a transaction for locally-authorized identifiers without waiting for or requesting an AuthorizeResponse from the CSMS.
+AuthCtrlr;MasterPassGroupId;;no;string;;IdTokens that have this id as groupId belong to the Master Pass Group. Meaning they can stop any ongoing transaction, but cannot start transactions.
+AuthCtrlr;OfflineTxForUnknownIdEnabled;;no;boolean;;Support for unknown offline transactions.
+AuthCtrlr;DisableRemoteAuthorization;;no;boolean;;When set to true this instructs the Charging Station to not issue any AuthorizationRequests, but only use Authorization Cache and Local Authorization List to determine validity of idTokens.
+AuthCtrlr;SupportedIdTokenType;;no;MemberList;;"The subset of the list of supported IdTokenTypes as defined in Appendix 7. ""Standardized values for enumerations as string: IdTokenEnumStringType"", that is supported by the Charging Station."
+CHAdeMOCtrlr;SelftestActive;;no;boolean;;Self-test is active or self-test is started by setting to true.
+CHAdeMOCtrlr;CHAdeMOProtocolNumber;;no;integer;;CHAdeMO protocol number (H'102.0)
+CHAdeMOCtrlr;VehicleStatus;;no;boolean;;Vehicle status (H'102.5.3)
+CHAdeMOCtrlr;DynamicControl;;no;boolean;;Vehicle is compatible with dynamic control (H'110.0.0)
+CHAdeMOCtrlr;HighCurrentControl;;no;boolean;;Vehicle is compatible with high current control (H'110.0.1)
+CHAdeMOCtrlr;HighVoltageControl;;no;boolean;;Vehicle is compatible with high voltage control (H'110.1.2)
+CHAdeMOCtrlr;AutoManufacturerCode;;no;integer;;Auto manufacturer code (H'700.0)
+ChargingStation;AllowNewSessionsPendingFirmwareUpdate;;no;boolean;;Indicates whether new sessions can be started on EVSEs, while Charging Station is waiting for all EVSEs to become Available in order to start a pending firmware update
+ChargingStation;AvailabilityState;;yes;OptionList;;This variable reports current availability state for the ChargingStation
+ChargingStation;Available;;yes;boolean;;Component exists
+ChargingStation;Model;;no;string;;Charging station model as reported in BootNotification.
+ChargingStation;SupplyPhases;;yes;integer;;Number of alternating current phases connected/available.
+ChargingStation;VendorName;;no;string;;Charging station vendor name as reported in BootNotification.
+ChargingStation;ActiveTransactionId;;no;string;;This variable for the ChargingStation component contains a comma-separated list of transaction IDs actively running on the Charging Station.
+ClockCtrlr;DateTime;;yes;dateTime;;Contains the current date and time
+ClockCtrlr;NextTimeOffsetTransitionDateTime;;no;dateTime;;Date time of the next time offset transition.
+ClockCtrlr;NtpServerUri;;no;string;;This contains the address of the NTP server.
+ClockCtrlr;NtpSource;;no;OptionList;;When an NTP client is implemented, this variable can be used to configure the client
+ClockCtrlr;TimeAdjustmentReportingThreshold;;no;integer;;If set, then time adjustments with an absolute value in seconds larger than this need to be reported as a security event SettingSystemTime
+ClockCtrlr;TimeOffset;;no;string;;A Time Offset with respect to Coordinated Universal Time (aka UTC or Greenwich Mean Time) in the form of an [RFC3339] time (zone) offset suffix, including the mandatory +\9dor - prefix.
+ClockCtrlr;TimeSource;;yes;SequenceList;;Via this variable, the Charging Station provides the CSMS with the option to configure multiple clock sources
+ClockCtrlr;TimeZone;;no;string;;"Configured current local time zone in the format: ""Europe/Oslo"", ""Asia/Singapore"" etc. For display purposes."
+ConnectedEV;ProtocolAgreed;;V2X;string;;Information about uri and version that was agreed upon between EV and EVSE in the supportedAppProtocolReq message from ISO 15118. Example: urn:iso:15118:2:2013:MsgDef,2,0
+ConnectedEV;ProtocolSupportedByEV;<Priority>;V2X;string;;Information from the supportedAppProtocolReq message from ISO 15118. Each priority is given its own variable instance. Example: urn:iso:15118:2:2013:MsgDef,2,0
+ConnectedEV;VehicleID;;V2X;string;;EVCCID (from ISO 15118 SessionSetupReq)
+ConnectedEV;VehicleCertificate;Leaf;V2X;string;;The PEM encoded X.509 Leaf certificate of the vehicle certificate chain
+ConnectedEV;VehicleCertificate;SubCA1;V2X;string;;The PEM encoded X.509 Intermediate certificate of the vehicle certificate chain
+ConnectedEV;VehicleCertificate;SubCA2;V2X;string;;The PEM encoded X.509 Intermediate certificate of the vehicle certificate chain
+ConnectedEV;VehicleCertificate;Root;V2X;string;;The PEM encoded X.509 Root certificate of the vehicle certificate chain
+ConnectedEV;ACCurrent.min/maxSet;;no;decimal;A;EV min/max AC current
+ConnectedEV;DCCurrent.min/maxSet;;no;decimal;A;EV min/max DC current
+ConnectedEV;DCCurrent.target;;no;decimal;V;EV target current from DC_ChargeLoopReq
+ConnectedEV;DCVoltage.min/maxSet;;no;decimal;V;EV min/max DC voltage
+ConnectedEV;DCVoltage.target;;no;decimal;V;EV target voltage from DC_ChargeLoopReq
+ConnectedEV;Power.maxSet;;no;decimal;W;EV max power limit
+ConnectedEV;DischargePower.maxSet;;no;decimal;W;EV max discharge power limit
+ConnectedEV;EnergyImport.maxSet;;no;decimal;Wh;EV energy capacity / maximum energy request
+ConnectedEV;EnergyImport.minSet;;no;decimal;Wh;EV minimum energy request
+ConnectedEV;EnergyImport.target;;no;decimal;Wh;EV target energy request
+ConnectedEV;BatteryCapacity;;no;decimal;Wh;EV battery capacity
+ConnectedEV;DepartureTime;;no;DateTime;;EV planned departure time
+ConnectedEV;RemainingTimeBulk;;no;integer;s;Remaining time to bulk SoC
+ConnectedEV;RemainingTimeFull;;no;integer;s;Remaining time to full SoC
+ConnectedEV;StateOfChargeBulk;;no;integer;%;Defined % for bulk SoC
+ConnectedEV;StateOfCharge.maxSet;;no;integer;%;Defined % for full SoC
+ConnectedEV;StateOfCharge.actual;;no;integer;%;Current SoC
+ConnectedEV;ChargingCompleteBulk;;no;boolean;;Charging to bulk SoC is complete
+ConnectedEV;ChargingCompleteFull;;no;boolean;;Charging to full SoC is complete
+ConnectedEV;ChargingState;;no;OptionList;;EVTerminationCode to signal error condition
+Connector;AvailabilityState;;no;OptionList;;This variable reports current availability state for the Connector. Optional, because already reported in StatusNotification.
+Connector;Available;;yes;boolean;;Component exists
+Connector;ChargeProtocol;;no;string;;The Charging Control Protocol applicable to a Connector. CHAdeMO: CHAdeMO protocol, ISO15118: ISO15118 V2G protocol (wired or wireless) as used with CCS, CPPWM: IEC61851-1 / SAE J1772 protocol (ELV DC & PWM signalling via Control Pilot wire), Uncontrolled: No charging power management applies (e.g. Schuko socket), Undetermined: Yet to be determined (e.g. before plugged in), Unknown: Not determinable, NOTE: ChargeProtocol is distinct from and orthogonal to connectorType.
+Connector;ConnectorType;;yes;string;;A value of ConnectorEnumType (See part 2) plus additionally: cGBT, cChaoJi, OppCharge. Specific type of connector, including sub-variant information. Note: Distinct and orthogonal to Charging Protocol, Power Type, Phases.
+Connector;SupplyPhases;;yes;integer;;Number of alternating current phases connected/available.
+Connector;SlotStatus;;no;OptionList;;Battery slot status of swapping station: Open, Locked, Faulted.
+CPPWMController;State;;no;string;;"IEC 61851-1 states (""A"" to ""E"")"
+CustomizationCtrlr;CustomImplementationEnabled;<vendorId>;no;boolean;;Custom implementation <vendorId> has been enabled.
+CustomizationCtrlr;CustomTriggers;;no;MemberList;;This variable defines the names of custom triggers that Charging Station supports in a customTrigger field of TriggerMessageRequest.
+DeviceDataCtrlr;BytesPerMessage;GetReport;yes;integer;;Maximum number of bytes in a message related to instance name: GetReport, GetVariables, SetVariables
+DeviceDataCtrlr;BytesPerMessage;GetVariables;yes;integer;;Maximum number of bytes in a message related to instance name: GetReport, GetVariables, SetVariables
+DeviceDataCtrlr;BytesPerMessage;SetVariables;yes;integer;;Maximum number of bytes in a message related to instance name: GetReport, GetVariables, SetVariables
+DeviceDataCtrlr;ConfigurationValueSize;;no;integer;;The limit to the following fields: SetVariableData.attributeValue and VariableCharacteristics.valueList. The max size of these values will always remain equal.
+DeviceDataCtrlr;ItemsPerMessage;GetReport;yes;integer;;Maximum number of ComponentVariable entries in message related to the instance name: GetReport, GetVariables, SetVariables
+DeviceDataCtrlr;ItemsPerMessage;GetVariables;yes;integer;;Maximum number of ComponentVariable entries in message related to the instance name: GetReport, GetVariables, SetVariables
+DeviceDataCtrlr;ItemsPerMessage;SetVariables;yes;integer;;Maximum number of ComponentVariable entries in message related to the instance name: GetReport, GetVariables, SetVariables
+DeviceDataCtrlr;ReportingValueSize;;no;integer;;The limit to the following fields: GetVariableResult.attributeValue, VariableAttribute.value and EventData.actualValue. The max size of these values will always remain equal.
+DeviceDataCtrlr;ValueSize;;no;integer;;Can be used to limit the following fields: SetVariableData.attributeValue, GetVariableResult.attributeValue, VariableAttribute.value, VariableCharacteristics.valueList and EventData.actualValue.
+DisplayMessageCtrlr;Available;;no;boolean;;Whether display messages are supported.
+DisplayMessageCtrlr;DisplayMessages;;yes;integer;;Amount of different messages that are currently configured in this Charging Station, via SetDisplayMessageRequest
+DisplayMessageCtrlr;Enabled;;no;boolean;;Whether display messages are enabled.
+DisplayMessageCtrlr;SupportedStates;;yes;MemberList;;List of the states during which to display a message supported by this Charging Station.
+DisplayMessageCtrlr;SupportedFormats;;yes;MemberList;;List of message formats supported by this Charging Station.
+DisplayMessageCtrlr;SupportedPriorities;;yes;MemberList;;List of the priorities supported by this Charging Station.
+DisplayMessageCtrlr;Language;;yes;OptionList;;Default language code, per RFC 5646, of this Charging Station. Languages that are supported are listed in the valuesList.
+EVSE;AllowReset;;no;boolean;;Can be used to announce that an EVSE can be reset individually
+EVSE;AvailabilityState;;yes;OptionList;;This variable reports current availability state for the EVSE
+EVSE;Available;;yes;boolean;;Component exists
+EVSE;EvseId;;no;string;;The name of the EVSE in the string format as required by ISO 15118 and IEC 63119-2.
+EVSE;Power;;yes;decimal;W, kW;The variableCharacteristic maxLimit, that holds the maximum power that this EVSE can provide, is required. The Actual value of the instantaneous (real) power is desired, but not required.
+EVSE;DischargePower;;V2X;decimal;W, kW;The variableCharacteristic maxLimit holds the maximum rated discharge power that this EVSE can provide. The variableCharacteristic maxSet holds the maximum configured discharge power that this EVSE can provide. The Actual value of the instantaneous (real) discharge power is recommended to be supported, but not required. Discharge power is represented by a positive value.
+EVSE;SupplyPhases;;yes;integer;;Number of alternating current phases connected/available.
+EVSE;DCInputPhaseControl;;no;boolean;; When DCInputPhaseControl is true, then the values of numberPhases and PhaseToUse in a ChargingSchedulePeriodType will select the input phases from the grid to be used by the DC EVSE.
+EVSE;ISO15118EvseId;;no;string;;"The name of the EVSE in the string format as required by ISO 15118 and IEC 63119-2. Example: ""DE*ICE*E*1234567890*1"""
+EVSE;ChargingState;;no;OptionList;;This variable reports the current transaction charging state for an EVSE.
+EVSE;ActiveTransactionId;;no;string;;This variable contains the transaction ID of the running transaction at the EVSE. If no transaction is active, it is an empty string.
+FiscalMetering;EnergyExport;;no;decimal;Wh, kWh;Total energy transferred: e.g. from EV during (ongoing or terminated) charging session (in wH by default)
+FiscalMetering;EnergyExportRegister;;no;decimal;Wh, kWh;Cumulative export kWh register value, such as from a (certified) fiscal energy meter.
+FiscalMetering;EnergyImport;;no;decimal;Wh, kWh;Total energy transferred.
+FiscalMetering;EnergyImportRegister;;no;decimal;Wh, kWh;Cumulative export kWh register value, such as from a (certified) fiscal energy meter.
+FiscalMetering;PublicKey ;;no;string;;The public key for a meter connected to a specific EVSE.
+ISO15118Ctrlr;CentralContractValidationAllowed;;no;boolean;;If this variable exists and has the value true, then Charging Station can provide a contract certificate that it cannot validate, to the CSMS for validation as part of the AuthorizeRequest.
+ISO15118Ctrlr;ContractValidationOffline;;yes;boolean;;If this variable is true, then Charging Station will try to validate a contract certificate when it is offline
+ISO15118Ctrlr;SeccId;;no;string;;The ID of the SECC in string format as defined by ISO15118.
+ISO15118Ctrlr;MaxScheduleEntries;;no;integer;;Maximum number of allowed schedule periods.
+ISO15118Ctrlr;RequestedEnergyTransferMode;;no;OptionList;;The requested energy transfer mode.
+ISO15118Ctrlr;RequestMeteringReceipt;;no;boolean;;If true, then Charging Station shall request a metering receipt from EV.
+ISO15118Ctrlr;CountryName;;no;string;;"The countryName of the SECC in the ISO 3166-1 format. It is used as the countryName (C) of the SECC leaf certificate. Example: ""DE"""
+ISO15118Ctrlr;OrganizationName;;no;string;;"The organizationName of the CSO operating the charging station. It is used as the organizationName (O) of the SECC leaf certificate. Example: ""John Doe Charging Services Ltd"" Note: This value will usually be identical to SecurityCtrlr.OrganizationName, but it does not have to be."
+ISO15118Ctrlr;PnCEnabled;;no;boolean;;If this variable is true, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is enabled. If this variable is false, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is disabled.
+ISO15118Ctrlr;V2GCertificateInstallationEnabled;;no;boolean;;If this variable is true, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station is enabled. If this variable is false, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station is disabled.
+ISO15118Ctrlr;ContractCertificateInstallationEnabled;;no;boolean;;If this variable is true, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is enabled. If this variable is false, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is disabled.
+ISO15118Ctrlr;CertificateStatusSource;;no;MemberList;;When present, this variable tells CSMS whether Charging Station uses OCSP or CRL to check for revoked certificates.
+ISO15118Ctrlr;NotificationDelay;;no;integer;s;The SECC (EVSE) uses the NotificationMaxDelay element in the EVSEStatus to indicate the time in seconds until it expects the EVCC (EV) to react on the action request indicated in EVSENotification.
+ISO15118Ctrlr;ServiceRenegotiationSupport;;no;boolean;;If set to 'True' the SECC (EVSE) is capable of ServiceRenegotiation.
+ISO15118Ctrlr;SupportedProviders;;no;string;;A comma-separated list of all providers (eMSPs) that are supported on this Charging Station. The providers are listed using country and provider ID from the EMAID, as defined in ISO 15118-20.
+ISO15118Ctrlr;MaxPriceElements;;no;integer;;The maximum number of priceRuleStacks and priceLevelScheduleEntries that Charging Station is able to accept in a ChargingScheduleType.
+ISO15118Ctrlr;ProtocolSupported;1, 2 .. 20;no;string;;A string with the following comma-separated items: \93<uri>,<major>,<minor>\94. <uri> is in the format as used in the SupportedAppProtocolReq message from ISO 15118-2 and ISO 15118-20.
+LocalAuthListCtrlr;Available;;no;boolean;;Local Authorization List is available.
+LocalAuthListCtrlr;BytesPerMessage;;yes;integer;;Maximum number of bytes in a SendLocalList message.
+LocalAuthListCtrlr;Enabled;;no;boolean;;If this variable exists and reports a value of true, Local Authorization List is enabled.
+LocalAuthListCtrlr;Entries;;yes;integer;;Amount of IdTokens currently in the Local Authorization List
+LocalAuthListCtrlr;ItemsPerMessage;;yes;integer;;Maximum number of records in SendLocalList
+LocalAuthListCtrlr;Storage;;no;integer;B;Indicates the number of bytes currently used by the Local Authorization List. MaxLimit indicates the maximum number of bytes that can be used by the Local Authorization List.
+LocalAuthListCtrlr;DisablePostAuthorize;;no;boolean;;When set to true this variable disables the behavior to request authorization for an idToken that is stored in the local authorization list with a status other than Accepted, as stated in C14.FR.03.
+LocalAuthListCtrlr;SupportsExpiryDateTime;;no;boolean;;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.
+LocalEnergyStorage;Capacity;;no;decimal;Wh;Maximum storage capacity
+;;;;;;
+MonitoringCtrlr;Available;;no;boolean;;Whether monitoring is available
+MonitoringCtrlr;BytesPerMessage;ClearVariableMonitoring;no;integer;;Maximum number of bytes in a ClearVariableMonitoring message.
+MonitoringCtrlr;BytesPerMessage;SetVariableMonitoring;yes;integer;;Maximum number of bytes in a SetVariableMonitoring message
+MonitoringCtrlr;Enabled;;no;boolean;;Whether monitoring is enabled.
+MonitoringCtrlr;ItemsPerMessage;ClearVariableMonitoring;no;integer;;Maximum number of IDs in a ClearVariableMonitoringRequest.
+MonitoringCtrlr;ItemsPerMessage;SetVariableMonitoring;yes;integer;;Maximum number of setMonitoringData elements that can be sent in one setVariableMonitoringRequest message.
+MonitoringCtrlr;OfflineQueuingSeverity;;no;integer;;When set and the Charging Station is offline, the Charging Station shall queue any notifyEventRequest messages triggered by a monitor with a severity number equal to or lower than the severity configured here.
+MonitoringCtrlr;MonitoringBase;;no;OptionList;;Currently used monitoring base (readonly)
+MonitoringCtrlr;MonitoringLevel;;no;integer;;Currently used monitoring level (readonly)
+MonitoringCtrlr;ActiveMonitoringBase;;no;OptionList;;Shows the last set MonitoringBase. Valid values according MonitoringBaseEnumType: All, FactoryDefault, HardwiredOnly.
+MonitoringCtrlr;ActiveMonitoringLevel;;no;integer;;Shows the currently used MonitoringLevel. Valid values are severity levels of SetMonitoringLevelRequest: 0-9.
+MonitoringCtrlr;MaxPeriodicEventStreams;;no;integer;;The maximum number of open periodic event streams that Charging Station supports.
+OCPPCommCtrlr;ActiveNetworkProfile;;no;string;;Indicates the configuration profile the station uses at that moment to connect to the network.
+OCPPCommCtrlr;FileTransferProtocols;;yes;MemberList;;List of supported file transfer protocols
+OCPPCommCtrlr;HeartbeatInterval;;no;integer;s;Interval of inactivity (no OCPP exchanges) with CSMS after which the Charging Station should send HeartbeatRequest.
+OCPPCommCtrlr;MessageTimeout;Default;yes;integer;s;MessageTimeout(Default) specifies after which time a message times out. It is configured in the network connection profile.
+OCPPCommCtrlr;MessageAttemptInterval;TransactionEvent;yes;integer;;MessageAttemptInterval(TransactionEvent) specifies long the Charging Station should wait before resubmitting a TransactionEventRequest message that the CSMS failed to process.
+OCPPCommCtrlr;MessageAttempts;TransactionEvent;yes;integer;;MessageAttempts(TransactionEvent) specifies how often the Charging Station should try to submit a TransactionEventRequest message when the CSMS fails to process it.
+OCPPCommCtrlr;NetworkConfigurationPriority;;yes;string;;A comma separated ordered list of the priority of the possible Network Connection Profiles.
+OCPPCommCtrlr;NetworkProfileConnectionAttempts;;yes;integer;;Specifies the number of connection attempts the Charging Station executes before switching to a different profile.
+OCPPCommCtrlr;OfflineThreshold;;yes;integer;s;When the offline period of a Charging Station exceeds the OfflineThreshold it is recommended to send a StatusNotificationRequest for all its Connectors.
+OCPPCommCtrlr;PublicKeyWithSignedMeterValue;;no;OptionList;;This Configuration Variable can be used to configure whether a public key needs to be sent with a signed meter value. Note, that the field is required, so it needs to be present as an empty string when the public key is not sent.
+OCPPCommCtrlr;QueueAllMessages;;no;boolean;;When this variable is set to true, the Charging Station will queue all message until they are delivered to the CSMS.
+OCPPCommCtrlr;ResetRetries;;yes;integer;;Number of times to retry a reset of the Charging Station when a reset was unsuccessful
+OCPPCommCtrlr;RetryBackOffRandomRange;;no;integer;;When the Charging Station is reconnecting, after a connection loss, it will use this variable as the maximum value for the random part of the back-off time
+OCPPCommCtrlr;RetryBackOffRepeatTimes;;no;integer;;When the Charging Station is reconnecting, after a connection loss, it will use this variable for the amount of times it will double the previous back-off time.
+OCPPCommCtrlr;RetryBackOffWaitMinimum;;no;integer;;When the Charging Station is reconnecting, after a connection loss, it will use this variable as the minimum back-off time, the first time it tries to reconnect.
+OCPPCommCtrlr;UnlockOnEVSideDisconnect;;yes;boolean;;When set to true, the Charging Station SHALL unlock the cable on the Charging Station side when the cable is unplugged at the EV. For an EVSE with only fixed cables, the mutability SHALL be ReadOnly and the actual value SHALL be false. For a charging station with fixed cables and sockets, the variable is only applicable to the sockets.
+OCPPCommCtrlr;WebSocketPingInterval;;no;integer;s;0 disables client side websocket Ping/Pong. In this case there is either no ping/pong or the server initiates the ping and client responds with Pong. Positive values are interpreted as number of seconds between pings. Negative values are not allowed.
+OCPPCommCtrlr;FieldLength;;no;integer;;This variable is used to report the length of <field> in <message> when it is larger than the length that is defined in the standard OCPP message schema.
+OCPPCommCtrlr;ExternalConfigChangeDate;;no;DateTime;;Date/time when the configuration was changed externally, i.e. outside of CSMS, for example by a local service action.
+ReservationCtrlr;Available;;no;boolean;;Whether reservation is supported.
+ReservationCtrlr;Enabled;;no;boolean;;Whether reservation is enabled.
+ReservationCtrlr;NonEvseSpecific;;no;boolean;;If this configuration variable is present and set to true: Charging Station supports Reservation where EVSE id is not specified.
+SampledDataCtrlr;Available;;no;boolean;;If this variable reports a value of true, Sampled Data is supported
+SampledDataCtrlr;Enabled;;no;boolean;;If this variable reports a value of true, Sampled Data is enabled.
+SampledDataCtrlr;SignReadings;;no;boolean;;If set to true, the Charging Station SHALL include signed meter values in the TransactionEventRequest to the CSMS
+SampledDataCtrlr;SignStartedReadings;;;;;If set to true, the Charging Station SHALL include signed meter values for context_= `Transaction.Begin` in the metervalues field in the TransactionEventRequest(Started or Updated)+
+SampledDataCtrlr;SignUpdatedReadings;;;;;If set to true, the Charging Station SHALL include signed meter values in the TransactionEventRequest Updated)
+SampledDataCtrlr;TxEndedInterval;;yes;integer;s;Interval between sampling of metering (or other) data, intended to be transmitted in the TransactionEventRequest (eventType = Ended) message.
+SampledDataCtrlr;TxEndedMeasurands;;yes;MemberList;;Sampled measurands to be included in the meterValues element of TransactionEventRequest (eventType = Ended), every SampledDataTxEndedInterval seconds from the start of the transaction.
+SampledDataCtrlr;TxStartedMeasurands;;yes;MemberList;;Sampled measurand(s) to be taken at the start of any transaction to be included in the meterValues field of the first TransactionEventRequest message send at the start of a transaction (eventType = Started)
+SampledDataCtrlr;TxUpdatedInterval;;yes;integer;s;Interval between sampling of metering (or other) data, intended to be transmitted via TransactionEventRequest (eventType = Updated) messages
+SampledDataCtrlr;TxUpdatedMeasurands;;yes;MemberList;;Sampled measurands to be included in the meterValues element of TransactionEventRequest (eventType = Ended)
+SampledDataCtrlr;RegisterValuesWithoutPhases;;no;boolean;;If this variable reports a value of true, then meter values of measurand Energy.Active.Import.Register will only report the total energy over all phases without reporting the individual phase values. If this variable is absent or false, then the value for each phase is reported, possibly also with a total value (depending on the meter).
+SampledDataCtrlr;UpstreamInterval;;no;integer;s;Size (in seconds) of the samplng interval, intended to be transmitted in the TransactionEventyRequest message for location `Upstream` only.
+SampledDataCtrlr;UpstreamMeasurands;;no;MemberList;;Sampled measurand(s) to be included in TransactionEventRequest for location `Upstream` only.
+SecurityCtrlr;AllowSecurityProfileDowngrade;;no;boolean;;If this variable is implemented and set to true, then the Charging Station allows downgrading the security profile from 3 to 2.
+SecurityCtrlr;AdditionalRootCertificateCheck;;no;boolean;;Required for all security profiles except profile 1.
+SecurityCtrlr;BasicAuthPassword;;no;passwordString;;The basic authentication password is used for HTTP Basic Authentication.
+SecurityCtrlr;CertificateEntries;;yes;integer;;Amount of Certificates currently installed on the Charging Station
+SecurityCtrlr;CertSigningRepeatTimes;;no;integer;;Number of times to resend a SignCertificateRequest when CSMS does nor return a signed certificate.
+SecurityCtrlr;CertSigningWaitMinimum;;no;integer;s;Seconds to wait before generating another CSR in case CSMS does not return a signed certificate.
+SecurityCtrlr;Identity;;no;identifierString;;The Charging Station identity.
+SecurityCtrlr;MaxCertificateChainSize;;no;integer;;Limit of the size of the 'certificateChain' field from the CertificateSignedRequest
+SecurityCtrlr;OrganizationName;;yes;string;;The organization name of the CSO or an organization trusted by the CSO. This organization name is used to specify the subject field in the client certificate.
+SecurityCtrlr;SecurityProfile;;yes;integer;;The security profile used by the Charging Station.
+SmartChargingCtrlr;ACPhaseSwitchingSupported;;no;boolean;;This variable can be used to indicate an on-load/in-transaction capability. If defined and true, this EVSE supports the selection of which phase to use for 1 phase AC charging.
+SmartChargingCtrlr;Available;;no;boolean;;Whether smart charging is supported.
+SmartChargingCtrlr;Enabled;;no;boolean;;Whether smart charging is enabled.
+SmartChargingCtrlr;Entries;ChargingProfiles;yes;integer;;Entries(ChargingProfiles) is the amount of Charging profiles currently installed on the Charging Station
+SmartChargingCtrlr;ExternalControlSignalsEnabled;;no;boolean;;Indicates whether a Charging Station should respond to external control signals that influence charging.
+SmartChargingCtrlr;LimitChangeSignificance;;yes;decimal;Percent;If at the Charging Station side a change in the limit in a ChargingProfile is lower than this percentage, the Charging Station MAY skip sending a NotifyChargingLimitRequest or a TransactionEventRequest message to the CSMS.
+SmartChargingCtrlr;NotifyChargingLimitWithSchedules;;no;boolean;;Indicates if the Charging Station should include the externally set charging limit/schedule in the message when it sends a NotifyChargingLimitRequest message.
+SmartChargingCtrlr;PeriodsPerSchedule;;yes;integer;;Maximum number of periods that may be defined per ChargingSchedule.
+SmartChargingCtrlr;Phases3to1;;no;boolean;;If defined and true, this Charging Station supports switching from 3 to 1 phase during a transaction
+SmartChargingCtrlr;ProfileStackLevel;;yes;integer;;Maximum acceptable value for stackLevel in a ChargingProfile. Since the lowest stackLevel is 0, this means that if SmartChargingCtrlr.ProfileStackLevel = 1, there can be at most 2 valid charging profiles per Charging Profile Purpose per EVSE.
+SmartChargingCtrlr;RateUnit;;yes;MemberList;;A list of supported quantities for use in a ChargingSchedule. Allowed values: 'A' and 'W
+SmartChargingCtrlr;ExternalConstraintsProfileDisallowed;;no;boolean;;Indicates whether a Charging Station allows an external system to submit limits to be represented as a `ChargingStationExternalConstraints` charging profile.
+SmartChargingCtrlr;ChargingProfilePersistence;TxProfile;no;boolean;;If an instance of this variable is true, then charging profiles with the chargingProfilePurpose mentioned in the variableInstance are persistent, i.e. they are stored persistently and will still exist after a reboot.
+SmartChargingCtrlr;ChargingProfilePersistence;LocalGeneration;no;boolean;;If an instance of this variable is true, then charging profiles with the chargingProfilePurpose mentioned in the variableInstance are persistent, i.e. they are stored persistently and will still exist after a reboot.
+SmartChargingCtrlr;ChargingProfilePersistence;ChargingStationExternalConstraints;no;boolean;;If an instance of this variable is true, then charging profiles with the chargingProfilePurpose mentioned in the variableInstance are persistent, i.e. they are stored persistently and will still exist after a reboot.
+SmartChargingCtrlr;SetpointPriority;;no;OptionList;;"Defines which setpoint shall be used when a `ChargingStationExternalConstraints` profile
+with a operationMode = `ExternalSetpoint` is active, but at the same time a `Tx(Default)Profile`
+charging profile is also active with a setpoint."
+SmartChargingCtrlr;MaxExternalConstraintsId;;no;integer;;Defines the highest value that a charging profile id of a `ChargingStationExternalConstraints` profile in the Charging Station can have.
+SmartChargingCtrlr;SupportedAdditionalPurposes;;no;MemberList;;This configuration variable lists the additional chargingProfilePurposes, that have been introduced in OCPP 2.1, that are supported by the Charging Station.
+SmartChargingCtrlr;SupportsDynamicProfiles;;no;boolean;;When this variable has value True, then the Charging Station supports charging profiles of kind `Dynamic`.
+SmartChargingCtrlr;SupportsMaxOfflineDuration;;no;boolean;;When this variable has value True, then the Charging Station supports the fields maxOfflineDuration and invalidAfterOfflineDuration in a charging profile.
+SmartChargingCtrlr;SupportsUseLocalTime;;no;boolean;;When this variable has value True, then the Charging Station supports the field useLocalTime in a charging schedule.
+SmartChargingCtrlr;SupportsRandomizedDelay;;no;boolean;;When this variable has value True, then the Charging Station supports the field randomizedDelay_in a charging schedule, which will delay the start of each charging schedule period by a random number between 0 and randomizedDelay.
+SmartChargingCtrlr;SupportsLimitAtSoC;;no;boolean;;When this variable has value True, then the Charging Station supports the field limitAtSoC in a charging schedule, which will cap the limit or setpoint in the ChargingSchedulePeriodType by the value of _imitAtSoC.limit.
+SmartChargingCtrlr;SupportsEvseSleep;;no;boolean;;When reported as true the Charging Station supports the evseSleep flag in a charging schedule period, which requests the EVSE electronics to go to sleep during operationMode = 'Idle'.
+TariffCostCtrlr;Available;Tariff;no;boolean;;If true then the Charging Station supports the TariffType structure,
+TariffCostCtrlr;Available;Cost;no;boolean;;If true, then Charging Station supports local cost calculation.
+TariffCostCtrlr;Currency;;yes;string;;Currency used by this Charging Station in a ISO 4217 [ISO4217] formatted currency code.
+TariffCostCtrlr;Enabled;Tariff;no;boolean;;If true then the Charging Station has enabled support for the TariffType structure, that describes the tariff in a machine-readable format.
+TariffCostCtrlr;Enabled;Cost;no;boolean;;If true, then local cost calculation is enabled on Charging Station.
+TariffCostCtrlr;Enabled;RunningCost;no;boolean;;If true then Charging Station will provide periodic running cost updates in costDetails in TransactionEventRequest messages.
+TariffCostCtrlr;TariffFallbackMessage;<language>;yes;string;;Message (and/or tariff information) to be shown to an EV Driver when there is no driver specific tariff information available.
+TariffCostCtrlr;TotalCostFallbackMessage;<language>;yes;string;;Message to be shown to an EV Driver when the Charging Station cannot retrieve the cost for a transaction at the end of the transaction.
+TariffCostCtrlr;OfflineTariffFallbackMessage;<language>;no;string;;Message (and/or tariff information) to be shown to an EV Driver when Charging Station is offline.
+TariffCostCtrlr;Interval;Tariff;no;integer;s;Interval specifies the maximum interval in seconds to use when evaluating the conditions regarding current, power and energy of a tariff element during a transaction.
+TariffCostCtrlr;Interval;Cost;no;integer;s;Specifies the interval in seconds to use to provide periodic running cost updates during a transaction.
+TariffCostCtrlr;MaxElements;Tariff;no;integer;;Specifies the maximum number of prices elements that the Charging Station supports in each energy, chargingTime, idleTime and fixedFee field of a TariffType.
+TariffCostCtrlr;ConditionsSupported;Tariff;no;boolean;;If set to true the Charging Station supports tariffs with conditions.
+TariffCostCtrlr;HandleFailedTariff;Tariff;no;OptionList;;This configuration determines how to act when a driver-specific tariff is received, which cannot be processed.
+TokenReader;Token;;no;string;;String of bytes representing an ID token.
+TokenReader;TokenType;;no;OptionList;;Type of Token. Value is one of IdTokenEnumType.
+TxCtrlr;ChargingTime;;no;decimal;s;Time from earliest to latest substantive energy transfer
+TxCtrlr;EVConnectionTimeOut;;yes;integer;s;"Interval from between ""starting"" of a transaction until incipient transaction is automatically canceled, due to failure of EV driver to (correctly) insert the charging cable connector(s) into the appropriate socket(s). "
+TxCtrlr;MaxEnergyOnInvalidId;;no;integer;;Maximum amount of energy in Wh delivered when an identifier is deauthorized by the CSMS after start of a transaction.
+TxCtrlr;StopTxOnEVSideDisconnect;;yes;boolean;;When set to true, the Charging Station SHALL deauthorize the transaction when the cable is unplugged from the EV.
+TxCtrlr;StopTxOnInvalidId;;yes;boolean;;Whether the Charging Station will deauthorize an ongoing transaction when it receives a non- Accepted authorization status in TransactionEventResponse for this transaction.
+TxCtrlr;TxBeforeAcceptedEnabled;;no;boolean;;Allow charging before having received a BootNotificationResponse with RegistrationStatus: Accepted.
+TxCtrlr;TxStartPoint;;yes;MemberList;;Defines when the Charging Station starts a new transaction
+TxCtrlr;TxStopPoint;;yes;MemberList;;Defines when the Charging Station ends a transaction
+TxCtrlr;ResumptionTimeout;;no;integer;s;This variable defines the maximum number of seconds that a transaction may be interrupted by a power outage and still be resumed afterwards.
+TxCtrlr;AllowEnergyTransferResumption;;no;boolean;;This variable defines whether energy transfer is allowed to be resumed when the transaction is resumed after a reset or power outage.
+TxCtrlr;SupportedLimits;;no;MemberList;;This variable defines which transaction limits in TransactionLimitType are supported by the Charging Station.
+V2XChargingCtrlr;Enabled;;yes;boolean;;Way for the CSMS to either activate or deactivate V2X functionality on a Charging Station.
+V2XChargingCtrlr;SupportedEnergyTransferModes;;yes;MemberList;;Lists the energy transfer services that are supported by the Charging Station.
+V2XChargingCtrlr;SupportedOperationModes;;yes;MemberList;;Lists the operation modes that are supported by the Charging Station.
+V2XChargingCtrlr;LocalFrequencyUpdateThreshold;;no;boolean;;The amount of change in net frequency in *mHz* is needed to trigger a recalculation of the setpoint.
+V2XChargingCtrlr;TxStartedMeasurands;<OperationMode>;no;MemberList;;List of sampled measurands to send in addition to those configured in SampledDataCtrlr.TxStartedMeasurands, when the Charging Station is in V2X operation mode <OperationMode>
+V2XChargingCtrlr;TxEndedMeasurands;<OperationMode>;no;MemberList;;List of sampled measurands to send in addition to SampledDataCtrlr.TxEndedMeasurands, when the Charging Station is in V2X operaion mode <OperationMode>.
+V2XChargingCtrlr;TxUpdatedMeasurands;<OperationMode>;no;MemberList;;List of sampled measurands to send in addition to SampledDataCtrlr.TxUpdatedMeasurands, when the Charging Station is in V2X operation mode <OperationMode>.
+V2XChargingCtrlr;TxEndedInterval;<OperationMode>;no;integer;s;The interval used to sample the list of measurands in V2XChargingCtrlr.TxEndedMeasurands, while the Charging Station is in V2X operation mode <OperationMode>.
+V2XChargingCtrlr;TxUpdatedInterval;<OperationMode>;no;integer;s;The interval used to sample the list of measurands in V2XChargingCtrlr.TxUpdatedMeasurands, while the Charging Station is in V2X operation mode <OperationMode>.
+V2XChargingCtrlr;LocalLoadBalancing;UpperThreshold;no;decimal;W;When power (in Watts) exceeds this limit, the local load balancing mechanism will try to imit the power to a maximum of UpperThreshold + UpperOffset.
+V2XChargingCtrlr;LocalLoadBalancing;LowerThreshold;no;decimal;W;When power (in Watts) drops below this limit, the local load balancing mechanism will try to keep the power to a minimum of LowerThreshold + LowerOffset.
+V2XChargingCtrlr;LocalLoadBalancing;UpperOffset;no;decimal;W;An offset value (in Watts) to add to the UpperThreshold. This allows for some tuning of the upper limit without changing the threshold value.
+V2XChargingCtrlr;LocalLoadBalancing;LowerOffset;no;decimal;W;An offset value (in Watts) to add to the LowerThreshold. This allows for some tuning of the lower limit without changing the threshold value.
+FrequencySimulator;Enabled;;no;boolean;;This variable must be set to true in order to activate the FrequencySimulator and gather data with the DataCollector.
+FrequencySimulator;DateTime;Start;no;DateTime;;"If _Enabled_ the FrequencySimulator will simulate a net frequency as long as time >= DateTime[""Start""] and time < DateTime[""End""]."
+FrequencySimulator;DateTime;End;no;DateTime;;"If _Enabled_ the FrequencySimulator will simulate a net frequency as long as time >= DateTime[""Start""] and time < DateTime[""End""]."
+FrequencySimulator;FrequencySchedule;;no;string;;A JSON-formatted string with an array of { time, freq } pairs.
+DataCollector;Enabled;;no;boolean;;This variable must be set to True in order to activate the DataCollector.
+DataCollector;DateTime;Start;no;DateTime;;"If _Enabled_ the DataCollector will sample measurandes from SampledMeasurands as long as time >= DateTime[""Start""] and time < DateTime[""End""]."
+DataCollector;DateTime;End;no;DateTime;;"If _Enabled_ the DataCollector will sample measurandes from SampledMeasurands as long as time >= DateTime[""Start""] and time < DateTime[""End""]."
+DataCollector;SamplingInterval;;no;decimal;s;The sampling interval in seconds.
+DataCollector;SampledMeasurands;;no;MemberList;;The set of measurands to be sampled by the DataCollector.
+DCDERCtrlr;Enabled;;no;boolean;;Whether DC DER control is enabled and DER capabilities are reported in this component.
+DCDERCtrlr;MaxW;;yes;decimal;W;Active power rating in watts at unity power factor
+DCDERCtrlr;OverExcitedW;;yes;decimal;W;Active power rating in watts at specified over-excited power factor
+DCDERCtrlr;OverExcitedPF;;yes;decimal;;Over-excited power factor
+DCDERCtrlr;UnderExcitedW;;yes;decimal;W;Active power rating in watts at specified under-excited power factor
+DCDERCtrlr;UnderExcitedPF;;yes;decimal;;Under-excited power factor
+DCDERCtrlr;MaxVA;;yes;decimal;VA;Maximum apparent power rating in voltamperes
+DCDERCtrlr;MaxVar;;yes;decimal;Var;Maximum injected reactive power rating in vars
+DCDERCtrlr;MaxVarNeg;;yes;decimal;Var;Maximum absorbed reactive power rating in vars
+DCDERCtrlr;MaxChargeRateW;;yes;decimal;W;Maximum active power charge rating in watts
+DCDERCtrlr;MaxChargeRateVA;;yes;decimal;VA;"Maximum apparent power charge rating in voltamperes; may differ from the apparent power maximum rating"
+DCDERCtrlr;VNom;;no;decimal;V;Nominal ac voltage rating in rms volts
+DCDERCtrlr;MaxV;;no;decimal;V;Maximum ac voltage rating in rms volts
+DCDERCtrlr;MinV;;no;decimal;V;Minimum ac voltage rating in rms volts
+DCDERCtrlr;ModesSupported;;yes;MemberList;;Indication of support for each control mode function
+DCDERCtrlr;InverterManufacturer;;yes;string;;Manufacturer of inverter
+DCDERCtrlr;InverterModel;;yes;string;;Model of inverter
+DCDERCtrlr;InverterSerialNumber;;no;string;;Serial number of inverter
+DCDERCtrlr;InverterSwVersion;;yes;string;;Software version of inverter
+DCDERCtrlr;InverterHwVersion;;yes;string;;Hardware version of inverter
+DCDERCtrlr;IslandingDetectionMethod;;no;OptionList;;Type of IslandingDetectionMethod
+DCDERCtrlr;IslandingDetectionTripTime;;no;decimal;s;Time until tripping after island detection
+DCDERCtrlr;ReactiveSusceptance;;yes;decimal;s;Reactive susceptance that remains connected to the electrical power system in the cease to energize and trip state
+ACDERCtrlr;ModesSupported;;yes;MemberList;;Indication of support for each control mode function
+BatterySwapCtrlr;TargetSoC;;no;integer;%;The state of charge that a battery must have in order to be eligible for swapping.
+BatterySwapCtrlr;MaxSoc;;no;integer;%;The maximum state of charge that a battery will be charged to.
+BatterySwapCtrlr;IdToken;;no;string;;The idToken that is used for charging transactions of swap batteries.
+BatterySwapCtrlr;Timeout;In;no;integer;s;imeout in seconds in which a set of batteries must be inserted after successful authorization.
+BatterySwapCtrlr;Timeout;Out;no;integer;s;Timeout in seconds in which the set of batteries that is offered by Charging Station to take out in exchange for the inserted set of batteries must be removed.
+BatteryCartridge;SoC;;no;integer;%;The component BatteryCartridge refers to the battery that is inserted at the EVSE. The variable SoC represents current state of charge as a percentage from 0..100.
+BatteryCartridge;SoH;;no;integer;%;The component BatteryCartridge refers to the battery that is inserted at the EVSE. The variable SoH represents current state of health as a value from 0..100.
+BatteryCartridge;WorkingMode;;no;OptionList;;This variable represents the current working mode of the battery.
+NetworkConfiguration;OcppCsmsUrl;;yes;string;;URL of the CSMS (without the Charging Station Identity)
+NetworkConfiguration;OcppInterface;;yes;OptionList;;OptionList of values of OcppInterfaceEnumType.
+NetworkConfiguration;OcppTransport;;yes;OptionList;;"OptionList of values of OCPPTransportEnumType. Is always ""JSON""."
+NetworkConfiguration;OcppVersion;;yes;OptionList;;OptionList of values of OcppVersionEnumType. This field is ignored.
+NetworkConfiguration;MessageTimeout;;yes;integer;;Duration in seconds before a message send by the Charging Station via this network connection times out.
+NetworkConfiguration;SecurityProfile;;yes;integer;;Security profile level.
+NetworkConfiguration;Identity;;no;string;;Required if SecurityCtrlr/Identity is ReadWrite
+NetworkConfiguration;BasicAuthPassword;;yes;string;;Writing to this variable only sets the password for the \93instance\94 configurationSlot of Component NetworkConfiguration.
+NetworkConfiguration;CsmsRootCertificateHashAlgorithm;;no;string;;References a specific CSMS Root Certificate which has to be contained in the chain.
+NetworkConfiguration;CsmsRootCertificateIssuerKeyHash;;no;string;;References a specific CSMS Root Certificate which has to be contained in the chain.
+NetworkConfiguration;CsmsRootCertificateIssuerNameHash;;no;string;;References a specific CSMS Root Certificate which has to be contained in the chain.
+NetworkConfiguration;CsmsRootCertificateSerialNumber;;no;string;;References a specific CSMS Root Certificate which has to be contained in the chain.
+NetworkConfiguration;VpnEnabled;;yes;boolean;;True: VPN is configured.
+NetworkConfiguration;VpnType;;no;string;;Value from VPNEnumType
+NetworkConfiguration;VpnServer;;no;string;;VPN server address
+NetworkConfiguration;VpnUser;;no;string;;VPN user name
+NetworkConfiguration;VpnGroup;;no;string;;VPN group name
+NetworkConfiguration;VpnPassword;;no;string;;VPN password
+NetworkConfiguration;VpnKey;;no;string;;VPN shared secret
+NetworkConfiguration;ApnEnabled;;yes;boolean;;True: APN is configured.
+NetworkConfiguration;Apn;;no;string;;Access Point Name as URL
+NetworkConfiguration;ApnUserName;;no;string;;APN user name
+NetworkConfiguration;ApnPassword;;no;string;;APN password
+NetworkConfiguration;SimPin;;no;string;;SIM card PIN code
+NetworkConfiguration;PreferredNetwork;;no;string;;Preferred network as concatenation of MCC and MNC
+NetworkConfiguration;UseOnlyPreferredNetwork;;no;boolean;;When true use only the preferred network
+NetworkConfiguration;ApnAuthentication;;no;string;;Value from APNAuthenticationEnumType
+PaymentCtrlr;Enabled;;yes;boolean;;Payment terminal support is enabled.
+PaymentCtrlr;Problem;;yes;boolean;;There's a problem with the payment terminal.
+PaymentCtrlr;AuthorizeDirectPayment;;yes;boolean;;If true, an AuthorizeRequest must be sent to CSMS to approve the direct payment.
+PaymentCtrlr;AuthorizationAmount;;yes;decimal;;Amount used for the pre-authorization.
+PaymentCtrlr;IncrementalAuthorizationAmount;;no;decimal;;If value is 0, then incremental authorization is not allowed. Variable will be absent if Charging Station or payment terminal do not support incremental authorization.
+PaymentCtrlr;IncrementalAuthorizationThreshold;;no;decimal;;If costs exceed current authorization amount minus IncrementalAuthorizationThreshold then the authorization needs to be increased.
+PaymentCtrlr;PaymentDetails;;yes;MemberList;;The _valuesList_ of PaymentDetails contains the information that the payment terminal is able to provide. The Actual value of PaymentDetails determines which of these details shall be provided in the idToken.additionInfo field.
+PaymentCtrlr;SettlementByCSMS;;yes;boolean;;When true, CSMS will take care of settlement
+PaymentCtrlr;ReceiptServerUrl;;yes;string;;URL to the receipt server, where an EV driver can find the receipt afterwards.
+PaymentCtrlr;ReceiptByCSMS;;yes;boolean;;When true, CSMS will provide a URL to receipt, else it is provided by payment terminal.
+PaymentCtrlr;Merchant;Id;yes;string;;Merchant ID to be added to a PSP/locally generated receipt.
+PaymentCtrlr;Merchant;TaxId;yes;string;;Tax ID of the merchant to be added to a PSP/locally generated receipt.
+PaymentCtrlr;Merchant;Name;yes;string;;Name of the merchant to be added to a PSP/locally generated receipt.
+PaymentCtrlr;Merchant;Address;yes;string;;Address of the merchant to be added to a PSP/locally generated receipt.
+PaymentCtrlr;Merchant;City;yes;string;;City of the merchant to be added to a PSP/locally generated receipt.
+PaymentCtrlr;TerminalID;;yes;string;;Terminal ID of the payment terminal.
+PaymentCtrlr;PaymentServiceProvider;;yes;string;;The payment service provider that the terminal is using. Typically read-only.
+PaymentCtrlr;VendorName;;yes;string;;Manufacturer of the payment terminal.
+PaymentCtrlr;Model;;yes;string;;Model of the payment terminal.
+PaymentCtrlr;SerialNumber;;yes;string;;Payment terminal serial number.
+PaymentCtrlr;FirmwareVersion;;yes;string;;Payment terminal firmware version.
+PaymentCtrlr;IMSI;;yes;string;;IMSI of the payment terminals SIM card.
+PaymentCtrlr;ICCID;;yes;string;;ICCID of the payment terminals SIM card.
+PaymentCtrlr;Connected;;yes;boolean;;Boolean to indicate whether the payment terminal is connected to its payment service provider.
+WebPaymentsCtrlr;URLTemplate;;yes;string;;URL template
+WebPaymentsCtrlr;URLParameters;;no;MemberList;;"List of supported URL parameters, valuesList: ""maxtime"", ""maxenergy"", ""maxcost"". When absent, none of these are supported."
+WebPaymentsCtrlr;TOTPVersion;;yes;string;;"Version of TOTP algorithm. valuesList: list of supported TOTP versions, e.g. ""v1"""
+WebPaymentsCtrlr;ChargingStationId;;no;string;;Charging station Id to use in URL. When absent will default to Charging Station identity, as defined in SecurityCtrlr.Identity.
+WebPaymentsCtrlr;ValidityTime;;yes;integer;s;Time in seconds to show QR, e.g. 30
+WebPaymentsCtrlr;SharedSecret;;yes;string;;<random text> set to a random value on first boot
+WebPaymentsCtrlr;Length;;yes;integer;;Length of TOTP, e.g. 8
+WebPaymentsCtrlr;QRCodeQuality;;no;OptionList;;Low, Medium, Quartile, High
--- /dev/null
+Value;Description
+Central;A centrally, in the CSMS (or other server) generated id (for example used for a remotely started transaction that is activated by SMS). No format defined, might be a UUID.
+DirectPayment;IdToken from a payment terminal that authorized a payment card. Usually a reference id from payment service provider.
+eMAID;Electro-mobility account id as defined in ISO 15118
+EVCCID;EVCCID of EV. For ISO 15118-2 this is the MAC address. For ISO 15118-20 this is an identifier up to 255 characters.
+ISO14443;ISO 14443 UID of RFID card. It is represented as an array of 4 or 7 bytes in hexadecimal representation.
+ISO15693;ISO 15693 UID of RFID card. It is represented as an array of 8 bytes in hexadecimal representation.
+KeyCode;A private key-code to authorize a charging transaction. For example: Pin-code.
+Local;A locally generated id (e.g. internal id created by the Charging Station). Needs no checking by CSMS. No format defined, might be a UUID
+MacAddress;MacAddress of the EVCC (Electric Vehicle Communication Controller) that is connected to the EVSE. Used when MAC address is used for authorization (Autocharge).
+NoAuthorization;Transaction is started and no authorization possible. Charging Station only has a start button or mechanical key etc. IdToken field SHALL be left empty.
+VIN;Vehicle Identification Number of EV.
\ No newline at end of file
--- /dev/null
+PaymentBrand;Description
+AMEX;
+ApplePay;
+Bancontact;
+BankAxept;
+Carnet;
+CartesBancaires;
+Dankort;
+Diners;
+Discover;
+EftposAustralia;
+Elo;
+Girocard;
+GooglePay;
+Hipercard;
+Interac;
+JCB;
+Maestro;
+Mastercard;
+SamsungPay;
+UnionPay;
+VPay;
+Visa;
\ No newline at end of file
--- /dev/null
+PaymentRecognition;Description
+CC;Credit card
+Debit;Debit card
+Alipay;
+ApplePay;
+GooglePay;
+GrabPay;
+PayPal;
+SamsungPay;
+WeChatPay;
\ No newline at end of file
--- /dev/null
+Group;Reason code;Description;Typically used for
+Charging Profiles;;;
+;DuplicateProfile;A charging profile with same _stackLevel - chargingProfilePurpose_ combination already exists on the Charging Station and has an overlapping validity period.;SetChargingProfile
+;InvalidProfile;Provided _chargingProfile_ contains invalid elements.;SetChargingProfile, RequestStartTransaction
+;InvalidProfileId;Provided _chargingProfile_ has an id that is within an invalid range.;SetChargingProfile, RequestStartTransaction
+;InvalidSchedule;Provided _chargingSchedule_ contains invalid elements.;SetChargingProfile, RequestStartTransaction
+;InvalidStackLevel;Provided value for _stackLevel_ is invalid.;SetChargingProfile
+;NoFreqWattCurve;A frequency-watt curve is missing in a charging schedule period with operation mode = LocalFrequency.;SetChargingProfile
+;NoPhaseForDC;Phase selection for a DC EVSE is not supported;SetChargingProfile
+;NoSignalWattCurve;A signal-watt curve is missing in a charging schedule period when an AFRRSignalRequest is received.;AFRRSignal
+;RateLimitExceeded;A charging profile of the same purpose is submitted too frequently;SetChargingProfile
+;UnsupportedKind;The requested charging profile kind is not supported;SetChargingProfile
+;UnsupportedPurpose;The requested charging profile purpose is not supported;SetChargingProfile
+;UnsupportedRateUnit;A _chargingRateUnit_ is provided that is not supported.;SetChargingProfile
+Charging Station;;;
+;CSNotAccepted;BootNotification of Charging Station has not (yet) been accepted by CSMS.;RequestStartTransaction, RequestStopTransaction
+;FixedCable;The connector has its own fixed cable that cannot be unlocked.;UnlockConnector
+;NoCable;No cable is connected at this time.;UnlockConnector
+;UnknownConnectorId;Connector Id is not known on EVSE;ChangeAvailability, UnlockConnector
+;UnknownConnectorType;Connector type is not known on EVSE;ReserveNow
+;UnknownEvse;EVSE is not known on Charging Stations;ChangeAvailability, ReserveNow, RequestStartTransaction
+Swap Station;;;
+;BatterySoHLow;Battery State of Health is too low;BatterySwap
+;BatterySoC;Battery State of Charge has unacceptable value;BatterySwap
+;BatteryDamaged;Battery is damaged;BatterySwap
+;BatteryUnknown;Battery has unknown serial number;BatterySwap
+;BatteryType;Battery type not accepted;BatterySwap
+;NoBatteryAvailable;No battery available for swapping;BatterySwap, RequestBatterySwap
+Miscellaneous;;;
+;DuplicateRequestId;A _requestId_ is provided, that has already been used for this type of request.;UpdateFirmware, PublishFirmware and requests for reports.
+;InvalidMessageSeq;Message should not be sent at this moment in current scenario.;(generic), SetChargingProfile with ISO15118
+;MissingDevModelInfo;Information needed for operation is missing from Device Model;(generic)
+;NoError;No error has occurred, but some extra information is in _additionalInfo_ .;(generic)
+;NotFound;No object(s) found that match a provided ID or criteria.;ClearVariableMonitoring, CustomerInformation, GetChargingProfiles, GetDisplayMessages, GetInstalledCertificateIds, GetReport
+;Unspecified;No reason is specified, but some extra information is in _additionalInfo_;(generic)
+;UnsupportedRequest;This request is not supported.;(generic)
+Operations and Permissions;;;
+;FwUpdateInProgress;Operation is not possible, because a firmware update is in progress.;Reset
+;NotEnabled;Feature is not enabled.;ClearCache
+;ReadOnly;Targeted variable is read-only and cannot be set.;SetVariables
+;WriteOnly;Targeted variable is write-only and cannot be read.;GetVariables
+Security;;;
+;InvalidCSR;Provided CSR is invalid;SignCertificate
+;InvalidCertificate;Provided certificate is invalid.;CertificateSigned, InstallCertificate
+;InvalidURL;Provided URL is invalid.;UpdateFirmware, PublishFirmware
+;RedirectNotAllowed;HTTP Redirection is not allowed;LogStatusNotification
+System Errors;;;
+;InternalError;Operation cannot be completed due to an internal error.;(generic)
+;OutOfMemory;Operation not possible, because system does not have enough memory.;(generic)
+;OutOfStorage;Operation not possible, because system does not have enough storage.;(generic)
+Transactions;;;
+;InvalidIdToken;Provided _idToken_ is not valid.;RequestStartTransaction
+;TxInProgress;A transaction is in progress.;ChangeAvailability, Reset, RequestStartTransaction
+;TxNotFound;There is no such transaction.;RequestStopTransaction, SetChargingProfile, GetVehicleCertificate
+;TxStarted;A transaction had already started (e.g. due to cable being plugged in).;RequestStartTransaction
+Values and Ranges;;;
+;InvalidValue;An invalid value has been provided.;(generic)
+;MissingParam;A parameter that is required for the request is missing.;(generic)
+;TooLargeElement;Provided element is too large to handle.;CertificateSigned, InstallCertificate
+;TooManyElements;Too many elements have been provided.;SetChargingProfile, SetVariables, SendLocalList
+;UnsupportedParam;A parameter was provided that is not supported.;(generic)
+;ValueOutOfRange;Provided value is out of range.;SetVariables, SetVariableMonitoring
+;ValuePositiveOnly;Provided value is not greater than zero.;(generic)
+;ValueTooHigh;Provided value is too high.;(generic)
+;ValueTooLow;Provided value is too low.;(generic)
+;ValueZeroNotAllowed;Provided value cannot be zero.;(generic)
\ No newline at end of file
--- /dev/null
+Security Event;Description;Critical
+FirmwareUpdated;The Charging Station firmware is updated;Yes
+FailedToAuthenticateAtCsms;The authentication credentials provided by the Charging Station were rejected by the CSMS;No
+CsmsFailedToAuthenticate;The authentication credentials provided by the CSMS were rejected by the Charging Station;No
+SettingSystemTime;The system time on the Charging Station was changed more than `ClockCtrlr.TimeAdjustmentReportingThreshold` seconds;Yes
+StartupOfTheDevice;The Charging Station has booted;Yes
+ResetOrReboot;The Charging Station was rebooted or reset;Yes
+SecurityLogWasCleared;The security log was cleared;Yes
+ReconfigurationOfSecurityParameters;Security parameters, such as keys or the security profile used, were changed;No
+MemoryExhaustion;The Flash or RAM memory of the Charging Station is getting full;Yes
+InvalidMessages;The Charging Station has received messages that are not valid OCPP messages, if signed messages, signage invalid/incorrect;No
+AttemptedReplayAttacks;The Charging Station has received a replayed message (other than the CSMS trying to resend a message because it there was for example a network problem);No
+TamperDetectionActivated;The physical tamper detection sensor was triggered;Yes
+InvalidFirmwareSignature;The firmware signature is not valid;Yes
+InvalidFirmwareSigningCertificate;The certificate used to verify the firmware signature is not valid;Yes
+InvalidCsmsCertificate;The certificate that the CSMS uses was not valid or could not be verified;Yes
+InvalidChargingStationCertificate;The certificate sent to the Charging Station using the CertificateSignedRequest message is not a valid certificate;Yes
+DiscardedRenewedClientCertificate;The Charging Station discarded the renewed client certificate, because it was unable to successfully establish a connection using it.;Yes
+InvalidTLSVersion;The TLS version used by the CSMS is lower than 1.2 and is not allowed by the security specification;Yes
+InvalidTLSCipherSuite;The CSMS did only allow connections using TLS cipher suites that are not allowed by the security specification;Yes
+MaintenanceLoginAccepted;Successful login to the local maintenance interface. It is recommended to include information like the user identification and the origin of the login attempt, which can be an ip-address or a touch screen for example, to the techInfo field. For this the following format is strongly recommended: '{\'user\': \'...\', \'origin\': \'...\'}';Yes
+MaintenanceLoginFailed;Failed login attempt to the local maintenance interface. It is recommended to include information like the user identification and the origin of the login attempt, which can be an ip-address or a touch screen for example, to the techInfo field. For this the following format is strongly recommended: '{\'user\': \'...\', \'origin\': \'...\'}';Yes
--- /dev/null
+SigningMethod;Algorithm;Curve;Key Length;Hash Algorithm
+ECDSA-secp192k1-SHA256;ECDSA;secp192k1;192 bits;SHA-256
+ECDSA-secp256k1-SHA256;ECDSA;secp256k1;256 bits;SHA-256
+ECDSA-secp192r1-SHA256;ECDSA;secp192r1;192 bits;SHA-256
+ECDSA-secp256r1-SHA256;ECDSA;secp256r1;256 bits;SHA-256
+ECDSA-brainpool256r1-SHA256;ECDSA;brainpool256r1;256 bits;SHA-256
+ECDSA-secp384r1-SHA256;ECDSA;secp384r1;384 bits;SHA-256
+ECDSA-brainpool384r1-SHA256;ECDSA;brainpool384r1;384 bits;SHA-256
--- /dev/null
+Value;Description
+A;Amperes (current)
+ASU;Arbitrary Strength Unit (Signal Strength)
+B;Bytes
+Celsius;Degrees (temperature)
+dB;Decibel (for example Signal Strength)
+dBm;Power relative to 1mW (^10^log(P/1mW))
+Deg;Degrees (angle/rotation)
+Fahrenheit;Degrees (temperature)
+Hz;Hertz (frequency)
+mHz;milliHertz (frequency)
+K;Degrees Kelvin (temperature)
+lx;Lux (Light Intensity)
+m;Meter (length)
+ms2;m/s^2^ (Acceleration)
+N;Newtons (Force)
+Ohm;Ohm (Impedance)
+kPa;kiloPascal (Pressure)
+Percent;Percentage
+RH;Relative Humidity%
+RPM;Revolutions per Minute
+s;Seconds (Time)
+V;Voltage (DC or r.m.s. AC)
+VA;Volt-Ampere (apparent power)
+kVA;kiloVolt-Ampere (apparent power)
+VAh;Volt-Ampere-hours (apparent energy)
+kVAh;kiloVolt-Ampere-hours (apparent energy)
+var;vars (reactive power)
+kvar;kilovars (reactive power)
+varh;var-hours (reactive energy)
+kvarh;kilovar-hours (reactive energy)
+W;Watts (power)
+kW;kilowatts (power)
+Wh;Watt-hours (energy). Default
+kWh;kilowatt-hours (energy)
--- /dev/null
+Name ; DataType ; Unit ; Description
+ACCurrent;decimal;A ; RMS AC Current (in amperes). For 3-phase circuits, each phase (and optional neutral) is represented by a Variable instance equal to a value of the PhaseEnumType (e.g. L1,N). Unkeyed values reported for a Component declared to be multi-phase are assumed to be an average of all per-phase readings and written values are common per-phase settings. Example(s): ChargingStation: Total AC current consumption (all EVSE’s, ancillaries), EVSE: Total current consumed by EVSE: includes losses (AC->DC) and EVSE specific ancillaries (e.g. fans), ElectricalFeed: Inflow AC current on feed
+ACPhaseSwitchingSupported;boolean;;If defined and true, this EVSE supports the selection of which phase to use for 1 phase AC charging.
+ACVoltage;decimal;V; RMS AC Voltage (in volts). For 3-phase circuits, each phase (and optional neutral) is represented by a Variable instance equal to a value of the PhaseEnumType (e.g. L1,N). Unkeyed values reported for a Component declared to be multi-phase are assumed to be an average ofall per-phase readings and written values are common per-phase settings. Example(s): ElectricalFeed: Input Voltage
+Active;boolean; ; Component is in its non-resting / active state: e.g: On, Engaged, Locked. Some Components may have secondary functions that have corresponding Active Variables with an explicit Variable instance., Note: Monitoring of changes in the Active state of any Component can be specified by setting Delta monitoring on the boolean value with a delta values of 1. Setting/clearing an Active Variable activates/stops the associated functionality, where remotely controllable. Only components that are Available and Enabled can be in the Active state.
+ActiveMonitoringBase;OptionList;;Shows the currently used MonitoringBase.
+ActiveMonitoringLevel;integer;;Shows the currently use MonitoringLevel.
+ActiveNetworkProfile;boolean;;Indicates the configuration profile the station uses to connect to the network.
+ActiveTransactionId;string;;Active transaction on charging station or EVSE.
+AdditionalInfoItemsPerMessage;integer;;Maximum number of _additionalInfo_ items that can be sent in one message.
+AdditionalRootCertificateCheck;boolean;;When set to true, only one certificate (plus a temporarily fallback certificate) of certificateType CSMSRootCertificate is allowed to be installed at a time.
+AllowEnergyTransferResumption;boolean;;This variable defines whether energy transfer is allowed to be resumed when the transaction is resumed after a reset or power outage.
+AllowNewSessionsPendingFirmwareUpdate;boolean;;Indicates whether new sessions can be started on EVSEs, while Charging Station is waiting for all EVSEs to become Available in order to start a pending firmware update.
+AllowReset ;boolean ; ; Component can be reset. Can be used to announce that an EVSE can be reset individually.
+AllowSecurityProfileDowngrade;boolean;;If this variable is implemented and set to _true_, then the Charging Station allows downgrading the security profile from 3 to 2.
+Angle;decimal; Deg ; Angle(s) relative to normal/design idle position. Multiple Variable instance values may be used to indicate angular position in multiple axes (e.g. Left-Right, Forward-Back).
+Attempts;integer ;; Number of attempts (INCLUDING the original attempt) in the last successful or attempted, cycle of operation. Applies typically to self-monitoring motorized electro-mechanical equipment, etc. {Null}: Unknown, 0: Not Attempted/Not allowed, 1: Single attempt/No retries [allowed], 2-N: [up to] N tries [allowed]
+AuthorizeRemoteStart;boolean;;Whether a remote request to start a transaction in the form of RequestStartTransactionRequest message should be authorized beforehand like a local action to start a transaction.
+AvailabilityState;OptionList; ; A value of ConnectorStatusEnumType (See part 2): replicates ConnectorStatus values reported in StatusNotification messages.
+Available;boolean; ; The Component exists and is locally configured/wired for use, but might not be (remotely) Enabled.
+BasicAuthPassword;string;;The basic authentication password is used for HTTP Basic Authentication.
+BytesPerMessage;integer;;Message Size (in bytes) - puts constraint on GetReportRequest, GetMonitoringReportRequest or GetVariableRequest message size.
+CentralContractValidationAllowed;boolean;;If this variable exists and has the value _true_, then Charging Station can provide a contract certificate that it cannot validate, to the CSMS for validation as part of the AuthorizeRequest.
+CertSigningRepeatTimes;integer;;This variable can be used to configure the amount of times the Charging Station SHALL double the previous back-off time, starting with the number of seconds configured at CertSigningWaitMinimum, every time the back-off time expires without having received the CertificateSignedRequest containing the from the CSR generated signed certificate.
+CertSigningWaitMinimum;integer;;This configuration variable defines how long the Charging Station has to wait before generating another CSR, in the case the CSMS accepts the SignCertificateRequest, but never returns the signed certificate.
+Certificate;string ; ;Digital Certificate (in Base64 encoding)
+CertificateEntries;integer;;Amount of Certificates currently installed on the Charging Station.
+CertificateStatusSource;string;;When present, this variable tells CSMS whether Charging Station uses OCSP or CRL to check for revoked certificates.
+ChargeProtocol;string; ;The Charging Control Protocol applicable to a Connector. CHAdeMO: CHAdeMO protocol, ISO15118: ISO15118 V2G protocol (wired or wireless) as used with CCS, CPPWM: IEC61851-1 / SAE J1772 protocol (ELV DC & PWM signalling via Control Pilot wire), Uncontrolled: No charging power management applies (e.g. Schuko socket), Undetermined: Yet to be determined (e.g. before plugged in), Unknown: Not determinable, NOTE: ChargeProtocol is distinct from and orthogonal to connectorType.
+ChargingCompleteBulk;boolean;;Charging up to StateOfChargeBulk has completed.
+ChargingCompleteFull;boolean;;Charging up to StateOfCharge.maxSet has completed.
+ChargingProfilePersistence;boolean;;If an instance of this variable is true, then charging profiles with the _chargingProfilePurpose_ mentioned in the *variableInstance* are persistent, i.e. they are stored persistently and will still exist after a reboot.
+ChargingState;OptionList;;This variable reports the current transaction charging state for an EVSE.
+ChargingTime;decimal;s ; Time from earliest to latest substantive energy transfer
+Color;string ; ; Standard 24 bit hexadecimal RGB values. Reg Green Blue color intensity, expressed as standard 24 bit hexadecimal RGB values: 3 00-FF (0-255), in order RRGGBB). E.g. 000000: Black, FF0000: Red, 00FF00: Green, 0000FF: Blue, FFFF00:Yellow, FFFFFF: White, 008000: Medium intensity green.
+CommunicationParent;string;;Points to a communication parent component (data flow source), to allow rendering the communication hierarchy in a UI.
+Complete;boolean; ; Component’s operation cycle has completed. Used only in event notifications, where it is always true.
+ConditionsSupported;boolean;;If set to true the Charging Station supports tariffs with conditions.
+ConfigurationValueSize;integer;;This Configuration Variable can be used to limit the following fields: SetVariableData.attributeValue and VariableCharacteristics.valuesList.
+ConnectedTime;decimal;s ; Time since logical connection established
+ConnectorType;OptionList ; ; A value of ConnectorStringEnumType (See Appendix 7). Specific type of connector, including sub-variant information. Note: Distinct and orthogonal to Charging Protocol, Power Type, Phases.
+ContractCertificateInstallationEnabled;boolean;;If this variable is _true_, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV
+ContractValidationOffline;boolean;;If this variable is _true_, then Charging Station will try to validate a contract certificate when it is offline.
+Count;integer; ; General purpose integer count variable for Component state reporting
+CountryName;string;;The countryName of the SECC in the ISO 3166-1 format.
+Currency;string;;Currency in a ISO 4217 formatted currency code.
+CurrentImbalance;decimal;Percent ;Percentage current imbalance in an AC three phase supply.
+CustomImplementationEnabled;boolean;;This standard configuration variable is used to enable/disable the custom implementation named in the *variableInstance*.
+CustomTriggers;MemberList;;This variable defines the names of custom triggers that Charging Station supports in a _customTrigger_ field of TriggerMessageRequest.
+DCCurrent;decimal;A ; DC Current (in amperes). May be an instantaneous measurement, or a period average, depending on context/equipment.
+DCInputPhaseControl;boolean;;When DCInputPhaseControl is true, then the values of _numberPhases_ and _PhaseToUse_ in a ChargingSchedulePeriodType will select the input phases from the grid to be used by the DC EVSE.
+DCVoltage;decimal;V ; DC Voltage (volts). May be an instantaneous measurement, or a period average, depending on context/equipment.
+DataText ; string; ; Text associated with a Component, e.g. a Display.
+DateTime;dateTime;;Point in time value, in [RFC3339] datetime format. Time zone optional.
+DepartureTime;dateTime;;Time in [RFC3339] datetime format, when an EV intends to leave the charging station.
+DisablePostAuthorize;boolean;;When set to _true_ this variable disables the behavior to request authorization for an
+DisableRemoteAuthorization;boolean;;When set to _true_ this instructs the Charging Station to not issue any AuthorizationRequests, but only use Authorization Cache and Local Authorization List to determine validity of idTokens.
+DischargePower;decimal;;The variableCharacteristic _maxLimit_ holds the maximum rated discharge power that this EVSE can provide. The variableCharacteristic _maxSet_ holds the maximum configured discharge power that this EVSE can provide. The _Actual_ value of the instantaneous (real) discharge power is recommended to be supported, but not required. Discharge power is represented by a positive value.
+DisplayMessages;integer;;Maximum number of different messages that can configured in this Charging Station simultaneous, via SetDisplayMessageRequest.
+ECVariant;string; ; Production series variants reflecting internal design changes or sub-component substitutions not affecting external functionality.
+EVConnectionTimeOut;integer;s;Interval from between 'starting' of a transaction until incipient transaction is automatically canceled, due to failure of EV driver to (correctly) insert the charging cable connector(s) into the appropriate socket(s).
+ElectricalParent;string;;Points to a electrical parent component (energy flow source), to allow rendering the electrical hierarchy in a UI.
+Enabled;boolean; ; The Component is Enabled for operation. For Available components that cannot be selectively (remotely) enabled / disabled, this value is always true. Note: Available cannot be false of Enabled is true, so during inventory reporting, Enabled=1 also logically states Available=true
+Energy;decimal;Wh;Energy quantity (in Wh) for reporting/configuring values related to stored energy (i.e. not transferred energy).
+EnergyCapacity;decimal;Wh ;Energy capacity in Wh of an energy storage device.
+EnergyExport;decimal;Wh ; Total energy transferred: e.g. from EV during (ongoing or terminated) charging session (in wH by default)
+EnergyExportRegister;decimal;Wh; Cumulative export kWh register value, such as from a (certified) fiscal energy meter.
+EnergyImport;decimal;Wh ; Total energy transferred.
+EnergyImportRegister;decimal;Wh ; Cumulative export kWh register value, such as from a (certified) fiscal energy meter.
+Entries;integer;;General purpose variable for reporting/managing numbers of entries in repetitive data structures. maxLimit characteristic reports maximum possible entries.
+ExternalConfigChangeDate;DateTime;;Date/time when the configuration was changed externally, i.e. outside of CSMS, for example by a local service action.
+ExternalConstraintsProfileDisallowed;boolean;;Indicates whether a Charging Station allows an external system to submit a `ChargingStationExternalConstraints` charging profile.
+ExternalControlSignalsEnabled;boolean;;Indicates whether a Charging Station is able to respond to external control signals that influence charging. If the variable is true, but CSMS has set <<configkey-external-constraints-profile-disallowed>> = true, then external control signals are only allowed during a charging profile with a _chargingProfilePeriod_ = `ExternalLimits` or `ExternalSetpoint`.
+Fallback;boolean; ; Component is operating in a fallback, or backup mode. In inventory reports, a Value of 1 for the maxLimit characteristic indicates that the component can enter a fallback state (i.e. a fallback mode is present).
+FanSpeed;decimal ;RPM ; Fan Speed (in RPM). A value of 0 represents stopped/stalled. An empty value indicates that fan speed cannot be read.
+FieldLength;integer;;This variable is used to report the length of <field> in <message> when it is larger
+FileTransferProtocols;MemberList;;List of supported file transfer protocols.
+FirmwareVersion;string ;; Version number of firmware.
+Force;decimal;N ; Reports (impact) force/ acceleration values (estimates) in one or more directions, in units of Newtons or “g”. Multiple force readings in different (orthogonal) dimensions may be reported using Variable instance values, such as Down, Right, Forward.
+Formats;MemberList;;List of message formats supported by this Charging Station. Possible values: ASCII, HTML, URI, UTF-8.
+Frequency;decimal;Hz ; Frequency of AC power, signal, or component operation.
+FrequencySchedule;string;;A JSON-formatted string with an array of { _time, freq_ } pairs, in which _time_ is
+FuseRating;decimal;A;Current rating of a fuse/breaker. Variable instances keyed by phase identifier (L1/L2/L3/N).
+HandleFailedTariff;OptionList;;This configuration determines how to act when a driver-specific tariff is received, which cannot be processed.
+HeartbeatInterval;integer;s;Interval of inactivity (no OCPP exchanges) with CSMS after which the Charging Station should send HeartbeatRequest.
+Height;decimal;m ; Height above(+)/below(-) reference level (ground level unless context demands otherwise).
+Humidity;decimal;RH; The relative humidity in %.
+Hysteresis;decimal;Percent;Specifies the width of a 'dead band' (as a percentage of the threshold) around the central value of a threshold setting (e.g. MinSet, MaxSet, monitor thresholds) to avoid repeated triggering when the measured quantity lies close to the threshold and is subject to small variations.
+ICCID; string ; ; ICCID (Integrated Circuit Card IDentifier) of mobile data SIM card.
+IMSI; string ;; IMSI (International Mobile Subscriber Identity) number of mobile data SIM card
+ISO15118EvseId;string;;EVSE ID in string format as used in ISO 15118 and IEC 63119-2
+IdToken;string;;The IdToken used to authorize a charging transaction.
+Identity;string;;The Charging Station identity.
+Impedance;decimal;Ohm ; Impedance: Primary value is real (resistive only) impedance. Where a complex impedance is to be reported, the imaginary part (reactance) must be represented with a separate Variable instance value of 'reactance'. Reactance values are expressed at the (nominal) relevant operating frequency of the Component (e.g. 50/60Hz for mains electricity feed).
+Interval;integer;s ; Minimum Interval (in seconds) between (attempted) operations.
+ItemsPerMessage;integer;;Maximum number of ComponentVariable entries that can be sent in one GetReportRequest or GetMonitoringReportRequest message.
+Label;string;;Label for a component. Specifies a non-unique label to be used in a hierarchy UI rendering, in place of the unique component name and instance
+Language;OptionList;;Default language code, per RFC 5646, of this Charging Station.
+Length ;decimal; m; General Purpose linear distance measure.
+LifeTime;integer;s;Indicates how long it takes until a token expires in the authorization cache since it is last used.
+Light;decimal;lx ; (Ambient) light level. The value is in Lux.
+LimitChangeSignificance;decimal;;If at the Charging Station side a change in the limit in a ChargingProfile is lower than this percentage, the Charging Station MAY skip sending a NotifyChargingLimitRequest or a TransactionEventRequest message to the CSMS.
+LocalAuthorizeOffline;boolean;;Whether the Charging Station, when _Offline_, will start a transaction for locally-authorized identifiers.
+LocalFrequencyUpdateThreshold;integer;mHz;The amount of change in net frequency in *mHz* is needed to trigger a recalculation of the setpoint.
+LocalLoadBalancing;decimal;;Variable with instances to control local load-balancing.
+LocalPreAuthorize;boolean;;Whether the Charging Station, when online, will start a transaction for locally-authorized identifiers without waiting for or requesting an AuthorizeResponse from the CSMS.
+LogicalParent;string;;Points to a logical parent component, to allow rendering a comprehensive overview of the Charging Station components in a UI.
+Manufacturer; string ; ; Component Manufacturer name
+MasterPassGroupId;string;;IdTokens that have this id as groupId belong to the Master Pass Group.
+MaxCertificateChainSize;integer;;This configuration variable can be used to limit the size of the 'certificateChain' field from the CertificateSignedRequest PDU.
+MaxElements;integer;;For TariffCostCtrlr: Specifies the maximum number of _prices_ elements that the Charging Station supports in each _energy_, _chargingTime, _idleTime_ and _fixedFee_ of a TariffType.
+MaxEnergyOnInvalidId;integer;Wh;Maximum amount of energy in Wh delivered when an identifier is deauthorized by the CSMS after start of a transaction.
+MaxExternalConstraintsId;integer;;Defines the highest value that a charging profile id of a `ChargingStationExternalConstraints` profile in the Charging Station can have.
+MaxPeriodicEventStreams;integer;;The maximum number of open periodic event streams that Charging Station supports.
+MaxPriceElements;integer;;For ISO15118Ctrlr: The maximum number of _priceRuleStacks_ and _priceLevelScheduleEntries_ that Charging Station is able to accept in a ChargingScheduleType.
+MaxSoc;integer;;The maximum state of charge that a battery will be charged to.
+Measurands;MemberList;;Measurand(s) to be included in <<metervaluesrequest,MeterValuesRequest>> or <<transactioneventrequest,TransactionEventRequest>>
+Message;string;;Specific stored message for display.
+MessageAttemptInterval;integer;s;How long the Charging Station should wait before resubmitting a TransactionEventRequest message that the CSMS failed to process.
+MessageAttempts;integer;;How often the Charging Station should try to submit a TransactionEventRequest message when the CSMS fails to process it.
+MessageTimeout;integer;s;The purpose of the message timeout is to be able to consider a request message as not sent and continue with other tasks when the message did not arrive due to communication errors or software failure.
+MinimumStatusDuration;integer;s;Minimum duration that a Charging Station or EVSE status is stable before StatusNotificationRequest is sent to the CSMS.
+Mode;string; ; Operating mode string from among valid options (communicated by OptionList, etc. during capability/configuration discovery).
+Model;string ; ; Manufacturer's Model code/number of Component, including suffixes etc. to identify functional, regional or linguistic variation, but NOT engineering change level internal variation not affecting external behaviour, etc.
+NetworkAddress ; string; ; Current network address of a Component.
+NetworkConfigurationPriority;SequenceList;;A comma separated ordered list of the priority of the possible Network Connection Profiles. The list of possible available profile slots for the network configuration profiles SHALL be reported, via the valuesList characteristic of this Variable.
+NetworkProfileConnectionAttempts;integer;;Specifies the number of connection attempts the Charging Station executes before switching to a different profile.
+NextTimeOffsetTransitionDateTime;DateTime;;Date time of the next time offset transition. On this date time, the clock displayed to the EV driver will be given the new offset as configured via `TimeOffsetNextTransition`.
+NonEvseSpecific;boolean;;For ReservationCtrlr: If this configuration variable is present and set to _true_: Charging Station supports reservation where EVSE id is not specified.
+NotificationMaxDelay;integer;s;For ISO15118Ctrlr: The SECC (EVSE) uses the NotificationMaxDelay element in the EVSEStatus to indicate the time in seconds until it expects the EVCC (EV) to react on the action request indicated in EVSENotification.
+NotifyChargingLimitWithSchedules;boolean;;Indicates if the Charging Station should include the externally set charging limit/schedule in the message when it sends a NotifyChargingLimitRequest message.
+NtpServerUri;string;;This contains the address of the NTP server.
+NtpSource;OptionList;;Use the NTP server provided via DHCP, or use the manually configured NTP server.
+OfflineQueuingSeverity;integer;;When set and the Charging Station is _offline_, the Charging Station shall queue any NotifyEventRequest messages triggered by a monitor with a severity number equal to or lower than the severity configured here.
+OfflineTariffFallbackMessage;string;;Message (and/or tariff information) to be shown to an EV Driver when Charging Station is offline.
+OfflineThreshold;integer;s;When the offline period of a Charging Station exceeds the `OfflineThreshold` it is recommended to send a StatusNotificationRequest for all its Connectors when the Charging Station is back online.
+OfflineTxForUnknownIdEnabled;boolean;;If this key exists and is true, the Charging Station supports Unknown Offline Authorization.
+Operated;boolean; ; The Component operated in an instantaneous, transient, or immediately self-resetting pattern. Used only in event notifications, where it is always true.
+OperatingTimes;string; ; Recurring operating times in iCalendar RRULE format.
+OrganizationName;string;;The organizationName of the CSO operating the charging station.
+Overload;boolean; ; Component is in Overload state.
+Percent;decimal;Percent ;Generic dimensionless value reporting/setting value.
+PeriodsPerSchedule;integer;;Maximum number of periods that may be defined per ChargingSchedule.
+PhaseRotation;string;;This variable describes the phase rotation of a Component relative to its parent Component, using a
+Phases3to1;boolean;;If defined and true, this Charging Station supports switching from 3 to 1 phase during a transaction.
+PhysicalParent;string;;Points to a physical parent component (container), to allow rendering an overview of the Charging Station component locations in a UI.
+PnCEnabled;boolean;;If this variable is _true_, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is enabled.
+Policy;OptionList;;Cache Entry Replacement Policy: least recently used, least frequently used, first in first out, other custom mechanism.
+PostChargingTime;decimal;s ; Elapsed time in seconds since last substantive energy transfer
+Power;decimal;W,kW ; Instantaneous (real) Power (measured/calculated, including power factor for AC). Where a component (e.g. AC to DC Power Converter) has multiple power measurements, the default (unkeyed) instance is “input” power.
+Present;boolean; ; Component exists, but might not be locally configured/wired for use, nor (remotely) Enabled.
+Problem;boolean; ; Component itself has a 'Problem' condition that impacts in any significant way on its normal operation. By definition, 'Problem' state includes (logical OR) 'Fault' state. 'Problem' specifically INCLUDES inability to operate that is propagated (up/down/sideways) from any other associated/connected/containing/contained Component.
+ProfileStackLevel;integer;;Maximum acceptable value for _stackLevel_ in a ChargingProfile.
+Protecting;boolean;;Applies to 'sensor' type Components that have an associated protection capability, whereby they can disconnect power (e.g. using the main PowerContactor) if the sensed quantity is outside preset/configured limits. If Protecting is true, the Component is actively preventing/interrupting charging.
+ProtocolAgreed;string;;For ConnectedEV: 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.
+ProtocolSupported;string;;For ISO15118Ctrlr: A string with the following comma-separated items: “<uri>,<major>,<minor>”. <uri> is in the format as used in the SupportedAppProtocolReq message from ISO 15118-2 and ISO 15118-20. This variable has at most 20 instances, one for each supported protocol version.
+ProtocolSupportedByEV;string;;For ConnectedEV: 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.
+PublicKey;string;;Configuration variable that can be used to retrieve the public key for a meter connected to a specific EVSE.
+PublicKeyWithSignedMeterValue;boolean;;This Configuration Variable can be used to configure whether a public key needs to be sent with a signed meter value.
+QueueAllMessages;boolean;;When this variable is set to _true_, the Charging Station will queue all message until they are delivered to the CSMS.
+RateUnit;string;;A list of supported quantities (A, W) for use in a ChargingSchedule.
+RegisterValuesWithoutPhases;boolean;;If this variable reports a value of _true_, then meter values of measurand `Energy.Active.Import.Register` will only report the total energy over all phases without reporting the individual phase values.
+RemainingTimeBulk;integer;s;Number of seconds remaining to charge to bulk state of charge, given by StateOfChargeBulk.
+RemainingTimeFull;integer;s;Number of seconds remaining to charge to 100% state of charge.
+ReportingValueSize;integer;;This Configuration Variable can be used to limit the following fields: GetVariableResult.attributeValue, VariableAttribute.value and EventData.actualValue.
+RequestMeteringReceipt;boolean;;For ISO15118Ctrlr: If this variable is _true_, then Charging Station shall request a metering receipt
+ResetRetries;integer;;Number of times to retry a reset of the Charging Station when a reset was unsuccessful.
+ResumptionTimeout;integer;s;This variable defines the maximum number of seconds that a transaction may be interrupted by a power outage and still be resumed afterwards.
+SampledMeasurands;MemberList;;The set of measurands to be sampled by the DataCollector component.
+SamplingInterval;decimal;s;The sampling interval in *seconds*.
+SeccId;string;;The name of the SECC in the string format as required by ISO 15118.
+SecurityProfile;integer;;This configuration variable is used to report the security profile used by the Charging Station.
+SendDuringIdle;boolean;;For AlignedDataCtrlr: If set to _true_, the Charging Station SHALL only send clock aligned meter values when there is no transaction ongoing.
+SerialNumber;string ;; Serial number of Component.
+ServiceRenegotiationSupport;boolean;;For ISO15118Ctrlr: If set to 'True' the SECC (EVSE) is capable of ServiceRenegotiation.
+SetpointPriority;OptionList;;Defines which _setpoint_ shall be used when a `ChargingStationExternalConstraints` profile
+SignReadings;boolean;;If set to _true_, the Charging Station SHALL include signed meter values in the TransactionEventRequest(Ended).
+SignStartedReadings;boolean;;If set to _true_, the Charging Station SHALL include signed meter values for _context_ = `Transaction.Begin` in the _metervalues_ field in the TransactionEventRequest(Started or Updated).
+SignUpdatedReadings;boolean;;If set to _true_, the Charging Station SHALL include signed meter values in the _metervalues_ field in the TransactionEventRequest(Updated).
+SignalStrength;decimal;dBm ; (Radio/Wired/Optical) data signal strength, in ASU (typically 0-31 or 99 for unknown). Or dbmW (typically -140 to -50).
+SlotStatus;OptionList;;This variable represents the status of the door of the battery slot.
+SoC;integer;Percent;SoC of the component BatteryCartridge which refers to the battery that is inserted at the EVSE.
+SoH;integer;Percent;SoH of the component BatteryCartridge which refers to the battery that is inserted at the EVSE.
+State;string; ; A state code or name identifier string, to allow the internal state of components to be reported and/or controlled
+StateOfCharge;decimal;Percent ; Energy Storage Device (e.g. battery) state of charge, expressed as a percentage of nominal design 0-100% operating range. The value of StateOfCharge.maxSet represents the maximum state of charge for a full battery and is usually at or near 100%.
+StateOfChargeBulk;decimal;Percent; Energy Storage Device (e.g. battery) state of charge up to which fast charging is possible. Above this percentage charging speed will drop significantly.
+StopTxOnEVSideDisconnect;boolean;;When set to _true_, the Charging Station SHALL deauthorize the transaction when the cable is unplugged from the EV.
+StopTxOnInvalidId;boolean;;Whether the Charging Station will deauthorize an ongoing transaction when it receives a non- _Accepted_ authorization status in TransactionEventResponse for this transaction.
+Storage;integer;B; In bytes. Amount of storage occupied. Storage(maxLimit) specifies absolute limit Storage(MaxSet) restricts usage to specified Max, if supported.
+SupplyPhases; integer ; ; Number of alternating current phases connected/available. 1 or 3 for AC, 0 means DC (no alternating phases). Null value indicates that the number of phases (e.g. in use) is unknown.
+SupportedAdditionalPurposes;MemberList;;This configuration variable lists the additional charging profile purposes, that have been introduced in OCPP 2.1, that are supported by the Charging Station.
+SupportedEnergyTransferModes;MemberList;;Lists the energy transfer services that are supported by the Charging Station.
+SupportedFormats;MemberList;;For DisplayMessageCtrlr: List of message formats supported by this Charging Station.
+SupportedIdTokenTypes;MemberList;;The subset of the list of supported IdTokenTypes as defined in Appendix 7.
+SupportedLimits;MemberList;;This variable defines which transaction limits in TransactionLimitType are supported by the Charging Station.
+SupportedOperationModes;MemberList;;Lists the V2X operation modes that are supported by the Charging Station.
+SupportedPriorities;MemberList;;For DisplayMessageCtrlr: List of the priorities supported by this Charging Station.
+SupportedProviders;string;;A comma-separated list of all providers (eMSPs) that are supported on this Charging Station. The providers are listed using country and provider ID from the EMAID, as defined in ISO 15118-20.
+SupportedStates;MemberList;;For DisplayMessageCtrlr: List of the states during which to display a message supported by this Charging Station.
+SupportsDynamicProfiles;boolean;;When this variable has value True, then the Charging Station supports charging profiles of type `Dynamic`.
+SupportsEvseSleep;boolean;;When reported as true the Charging Station supports the _evseSleep_ flag in a ChargingSchedulePeriod, which requests the EVSE electronics to go to sleep during _operationMode_ = 'Idle'.
+SupportsExpiryDateTime;boolean;;For LocalAuthListCtrlr: 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_.
+SupportsLimitAtSoC;boolean;;When this variable has value True, then the Charging Station supports the field _limitAtSoC_ in ChargingSchedul, which will cap the limit or setpoint in the ChargingSchedulePeriodType by the value of _limitAtSoC.limit._
+SupportsMaxOfflineDuration;boolean;;When this variable has value True, then the Charging Station supports the fields _maxOfflineDuration_ and _invalidAfterOfflineDuration_ in ChargingProfile.
+SupportsRandomizedDelay;boolean;;When this variable has value True, then the Charging Station supports the field _randomizedDelay_ in ChargingSchedule, which will delay the start of each charging schedule period by a random number between 0 and _randomizedDelay_.
+SupportsUseLocalTime;boolean;;When this variable has value True, then the Charging Station supports the field _useLocalTime_ in ChargingSchedule.
+Suspending;boolean;;If Suspending is true, the Component can is currently suspending charging.
+Suspension;boolean;;Applies to 'sensor' type Components that have a charging suspension capability, typically for safety or equipment protection reasons. If Suspension is true, the component can suspend charging when the sensed quantity is outside preset/configured limits.
+TargetSoc;integer;Percent;For BatterySwapCtrlr: The state of charge that a battery must have in order to be eligible for swapping.
+TariffFallbackMessage;string;;Message (and/or tariff information) to be shown to an EV Driver when there is no driver specific tariff information available.
+Temperature;decimal;Celsius, Fahrenheit ; Temperature(s) of component (in Celsius, by default). Components may have multiple indexed temperature sensors.
+Time;dateTime; ; Point in time value, in ISO 8601 datetime format. Time zone optional.
+TimeAdjustmentReportingThreshold;integer;s;When the clock time is adjusted forwards or backwards for more then TimeAdjustmentReportingThreshold number of seconds, a SecurityEventNotification( 'SettingSystemTime' ) is sent by the charging station.
+TimeOffset;string;; A Time Offset with respect to Coordinated Universal Time (aka UTC or Greenwich Mean Time) in the form of an [RFC3339] time (zone) offset suffix, including the mandatory “+” or “-“ prefix.
+TimeSource;SequenceList;;Via this variable, the Charging Station provides the CSMS with the option to configure a clock source.
+TimeZone;string;;Configured current local time zone in the format: 'Europe/Oslo', 'Asia/Singapore' etc.
+Timeout;decimal;s; Generic timeout value for Component operation (in seconds).
+Timeout;integer;s;For BatterySwapCtrlr: Timeout in seconds in which a set of batteries must be inserted or removed after successful authorization.
+Token;string ;; String of bytes representing an ID token.
+TokenType; OptionList;; Type of Token. Value is one of IdTokenEnumStringType (See Appendix 7).
+TotalCostFallbackMessage;string;;Message to be shown to an EV Driver when the Charging Station cannot retrieve the cost for a transaction at the end of the transaction.
+Tries ; integer; ; Number of attempts done by a Component.
+Tripped;boolean; ; Single-shot device requires explicit intervention to re-prime/activate to normal.
+TxBeforeAcceptedEnabled;boolean;;With this configuration variable the Charging Station can be configured to allow charging before having received a BootNotificationResponse with status: Accepted.
+TxEndedInterval;integer;s;Interval between sampling of metering (or other) data, intended to be transmitted in the TransactionEventRequest(Ended) message.
+TxEndedMeasurands;MemberList;;Sampled measurands to be included in the _meterValues_ element of TransactionEventRequest(Ended).
+TxStartPoint;MemberList;;Start points for a transaction.
+TxStartedMeasurands;MemberList;;Sampled measurands to be included in the _meterValues_ element of TransactionEventRequest(Started).
+TxStopPoint;MemberList;;Stop points of a transaction.
+TxUpdatedInterval;integer;s;Interval between sampling of metering (or other) data, intended to be transmitted in the TransactionEventRequest(Updated) message.
+TxUpdatedMeasurands;MemberList;;Sampled measurands to be included in the _meterValues_ element of TransactionEventRequest(Updated).
+UnlockOnEVSideDisconnect;boolean;;When set to true, the Charging Station SHALL unlock the cable on the Charging Station side when the cable is unplugged at the EV.
+UpstreamInterval;integer;s;Interval between sampling of metering (or other) data, intended to be transmitted via TransactionEventRequest(Updated) messages for location = `Upstream` only.
+UpstreamMeasurands;MemberList;;Sampled measurands to be included in the _meterValues_ element of every TransactionEventRequest(Updated) for location = `Upstream` only.
+V2GCertificateInstallationEnabled;boolean;;If this variable is _true_, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS
+VehicleCertificate;string;;For ConnectedEV: The PEM encoded X.509 leaf/intermediate/root certificate when present in the vehicle certificate chain.
+VehicleId;string;;For ConnectedEV: EVCCID from ISO 15118 or CHAdeMO.
+VehicleId;string;;ID that EV provides to charging station. Encoded as a hexbinary string. In ISO 15118 the EVCCID is 6 bytes (MAC address), in CHAdeMO the vehicle id can be 24 bytes.
+VersionDate;dateTime;;[RFC3339]
+VersionNumber;string;;Version number of hardware
+VoltageImbalance;decimal;Percent; Percentage voltage imbalance in three phase supply.
+WorkingMode;OptionList;;This variable represents the current working mode of the battery in BatteryCartridge component.
\ No newline at end of file
--- /dev/null
+# OCPP
+
+OCPP 2.1 Edition 1
+
+Errata 2025-09
+
+# Table of Contents
+
+Disclaimer 1
+Scope 2
+Terminology and Conventions 2
+0. Part 0 3
+
+1. Part 1 4
+2. Part 2 5
+ 2.1. Page 65-(2025-09)-B07.FR.15 has been deleted [1007]. 5
+ 2.2. Page 70-(2025-09)-B09.FR.02/04/05-Added optionalreasonCode 5
+ 2.3. Page 71 - (2025-09) - B09.FR.22/26/27/28 - Improved definitions 5
+ 2.4. Page 71 - (2025-09) - B09.FR.31/32 - Improved definition
+ 2.5. Page 71 - (2025-09) - B09.FR.33/34/35 - Added requirements to validate NetworkConfiguration
+ 2.6. Page 74 - (2025-06) - B10.FR.03/04/10 - Migrate to new NetworkConnectionProfile 8
+ 2.7. Page 75 - (2025-06) - B11 - Clarify meaning of Onldle for Reset
+ 2.8. Page 189-(2025-06)-E06.FR.05 for DataSigned as TxStopPoint is invalid 9
+ 2.9. Page 193 - (2025-09) - E07.FR.07 - Improved precondition.. 9
+ 2.10. Page 219 - (2025-06) - E17.FR.01 Clarification of transaction state to store 9
+ 2.11. Page 240 - (2025-06) - F06 Requirement for CSMS to support customTrigger [896] 10
+ 2.12. Page 260 - (2025-06) - H02 - Added missing requirements 10
+ 2.13. Page 290 - (2025-09) - I08.FR.31 is a duplicate requirement number [1042] 11
+ 2.14. Page 297 - (2025-09) - I12.FR.02 fails to mention that chargingPeriods are not sent for running cost updates [1048] . . . 12
+ 2.15. Page 354-(2025-06)-Updated remark of K11 12
+ 2.16. Page 327 - (2025-06) - Updated note of K01.FR.05 13
+ 2.17. Page 327 - (2025-06) - Add cross-references to K01.FR.06 and K01.FR.39 13
+ 2.18. Page 331-(2025-06)-K01.FR.50 requirement is a SHALL 14
+ 2.19. Page 332 - (2025-09) - K01.FR.56 is too strict 14
+
+2.19.1. Page 747-ChargingProfileUpdateRateLimit 15
+2.19.2. ChargingProfileUpdateRateLimit 15
+
+2.20. Page 332 - (2025-06) - CSMS requirements for useLocalTime, PriorityCharging and others [954] 16
+2.21. Page 333 - [2025-09] - K01 New requirement for randomized Delays larger than schedule period [1004] 16
+2.22. Page 336 - (2025-06) - K02 Updated remark of use case about merging profiles 17
+2.23. Page 334 - (2025-09) - Requirement for supported operationMode 17
+2.24. Page 335 - (2025-06) - Requirements for checking operationMode and phases L2/L3 17
+2.25. Page 335 - (2025-09) - K01.FR.126 corrected requirement definition 19
+2.26. Page 376 - (2025-09) - K15 Added rule for composite schedules in case of multiple charging schedules [1002] 19
+
+2.26.1. K15-ISO 15118-2. 20
+2.26.2. K18 - ISO 15118-20 Scheduled Control Mode. 20
+2.26.3. K19 - ISO 15118-20 Dynamic Control Mode 20
+
+2.27. Page 350 - (2025-06) - GetCompositeSchedule and L2/L3 values 20
+2.28. Page 356 - (2025-06) - Updated note of K11.FR.06 with MaxExternalConstraintsId 20
+2.29. Page 376 - (2025-09) - K16 use case description update 21
+
+2.29.1. Page 377 22
+
+2.30. Page 475 - (2025-06) - 001 - Added missing requirements 22
+2.31. Page 370 - (2025-06) - K27 Updated remark of use case 23
+2.32. Page 389 - (2025-06) - K19.FR.04 Minor rephrasing 23
+2.33. Page 395 - (2025-06) - CSMS requirement to support UsePriorityCharging. 23
+2.34. Page 396 - (2025-06) - 5.5 Dynamic Charging Profile [882] 24
+2.35. Page 397 - (2025-06) - K28 missing requirement about duration [882]. 24
+2.36. Page 399 - (2025-09) - K28.FR.10 Precondition not complete 25
+2.37. Page 400 - (2025-06) - K29 missing requirement about duration [882]. 26
+2.38. Page 401 - (2025-06) - K29.FR.04: updated precondition to using dynamic profiles. 26
+2.39. Page 402 - (2025-06) - K29.FR.05: Setpoint missing in precondition 27
+2.40. Page 447 - (2025-09) - N01.FR.12 - Improved definition 27
+2.41. Page 449 - (2025-09) - N02: changed empty to absent. 27
+2.42. Page 450 - (2025-06) - N02.FR.13/23 monitoringCriteria DeltaMonitoring is used for TargetDelta [895] 27
+2.43. Page 720 - (2025-06) - New configuration variable to allow TLS wildcard certificates 28
+2.44. Page 739 - (2025-09) - Error in description of Associated data interval variables [1043] 28
+
+2.44.1. AlignedDataInterval 28
+2.44.2. AlignedDataTxEndInterval 29
+2.44.3. AlignedDataUpstreamInterval 29
+
+2.45. Page 492 - (2025-09) - Text instances of dischargingLimit instead of dischargeLimit 29
+2.46. Page 499 - (2025-06) - Additional V2X generic requirements. 29
+2.47. Page 503 - (2025-06) - Q01.FR.05 Precondition needs to refer to ISO15118-serviceRenegotiationSupport . 30
+2.48. Page 504 - (2025-09) - Q01.FR.02 Enhanced precondition to apply only for V2X 30
+2.49. Page 504 - (2025-09) - Q01.FR.07 Clarified difference Accepted and Processing. 31
+2.50. Page 504 - (2025-09) - Q01.FR.08 Improved precondition 31
+2.51. Page 503 - (2025-06) - Q01.FR.09 Wrong precondition. 31
+2.52. Page 504 - (2025-06) - Q02 Use case text not in line with Q02.FR.03 32
+2.53. Page 513 - (2025-06) - Q05 add requirement about duration [822] 32
+2.54. Page 514 - (2025-06) - Prerequisite in use case Q06 updated 32
+2.55. Page 516 - (2025-06) - Q06.FR.11/12 can be combined [883] 33
+2.56. Page 517 - (2025-06) - Q06 add requirement about duration [822] 33
+2.57. Page 519 - (2025-09) - Q07 Added requirements 33
+2.58. Page 522 - (2025-09) - Q08.FR.02/12 Requirement updates for aFRR 34
+2.59. Page 550 - (2025-09) - R04 extra requirements to SetDERControlRequest [997]. 34
+2.60. Page 551 - (2025-09) - R04 extra requirements to GetDERControlRequest [998] 35
+2.61. Page 551 - (2025-09) - R04 updated requirements to ClearDERControlRequest [999] 35
+2.62. Page 620 - (2025-06) - ChargingSchedulePeriodType limit description update. 37
+2.63. Page 703 - (2025-06) - Controller component PaymentCtrl added to list 37
+2.64. Page 750 - (2025-09) - TariffCostCtrl.Enabled can be ReadOnly [934]. 37
+2.65. Appendix Page 51 - (2025-09) - Added connector type BatterySlot. 38
+
+3. Part 3 39
+4. Part 4 40
+
+4.1. Page 16 - (2025-06) - 5.4 Reconnecting - reset backoff wait timer 40
+4.2. Page 21 - (2025-06) - 6.3 Connection loss - Allow Local Controller to keep connection open 40
+
+# Disclaimer
+
+Copyright © 2010 - 2025 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
+
+<table><tr><td>Version</td><td>Date</td><td>Description</td></tr><tr><td>2025-09</td><td>2025-09-22</td><td>Includes errata for Part 2 and 4 of OCPP 2.1 Edition 1.</td></tr><tr><td>2025-06</td><td>2025-07-08</td><td>Includes errata for Part 2 and 4 of OCPP 2.1 Edition 1.</td></tr></table>
+
+# Scope
+
+This document contains errata on the OCPP 2.1 documentation. These errata have to be read as an addition to the release of OCPP 2.1 Edition 1.
+
+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 2025-09 of the errata. The errata of this version are marked with "(2025-09)" in the section title.
+
+In some cases 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]".
+
+# 0. Part 0
+
+Currently no new errata for OCPP 2.1 Edition 1 part 0.
+
+# 1. Part 1
+
+Currently no new errata for OCPP 2.1 Edition 1 part 1.
+
+# 2. Part 2
+
+# 2.1. Page 65 - (2025-09) - B07.FR.15 has been deleted [1007]
+
+B07.FR.15 was added since 2.1, but it is wrong. It speaks about ReadOnly variables, but this must be WriteOnly. It is also not needed, because in 2.0.1 Errata 2025-02 requirement B07.FR.03 was already updated to exclude WriteOnly variables.
+
+Deleted requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B07.FR.15</td><td>When the Charging Station is sending the requested information via one or more NotifyReportRequest messages to the CSMS</td><td>The Charging Station SHALL omit the value of readily variables</td><td></td></tr></table>
+
+# 2.2. Page 70 - (2025-09) - B09.FR.02/04/05 - Added optional reasonCode
+
+A mention of adding an optional reasonCode when a SetNetworkProfileRequest is rejected, has been added.
+
+Changed requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B09.FR.02</td><td>On receipt of the SetNetworkProfileRequest</td><td>The Charging Station SHALL validate the content. If the content is invalid, the Charging Station SHALL respond by sending a SetNetworkProfileResponse message, with status Rejected and optional statusInforeasonCode = "InvalidNetworkConf"</td><td>Matches B09.FR.34 for NetworkConfiguration.</td></tr><tr><td>B09.FR.04</td><td>The variable AllowSecurityProfileDowngrade is not implemented or implemented and set to false AND the Charging Station receives a SetNetworkProfileRequest AND the NetworkConnectionProfile contains a lower securityProfile than the currently active security profile</td><td>The Charging Station SHALL respond by sending a SetNetworkProfileResponse message, with status Rejected and optional statusInforeasonCode = "NoSecurityDowngrade"</td><td>Matches B09.FR.35 for NetworkConfiguration.</td></tr><tr><td>B09.FR.05</td><td>When the value of configurationSlot in SetNetworkProfileRequest does not match an entry in valuesList of NetworkConfigurationPriority</td><td>The Charging Station SHALL respond by sending a SetNetworkProfileResponse message with status Rejected with optional statusInforeasonCode = "InvalidConfSlot"</td><td></td></tr></table>
+
+# 2.3. Page 71 - (2025-09) - B09.FR.22/26/27/28 - Improved definitions
+
+The original requirements have been rephrased so that they apply to network configurations from SetNetworkProfileRequests as well as instances of NetworkConfiguration.
+
+Changed requirements
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>B09.FR.2 2 (2.1)</td><td>B09.FR.10 AND On receipt of a SetVariablesRequest containing any NetworkConfiguration component variable AND the component instance matches any of the members in the currently configured NetworkConfigurationPriority</td><td>The Charging Station SHALL respond by sending a SetVariablesResponse with the corresponding setVariableResult containing status Rejected</td><td>It is not allowed to update any NetworkConfiguration instance that can potentially be used during a reconnection attempt.</td></tr><tr><td>New</td><td>B09.FR.2 2 (2.1)</td><td>B09.FR.10 AND On receipt of a SetVariablesRequest containing any NetworkConfiguration component variable AND the component instance matches any of the members in the currently configured NetworkConfigurationPriority</td><td>The Charging Station SHALL respond by sending a SetVariableResult with the corresponding setVariableResult with attributeStatus Rejected and attributeStatusInfoReasonCode = "ActiveNetworkConf"</td><td>It is not allowed to update any NetworkConfiguration instance that can potentially be used during a reconnection attempt.</td></tr><tr><td>Old</td><td>B09.FR.2 6 (2.1)</td><td>B09.FR.10 AND On receipt of a SetVariablesRequest containing the variable SecurityCtrl.Identity AND the mutability of this variable is read/write</td><td>The Charging Station SHALL also set the variable of the same name in all NetworkConfiguration component instances to the same value (if valid), including component instances which are contained in the currently configured NetworkConfigurationPriority. This is for backwards compatibility only. CSMS SHOULD set the NetworkConfiguration component variable instead.</td><td></td></tr><tr><td>New</td><td>B09.FR.2 6 (2.1)</td><td>When a SetVariablesRequest changes the variable of SecurityCtrl.Identity</td><td>The Charging Station SHALL clear the Identity from the active NetworkConnectionProfile and NetworkConfiguration (when it is writable)</td><td>The SecurityCtrl.Identity is deprecated, and remains for backwards compatibility only. This assures that the Charging Station will use the value from the SecurityCtrl.Identity if it is set by CSMS (See B09.FR.16).</td></tr><tr><td>Old</td><td>B09.FR.2 7 (2.1)</td><td>B09.FR.10 AND On receipt of a SetVariablesRequest containing the variable SecurityCtrl.BasicAuthPassword d</td><td>The Charging Station SHALL also set the variable of the same name in all NetworkConfiguration component instances to the same value (if valid), including component instances which are contained in the currently configured NetworkConfigurationPriority. This is for backwards compatibility only. CSMS SHOULD set the NetworkConfiguration component variable instead.</td><td></td></tr><tr><td>New</td><td>B09.FR.2 7 (2.1)</td><td>When a SetVariablesRequest changes the variable SecurityCtrl.BasicAuthPassword d</td><td>The Charging Station SHALL clear the BasicAuthPassword from the active NetworkConnectionProfile and NetworkConfiguration (when it is writable)</td><td>The SecurityCtrl.BasicAuthPassword is deprecated, and remains for backwards compatibility only. This assures that the Charging Station will use the value from the SecurityCtrl.BasicAuthPassword d if it is set by CSMS (See B09.FR.16).</td></tr><tr><td>Old</td><td>B09.FR.2 8 (2.1)</td><td>B09.FR.10 AND When Charging Station activates a new network configuration</td><td>Charging Station SHALL ensure that the values of SecurityCtrl.Identity and SecurityCtrl.BasicAuthPassword match the corresponding variables of NetworkConfiguration.Identity[configurationSlot] and NetworkConfiguration.BasicAuthPassword [configurationSlot] for the currently active configurationSlot.</td><td></td></tr><tr><td>New</td><td>B09.FR.2 8 (2.1)</td><td>If the NetworkConnectionProfile or NetworkConfiguration used for the currently active connection includes values for the variables Identity and/or BasicAuthPassword</td><td>The Charging Station SHALL set the values of SecurityCtrl.Identity and/or SecurityCtrl.BasicAuthPassword accordingly.</td><td></td></tr></table>
+
+# 2.4. Page 71 - (2025-09) - B09.FR.31/32 - Improved definition
+
+The original requirements has been rephrased so that it applies to a network configuration from either SetNetworkProfileRequests or from an instance of NetworkConfiguration.
+
+Changed requirements
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>B09.FR.31</td><td>The variableAllowSecurityProfileDowngrade is implemented and set to true AND The currently active 'SecurityProfile' is 3 AND The Charging Station receives a SetNetworkProfileRequest AND the NetworkConnectionProfile contains a securityProfile with a value of 2.</td><td>The Charging Station SHALL respond with SetVariablesResponse(Accepted)</td><td></td></tr><tr><td>New</td><td>B09.FR.31</td><td>The variableAllowSecurityProfileDowngrade is implemented and set to true AND the currently active 'SecurityProfile' is higher than 1 AND the Charging Station receives a SetNetworkProfileRequest with a NetworkConnectionProfile with securityProfile = 1</td><td>The Charging Station SHALL respond with SetNetworkProfileResponse with status Rejected and optional statusInforeasonCode = "NoSecurityDowngrade"</td><td></td></tr><tr><td>Old</td><td>B09.FR.32</td><td>The variableAllowSecurityProfileDowngrade is implemented and set to true AND The currently active 'SecurityProfile' is higher than 1 AND The Charging Station receives a SetNetworkProfileRequest AND the NetworkConnectionProfile contains a securityProfile with a value of 1.</td><td>The Charging Station SHALL respond with SetVariablesResponse(Rejected)</td><td></td></tr><tr><td>New</td><td>B09.FR.32 (2.1)</td><td>The variableAllowSecurityProfileDowngrade is implemented and set to true AND the currently active 'SecurityProfile' is higher than 1 AND the Charging Station receives a SetVariablesRequest for NetworkConfiguration.SecurityProfile with attributeValue = 1.</td><td>The Charging Station SHALL respond with SetVariablesResponse with the corresponding setVariableResult with attributeStatus Rejected and attributeStatusInforeasonCode = "NoSecurityDowngrade"</td><td></td></tr></table>
+
+# 2.5. Page 71 - (2025-09) - B09.FR.33/34/35 - Added requirements to validate NetworkConfiguration
+
+The same validations that are performed when activating a network connection profile from SetNetworkProfileRequest also need to be performed when activating an instance of NetworkConfiguration.
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B09.FR.33(2.1)</td><td>B09.FR.10 ANDOn receipt of a SetVariablesRequest containing the variableNetworkConfigurationPriority ANDthe new value adds configurationslot(s) to the current value</td><td>The Charging Station SHALL validate theNetworkConfiguration component for instancesequal to the added configuration slot(s), and if successful, the Charging Station SHALL respond by sending a SetVariablesResponse message, with status Accepted</td><td></td></tr><tr><td>B09.FR.034(2.1)</td><td>B09.FR.10 ANDOn receipt of a SetVariablesRequest containing the variableNetworkConfigurationPriority ANDthe new value adds configurationslot(s) to the current value</td><td>The Charging Station SHALL validate theNetworkConfiguration component for instancesequal to the added configuration slot(s), and if not successful the Charging Station SHALL respond by sending a SetVariablesResponse message, with the corresponding setVariableResult withattributeStatus Rejected andattributeStatusInforeasonCode = "InvalidNetworkConf"</td><td>The field additionalInfo can be used to providedetails about whichNetworkConfigurationvariable is invalid.Matches B09.FR.02 forSetNetworkProfileRequest.</td></tr><tr><td>B09.FR.35(2.1)</td><td>The variableAllowSecurityProfileDowngrade is notimplemented or set to false ANDThe Charging Station receives aSetVariablesRequest forNetworkConfiguration.SecurityProfilewith an attributeValue that has a lowervalue than the currently active‘SecurityProfile'</td><td>The Charging Station SHALL respond withSetVariablesResponse with the correspondingsetVariableResult with attributeStatus Rejectedand attributeStatusInforeasonCode = "NoSecurityDowngrade"</td><td>Matches B09.FR.04 forSetNetworkProfileRequest.</td></tr></table>
+
+# 2.6. Page 74 - (2025-06) - B10.FR.03/04/10 - Migrate to new NetworkConnectionProfile
+
+Changed requirements
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>B10.FR.03</td><td>B10.FR.04 AND When connecting fails</td><td>The Charging Station SHALL make the number of attempts as configured in NetworkProfileConnectionAttempts per entry of NetworkConfigurationPriority.</td><td></td></tr><tr><td>New</td><td>B10.FR.03</td><td>After a reboot OR When connection to CSMS is lost</td><td>The Charging Station SHALL make the number of attempts as configured in NetworkProfileConnectionAttempts per entry of NetworkConfigurationPriority.</td><td></td></tr><tr><td>Old</td><td>B10.FR.04</td><td>B10.FR.01 OR B09.FR.01 AND After a reboot</td><td>The Charging Station SHALL begin connecting to the first entry of NetworkConfigurationPriority</td><td>Same as A05.FR.05</td></tr><tr><td>New</td><td>B10.FR.04</td><td>(B10.FR.01 OR B09.FR.01) AND After a reboot</td><td>The Charging Station SHALL begin connecting to the first entry of NetworkConfigurationPriority</td><td>Same as A05.FR.05</td></tr></table>
+
+The following requirement is added to make explicit that a BootNotification must be sent, or else Charging Station might connect to a new CSMS without it, in which case CSMS would respond with a CALLERROR(SecurityEvent).
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B10.FR.10 (new)</td><td>B10.FR.03 AND Charging Station successfully connected after having switched to a different NetworkConnectionProfile</td><td>Charging Station SHALL send a BootNotificationRequest to CSMS to reestablish its registration status, even if it has not rebooted since last being accepted by any CSMS.</td><td>Charging Station does not need to check whether the CSMS it connected to, is actually one that it has not connected to before.</td></tr></table>
+
+# 2.7. Page 75 - (2025-06) - B11 - Clarify meaning of Onidle for Reset
+
+The "idle state" is defined in Terminology as: "In both use cases and sequence diagrams, Idle status is referred as the state in which a Charging Station is not performing any use case related tasks. Condition during which the equipment can promptly provide a primary function but is not doing so." This is a broader concept, than having an active transaction. A remark is added to the use case to explain that.
+
+The sentence about persistent states and ResetResponse did not belong in Remarks section.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reset - Without Ongoing Transaction</td></tr><tr><td>...</td><td>...</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>Persistent states: for example, EVSE set to Unavailable SHALL persist.+ [line-through]#The Charging Station responds with ResetResponse.OnIdle refers to the "idle state" of a charging station. This is when the Charging Station is not performing any use case related tasks that might interfere with a reset process. The most obvious case is being involved in an active transaction, but there are other conditions when the Charging Station is not idle, for example, when a firmware update process is ongoing, a log file is uploaded to CSMS, a reservation is pending or a cable is still locked in the Charging Station.</td></tr></table>
+
+# 2.8. Page 189 - (2025-06) - E06.FR.05 for DataSigned as TxStopPoint is invalid
+
+DataSigned cannot be used as a TxStopPoint. This requirement is therefore invalid and confusing when present.
+
+Deleted requirement
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>Delete</td><td>E06.FR.05</td><td>TxStopPoint contains: DataSigned AND Charging Station can no longer retrieve signed meter values.</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr></table>
+
+# 2.9. Page 193 - (2025-09) - E07.FR.07 - Improved precondition
+
+The precondition of E07.FR.07 was written as text, but it is more precise to refer another requirement.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>E07.FR.07</td><td>As part of the normal transaction termination.</td><td>The Charging Station SHALL unlock the cable (if not permanently attached).</td><td></td></tr><tr><td>New</td><td>E07.FR.07</td><td>E07.FR.02</td><td>The Charging Station SHALL unlock the cable (if not permanently attached).</td><td></td></tr></table>
+
+# 2.10. Page 219 - (2025-06) - E17.FR.01 Clarification of transaction state to store
+
+Minor improvement of definition to clarify that state information needed to resume a transaction must be persisted.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>E17.FR.01</td><td>If [configkey-tx-resumption-timeout] > 0</td><td>Charging Station SHALL store transaction state in persistent memory</td><td>This is needed in order to resume transactions after a power loss.</td></tr><tr><td>New</td><td>E17.FR.01</td><td>If [configkey-tx-resumption-timeout] > 0</td><td>Charging Station SHALL store transaction state that is needed to resume transactions in persistent memory</td><td>This includes at least, but is not limited to, the seqNo, idToken, evse and transactionInfo data of all active transactions. This ensures transactions can be restored after a power loss.</td></tr></table>
+
+# 2.11. Page 240 - (2025-06) - F06 Requirement for CSMS to support customTrigger [896]
+
+A requirement for CSMS to support customTriggers was missing.
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F06.FR.20 (2.1)</td><td>If Charging Station reports custom triggers in CustomizationCtrl.CustomTriggers</td><td>CSMS SHALL support sending these custom triggers as a [triggermessagerequest] with requestedMessage = CustomTrigger and customTrigger set to the custom trigger.</td><td></td></tr></table>
+
+# 2.12. Page 260 - (2025-06) - H02 - Added missing requirements
+
+Added missing requirements explicitly specifying behaviour of Charging Station when a reservation is cancelled.
+
+Removed details from scenario description:
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td colspan="3">[...]</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver asks the CSMS to cancel a reservation.
+2. To cancel a reservation, the CSMS sends CancelReservationRequest to the Charging Station.
+3. If the Charging Station has a reservation matching the reservationId in the request PDU, it returns the status Accepted.
+4. If a specific EVSE was reserved for this reservation, the Charging Station sends a NotifyEventRequest with variable "AvailabilityState" set to "Available" for all the Connectors of that EVSE.
+5. The CSMS responds with a NotifyEventResponse to the Charging Station.
+6. The reservation is canceled.</td></tr><tr><td colspan="3">[...]</td></tr></table>
+
+Removed details from sequence diagram
+
+Old:
+
+
+Sequence Diagram: Cancel Reservation
+
+New:
+
+
+Sequence Diagram: Cancel Reservation
+
+New requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>H02.FR.03</td><td>H02.FR.02 ANDIf a specific EVSE was reserved for this reservation</td><td>The Charging Station SHALL allow charging again on this EVSE.</td></tr><tr><td>H02.FR.04</td><td>H02.FR.03</td><td>The Charging Station SHALL send a StatusNotificationRequest with status Available or a NotifyEventRequest with AvailabilityState set to Available to the CSMS for each connector, notifying the CSMS that all the connectors of this EVSE are available again for any EV Driver.</td></tr><tr><td>H02.FR.05</td><td>H02.FR.02 ANDIf no specific EVSE was reserved for this reservation</td><td>The Charging Station SHALL allow charging on all EVSE which were not reserved explicitly.</td></tr><tr><td>H02.FR.06</td><td>H01.FR.05 ANDbefore cancelling the reservation the amount of EVSEs reserved was equal to the amount of reservations</td><td>The Charging Station SHALL send for all connectors of all EVSEs which were not reserved explicitly:- a NotifyEventRequest with component = "Connector", variable = "AvailabilityState", trigger = "Delta", actualValue = "Available", OR - a StatusNotificationRequest with connectorStatus = Available.</td></tr></table>
+
+# 2.13. Page 290 - (2025-09) - I08.FR.31 is a duplicate requirement number [1042]
+
+By mistake the requirement number I08.FR.31 occurs twice in I08. This has been fixed by moving the first I08.FR.31 requirement to become I08.FR.37.
+
+Requirement number changed
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Notes</td></tr><tr><td>I08.FR.31</td><td rowspan="2">I08.FR.30 AND Charging Station does not have a Delta monitor installed on TariffCostCtrlr.Problem</td><td rowspan="2">Charging Station SHALL send a [notifyeventrequest] with trigger = Alerting, eventNotificationType = HardWiredNotification, component = "TariffCostCtrlr", variable = "Problem", actualValue = "true" and techCode optionally set to the applicable reason code from Appendix 5, to notify CSMS that it cannot support the tariff in the response.</td><td rowspan="2">techCode can be, for example, one of "TooManyElements", "OutOfMemory", "InternalError", "UnsupportedParam", etc.</td></tr><tr><td>I08.FR.37</td></tr></table>
+
+# 2.14. Page 297 - (2025-09) - I12.FR.02 fails to mention that chargingPeriods are not sent for running cost updates [1048]
+
+The element chargingPeriods in CostDetailsType is not sent for running cost updates, because that is not needed and adds a lot of data to the message. This is mentioned explicitly in CostDetailsType, but it is not formalized in the requirements.
+
+Changed requirement
+
+<table><tr><td></td><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Notes</td></tr><tr><td>Old</td><td>I12.FR.02</td><td>I12.FR.01 AND TariffCostCtrl.Enabled[RunningCost] = true</td><td>Charging Station SHALL provide a costDetails field of type [cmn_costdetailedtype] in [transactioneventrequest] with eventType = Started and every TariffCostCtrlInterval[Cost] seconds during the transaction for eventType = Updated.</td><td>Providing running cost updates needs to be enabled via TariffCostCtrl.Enabling[RunningCost]. See [configkey-running-cost-enabled] and [configkey-cost-interval].</td></tr><tr><td>New</td><td>I12.FR.02</td><td>I12.FR.01 AND TariffCostCtrl.Enabled[RunningCost] = true</td><td>Charging Station SHALL provide a costDetails field of type [cmn_costdetailedtype] without a chargingPeriods field in [transactioneventrequest] with eventType = Started and every TariffCostCtrlInterval[Cost] seconds during the transaction for eventType = Updated.</td><td>Providing running cost updates needs to be enabled via TariffCostCtrl.Enabling[RunningCost]. See [configkey-running-cost-enabled] and [configkey-cost-interval].</td></tr></table>
+
+# 2.15. Page 354 - (2025-06) - Updated remark of K11
+
+Added sentence to Remarks a new charging profile for an update of external limit can use the same charging profile id.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>...</td><td>...</td><td>...</td></tr><tr><td>8</td><td>Remarks</td><td>[...]If the external limit is represented by an Absolute or RelativeChargingStationExternalConstraints charging profile, then every update of the external limit requires (K11.FR.06) that the existingChargingStationExternalConstraints charging profile is replaced by a new one. This one can use the samechargingProfile.id, however.</td></tr></table>
+
+# 2.16. Page 327 - (2025-06) - Updated note of K01.FR.05
+
+Note suggested that ChargingStationExternalConstraints cannot be replaced at all. Updated note to clarify that a ChargingStationExternalConstraints cannot be replaced by CSMS.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>K01.FR.05</td><td>When a SetChargingProfileRequest with an already known ChargingProfile.id is received AND the existing ChargingProfile does NOT have chargingProfilePurpose = ChargingStationExternalConstraints</td><td>The Charging Station SHALL replace the existing ChargingProfile with the one specified.</td><td>ChargingStationExternalConstraints profile cannot be replaced.</td></tr><tr><td>New</td><td>K01.FR.05</td><td>When a SetChargingProfileRequest with an already known ChargingProfile.id is received AND the existing ChargingProfile does NOT have chargingProfilePurpose = ChargingStationExternalConstraints</td><td>The Charging Station SHALL replace the existing ChargingProfile with the one specified.</td><td>ChargingStationExternalConstraints profile cannot be replaced by CSMS.</td></tr></table>
+
+# 2.17. Page 327 - (2025-06) - Add cross-references to K01.FR.06 and K01.FR.39
+
+Requirement K01.FR.06 and K01.FR.39 are similar, but located far apart in the table. It is convenient to add a cross-reference between both.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>K01.FR.06</td><td>When chargingProfilePurpose is NOT TxProfile</td><td>The CSMS SHALL NOT send a ChargingProfile with a stackLevel - chargingProfilePurpose - evseld combination that already exists in another ChargingProfile (with different id) on the Charging Station and has an overlapping validity period.</td><td>This is to ensure that no two charging profiles with same stack level and purpose can be valid at the same time.</td></tr><tr><td>New</td><td>K01.FR.06</td><td>When chargingProfilePurpose is NOT TxProfile</td><td>The CSMS SHALL NOT send a ChargingProfile with a stackLevel - chargingProfilePurpose - evseld combination that already exists in another ChargingProfile (with different id) on the Charging Station and has an overlapping validity period.</td><td>This is to ensure that no two charging profiles with same stack level and purpose can be valid at the same time.
+(See also K01.FR.39)</td></tr><tr><td>Old</td><td>K01.FR.39</td><td>When chargingProfilePurpose is TxProfile</td><td>The CSMS SHALL NOT send a ChargingProfile with a stackLevel - transactionId combination that already exists in another ChargingProfile (with different id) with purpose TxProfile.</td><td>This is to ensure that no two charging profiles with same stack level and purpose can be valid at the same time.</td></tr><tr><td>New</td><td>K01.FR.39</td><td>When chargingProfilePurpose is TxProfile</td><td>The CSMS SHALL NOT send a ChargingProfile with a stackLevel - transactionId combination that already exists in another ChargingProfile (with different id) with purpose TxProfile.</td><td>This is to ensure that no two charging profiles with same stack level and purpose can be valid at the same time.
+(See also K01.FR.06)</td></tr></table>
+
+# 2.18. Page 331 - (2025-06) - K01.FR.50 requirement is a SHALL
+
+Physics determines how to convert power to current. This cannot be a "should" requirement, but is a SHALL.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>K01.FR.49</td><td>When a SetChargingProfileRequest without a value for numberPhases is received AND the EVSE is of type AC</td><td>The Charging Station SHALL assume numberPhases = 3 as a default value.</td><td></td></tr><tr><td>New</td><td>K01.FR.49</td><td>When a SetChargingProfileRequest without a value for numberPhases is received AND the EVSE is of type AC</td><td>The Charging Station SHALL assume numberPhases = 3 as a default value.</td><td>Regions with a single phase network should always provide numberPhases = 1, otherwise 3 phases will be assumed.</td></tr><tr><td>Old</td><td>K01.FR.50</td><td>When a SetChargingProfileRequest with a chargingRateUnit = W is received AND The ChargingSchedule is used for AC charging</td><td>The Charging Station SHOULD calculate the phase current limit via: Current per phase = Power / (Line Voltage * Number of Phases).</td><td>The "Line Voltage" used in the calculation is not the measured voltage, but the set voltage for the area (for example, 230 or 110 V). The "Number of Phases" is the numberPhases from the ChargingSchedulePeriod. It is usually more convenient to use chargingRateUnit = A for AC charging.</td></tr><tr><td>New</td><td>K01.FR.50</td><td>When a SetChargingProfileRequest with a chargingRateUnit = W is received AND The charging profile is used for AC charging</td><td>The Charging Station SHALL calculate the phase current limit via: Current per phase = limit / (Line Voltage * numberPhases), in which limit and numberPhases are the values from the ChargingSchedulePeriod.</td><td>The "Line Voltage" used in the calculation is not the measured voltage, but the set voltage for the area (for example, 230 or 110 V). The limit and numberPhases are the values from the ChargingSchedulePeriod. When numberPhases is not specified, a value of 3 is assumed (see K01.FR.49). It is usually more convenient to use chargingRateUnit = A for AC charging, since in that case the limit does not change depending on number of phases in use.</td></tr></table>
+
+# 2.19. Page 332 - (2025-09) - K01.FR.56 is too strict
+
+K01.FR.56 attempts to limit the update rate of persistent profiles, but current requirement prohibits setting profiles on different EVSEs in quick succession.
+
+Updated requirement
+
+New requirement
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>K01.FR.56(2.1)</td><td>When Charging Station receives a [setchargingprofilerequest] for a [cmn_chargingprofiletype] with a chargingProfilePurpose that is to be stored persistently AND the previous [setchargingprofilerequest] for this chargingProfilePurpose was less than ChargingProfileUpdateRateLimit seconds ago</td><td>Charging Station MAY respond with [setchargingprofileresponse] with status = Rejected andreasonCode = "RateLimitExceeded"</td><td>See also K01.FR.55 and K01.FR.27. If ChargingProfileUpdateRateLimit does not exist, there is no rate limit.</td></tr><tr><td>New</td><td>K01.FR.56(2.1)</td><td>When Charging Station receives frequent [setchargingprofilerequest] messages at a rate that threatens to wear out its persistent memory, for a [emm_chargingprofiletype] with a chargingProfilePurpose that is to be stored persistently</td><td>Charging Station MAY respond with [setchargingprofileresponse] with status = Rejected andreasonCode = "RateLimitExceeded"</td><td>See K01.FR.55 and K01.FR.27 for which charging profiles are persistent.</td></tr></table>
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K01.FR.57(2.1)</td><td>K01.FR.56</td><td>Charging Station SHOULD report the duration after which a next update will be accepted, in field statusInfo additionlInfo as "<xx> seconds before retry"</td><td><xx> is the number of seconds after which the next [setchargingprofilerequest] is allowed.</td></tr><tr><td>K01.FR.58(2.1)</td><td>K01.FR.56</td><td>CSMS MAY retry the [setchargingprofilerequest] if still applicable</td><td></td></tr><tr><td>K01.FR.59(2.1)</td><td>K01.FR.57</td><td>CSMS IS RECOMMENDED to use at least the number of seconds in statusInfo additionlInfo as a delay before retrying</td><td>This will avoid unnecessary rejections</td></tr></table>
+
+# 2.19.1. Page 747 - ChargingProfileUpdateRateLimit
+
+This variable has now been deprecated.
+
+# 2.19.2. ChargingProfileUpdateRateLimit
+
+Deprecated
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">UpdateRateLimit</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr></table>
+
+<table><tr><td rowspan="2">Description</td><td>This configuration key limits how often a persistent charging profile can be updated. It is the minimum duration in seconds between updates of charging profiles of the same chargingProfilePurpose. A Charging Station may reject SetChargingProfileRequests that occur too frequently, as per K01.FR.56.</td></tr><tr><td>Note: This configuration variable has been deprecated, because a simple variable with number of seconds between updates does not determine when a Charging Station may reject a message or not.</td></tr></table>
+
+# 2.20. Page 332 - (2025-06) - CSMS requirements for useLocalTime, PriorityCharging and others [954]
+
+Requirements have been added for the implicit assumption that CSMS has to support these new features.
+
+New requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td colspan="4">PriorityCharging</td></tr><tr><td>K01.FR.72(2.1)</td><td></td><td>CSMS SHALL support sending a SetChargingProfileRequest with chargingProfilePurpose = PriorityCharging.</td><td></td></tr><tr><td>K01.FR.73(2.1)</td><td></td><td>CSMS SHALL NOT add a duration to a chargingSchedule in a chargingProfile with chargingProfilePurpose = PriorityCharging.</td><td></td></tr><tr><td colspan="4">Use Local Time / Randomized Delay</td></tr><tr><td>K01.FR.96(2.1)</td><td></td><td>CSMS SHALL support sending a SetChargingProfileRequest with a chargingSchedule that contains fields useLocalTime = true and/or randomizedDelay > 0</td><td></td></tr><tr><td colspan="4">Limit Beyond SoC / Offline validity</td></tr><tr><td>K01.FR.104(2.1)</td><td></td><td>CSMS SHALL support sending a SetChargingProfileRequest with a maxOfflineDuration > 0 and invalidAfterOfflineDuration = true or false.</td><td></td></tr><tr><td>K01.FR.105(2.1)</td><td></td><td>CSMS SHALL support sending a SetChargingProfileRequest with a chargingSchedule with a limitAtSoC element.</td><td></td></tr></table>
+
+# 2.21. Page 333 - [2025-09] - K01 New requirement for randomizedDelays larger than schedule period [1004]
+
+Each startPeriod (except the first one) is increased with a random value at start of the transaction. Remember that a delay in the start of the next period, implies an increase in the length of the current period.
+
+A requirement was missing to define how to deal with the situation where a randomizedDelay turns out to be longer than the duration of the chargingSchedulePeriod for which the start is randomized. It is important to remember that all randomized startPeriods are calculated before the charging profile is used (at submission or start of transaction). If a randomization of the startPeriod is longer than the schedule period (i.e. until the randomized start of the next period), then this period is skipped entirely.
+
+This implies that a randomized delay can never become more than the duration between startPeriod(i) and startPeriod(i+1)\_randomized, because at that point the next period is started.
+
+# Example
+
+# Assume a schedule
+
+{start:0,limit:0}, {start:300,limit:1}, {start:600,limit:2}, {start:900,limit:3}
+
+# Random delays create
+
+{start: 0, limit: 0}, {start: 300+753=1053, limit: 1}, {start: 600+123=723, limit: 2}, {start: 900+87=987, limit: 3} In this case the second period will be dropped, because it exceeds start of the third period (723).
+
+<table><tr><td>K01.FR.97
+(2.1)</td><td>K01.FR.93 AND
+startPeriod + <random delay> of
+chargingSchedulePeriod[i] is
+greater/equal than startPeriod +
+<random delay> of
+chargingSchedulePeriod[i+1] or
+greater/equal than chargingSchedule
+.duration</td><td>chargingSchedulePeriod[i] is skipped
+from the randomized charging
+schedule.</td><td>chargingSchedulePeriod[i] is skipped
+because its randomized start would
+take place after the randomized start
+of chargingSchedulePeriod[i+1] or
+after end of charging schedule. This
+is basically means that
+chargingSchedulePeriod[i-1]
+continues until (randomized) start of
+chargingSchedulePeriod[i+1] or until
+charging schedule end if this is the
+last period.</td></tr></table>
+
+# 2.22. Page 336 - (2025-06) - K02 Updated remark of use case about merging profiles
+
+The description of merging profiles in the remark was not complete. It has been updated to refer to the appropriate requirement.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>...</td><td>...</td><td>...</td></tr><tr><td>8</td><td>Remark(s)</td><td>[...]The final schedule constraints that apply to a transaction are determined by merging the profiles with purposes ChargingStationMaxProfile with the profile TxProfile or TxDefaultProfile in case no profile of purpose TxProfile is provided. Zero or more of the following ChargingProfile purposes MAY have been previously received from the CSMS: ChargingStationMaxProfile or TxDefaultProfile, as described in requirement SC.01 in Chapter 4. Smart Charging Signals to a Charging Station from Multiple Actors .[...]</td></tr></table>
+
+# 2.23. Page 334 - (2025-09) - Requirement for supported operationMode
+
+A missing requirement that only supported operationModes are accepted, has been added.
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K01.FR.115 (2.1)</td><td>When Charging Station receives a [setchargingprofilerequest] with a charging profile that contains a [cmn_chargescheduleperi odtype] with a value for operationMode that is not ChargingOnly and not part of the attributeValue of [configkey- v2xsupportedoperationmod es]</td><td>Charging Station SHALL respond with [setchargingprofileresponse] with status = Rejected and statusInfo withreasonCode = "InvalidOperationMode"</td><td></td></tr></table>
+
+# 2.24. Page 335 - (2025-06) - Requirements for checking operationMode and phases L2/L3
+
+The following requirements have been made explicit from the table in paragraph 3.2 Charging Profile purpose.
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td colspan="4">OperationMode</td></tr><tr><td>K01.FR.111(2.1)</td><td>When a charging profile haschargingProfilePurpose =PriorityCharging orChargingStationMaxPrforfile</td><td>The charging profile SHALL only containchargingSchedulePeriodswith operationMode =ChargingOnly or without operationMode.</td><td></td></tr><tr><td>K01.FR.112(2.1)</td><td>When a charging profile haschargingProfilePurpose =ChargingStationExternalLimits</td><td>The charging profile SHALL only containchargingSchedulePeriodswith operationMode =ChargingOnly, ExternalLimits,ExternalSetpoint or without operationMode.</td><td></td></tr><tr><td>K01.FR.113(2.1)</td><td>When a charging profile haschargingProfilePurpose =LocalGeneration</td><td>The charging profile SHALL only containchargingSchedulePeriodswith operationMode =ChargingOnly, ExternalLimits or without operationMode.</td><td></td></tr><tr><td>K01.FR.114(2.1)</td><td>When Charging Stationreceives a[setchargingprofilerequest]with a charging profile thatdoes not obey toK01.FR.111, K01.FR.112,K01.FR.113</td><td>Charging Station SHALL respond with[setchargingprofileresponse] with status =Rejectedand statusInfo withreasonCode = "InvalidOperationMode"</td><td></td></tr></table>
+
+The following requirements have been added to make explicit when \_L2 and \_L3 fields can be used.
+
+New requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td colspan="4">ISO 15118-20 multi-phase support</td></tr><tr><td>K01.FR.140(2.1)</td><td>When determining the composite schedule from multiple charging profiles</td><td>Charging Station SHALL at each point in time use the lowest value of numberPhases for that point in time in all applicable chargingSchedulePeriods.</td><td>For example, if ChargingStationMaxProfile has numberPhases = 1 and TxProfile has numberPhases = 3, then the value 1 is used.</td></tr><tr><td>K01.FR.141(2.1)</td><td>When Charging Station receives a [setchargingprofilerequest] that introduces a conflicting value of phaseToUse with the schedule periods of other applicable charging profiles</td><td>Charging Station SHALL respond with [setchargingprofileresponse] with status = Rejected and a statusInfo withreasonCode = "PhaseConflict".</td><td>For example, if ChargingStationMaxProfile has phaseToUse = 1 and TxProfile is submitted with phaseToUse = 3, then this will be rejected.</td></tr><tr><td>K01.FR.142(2.1)</td><td>When v2xChargingParameters of [notifyevchargingneedsrequest] from Charging Station does not contain maxChargePower_L2 and/or maxChargePower_L3</td><td>CSMS SHALL NOT provide values for limit_L2 and/or limit_L3 fields in a charging profile.</td><td>If EV does not report L2/L3 fields then do not provide separate limits for them.</td></tr><tr><td>K01.FR.143(2.1)</td><td>When CSMS sends a [setchargingprofilerequest] for a chargingProfilePurpose that is not TxProfile</td><td>CSMS SHALL NOT provide values for limit_L2 and limit_L3 fields in chargingSchedulePeriods of the charging profile</td><td>Only a TxProfile is submitted after receiving a NotifyEVChargingNeedsRequest.</td></tr><tr><td>K01.FR.144(2.1)</td><td>(K01.FR.142 OR K01.FR.143) AND Charging Station receives a [setchargingprofilerequest] with values for limit_L2 and/or limit_L3 fields in a charging profile</td><td>Charging Station SHALL respond with [setchargingprofileresponse] with status = Rejected and a statusInfo withreasonCode = "PhaseConflict".</td><td></td></tr><tr><td>K01.FR.145(2.1)</td><td>When CSMS sends a [setchargingprofilerequest] of chargingProfilePurpose = TxProfile</td><td>CSMS SHALL NOT provide values for limit_L2 and/or limit_L3 fields in a chargingSchedulePeriod without providing a value for limit.</td><td>E.g. limit_L2/L3 can only exist if limit is also provided, because in that case limit represents phase L1.</td></tr><tr><td>K01.FR.146(2.1)</td><td>K01.FR.145 AND Charging Station receives a [setchargingprofilerequest] with values for limit_L2 and/or limit_L3 fields in a charging profile, but no value for limit</td><td>Charging Station SHALL respond with [setchargingprofileresponse] with status = Rejected and a statusInfo withreasonCode = "PhaseConflict".</td><td></td></tr><tr><td>K01.FR.147(2.1)</td><td>In the event that an AC ISO 15118-20 session is ongoing and Charging Station falls back to using Mode 3 PWM communication AND charging profiles are active that specify limit_L2 and/or limit_L3</td><td>Charging Station SHALL use the lowest value of limit, limit_L2 and/or limit_L3 as the limit to use for each phase.</td><td>The phrase "limit_L2 and/or limit_L3" is used to cater for both 2-phase and 3-phase situations.</td></tr></table>
+
+# 2.25. Page 335 - (2025-09) - K01.FR.126 corrected requirement definition
+
+K01.FR.126 was not entirely correct, because evseSleep can only occur while in operationMode = Idle.
+
+Changed requirement
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>Old</td><td>K01.FR.126(2.1)</td><td>When Charging Station receives a [setchargingprofilerequest] with evseSleep = true AND [configkey-supports- evsesleep] is false or absent</td><td>Charging Station SHALL respond with [setchargingprofileresponse] with status = Rejected and optionally withreasonCode = "InvalidSchedule".</td><td></td></tr><tr><td>New</td><td>K01.FR.126(2.1)</td><td>When Charging Station receives a [setchargingprofilerequest] with a chargingSchedulePeriod that has evseSleep = true and operationMode != 'Idle' AND [configkey- supports-evsesleep] is false or absent</td><td>Charging Station SHALL respond with [setchargingprofileresponse] with status = Rejected and optionally withreasonCode = "InvalidSchedule".</td><td>A request for EVSE to sleep can only occur during operationMode Idle. See Q10 for evseSleep behavior.</td></tr></table>
+
+# 2.26. Page 376 - (2025-09) - K15 Added rule for composite schedules in case of multiple charging schedules [1002]
+
+In the theoretical situation that 2 TxProfiles are submitted with different stack levels and multiple charging schedules (which can only be the case for an ISO 15118 session) and, because of different durations of these schedules, parts of each of these schedules will be valid at one point or another, then how is the composite schedule calculated? It is not $3 \times 3$ composite schedules (all possible combinations), but only 3 composite schedules, because schedule #1 is always combined with schedule #1, #2 with #2 and #3 with #3. Other chargingProfilePurposes, like ChargingStationMaxProfile need also to be taken into account when calculating the composite schedule.
+
+A new requirement is added to define this behavior.
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K15.FR.22</td><td>When calculating CompositeSchedule(s) to create a SAScheduleList for ISO 15118-2 to send to EV AND multiple ChargingProfileTypes of chargingProfilePurpose = TxProfile with different stackLevels are valid AND some or all these ChargingProfileTypes have more than one chargingSchedule</td><td>Charging Station SHALL create up to three CompositeSchedules as defined in K08.FR.04, by combining the first chargingSchedule with the first chargingSchedule of other stack levels, the second with second (if existing), the third with the third (if existing), based on their order in the ChargingProfileTypes.</td><td>This is about a corner case when multiple TxProfiles with different stack levels and multiple charging schedules have been sent to the Charging Station. (See K18.FR.24)</td></tr></table>
+
+# 2.26.2. K18 - ISO 15118-20 Scheduled Control Mode
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K18.FR.24</td><td>When calculating CompositeSchedule(s) to create ScheduleTupleTypes for ISO 15118-20 to send to EV AND multiple ChargingProfileTypes of chargingProfilePurpose = TxProfile with different stackLevels are valid AND some or all these ChargingProfileTypes have more than one chargingSchedule</td><td>Charging Station SHALL create up to three CompositeSchedules as defined in K08.FR.04, by combining the first chargingSchedule with the first chargingSchedule of other stack levels, the second with the second (if existing), the third with the third (if existing), based on their order in the ChargingProfileTypes.</td><td>This is about a corner case when multiple TxProfiles with different stack levels and multiple charging schedules have been sent to the Charging Station. (See K15.FR.22)</td></tr></table>
+
+# 2.26.3. K19 - ISO 15118-20 Dynamic Control Mode
+
+This issue does not affect the requirements in K19, because in Dynamic Control Mode only a single charging schedule is offered by CSMS.
+
+# 2.27. Page 350 - (2025-06) - GetCompositeSchedule and L2/L3 values
+
+The following clarifies that a composite schedule only needs to report L2/L3 values when they exist in the applicable charging profiles.
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>K08.FR.09 (2.1)</td><td>K08.FR.02 AND a chargingSchedulePeriod in the applicable charging profiles contains limit_L2 and/or limit_L3 values</td><td>Charging Station SHALL report the composite value for limit_L2 and/or limit_L3 values in the resulting chargingSchedulePeriod of the [getcompositescheduleresponse].</td></tr></table>
+
+# 2.28. Page 356 - (2025-06) - Updated note of K11.FR.06 with MaxExternalConstraintsId
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>K11.FR.06</td><td>When an external charging limit/schedule is received</td><td>The Charging Station SHALL use purpose ChargingStationExternalConstraints when reporting about this limit (i.e. in a ReportChargingProfilesRequest).</td><td>It is RECOMMENDED to use negative values for the id of a ChargingStationExternalConstraints profile, to minimize the risk of a clash with an id that CSMS might use for a (future) charging profile. See use case K29 for the use of Dynamic charging profiles and external limits.</td></tr><tr><td>New</td><td>K11.FR.06</td><td>When an external charging limit/schedule is received</td><td>The Charging Station SHALL use purpose ChargingStationExternalConstraints when reporting about this limit (i.e. in a ReportChargingProfilesRequest).</td><td>When configuration variable MaxExternalConstraintsId exists, it is RECOMMENDED to use values for the id of a ChargingStationExternalConstraints profile below this value, to minimize the risk of a clash with an id that CSMS might use for a (future) charging profile. When configuration variable MaxExternalConstraintsId does not exist, it is RECOMMENDED to use negative values for the id of a ChargingStationExternalConstraints profile, to minimize the risk of a clash with an id that CSMS might use for a (future) charging profile. See use case K29 for the use of Dynamic charging profiles and external limits.</td></tr></table>
+
+# 2.29. Page 376 - (2025-09) - K16 use case description update
+
+The use case description refers to SetChargingProfile in step 7, but that is too restricting. It is the composite schedule that is provided to EV.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>...</td><td>...</td><td>...</td></tr><tr><td></td><td>Scenario description</td><td>1 CSMS sends a SetChargingProfileRequest to the Charging Station.
+2 Charging Station responds with a SetChargingProfileResponse to the CSMS.
+3 When EV sends the next CurrentDemandReq (for DC) or ChargingStatusReq (for AC), the Charging Station will respond with evseNotification = ReNegotiation.
+4 EV sends a PowerDeliveryReq with chargeProgress = ReNegotiate to confirm this.
+5 Charging Station responds with a PowerDeliveryRes.
+6 EV sends a ChargeParameterDiscoveryReq.
+7 Charging Station responds with a ChargeParameterDiscoveryRes with an SAScheduleList that contains the composite schedule(s) for the EVSE ChargingSchedule data from the SetChargingProfileRequest.
+8 EV sends a PowerDeliveryReq with chargeProgress = Start (with an optional charging profile) to confirm this.
+9 Charging Station responds with PowerDeliveryRes and, if charging was suspended at start of the renegotiation, will resume power delivery.
+10 If EV provided a charging profile in the previous step, then Charging Station will send a NotifyEVChargingScheduleRequest to the CSMS.</td></tr><tr><td>...</td><td>...</td><td>...</td></tr></table>
+
+# 2.29.1. Page 377
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirements</td><td>NOTE</td></tr><tr><td>Old</td><td>K16.FR.0 2 (2.1)</td><td>K16.FR.01</td><td>Charging Station SHALL initiate schedule renegotiation with EV.</td><td>In ISO 15118-2 this is done by replying with EVSENotification=ReNegotiation to a CurrentDemandReq (for DC) or ChargingStatusReq (for AC) message.In ISO 15118-20 this is done by replying with EVSENotification=ScheduleRenegotiation in ChargeLoopRes.</td></tr><tr><td>New</td><td>K16.FR.0 2 (2.1)</td><td>When the composite schedule for the EVSE changes</td><td>Charging Station SHALL initiate schedule renegotiation with EV.</td><td>This can be caused by a Set/ClearChargingProfileRequest or a change in ChargingStationExternalConstraints/Local Generation charging profiles.In ISO 15118-2 renegotiation is started by replying with EVSENotification=ReNegotiation to a CurrentDemandReq (for DC) or ChargingStatusReq (for AC) message.In ISO 15118-20 this is done by replying with EVSENotification=ScheduleRenegotiation in ChargeLoopRes.</td></tr><tr><td>Old</td><td>K16.FR.0 3</td><td>K16.FR.02</td><td>Charging Station SHALL provide the ChargingSchedule data to the EV.</td><td>In ISO 15118 this is done in the ChargeParameterDiscoverRes message.</td></tr><tr><td>New</td><td>K16.FR.0 3</td><td>K16.FR.02</td><td>Charging Station SHALL provide the composite schedule(s) ChargingSchedule data to the EV.</td><td>In ISO 15118 this is done in the ChargeParameterDiscoverRes message.</td></tr></table>
+
+# 2.30. Page 475 - (2025-06) - 001 - Added missing requirements
+
+Added missing requirements explicitly specifying behaviour of Charging Station it contains one or more displays.
+
+New requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td colspan="3">Multiple Display support</td></tr><tr><td>001.FR.20</td><td>When Charging Station has multiple displays AND Charging Station receives a [setdisplaymessagerequest] without a display element in its MessageInfoType</td><td>Charging Station SHOULD use the message for the main display(s)</td></tr><tr><td>001.FR.21</td><td>When receiving a GetBaseReportRequest AND Charging Station has one or more displays</td><td>Charging Station SHOULD include in the report a Display component for every display it contains.</td></tr><tr><td>001.FR.22</td><td>When Charging Station receives a [setdisplaymessagerequest] with Display element referencing an unknown Display in its MessageInfoType</td><td>Charging Station SHOULD respond with a [setdisplaymessageresponse] with status = Rejected.</td></tr><tr><td>001.FR.23</td><td>When Charging Station receives a [setdisplaymessagerequest] with Display element referencing a known Display in its MessageInfoType</td><td>Charging Station SHOULD use the message only for the specified display.</td></tr></table>
+
+# 2.31. Page 370 - (2025-06) - K27 Updated remark of use case
+
+The remark of K27 has been improved to clarify the difference between using an Absolute or a Dynamic chargingProfileKind for a charging profile with a LocalGeneration chargingProfilePurpose, and to mention that chargingProfile.id for the updates does not change.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>...</td><td>...</td><td>...</td></tr><tr><td>8</td><td>Remarks</td><td>If the external system provides a limit via a protocol that is not OCPP, e.g. ModBus, then Charging Station can represent this as an Absolute charging profile, that is replaced when the limit changes, or as a Dynamic charging profile with a single charging schedule period with operationMode = ExternalLimits in which the limit is dynamically updated.
+It is up to the Charging Station implementation to decide whether to represent the external limits for LocalGeneration as an Absolute charging profile that is replaced by a new charging profile with the same chargingProfile.id upon each change of the external limit, or as a Dynamic charging profile with an operationMode = ExternalLimits in which the limit is changed upon each change of the external limit.</td></tr></table>
+
+# 2.32. Page 389 - (2025-06) - K19.FR.04 Minor rephrasing
+
+K19.FR.04 reads "If the CSMS is not able to provide ...". This suggests that it may be caused by an error condition, but it can be a conscious choice to not provide a charging profile. Changed "able" to "going" to make this clear.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>K19.FR.04</td><td>K19.FR.02</td><td>If the CSMS is not able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to NoChargingProfile.</td><td>(Note, status value differs from K15.FR.04). Charging Station will use a TxDefaultProfile or provide a schedule with unlimited power.</td></tr><tr><td>New</td><td>K19.FR.04</td><td>K19.FR.02</td><td>If the CSMS is not going to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to NoChargingProfile.</td><td>(Note, status value differs from K15.FR.04). Charging Station will use a TxDefaultProfile or provide a schedule with maximum power of EVSE.</td></tr></table>
+
+# 2.33. Page 395 - (2025-06) - CSMS requirement to support UsePriorityCharging
+
+A CSMS must support priority charging. This has been added as a requirement.
+
+New requirement
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K21.FR.10</td><td></td><td>CSMS SHALL support sending a [useprioritychargingrequest]</td><td>A Charging Station reports support for this in SmartChargingCtrlr.SupportedAdditionalPurposes.</td></tr></table>
+
+# 2.34. Page 396 - (2025-06) - 5.5 Dynamic Charging Profile [882]
+
+The following paragraphs are added to clarify use of duration field.
+
+# Duration in dynamic charging profiles
+
+The field duration of ChargingScheduleType limits the maximum duration of a charging schedule. A dynamic charging profile consists of a charging schedule with only a single period. If no duration is given in the charging schedule, this period is valid indefinitely, and the limits only change when updated via an UpdateDynamicScheduleRequest or PullDynamicScheduleUpdateResponse message or by an external system.
+
+If a value for duration is given, then the charging schedule will end if no update for the limits has been received for more than duration seconds since the last update. This mechanism can be used to ensure that a dynamic charging profile that depends on regular limit updates from CSMS or an external system, will cease to be used when no updates are received anymore, e.g. because connection to the CSMS or external system has been lost.
+
+# 2.35. Page 397 - (2025-06) - K28 missing requirement about duration [882]
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Dynamic charging profiles from CSMS</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="3"></td><td rowspan="3">Scenario description #1</td><td>Updates sent by CSMS</td></tr><tr><td>...</td></tr><tr><td>5. If chargingSchedule.duration is set and the setpoint/limit is not updated by a [updatedynamicschedulerequest] after duration seconds, then the chargingSchedule ends and Charging Station will fall back to the next valid charging profile.a. If chargingSchedule.duration has not been set, then the chargingSchedule is valid indefinitely, until the charging profile is cleared or replaced by CSMS.</td></tr><tr><td rowspan="3"></td><td rowspan="3">Scenario description #2</td><td>Updates requested by Charging Station</td></tr><tr><td>...</td></tr><tr><td>6. If chargingSchedule.duration is set and the setpoint/limit is not updated by [pulldynamicscheduleupdateresponse] after duration seconds, then the chargingSchedule ends and Charging Station will fall back to the next valid charging profile.a. If chargingSchedule.duration has not been set, then the chargingSchedule is valid indefinitely, until the charging profile is cleared or replaced by CSMS.</td></tr><tr><td colspan="3">...</td></tr></table>
+
+The following requirements have been copied from Q05 to K28, because they are generic.
+
+New requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K28.FR.13</td><td>When a ChargingProfileType has chargingProfileKind = Dynamic AND chargingSchedule.duration is set AND current time > (chargingSchedule.duration + dynUpdateTime)</td><td>Charging Station SHALL consider the charging profile invalid and switch to using the next valid charging profile.</td><td>This is a fallback when CSMS is no longer responding within time set by duration.</td></tr><tr><td>K28.FR.14</td><td>K28.FR.13 AND Charging Station receives an update for limit or setpoint from CSMS via [updatedynamicschedulereques] or [pulldynamicscheduleupdateresponse]</td><td>Charging Station SHALL consider the charging profile eligible again as a valid profile.</td><td>This means the charging profile is valid again when a new update is received, assuming there is no other charging profile of higher stack level.</td></tr></table>
+
+Having K28.FR.07 as precondition in K28.FR.09 is not correct.
+
+Updated requirement
+
+<table><tr><td></td><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>K28.FR.09</td><td>K28.FR.06 OR K28.FR.07 OR K28.FR.08</td><td>Charging Station SHALL set dynUpdateTime to current time.</td><td></td></tr><tr><td>New</td><td>K28.FR.09</td><td>K28.FR.06 OR K28.FR.07 OR K28.FR.08</td><td>Charging Station SHALL set dynUpdateTime to current time.</td><td></td></tr></table>
+
+# 2.36. Page 399 - (2025-09) - K28.FR.10 Precondition not complete
+
+Pulling a new schedule is, of course, only required when the dynUpdateInterval has elapsed.
+
+<table><tr><td></td><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>K28.FR.10</td><td>When chargingProfileKind = Dynamic and dynUpdateInterval > 0 in chargingProfile</td><td>Charging Station SHALL send a [pulldynamicscheduleupdaterequest] with chargingProfileId = chargingProfile.id to request an update of the chargingSchedulePeriod.</td><td></td></tr><tr><td>New</td><td>K28.FR.10</td><td>When chargingProfileKind = Dynamic and dynUpdateInterval > 0 in chargingProfile AND dynUpdateTime + dynUpdateTime >= <current time></td><td>Charging Station SHALL send a [pulldynamicscheduleupdaterequest] with chargingProfileId = chargingProfile.id to request an update of the chargingSchedulePeriod.</td><td></td></tr></table>
+
+New requirement
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K28.FR.15</td><td>When a [cmnchargeringscheduetype] of a [cmnchargeringsprofiletype] with chargingProfileKind = Dynamic contains the field duration AND current time > (chargingSchedule.duration + dynUpdateTime)</td><td>Charging Station SHALL consider the charging profile invalid and switch to using the next valid charging profile.</td><td>Field duration defines how long a the charging schedule remains valid after receipt of a [updatedynamicschedulereques t] or [pulldynamicscheduleupdateres ponse].</td></tr></table>
+
+# 2.37. Page 400 - (2025-06) - K29 missing requirement about duration [882]
+
+The scenarios have been updated to show how to deal with a limited duration of a dynamic charging profile.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Dynamic charging profiles from external system</td></tr><tr><td colspan="3">...</td></tr><tr><td rowspan="3"></td><td rowspan="3">Scenario description #1</td><td>Charging profile from external system with dynamic updates</td></tr><tr><td>...</td></tr><tr><td>5. If chargingSchedule.duration is set and the setpoint/limit is not updated by External System after duration seconds, then the chargingSchedule ends and Charging Station will fall back to the next valid charging profile.a. If chargingSchedule.duration has not been set, then the chargingSchedule is valid indefinitely, until the charging profile is cleared or replaced by External System.</td></tr><tr><td rowspan="2"></td><td rowspan="2">Scenario description #2</td><td>Charging profile from CSMS with dynamic updates from external system...</td></tr><tr><td>5. If chargingSchedule.duration is set and the setpoint/limit is not updated by External System after duration seconds, then the chargingSchedule ends and Charging Station will fall back to the next valid charging profile.#a. If chargingSchedule.duration has not been set, then the chargingSchedule is valid indefinitely, until the charging profile is cleared or replaced by CSMS.</td></tr><tr><td>8</td><td>Remarks</td><td>...It is advised to have a charging profile with a lower stack level present to fall back to, in case the dynamic charging profile is invalidated, because no update is provided within duration seconds.</td></tr></table>
+
+The following requirements have been copied from Q05 to K29, because they are generic.
+
+New requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K29.FR.07</td><td>When a ChargingProfileType has chargingProfileKind = Dynamic AND chargingSchedule.duration is set AND current time > (chargingSchedule.duration + dynUpdateTime)</td><td>Charging Station SHALL consider the charging profile invalid and switch to using the next valid charging profile.</td><td>This is a fallback when CSMS or External System is no longer responding within time set by duration.</td></tr><tr><td>K29.FR.08</td><td>K29.FR.07 AND Charging Station receives an update for limit or setpoint from External System</td><td>Charging Station SHALL consider the charging profile eligible again as a valid profile.</td><td>This means the charging profile is valid again when a new update is received, assuming there is no other charging profile of higher stack level. (See also K29.FR.03)</td></tr></table>
+
+# 2.38. Page 401 - (2025-06) - K29.FR.04: updated precondition to using dynamic profiles
+
+K29.FR.04 only applies when Charging Station intends to use a dynamic charging profile. This is reflected by adding K29.FR.05 in precondition.
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr></table>
+
+<table><tr><td>Old</td><td>K29.FR.04</td><td>NOT K29.FR.03 AND [configkey-external-constraints-profile-disallowed] is false or absent AND An external system provides a current or power limit (i.e. single value, not a schedule)</td><td>Charging Station SHALL represent this as a [cmnchargerprofiletype] with a single chargingSchedulePeriod, and having a chargingProfilePurpose = ChargingStationExternalConstraints with a chargingProfileKind = Dynamic.</td><td>The alternative, using a chargingProfileKind = Absolute, is described in K11.FR.06.</td></tr><tr><td>New</td><td>K29.FR.04</td><td>NOT K29.FR.03 AND K29.FR.05 AND [configkey-external-constraints-profile-disallowed] is false or absent AND An external system provides a current or power limit (i.e. single value, not a schedule)</td><td>Charging Station SHALL represent this as a [cmnchargerprofiletype] with a single chargingSchedulePeriod, and having a chargingProfilePurpose = ChargingStationExternalConstraints with a chargingProfileKind = Dynamic.</td><td>The alternative, using a chargingProfileKind = Absolute, is described in K11.FR. 06.</td></tr></table>
+
+# 2.39. Page 402 - (2025-06) - K29.FR.05: Setpoint missing in precondition
+
+<table><tr><td></td><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>K29.FR.05</td><td>When external system updates a limit AND Charging Station represents this as a Dynamic charging profile</td><td>Charging Station SHALL update the limit or setpoint in this charging profile.</td><td></td></tr><tr><td>New</td><td>K29.FR.05</td><td>When external system updates a limit or setpoint AND Charging Station represents this as a Dynamic charging profile</td><td>Charging Station SHALL update the limit or setpoint in this charging profile.</td><td></td></tr></table>
+
+# 2.40. Page 447 - (2025-09) - N01.FR.12 - Improved definition
+
+Updated requirement definition to clarify the AcceptedCanceled status.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>Old</td><td>N01.FR.12</td><td>When a Charging Station is assembling or uploading the log file AND the Charging Station receives a new GetLogRequest</td><td>The Charging Station SHOULD cancel the ongoing log file upload AND respond with status AcceptedCanceled.</td></tr><tr><td>New</td><td>N01.FR.12</td><td>When a Charging Station is assembling or uploading the log file AND the Charging Station receives a new GetLogRequest</td><td>The Charging Station SHOULD cancel the ongoing log file upload AND respond GetLogResponse with status AcceptedCanceled.</td></tr></table>
+
+# 2.41. Page 449 - (2025-09) - N02: changed empty to absent.
+
+A number of requirements previously stated "empty" when they should have indicated "absent." For example, the phrases referring to monitoringCriteria and componentVariables being "empty" are incorrect. These arrays cannot be empty; they must be absent instead. This correction has been applied to all occurrences throughout section N02.
+
+# 2.42. Page 450 - (2025-06) - N02.FR.13/23 monitoringCriteria DeltaMonitoring is used for TargetDelta [895]
+
+There is no monitoring criteria TargetDeltaMonitoring. That is just DeltaMonitoring.
+
+Change requirement
+
+Deleted requirement
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>Old</td><td>N02.FR.13</td><td>If monitoringCriteria contains DeltaMonitoring</td><td>All monitors with type = Delta are reported.</td></tr><tr><td>New</td><td>N02.FR.13</td><td>If monitoringCriteria contains DeltaMonitoring</td><td>All monitors with type = Delta, TargetDelta and TargetDeltaRelative are reported.</td></tr></table>
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N02-FR.23 (2.1)</td><td>If monitoringCriteria contains TargetDeltaMonitoring</td><td>All monitors with type = TargetDelta and type = TargetDeltaRelative are reported.</td></tr></table>
+
+# 2.43. Page 720 - (2025-06) - New configuration variable to allow TLS wildcard certificates
+
+New configuration key
+
+AllowCSMSTLSWildcards
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>ijklname</td><td colspan="2">AllowCSMSTLSWildcards</td></tr><tr><td>ijkl attributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>ijklCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">This variable allows a Charging Station to support non-compliant OCPP behavior and connect to a CSMS that uses a wildcard TLS server certificate for the OCPP connection. If this variable is present it SHALL be ReadWrite. If this variable is not implemented or has value false, the OCPP-compliant behavior is that a Charging Station rejects a connection from a CSMS that presents a wildcard certificate. It is highly RECOMMENDED to not allow wildcard certificates.</td></tr></table>
+
+# 2.44. Page 739 - (2025-09) - Error in description of AssociatedData interval variables [1043]
+
+The Interval and TxEndedInterval variables of AlignmentDataCtrl mention an incorrect time and duration format (ISO8601) that is not supported by OCPP.
+
+# 2.44.1.AlignedDataInterval
+
+<table><tr><td>...</td><td>...</td></tr><tr><td>Description</td><td>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.
+A value of "0" (numeric zero), by convention, is to be interpreted to mean that no clock-aligned data should be transmitted.</td></tr></table>
+
+# 2.44.2.AlignedDataTxEndInterval
+
+<table><tr><td>...</td><td>...</td></tr><tr><td>Description</td><td>Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the TransactionRequest (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 intervals are transmitted (if so enabled) at the end of the transaction in 1 TransactionRequest (eventType = Ended) message.
+This is not a recommended practice, since the size of the message can become very large.</td></tr></table>
+
+# 2.44.3.AlignedDataUpstreamInterval
+
+New in OCPP 2.1
+
+<table><tr><td>...</td><td>...</td></tr><tr><td>Description</td><td>Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the MeterValuesRequest message for location Upstream only. 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, 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.</td></tr></table>
+
+# 2.45. Page 492 - (2025-09) - Text instances of dischargingLimit instead of dischargeLimit
+
+There were many instances of the word dischargingLimit being used in text or requirements of section Q, instead of the correct word dischargeLimit. This has been fixed globally.
+
+# 2.46. Page 499 - (2025-06) - Additional V2X generic requirements
+
+The phase-related requirement from K01 also apply to discharging and setpoint parameters in block Q.
+
+New requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>V2X.06</td><td></td><td>Any requirements for limit, dischargingLimit, setpoint and setpointReactive also apply to their equivalents with postfix _L2 and _L3</td><td></td></tr><tr><td>V2X.07</td><td></td><td>The postfixed L2 and L3 variants of limit, dischargingLimit, setpoint and setpointReactive can only occur in combination with the associated field without the postfix.</td><td>See K01.FR.145</td></tr><tr><td>V2X.08</td><td>When v2xChargingParameters of [notifyevchargingneed srequest] from Charging Station does not contain maxDischargePower_L2 and/or maxDischargePower_L3</td><td>CSMS SHALL NOT provide values for dischargeLimit_L2, dischargeLimit_L3, setpoint(Reactive)_L2 or setpoint(Reactive)_L3 fields in a charging profile.</td><td>If EV does not report L2/L3 fields then do not provide separate limits for them. See K01.FR.142.</td></tr><tr><td>V2X.09</td><td>When CSMS sends a [setchargingprofilerequest] for a chargingProfilePurpose other than TxProfile</td><td>CSMS SHALL NOT provide values for dischargeLimit_L2, dischargeLimit_L3, setpoint(Reactive)_L2 or setpoint(Reactive)_L3 fields in chargingSchedulePeriods of the charging profile</td><td>Only a TxProfile is submitted after receiving a NotifyEVChargingNeedsRequest. See K01.FR.143.</td></tr><tr><td>V2X.10</td><td>(V2X.08 OR V2X.09) AND Charging Station receives a [setchargingprofilerequest] with values for dischargeLimit_L2, dischargeLimit_L3, setpoint(Reactive)_L2 or setpoint(Reactive)_L3 fields in a charging profile</td><td>Charging Station SHALL respond with [setchargingprofileresponse] with status = Rejected and a statusInfo with reasonCode = "PhaseConflict".</td><td>See K01.FR.144.</td></tr></table>
+
+# 2.47. Page 503 - (2025-06) - Q01.FR.05 Precondition needs to refer to ISO15118-serviceRenegotiationSupport
+
+<table><tr><td></td><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>Q01.FR.05</td><td>Q01.FR.04</td><td>Charging Station SHOULD start a service renegotiation with EV for a different energy transfer service</td><td>This situation should not occur when an energy transfer is selected from the allowedEnergyTransfer list in theauthorizeResponse.</td></tr><tr><td>New</td><td>Q01.FR.05</td><td>Q01.FR.04 AND ISO15118(ServiceRenegotiationSupport = true</td><td>Charging Station SHALL start a service renegotiation with EV for a different energy transfer service and send a new NotifyEVChargingNeedsRequest</td><td>This situation should not occur when an energy transfer is selected from the allowedEnergyTransfer list in theauthorizeResponse.</td></tr></table>
+
+# 2.48. Page 504 - (2025-09) - Q01.FR.02 Enhanced precondition to apply only for V2X
+
+The need to send an EVCCID only applies for stations that are able to switch to V2X. This has been added to precondition.
+
+<table><tr><td></td><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>Q01.FR.02</td><td>When Charging Station starts an ISO 15118-20 transaction</td><td>Charging Station SHALL add EVCCID to idToken in [transactioneventrequest](eventType=Started) in idToken不断增加Info.additionallyd Token and with idToken不断增加Info.type set to "EVCCID".</td><td>This transaction may become bidirectional. This is needed in case CSMS uses the EVCCID of vehicle to decide whether to allow V2X.</td></tr><tr><td>New</td><td>Q01.FR.02</td><td>When Charging Station's ISO15118Ctrlr.Enabled = true and V2XChargingCtrlr.Enabled = true AND When Charging Station starts an ISO 15118-20 transaction</td><td>Charging Station SHALL add EVCCID to idToken in [transactioneventrequest](eventType=Started) in idToken不断增加Info不断增加Id Token and with idToken不断增加Info.type set to "EVCCID".</td><td>This transaction may become bidirectional. This is needed in case CSMS uses the EVCCID of vehicle to decide whether to allow V2X.</td></tr></table>
+
+# 2.49. Page 504 - (2025-09) - Q01.FR.07 Clarified difference Accepted and Processing
+
+The difference between status Accepted and Processing was not mentioned in requirement, because that is described in use cases K18 and K19. As such, the requirement Q01.FR.07 could have been omitted in Q01, but since it is so essential to the use case flow, it was added to the requirements table. This errata clarifies the difference between Accepted and Processing and refers to K18 and K19.
+
+<table><tr><td></td><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>Q01.FR.07</td><td>If CSMS accepts the requestedEnergyTransfer</td><td>CSMS SHALL respond with a [notifyevchargingneedsresponse] with status = Accepted or Processing.</td><td>Charging station can expect to receive a charging profile immediately or soon.</td></tr><tr><td>New</td><td>Q01.FR.07</td><td>If CSMS accepts the requestedEnergyTransfer</td><td>CSMS SHALL respond with a [notifyevchargingneedsresponse] with status = Accepted if able to provide a charging profile immediately or Processing if more time is needed to provide a charging profile.</td><td>See requirements K18/19.FR.03 and K18/19.FR.05. Charging station can expect to receive a charging profile immediately or soon.</td></tr></table>
+
+# 2.50. Page 504 - (2025-09) - Q01.FR.08 Improved precondition
+
+Q01.FR.08 had Q01.FR.01 as precondition, but they were contradicting each other about being able and not able to determine allowedEnergyTransfer. Relevant part of Q01.FR.01 precondition has been added to Q01.FR.08.
+
+<table><tr><td></td><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>Q01.FR.08</td><td>Q01.FR.01 AND CSMS is not able to determine a list of allowedEnergyTranfer before sending the [authorizeresponse]</td><td>CSMS SHALL omit allowedEnergyTransfer from [authorization].</td><td>This can happen if it could not be determined within the short time span before the response has to be returned, e.g. because a third party has to be requested for permission.</td></tr><tr><td>New</td><td>Q01.FR.08</td><td>Q01.FR.01 AND Charging Station's ISO15118Ctrlr.Enabled = true and V2XChargingCtrlr.Enabled = true AND CSMS receives an [authorization] AND CSMS is not able to determine a list of allowedEnergyTranfer before sending the [authorization]</td><td>CSMS SHALL omit allowedEnergyTransfer from [authorization].</td><td>This can happen if it could not be determined within the short time span before the response has to be returned, e.g. because a third party has to be requested for permission.</td></tr></table>
+
+# 2.51. Page 503 - (2025-06) - Q01.FR.09 Wrong precondition
+
+<table><tr><td></td><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>Q01.FR.09</td><td>Q01.FR.20</td><td>Charging Station SHALL send a [notifyevchargingneedsrequest] with evseld set to the EVSE used for this transaction and requestedEnergyTransfer set to its default energy transfer (charging only AC/DC) and availableEnergyTransfer set to the supported energy transfers.</td><td>Depending on type of EVSE this will be AC_single_phase, AC_two_phase, AC_three_phase or DC, DC_ACDP</td></tr><tr><td>New</td><td>Q01.FR.09</td><td>Q01.FR.08</td><td>Charging Station SHALL send a [notifyevchargingneedsrequest] with evseld set to the EVSE used for this transaction and requestedEnergyTransfer set to its default energy transfer (charging only AC/DC) and availableEnergyTransfer set to the supported energy transfers.</td><td>Depending on type of EVSE this will be AC_single_phase, AC_two_phase, AC_three_phase or DC, DC_ACDP</td></tr></table>
+
+# 2.52. Page 504 - (2025-06) - Q02 Use case text not in line with Q02.FR.03
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Starting in operationMode ChargingOnly before enabling V2X</td></tr><tr><td colspan="3">...</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends a [authorizerequest] with EVCCID of EV in additionInfo of idToken.
+a. The CSMS cannot (yet) allow V2X and returns an [authorizeresponse] with idTokenInfo.status = Accepted and omits the field allowedEnergyTransfer.</td></tr><tr><td colspan="3">...</td></tr></table>
+
+# 2.53. Page 513 - (2025-06) - Q05 add requirement about duration [822]
+
+Requirement from K28 has been added that charging profile becomes valid again after an update of limit is received.
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Q05.FR.08</td><td>Q05.FR.07 AND Charging Station receives an update for limit, dischargingLimit or setpoint from External System</td><td>Charging Station SHALL consider the charging profile eligible again as a valid profile.</td><td>This means the charging profile is valid again when a new update is received, assuming there is no other charging profile of higher stack level.</td></tr></table>
+
+# 2.54. Page 514 - (2025-06) - Prerequisite in use case Q06 updated
+
+The use case Q06 contains a prerequisite about TxProfile or TxDefaultProfile which does not belong here.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>External V2X control with a charging profile from an External System</td></tr><tr><td colspan="3">...</td></tr><tr><td>5</td><td>Prerequisites</td><td>For discharging, at least one of the active charging sessions must have an active TxProfile or TxDefaultProfile for V2X operations.
+Configuration variable [configkey-external-control-signals-enabled] = true.
+Configuration variable [configkey-external-constraints-profile-disallowed] = false or absent.</td></tr><tr><td colspan="3">...</td></tr></table>
+
+# 2.55. Page 516 - (2025-06) - Q06.FR.11/12 can be combined [883]
+
+Requirements Q06.FR.11 and Q06.FR.12 are overlapping and can be combined.
+
+<table><tr><td></td><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>Q06.FR.11</td><td>Q06.FR.02 OR Q06.FR.04</td><td>Charging Station SHALL send a [notifycharginglimitrequest] with chargingLimitSource = EMS, isDynamic = true and with the received schedule in chargingSchedule to CSMS.</td><td>This chargingSchedule will only have a single period.</td></tr><tr><td>New</td><td>Q06.FR.11</td><td>(Q06.FR.02 OR Q06.FR.04) AND The value of limit, dischargingLimit setpoint, setpointReactive changes more than SmartChargingCtrl.LimitChangeSignificance</td><td>Charging Station SHALL send a [notifycharginglimitrequest] with chargingLimitSource = EMS, isDynamic = true and with the received schedule in chargingSchedule to CSMS.</td><td>This chargingSchedule will only have a single period. Also applies to L2 and L3 values.</td></tr></table>
+
+Deleted requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Q06.FR.12</td><td>Q06.FR.07 AND The value of limit, dischargingLimit, setpoint, setpointReactive changes more than SmartChargingCtrl.LimitChangeSignificance</td><td>Charging Station SHALL send a [notifycharginglimitrequest] with chargingLimitSource = EMS, isDynamic = true and a schedule with the new values in chargingSchedule to CSMS.</td><td>Also applies to L2 and L3 values.</td></tr></table>
+
+# 2.56. Page 517 - (2025-06) - Q06 add requirement about duration [822]
+
+Requirement from K29 has been added that charging profile becomes valid again after an update of limit is received.
+
+New requirement
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td colspan="4">Dynamic duration</td></tr><tr><td>Q06.FR.40</td><td>When a ChargingProfileType has chargingProfileKind = Dynamic AND chargingSchedule.duration is set AND current time > (chargingSchedule.duration + dynUpdateTime)</td><td>Charging Station SHALL consider the charging profile invalid and switch to using the next valid charging profile.</td><td>This is a fallback when External System is no longer responding within time set by duration. (Same as K29.FR.07)</td></tr><tr><td>Q06.FR.41</td><td>Q06.FR.40 AND Charging Station receives an update for limit, dischargingLimit or setpoint from External System</td><td>Charging Station SHALL consider the charging profile eligible again as a valid profile.</td><td>This means the charging profile is valid again when a new update is received, assuming there is no other charging profile of higher stack level.</td></tr></table>
+
+# 2.57. Page 519 - (2025-09) - Q07 Added requirements
+
+Q07 is a special case of CentralSetpoint, but some requirements were added for completeness.
+
+New requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td colspan="4">OperationMode CentralFrequency</td></tr><tr><td>Q07.FR.01</td><td>When Charging Station supports centrally controlled frequency support</td><td>Charging Station SHALL report the operation mode CentralFrequency in [configkey-v2xsupportedoperationmodes]</td><td></td></tr><tr><td>Q07.FR.02</td><td>When CSMS is providing centrally controlled frequency support via setpoints</td><td>CSMS SHALL send a [setchargingprofilerequest] message with chargingProfileKind = Dynamic and a single chargingSchedulePeriod that has operationMode = CentralFrequency.</td><td></td></tr><tr><td>Q07.FR.03</td><td>Q07.FR.02</td><td>CSMS SHALL NOT include fields limit and dischargeLimit in the [cmnchargeringscheduleperiodtype].</td><td>This also includes the L2 and L3 variants of those fields.</td></tr><tr><td>Q07.FR.04</td><td>Q07.FR.02</td><td>CSMS IS RECOMMENDED to set a duration of the chargingSchedule to prevent that the schedule remains active indefinitely when CSMS is unable to send any [updatedynamicschedulerequest] for whatever reason.</td><td></td></tr></table>
+
+# 2.58. Page 522 - (2025-09) - Q08.FR.02/12 Requirement updates for aFRR
+
+Changed requirement
+
+<table><tr><td></td><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>Q08.FR.02</td><td>Q08.FR.01</td><td>The [cmnchargeringscheduleperiodtype] SHALL have a v2xFreqWattCurve with at least two [cmn_v2xfreqwattpointtype] elements, and a value for v2xBaseline.</td><td></td></tr><tr><td>New</td><td>Q08.FR.02</td><td>Q08.FR.01</td><td>The [cmnchargeringscheduleperiodtype] SHALL have a v2xFreqWattCurve with at least two [cmn_v2xfreqwattpointtype] elements, and a value for v2xBaseline, and optionally a v2xSignalWattCurve with at least to [cmn_v2xsignalwattpointtype] elements.</td><td></td></tr></table>
+
+New requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Q08.FR.12</td><td>When CSMS receives an aFRR signal from an external actor</td><td>CSMS SHALL send a [afrrsignalrequest] with timestamp set to current time and signal set to value received from external actor.</td><td>External actor is, for example, a TSO.</td></tr><tr><td colspan="4">Configuration</td></tr><tr><td>Q08.FR.20</td><td>When Charging Station supports local frequency support</td><td>Charging Station SHALL report the operation mode LocalFrequency in [configkey-v2xsupportedoperationmodes]</td><td></td></tr></table>
+
+# 2.59. Page 550 - (2025-09) - R04 extra requirements to SetDERControlRequest [997]
+
+A default control cannot have a startTime or duration. Requirements have been added to make this explicit. The mapping of(controlType to control fields has been made explicit.
+
+New requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>R04.FR.12</td><td></td><td>CSMS SHALL not send a [setdercontrolrequest] that has isdefault = true for a control that has astartTime and/or duration field</td><td>All controls except enterService and gradient have optionalstartTime, duration.</td></tr><tr><td>R04.FR.13</td><td>Charging Station receives a [settercontrolrequest] with isDefault = true AND a control that has astartTime and/or duration field</td><td>Charging Station SHALL respond with [settercontrolresponse] with status = Rejected</td><td>Default controls cannot have astartTime or duration.</td></tr><tr><td>R04.FR.14</td><td></td><td>CSMS SHALL not send [settercontrolrequest] that has isdefault = false for(controlType = EnterService or Gradients</td><td>These only exist as default controls.</td></tr><tr><td>R04.FR.15</td><td>Charging Station receives a [settercontrolrequest] with isDefault = false AND controlType = EnterService or Gradients</td><td>Charging Station SHALL respond with [settercontrolresponse] with status = Rejected</td><td></td></tr><tr><td>R04.FR.16</td><td></td><td>CSMS SHALL only provide in [settercontrolrequest] the control field that is related to(controlType, according to the following mapping: fixedPFAbsorb for FixedPFAbsorb, fixedPFInject for FixedPFInject, fixedVar for FixedVar, limitMaxDischarge for LimitMaxDischarge, freqDroop for FreqDroop, enterService for EnterService, gradient for Gradients, curve for all other controlTypes</td><td></td></tr><tr><td>R04.FR.17</td><td>Charging Station receives a [settercontrolrequest] with multiple controls or with a control that does not match(controlType</td><td>Charging Station SHALL respond with [settercontrolresponse] with status = Rejected</td><td>See R04.FR.16 for mapping of control fields to(controlType.</td></tr></table>
+
+# 2.60. Page 551 - (2025-09) - R04 extra requirements to GetDERControlRequest [998]
+
+Requirement added for the case where only isDefault is provided as a parameter.
+
+New requirement
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>R04.FR.37</td><td>NOT R04.FR.30 AND Charging Station receives a [getdercontrolrequest] with a value for isDefault and no(controlType and no controlled</td><td>Charging Station SHALL return a status = Accepted and send one or more [reportdercontrolrequest] messages for all controls that match the value of isDefault.</td><td>This is used to request all default or all scheduled controls at once.</td></tr></table>
+
+# 2.61. Page 551 - (2025-09) - R04 updated requirements to ClearDERControlRequest [999]
+
+Requirements R04.FR.41 and R04.FR.42 have been simplified. The way that requirement R04.FR.45 was phrased, it always returns Accepted - even when no matching controls exist. Requirement R04.FR.46 has been added for clearing based on controlId.
+
+Changed requirements
+
+New requirement
+
+<table><tr><td></td><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Old</td><td>R04.FR.41</td><td>Charging Station receives a [clearercontrolrequest] with no controlId and with a controlType that it supports, but that has not been set at the Charging Station for the specified value of isDefault</td><td>Charging Station returns a [clearercontrolresponse] with status = NotFound.</td><td></td></tr><tr><td>New</td><td>R04.FR.41</td><td>Charging Station receives a [clearercontrolrequest] with no controlId and with a controlType that it supports, but that has not been set at the Charging Station for the specified value of isDefault</td><td>Charging Station returns a [clearercontrolresponse] with status = NotFound.</td><td></td></tr><tr><td>Old</td><td>R04.FR.42</td><td>Charging Station receives a [clearercontrolrequest] with no controlType and with a controlId that has not been set for the given value of isDefault</td><td>Charging Station SHALL respond with [clearercontrolresponse] with status = NotFound.</td><td></td></tr><tr><td>New</td><td>R04.FR.42</td><td>Charging Station receives a [clearercontrolrequest] with no controlType and with a controlId that has not been set for the given value of isDefault</td><td>Charging Station SHALL respond with [clearercontrolresponse] with status = NotFound.</td><td></td></tr><tr><td>Old</td><td>R04.FR.45</td><td>Charging Station receives a [clearercontrolrequest] with no controlId and with a controlType that it supports and that is in use</td><td>Charging Station SHALL clear all controls that match the value of isDefault and(controlType in the request, and return a [clearercontrolresponse] with status = Accepted.</td><td>Return default or scheduled messages for controlType based on value of isDefault.</td></tr><tr><td>New</td><td>R04.FR.45</td><td>Charging Station receives a [clearercontrolrequest] with no controlId and with a controlType that it supports and that is in use</td><td>Charging Station SHALL clear all controls that match the value of isDefault and(controlType in the request, and return a [clearercontrolresponse] with status = Accepted.</td><td>Clear default or scheduled messages for controlType based on value of isDefault.</td></tr></table>
+
+<table><tr><td>R04.FR.46</td><td>Charging Station receives a [clearercontrolrequest] with a controId that has been set for the given value of isDefault</td><td>Charging Station SHALL clear the control that matches the value of controId in the request, and return a [clearercontrolresponse] with status = Accepted.</td><td></td></tr></table>
+
+# 2.62. Page 620 - (2025-06) - ChargingSchedulePeriodType limit description update
+
+The sentence about allowing negative values has been removed, because that is not in line with requirements. The meaning of this field in case chargingRateUnit = A, was missing.
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td colspan="4">...</td></tr><tr><td>limit</td><td>decimal</td><td>0..1</td><td>Optional. Optional only when not required by the operationMode, as in CentralSetpoint, ExternalSetpoint, ExternalLimits, LocalFrequency, LocalLoadBalancing. Charging rate limit during the schedule period, in the applicable chargingRateUnit. This SHOULD be a non-negative value; a negative value is only supported for backwards compatibility with older systems that use a negative value to specify a discharging limit. The value is zero or positive. When using chargingRateUnit = w, this field represents the sum of the power of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1. When using chargingRateUnit = A, this field represents the current on each phase, unless values are provided for L2 and L3, in which case the field represents phase L1.</td></tr><tr><td colspan="4">...</td></tr></table>
+
+# 2.63. Page 703 - (2025-06) - Controller component PaymentCtrl added to list
+
+The PaymentCtrl has been added to the list of controller components.
+
+<table><tr><td>Controller Component</td><td>Description</td></tr><tr><td>...</td><td>...</td></tr><tr><td>PaymentCtrl (2.1)</td><td>Responsible for configuration relating to a payment terminal.</td></tr></table>
+
+# 2.64. Page 750 - (2025-09) - TariffCostCtrlr.Enabled can be ReadOnly [934]
+
+There are good reasons to allow TariffCostCtrlr.Enabled to be a ReadOnly variable. TariffCostCtrlr.Enabled[Cost] (CostEnabled) can be set to ReadOnly false when Local Cost Calculation is not supported, and only cost calculation from the CSMS is supported. In this case TariffCostCtrlr.Available[Cost] will also be false.
+
+TariffCostCtrl.Enabled[Tariff] (TariffEnabled) can be set to ReadOnly true when the Charging Station only supports OCPP standardized tariff structures and no proprietary tariff structures. In this case TariffCostCtrl.Available[Tariff] will be true.
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableInstance</td><td colspan="2">Tariff</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite /ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">...</td></tr><tr><td>variableInstance</td><td colspan="2">Cost</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite /ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">...</td></tr></table>
+
+# 2.65. Appendix Page 51 - (2025-09) - Added connector type BatterySlot
+
+The generic connector type BatterySlot for battery swap stations has been added to ConnectorEnum.Type.
+
+New connector type
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>bBatterySlot</td><td>Slot of a battery swap station to accept battery cartridges (type unspecified)</td></tr></table>
+
+Example representation of a battery swap station in device model
+
+<table><tr><td>Connector</td><td>1</td><td>1</td><td></td><td>ConnectorType</td><td></td><td>Actual</td><td>b BatterySlot</td><td>string</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>1</td><td></td><td>ConnectorType</td><td></td><td>Actual</td><td>b BatterySlot</td><td>string</td><td></td><td>false</td></tr></table>
+
+# 3. Part 3
+
+Currently no new errata for OCPP 2.1 part 3.
+
+# 4. Part 4
+
+# 4.1. Page 16 - (2025-06) - 5.4 Reconnecting - reset backoff wait timer
+
+The RetryBackOffWaitMinimum timer is to be used the first time it tries to connect. A sentence has been added to below paragraph to make it explicit that it needs to be reset after successful connection.
+
+The first reconnection attempts SHALL be after a back-off time of: RetryBackOffWaitMinimum seconds, plus a random value with a maximum of RetryBackOffRandomRange seconds. After every failed reconnection attempt the Charging Station SHALL double the previous back-off time, with a maximum of RetryBackOffRepeatTimes, adding a new random value with a maximum of RetryBackOffRandomRange seconds to every reconnection attempt. After RetryBackOffRepeatTimes reconnection attempts, the Charging Station SHALL keep reconnecting with the last back-off time, not increasing it any further. After a successful connection the backoff wait timer SHALL be reset to RetryBackOffWaitMinimum seconds.
+
+# 4.2. Page 21 - (2025-06) - 6.3 Connection loss - Allow Local Controller to keep connection open
+
+The sentence in this section was too strict about requiring a Local Controller to always close the connection with its charging stations when the connection with CSMS is lost. The sentence has been updated in order to allow for Local Controller implementations that are able to manage the local charging stations locally (for a limited time) when the connection with CSMS is down.
+
+<table><tr><td>Old text</td><td>Whenever one or more WebSocket connections between CSMS and the Local Controller are lost, the Local Controller SHALL close all corresponding WebSocket to the Charging Stations that are connected to it.</td></tr><tr><td>New text</td><td>Whenever one or more WebSocket connections between CSMS and the Local Controller are lost, the Local Controller SHALL close all corresponding WebSocket to the Charging Stations that are connected to it, unless the Local Controller is capable of responding to Charging Station requests, and forwards transaction-related requests to the CSMS once the connection is restored.</td></tr></table>
--- /dev/null
+# OCPP
+
+# Table of Contents
+
+Disclaimer 1
+
+Version History 2
+
+1. Introduction. 3
+
+1.1. OCPP version 2.1 3
+1.2. Terms and abbreviations 3
+1.3. References 5
+
+2. New functionality in OCPP 2.1 6
+
+3. OCPP2.1 Documentation Structure. 8
+
+3.1. Overview of Specification Parts 8
+3.2. Functional Blocks 9
+3.3. All Functional Blocks and use cases 10
+
+4. Basic implementation of OCPP 2.1 15
+
+# Disclaimer
+
+Copyright © 2010 - 2025 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
+
+<table><tr><td>Version</td><td>Date</td><td>Description</td></tr><tr><td>2.1 Edition 1</td><td>2025-01-23</td><td>OCPP 2.1 Edition 1</td></tr></table>
+
+# Chapter 1. Introduction
+
+Electric Vehicles (EVs) are becoming the new standard for mobility all over the world. This development is only possible with a good coverage of Charging Stations. To advance the roll out of charging infrastructure, open communication standards play a key role: to enable switching from charging network without necessarily replacing all the Charging Stations, to encourage innovation and cost effectiveness and to allow many and diverse players participate in this new industry.
+
+Additionally, the EV charging infrastructure is part of the Smart Grid, a larger and still evolving ecosystem of actors, devices and protocols. In this Smart Grid ecosystem, open communications standards are key enablers for two-way power flows, real time information exchange, demand control and eMobility services.
+
+The Open Charge Point Protocol (OCPP) is the industry-supported de facto standard for communication between a Charging Station and a Charging Station Management System (CSMS) and is designed to accommodate any type of charging technique. OCPP is an open standard with no cost or licensing barriers for adoption.
+
+# 1.1. OCPP version 2.1
+
+This specification defines version 2.1 of OCPP.
+
+Version 2.1 is an extension of OCPP 2.0.1. OCPP 2.1 has its own JSON schemas, but the schemas are OCPP 2.0.1 schemas that have been extended with optional fields that are used by OCPP 2.1 functionality. With the minor exceptions mentioned below, all application logic developed for OCPP 2.0.1 will continue to work in OCPP 2.1 without any changes. The new features of OCPP 2.1, of course, require new application logic.
+
+# Use case A02 & A03
+
+The application logic in a CSMS for OCPP 2.0.1 for use cases A02 & A03 requires a small change in order to work in OCPP 2.1.
+
+The SignCertificateRequest message has been extended with a requestId field, such that the resulting
+
+CertificateSignedRequest message can be accurately mapped to the request that initiated it. Use of requestId is optional for
+
+Charging Station, but when present, CSMS will have to use it in the subsequent CertificateSignedRequest message.
+
+Note, that the updated application logic remains valid to use in OCPP 2.0.1.
+
+# Use case N02
+
+The application logic in a Charging Station for OCPP 2.0.1 for use case N02 requires a small change in order to work for OCPP 2.1.
+
+The message NotifyMonitoringReportRequest has been extended with a required field in VariableMonitoringType: eventNotificationType. Charging Station has to provide this field. It provides essential information to CSMS about the type of monitor (HardWiredMonitor, PreconfiguredMonitor, CustomMonitor) that was missing in OCPP 2.0.1. Existing OCPP 2.0.1 logic in a CSMS that is not aware of this new field, will continue to work.
+
+# 1.2. Terms and abbreviations
+
+This section contains the terminology and abbreviations that are used throughout this document.
+
+# 1.2.1. Terms
+
+<table><tr><td>Term</td><td>Meaning</td></tr><tr><td>Charging Station</td><td>The Charging Station is the physical system where an EV can be charged. A Charging Station has one or more EVSEs.</td></tr><tr><td>Charging Station Management System (CSMS)</td><td>Charging Station Management System: manages Charging Stations and has the information for authorizing Users for using its Charging Stations.</td></tr><tr><td>Electric Vehicle Supply Equipment (EVSE)</td><td>An EVSE is considered as an independently operated and managed part of the Charging Station that can deliver energy to one EV at a time.</td></tr><tr><td>Energy Management System (EMS)</td><td>In this document this is defined as a device that manages the local loads (consumption and production) based on local and/or contractual constraints and/or contractual incentives. It has additional inputs, such as sensors and controls from e.g. PV, battery storage.</td></tr></table>
+
+# 1.2.2. Abbreviations
+
+<table><tr><td>Term</td><td>Meaning</td></tr><tr><td>CSO</td><td>Charging Station Operator</td></tr><tr><td>CSMS</td><td>Charging Station Management System</td></tr><tr><td>EMS</td><td>Energy Management System.</td></tr><tr><td>EV</td><td>Electric Vehicle</td></tr><tr><td>EVSE</td><td>Electric Vehicle Supply Equipment</td></tr><tr><td>RFID</td><td>Radio-Frequency Identification</td></tr></table>
+
+# 1.3. References
+
+Table 1. References
+
+<table><tr><td>Reference</td><td>Description</td></tr><tr><td>[IEC61851-1]</td><td>IEC 61851-1 2017: EV conductive charging system - Part 1: General requirements. https://webstore.iec.ch/publication/33644</td></tr><tr><td>[IEC62559-2:2015]</td><td>Definition of the templates for use cases, actor list and requirements list. https://webstore.iec.ch/publication/22349</td></tr><tr><td>[ISO15118-1]</td><td>ISO 15118-1 specifies terms and definitions, general requirements and use cases as the basis for the other parts of ISO 15118. It provides a general overview and a common understanding of aspects influencing the charge process, payment and load leveling. https://webstore.iec.ch/publication/9272</td></tr><tr><td>[OCPP1.5]</td><td>http://www.openchargealliance.org/downloads/</td></tr><tr><td>[OCPP1.6]</td><td>http://www.openchargealliance.org/downloads/</td></tr></table>
+
+# Chapter 2. New functionality in OCPP 2.1
+
+OCPP 2.1 introduces new functionality compared to OCPP 2.0.1.
+
+The application logic for OCPP 2.0.1 remains valid, but will have to be extended to support the new features of OCPP 2.1.
+
+Most important new features of OCPP 2.1 include support for ISO 15118-20 and extensive support for bidirectional power transfer (V2X), and control of Charging Stations and EVs as Distributed Energy Resources (DER). New use cases have been added that describe ad hoc payment, and Charging Stations can now do local cost calculation based on tariff information from CSMS.
+
+Below is a list of sections of Part 2 of the specification that have new or updated functionality.
+
+# A Security
+
+A02/A03 A requestId has been added to SignCertificateRequest. Added support for ISO 15118-20 certificates.
+
+A05 Downgrading from security profile 3 to 2 is no longer prohibited.
+
+# B Provisioning
+
+B09 SetNetworkProfileRequest has been extended with basicAuthPassword and identity.
+
+B13 New use case to support resuming transaction after a reset.
+
+# C Authorization
+
+Length of IdToken has been extended to 255 characters.
+IdToken type is now a predefined list instead of enumeration to allow for easier extension.
+C07/C08 ISO 15118 authorization use cases updated with ISO 15118-20 flows.
+C10 Explicit requirement added about expiration in authorization cache.
+C17 New use case for authorization with prepaid card.
+C18-C23 New use cases for ad hoc payment with integrated payment terminal.
+C24 New use case for ad hoc payment via stand-alone payment terminal.
+C25 New use case for ad hoc payment via dynamic QR code.
+
+# E Transactions
+
+E16 New use case for transactions with cost, energy, time, SoC limit.
+E17 New use case for resuming a transaction after forced reboot.
+
+# F Remote Control
+
+F06 Added CustomTrigger to TriggerMessageRequest.
+F07 Net use case for remote start of transaction with limits.
+
+# G Availability
+
+Availability notification using NotifyEventRequest for component Connector is now the preferred method, instead of StatusNotification.
+
+# I Tariff and Cost
+
+Introducing local cost calculation
+
+I07-I11 New use cases to set default/user tariffs on charging station.
+I12 New use case to report calculated cost during and at end of transaction.
+
+# J Metvalues
+
+New metervalue location: Upstream.
+
+New measurands for bidirectional charging.
+
+# K Smart Charging
+
+New charging profile purposes PriorityCharging and LocalGeneration.
+Added operationMode to ChargingSchedulePeriodType to facilitate bidirectional charging scenarios.
+K01 Added dynamic charging profiles for frequent and unscheduled updates of limits.
+K23-K27 New use cases for topologies with energy management systems.
+K18-K20 New uses cases to support ISO 15118-20.
+K21-K22 New uses cases for priority charging to allow user to overrule charging profile.
+
+# M Certificate Management
+
+M01 Updated use case for ISO 15118-20.
+
+# N Diagnostics
+
+N01 Added support for data collector log on charging station.
+N02 Added monitoring types TargetDelta and TargetDeltaRelative.
+N07 Added severity to NotifyEventRequest.
+N11-14 New use cases for optimized frequent periodic variable monitoring via an event stream. This utilizes the new unconfirmed message type: SEND.
+N15 Use case to set a frequent periodic monitoring via event stream.
+
+# O Display Message
+
+001 Added multi-language support.
+
+# Q Bidirectional Power Transfer
+
+New section that describes control of bidirectional charging via charging profiles.
+Q01-Q04 V2X control with centrally controlled charging profiles.
+Q05-Q06 V2X control with externally controlled charging profiles.
+Q07-Q08 Central can local frequency control.
+Q09 Local load-balancing with V2X.
+Q10-Q12 Idle state, offline and resuming after offline.
+
+# R DER Control
+
+New section that describes grid control when EV and charging station are considered to be a Distributed Energy Resource (DER).
+
+U01 DER control in EVSE.
+U02 DER control in EV.
+U03 Hybrid DER control in both EVSE and EV.
+U04 Configure DER controls in charging station.
+U05 Charging station reporting a DER event.
+
+# S Battery Swapping
+
+New section that describes how to control a battery swap station.
+
+S01 Battery Swap Local Autorization
+S02 Battery Swap Remote Start
+S03 Battery Swap In/Out
+S04 Battery Swap Charging
+
+# Chapter 3. OCPP 2.1 Documentation Structure
+
+# 3.1. Overview of Specification Parts
+
+For readability and implementation purposes, OCPP 2.1 is divided in seven parts.
+
+Table 2. Parts
+
+<table><tr><td>Part 0</td><td>Introduction (this document)</td></tr><tr><td>Part 1</td><td>Architecture & Topology</td></tr><tr><td>Part 2</td><td>Specification:
+Use Cases and Requirements, Messages, Data Types and Referenced Components and Variables
+Appendices:
+Security Events, Standardized Units of Measure, Components and Variables</td></tr><tr><td>Part 3</td><td>Schemas</td></tr><tr><td>Part 4</td><td>Implementation Guide JSON</td></tr><tr><td>Part 5</td><td>Certification Profiles (not yet available)</td></tr><tr><td>Part 6</td><td>Test Cases (not yet available)</td></tr></table>
+
+The OCPP 2.1 specification is written using a structure, based on [IEC62559-2:2015]: "Use case methodology - Part 2: Definition of the template for use cases, actor list and requirements list".
+
+Part 2, the specification, is divided into 'Functional Blocks'. These Functional Blocks contain use cases and requirements. Messages, Data Types and Referenced Components and Variables are described at the end of the document. The Appendices can be found in the separate document: Part 2 - Appendices.
+
+# 3.2. Functional Blocks
+
+OCPP 2.1 consists of the following Functional Blocks.
+
+Table 3. Functional Blocks
+
+<table><tr><td>Clause</td><td>Functional Block Title</td><td>Description</td></tr><tr><td>A.</td><td>Security</td><td>This Functional Block describes a security specification for the OCPP protocol.</td></tr><tr><td>B.</td><td>Provisioning</td><td>This Functional Block describes all the functionalities that help a CSO provision their Charging Stations, allowing them to be registered and accepted on their network and retrieving basic configuration information from these Charging Stations.</td></tr><tr><td>C.</td><td>Authorization</td><td>This Functional Block describes all the authorization related functionality: AuthorizationRequest message handling/behavior and Authorization Cache functionality.</td></tr><tr><td>D.</td><td>Local Authorization List Management</td><td>This Functional Block describes functionality for managing the Local Authorization List.</td></tr><tr><td>E.</td><td>Transactions</td><td>This Functional Block describes the basic OCPP Transaction related functionality for transactions that are started/stopped on the Charging Station.</td></tr><tr><td>F.</td><td>Remote Control</td><td>This Functional Block describes three types of use cases for remote control management from the CSMS: Remote Transaction Control, Unlocking a Connector and Remote Trigger.</td></tr><tr><td>G.</td><td>Availability</td><td>This functional Block describes the functionality of sending status notification messages.</td></tr><tr><td>H.</td><td>Reservation</td><td>This Functional Block describes the reservation functionality of a Charging Station.</td></tr><tr><td>I.</td><td>Tariff and Cost</td><td>This Functional Block provides tariff and cost information to an EV Driver, when a Charging Station is capable of showing this on a display. Before a driver starts charging tariff information needs to be given, detailed prices for all the components that make up the tariff plan applicable to this driver at this Charging Station. During charging the EV Driver needs to be shown the running total cost, updated at a regular, fitting interval. When the EV Driver stops charging the total cost of this transaction needs to be shown.</td></tr><tr><td>J.</td><td>Metering</td><td>This Functional Block describes the functionality for sending meter values, on a periodic sampling and/or clock-aligned timing basis.</td></tr><tr><td>K.</td><td>Smart Charging</td><td>This Functional Block describes all the functionality that enables the CSO (or indirectly a third party) to influence the charging current/power of a charging session, or set limits to the amount of power/current a Charging Station can offer to an EV.</td></tr><tr><td>L.</td><td>Firmware Management</td><td>This Functional Block describes the functionality that enables a CSO to update the firmware of a Charging Station.</td></tr><tr><td>M.</td><td>Certificate Management</td><td>This Functional Block provides the installation and update of certificates.</td></tr><tr><td>N.</td><td>Diagnostics</td><td>This Functional Block describes the functionality that enables a CSO to request and track the upload of a diagnostics file from a Charging Station, and to manage the monitoring of Charging Station data.</td></tr><tr><td>O.</td><td>Display Message</td><td>With the DisplayMessage feature OCPP enables a CSO to display a message on a Charging Station, that is not part of the firmware of the Charging Station. The CSO gets control over these messages: the CSO can set, retrieve (get), replace and clear messages.</td></tr><tr><td>P.</td><td>Data Transfer</td><td>This Functional Block describes the functionality that enables a party to add custom commands to OCPP, enabling custom extension to OCPP.</td></tr><tr><td>Q</td><td>Bidirectional Power Transfer</td><td>This Functional block extends Smart Charging with bidirectional power transfer (V2X).</td></tr><tr><td>R</td><td>DER Control</td><td>This Functional Block describes how charging stations and EVs can be controlled as Distributed Energy Resources. It provides functions to configure grid code parameters on a charging station via CSMS. It is designed to support DER settings from IEC 61850 and IEEE 2030.5 on the grid side, and ISO 15118-20 Amendment 1 on the EV side.</td></tr><tr><td>S</td><td>Battery Swapping</td><td>This Functional block describes how to deal with battery swap stations in OCPP and adds the BatterySwap message.</td></tr></table>
+
+# 3.3. All Functional Blocks and use cases
+
+The following table shows the full list of use cases supported by OCPP 2.1 and which use cases were already supported by OCPP 1.6 [OCPP1.6] and OCPP 2.1.
+
+<table><tr><td>Clause</td><td>Functional Block</td><td>UC ID</td><td>Use case name</td><td>OCPP 1.6</td><td>New in OCPP 2.0.1</td><td>New in OCPP 2.1</td></tr><tr><td>A</td><td>Security</td><td>A01</td><td>Update Charging Station Password for HTTP Basic Authentication</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>A02</td><td>Update Charging Station Certificate by request of CSMS</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>A03</td><td>Update Charging Station Certificate initiated by the Charging Station</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>A04</td><td>Security Event Notification</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>A05</td><td>Upgrade Charging Station Security Profile</td><td></td><td>o</td><td></td></tr><tr><td>B</td><td>Provisioning</td><td>B01</td><td>Cold Boot Charging Station</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>B02</td><td>Cold Boot Charging Station - Pending</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>B03</td><td>Cold Boot Charging Station - Rejected</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>B04</td><td>Offline Behavior Idle Charging Station</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>B05</td><td>Set Variables</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>B06</td><td>Get Variables</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>B07</td><td>Get Base Report</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>B08</td><td>Get Custom Report</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>B09</td><td>Setting a new NetworkConnectionProfile</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>B10</td><td>Migrate to new CSMS</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>B11</td><td>Reset - Without Ongoing Transaction</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>B12</td><td>Reset - With Ongoing Transaction</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>B13</td><td>Reset - With Ongoing Transaction - Resuming Transaction</td><td></td><td></td><td>o</td></tr><tr><td>C</td><td>Authorization</td><td>C01</td><td>EV Driver Authorization using RFID</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>C02</td><td>Authorization using a start button</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>C03</td><td>Authorization using credit/debit card</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>C04</td><td>Authorization using PIN-code</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>C05</td><td>Authorization for CSMS initiated transactions</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>C06</td><td>Authorization using local id type</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>C07</td><td>Authorization using Contract Certificates</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>C08</td><td>Authorization at EVSE using ISO 15118 External Identification Means (EIM)</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>C09</td><td>Authorization by GroupId</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>C10</td><td>Store Authorization Data in the Authorization Cache</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>C11</td><td>Clear Authorization Data in Authorization Cache</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>C12</td><td>Start Transaction - Cached Id</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>C13</td><td>Offline Authorization through Local Authorization List</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>C14</td><td>Online Authorization through Local Authorization List</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>C15</td><td>Offline Authorization of unknown Id</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>C16</td><td>Stop Transaction with a Master Pass</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>C17</td><td>Authorization with prepaid card</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>C18</td><td>Authorization using locally connected payment terminal</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>C19</td><td>Cancelation prior to transaction</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>C20</td><td>Cancelation after start of transaction, before costs have been incurred.</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>C21</td><td>Settlement at end of transaction</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>C22</td><td>Settlement is rejected or fails</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>C23</td><td>Increasing authorization amount</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>C24</td><td>Ad hoc payment via stand-alone payment terminal</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>C25</td><td>Ad hoc payment via static or dynamic QR code</td><td></td><td></td><td>o</td></tr><tr><td>D</td><td>LocalAuthorizationList</td><td>D01</td><td>Send Local Authorization List</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>D02</td><td>Get Local List Version</td><td>o</td><td></td><td></td></tr><tr><td>E</td><td>Transactions</td><td>E01</td><td>Start Transaction Options</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>E02</td><td>Start Transaction - Cable Plugin First</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>E03</td><td>Start Transaction - IdToken First</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>E04</td><td>Transaction started while Charging Station is offline</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>E05</td><td>Start Transaction - Id not Accepted</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>E06</td><td>Stop Transaction Options</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>E07</td><td>Transaction locally stopped by IdToken</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>E08</td><td>Transaction stopped while Charging Station is offline</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>E09</td><td>When cable disconnected on EV-side: Stop Transaction</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>E10</td><td>When cable disconnected on EV-side: Suspend Transaction</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>E11</td><td>Connection Loss During Transaction</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>E12</td><td>Inform CSMS of an Offline Occurred Transaction</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>E13</td><td>Transaction related message not accepted by CSMS</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>E14</td><td>Check transaction status</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>E15</td><td>End of charging process</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>E16</td><td>Transactions with fixed cost, energy, SoC or time</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>E17</td><td>Resuming transaction after forced</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>E18</td><td>Battery Swapping</td><td></td><td></td><td>o</td></tr><tr><td>F</td><td>RemoteControl</td><td>F01</td><td>Remote Start Transaction - Cable Plugin First</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>F02</td><td>Remote Start Transaction - Remote Start First</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>F03</td><td>Remote Stop Transaction</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>F04</td><td>Remote Stop ISO 15118 charging from CSMS</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>F05</td><td>Remotely Unlock Connector</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>F06</td><td>Trigger Message</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>F07</td><td>Remote start with fixed cost, energy or time</td><td></td><td></td><td>o</td></tr><tr><td>G</td><td>Availability</td><td>G01</td><td>Status Notification</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>G02</td><td>Heartbeat</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>G03</td><td>Change Availability EVSE</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>G04</td><td>Change Availability Charging Station</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>G05</td><td>Lock Failure</td><td>o</td><td></td><td></td></tr><tr><td>H</td><td>Reservation</td><td>H01</td><td>Reservation</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>H02</td><td>Cancel Reservation</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>H03</td><td>Use a reserved EVSE</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>H04</td><td>Reservation Ended, not used</td><td>o</td><td></td><td></td></tr><tr><td>I</td><td>Tariff and Costs</td><td>I01</td><td>Show EV Driver-specific tariff information</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>I02</td><td>Show EV Driver running total cost during charging</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>I03</td><td>Show EV Driver final total cost after charging</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>I04</td><td>Show fallback tariff information</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>I05</td><td>Show fallback total cost message</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>I06</td><td>Update Tariff Information During Transaction</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>I07</td><td>Local Cost Calculation - Set Default Tariff</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>I08</td><td>Local Cost Calculation - Receive User Tariff</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>I09</td><td>Local Cost Calculation - Get Tariffs</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>I10</td><td>Local Cost Calculation - Clear Tariffs</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>I11</td><td>Local Cost Calculation - Change transaction tariff</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>I12</td><td>Local Cost Calculation - Cost Details of Transaction</td><td></td><td></td><td>o</td></tr><tr><td>J</td><td>Metering</td><td>J01</td><td>Sending Meter Values not related to a transaction</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>J02</td><td>Sending transaction related Meter Values</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>J03</td><td>Charging Loop with metering information exchange</td><td></td><td>o</td><td></td></tr><tr><td>K</td><td>SmartCharging</td><td>K01</td><td>SetChargingProfile</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>K02</td><td>Central Smart Charging</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>K03</td><td>Local Smart Charging</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>K04</td><td>Internal Load Balancing</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>K05</td><td>Remote Start Transaction with Charging Profile</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>K06</td><td>Offline Behavior Smart Charging During Transaction</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>K07</td><td>Offline Behavior Smart Charging at Start of Transaction</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>K08</td><td>Get Composite Schedule</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>K09</td><td>Get Charging Profiles</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>K10</td><td>Clear Charging Profile</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>K11</td><td>Set / Update External Charging Limit With Ongoing Transaction</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>K12</td><td>Set / Update External Charging Limit Without Ongoing Transaction</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>K13</td><td>Reset / release external charging limit</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>K14</td><td>External Charging Limit with Local Controller</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>K15</td><td>Charging with load leveling based on High Level Communication</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>K16</td><td>Optimized charging with scheduling to the CSMS</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>K17</td><td>Renegotiating a Charging Schedule</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>K18</td><td>ISO 15118-20 Scheduled Control Mode</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>K19</td><td>ISO 15118-20 Dynamic Control Mode</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>K20</td><td>Adjusting charging schedule when energy needs change</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>K21</td><td>Requesting priority charging remotely</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>K22</td><td>Requesting priority charging locally</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>K23</td><td>Smart Charging with EMS connected to Charging Stations</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>K24</td><td>Smart Charging with EMS connected to Local Controller</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>K25</td><td>Smart Charging with EMS acting as a Local Controller</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>K26</td><td>Smart Charging with Hybrid Local & Cloud EMS</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>K27</td><td>Smart Charging with EMS and LocalGeneration</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>K28</td><td>Dynamic charging profiles</td><td></td><td></td><td>o</td></tr><tr><td>L</td><td>Firmware Management</td><td>L01</td><td>Secure Firmware Update</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>L02</td><td>Non-Secure Firmware Update</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>L03</td><td>Publish Firmware file on Local Controller</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>L04</td><td>Unpublish Firmware file on Local Controller</td><td></td><td>o</td><td></td></tr><tr><td>M</td><td>Certificate Management</td><td>M01</td><td>Certificate Installation EV</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>M02</td><td>Certificate Update EV</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>M03</td><td>Retrieve list of available certificates from a Charging Station</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>M04</td><td>Delete a specific certificate from a Charging Station</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>M05</td><td>Install CA certificate in a Charging Station</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>M06</td><td>Get Charging Station Certificate status</td><td></td><td>o</td><td></td></tr><tr><td>N</td><td>Diagnostics</td><td>N01</td><td>Retrieve Log Information</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>N02</td><td>Get Monitoring report</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>N03</td><td>Set Monitoring Base</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>N04</td><td>Set Variable Monitoring</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>N05</td><td>Set Monitoring Level</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>N06</td><td>Clear / Remove Monitoring</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>N07</td><td>Alert Event</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>N08</td><td>Periodic Event</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>N09</td><td>Get Customer Information</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>N10</td><td>Clear Customer Information</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>N11</td><td>Set Frequent Periodic Variable Monitoring</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>N12</td><td>Get Periodic Event Streams</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>N13</td><td>Close Periodic Event Streams</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>N14</td><td>Adjust Periodic Event Streams</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>N15</td><td>Periodic Event Streams</td><td></td><td></td><td>o</td></tr><tr><td>O</td><td>Display Message</td><td>001</td><td>Set DisplayMessage</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>002</td><td>Set DisplayMessage for Transaction</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>003</td><td>Get All DisplayMessages</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>004</td><td>Get Specific DisplayMessages</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>005</td><td>Clear a DisplayMessage</td><td></td><td>o</td><td></td></tr><tr><td></td><td></td><td>006</td><td>Replace DisplayMessage</td><td></td><td>o</td><td></td></tr><tr><td>P</td><td>DataTransfer</td><td>P01</td><td>Data Transfer to the Charging Station</td><td>o</td><td></td><td></td></tr><tr><td></td><td></td><td>P02</td><td>Data Transfer to the CSMS</td><td>o</td><td></td><td></td></tr><tr><td>Q</td><td>Bidirectional Power Transfer</td><td>Q01</td><td>V2X Authorization</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>Q02</td><td>Charging only (V2X control) before starting V2X</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>Q03</td><td>Central V2X control with charging schedule</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>Q04</td><td>Central V2X control with dynamic CSMS setpoint</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>Q05</td><td>External V2X setpoint control with a charging profile from CSMS</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>Q06</td><td>External V2X control with a charging profile from an External System</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>Q07</td><td>Central V2X control for frequency support</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>Q08</td><td>Local V2X control for frequency support</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>Q09</td><td>Local V2X control for load balancing</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>Q10</td><td>Idle, minimizing energy consumption</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>Q11</td><td>Going offline during V2X operation</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>Q12</td><td>Resuming a V2X operation after an offline period</td><td></td><td></td><td>o</td></tr><tr><td>R</td><td>DER Control</td><td>R01</td><td>Starting a V2X session with DER control in EVSE</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>R02</td><td>Starting a V2X session with DER control in EV</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>R03</td><td>Starting a V2X session with hybrid DER control in both EV and EVSE</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>R04</td><td>Configure DER control settings at Charging Station</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>R05</td><td>Charging station reporting a DER event</td><td></td><td></td><td>o</td></tr><tr><td>S</td><td>Battery Swapping</td><td>S01</td><td>Battery swap local authorization</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>S02</td><td>Battery swap remote start</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>S03</td><td>Battery swap in/out</td><td></td><td></td><td>o</td></tr><tr><td></td><td></td><td>R04</td><td>Battery swap charging</td><td></td><td></td><td>o</td></tr></table>
+
+# NOTE
+
+OCPP is used in many different regions and for many different charging solutions. Not all functionalities offered by OCPP will be applicable to all implementations. Implementers can decide what specific functionalities apply to their charging solution.
+
+For interoperability purposes, the Open Charge Alliance introduces Certification Profiles in Part 5 of the specification.
+
+# Chapter 4. Basic implementation of OCPP 2.1
+
+This section is informative.
+
+The OCPP protocol describes a large number of use cases and messages, which are not all needed to implement a basic Charging Station or CSMS. The table below lists messages that are typically implemented to deliver basic functionality for an OCPP managed Charging Station. The purpose of this list is to guide developers that are new to OCPP.
+
+The basic implementation set for OCPP 2.1 is the same as for OCPP 2.0.1.
+
+# NOTE
+
+this table does not define what needs to be done to become OCPP 2.1 "certified". The functionality that is to be implemented to become OCPP 2.1 certified is described in Part 5 of the specification, "Certification Profiles".
+
+Table 4. OCPP 2.1 Basic Implementation
+
+<table><tr><td>Functionality</td><td>Use cases</td><td>Messages</td></tr><tr><td>Booting a Charging Station</td><td>B01-B04</td><td>BootNotification</td></tr><tr><td>Configuring a Charging Station</td><td>B05-B07</td><td>SetVariables, GetVariables and GetReportBase (respond correctly to requests with reportBase = ConfigurationInventory, FullInventory and SummaryInventory).</td></tr><tr><td>Resetting a Charging Station</td><td>B11-B12</td><td>Reset</td></tr><tr><td>Authorization options</td><td>One of C01, C02 and C04</td><td>Authorization</td></tr><tr><td>Transaction mechanism</td><td>E01 (one of S1-S6), E02-E03, E05, E06 (one of S1-S6), E07-E08, One of E09-E10, E11-E13</td><td>TransactionEvent</td></tr><tr><td>Availability</td><td>G01, G03-G04</td><td>Only ChangeAvailability and StatusNotification.</td></tr><tr><td>Monitoring Events</td><td>G05, N07</td><td>A basic implementation of the NotifyEvent message to be used to report operational state changes and problem/error conditions of the Charging Station, e.g. for Lock Failure. Also used for reporting built-in monitoring events.</td></tr><tr><td>Sending transaction related Meter values</td><td>J02</td><td>TransactionEvent</td></tr><tr><td>DataTransfer</td><td>P01-P02</td><td>Any OCPP implementations should at least be able to reject any request for DataTransfer if no (special) functionality is implemented.</td></tr></table>
+
+# NOTE
+
+Please also refer to the section on Minimum Device Model in part 1.
--- /dev/null
+# OCPP
+
+# Table of Contents
+
+Disclaimer 1
+
+Version History 2
+
+1. Introduction. 3
+
+1.1. Goal of this document 3
+1.2. Terms and abbreviations 3
+
+2. 3-tier model 4
+
+3. Device Model: Addressing Components and Variables 5
+
+3.1. Components 5
+3.2. Variables 6
+3.3. Characteristics and Attributes 6
+3.4. Monitoring 8
+3.5. Standardized lists of Components and Variables 9
+3.6. Minimum Device Model 9
+
+4. Device Model hierarchy 11
+5. Information Model vs. Device Model 12
+6. Using OCPP for other purposes than EV charging 13
+7. Numbering 14
+
+7.1. EVSE numbering. 14
+7.2. Connector numbering 14
+7.3. Transaction IDs. 14
+
+8. Topologies supported by OCPP 15
+
+8.1. Charging Station(s) directly connected to CSMS 15
+8.2. Multiple Charging Stations connected to CSMS via Local Proxy 15
+8.3. Multiple Charging Stations connected to CSMS via Local Controller 16
+8.4. Non-OCPP Charging Stations connected to CSMS via OCPP Local Controller 16
+8.5. DSO control signals to CSMS 16
+
+9. Energy management topologies supported by OCPP 18
+
+9.1. Parallel control of charging station by CSMS and smart meter 18
+9.2. Parallel control of charging location by CSMS and EMS 18
+9.3. EMS via Local Controller 19
+9.4. EMS as man-in-the-middle 20
+9.5. Hybrid local & cloud EMS 20
+9.6. Parallel control by CSMS and EMS 21
+
+# Disclaimer
+
+Copyright © 2010 - 2025 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
+
+<table><tr><td>Version</td><td>Date</td><td>Description</td></tr><tr><td>2.1 Edition 1</td><td>2025-01-23</td><td>OCPP 2.1 Edition 1</td></tr></table>
+
+# Chapter 1. Introduction
+
+# 1.1. Goal of this document
+
+The goal of this document is to describe a number of architecture related topics for OCPP 2.1. It is not fundamentally different from the version for OCPP 2.0.1.
+
+OCPP was originally intended for two way communication between a backoffice, in OCPP the Charging Station Management System (in this document: CSMS) and a Charging Station. The protocol has become more advanced and with every new revision new functionalities and options are added. It has evolved into a protocol that can be used in different architectures for different types of Charging Stations.
+
+This document describes, in addition to the original "simple" setup CSMS $\ll$ Charging Station, a number of topologies as an additional explanation for using OCPP. Furthermore, the Device Management concept to configure and monitor any type of Charging Station, the OCPP Information Model and the 3-tier model are explained.
+
+This document is partially informative and partially normative and is not intended to limit the use of OCPP. However, it does add an explanation what kind of use of OCPP the creators of OCPP had in mind when creating this version of the specification. This document is therefore also intended to support the reader of the protocol specification in Part 2 of OCPP to understand how it can be used.
+
+# 1.2. Terms and abbreviations
+
+This section contains the terminology and abbreviations that are used throughout this document.
+
+# 1.2.1. Terms
+
+<table><tr><td>Term</td><td>Meaning</td></tr><tr><td>Charging Location</td><td>A group of one or more Charging Stations that belong together geographically or spatially.</td></tr><tr><td>Charging Station</td><td>The Charging Station is the physical system where EVs can be charged. A Charging Station has one or more EVSEs.</td></tr><tr><td>Connector</td><td>The term Connector, as used in this specification, refers to an independently operated and managed electrical outlet on a Charging Station. In other words, this corresponds to a single physical Connector. In some cases an EVSE may have multiple physical socket types and/or tethered cable/Connector arrangements (i.e. Connectors) to facilitate different vehicle types (e.g. four-wheeled EVs and electric scooters).</td></tr><tr><td>EVSE</td><td>An EVSE is considered as an independently operated and managed part of the Charging Station that can deliver energy to one EV at a time.</td></tr><tr><td>Local port Smart Meter</td><td>The local port on a Smart Meter is a port (for example serial) on a digital electricity meter that provides access to information about meter readings and usage.</td></tr></table>
+
+# 1.2.2. Abbreviations
+
+<table><tr><td>Abbreviation</td><td>Meaning</td></tr><tr><td>DSO</td><td>Distribution System Operator</td></tr><tr><td>CSO</td><td>Charging Station Operator</td></tr><tr><td>CSMS</td><td>Charging Station Management System</td></tr><tr><td>EMS</td><td>Energy Management System. In this document this is defined as a device that manages the local loads (consumption an production) based on local and/or contractual constraints and/or contractual incentives. It has additional inputs, such as sensors and controls from e.g. PV, battery storage.</td></tr><tr><td>EVSE</td><td>Electric Vehicle Supply Equipment</td></tr><tr><td>LC</td><td>Local Controller. In this document this is defined as a device that can send messages to its Charging Stations, independently of the CSMS. A typical usage for this is the local smart charging case described in the Smart Charging chapter of Part 2 of OCPP, where a Local Controller can impose charge limits on its Charging Stations.</td></tr><tr><td>LP</td><td>Local Proxy. Acts as a message router.</td></tr></table>
+
+# Chapter 2. 3-tier model
+
+This section is informative.
+
+To understand the terminology in the OCPP specification, it is important to understand the starting point of this specification. The OCPP specification uses the term Charging Station as the physical system where EVs can be charged. A Charging Station can have one or more EVSEs (Electric Vehicle Supply Equipment). An EVSE is considered as a part of the Charging Station that can deliver energy to one EV at a time. The term Connector, as used in this specification, refers to an independently operated and managed electrical outlet on a Charging Station, in other words, this corresponds to a single physical Connector. In some cases an EVSE may have multiple physical socket types and/or tethered cable/connector arrangements to facilitate different vehicle types (e.g. four-wheeled EVs and electric scooters). This setup is referred to as the 3-tier model and visualized in the figure below.
+
+
+Figure 1. 3-tier model as used in OCPP
+
+A Charging Location is a group of Charging Stations at the same place or building. This concept has no meaning in OCPP, since OCPP is about CSMS to Charging Station communication, but a Charging Location may exist as a concept in a CSMS for management and reporting purposes.
+
+# NOTE
+
+This section describes the charging infrastructure on a logical level for communication purposes. We do not wish to impose a mapping onto physical hardware. This is a manufacturer's choice. For example, the EVSE might be integrated into a Charging Station and to look as just a part of that device, but it might just as well have its own casing and live outside of the physical entity Charging Station, for example a charging plaza with 20 EVSEs and Connectors which communicates via 1 modem as 1 Charging Station to the CSMS is seen by OCPP as 1 Charging Station.
+
+# Chapter 3. Device Model: Addressing Components and Variables
+
+The Device Model refers to a generalized mechanism within OCPP to enable any model of Charging Station to report how it is build up, so it can be managed from any CSMS. To manage a Charging Station with the Device Model (i.e. "to manage a device") a number of messages and use cases is defined to configure and monitor a Charging Station in detail, without defining the structure of the Charging Station in advance. To be able do do this, OCPP provides a generalized mechanism to allow the exchange of a wide range of information about Charging Station. This version of the Device Model has the 3-tier model (Charging Station, EVSE, Connector) as its starting point, which means that any description created with the Device Model follows these three tiers. The remainder of this chapter describes how the data (and associated meta-data) looks like that can be exchanged between a Charging Station and a CSMS. The use cases and messages that are used to manage a device are not described here, but in Part 2 of the specification. This chapter only focuses on the data model.
+
+# 3.1. Components
+
+In OCPP 2.1, a Charging Station is modelled as a set of "Components", typically representing physical devices (including any external equipment to which it is connected for data gathering and/or control), logical functionality, or logical data entities.
+
+Components of different types are primarily identified by a ComponentName, that is either the name of a standardized component (see OCPP part 2c), or a custom/non-standardized component name, for new, pre-standardized equipment, vendor specific extensions, etc.
+
+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. 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 "evseld = 1". In the same manner, Connector 1 on EVSE 1 is represented by the component named "Connector" (no instance name) with "evseld = 1, connectorld = 1".
+
+By default, all components are located at the ChargingStation tier, but individual instances of any component can be associated with a specific EVSE, or a specific Connector (on a specific EVSE) by including EVSE or EVSE and Connector identification numbers as part of a component addressing reference.
+
+Additionally, there can be more than one instance of a component (in the functional dimension), representing multi-occurrence physical or logical components (e.g. power converter modules, fan banks, resident firmware images, etc.).
+
+Each distinct component instance is uniquely identified by an (optional) componentInstance addressing key. When no
+
+componentInstance is provided, then the default or only instance of a component is referenced.
+
+Components do not in themselves hold data: all externally accessible data associated with each component instance is represented by a set of variables that can be read, set, and/or monitored for changes. The relationship of a Component with one or more Variables is illustrated in below.
+
+
+Figure 2. Component and variables
+
+The table below illustrates some common components (by their standardized component-names), and examples of the hierarchical location levels at which they typically occur for a basic home charger and a typical public Charging Station.
+
+<table><tr><td colspan="3">Basic home charger example configuration</td></tr><tr><td>ChargingStation tier</td><td>EVSE tier</td><td>Connector tier</td></tr><tr><td>ChargingStation (itself, as a whole)</td><td>EVSE (itself, as a whole)</td><td>Connector (itself, as a whole)</td></tr><tr><td>RadioLink</td><td>ControlMetering</td><td>PlugRetentionLock</td></tr><tr><td>TokenReader</td><td>OverCurrentBreaker</td><td></td></tr><tr><td>Controller</td><td>RCD</td><td></td></tr><tr><td></td><td>ChargingStatusIndicator</td><td></td></tr><tr><td colspan="3">Public Charging Station example configuration</td></tr><tr><td>ChargingStation tier</td><td>EVSE tier</td><td>Connector tier</td></tr><tr><td>ChargingStation (itself, as a whole)</td><td>EVSE (itself, as a whole)</td><td>Connector (itself, as a whole)</td></tr><tr><td>ElectricalFeed</td><td>ElectricalFeed</td><td>AccessProtection</td></tr><tr><td>TokenReader</td><td>TokenReader</td><td>PlugRetentionLock</td></tr><tr><td>Display</td><td>Display</td><td></td></tr><tr><td>FiscalMetering</td><td>FiscalMetering</td><td></td></tr><tr><td>Clock</td><td>ControlMetering</td><td></td></tr><tr><td>Controller</td><td>OverCurrentBreaker</td><td></td></tr><tr><td></td><td>RCD</td><td></td></tr><tr><td></td><td>ChargingStatusIndicator</td><td></td></tr></table>
+
+# 3.2. Variables
+
+Every component has a number of variables, that can, as appropriate, be used to hold, set, read, and/or report on all (externally visible) data applicable to that component, including configuration parameters, measured values (e.g. a current or a temperature) and/or monitored changes to variable values.
+
+Although many components can have associated variables that are, by their nature, specific to the component type (e.g. ConnectorType for a Connector component), there is a minimal set of standardized variables that is used to provide standardized high level event notification and state/status reporting (e.g. Problem, Active) on a global and/or selective basis, and also to report component presence, availability, etc. during the inventorying/discovery process (e.g. Available, Enabled). A Charging Station is not required to report the base variables: Present, Available and Enabled when they are readily and set to true. When a Charging Station does not report: Present, Available and/or Enabled the Central System SHALL assume them to be readily and set to true Variables can be any of a range of common general-purpose data types (boolean, integer, decimal, date-time, string), but also can have their allowable values constrained to particular ranges, enumeration lists, sets, or ordered lists.
+
+To support complex components, there can be more than one instance of any given variable name associated with any components (e.g. power converter modules reporting temperature, current, or voltage at multiple points).
+
+Each distinct variable instance is uniquely identified by an (optional) variableInstance addressing key string value. When no variableInstance is provided, then the default or only instance of a variable is referenced.
+
+# 3.3. Characteristics and Attributes
+
+Each variable, in addition to its primary ("Actual") value, can have a set of associated secondary data that is linked to the same primary variable name and variableInstance.
+
+This greatly avoids cluttering the variables namespace with confusing clusters of ancillary variable names (e.g. FanSpeed, FanSpeedUnits, MinimumFanSpeed, BaseFanSpeed) that lack consistence and discoverability.
+
+The ancillary variable data includes:
+
+- Variable characteristics meta-data (read-only)
+
+。Unit of measure (V,W,kW,kWh,etc.)
+。Data type (Integer, Decimal, String, Date, OptionList, etc.)
+。Lower limit
+。Upper limit
+。List of allowed values for enumerated variables
+
+Variable attributes (read-write):
+
+。Actual value
+。Target value
+。Configured lower limit
+。Configured upper limit
+。Mutability (whether the value can be altered or not, e.g. ReadOnly orReadWrite)
+. Persistence (whether the value is preserved in case of a reboot or power loss)
+
+The relationship of a Variable with one or more VariableAttributes is illustrated in the figure below.
+
+
+Figure 3. Variable attributes and characteristics
+
+There is a difference between how to implement (physical) devices and (virtual) controller components, using the DeviceModel. A (virtual) controller component has to be implementing as described in part 2 chapter the "Referenced Components and Variables". These kind of components/variables are only using the variableAttribute type 'Actual'. Depending on if this variableAttribute is writable, the CSMS can use this to set a new value.
+
+(Physical) devices are a bit more complex to implement. For example, there is a fan with a fan speed, that has a (physical) limit with a range of 0 - 1000. But it should not be allowed to set the value below 200, because the fan can stop functioning. And it should not be set above 500, because that would be bad for the fan on the long run. When implementing this device using the DeviceModel, it can be defined as follows:
+
+<table><tr><td>Component</td><td>name</td><td>Fan</td><td></td></tr><tr><td rowspan="13">Variable</td><td>name</td><td>FanSpeed</td><td></td></tr><tr><td rowspan="3">variableAttribute 1</td><td>type</td><td>Actual</td></tr><tr><td>value</td><td><The current fan speed value of the fan.></td></tr><tr><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="3">variableAttribute 2</td><td>type</td><td>Target</td></tr><tr><td>value</td><td><The CSMS can use this value to adjust the fan speed. The Charging Station SHALL try to keep the actual value at the target value.></td></tr><tr><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableAttribute 3</td><td>type</td><td>MaxSet</td></tr><tr><td>value</td><td><The value '500' from the example. The target may not be set above this value.></td></tr><tr><td rowspan="2">variableAttribute 4</td><td>type</td><td>MinSet</td></tr><tr><td>value</td><td><The value '200' from the example. The target may not be set below this value.></td></tr><tr><td rowspan="2">variableCharacteristics</td><td>maxLimit</td><td><The value '1000' from the example. This could be the physical max limit of the fan.></td></tr><tr><td>minLimit</td><td><The value '0' from the example. This could be the physical min limit of the fan. This could also be -1000, if the fan is also able to rotate in the other direction.></td></tr><tr><td>Description</td><td colspan="3">This is an example of how a fan could be defined using the DeviceModel.</td></tr></table>
+
+When trying to set the target with value 600, the Charging Station will first check the allowed min and max values/limits and reject the set. If the target value is set to 500, the value is within range and the Charging Station will allow the set and start to adjust the actual fan speed. If the actual fan speed is measured to be 502, it's out of range. But it should be reported to the CSMS, so the actual value of a physical component should be updated without checking the min and max values/limits.
+
+# 3.4. Monitoring
+
+(Updated in OCPP 2.1)
+
+Optional monitoring settings can be associated with a variable, that allow changes to variable (Actual) values are to be reported to the CSMS as event notifications.
+
+These include:
+
+Monitoring value
+Monitoring type: upper threshold, lower threshold, delta, periodic
+
+- Severity level when reporting the event
+
+The following table show which MonitorType/dataType combinations are possible.
+
+<table><tr><td></td><td>string</td><td>decimal</td><td>integer</td><td>dateTime</td><td>boolean</td><td>OptionList</td><td>SequenceList</td><td>MemberList</td></tr><tr><td>UpperThresh old</td><td></td><td>X</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>LowerThresh old</td><td></td><td>X</td><td>X</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Delta</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td></tr><tr><td>Periodic</td><td>X</td><td>X</td><td>X</td><td></td><td>X</td><td>X</td><td>X</td><td>X</td></tr><tr><td>PeriodicCloc kAligned</td><td>X</td><td>X</td><td>X</td><td></td><td>X</td><td>X</td><td>X</td><td>X</td></tr><tr><td>TargetDelta</td><td>X</td><td>X</td><td>X</td><td></td><td>X</td><td>X</td><td>X</td><td>X</td></tr><tr><td>TargetDeltaR elative</td><td>X</td><td>X</td><td>X</td><td></td><td>X</td><td>X</td><td>X</td><td>X</td></tr></table>
+
+- For UpperThreshold and LowerThreshold the value represents the to be exceeded value by the actual value of the variable.
+- For Delta this value represents the change in value compared to the actual value from the moment the monitor was set.
+
+When thedataType of the variable is integer or decimal, this value represents the absolute difference to be reached to trigger the monitor.
+。When thedataType of the variable is DateTime the unit of measure will be in seconds.
+When the dataType of the variable is string, boolean, OptionList, SequenceList or MemberList, this value is ignored. The monitor will be triggered by every change in the actual value.
+
+- When a delta monitor is triggered OR when the Charging Station has rebooted, the Charging Station shall set a new momentary value.
+- For Periodic and PeriodicClockAligned the value represents the interval in seconds.
+- For TargetDelta this value represents the absolute difference between the variableAttributes "Actual" and "Target" (calculated as Actual - Target).
+- For TargetDeltaRelative this value represents the relative deviation of the "Actual" variableAttribute with respect to the "Target" variableAttribute (calculated as the absolute value of (Actual - Target) / Target).
+
+The relationship between a Variable and one or more VariableMonitoring elements is illustrated in the figure below.
+
+
+Figure 4. Variables and monitoring
+
+# 3.5. Standardized lists of Components and Variables
+
+To provide some level of interoperability between different Charging Stations and CSMSs, besides the above defined model of Components and Variables, part 2 - appendices of the OCPP specification provides a list of standardized names for Components and Variables. The idea of this lists is to make sure that if a Charging Station and CSMS want to exchange information about a component, they both use the same name and description if it is listed in the OCPP specification. For names of a Components or Variables that are not listed in the specification, bilateral appointments between Charging Station manufacturer and CSMS are to be made. In these cases it is advised to provide feedback to the Open Charge Alliance to be able to include new/additional Components and Variables in new versions of OCPP.
+
+# 3.6. Minimum Device Model
+
+Since the Device Model is a generalized mechanism which can be applied to any model of Charging Station, the complexity of different implementations can vary. It consists of a number of use cases and messages that are not all required. This section describes the minimum part of the Device Model that needs to be implemented to create a working implementation of OCPP 2.1.
+
+The Device Model introduces Components and Variables that can be used for configuring and monitoring a Charging Station. A number of these Components and Variables are included in the list of Referenced Components and Variables (grouped by Functional Block) in Part 2 of the specification. When implementing a Functional Block, ALL required Configuration Variables that belong to a Functional Block SHALL be implemented. The required Configuration Variables from the General section SHALL also be implemented for all implementations of OCPP 2.1.
+
+The following table describes which messages are required to implement for use cases that are part of the Device Model implementation.
+
+<table><tr><td colspan="2">Use cases / messages that are part of a minimum Device Model implementation</td></tr><tr><td>Use case</td><td>Messages</td></tr><tr><td>B05 Set Variables</td><td>SetVariables message MUST be implemented</td></tr><tr><td>B06 Get Variables</td><td>GetVariables message MUST be implemented.</td></tr><tr><td>B07 Get Base Report</td><td>GetBaseReport message MUST be implemented and MUST support ConfigurationInventory and FullInventory. The content of these reports depends on the implementation of the Charging Station. It is up to the implementer to decide which components and variables exist in the implementation.</td></tr><tr><td colspan="2">Additional use cases / messages that are not part of a minimum Device Model implementation</td></tr><tr><td>Use case</td><td>Messages</td></tr><tr><td>B08 Get Custom Report</td><td>GetCustomReport message is optional.</td></tr><tr><td>N02 Get Monitoring Report</td><td>GetMonitoringRequest message is optional.</td></tr><tr><td>N03 Set Monitoring Base</td><td>SetMonitoringBaseRequest message is optional.</td></tr><tr><td>N04 Set Variable Monitoring</td><td>SetVariableMonitoringRequest message is optional.</td></tr><tr><td>N05 Set Monitoring Level</td><td>SetMonitoringLevelRequest message is optional.</td></tr><tr><td>N06 Clear/Remove Monitoring</td><td>ClearVariableMonitoringRequest message is optional.</td></tr><tr><td>N07 Alert Event</td><td>it is RECOMMENDED that NotifyEventRequest is implemented in the Charging Station even when monitoring is not implemented, so that this can be used to report built-in monitoring events.</td></tr><tr><td>N08 Periodic Event</td><td>see N07.</td></tr></table>
+
+# Chapter 4. Device Model hierarchy
+
+(New in OCPP 2.1)
+
+The 3-tier model of the Device Model does not suffice to represent the hierarchy of Charging Stations with a lot of components. If there is a need to represent a hierarchy between components, then a set of standard variables can be used for this. To allow comprehensive rendering of its components in a UI, a Charging Station may describe the hierarchy of its components using the following read-only variables:
+
+- CommunicationParent (data flow source),
+- ElectricalParent (power flow source),
+- LogicalParent (for a comprehensive overview),
+- PhysicalParent (container).
+
+These variables point to one or more (using multiple instances of these variables) parent components. Since the Device Model does not permit duplicate component names and instances, which might occur in a hierarchy, the optional read-only variable "Label" permits specifying a non-unique label to use instead of the component name and instance in a hierarchical rendering.
+
+See Part 2 of this specification for details on these variables.
+
+
+Figure 5. Example of hierarchy in device model
+
+# Chapter 5. Information Model vs. Device Model
+
+As described above, the terms Information Model and Device Model refer to different concepts. The Information Model refers to a model of the information structure upon which the messages and datatypes in OCPP are based, whereas the Device Model refers to a generalized mechanism within OCPP to enable any model of Charging Station to report how it is build up so, it can be managed from any CSMS without defining the structure of the Charging Station in advance.
+
+# Chapter 6. Using OCPP for other purposes than EV charging
+
+As indicated in the introduction of this document, OCPP is primarily intended for two way communication between a CSMS and a Charging Station. However, with the addition of the Device Model as described in the chapter Device Model, OCPP can additionally be used for other purposes. For example, the reporting of Events or Status changes in transformers or stand-alone battery packs might also be useful for companies that are rolling out EV charging infrastructure. In this example, a BootNotification could be used to connect these devices to a management system. In the device model a device that is not a Charging Station, can be recognized by the fact that the component Charging Station is not present at the top level. At the moment the OCPP specification does not provide use cases for non Charging Station devices. However, they may be added in a future version of OCPP.
+
+# Chapter 7. Numbering
+
+This section is normative.
+
+# 7.1. EVSE numbering
+
+To enable the CSMS to address all the EVSEs of a Charging Station, EVSEs MUST always be numbered in the same way.
+
+EVSEs numbering (evselds) MUST be as follows:
+
+- The EVSEs MUST be sequentially numbered, starting from 1 at every Charging Station (no numbers may be skipped).
+- evselds MUST never be higher than the total number of EVSEs of a Charging Station
+- For operations initiated by the CSMS, evseld 0 is reserved for addressing the entire Charging Station.
+- For operations initiated by the Charging Station (when reporting), evseld 0 is reserved for the Charging Station main controller.
+
+Example: A Charging Station with 3 EVSEs: All EVSEs MUST be numbered with the IDs: 1, 2 and 3. It is advisable to number the EVSEs of a Charging Station in a logical way: from left to right, top to bottom incrementing.
+
+# 7.2. Connector numbering
+
+To enable the CSMS to address all the Connectors of a Charging Station, Connectors MUST always be numbered in the same way.
+
+Connector numbering (connectorlds) MUST be as follows:
+
+- The connectors are numbered (increasing) starting at connectorld 1 on every EVSE
+- Every connector per EVSE has a unique number
+- ID of the first Connector of an EVSE MUST be 1
+ Additional Connectors of the same EVSE MUST be sequentially numbered (no numbers may be skipped)
+- connectorlds MUST never be higher than the total number of connectors on that EVSE
+
+Example: A Charging Station with 3 EVSEs that each have 2 connectors, is numbered as follows:
+
+- EVSE 1 has connectors with connectorld 1 and 2
+- EVSE 2 has connectors with connectorld 1 and 2
+- EVSE 3 has connectors with connectorld 1 and 2
+
+# 7.3. Transaction IDs
+
+TransactionIds are now generated by the Charging Station and MUST be unique on this Charging Station for every started transaction.
+
+In OCPP 1.x this was done by the CSMS.
+
+The format of the transaction ID is left to implementation. This MAY for example be an incremental number or an UUID.
+
+# Chapter 8. Topologies supported by OCPP
+
+This chapter shows a number of topologies for using OCPP. As indicated in the introduction, OCPP was originally used for a setup where each Charging Station communicates directly with the CSMS. It is important to keep in mind that OCPP has no knowledge of the topology of the Charging Station network. The following figure shows an example of a more complex topology where OCPP is used between CSMS, Local Controller and Charging Station, and other protocols are being used between EMS (Energy Management System) and Local Controller, and the smart grid meter and the Charging Station.
+
+
+Figure 6. Example of a topology with OCPP and non-OCPP components
+
+# 8.1. Charging Station(s) directly connected to CSMS
+
+# Description
+
+This is the basic setup for using OCPP.
+
+
+Figure 7. Charging Station directly connected to CSMS
+
+# 8.2. Multiple Charging Stations connected to CSMS via Local Proxy
+
+# Description
+
+In some situations it is desirable to route all communications for a group of Charging Stations through a single network node (i.e. modem, router, etc.). A typical example is the situation where a number of a Charging Stations are located in an underground parking garage with little or no access to the mobile network. In order to provide access to mobile data the Charging Stations are linked to a central data communications unit over a LAN. This central unit connects to the mobile network and acts as a proxy between CSMS and Charging Stations. Such a unit is called a "local proxy" (LP) in OCPP. A local proxy acts as a message router. Neither the CSMS nor the Charging Stations are aware of the topology of the network. For the Charging Stations in the group the local proxy "is" the CSMS. Similarly, for the CSMS the local proxy "is" the Charging Station. The diagram below illustrates this configuration.
+
+
+Figure 8. Multiple Charging Stations connected to CSMS via Local Proxy
+
+# 8.3. Multiple Charging Stations connected to CSMS via Local Controller
+
+# Description
+
+Whereas a local proxy does little more than route OCPP messages, a Local Controller can send messages to its Charging Stations, independently of the CSMS. A typical usage for this is the local smart charging case described in the Smart Charging chapter of Part 2 of OCPP, where a Local Controller can impose charge limits on its Charging Stations. In order for a Local Controller to be addressed by the CSMS, it needs to have its own Charging Station identity. From the point of view from OCPP, the Local Controller will just be a Charging Station (without any EVSEs/Connectors). The CSMS will possess the logic to deal with the Local Controller in order to support, for example, local smart charging. It is up to the implementation of the CSMS, whether the group topology is manually configured or deduced from the network based on IP addresses and information in BootNotifications. The diagram below illustrate this configuration.
+
+
+Figure 9. Multiple Charging Stations connected to CSMS via Local Controller
+
+# NOTE
+
+When a Charging Station connects to the Local Controller, the Local Controller must open a websocket connection with the same address to the CSMS. The advantage of this approach is that CSMS does not require any modification, because it does not notice that a Local Controller is in between. Still, a Local Controller can read all messages to a Charging Stations, and can act on it, for example to perform local load-balancing. It will, however, in large installations lead to a lot of websocket connections between CSMS and LC. For further information, please refer to OCPP implementation guide in Part 4.
+
+# 8.4. Non-OCPP Charging Stations connected to CSMS via OCPP Local Controller
+
+This setup has multiple non-OCPP Charging Stations that are abstracted away using a OCPP enabled Local Controller. When applying OCPP in this situation, the LC should be considered as a Charging Station with many EVSEs or the LC should act as multiple OCPP Charging Stations (having their own Charging Station Identity).
+
+
+Figure 10. Multiple non-OCPP Charging Stations connected to CSMS via Local Controller
+
+# 8.5. DSO control signals to CSMS
+
+This is a set-up in which the CSMS is the only application sending signals to a its Charging Stations, but the CSMS receives smart charging signals from a DSO based on (most likely) grid constraints. This means that a non-OCPP signal such as OpenADR or OSCP is received and based on this signal, the CSMS limits charging on its Charging Stations. CSOs that want full control over their Charging Station use this architecture, this way they are in control of the amount of energy being used by their Charging Stations. This can be done by sending charging profiles / charging schedules to Charging Stations.
+
+
+Figure 11. Smart Charging - DSO control signals to CSMS
+
+# Chapter 9. Energy management topologies supported by OCPP
+
+(New in OCPP 2.1)
+
+This chapter describes various topologies that can be used when combining an external actor for energy management with Charging Stations. The external actor can be a full-fledged (home) energy management system, often abbreviated as EMS or HEMS, but it can also be a smart meter that provides a maximum power limit. It is not meant to be an exhaustive list of possibilities, and in the future other topologies may become possible.
+
+In the diagrams the following convention is used for the connectors between components:
+
+
+
+# 9.1. Parallel control of charging station by CSMS and smart meter
+
+In this setup a Charging Station is connected to a smart meter of the grid connection for the premise. The smart meter provides a charging limit to the Charging Station, such that the power consumption of the Charging Station will be reduced if the capacity of the grid connection is about to be reached.
+
+
+Figure 12. Parallel control by CSMS and smart meter
+
+# 9.2. Parallel control of charging location by CSMS and EMS
+
+In this setup a Charging Location with one or more Charging Stations is equipped with an Energy Management System (EMS). CSMS controls the Charging Stations via OCPP, but local load-balancing on-site is controlled by the EMS. EMS will have its own connection to a Charging Station, using its own protocol, for example Modbus. If a Charging Station receives a charging constraint from EMS, then it will represent this constraint internally as an OCPP charging profile with purpose ChargingStationExternalConstraints. This charging profile is combined with other charging profiles that it might receive from CSMS. When such an external constraint is received by the Charging Station, it will immediately report this constraint to CSMS via the NotifyChargingLimitRequest message. A limitation of this topology is that EMS is not aware of OCPP information that is exchanged between Charging Station and CSMS. EMS can therefore not know who is charging at a Charging Station, or what the specific charging needs of a user are. Local balancing based on user needs (e.g. time of departure) or priorities is not possible in this topology.
+
+
+Figure 13. Parallel control by CSMS and EMS
+
+# 9.3. EMS via Local Controller
+
+The limitation of Parallel control of charging location by CSMS and EMS can be overcome with help of a Local Controller component. A Local Controller is a kind of "local CSMS" (see Multiple Charging Stations connected to CSMS via Local Controller), that uses OCPP messages to perform local load-balancing. In this topology the Energy Management System (EMS) is connected to the Local Controller. EMS treats all Charging Stations at Charging Location as a single load, and provides its constraint to the Local Controller. The Local Controller will represent this constraint internally as a ChargingStationExternalConstraints charging profile for the cluster of Charging Stations at the Charging Location. It is up to the Local Controller to divide the available capacity among the Charging Stations in the cluster. Because all OCPP traffic between Charging Station and CSMS passes through the Local Controller, it can be made aware of user needs and priorities, and use this information for intelligent scheduling. An added advantage of an on-site Local Controller is, that it can continue to function and support local load-balancing, even when connection to CSMS is lost.
+
+
+Figure 14. EMS via Local Controller
+
+# 9.4. EMS as man-in-the-middle
+
+In the topology sketched above in EMS via Local Controller it is a logical step to combine the EMS and Local Controller functionality in one box. EMS is acting as a Local Controller and is placed as a "man-in-the-middle" between CSMS and Charging Stations. An advantage of this setup is, that EMS (as part of a Local Controller) is aware of instructions coming from CSMS. This enables EMS to know about a charging limitation set by CSMS to the (cluster of) Charging Stations. Having this knowledge allows for more sophisticated energy management, because EMS can now differentiate between the situation where an EV is charging at low power because it does not need more power, and the situation where it is not allowed more power by CSMS or Local Controller.
+
+
+Figure 15. EMS as man-in-the-middle
+
+# 9.5. Hybrid local & cloud EMS
+
+The hybrid local & cloud EMS topology describes the situation where an advanced EMS is running in the cloud. This cloud EMS can have advanced scheduling algorithms and has access to external information, like weather forecasts and control signals from a
+
+DSO. Since it is running in the cloud it can even optimize across multiple sites. An EMS in the cloud will likely not be able to react fast enough to protect the local grid connection, and it will not be able to control the site when the internet connection is lost. This topology therefore adds a local EMS, whose main task is to protect the fuse of the local grid connection, to pass data with local load measurements on to the cloud EMS, and to act as a fallback when data connection to the cloud is lost. Charging Stations can connect directly to the Cloud EMS acting as a Local Controller, as shown below.
+
+
+Figure 16. Hybrid topology with cloud EMS as Local Controller
+
+Alternatively, the Local Controller function can be performed by the Local EMS. The Cloud EMS scheduling will be suboptimal, however, because in this case it is not aware of the state of ongoing transactions, unless this information is explicitly passed by Local EMS to Cloud EMS.
+
+
+Figure 17. Hybrid topology with local EMS as Local Controller
+
+# 9.6. Parallel control by CSMS and EMS
+
+(Updated in OCPP 2.1 and moved from chapter 8 to 9)
+
+# Description
+
+In a (semi-)private situation where a Charging Station is not only connected to the CSMS, but also to an Energy Management System, some form of parallel control is possible. OCPP is then used for transaction handling and management of the Charging Station, and the Energy Management System provides smart charging controls. OCPP 2.1 supports reporting external smart charging control limits. Control limits that EMS provides via its own protocol, are represented (and reported as) "ExternalConstraints" charging profiles by the Charging Station.
+
+When the Energy Management System decides to delay charging, the Energy Management System can impose an external limit (e.g. 0) to a Charging Station, which the Charging Station in turn can report to the CSMS via OCPP. The Energy Management System might get input from e.g. Local port of a Smart Meter to prevent overloading the grid connection, but can also have other reasons for not charging (e.g. weather conditions).
+
+The protocol between Charging Station and EMS is not specified. Charging limits or schedules can be provided by any means that Charging Station supports. This can also be implemented using OCPP messages. See also Part 2, section K 2.4 for some topology examples with an EMS.
+
+NOTE
+
+An OCPP message exchange between Charging Station and EMS is not a full-fledged OCPP connection in which EMS acts as the server. It is a limited solution consisting of a websocket connection over which EMS sends, for
+
+example, a SetChargingProfile message, and Charging Station sends MeterValue messages.
+
+
+Figure 18. Parallel control by CSMS and EMS
--- /dev/null
+# OCPP
+
+# Table of Contents
+
+Disclaimer 1
+
+Generic. 2
+
+Version History. 3
+
+1. Scope 4
+
+1.1. OCPP2.1 Edition 1. 4
+
+2. Conventions, Terminology and Abbreviations 5
+
+2.1. Conventions 5
+2.2. Terminology 6
+2.3. Abbreviations 9
+2.4. Actors 10
+2.5. References 12
+2.6. Definition of Transaction 14
+2.7. ISO15118 support. 14
+
+3. Generic Requirements. 16
+
+3.1. Time Format Requirements 17
+3.2. Message Timeouts 17
+3.3. Language support 17
+
+A. Security 19
+
+1. OCPP Security 20
+
+1.1. Security Objectives 20
+1.2. Design Considerations 20
+1.3. Security Profiles 21
+1.4. Keys used in OCPP 29
+1.5. Certificate Revocation 31
+1.6. Installation 31
+
+2.Use cases & Requirements. 33
+
+A01 - Update Charging Station Password for HTTP Basic Authentication 33
+A02 - Update Charging Station Certificate by request of CSMS 34
+A03 - Update Charging Station Certificate initiated by the Charging Station 39
+A04 - Security Event Notification 45
+A05 - Upgrade Charging Station Security Profile 46
+
+B.Provisioning 48
+
+1. Introduction 49
+
+1.1. Transactions before being accepted by a CSMS 49
+
+2. Use cases & Requirements. 50
+
+2.1. Booting a Charging Station 50
+B01 - Cold Boot Charging Station 50
+B02 - Cold Boot Charging Station-Pending. 53
+B03 - Cold Boot Charging Station-Rejected 55
+B04 - Offline Behavior Idle Charging Station 57
+2.2. Configuring a Charging Station 58
+B05 - Set Variables 58
+B06 - Get Variables 61
+B07 - Get Base Report. 63
+B08 - Get Custom Report 66
+B09 - Setting a new NetworkConnectionProfile. 69
+B10 - Migrate to new CSMS 73
+2.3. Resetting a Charging Station 74
+B11 - Reset-WithoutOngoingTransaction 75
+B12 - Reset - With Ongoing Transaction 78
+B13 - Reset - With Ongoing Transaction - Resuming Transaction. 81
+
+C. Authorization 85
+
+1. Introduction 86
+
+1.1. ID Tokens 86
+1.2. Group ID Tokens 86
+1.3. Authorization Cache 87
+1.4. Local Authorization List 87
+1.5. Unknown Offline Authorization 87
+1.6. Relationship between authorization and transaction 88
+
+# 2. Use cases & Requirements. 89
+
+2.1. Authorization options 89
+C01 - EV Driver Authorization using RFID 89
+C02 - Authorization using a start button. 93
+C03 - Authorization using credit/debit card 95
+C04 - Authorization using PIN-code 96
+C05 - Authorization for CSMS initiated transactions 98
+C06 - Authorization using local id type 100
+2.2. ISO 15118 Authorization. 102
+C07 - Authorization using Contract Certificates 102
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM) 106
+2.3. GroupId 109
+C09 - Authorization by GroupId 109
+2.4. Authorization Cache 111
+C10 - Store Authorization Data in the Authorization Cache 111
+C11 - Clear Authorization Data in Authorization Cache 113
+C12 - Start Transaction-Cached Id 114
+2.5. Local Authorization list 115
+C13 - Offline Authorization through Local Authorization List 115
+C14 - Online Authorization through Local Authorization List. 117
+2.6. Offline Authorization 118
+C15 - Offline Authorization of unknown Id 119
+2.7. Master Pass 121
+C16 - Stop Transaction with a Master Pass. 121
+2.8. Authorization with prepaid card 123
+C17 - Authorization with prepaid card 124
+2.9. Ad hoc payments 127
+C18 - Authorization using locally connected payment terminal 128
+C19 - Cancelation prior to transaction 131
+C20 - Cancelation after start of transaction. 133
+C21 - Settlement at end of transaction. 135
+C22 - Settlement is rejected or fails 138
+C23 - Increasing authorization amount 140
+C24 - Ad hoc payment via stand-alone payment terminal 141
+C25 - Ad hoc payment via a QR code 144
+
+# D. Local Authorization List Management 153
+
+1. Introduction 154
+2. Use cases & Requirements 155
+
+D01 - Send Local Authorization List 155
+D02 - Get Local List Version. 158
+
+# E. Transactions. 159
+
+1. Introduction 160
+
+1.1. Flexible transaction start/stop 160
+1.2. TransactionId generation 161
+1.3. Delivering transaction-related messages 161
+1.4. Authorization 162
+1.5. Clarification for optional fields in TransactionRequest 162
+
+# 2. Use cases & Requirements 164
+
+2.1. OCPP transaction mechanism 164
+E01 - Start Transaction options. 164
+E02 - Start Transaction-Cable Plugin First 171
+E03 - Start Transaction-IdTokenFirst. 176
+E04 - Transaction started while Charging Station is offline 179
+E05 - Start Transaction - ld not Accepted 182
+E06 - Stop Transaction options 185
+E07 - Transaction locally stopped by IdToken. 190
+E08 - Transaction stopped while Charging Station is offline 194
+E09 - When cable disconnected on EV-side: Stop Transaction 197
+E10 - When cable disconnected on EV-side: Suspend Transaction 200
+E11 - Connection Loss During Transaction 204
+E12 - Inform CSMS of an Offline Occurred Transaction. 206
+E13 - Transaction-related message not accepted by CSMS 208
+E14 - Check transaction status 210
+2.2. Interrupting and Stopping ISO 15118 Charging 211
+E15 - End of charging process 211
+2.3. Transactions with limits 213
+E16 - Transactions with fixed cost, energy, SoC or time 213
+2.4. Resuming transactions 217
+E17 - Resuming transaction after forced reboot 217
+
+# F. Remote Control 221
+
+1. Introduction 222
+2. Use cases & Requirements 223
+
+2.1. Remote Transaction Control 223
+F01 - Remote Start Transaction - Cable Plugin First 223
+F02 - Remote Start Transaction - Remote Start First 226
+F03 - Remote Stop Transaction 232
+F04 - Remote Stop ISO 15118 Charging from CSMS 234
+2.2. Unlock Connector 236
+F05 - Remotely Unlock Connector 236
+2.3. Remote Trigger 238
+F06 - Trigger Message 238
+F07 - Remote start with fixed cost, energy, SoC or time. 240
+
+# G. Availability 243
+
+1. Introduction 244
+2. Use cases & Requirements 245
+
+G01 - Report connector AvailabilityState 245
+G02 - Heartbeat 247
+G03 - Change Availability EVSE/Connector 249
+G04 - Change Availability Charging Station 251
+G05 - Lock Failure 253
+
+# H. Reservation 254
+
+1. Introduction 255
+2. Use cases & Requirements 256
+
+H01 - Reservation 256
+H02 - Cancel Reservation 260
+H03 - Use a reserved EVSE 261
+H04 - Reservation Ended, not used 265
+
+# I. Tariff And Cost 266
+
+1. Introduction 267
+
+1.1. Configuration Settings 267
+1.2. TariffStructures 267
+1.3. CostDetails 271
+
+# 2. Use cases & Requirements 274
+
+I01 - Show EV Driver-specific Tariff Information 274
+102 - Show EV Driver Running Total Cost During Charging 275
+103 - Show EV Driver Final Total Cost After Charging 276
+104 - Show Fallback Tariff Information 277
+I05 - Show Fallback Total Cost Message 279
+I06 - Update Tariff Information During Transaction 280
+107 - Local Cost Calculation - Set Default Tariff 281
+108 - Local Cost Calculation - Receive Driver Tariff 284
+I09 - Local Cost Calculation - Get Tariffs 290
+I10 - Local Cost Calculation - Clear Tariffs. 292
+I11 - Local Cost Calculation - Change transaction tariff 293
+I12 - Local Cost Calculation - Cost Details of Transaction 295
+
+J. Meter Values. 300
+
+1. Introduction 301
+2. Configuration 302
+
+2.1. Transaction Meter Values 302
+2.2. Clock-Aligned Meter Values 302
+2.3. Multiple Locations/Phases 303
+2.4. Signed Meter Values 303
+2.5. Configuration Examples 304
+
+3. Use cases & Requirements 305
+
+3.1. MeterValues 305
+J01 - Sending Meter Values not related to a transaction 305
+J02 - Sending transaction related Meter Values 308
+3.2. ISO 15118 MeterValue signing. 310
+J03 - Charging Loop with metering information exchange 310
+
+K. Smart Charging 312
+
+1. Introduction 313
+2. Types of Smart Charging 314
+
+2.1. Internal Load Balancing 314
+2.2. Central Smart Charging 314
+2.3. Local Smart Charging 314
+2.4. External Smart Charging Control Signals 315
+
+3. Charging profiles 317
+
+3.1. Introduction 317
+3.2. Charging profile purposes 317
+3.3. Charging profile kind 318
+3.4. Smart Charging Operation Modes 318
+3.5. Stacking charging profiles 319
+3.6. Combining Charging Profile Purposes 320
+3.7. Example Charging Profile 320
+3.8. Avoiding Phase Conflicts 322
+3.9. Using randomized delays in schedule periods 323
+
+4. Smart Charging Signals to a Charging Station from Multiple Actors 324
+
+5. Use cases & Requirements 326
+
+5.1. General Smart Charging 326
+K01 - SetChargingProfile 326
+K02 - Central Smart Charging 335
+K03 - Local Smart Charging 339
+K04 - Internal Load Balancing 343
+K05 - Remote Start Transaction with Charging Profile 344
+K06 - Offline Behavior Smart Charging During Transaction. 345
+K07 - Offline Behavior Smart Charging at Start of Transaction 347
+K08 - Get Composite Schedule 348
+K09 - Get Charging Profiles 350
+K10 - Clear Charging Profile 351
+
+5.2. External Charging Limit based Smart Charging 354
+K11 - Set / Update External Charging Limit With Ongoing Transaction 354
+K12 - Set / Update External Charging Limit Without Ongoing Transaction 356
+K13 - Reset / Release External Charging Limit 357
+K14 - External Charging Limit with Local Controller 359
+K23 - Smart Charging with EMS connected to Charging Stations. 360
+K24 - Smart Charging with EMS connected to Local Controller 362
+K25 - SmartChargingwithEMSactingasalocalController 364
+K26 - Smart Charging with Hybrid Local & Cloud EMS 366
+K27 - Smart Charging with EMS and LocalGeneration 369
+5.3. ISO 15118 based Smart Charging 373
+K15 - ISO 15118-2 Charging with load leveling 373
+K16 - Renegotiation initiated by CSMS 376
+K17 - Renegotiation initiated by EV 379
+K18 - ISO 15118-20 Scheduled Control Mode 383
+K19 - ISO 15118-20 Dynamic Control Mode 387
+K20 - ISO 15118-20 Adjusting charging schedule when energy needs change. 391
+5.4. Priority Charging 393
+K21 - Requesting priority charging remotely 393
+K22 - Requesting priority charging locally 395
+5.5. Dynamic Charging Profiles 396
+K28 - Dynamic charging profiles from CSMS 397
+K29 - Dynamic charging profiles from external system 399
+
+L. Firmware Management 403
+
+1. Introduction 404
+2. Use cases & Requirements 405
+
+L01 - Secure Firmware Update 405
+L02 - Non-Secure Firmware Update 411
+L03 - Publish Firmware file on Local Controller 416
+L04 - Unpublish Firmware file on Local Controller 418
+
+M. Certificate Management 420
+
+1. Introduction 421
+2. ISO 15118 Certificates 426
+
+2.1. ISO 15118 Certificate structure 426
+2.2. Using ISO 15118 Certificates in OCPP 427
+2.3. 15118 communication set-up 428
+2.4. Certificate - Use Case mapping 428
+
+3. Use cases from ISO 15118 relevant for OCPP. 430
+4. Use cases & Requirements 431
+
+M01 - Certificate installation EV 431
+M02 - Certificate Update EV 433
+M03 - Retrieve list of available certificates from a Charging Station 434
+M04 - Delete a specific certificate from a Charging Station 435
+M05 - Install CA certificate in a Charging Station 437
+M06 - Get V2G Charging Station Certificate status. 438
+M07 - Get Vehicle Certificate Chain Revocation Status 440
+
+N. Diagnostics 443
+
+1. Introduction 444
+2. Use cases & Requirements 445
+
+2.1. Logging 445
+N01 - Retrieve Log Information 445
+2.2. Configure Monitoring 448
+N02 - Get Monitoring report 448
+N03 - Set Monitoring Base 450
+N04 - Set Variable Monitoring 452
+N05 - Set Monitoring Level. 454
+N06 - Clear/RemoveMonitoring 455
+2.3. Monitoring Events 456
+N07 - Alert Event 456
+N08 - Periodic Event 459
+2.4. Customer Information 461
+N09 - Get Customer Information 461
+N10 - Clear Customer Information 462
+2.5. Frequent Periodic Variable Monitoring 465
+N11 - Set Frequent Periodic Variable Monitoring 465
+N12 - Get Periodic Event Streams 467
+N13 - Close Periodic Event Streams 467
+N14 - Adjust Periodic Event Streams 468
+N15 - Periodic Event Streams 469
+
+O. Display Message 472
+
+1. Introduction 473
+2. Use cases & Requirements 474
+
+001 - Set DisplayMessage 474
+002 - Set DisplayMessage for Transaction 477
+
+003 - Get All DisplayMessages 479
+004 - Get Specific DisplayMessages 481
+005 - Clear a DisplayMessage. 483
+006 - Replace DisplayMessage 484
+
+# P.DataTransfer 485
+
+1. Introduction 486
+2. Use cases & Requirements 487
+
+P01 - Data Transfer to the Charging Station 487
+P02 - Data Transfer to the CSMS 489
+
+# Q. Bidirectional Power Transfer 491
+
+1. Introduction 492
+2. Smart Charging Extensions for V2X 493
+
+2.1. Setpoint and charge/discharge limits 493
+2.2. V2X operation modes 493
+2.3. Switching V2X operation modes 498
+2.4. Residual measurand 498
+2.5. Genericsmartcharging rulesforV2X 499
+
+# 3. Use Cases & Requirements 500
+
+Q01 - V2X Authorization 500
+Q02 - Starting in operationMode ChargingOnly before enabling V2X. 504
+Q03 - Central V2X control with charging schedule 507
+Q04 - Central V2X control with dynamic CSMS setpoint 509
+Q05 - External V2X setpoint control with a charging profile from CSMS 512
+Q06 - External V2X control with a charging profile from an External System 513
+Q07 - Central V2X control for frequency support 517
+Q08 - Local V2X control for frequency support 518
+Q09 - Local V2X control for load balancing 522
+Q10 - Idle, minimizing energy consumption. 524
+Q11 - Going offline during V2X operation. 526
+Q12 - Resuming a V2X operation after an offline period 527
+
+# R.DER Control 529
+
+1. Introduction 530
+2. DER Control using OCPP and ISO 15118-20 531
+
+2.1. CSO acting as aggregator 531
+2.2. DER Control for DC bidirectional power transfer 531
+2.3. DER Control for AC bidirectional power transfer 532
+2.4. ISO15118V2G-ACinverter architecture 532
+2.5. ISO15118V2G-Split inverter architecture 532
+2.6. DER nameplate information 533
+2.7. DER controls. 533
+2.8. DER alarms 536
+2.9. Prioritizing of controls. 536
+
+# 3. Use Cases for DER control 538
+
+R01 - Starting a V2X session with DER control in EVSE 538
+R02 - Starting a V2X session with DER control in EV 541
+R03 - Starting a V2X session with hybrid DER control in both EV and EVSE 544
+R04 - Configure DER control settings at Charging Station 547
+R05 - Charging station reporting a DER event 552
+
+# S. Battery Swapping 555
+
+1. Introduction 556
+2. Availability states for a battery slot 557
+3. Use cases for Battery Swapping 558
+
+S01 - Battery Swap Local Authorization 558
+S02 - Battery Swap Remote Start 559
+S03 - Battery Swap In/Out 560
+S04 - Battery Swap Charging 562
+
+# Messages, Datatypes & Enumerations 565
+
+1. Messages 566
+
+1.1. AdjustPeriodicEventStream 566
+
+1.2. AFRRSignal. 566
+1.3. Authorization 566
+1.4. BatterySwap 567
+1.5. BootNotification. 567
+1.6. CancelReservation. 568
+1.7. CertificateSigned 568
+1.8. ChangeAvailability 569
+1.9. ChangeTransactionTariff 570
+1.10. ClearCache 570
+1.11. ClearChargingProfile 570
+1.12. ClearDERControl 571
+1.13. ClearDisplayMessage 571
+1.14. ClearedChargingLimit 572
+1.15. ClearTariffs 572
+1.16. ClearVariableMonitoring 572
+1.17. ClosePeriodicEventStream 573
+1.18. CostUpdated 573
+1.19. CustomerInformation 573
+1.20. DataTransfer 574
+1.21. DeleteCertificate 575
+1.22. FirmwareStatusNotification 575
+1.23. Get15118EVCertificate 575
+1.24. GetBaseReport. 576
+1.25. GetCertificateChainStatus 577
+1.26. GetCertificateStatus 577
+1.27. GetChargingProfiles 578
+1.28. GetCompositeSchedule 578
+1.29. GetDERControl 579
+1.30. GetDisplayMessages 579
+1.31. GetInstalledCertificates 580
+1.32. GetLocalListVersion 580
+1.33. GetLog 580
+1.34. GetMonitoringReport 581
+1.35. GetPeriodicEventStream 582
+1.36. GetReport 582
+1.37. GetTariffs 582
+1.38. GetTransactionStatus 583
+1.39. GetVariables. 583
+1.40. Heartbeat 583
+1.41. InstallCertificate 584
+1.42. LogStatusNotification 584
+1.43. MeterValues 585
+1.44. NotifyAllowedEnergyTransfer 585
+1.45. NotifyChargingLimit 586
+1.46. NotifyCustomerInformation 586
+1.47. NotifyDERAlarm. 586
+1.48. NotifyDERStartStop 587
+1.49. NotifyDisplayMessages 587
+1.50. NotifyEVChargingNeeds 588
+1.51. NotifyEVChargingSchedule 588
+1.52. NotifyEvent 589
+1.53. NotifyMonitoringReport 589
+1.54. NotifyPeriodicEventStream 590
+1.55. NotifyPriorityCharging 590
+1.56. NotifyReport 590
+1.57. NotifySettlement 591
+1.58. NotifyWebPaymentStarted 591
+1.59. OpenPeriodicEventStream 592
+1.60. PublishFirmware 592
+1.61. PublishFirmwareStatusNotification 593
+1.62. PullDynamicScheduleUpdate 593
+1.63. ReportChargingProfiles 594
+1.64. ReportDERControl 594
+1.65. RequestBatterySwap. 595
+1.66. RequestStartTransaction 595
+1.67. RequestStopTransaction 596
+1.68. ReservationStatusUpdate 596
+1.69. ReserveNow 596
+1.70. Reset 597
+1.71. SecurityEventNotification 598
+1.72. SendLocalList 598
+1.73. SetChargingProfile 598
+1.74. SetDefaultTariff 599
+1.75. SetDERControl 599
+1.76. SetDisplayMessage 600
+1.77. SetMonitoringBase 601
+1.78. SetMonitoringLevel 601
+1.79. SetNetworkProfile 602
+1.80. SetVariableMonitoring 603
+1.81. SetVariables 603
+1.82. SignCertificate 604
+1.83. StatusNotification 604
+1.84. TransactionEvent. 605
+1.85. TriggerMessage. 606
+1.86. UnlockConnector 607
+1.87. UnpublishFirmware 607
+1.88. UpdateDynamicSchedule 608
+1.89. UpdateFirmware 608
+1.90. UsePriorityCharging 609
+1.91. VatNumberValidation 609
+
+# 2. Datatypes 611
+
+2.1. AbsolutePriceScheduleType 611
+2.2. ACChargingParametersType 612
+2.3. AdditionalInfoType 612
+2.4. AdditionalSelectedServicesType 613
+2.5. AddressType 613
+2.6. APNType. 613
+2.7. AuthorizationData 614
+2.8. BatteryDataType 614
+2.9. CertificateHashDataChainType 614
+2.10. CertificateDataType 615
+2.11. CertificateStatusRequestInfoType 615
+2.12. CertificateStatusType 615
+2.13. ChargingLimitType 615
+2.14. ChargingNeedsType 616
+2.15. ChargingPeriodType 616
+2.16. ChargingProfileCriterionType 617
+2.17. ChargingProfileType 617
+2.18. ChargingSchedulePeriodType 619
+2.19. ChargingScheduleType 621
+2.20. ChargingScheduleUpdateType 623
+2.21. ChargingStationType 624
+2.22. ClearChargingProfileType 624
+2.23. ClearMonitoringResultType 625
+2.24. Clear Tariffs ResultType 625
+2.25. ComponentType 625
+2.26. ComponentVariableType 626
+2.27. CompositeScheduleType 626
+2.28. ConstantStreamDataType 626
+2.29. ConsumptionCostType 626
+2.30. CostDetailsType 627
+2.31. CostDimensionType 627
+2.32. CostType 627
+2.33. DCChargingParametersType 628
+2.34. DERChargingParametersType 628
+2.35. DERCurveGetType 633
+2.36. DERCurvePointsType 633
+2.37. DERCurveType 633
+2.38. EnterServiceGetType 634
+2.39. EnterServiceType 634
+2.40. EVAbsolutePriceScheduleEntryType 634
+2.41. EVAbsolutePriceScheduleType 635
+2.42. EVEnergyOfferType 635
+2.43. EventDataType 635
+2.44. EVPowerScheduleEntryType 636
+2.45. EVPowerScheduleType 636
+2.46. EVPriceRuleType 636
+2.47. EVSEType 637
+2.48. FirmwareType 637
+2.49. FixedPFGETYPE 637
+2.50. FixedPFType 637
+2.51. FixedVar类型的 638
+2.52. FixedVarType 638
+2.53. FreqDroopGetType 638
+2.54. FreqDroopType 638
+2.55. GetVariableDataType 639
+2.56. GetVariableResultType 639
+2.57. Gradient类型的 639
+2.58. GradientType 640
+2.59. HysteresisType 640
+2.60. IdTokenInfoType 640
+2.61. IdTokenizerType 641
+2.62. LimitAtSoCType 641
+2.63. LimitMaxDischargeGetType 641
+2.64. LimitMaxDischargeType 642
+2.65. LogParametersType 642
+2.66. MessageContentType 642
+2.67. MessageInfoType 643
+2.68. MeterValueType. 643
+2.69. ModemType 643
+2.70. MonitoringDataType 644
+2.71. NetworkConnectionProfileType 644
+2.72. OCSPRequestDataType 645
+2.73. OverstayRuleelistType 645
+2.74. OverstayRuleType 645
+2.75. PeriodicEventStreamParamsType 646
+2.76. PriceLevelScheduleEntryType 646
+2.77. PriceLevelScheduleType 646
+2.78. PriceRuleStackTrace 646
+2.79. PriceRuleType 647
+2.80. PriceType 647
+2.81. RationalNumberType 647
+2.82. ReactivePowerParamsType 648
+2.83. RelativeTimeIntervalType 648
+2.84. ReportDataType 648
+2.85. SalesTariffEntryType 648
+2.86. SalesTariffType 649
+2.87. SampledValueType 649
+2.88. SetMonitoringDataType 649
+2.89. SetMonitoringResultType 651
+2.90. SetVariableDataType 652
+2.91. SetVariableResultType 652
+2.92. SignedMeterValueType 652
+2.93. StatusInfoType 653
+2.94. StreamDataElementType 653
+2.95. TariffAssignmentType 653
+2.96. TariffConditionsFixedType 654
+2.97. TariffConditionsType 654
+2.98. TariffEnergyPriceType 656
+2.99. TariffEnergyType 656
+2.100. TariffFixedPriceType 656
+2.101. TariffFixedType 657
+2.102. TariffTimePriceType 657
+2.103. TariffTimeType 657
+2.104. TariffType 657
+2.105. TaxRateType 658
+2.106. TaxRuleType 658
+2.107. TotalCostType 659
+2.108. TotalPriceType 659
+2.109. TotalUsageType 659
+2.110. TransactionLimitType 660
+2.111. TransactionType 660
+2.112. UnitOfMeasureType 661
+2.113. V2XChargingParametersType 661
+2.114. V2XFreqWattPointType 663
+2.115. V2XSignalWattPointType 664
+2.116. Variable_ATTRIBUTEType 664
+2.117. VariableCharacteristicsType 664
+2.118. VariableMonitoringType 665
+2.119. VariableType 666
+2.120. VoltageParamsType 667
+2.121. VPNType 667
+
+# 3. Enumerations 668
+
+3.1. APNAAuthenticationEnumType 668
+3.2. AttributeEnumType 668
+3.3. AuthorizationStatusEnumType 668
+3.4. AuthorizationCertificateStatusEnumType 668
+3.5. BatterySwapEventEnumType 669
+3.6. BootReasonEnumType 669
+3.7. CancelReservationStatusEnumType 669
+3.8. CertificateActionEnumType 670
+3.9. CertificateSignedStatusEnumType 670
+3.10. CertificateSigningUseEnumType 670
+3.11. CertificateStatusEnumType 670
+3.12. CertificateStatusSourceEnumType 670
+3.13. ChangeAvailabilityStatusTypeDef 671
+3.14. ChargingProfileKindEnumType 671
+3.15. ChargingProfilePurposeEnumType 671
+3.16. ChargingProfileStatusEnumType 672
+3.17. ChargingRateUnitEnumType 672
+3.18. ChargingStateEnumType 672
+3.19. ClearCacheStatusEnumType 673
+3.20. ClearChargingProfileStatusEnumType 673
+3.21. ClearMessageStatusEnumType 673
+3.22. ClearMonitoringStatusEnumType 673
+3.23. ComponentCriterionEnumType 673
+3.24. ConnectorStatusEnumType 674
+3.25. ControlModeEnumType 674
+3.26. CostDimensionEnumType 674
+3.27. CostKindEnumType 675
+3.28. CustomerInformationStatusEnumType 675
+3.29. DataEnumType 675
+3.30. DataTransferStatusEnumType 675
+3.31. DayOfWeekEnumType 676
+3.32. DeleteCertificateStatusEnumType 676
+3.33. DERControlEnumType 676
+3.34. DERControlStatusEnumType 677
+3.35. DERUnitEnumType 677
+3.36. DisplayMessageStatusEnumType 677
+3.37. EnergyTransferModeEnumType 678
+3.38. EventNotificationEnumType 678
+3.39. EventTriggerEnumType 678
+3.40. EvseKindEnumType. 679
+3.41. FirmwareStatusEnumType 679
+3.42. GenericDeviceModelStatusEnumType 680
+3.43. GenericStatusEnumType 680
+3.44. GetCertificateldUseEnumType 680
+3.45. GetCertificateStatusEnumType 680
+3.46. GetChargingProfileStatusEnumType 681
+3.47. GetDisplayMessagesStatusEnumType 681
+3.48. GetInstalledCertificateStatusEnumType 681
+3.49. GetVariableStatusEnumType 681
+3.50. GridEventFaultEnumType 681
+3.51. HashAlgorithmEnumType 682
+3.52. InstallCertificateStatusEnumType 682
+3.53. InstallCertificateUseEnumType 682
+3.54. IslandingDetectionEnumType 682
+3.55. Iso15118EVCertificateStatusEnumType 683
+3.56. LocationEnumType 683
+3.57. LogEnumType 684
+3.58. LogStatusEnumType 684
+3.59. MeasurandEnumType 684
+3.60. MessageFormatEnumType 686
+3.61. MessagePriorityEnumType 687
+3.62. MessageStateEnumType 687
+3.63. MessageTriggerEnumType 687
+3.64. MobilityNeedsModeEnumType 688
+3.65. MonitorEnumType 688
+3.66. MonitoringBaseEnumType 688
+3.67. MonitoringCriterionEnumType 689
+3.68. MutabilityEnumType 689
+3.69. NotifyAllowedEnergyTransferStatusEnumType 689
+3.70. NotifyEVChargingNeedsStatusEnumType 689
+3.71. OCPPInterfaceEnumType 690
+3.72. OCPPTransportEnumType 690
+3.73. OCPPVersionEnumType 690
+3.74. OperationalStatusEnumType 691
+3.75. OperationModeEnumType 691
+3.76. PaymentStatusEnumType 691
+3.77. PhaseEnumType 691
+3.78. PowerDuringCessationEnumType 692
+3.79. PreconditioningStatusEnumType 692
+3.80. PriorityChargingStatusEnumType 692
+3.81. PublishFirmwareStatusEnumType 692
+3.82. ReadingContextEnumType 693
+3.83. ReasonEnumType 693
+3.84. RecurrencyKindEnumType 694
+3.85. RegistrationStatusEnumType 694
+3.86. ReportBaseEnumType 694
+3.87. RequestStopStatusEnumType 695
+3.88. ReservationUpdateStatusEnumType 695
+3.89. ReserveNowStatusEnumType 695
+3.90. ResetEnumType 696
+3.91. ResetStatusEnumType 696
+3.92. SendLocalListStatusEnumType 696
+3.93. SetMonitoringStatusEnumType 696
+3.94. SetNetworkProfileStatusEnumType 697
+3.95. SetVariableStatusEnumType 697
+3.96. TariffChangeStatusEnumType 697
+3.97. TariffClearStatusEnumType 697
+3.98. TariffCostEnumType 698
+3.99. TariffGetStatusEnumType 698
+3.100. TariffKindEnumType 698
+3.101. TariffSetStatusEnumType 698
+3.102. TransactionEventEnumType 699
+3.103 TriggerMessageStatusEnumType 699
+3.104. TriggerReasonEnumType 699
+3.105. UnlockStatusEnumType 700
+3.106. UnpublishFirmwareStatusEnumType 700
+3.107. UpdateEnumType 700
+3.108. UpdateFirmwareStatusEnumType 701
+3.109. UploadLogStatusEnumType 701
+3.110. VPNUMType. 701
+
+# Referenced Components and Variables 702
+
+1. Controller Components 703
+2. Referenced Components and Variables 705
+
+General requirements 705
+Shortcut notation for variables 705
+2.1. General 705
+2.2. Security related 717
+2.3. Authorization related 720
+2.4. Adhoc payment related 723
+2.5. Authorization Cache related 725
+2.6. Local Authorization List Management related 726
+2.7. Transaction related 729
+2.8. EnergyTransferResumptionRandomRange 733
+2.9. Metering related. 733
+2.10. Reservation related 742
+2.11. Smart Charging related. 743
+2.12. Tariff & Cost related 750
+2.13. Diagnostics related 755
+2.14. Display Message related 758
+2.15. Charging Infrastructure related 760
+2.16. ISO 15118 related 765
+2.17. Connected EV related 770
+2.18. Bidirectional Charging related 775
+2.19. DER Control related 783
+2.20. Battery Swapping related 784
+2.21. Device Model hierarchy variables 787
+
+# Disclaimer
+
+Copyright © 2010 - 2025 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).
+
+# Generic
+
+# Version History
+
+<table><tr><td>Version</td><td>Date</td><td>Description</td></tr><tr><td>2.1 Edition 1</td><td>2025-01-23</td><td>OCPP 2.1 Edition 1</td></tr></table>
+
+# Chapter 1. Scope
+
+This document defines the protocol used between a Charging Station and a Charging Station Management System in an EV charging infrastructure in the form of use cases. If the protocol requires a certain action or response from one side or the other, then this will be stated in this document.
+
+This part of the specification does not define the communication technology. In order to ensure widespread compatibility OCPP 2.1 is limited to JSON. The specifications for the JSON implementation are in "Part 4 - JSON over WebSockets implementation guide".
+
+# 1.1.OCPP 2.1 Edition 1
+
+OCPP 2.1 extends OCPP 2.0.1 with additional functionality. Care has been taken to make sure that the handling of OCPP 2.1 messages continues to work exactly the same as in OCPP 2.0.1 as long as none of the added (optional) fields in those messages are used.
+
+# Chapter 2. Conventions, Terminology and Abbreviations
+
+# 2.1. Conventions
+
+# 2.1.1. Normative
+
+All sections and appendices are normative, unless they are explicitly indicated to be informative.
+
+# 2.1.2. Requirements take precedence over text
+
+Whenever there is any (apparent) conflict between narrative text, sequence diagrams, examples and requirements in the specification document, the requirements have precedence.
+
+# 2.1.3. Requirement Keywords
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119], subject to the following additional clarification clause:
+
+The phrase "valid reasons in particular circumstances" relating to the usage of the terms "SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" is to be taken to mean technically valid reasons, such as the absence of necessary hardware to support a function from a Charging Station design: for the purposes of this specification it specifically excludes decisions made on commercial, or other non-technical grounds, such as cost of implementation, or likelihood of use.
+
+# 2.1.4. Primitive Datatypes
+
+The specification mentions the following primitive datatypes:
+
+Table 1. Primitive Datatypes
+
+<table><tr><td>Datatype</td><td>Description</td></tr><tr><td>string</td><td>The characters defined in the UTF-8 character set are allowed to be used.</td></tr><tr><td>integer</td><td>32 bit (31 bit resolution, 1 sign bit)No leading 0'sNo plus signAllowed value examples: 1234, -1234Not Allowed: 01234, +1234</td></tr><tr><td>decimal</td><td>For data being reported by the Charging Station, the full resolution of the source data must be preserved. The decimal sent towards the Charging Station SHALL NOT have more than six decimal places.</td></tr><tr><td>identifierString</td><td>This is a case-insensitivedataType and can only contain characters from the following character set: a-z, A-Z, 0-9, *', '-', ' ',=' ', ':', ' ', '@', '.</td></tr><tr><td>dateTime</td><td>All time values exchanged between CSMS and Charging Station SHALL be formatted as defined in [RFC3339]. Additionally fractional seconds have been given an extra limit. The number of decimal places SHALL NOT exceed the maximum of 3.Example 1: 2019-04-12T23:20:50.52Z represents 20 minutes and 50.52 seconds after the 23rd hour of April 12th, 2019 in UTC.Example 2: 2019-12-19T16:39:57+01:00 represents 39 minutes and 57 seconds after the 16th hour of December 19th, 2019 with an offset of +01:00 from UTC (Central European Time).</td></tr><tr><td>passwordString</td><td>This is a UTF-8 encoded case-sensitive string.</td></tr><tr><td>AnyType</td><td>Data without specified length or format.</td></tr><tr><td>boolean</td><td>Only allowed values: "false" and "true".</td></tr></table>
+
+# 2.1.5. Normal communication
+
+Unless otherwise specified, all use cases and requirements assume normal communication between Charging Station and CSMS (Online).
+
+# 2.1.6. Field description
+
+In many cases, further explanation about how or when to use certain fields in messages and datatypes is given in the field description. See Chapter Messages.
+
+# 2.2. Terminology
+
+# 2.2.1. General Terminology
+
+This section contains the terminology that is used throughout this document.
+
+Table 2. Terminology
+
+<table><tr><td>Terminology</td><td>Description</td></tr><tr><td>Application layer</td><td>OSI-Layer 5-7.</td></tr><tr><td>Authentication</td><td>Authentication is the process of confirming an identity or attribute. When speaking about authentication one should distinguish between user authentication (e.g. sender/receiver) and message authentication.</td></tr><tr><td>Block cipher</td><td>Cryptographic primitive to encrypt/ decrypt messages of fixed block length. Example: AES encrypts blocks of 128 bits (16 bytes) at a time.</td></tr><tr><td>Cable Plugged in</td><td>In this document this can mean the following:- Cable fixed on Charging Station side, cable plugged in to EV-Cable plugged into the Charging Station and EV-Wireless Charger detects an EV</td></tr><tr><td>Certificate</td><td>A digital certificate authenticates a public key or entity. See also Public-Key Infrastructure.</td></tr><tr><td>Certificate Management Protocol</td><td>An internet protocol used to manage X.509 digital certificates within a PKI. It is described in RFC 4210 and uses the certificate request message format (CRMF) described in RFC 4211.</td></tr><tr><td>Charging Cable</td><td>Cable assembly equipped with a, by the EV accepted, plug, intended to be used for the connection between an EV and an EVSE. One side may be permanently attached to the EVSE, or also be equipped with a plug that is accepted by the EVSE.</td></tr><tr><td>Charging Loop</td><td>In this specification the ISO 15118-2 definition of the charging loop is used: the V2G messaging phase for controlling the charging process by ISO 15118.</td></tr><tr><td>Charging Profile</td><td>Generic Charging Profile, used for different types of Profiles. Contains information about the Profile and holds the ChargingSchedule.</td></tr><tr><td>Charging Schedule</td><td>Part of a Charging Profile. Defines a block of charging Power or Current limits. Can contain a start time and length.</td></tr><tr><td>Charging Station</td><td>The Charging Station is the physical system where EVs can be charged. A Charging Station has one or more EVSEs.</td></tr><tr><td>Composite Charging Schedule</td><td>The charging schedule as calculated by the Charging Station. It is the result of the calculation of all active schedules and possible local limits present in the Charging Station. Local Limits might be taken into account.</td></tr><tr><td>Confidentiality</td><td>Only authorized entities may access confidential data. To protect data from unauthorized access it can be encrypted. Then only entities with access to the secret keys can access the data after decrypting it.</td></tr><tr><td>Connector</td><td>The term Connector, as used in this specification, refers to an independently operated and managed electrical outlet on a Charging Station. In other words, this corresponds to a single physical Connector. In some cases an EVSE may have multiple physical socket types and/or tethered cable/Connector arrangements(i.e. Connectors) to facilitate different vehicle types (e.g. four-wheeled EVs and electric scooters).</td></tr><tr><td>Contactor</td><td>An electrically controlled switching device, typically used by Charging Stations to switch charging power on/off.</td></tr><tr><td>Contract Certificate</td><td>A valid certificate for a charging contract in an EV for 15118 communication.</td></tr><tr><td>Control Pilot signal</td><td>A signal used by a Charging Station to inform an EV of a maximum current limit, as defined by IEC61851-1.</td></tr><tr><td>Cost</td><td>Cost to be paid by an EV Driver for consumed energy/time etc. Including taxes.</td></tr><tr><td>Cryptographic hash function</td><td>Cryptographic hash functions should behave as one-way functions. They must be preimage resistant, 2nd preimage resistant, and collision-resistant. Changes in the input must produce explicitly different results in the output. Example: SHA-256. See also ENISA OCPP Security [1].</td></tr><tr><td>Cryptography</td><td>The ENISA Algorithms, Key Sizes and Parameters Report (OCPP Security [1]) provides an overview of the current state of the art.</td></tr><tr><td>CSMS</td><td>Charging Station Management System. The system that manages Charging Stations and has the information for authorizing Users for using its Charging Stations.</td></tr><tr><td>Data Integrity</td><td>See Integrity and Message authentication.</td></tr><tr><td>Digital Signature</td><td>Authenticates the sender. In practice digital signatures are implemented using elliptic curves (EC).</td></tr><tr><td>Encryption</td><td>Using a cryptographic scheme, the message is mapped to a random-looking undecipherable string (ciphertext). Decryption reverses the encryption process and can only be performed with the corresponding decryption key. This decryption key is either the same as the encryption key (symmetric cryptography) or the private key in a public-key cryptosystem. The confidentiality of the message can be guaranteed only while the keys are kept secret.</td></tr><tr><td>Energy Management System</td><td>A device that manages the local loads (consumption and production) based on local and/or contractual constraints and/or contractual incentives. It has additional inputs, such as sensors and controls from e.g. PV, battery storage.</td></tr><tr><td>Energy Offer Period</td><td>Time during which a Charging Station is ready and willing to offer energy to an EV.</td></tr><tr><td>Energy Transfer Period</td><td>Time during which an EV chooses to take offered energy, or return it.</td></tr><tr><td>EVSE</td><td>EVSE stands for "EV Supply Equipment". An EVSE is considered to be an independently operated and managed part of the Charging Station that can deliver energy to one EV at a time.</td></tr><tr><td>Hash function</td><td>Function that maps a message to a bit string of fixed length (hash value). See also cryptographic hash function.</td></tr><tr><td>Hash value</td><td>Output of a (cryptographic) hash function. The length is fixed in the specs of the hash function.</td></tr><tr><td>High level communication</td><td>Bidirectional digital communication using protocol and messages and physical and data link layers specified in ISO 15118 series [ISO15118-1]</td></tr><tr><td>Idle State</td><td>In both use cases and sequence diagrams, Idle state is referred as the state in which a Charging Station is not performing any use case related tasks. Condition during which the equipment can promptly provide a primary function but is not doing so.</td></tr><tr><td>Integrity</td><td>Data cannot be altered without authorization. See also Message authentication.</td></tr><tr><td>Local Controller</td><td>A logical entity between a CSMS and one or more Charging Stations that has the ability to control charging of a group of Charging Stations based on the input from the CSMS, and can send messages to its Charging Stations, independently of the CSMS.</td></tr><tr><td>Master Pass</td><td>IdToken that can be used to stop any (or all) ongoing transactions. This can be used by for example law enforcement personal to stop a transaction.</td></tr><tr><td>Master Pass UI</td><td>Master Pass User Interface, this might be a full color touchscreen, but might also be just a couple of buttons and LEDs and/or sounds that enable a user to select transactions to be stopped.</td></tr><tr><td>Message authentication</td><td>Messages should be protected against unauthorized modifications. The message should always be sent together with an authentication tag providing its authenticity. Such an authentication tag can be the second output of an authenticated cipher such as AES-CCM or AES-GCM or a message authentication code.</td></tr><tr><td>Mode of Operation</td><td>A mode of operation specifies how the message blocks are processed by the block cipher. Using a block cipher in CBC or CTR mode provides encryption only, whereas using a block cipher in CCM or GCM mode encrypts the plaintext and produces a message authentication tag for the ciphertext.</td></tr><tr><td>OCPP-J</td><td>OCPP via JSON over WebSocket.</td></tr><tr><td>Offline</td><td>There is no communication possible between the Charging Station and CSMS. For an OCPP-J connection this means the WebSocket connection is not open.</td></tr><tr><td>Password authentication</td><td>The user proves his/her identity using a password or PIN.</td></tr><tr><td>Phase Rotation</td><td>Defines the wiring order of the phases between the electrical meter (or if absent, the grid connection), and the Charging Station Connector.</td></tr><tr><td>Price</td><td>Specific price tag of a single tariff entry, for example: 0.35 per kWh incl. 18% VAT.</td></tr><tr><td>Public-key cryptography</td><td>"Cryptographic scheme where a public key is published and henceforth can be used for encryption of messages or verification of digital signatures. Each public key has a counterpart, the corresponding private key. This key must be kept secret and is used for decryption or digital signing of messages. Public-key primitives have a high computational complexity for encryption and therefore are mostly used as part of a hybrid encryption scheme where the public key is used to communicate a common symmetric session key under which all further communication is encrypted. Certificates administered by a public-key infrastructure are used to establish the authenticity of the public key. See also ENISA OCPP Security [12]. The most popular public-key encryption scheme is RSA. Digital signatures can be generated most efficiently with elliptic-curve based (EC) mechanisms."</td></tr><tr><td>Public-key infrastructure</td><td>System to generate, administer, and revoke certificates.</td></tr><tr><td>Resume regular transaction</td><td>Used in sequence diagrams to indicate that this use case/sequence diagram has ended, but the transaction has not ended and will continue, but that is outside of scope of that specific use case.</td></tr><tr><td>Requirement</td><td>Provision that conveys criteria to be fulfilled. ISO/IEC Guide 2:2004, 7.5.</td></tr><tr><td>Security Event</td><td>Any event relevant to the secure operation of the device.</td></tr><tr><td>Security Function</td><td>Any function on the device that is needed for it to be operated securely, including access control, authentication, and encryption.</td></tr><tr><td>Session</td><td>A Session in OCPP is a general term that refers to the charging process of an EV, that might include a Transaction.</td></tr><tr><td>Session key</td><td>Symmetric key with a limited lifetime.</td></tr><tr><td>Symmetric cryptography</td><td>Sender and receiver hold the same key. Examples for symmetric primitives are block ciphers or MACs.</td></tr><tr><td>Transaction</td><td>A transaction in OCPP is a part of the complete process of charging an EV that starts and stops based on configurable parameters. These configurable parameters refer to moments in the charging process, such as the EV being connected or the EV driver being authorized.</td></tr><tr><td>Tariff</td><td>Collection of prices depending on charging time, power usage and other price affecting parameters.</td></tr><tr><td>Use case</td><td>A use case is a structured way of describing the (inter)actions necessary to achieve a certain objective. In this document, a use case consists of an actor list, a scenario description, postconditions and a sequence diagram and is always followed by a list of numbered requirements.</td></tr><tr><td>User Authentication</td><td>Verification of the identity of the communication partners (e.g., user on the device). Moreover, verification that the communication partners are still alive throughout a session.</td></tr><tr><td colspan="2">OCPP 2.1 DER terminology</td></tr><tr><td>Cease to Energize</td><td>Halting the delivery of active power during stable and unstable conditions while restricting the exchange of reactive power.</td></tr><tr><td>DER Curve</td><td>A set of points that outline a curve representing the adjustments required for the Y-axis value based on the X-axis value. An example of this is the Volt-Watt curve or P(U), which determines active power based on voltage.</td></tr><tr><td>Distributed Energy Resource (DER)</td><td>An electricity source that is not directly linked to a bulk power system. DER comprises generators and energy storage technologies that can provide active power to an electrical power system. For the purposes of this document, a bidirectional charging station and bidirectional EV make up a DER.</td></tr><tr><td>Frequency Droop</td><td>A type of frequency-watt curve defined by a dead-band between under- and over-frequency, and a frequency change per unit power output change (frequency droop) for under- and over-frequencies.</td></tr><tr><td>Momentary Cessation</td><td>A temporary halt to active power delivery in response to voltage or system frequency disruptions, with the ability to immediately restore operation output when the voltages and frequency return to specified ranges.</td></tr><tr><td>Nameplate Ratings</td><td>Capabilities of a DER for sustained operation, e.g. nominal voltage (V), current (A), maximum active power (kW), apparent power (kVA), and reactive power (kvar).</td></tr><tr><td>Ride-Through Curve</td><td>A specific type of DER curve represented as a piecewise linear curve that defines regions associated with voltage and frequency behavior for trip, momentary cessation, and may trip.</td></tr><tr><td>Ride-Through</td><td>The ability to withstand voltage or frequency disruptions within specified limits and continue operating as specified.</td></tr><tr><td>Trip Curve</td><td>Similar to a ride-through curve, but without momentary cessation.</td></tr><tr><td>Trip</td><td>The inhibition of immediate service restoration, which may require disconnection.</td></tr></table>
+
+# 2.2.2. ISO 15118 and OCPP terminology mapping
+
+This section is informative.
+
+The ISO 15118 terminology is more comprehensive when referring to specific components within EVs and Charging Stations. The following table shows a "mapping" of these terms.
+
+Table 3. ISO 15118 and OCPP terminology mapping
+
+<table><tr><td>ISO 15118</td><td>OCPP</td></tr><tr><td>ChargingProfile (contains the power over time the EV is planned to consume)</td><td>Loosely corresponds to ChargingSchedule in NotifyEVChargingSchedule message.</td></tr><tr><td>SASchedule (the power limits from a secondary actor for charging an EV for a specific time)</td><td>Loosely corresponds to ChargingProfile in SetChargingProfile message.</td></tr><tr><td>EVCC (i.e. Electric Vehicle Communication Controller)</td><td>Controller in the EV that is used for ISO 15118 communication.</td></tr><tr><td>Outlet</td><td>Connector</td></tr><tr><td>SECC (i.e. Supply Equipment Communication Controller)</td><td>Controller in the EVSE of the Charging Station that is used for ISO 15118 communication.</td></tr><tr><td>SA (i.e. Secondary Actor)</td><td>CSMS (or other backend systems)</td></tr></table>
+
+# 2.3. Abbreviations
+
+# 2.3.1. General Abbreviations
+
+This section contains the abbreviations that are used throughout this document.
+
+Table 4. Abbreviations
+
+<table><tr><td>Abbreviation</td><td>Description</td></tr><tr><td>AES</td><td>Advanced Encryption Standard. Original name for this block cipher was Rijndael named after its designers Vincent Rijmen and Joan Daemen.</td></tr><tr><td>BEV</td><td>Battery Electric Vehicle</td></tr><tr><td>CMP</td><td>Certificate Management Protocol</td></tr><tr><td>CS</td><td>Charging Station</td></tr><tr><td>CSL</td><td>Comma Separated List</td></tr><tr><td>CSMS</td><td>Charging Station Management System</td></tr><tr><td>CSO</td><td>Charging Station Operator</td></tr><tr><td>DER</td><td>Distributed Energy Resource</td></tr><tr><td>DHCP</td><td>Dynamic Host Configuration Protocol</td></tr><tr><td>DNS</td><td>Domain Name System</td></tr><tr><td>DSO</td><td>Distribution System Operator</td></tr><tr><td>DST</td><td>Daylight Saving Time</td></tr><tr><td>EC</td><td>Elliptic Curve. See also ENISA OCPP Security [1]</td></tr><tr><td>ECDSA</td><td>Elliptic Curve Digital Signature Algorithm.</td></tr><tr><td>EMS</td><td>Energy Management System</td></tr><tr><td>ENISA</td><td>European Union Agency for Network and Information Security.</td></tr><tr><td>EV</td><td>Electric Vehicle</td></tr><tr><td>EVSE</td><td>EV Supply Equipment IEC61851-1</td></tr><tr><td>FQDN</td><td>Fully Qualified Domain Name</td></tr><tr><td>FTP(S)</td><td>File Transport Protocol (Secure)</td></tr><tr><td>HTTP(S)</td><td>HyperText Transport Protocol (Secure)</td></tr><tr><td>ICCID</td><td>Integrated Circuit Card Identifier</td></tr><tr><td>IMSI</td><td>International Mobile Subscription Identity</td></tr><tr><td>JSON</td><td>JavaScript Simple Object Notation</td></tr><tr><td>MAC</td><td>Message authentication code. Provides data integrity. Examples: CMAC, GMAC. See also ENISA OCPP Security [1].</td></tr><tr><td>NAT</td><td>Network Address Translation</td></tr><tr><td>NIST</td><td>National Institute of Standards and Technology.</td></tr><tr><td>NTP</td><td>Network Time Protocol</td></tr><tr><td>PDU</td><td>Protocol Data Unit</td></tr><tr><td>PHEV</td><td>Plugin Hybrid Electric Vehicle</td></tr><tr><td>RDN</td><td>Relative Distinguished Name</td></tr><tr><td>RSA</td><td>Public-key cryptosystem named after its inventors Rivest, Shamir, and Adleman.</td></tr><tr><td>RSA-PSS</td><td>RSA-PSS is a new signature scheme that is based on the RSA cryptosystem and provides increased security assurance. It was added in version 2.1 of PKCS #1, following OCPP Security [23]</td></tr><tr><td>RST</td><td>3 phase power connection, Standard Reference Phasing</td></tr><tr><td>RTS</td><td>3 phase power connection, Reversed Reference Phasing</td></tr><tr><td>SRT</td><td>3 phase power connection, Reversed 240 degree rotation</td></tr><tr><td>STR</td><td>3 phase power connection, Standard 120 degree rotation</td></tr><tr><td>TRS</td><td>3 phase power connection, Standard 240 degree rotation</td></tr><tr><td>TSR</td><td>3 phase power connection, Reversed 120 degree rotation</td></tr><tr><td>SC</td><td>Smart Charging</td></tr><tr><td>TLS</td><td>Transport Layer Security</td></tr><tr><td>TSO</td><td>Transmission System Operator</td></tr><tr><td>URI</td><td>Uniform Resource Identifier RFC-3986 [RFC3986]</td></tr><tr><td>URL</td><td>Uniform Resource Locator - refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location").</td></tr><tr><td>UTC</td><td>Coordinated Universal Time</td></tr><tr><td>WAN</td><td>Wide Area Network.</td></tr></table>
+
+# 2.3.2. ISO 15118 Abbreviations
+
+This section contains the abbreviations from ISO 15118 that are used in this document.
+
+Table 5. ISO 15118 Abbreviations
+
+<table><tr><td>EIM</td><td>External Identification Means</td></tr><tr><td>EMAID</td><td>E-Mobility Account Identifier</td></tr><tr><td>EVCC</td><td>EV Communication Controller</td></tr><tr><td>HLC</td><td>High Level Communication</td></tr><tr><td>HMI</td><td>Human Machine Interface</td></tr><tr><td>LAN</td><td>Local Area Network</td></tr><tr><td>MO</td><td>Mobility Operator</td></tr><tr><td>OEM</td><td>Original Equipment Manufacturer</td></tr><tr><td>OCSP</td><td>Online Certificate Status Protocol</td></tr><tr><td>PWM</td><td>Pulse Width Modulation</td></tr><tr><td>SA</td><td>Secondary Actor</td></tr><tr><td>SECC</td><td>Supply Equipment Communication Controller</td></tr><tr><td>V2G</td><td>Vehicle to Grid</td></tr></table>
+
+# 2.4. Actors
+
+This section is informative.
+
+In OCPP, system actors are covering functions or devices.
+
+Table 6. Actors
+
+<table><tr><td>Actor name</td><td>Actor type</td><td>Actor description</td></tr><tr><td>EV Driver</td><td>Actor</td><td>The Driver of an EV who wants to charge the EV at a Charging Station.</td></tr><tr><td>Connector</td><td>Device</td><td>The term "Connector", as used in this specification, refers to an independently operated and managed electrical outlet on a Charging Station. In other words, this corresponds to a single physical Connector. In some cases an EVSE may have multiple Connectors: for example a DC EVSE with a CCS2 and a CHAdeMO connector).</td></tr><tr><td>CSMS</td><td>System</td><td>Charging Station Management System: manages Charging Stations and has the information for authorizing Users for using its Charging Stations.</td></tr><tr><td>Charging Station</td><td>Device</td><td>The Charging Station is the physical system where an EV can be charged. A Charging Station has one or more EVSEs.</td></tr><tr><td>Charging Station Operator</td><td>Actor</td><td>A party that manages a CSMS.</td></tr><tr><td>Electric Vehicle</td><td>Device</td><td>An electric vehicle (EV) is a type of vehicle that is powered by one or more electric motors, using energy stored in rechargeable batteries.</td></tr><tr><td>Local Controller</td><td>Device</td><td>A logical entity logically placed between a CSMS and one or more Charging Stations that has the ability to control charging of a group of Charging Stations based on the input from the CSMS and/or external systems.</td></tr><tr><td>External Control System</td><td>Actor</td><td>An external system that may impose charging limits/constraints on the Charging Station or CSMS, for example a DSO or EMS.</td></tr></table>
+
+# 2.5. References
+
+# 2.5.1. Generic references
+
+Table 7. References
+
+<table><tr><td>Reference</td><td>Description</td></tr><tr><td>[DNP3]</td><td>Distributed Network Protocol. https://www.dnp.org/About/Overview-of-DNP3-Protocol</td></tr><tr><td>[EN50549-1]</td><td>EN 50549-1:2019 Requirements for generating plants to be connected in parallel with distribution networks - Part 1: Connection to a LV distribution network - Generating plants up to and including Type B</td></tr><tr><td>[IEC60870-5-104]</td><td>Set of standards which define systems used for telecontrol (supervisory control and data acquisition) in electrical engineering and power system automation applications. https://webstore.iec.ch/publication/3755</td></tr><tr><td>[IEC61850-7-420]</td><td>Communications standard for distributed energy resources (DER). https://webstore.iec.ch/publication/6019</td></tr><tr><td>[IEC61851-1]</td><td>"IEC 61851-1 2017: EV conductive charging system - Part 1: General requirements" https://webstore.iec.ch/publication/33644</td></tr><tr><td>[IEC62196]</td><td>IEC 62196: Plugs, socket-outlets, vehicle couplers and vehicle inlets - Conductive charging of electric vehicles. https://webstore.iec.ch/publication/6582</td></tr><tr><td>[ISO15118-1]</td><td>ISO 15118-1 specifies terms and definitions, general requirements and use cases as the basis for the other parts of ISO 15118. It provides a general overview and a common understanding of aspects influencing the charge process, payment and load leveling. https://webstore.iec.ch/publication/29264</td></tr><tr><td>[ISO15118-2]</td><td>Road vehicles - Vehicle to grid communication interface - Part 2: Network and application protocol requirements, First edition, 2014-04-01. https://webstore.iec.ch/publication/9273</td></tr><tr><td>[ISO15118-20]</td><td>Road vehicles - Vehicle to grid communication interface - Part 20: Network and application protocol requirements. https://webstore.iec.ch/publication/26347</td></tr><tr><td>[ISO4217]</td><td>"ISO 4217: Currency codes" http://www.iso.org/iso/home/standards/currency_codes.htm</td></tr><tr><td>[OCPP2.1-PART1]</td><td>"OCPP 2.1: Part 1 - Architecture & Topology". http://www.openchargealliance.org/downloads/</td></tr><tr><td>[OCPP2.1-PART2-APPENDIX]</td><td>"OCPP 2.1: Part 2 - Appendices". http://www.openchargealliance.org/downloads/</td></tr><tr><td>[OCPP2.1-PART4]</td><td>"OCPP 2.1: Part 4 - JSON over WebSockets implementation guide". http://www.openchargealliance.org/downloads/</td></tr><tr><td>[OpenADR]</td><td>"Open Automated Demand Response" http://www.openadr.org/</td></tr><tr><td>[RFC1321]</td><td>"The MD5 Message-Digest Algorithm" https://tools.ietf.org/html/rfc1321</td></tr><tr><td>[RFC2119]</td><td>"Key words for use in RFCs to Indicate Requirement Levels". S. Bradner. March 1997. http://www.ietf.org/rfc/rfc2119.txt</td></tr><tr><td>[RFC3339]</td><td>"Date and Time on the Internet: Timestamps" https://tools.ietf.org/html/rfc3339</td></tr><tr><td>[RFC3986]</td><td>"Uniform Resource Identifier (URI): Generic Syntax" https://tools.ietf.org/html/rfc3986</td></tr><tr><td>[RFC5646]</td><td>"Tags for Identifying Languages" https://tools.ietf.org/html/rfc5646</td></tr><tr><td>[IEC 61850-7-420]</td><td>Communication networks and systems for power utility automation - Part 7-420: Basic communication structure - Distributed energy resources logical nodes (IEC 61850-7-420:2009,IDT)</td></tr><tr><td>[IEEE 1547-2018]</td><td>Standard for Interconnection and Interoperability of Distributed Energy Resources with Associated Electric Power Systems Interfaces</td></tr><tr><td>[IEEE 2030.5-2018]</td><td>Standard for Smart Energy Profile Application Protocol</td></tr><tr><td>[CSIP IEEE 2030.5]</td><td>Sunspec Alliance, Common Smart Inverter Profile, Implementation Guide for Smart Inverters, 2018, v2.1</td></tr><tr><td>[SAE J3072]</td><td>SAE J3072-2021 Interconnection Requirements for Onboard, Grid Support Inverter Systems</td></tr></table>
+
+# 2.5.2. Security related references
+
+Table 8. Security related references
+
+<table><tr><td>Reference</td><td>Description</td></tr><tr><td>[1]</td><td>ENISA European Network and Information Security Agency, Algorithms, key size and parameters report 2014, 2014. (last accessed on 17 January 2016) https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014</td></tr><tr><td>[2]</td><td>National Institute of Standards and Technology. FIPS PUB 140-2, Security Requirements for Cryptographic Modules, May 2001. http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf</td></tr><tr><td>[3]</td><td>Cooper, D., et al., Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Internet Engineering Task Force, Request for Comments 5280, May 2008, http://www.ietf.org/rfc/rfc5280.txt</td></tr><tr><td>[4]</td><td>Dierks, T. and Rescorla, E., The Transport Layer Security (TLS) Protocol Version 1.2, Internet Engineering Task Force, Request for Comments 5246, August 2008, http://www.ietf.org/rfc/rfc5246.txt</td></tr><tr><td>[5]</td><td>Eastlake, D., Transport Layer Security (TLS) Extensions: Extension Definitions, Internet Engineering Task Force, Request for Comments 6066, January 2011, http://www.ietf.org/rfc/rfc6066.txt</td></tr><tr><td>[6]</td><td>McGrew, D. and Bailey, D., AES-CCM Cipher Suites for Transport Layer Security (TLS), Internet Engineering Task Force, Request for Comments 6655, July 2012, http://www.ietf.org/rfc/rfc6655.txt</td></tr><tr><td>[7]</td><td>Rescorla E. et al., Transport Layer Security (TLS) Renegotiation Indication Extension, Internet Engineering Task Force, Request for Comments 5746, February 2010, http://www.ietf.org/rfc/rfc5746.txt</td></tr><tr><td>[8]</td><td>"Russel Housley, Tim Polk, Warwick Ford, and David Solo. Internet Public Key Infrastructure: X.509 Certificate and Certificate Revocation List (CRL) Profile, RFC 3280, April 2002." https://www.ietf.org/rfc/rfc3280.txt</td></tr><tr><td>[9]</td><td>Pettersen. "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension." RFC 6961, June 2013. https://tools.ietf.org/html/rfc6961.</td></tr><tr><td>[10]</td><td>Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004. https://www.ietf.org/rfc/rfc3749.txt</td></tr><tr><td>[11]</td><td>National Institute of Standards and Technology. Annex C: Approved Random Number Generators for FIPS PUB 140-2 [25], February 2012. https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexc.pdf</td></tr><tr><td>[12]</td><td>Bundesamt für Sicherheit in der Informationstechnik: Anwendungshinweise und Interpretationen zum Schema, AIS 20, Funktionalitätstklassen und Evaluationsmethodologie für deterministicische Zufallszahlengeneratoren, Version 3.0, Bonn, Germany, May 2013. (in German) https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_20pdf.html</td></tr><tr><td>[13]</td><td>Bundesamt für Sicherheit in der Informationstechnik: Anwendungshinweis und Interpretationen zum Schema, AIS 31, Funktionalitätstklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren, Version 3.0, Bonn, Germany, May 2013. (in German) https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31pdf.html</td></tr><tr><td>[14]</td><td>"OWASP - Transport Layer Protection Cheat Sheet. https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Extended_Observation_Certificates"</td></tr><tr><td>[15]</td><td>P. Hoffman and W.C.A. Wijngaards, Elliptic Curve Digital Signature Algorithm (DSA) for DNNSEC, Internet Engineering Task Force (IETF) RFC 6605, April 2012. http://www.ietf.org/rfc/rfc6605.txt</td></tr><tr><td>[16]</td><td>Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005. https://www.ietf.org/rfc/rfc4210.txt</td></tr><tr><td>[17]</td><td>National Institute of Standards and Technology. Special Publication 800-57 Part 1 Rev. 4, Recommendation for Key Management. January 2016. https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-4/final</td></tr><tr><td>[18]</td><td>RFC 2617. HTTP Authentication: Basic and Digest Access Authentication. https://www.ietf.org/rfc/rfc2617.txt</td></tr><tr><td>[19]</td><td>RFC 5280. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. https://www.ietf.org/rfc/rfc5280.txt</td></tr><tr><td>[20]</td><td>OCPP 1.6. Interface description between Charging Station and CSMS. October 2015. http://www.openchargealliance.org/downloads/</td></tr><tr><td>[21]</td><td>Eekelen, M. van, Poll, E., Hubbers, E., Vieira, B., Broek, F. van den: An end-to-end security design for smart EV-charging for Enexus and ElaadNL by LaQuSo1. December 2, 2014. https://www.elaad.nl/smart-charging-end2end-security-design/</td></tr><tr><td>[22]</td><td>RFC 2986. PKCS #10: Certification Request Syntax Specification, Version 1.7. https://www.ietf.org/rfc/rfc2986.txt</td></tr><tr><td>[23]</td><td>RSA-PSS. https://tools.ietf.org/html/rfc8017</td></tr><tr><td>[24]</td><td>Santesson, et al. "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP" RFC 6960. June 2013. https://tools.ietf.org/html/rfc6960</td></tr><tr><td>[25]</td><td>RFC 2818. HTTP Over TLS. https://tools.ietf.org/html/rfc2818</td></tr></table>
+
+# 2.6. Definition of Transaction
+
+This section is informative.
+
+To support as many business cases as possible, and to prevent too many messages being sent when not needed for certain business cases, OCPP 2.0.1 supports flexible configuration of the start and stop of a transaction. This makes it possible to define the start and stop of a transaction depending on market demands.
+
+See: Flexible transaction start/stop for more information.
+
+# 2.6.1. Transaction in relation to Energy Transfer Period
+
+The Energy Transfer Period is a period of time during which energy is transferred between the EV and the EVSE. There MAY be multiple Energy Transfer Periods during a Transaction.
+
+Multiple Energy Transfer Periods can be separated by either:
+
+- an EVSE-initiated suspense of transfer during which the EVSE does not offer energy transfer, or;
+- an EV-initiated suspense of transfer during which the EV remains electrically connected to the EVSE, or;
+- an EV-initiated suspense of transfer during which the EV is not electrically connected to the EVSE.
+
+
+Figure 1. OCPP Charging Transaction definition
+
+# 2.7. ISO 15118 support
+
+This section is informative.
+
+OCPP supports ISO 15118 authorization (also called "Plug and Charge") and ISO 15118 based Smart Charging. (See [ISO15118-2] and [ISO15118-20]). Furthermore, it describes how to install and update ISO 15118 certificates. This functionality is not included as one functional block, but is included in multiple chapters throughout the specification. ISO 15118 authorization is included in the functional block C. Authorization and the Smart Charging use cases for ISO 15118 are included in the section K 5.3. ISO 15118 based Smart Charging. Certificate handling is described in a M Certificate Management.
+
+OCP 2.1 has added specific support for bidirectional power transfer with ISO 15118-20 in Q. Bidirectional Power Transfer.
+
+Implementors need to be aware of timeout constraints enforced by ISO 15118, see [ISO15118-2] (Page: 172, Table: 109) and [ISO15118-20] (Page 384, Table: 215).
+
+For reference, the current timing constraints for ISO 15118-2:2014 are:
+
+Table 9.ISO 15118-2 Timing constrains
+
+<table><tr><td>Timeout</td><td>Default</td></tr><tr><td>Sequence Timeouts</td><td>60 seconds</td></tr><tr><td>Sequence Performance Timeouts</td><td>40 seconds</td></tr><tr><td>PaymentDetailsReq/Res</td><td>4.5 seconds</td></tr><tr><td>AuthorizationReq/Res</td><td>1.5 seconds</td></tr><tr><td>CertificateUpdateReq/Res</td><td>4.5 seconds</td></tr><tr><td>CertificateInstallationReq/Res</td><td>4.5 seconds</td></tr></table>
+
+For reference, the current timing constraints for ISO 15118-20:2022 are:
+
+Table 10. ISO 15118-20 Timing constrains
+
+<table><tr><td>Timeout</td><td>Default</td></tr><tr><td>Sequence Timeouts</td><td>60 seconds</td></tr><tr><td>Sequence Performance Timeouts</td><td>40 seconds</td></tr><tr><td>AuthorizationSetupReq/Res</td><td>1.5 seconds</td></tr><tr><td>AuthorizationReq/Res</td><td>1.5 seconds</td></tr><tr><td>CertificateInstallationReq/Res</td><td>4.5 seconds</td></tr></table>
+
+# Chapter 3. Generic Requirements
+
+This section is normative.
+
+The generic requirements build the basis for defining the use case elements described in the Functional Blocks.
+
+IMPORTANT
+
+This section requires knowledge of chapter 4 in Part 4 of the specification ([ref-ocpp20-part4]).
+
+Table 11. Generic requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>FR.01</td><td></td><td>The sender of a <message>Request SHALL wait for a <message>Response or a timeout, before sending another request message.</td><td></td></tr><tr><td>FR.02</td><td>When the Charging Station receives a valid OCPP request message according to the JSON schemas / RPC Framework AND the other system is not causing a security violation</td><td>The Charging Station SHALL respond with a RPC Framework: CALLRESULT.</td><td>If the Charging Station/CSMS needs to provide additional information, this can be done in the statusInfo element of the response message.</td></tr><tr><td>FR.03</td><td>When the Charging Station/CSMS receives an invalid OCPP request message according to the JSON schemas / RPC Framework OR the other system causes a security violation</td><td>The Charging Station/CSMS SHALL respond with a RPC Framework: CALLERROR.</td><td></td></tr><tr><td>FR.04</td><td>When the CSMS rejected the BootNotificationRequest from the Charging Station AND The Charging Station sends a message other than BootNotificationRequest</td><td>The CSMS SHALL respond with a RPC Framework: CALLERROR: SecurityError.</td><td>See use cases B02 and B03 for details.</td></tr><tr><td>FR.05</td><td>There are a few messages that do not provide their result in the response message, but send one or more messages that contain the result. When one of the following messages is received; GetReport, GetBaseReport, GetMonitoringReport, GetDisplayMessages, CustomerInformation, GetChargingProfiles, GetLog, UpdateFirmware, PublishFirmware, TriggerMessage(<message>)</td><td>The Charging Station SHALL acknowledge the requests in the list below with a response message (shown after the arrow "→") with the same requestId as the request: GetReport → NotifyReport GetBaseReport → NotifyReport GetMonitoringReport → NotifyMonitoringReport GetDisplayMessages → NotifyDisplayMessage CustomerInformation → NotifyCustomerInformation GetChargingProfiles → ReportChargingProfiles GetLog → LogStatusNotification UpdateFirmware → FirmwareStatusNotification PublishFirmware → PublishFirmwareStatusNotification TriggerMessage(<message>) → <requested message></td><td>The CSMS needs to know that a request for requestId = X was accepted, so that it can expect result messages for this requestId. TriggerMessage does not have a requestId, but the requirement still applies in the sense that a TriggerMessageResponse must be sent before the sending the requested message.</td></tr><tr><td>FR.06 (2.1)</td><td>When the Charging Station/CSMS receives an invalid OCPP response message according to the JSON schemas / RPC Framework</td><td>The Charging Station/CSMS SHALL respond with a RPC Framework: CALLRESULT TERROR.</td><td></td></tr><tr><td>FR.07 (2.1)</td><td>When the Charging Station sends an OCPP message RPC Framework type SEND</td><td>CSMS SHALL NOT respond with a message.</td><td>Receipt of a SEND message is not acknowledged. The sender will never know if the message has been received or processed.</td></tr></table>
+
+# 3.1. Time Format Requirements
+
+This section is normative.
+
+All time values exchanged between CSMS and Charging Station SHALL be formatted as defined in RFC-3339 [RFC3339]. Additionally fractional seconds have been given an extra limit. The number of decimal places SHALL NOT exceed the maximum of 3. However, it is RECOMMENDED to omit fractional seconds entirely, because it is of limited use and omitting it reduces data usages.
+
+It is strongly RECOMMENDED to exchange all time values between CSMS and Charging Station as UTC, with the time zone designator 'Z', as specified by RFC-3339 [RFC3339]. This will improve interoperability between CSMS and Charging Station.
+
+# 3.1.1. Displaying local time
+
+When a Charging Station wants to give detailed control of configuring the internal clock to a CSO, it can implement one or more of the following Configuration Variables: TimeSource, TimeZone, TimeOffset, NtpSource, NtpServerUri.
+
+# 3.1.1.1. Daylight Saving Time
+
+There are 2 ways a Charging Station can support punctual automated bi-annual changeover between "standard time" and "daylight saving time" periods.
+
+- The transition dates and offsets are known in the Charging Station, based on the configured TimeZone.
+- The transition date and offset is manually configured for every transition via: NextTimeOffsetTransitionDateTime and TimeOffsetNextTransition.
+
+Daylight saving time is used for displaying the current time to the EV driver.
+
+# 3.2. Message timeouts
+
+This section is normative.
+
+OCPP does not specify timing requirements for messages. Timing of messages is greatly influenced by the underlying network used. A GPRS network has different timing characteristics compared to a land-line. As OCPP does not require a certain type of network, but leaves this open for the CSO to select, OCPP cannot require timing constrains.
+
+If you are looking for some guidance, start with a 30 second timeout on message requests, and tune it for the network used.
+
+The message timeout setting in a Charging Station can be configured in the messageTimeout field in the NetworkConnectionProfile. The purpose of the message timeout is to be able to consider a request message as not sent and continue with other tasks when the message did not arrive due to communication errors or software failure. For transaction related events, use case E13 - Transaction-related message not accepted by CSMS describes the retry procedure when this happens. See also the section Delivering transaction-related messages in Functional Block E.
+
+A charging station may discover that the connection to CSMS is not functioning correctly when it gets a timeout to a request or when the websocket ping is not answered. In such a situation it is advised that the charging station drops the connection and then reconnects to CSMS. This will create a fresh session and will possibly connect to a different endpoint of a multi-instance CSMS, which may resolve the error.
+
+# 3.3. Language support
+
+This section is informative.
+
+A CSMS can provide the Charging Station with preferred languages for an EV Driver, enabling the Charging Station to communicate with the EV Driver in a language according to his/her preferences.
+
+For any Charging Station that shows messages on a display it is RECOMMENDED to at least also implement these in "English". When the preferred languages for an EV-driver (provided by the CSMS) are not "English" and don't match any of the other languages
+
+implemented in the Charging Station, it is RECOMMENDED to use "English" as fall-back.
+
+# A. Security
+
+# Chapter 1. OCPP Security
+
+This Functional Block describes the security requirements for the OCPP protocol. The security part was developed to strengthen and mature the future development and standardization of OCPP. It is based amongst others on the end-to-end security design by LaQuSo [21]. Security requirements are included on security measures at Charging Station and CSMS, to support users of the OCPP.
+
+# 1.1. Security Objectives
+
+This section is informative.
+
+OCPP security has been designed to meet the following security objectives:
+
+1. To allow the creation of a secure communication channel between the CSMS and Charging Station. The integrity and confidentiality of messages on this channel should be protected with strong cryptographic measures.
+2. To provide mutual authentication between the Charging Station and the CSMS. Both parties should be able to identify who they are communicating with.
+3. To provide a secure firmware update process by allowing the Charging Station to check the source and the integrity of firmware images, and by allowing non-repudiation of these images.
+4. To allow logging of security events to facilitate monitoring the security of the smart charging system. A list of security related events and their 'criticality' is provided in the appendices.
+
+# 1.2. Design Considerations
+
+This section is informative.
+
+The security Functional Block was designed to fit into the approach taken in OCPP. Standard web technologies are used whenever possible to allow cost-effective implementations using available web libraries and software. No application layer security measures are included. Based on these considerations, OCPP security is based on TLS and public key cryptography using X.509 certificates. Because the CSMS usually acts as the server, different users or role-based access control on the Charging Station are not implemented in this standard. To mitigate this, it is recommended to implement access control on the CSMS. To make sure the mechanisms implemented there cannot be bypassed, OCPP should not be used by qualified personnel performing maintenance to Charging Stations locally at the Charging Station, as other protocols may be used for local maintenance purposes.
+
+# 1.3. Security Profiles
+
+This section defines the different OCPP security profiles and their requirement. OCPP 2.1 supports three security profiles: The table below shows which security measures are used by which profile.
+
+Table 12. Overview of OCPP security profiles
+
+<table><tr><td>Profile</td><td>Charging Station Authentication</td><td>CSMS Authentication</td><td>Communication Security</td></tr><tr><td>1. Unsecured Transport with Basic Authentication</td><td>HTTP Basic Authentication</td><td>-</td><td>-</td></tr><tr><td>2. TLS with Basic Authentication</td><td>HTTP Basic Authentication</td><td>TLS authentication using certificate</td><td>Transport Layer Security (TLS)</td></tr><tr><td>3. TLS with Client Side Certificates</td><td>TLS authentication using certificate</td><td>TLS authentication using certificate</td><td>Transport Layer Security (TLS)</td></tr></table>
+
+- 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.1 without implementing security. While this is possible, it is NOT considered a valid OCPP 2.1 implementation.
+- When the Charging Station does not have the correct date and time set, it cannot validate the server certificate. A solution for this might be to either use NTP, mobile network to set time automatically, or have an installer tool that sets the time before the first connection.
+
+# 1.3.1. Generic Security Profile requirements
+
+Table 13. Generic Security Profile requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.001</td><td></td><td>The Charging Station and CSMS SHALL only use one security profile at a time</td></tr><tr><td>A00.FR.002</td><td>If the Charging Station tries to connect with a different profile than the CSMS is using</td><td>The CSMS SHALL terminate the connection.</td></tr><tr><td>A00.FR.004</td><td></td><td>The security profile SHALL be configured before OCPP communication is possible.</td></tr><tr><td>A00.FR.005</td><td></td><td>Lowering the security profile that is used, to a less secure profile, is for security reasons, not recommended.The Charging Station SHALL only allow to lower the security profile if the variable AllowSecurityProfileDowngrade is implemented and set to true. In that case, the Charging Station SHALL only allow to downgrade from profile 3 to profile 2. The Charging Station SHALL NOT allow to downgrade from profile 2 or profile 3 to profile 1 using the OCPP protocol.</td></tr><tr><td>A00.FR.006</td><td>When a CSMS communicates with Charging Stations with different security profiles or different versions of OCPP.</td><td>The CSMS MAY operate the Charging Stations via different addresses or ports of the CSMS.For instance, the CSMS server may have one TCP port for TLS with Basic Authentication, and another port for TLS with Client Side Certificates.In this case there is only one security profile in use per port of the CSMS, which is allowed.</td></tr></table>
+
+# 1.3.2. Unsecured Transport with Basic Authentication Profile - 1
+
+Table 14. Security Profile 1 - Unsecured Transport with Basic Authentication
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Unsecured Transport with Basic Authentication</td></tr><tr><td>2</td><td>Profile No.</td><td>1</td></tr><tr><td>3</td><td>Description</td><td>The Unsecured Transport with Basic Authentication profile provides a low level of security. Charging Station authentication is done through a username and password. No measures are included to secure the communication channel.</td></tr><tr><td>4</td><td>Charging Station Authentication</td><td>For Charging Station authentication HTTP Basic authentication is used.</td></tr><tr><td>5</td><td>CSMS Authentication</td><td>In this profile, the CSMS does not authenticate itself to the Charging Station. The Charging Station has to trust that the server it connects to is indeed the CSMS.</td></tr><tr><td>6</td><td>Communication Security</td><td>No communication security measures are included in the profile.</td></tr></table>
+
+
+Figure 2. Sequence Diagram: HTTP Basic Authentication sequence diagram
+
+<table><tr><td>7</td><td>Remark(s)</td><td>Please note, that the encoding of the basic authentication password in OCPP 2.1 (A00.FR.205) differs from how this was done in OCPP 1.6.</td></tr></table>
+
+# 1.3.3. Unsecured Transport with Basic Authentication Profile - Requirements
+
+Table 15. Security Profile 1 - Unsecured Transport with Basic Authentication - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.201</td><td></td><td>The Unsecured Transport with Basic Authentication Profile SHOULD only be used in trusted networks.</td></tr><tr><td>A00.FR.202</td><td></td><td>The Charging Station SHALL authenticate itself to the CSMS using HTTP Basic authentication [18]</td></tr><tr><td>A00.FR.203</td><td>A00.FR.202</td><td>The client, i.e. the Charging Station, SHALL provide a username and password with every connection request.</td></tr><tr><td>A00.FR.204</td><td>A00.FR.203</td><td>The username SHALL be equal to the Charging Station identity, which is the identifying string of the Charging Station as it uses it in the OCPP-J connection URL. When using Basic Authentication, the Charging Station identity may not contain the character"." Otherwise the CSMS may be unable to separate the username from the password.</td></tr><tr><td>A00.FR.205</td><td></td><td>The password SHALL be stored in the BasicAuthPassword configuration variable. It SHALL be a randomly chosen passwordString with a sufficiently high entropy, consisting of minimum 16 and a maximum as defined by the maxLimit of configuration variable BasicAuthPassword, which must be at least 40 characters and at most 64. The password SHALL be sent as a UTF-8 encoded string (NOT encoded into octet string or base64).</td></tr><tr><td>A00.FR.206</td><td>A00.FR.203</td><td>With HTTP Basic, the username and password are transmitted in clear text, encoded in base64 only. Hence, it is RECOMMENDED that this mechanism will only be used over connections that are already secured with other means, such as VPNs.</td></tr><tr><td>A00.FR.207</td><td>A00.FR.202</td><td>The CSMS SHALL validate that Charging Station identity and the Basic Authentication password match with username and password in the authorization header of the connection request.</td></tr></table>
+
+# 1.3.4. TLS with Basic Authentication Profile - 2
+
+Table 16. Security Profile 2 - TLS with Basic Authentication
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>TLS with Basic Authentication</td></tr><tr><td>2</td><td>Profile No.</td><td>2</td></tr><tr><td>3</td><td>Description</td><td>In the TLS with Basic Authentication profile, the communication channel is secured using Transport Layer Security (TLS). The CSMS authenticates itself using a TLS server certificate. The Charging Stations authenticate themselves using HTTP Basic Authentication.</td></tr><tr><td>4</td><td>Charging Station Authentication</td><td>For Charging Station authentication HTTP Basic authentication is used.Because TLS is used in this profile, the password will be sent encrypted, reducing the risks of using this authentication method.</td></tr><tr><td>5</td><td>CSMS Authentication</td><td>The Charging Station authenticates the CSMS via the TLS server certificate.</td></tr><tr><td>6</td><td>Communication Security</td><td>The communication between Charging Station and CSMS is secured using TLS.</td></tr></table>
+
+
+Figure 3. Sequence Diagram: TLS with Basic Authentication sequence diagram
+
+<table><tr><td>7</td><td>Remark(s)</td><td>TLS allows a number of configurations, not all of which provide sufficient security. The requirements below describe the configurations allowed for OCPP.
+The Charging Station should include the same header as used in Basic Auth RFC 2617, while requesting to upgrade the http connection to a websocket connection as described in RFC 6455. The server first needs to validate the Authorization header before upgrading the connection.
+Example:
+GET /ws HTTP/1.1
+Remote-Addr: 127.0.0.1
+UPGRADE: websocket
+CONNECTION: Upgrade
+HOST: 127.0.0.1:9999
+ORIGIN: http://127.0.0.1:9999
+SEC-WEBSOCKET-KEY: Pb4obWo2214EfaPQuazMjA==
+SEC-WEBSOCKET-VERSION: 13
+AUTHORIZATION: Basic <Base64 encoded(<ChargePointId>:_<AuthorizationKey>)</td></tr><tr><td></td><td></td><td>Please note, that the encoding of the basic authentication password in OCPP 2.1 (A00.FR.304) differs from how this was done in OCPP 1.6.</td></tr></table>
+
+# 1.3.5. TLS with Basic Authentication Profile - Requirements
+
+Table 17. Security Profile 2 - TLS with Basic Authentication - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.301</td><td></td><td>The Charging Station SHALL authenticate itself to the CSMS using HTTP Basic authentication [18] (Same as A00.FR.202)</td></tr><tr><td>A00.FR.302</td><td>A00.FR.301</td><td>The client, i.e. the Charging Station, SHALL provide a username and password with every connection request. (Same as A00.FR.203)</td></tr><tr><td>A00.FR.303</td><td>A00.FR.302</td><td>The username SHALL be equal to the Charging Station identity, which is the identifying string of the Charging Station as it uses it in the OCPP-J connection URL. When using Basic Authentication, the Charging Station identity may not contain the character"." Otherwise the CSMS may be unable to separate the username from the password. (Same as A00.FR.204)</td></tr><tr><td>A00.FR.304</td><td>A00.FR.302</td><td>The password SHALL be stored in the BasicAuthPassword Configuration Variable. It SHALL be a randomly chosen passwordString with a sufficiently high entropy, consisting of minimum 16 and a maximum as defined by the maxLimit of configuration variable BasicAuthPassword, which must be at least 40 characters and at most 64. The password SHALL be sent as a UTF-8 encoded string (NOT encoded into octet string or base64). (Same as A00.FR.205)</td></tr><tr><td>A00.FR.306</td><td></td><td>The CSMS SHALL act as the TLS server.</td></tr><tr><td>A00.FR.307</td><td></td><td>The CSMS SHALL authenticate itself by using the CSMS certificate as server side certificate.</td></tr><tr><td>A00.FR.308</td><td></td><td>The Charging Station SHALL verify the certification path of the CSMS's certificate according to the path validation rules established in Section 6 of [3].</td></tr><tr><td>A00.FR.309</td><td></td><td>The Charging Station SHALL verify that the commonName includes the CSMS's FQDN.</td></tr><tr><td>A00.FR.310</td><td>If the CSMS does not own a valid certificate, or if the certification path is invalid</td><td>The Charging Station SHALL trigger an InvalidCsmsCertificate security event (See part 2 appendices for the full list of security events).</td></tr><tr><td>A00.FR.311</td><td>A00.FR.310</td><td>The Charging Station SHALL terminate the connection.</td></tr><tr><td>A00.FR.312</td><td></td><td>The communication channel SHALL be secured using Transport Layer Security (TLS) [4].</td></tr><tr><td>A00.FR.313</td><td></td><td>The Charging Station and CSMS SHALL only use TLS v1.2 or above.</td></tr><tr><td>A00.FR.314</td><td></td><td>Both of these endpoints SHALL check the version of TLS used.</td></tr><tr><td>A00.FR.315</td><td>A00.FR.314 AND The CSMS detects that the Charging Station only allows connections using an older version of TLS, or only allows SSL</td><td>The CSMS SHALL terminate the connection.</td></tr><tr><td>A00.FR.316</td><td>A00.FR.314 AND The Charging Station detects that the CSMS only allows connections using an older version of TLS, or only allows SSL</td><td>The Charging Station SHALL trigger an InvalidTLSVersion security event AND terminate the connection (See part 2 appendices for the full list of security events).NOTE: This is a critical security event that will need to be queued and sent to CSMS once a successful connection has 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.</td></tr><tr><td>A00.FR.317</td><td></td><td>TLS SHALL be implemented as in [4] or its successor standards without any modifications.</td></tr><tr><td>A00.FR.318</td><td></td><td>The CSMS SHALL support at least the following four cipher suites:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_GCM_SHA384Note: The CSMS will have to provide 2 different certificates to support both cipher suites. Also when using security profile 3, the CSMS should be capable of generating client side certificates for both cipher suites.</td></tr><tr><td>A00.FR.319</td><td></td><td>The Charging Station SHALL support at least the cipher suites:(TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256ANDTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384)OR(TLS_RSA_WITH_AES_128_GCM_SHA256ANDTLS_RSA_WITH_AES_256_GCM_SHA384)Note 1: TLS_RSA does not support forward secrecy, therefore TLS_ECDHE is RECOMMENDED. In certain jurisdictions forward secrecy is mandatory. Furthermore, if the Charging Station detects an algorithm used that is not secure, it SHOULD trigger an InvalidTLSCipherSuite security event (See part 2 appendices for the full list of security events).Note 2: Please note that ISO15118-2 prescribes to implement the following cipher suites for the communication between EV and Charging Station:TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256</td></tr><tr><td>A00.FR.320</td><td></td><td>The Charging Station and CSMS SHALL NOT use cipher suites that use cryptographic primitives marked as unsuitable for legacy use in [1]. This will mean that when one (or more) of the cipher suites described in this specification becomes marked as unsuitable for legacy use, it SHALL NOT be used anymore.</td></tr><tr><td>A00.FR.321</td><td></td><td>The TLS Server and Client SHALL NOT use TLS compression methods to avoid compression side-channel attacks and to ensure interoperability as described in Section 6 of [10].</td></tr><tr><td>A00.FR.322</td><td>A00.FR.320 AND The CSMS detects that the Charging Station only allows connections using one of these suites</td><td>The CSMS SHALL terminate the connection.</td></tr><tr><td>A00.FR.323</td><td>A00.FR.320 AND The Charging Station detects that the CSMS only allows connections using one of these suites</td><td>The Charging Station SHALL trigger an InvalidTLSCipherSuite security event AND terminate the connection (See part 2 appendices for the full list of security events).</td></tr><tr><td>A00.FR.324</td><td>A00.FR.302</td><td>The CSMS SHALL validate that Charging Station identity and the Basic Authentication password match with username and password in the authorization header of the connection request.</td></tr></table>
+
+# 1.3.6. TLS with Client Side Certificates Profile - 3
+
+Table 18. Security Profile 3 - TLS with Client Side Certificates
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>TLS with Client Side Certificates</td></tr><tr><td>2</td><td>Profile No.</td><td>3</td></tr><tr><td>3</td><td>Description</td><td>In the TLS with Client Side Certificates profile, the communication channel is secured using Transport Layer Security (TLS). Both the Charging Station and CSMS authenticate themselves using certificates.</td></tr><tr><td>4</td><td>Charging Station Authentication</td><td>The CSMS authenticates the Charging Station via the TLS client certificate.</td></tr><tr><td>5</td><td>CSMS Authentication</td><td>The Charging Station authenticates the CSMS via the TLS server certificate.</td></tr><tr><td>6</td><td>Communication Security</td><td>The communication between Charging Station and CSMS is secured using TLS.</td></tr></table>
+
+
+Figure 4. Sequence Diagram: TLS with Client Side Certificates
+
+<table><tr><td>7</td><td>Remark(s)</td><td>N/a</td></tr></table>
+
+# 1.3.7. TLS with Client Side Certificates Profile - Requirements
+
+Table 19. Security Profile 3 - TLS with Client Side Certificates - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.401</td><td></td><td>The Charging Station SHALL authenticate itself to the CSMS using the Charging Station certificate.</td></tr><tr><td>A00.FR.402</td><td></td><td>The Charging Station certificate SHALL be used as a TLS client side certificate</td></tr><tr><td>A00.FR.403</td><td></td><td>The CSMS SHALL verify the certification path of the Charging Station's certificate according to the path validation rules established in Section 6 of [3]</td></tr><tr><td>A00.FR.404</td><td></td><td>The CSMS SHALL verify that the certificate is owned by the CSO (or an organization trusted by the CSO) by checking that the O (organizationName) RDN in the subject field of the certificate contains the CSO name.</td></tr><tr><td>A00.FR.405</td><td></td><td>The CSMS SHALL verify that the certificate belongs to this Charging Station by checking that the CN (commonName) RDN in the subject field of the certificate contains the unique serial number of the Charging Station (see Certificate Properties).</td></tr><tr><td>A00.FR.406</td><td>If the Charging Station certificate is not owned by the CSO, for instance immediately after installation</td><td>it is RECOMMENDED to update the certificate before continuing communication with the Charging Station (also see Installation)</td></tr><tr><td>A00.FR.407</td><td>NOT A00.FR.429 AND If the Charging Station does not own a valid certificate, or if the certification path is invalid</td><td>The CSMS SHALL terminate the connection.</td></tr><tr><td>A00.FR.408</td><td>A00.FR.407 OR A00.FR.429</td><td>It is RECOMMENDED to log a security eventInvalidChargingStationCertificate in the CSMS.</td></tr><tr><td>A00.FR.409</td><td></td><td>The CSMS SHALL act as the TLS server. (Same as A00.FR.306)</td></tr><tr><td>A00.FR.410</td><td></td><td>The CSMS SHALL authenticate itself by using the CSMS certificate as server side certificate. (Same as A00.FR.307)</td></tr><tr><td>A00.FR.411</td><td></td><td>The Charging Station SHALL verify the certification path of the CSMS's certificate according to the path validation rules established in Section 6 of [3]. (Same as A00.FR.308)</td></tr><tr><td>A00.FR.412</td><td></td><td>The Charging Station SHALL verify that the commonName matches the CSMS's FQDN. (Same as A00.FR.309)</td></tr><tr><td>A00.FR.413</td><td>If the CSMS does not own a valid certificate, or if the certification path is invalid</td><td>The Charging Station SHALL trigger an InvalidCsmsCertificate security event (See part 2 appendices for the full list of security events). (Same as A00.FR.310)</td></tr><tr><td>A00.FR.414</td><td>A00.FR.413</td><td>The Charging Station SHALL terminate the connection. (Same as A00.FR.311)</td></tr><tr><td>A00.FR.415</td><td></td><td>The communication channel SHALL be secured using Transport Layer Security (TLS) [4]. (Same as A00.FR.312)</td></tr><tr><td>A00.FR.416</td><td></td><td>The Charging Station and CSMS SHALL only use TLS v1.2 or above. (Same as A00.FR.313)</td></tr><tr><td>A00.FR.417</td><td></td><td>Both of these endpoints SHALL check the version of TLS used. (Same as A00.FR.314)</td></tr><tr><td>A00.FR.418</td><td>A00.FR.417ANDThe CSMS detects that the Charging Station only allows connections using an older version of TLS, or only allows SSL</td><td>The CSMS SHALL terminate the connection. (Same as A00.FR.315)</td></tr><tr><td>A00.FR.419</td><td>A00.FR.417ANDThe Charging Station detects that the CSMS only allows connections using an older version of TLS, or only allows SSL</td><td>The Charging Station SHALL trigger an InvalidTLSVersion security event AND terminate the connection (See part 2 appendices for the full list of security events). (Same as A00.FR.316)NOTE: This is a critical security event that will need to be queued and sent to CSMS once a connection has 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.</td></tr><tr><td>A00.FR.420</td><td></td><td>TLS SHALL be implemented as in [4] or its successor standards without any modifications. (Same as A00.FR.317)</td></tr><tr><td>A00.FR.421</td><td></td><td>The CSMS SHALL support at least the following four cipher suites:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_GCM_SHA384(Same as A00.FR.318)Note: The CSMS will have to provide 2 different certificates to support both cipher suites. Also when using security profile 3, the CSMS should be capable of generating client side certificates for both cipher suites.</td></tr><tr><td>A00.FR.422</td><td></td><td>The Charging Station SHALL support at least the cipher suites:(TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256ANDTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384)OR(TLS_RSA_WITH_AES_128_GCM_SHA256ANDTLS_RSA_WITH_AES_256_GCM_SHA384)(Same as A00.FR.319)Note 1: TLS_RSA does not support forward secrecy, therefore TLS_ECDEHIES RECOMMENDED. In certain jurisdictions formward secrecy is mandatory. Furthermore, if the Charging Station detects an algorithm used that is not secure, it SHOULD trigger an InvalidTLSCipherSuite security event (See part 2 appendices for the full list of security events).Note 2: Please note that ISO15118-2 prescribes to implement the following cipher suites for the communication between EV and Charging Station:TLS_ECDEH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDEH_ECDSA_WITH_AES_128_CBC_SHA256</td></tr><tr><td>A00.FR.423</td><td></td><td>The Charging Station and CSMS SHALL NOT use cipher suites that use cryptographic primitives marked as unsuitable for legacy use in [1]. This will mean that when one (or more) of the cipher suites described in this specification becomes marked as unsuitable for legacy use, it SHALL NOT be used anymore. (Same as A00.FR.320)</td></tr><tr><td>A00.FR.424</td><td></td><td>The TLS Server and Client SHALL NOT use TLS compression methods to avoid compression side-channel attacks and to ensure interoperability as described in Section 6 of [10]. (Same as A00.FR.321)</td></tr><tr><td>A00.FR.425</td><td>A00.FR.424ANDIf the CSMS detects that the Charging Station only allows connections using one of these suites</td><td>The CSMS SHALL terminate the connection. (Same as A00.FR.322)</td></tr><tr><td>A00.FR.426</td><td>A00.FR.424ANDThe Charging Station detects that the CSMS only allows connections using one of these suites</td><td>The Charging Station SHALL trigger an InvalidTLSCipherSuite security event AND terminate the connection (See part 2 appendices for the full list of security events). (Same as A00.FR.323)</td></tr><tr><td>A00.FR.427</td><td></td><td>A unique Charging Station certificate SHALL be used for each Charging Station.</td></tr><tr><td>A00.FR.428</td><td></td><td>The Charging Station Certificate MAY be the same certificate as the SECC Certificate in ISO15118-2, used to set up a TLS connection between the Charging Station and an Electric Vehicle.</td></tr><tr><td>A00.FR.429</td><td>If Charging Station certificate has been expired AND CSMS has been explicitly configured to accept a connection by this specific Charging Station with an expired certificate.</td><td>CSMS MAY accept this Charging Station in a BootNotification - Pending state (use case B02) after which it SHALL immediately execute A02 - Update Charging Station Certificate by request of CSMS to renew the certificate.</td></tr><tr><td>A00.FR.430</td><td>If the Charging Station certificate has expired</td><td>The Charging Station SHOULD still attempt to establish a connection with the CSMS and leave the decision to accept the connection up to the CSMS.</td></tr></table>
+
+# 1.4. Keys used in OCPP
+
+This section is normative.
+
+OCPP uses a number of public private key pairs for its security, see below Table. To manage the keys on the Charging Station, messages have been added to OCPP. Updating keys on the CSMS or at the manufacturer is out of scope for OCPP. If TLS with Client Side certificates is used, the Charging Station requires a "Charging Station certificate" for authentication against the CSMS.
+
+Table 20. Certificates used in the OCPP security specification
+
+<table><tr><td>Certificate</td><td>Private Key Stored At</td><td>Description</td></tr><tr><td>CSMS Certificate</td><td>CSMS</td><td>Key used to authenticate the CSMS.</td></tr><tr><td>Charging Station Certificate</td><td>Charging Station</td><td>Key used to authenticate the Charging Station.</td></tr><tr><td>Firmware Signing Certificate</td><td>Manufacturer</td><td>Key used to verify the firmware signature.</td></tr><tr><td>SECC Certificate</td><td>Charging Station</td><td>Certificate used by ISO15118-2 to set up a TLS connection between the Charging Station and an Electric Vehicle.</td></tr></table>
+
+# 1.4.1. Certificate Properties
+
+This section is normative.
+
+Table 21. Certificate Properties requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.501</td><td></td><td>All certificates SHALL use a private key that provides security equivalent to a symmetric key of at least 112 bits according to Section 5.6.1 of [17]. This is the key size that NIST recommends for the period 2011-2030.</td></tr><tr><td>A00.FR.502</td><td>A00.FR.501ANDRSA or DSA</td><td>This translates into a key that SHALL be at least 2048 bits long.</td></tr><tr><td>A00.FR.503</td><td>A00.FR.501ANDelliptic curve cryptography</td><td>This translates into a key that SHALL be at least 224 bits long.</td></tr><tr><td>A00.FR.504</td><td></td><td>For all cryptographic operations, only the algorithms recommended by BSI in [12], which are suitable for use in future systems, SHALL be used. This restriction includes the signing of certificates in the certificate hierarchy</td></tr><tr><td>A00.FR.505</td><td></td><td>For signing by the certificate authority RSA-PSS, or ECDSA SHOULD be used.</td></tr><tr><td>A00.FR.506</td><td></td><td>For computing hash values the SHA256 algorithm SHOULD be used.</td></tr><tr><td>A00.FR.507</td><td></td><td>The certificates SHALL be stored and transmitted in the X.509 format encoded in Privacy-Enhanced Mail (PEM) format.</td></tr><tr><td>A00.FR.508</td><td></td><td>All certificates SHALL include a serial number.</td></tr><tr><td>A00.FR.509</td><td></td><td>The subject field of the certificate SHALL contain the organization name of the certificate owner in the O (organizationName) RDN.</td></tr><tr><td>A00.FR.510</td><td></td><td>For the CSMS certificate, the subject field SHALL contain the FQDN of the endpoint of the server in the CN (commonName) RDN.</td></tr><tr><td>A00.FR.511</td><td></td><td>For the Charging Station certificate, the subject field SHALL contain a CN (commonName) RDN which consists of the unique serial number of the Charging Station. This serial number SHALL NOT be in the format of a URL or an IP address so that Charging Station certificates can be differentiated from CSMS certificates.Note: According to RFC 2818, if a subjectAltName extension of type dnsName is present, that must be used as the identity. This would be incompliant with OCPP and ISO 15118. Therefore it SHOULD NOT be used in Charging Station and CSMS certificates.It is allowed to use the subjectAltName extension of type dnsName for a CSMS, when the CSMS has multiple network paths to reach it (for example, via a private APN + VPN using its IP address in the VPN and via public Internet using a named URL).</td></tr><tr><td>A00.FR.512</td><td></td><td>For all certificates the X.509 Key Usage extension [19] SHOULD be used to restrict the usage of the certificate to the operations for which it will be used.</td></tr><tr><td>A00.FR.513</td><td></td><td>If the Charging Station Certificate is also used as SECC Certificate in the ISO 15118 protocol, the certificate needs to meet the requirements in ISO 15118-2 or ISO 15118-20.</td></tr><tr><td>A00.FR.514</td><td></td><td>For all certificates it is strongly RECOMMENDED NOT to use the X.509 Extended Key Usage extension, to be compatible with the ISO 15118 standard. There are alternative mechanisms available.</td></tr></table>
+
+# 1.4.2. Certificate Hierarchy
+
+This section is normative.
+
+The OCPP protocol supports the use of two separate certificate hierarchies:
+
+1. The Charging Station Operator hierarchy which contains the CSMS, and Charging Station certificates.
+2. The Manufacturer hierarchy which contains the Firmware Signing certificate.
+
+The CSMS can update the CSO root certificates stored on the Charging Station using the InstallCertificateRequest message.
+
+Table 22. Certificate Hierarchy requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.601</td><td></td><td>The Charging Station Operator MAY act as a certificate authority for the Charging Station Operator hierarchy</td></tr><tr><td>A00.FR.602</td><td>A00.FR.601</td><td>The Charging Station Operator MAY for instance follow the certificate hierarchy described in Appendices E and F of ISO15118-2 and use the CSO Sub-CA 2 certificate to sign the CSMS and Charging Station certificates. This could give the advantage that the online verification of Charging Station client side certificates can be done within the Charging Station Operator's networks, simplifying the network architecture.</td></tr><tr><td>A00.FR.603</td><td></td><td>The private keys belonging to the CSO root certificates MUST be well protected.</td></tr><tr><td>A00.FR.604</td><td></td><td>As the Manufacturer is usually a separate organization from the Charging Station Operator, a trusted third party SHOULD be used as a certificate authority. This is essential to have non-repudiation of firmware images.</td></tr></table>
+
+# NOTE
+
+It is not recommended to have preinstalled well-known root CA certificates on a Charging Station like in operating systems or browsers, like for example a CA bundle. Only root and intermediate certificates part of the Charging Station Operator hierarchy should be used for the OCPP connection, as described by section Certificate Hierarchy. Trusting many additional well-known root CA certificates creates security risks.
+
+# 1.5. Certificate Revocation
+
+This section is normative.
+
+In some cases a certificate may become invalid prior to the expiration of the validity period. Such cases include changes of the organization name, or the compromise or suspected compromise of the certificate's private key. In such cases, the certificate needs to be revoked or indicate it is no longer valid. The revocation of the certificate does not mean that the connection needs to be closed as the connection can stay open longer than 24 hours.
+
+Different methods are recommended for certificate revocation, see below Table.
+
+Table 23. Recommended revocation methods for the different certificates.
+
+<table><tr><td>Certificate</td><td>Revocation</td></tr><tr><td>CSMS certificate</td><td>Fast expiration</td></tr><tr><td>Charging Station certificate</td><td>Online verification</td></tr><tr><td>Firmware Signing certificate</td><td>Online verification</td></tr></table>
+
+Table 24. Certificate Revocation requirements
+Table 25. Certificate Installation requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.701</td><td></td><td>Fast expiration SHOULD be used to revoke the CSMS certificate. (See Note 1)</td></tr><tr><td>A00.FR.702</td><td></td><td>The CSMS SHOULD use online certificate verification to verify the validity of the Charging Station certificates.</td></tr><tr><td>A00.FR.703</td><td></td><td>It is RECOMMENDED that a separate certificate authority server is used to manage the certificates.</td></tr><tr><td>A00.FR.704</td><td>A00.FR.703</td><td>This server SHOULD also keep track of which certificates have been revoked.</td></tr><tr><td>A00.FR.705</td><td></td><td>The CSMS SHALL verify the validity of the certificate with the certificate authority server. (See Note 2)</td></tr><tr><td>A00.FR.707</td><td></td><td>Prior to providing the certificate for firmware validation to the Charging Station, the CSMS SHOULD validate both, the certificate and the signed firmware update.</td></tr></table>
+
+Note 1: With fast expiration, the certificate is only valid for a short period, less than 24 hours. After that the server needs to request a new certificate from the Certificate Authority, which may be the CSO itself (see section Certificate Hierarchy). This prevents the Charging Stations from needing to implement revocation lists or online certificate verification. This simplifies the implementation of certificate management at the Charging Station and reduces communication costs at the Charging Station side. By requiring fast expiration, if the certificate is compromised, the impact is reduced to only a short period.
+
+When the certificate chain should become compromised, attackers could used forged certificates to trick a Charging Station to connect to a "fake" CSMS. By using fast expiration, the time a Charging Station is vulnerable is greatly reduced.
+
+The Charging Station always communicates with the Certificate Authority through the CSMS, this way, if the Charging Station is compromised, the Charging Station cannot attack the CA directly.
+
+Note 2: This allows for immediate revocation of Charging Station certificates. Revocation of Charging Station certificates will happen for instance when a Charging Station is removed. This is more common than revoking the CSMS certificate, which is normally only done when it is compromised.
+
+# 1.6. Installation
+
+This section is normative.
+
+Unique credentials should be used to authenticate each Charging Station to the CSMS, whether they are the password used for HTTP Basic Authentication (see Charging Station Authentication) or the Charging Station certificate. These unique credentials have to be put on the Charging Station at some point during manufacturing or installation.
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A00.FR.801</td><td></td><td>It is RECOMMENDED that the manufacturer initializes the Charging Station with unique credentials during manufacturing.</td></tr><tr><td>A00.FR.802</td><td>A00.FR.801</td><td>The credentials SHOULD be generated using a cryptographic random number generator, and installed in a secure environment.</td></tr><tr><td>A00.FR.803</td><td>A00.FR.801</td><td>They SHOULD be sent to the CSO over a secure channel, so that the CSO can import them in the CSMS</td></tr><tr><td>A00.FR.804</td><td>If Charging Station certificates are used.</td><td>The manufacturer MAY sign these using their own certificate.</td></tr><tr><td>A00.FR.805</td><td>A00.FR.804</td><td>It is RECOMMENDED that the CSO immediately updates the credentials after installation using the methods described in Section A01 - Update Charging Station Password for HTTP Basic Authentication or A02 - Update Charging Station Certificate by request of CSMS.</td></tr><tr><td>A00.FR.806</td><td>Before the 'factory credentials' have been updated</td><td>The CSMS MAY restrict the functionality that the Charging Station can use. The CSMS can use the BootNotification state: Pending for this. During the Pending state, the CSMS can update the credentials.</td></tr><tr><td>A00.FR.807</td><td>A00.FR.804 AND Charging Station manufacturer certificate has expired</td><td>The CSMS MAY accept a connection by Charging Station in a Pending state after the BootNotification and immediately execute use case A02 - Update Charging Station Certificate by request of CSMS to install a new valid CSO certificate.</td></tr></table>
+
+# Chapter 2. Use cases & Requirements
+
+# A01 - Update Charging Station Password for HTTP Basic Authentication
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Update Charging Station Password for HTTP Basic Authentication</td></tr><tr><td>2</td><td>ID</td><td>A01</td></tr><tr><td>3</td><td>Objective(s)</td><td>This use case defines how to use the BasicAuthPassword, the password used to authenticate Charging Stations in the Basic and TLS with Basic Authentication security profiles.</td></tr><tr><td>4</td><td>Description</td><td>To enable the CSMS to configure a new password for HTTP Basic Authentication, the CSMS can send a new value for the BasicAuthPassword Configuration Variable.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a SetVariablesRequest( ComponentName=SecurityCtrl, VariableName=BasicAuthPassword) to the Charging Station.
+2. The Charging Station responds with SetVariablesResponse and the status Accepted.
+3. The Charging Station disconnects its current connection. (Storing any queued messages)
+4. The Charging Station connects to the CSMS with the new password.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Security Profile: Basic Security Profile or TLS with Basic Authentication in use.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station has reconnected to the CSMS with the new password.
+Failure postcondition:
+If the Charging Station responds to the SetVariablesRequest with a SetVariablesResponse with a status other than Accepted, the Charging Station will keep using the old credentials. The CSMS might treat the Charging Station differently, e.g. by not accepting the Charging Station's boot notifications.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 5. Update Charging Station Password for HTTP Basic Authentication (happy flow)
+
+# A01 - Update Charging Station Password for HTTP Basic Authentication - Requirements
+
+Table 26. A01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A01.FR.01</td><td></td><td>The password SHALL be stored in the configuration variable BasicAuthPassword.</td></tr><tr><td>A01.FR.02</td><td></td><td>To set a Charging Station's basic authorization password via OCPP, the CSMS SHALL send the Charging Station a SetVariablesRequest message with the BasicAuthPassword Configuration Variable.</td></tr><tr><td>A01.FR.03</td><td>A01.FR.02ANDThe Charging Station responds to this SetVariablesRequest with a SetVariablesResponse with status Accepted.</td><td>The CSMS SHALL assume that the authorization key change was successful, and no longer accept the credentials previously used by the Charging Station.</td></tr><tr><td>A01.FR.04</td><td>A01.FR.02ANDThe Charging Station responds to this SetVariablesRequest with a SetVariablesResponse with status other than Accepted</td><td>The CSMS SHALL assume that the Charging Station has NOT changed the password. Therefore the CSMS SHALL keep accepting the old credentials.</td></tr><tr><td>A01.FR.05</td><td>A01.FR.04</td><td>While the CSMS SHALL still accepts a connection from the Charging Station, it MAY restrict the functionality that the Charging Station can use. The CSMS can use the BootNotification state: Pending for this. During the Pending state, the CSMS can for example retry to update the credentials.</td></tr><tr><td>A01.FR.06</td><td></td><td>Different passwords SHOULD be used for different Charging Stations.</td></tr><tr><td>A01.FR.07</td><td></td><td>Passwords SHOULD be generated randomly to ensure that the passwords have sufficient entropy.</td></tr><tr><td>A01.FR.08</td><td></td><td>the CSMS SHOULD only store salted password hashes, not the passwords themselves.</td></tr><tr><td>A01.FR.09</td><td></td><td>the CSMS SHOULD NOT put the passwords in clear-text in log files or debug information. In this way, if the CSMS is compromised not all Charging Station password will be immediately compromised.</td></tr><tr><td>A01.FR.10</td><td></td><td>On the Charging Station the password needs to be stored in clear-text. Extra care SHOULD be taken into storing it securely. Definitions of mechanisms how to securely store the credentials are however not in scope of the OCPP Security Profiles.</td></tr><tr><td>A01.FR.11</td><td>A01.FR.02</td><td>The Charging Station SHALL log the change of an BasicAuthPassword in the Security log.</td></tr><tr><td>A01.FR.12</td><td>A01.FR.11</td><td>The Charging Station SHALL NOT disclose the content of the BasicAuthPassword in its logging. This is to prevent exposure of key material to persons that may have access to a diagnostics file.</td></tr></table>
+
+# A02 - Update Charging Station Certificate by request of CSMS
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Update Charging Station Certificate by request of CSMS</td></tr><tr><td>2</td><td>ID</td><td>A02</td></tr><tr><td>3</td><td>Objective(s)</td><td>To facilitate the management of the Charging Station client side certificate, a certificate update procedure is provided.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS requests the Charging Station to update its key using TriggerMessageRequest with the requestedMessage field set to SignChargingStationCertificate (or SignV2GCertificate/SignV2G20Certificate for separate ISO 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 "Seccld".</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, Certificate Authority Server</td></tr><tr><td></td><td>Scenario description</td><td>SignChargingStationCertificate</td></tr><tr><td></td><td></td><td>1. The CSMS requests the Charging Station to update its certificate using the TriggerMessageRequest with the requestedMessage field set to SignChargingStationCertificate.2. The Charging Station responds with TriggerMessageResponse3. 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.</td></tr><tr><td></td><td>Alternative scenario</td><td>SignV2GCertificate</td></tr><tr><td></td><td></td><td>1. CSMS requests information about component ISO15118Ctrl by sending a GetReportRequest for componentVariable.parent = "ISO15118Ctrl" and componentVariable.variable = "Seccld".2. For each unique Seccld 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 ISO15118Ctrl. (If ISO15118Ctrl only exists as one component at toplevel, then evse can be omitted.)2.2. The Charging Station responds with TriggerMessageResponse2.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 csv in which the CommonName (CN) is set to the value of Seccld and with a hashRootCertificate element that identifies the Certificate Authority to use.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.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The standard configuration variable "OrganizationName" MUST be set. For SignV2GCertificate the variable ISO15118Ctrl.Seccld must be set.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:New Client Side certificate installed in the Charging Station.Failure postcondition:New Client Side certificate is rejected and discarded.</td></tr><tr><td>7</td><td>Error handling</td><td>The CSMS accepts the CSR request from the Charging Station, before forwarding it to the CA. But when the CA cannot be reached, or rejects the CSR, the Charging Station will never be known. The CSMS may do some checks on the CSR, but cannot do all the checks that a CA does, and it does not prevent connection timeout to the CA. When something like this goes wrong, either the CA is offline or the CSR send by the Charging Station is not correct, according to the CA. In both cases this is something an operator at the CSO needs to be notified of. The operator then needs to investigate the issue. When resolved, the operator can re-run A02.</td></tr><tr><td>8</td><td>Remark(s)</td><td>The Charging Station Operator may act as a certificate authority for the Charging Station Operator hierarchy.The applicable Certification Authority SHALL check the information in the CSR.If it is correct, the Certificate Authority SHALL sign the CSR, send it to the CSO, the CSO sends it back to the Charging Station in the CertificateSignedRequest message.The certificate authority SHOULD implement strong measures to keep the certificate signing private keys secure.Even though the messages CertificateSignedRequest (see use cases A02 and A03) and InstallCertificateRequest (use case M05 - Install CA Certificate in a Charging Station) are both used to send certificates, their purposes are different. CertificateSignedRequest is used to return the the Charging Stations own public certificate and V2G certificate(s) signed by a Certificate Authority. InstallCertificateRequest is used to install Root certificates.For V2G certificate handling see use cases M03 - Retrieve list of available certificates from a Charging Station, M04 - Delete a specific certificate from a Charging Station and M06 - Get Charging Station Certificate status.ISO 15118-20 uses higher security algorithms than ISO 15118-2. A Charging Station that supports ISO 15118-20 therefore needs to install two SeccLeafCertificates to support both signature algorithms. In that case CSMS needs to request Charging Station via two TriggerMessageRequests to send a SignCertificateRequest for the ISO 15118-2 certificate and for the ISO 15118-20 certificate. This is reflected in requirements A02.FR.22/23.</td></tr></table>
+
+
+Figure 6. Update Charging Station Certificate
+
+# A02 - Update Charging Station Certificate by request of CSMS - Requirements
+
+Table 27. A02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>A02.FR.01</td><td></td><td>A key update SHOULD be performed after installation of the Charging Station, to change the key from the one initially provisioned by the manufacturer (possibly a default key).</td><td></td></tr><tr><td>A02.FR.02</td><td>After sending a TriggerMessageResponse e.</td><td>The Charging Station SHALL generate a new public / private key pair using one of the key generation functions described in Section 4.2.1.3 of [16].</td><td></td></tr><tr><td>A02.FR.03</td><td>A02.FR.02</td><td>The Charging Station SHALL send the public key in form of a Certificate Signing Request (CSR) as described in RFC 2986 [22] and then PEM encoded, using the SignCertificateRequest message.</td><td></td></tr><tr><td>A02.FR.04</td><td></td><td>The CSMS SHOULD NOT sign the certificate itself, but instead forwards the CSR to a dedicated certificate authority server managing the certificates for the Charging Station infrastructure. The dedicated authority server MAY be operated by the CSO.</td><td></td></tr><tr><td>A02.FR.05</td><td></td><td>The private key generated by the Charging Station during the key update process SHALL NOT leave the Charging Station at any time, and SHALL NOT be readable via OCPP or any other (remote) communication connection.</td><td></td></tr><tr><td>A02.FR.06</td><td></td><td>The Charging Station SHALL verify the validity of the signed certificate in the CertificateSignedRequest message, checking that the current date (at the time of the update) is within the certificate's validity period, the properties in Certificate Properties, and that it is part of the Charging Station Operator certificate hierarchy as described in Certificate Hierarchy.</td><td>When providing a newly signed client certificate with a start period that equals the current time, the CSMS should take into account that there might be a slight discrepancy in the time between the Charging Station and CSMS. This could cause the Charging Station to reject the new certificate, because in case a small time difference exists, the validity period might (just) be in the future for the device.</td></tr><tr><td>A02.FR.07</td><td>If the certificate is not valid.</td><td>The Charging Station SHALL respond to the CertificateSignedRequest with status Rejected AND discard the certificate AND trigger an InvalidChargingStationCertificate security event (See part 2 appendices for the full list of security events).</td><td></td></tr><tr><td>A02.FR.08</td><td>If the certificate is valid.</td><td>The Charging Station SHALL respond to the CertificateSignedRequest with status Accepted AND the Charging Station SHALL switch to the new certificate by reconnecting the websocket and TLS connection.</td><td></td></tr><tr><td>A02.FR.10</td><td>(A02.FR.08 OR A02.FR.28) AND The Charging Station successfully connected to the CSMS using either one of the certificates.</td><td>The Charging Station SHALL discard the client certificate that is NOT in use.</td><td>This is to prevent having multiple client certificates installed at the Charging Station, which the CSMS is unable to manage.</td></tr><tr><td>A02.FR.11</td><td>Upon receipt of a SignCertificateRequest AND It is able to process the request</td><td>The CSMS SHALL set status to Accepted in the SignCertificateResponse.</td><td></td></tr><tr><td>A02.FR.12</td><td>Upon receipt of a SignCertificateRequest AND It is NOT able to process the request</td><td>The CSMS SHALL set status to Rejected in the SignCertificateResponse.</td><td></td></tr><tr><td>A02.FR.13</td><td>When using different certificates for 15118 connections and the Charging Station to CSMS connection</td><td>The Charging Station SHALL set the certificateType field in the SignCertificateRequest to the certificate for which the update was triggered.</td><td></td></tr><tr><td>A02.FR.14</td><td>When receiving a SignCertificateRequest with certificateType included</td><td>It is RECOMMENDED for the CSMS to set the certificateType field in the CertificateSignedRequest to the type of certificate in the SignCertificateRequest.</td><td></td></tr><tr><td>A02.FR.15</td><td>If the Charging Station contains more than one valid V2G certificate, derived from the same root certificate.</td><td>The Charging Station SHALL use the newest certificate, as measured by the start of the validity period.</td><td></td></tr><tr><td>A02.FR.16</td><td>If the configuration variable MaxCertificateChainSize is implemented AND The Charging Station receives a CertificateSignedRequest message with a certificate (chain) with a size that exceeds the set value configured at MaxCertificateChainSize</td><td>The Charging Station MAY respond with a CertificateSignedResponse message with status Rejected .</td><td></td></tr><tr><td>A02.FR.17</td><td>When the CSMS accepted the SignCertificateRequest for a CSR AND the Charging Station did not yet receive a CertificateSignedRequest for this CSR AND the number of seconds configured at CertSigningWaitMinimum has expired</td><td>The Charging Station SHALL send a new SignCertificateRequest for the CSR. Optionally, this CSR MAY be for a newly generated key pair.</td><td></td></tr><tr><td>A02.FR.18</td><td>A02.FR.17</td><td>The Charging Station SHALL double the previous back-off time, starting with the number of seconds configured at CertSigningWaitMinimum, every time the back-off time expires without having received the CertificateSignedRequest for this CSR.</td><td></td></tr><tr><td>A02.FR.19 (2.1)</td><td>A02.FR.18 AND The maximum number of increments is reached</td><td>The Charging Station SHALL stop resending the SignCertificateRequest, until it is requested by the CSMS via a TriggerMessageRequest for SignChargingStationCertificate, SignV2GCertificate, SignV2G20Certificate or SignCombinedCertificate.</td><td></td></tr><tr><td>A02.FR.20 (2.1)</td><td>A02.FR.07</td><td>The Charging Station SHALL NOT initiate the back-off mechanism and resend the SignCertificateRequest, until this is requested by the CSMS via a TriggerMessageRequest for SignChargingStationCertificate, SignV2GCertificate, SignV2G20Certificate or SignCombinedCertificate.</td><td></td></tr><tr><td>A02.FR.21</td><td>When the Charging Station receives a SignCertificateResponse with status Rejected, in response to a SignCertificateRequest with certificateType V2GCertificate</td><td>It is RECOMMENDED to turn off ISO15118PnCEnabled until the Charging Station has been rebooted.</td><td></td></tr><tr><td>A02.FR.22(2.1)</td><td>A02.FR.02 AND requestedMessage = SignV2GCertificate in TriggerMessageRequest</td><td>Charging Station SHALL send a SignCertificateRequest message for a V2G certificate for ISO 15118-2.</td><td></td></tr><tr><td>A02.FR.23(2.1)</td><td>A02.FR.02 AND requestedMessage = SignV2G20Certificate in TriggerMessageRequest</td><td>Charging Station SHALL send a SignCertificateRequest message for a V2G certificate for ISO 15118-20.</td><td></td></tr><tr><td>A02.FR.24(2.1)</td><td></td><td>Charging Station SHOULD add a requestId to SignCertificateRequest to be able to match the request to the resulting CertificateSignedRequest message.</td><td></td></tr><tr><td>A02.FR.25(2.1)</td><td>When CSMS receives a SignCertificateRequest with a field requestId</td><td>CSMS SHALL include this requestId in the resulting CertificateSignedRequest message.</td><td></td></tr><tr><td>A02.FR.26(2.1)</td><td>When Charging Station receives a CertificateSignedRequest with an unknown requestId</td><td>Charging Station SHALL respond with a CertificateSignedResponse with status = Rejected.</td><td></td></tr><tr><td>A02.FR.27(2.1)</td><td>When certificateType in SignCertificateRequest is SignV2GCertificate or SignV2G20Certificate</td><td>Charging Station SHOULD include hashRootCertificate in SignCertificateRequest with the certificate hash of the Root CA to identify the Certificate Authority to use.</td><td></td></tr><tr><td>A02.FR.28</td><td>A02.FR.08 AND the charging station was not able to successfully connect to any of the configured entries of NetworkConfigurati onPriority using the new certificate AND The Charging Station supports either one or both reconnection mechanisms described at requirements; B10.FR.07 and B10.FR.08.</td><td>The Charging Station SHALL for the reconnection mechanism described at B10.FR.07 fallback to the old client certificate AND for the reconnection mechanism described at B10.FR.08 alternate between using the old and new client certificate after all NetworkConfigurationPriority entries.</td><td>As described by requirement B10.FR.09, the Charging Station SHOULD NOT stop trying to reconnect to the CSMS. This is to prevent the Charging Station from becoming a stranded asset.</td></tr><tr><td>A02.FR.29</td><td>A02.FR.10 AND The Charging Station discarded the new client certificate.</td><td>The Charging Station SHOULD send a SecurityEventNotification DiscardedRenewedClientCertificate to the CSMS.</td><td>Otherwise the CSMS is not aware that the Charging Station discarded the new client certificate and the CSMS should again trigger a client certificate renewal.</td></tr></table>
+
+# A03 - Update Charging Station Certificate initiated by the Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Update Charging Station Certificate initiated by the Charging Station</td></tr><tr><td>2</td><td>ID</td><td>A03</td></tr><tr><td>3</td><td>Objective(s)</td><td>To facilitate the management of the Charging Station client side certificate, a certificate update procedure is provided.</td></tr><tr><td>4</td><td>Description</td><td>The Charging Station detects that the certificate ChargingStationCertificate or V2GCertificate for ISO 15118-2 or V2G20Certificate for ISO 15118-20) it is using, will expire in one month. The Charging Station initiates the process to update its key using SignCertificateRequest, indicating the requested certificate in the certificateType field.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, Certificate Authority Server</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station detects that the Charging Station certificate is due to expire.
+2. The Charging Station generates a new public / private key pair.
+3. The Charging Station sends a SignCertificateRequest to the CSMS containing the applicable CertificateSigningUse.
+4. The CSMS responds with a SignCertificateResponse, with status Accepted.
+5. The CSMS forwards the CSR to the Certificate Authority Server.
+6. Certificate Authority Server signs the certificate.
+7. The Certificate Authority Server returns the Signed Certificate to the CSMS.
+8. The CSMS sends a CertificateSignedRequest to the Charging Station.
+9. The Charging Station verifies the signed certificate.
+10. The Charging Station responds with a CertificateSignedResponse to the CSMS with the status Accepted or Rejected.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The standard configuration variable OrganizationName MUST be set.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+New Client Side certificate installed in the Charging Station.
+Failure postcondition:
+New Client Side certificate is rejected and discarded.</td></tr><tr><td>7</td><td>Error handling</td><td>The CSMS accepts the CSR request from the Charging Station, before forwarding it to the CA. But when the CA cannot be reached, or rejects the CSR, the Charging Station will never be known. The CSMS may do some checks on the CSR, but cannot do all the checks that a CA does, and it does not prevent connection timeout to the CA. When something like this goes wrong, either the CA is offline or the CSR send by the Charging Station is not correct, according to the CA. In both cases this is something an operator at the CSO needs to be notified of. The operator then needs to investigate the issue. When resolved, the operator can re-run A02.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Same remarks as in A02 - Update Charging Station Certificate by request of CSMS apply.</td></tr></table>
+
+
+Figure 7. Update Charging Station Certificate initiated by Charging Station
+
+# A03 - Update Charging Station Certificate initiated by the Charging Station - Requirements
+
+Table 28. A03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>A03.FR.01</td><td></td><td>A key update MAY be performed after installation of the Charging Station, to change the key from the one initially provisioned by the manufacturer (possibly a default key).</td><td></td></tr><tr><td>A03.FR.02</td><td>When the Charging Station detects that the current Charging Station certificate will expire in one month.</td><td>The Charging Station SHALL generate a new public / private key pair using one of the key generation functions described in Section 4.2.1.3 of [16].</td><td></td></tr><tr><td>A03.FR.03</td><td>A03.FR.02</td><td>The Charging Station SHALL send the public key in form of a Certificate Signing Request (CSR) as described in RFC 2986 [22] and then PEM encoded, using the SignCertificateRequest message. (Same as A02.FR.03)</td><td></td></tr><tr><td>A03.FR.04</td><td></td><td>The CSMS SHOULD NOT sign the certificate itself, but instead forwards the CSR to a dedicated certificate authority server managing the certificates for the Charging Station infrastructure. The dedicated authority server MAY be operated by the CSO. (Same as A02.FR.04)</td><td></td></tr><tr><td>A03.FR.05</td><td></td><td>The private key generated by the Charging Station during the key update process SHALL NOT leave the Charging Station at any time, and SHALL NOT be readable via OCPP or any other (remote) communication connection. (Same as A02.FR.05)</td><td></td></tr><tr><td>A03.FR.06</td><td></td><td>The Charging Station SHALL verify the validity of the signed certificate in the CertificateSignedRequest message, checking that the current date (at the time of the update) is within the certificate's validity period, the properties in Certificate Properties, and that it is part of the Charging Station Operator certificate hierarchy as described in Certificate Hierarchy. (Same as A02.FR.06)</td><td>When providing a newly signed client certificate with a start period that equals the current time, the CSMS should take into account that there might be a slight discrepancy in the time between the Charging Station and CSMS. This could cause the Charging Station to reject the new certificate, because in case a small time difference exists, the validity period might (just) be in the future for the device.</td></tr><tr><td>A03.FR.07</td><td>If the certificate is not valid.</td><td>The Charging Station SHALL respond to the CertificateSignedRequest with status Rejected AND discard the certificate AND trigger an InvalidChargingStationCertificate security event (See part 2 appendices for the full list of security events). (Same as A02.FR.07)</td><td></td></tr><tr><td>A03.FR.08</td><td>If the certificate is valid.</td><td>The Charging Station SHALL respond to the CertificateSignedRequest with status Accepted AND the Charging Station SHALL switch to the new certificate by reconnecting the websocket and TLS connection. (Same as A02.FR.08)</td><td></td></tr><tr><td>A03.FR.10</td><td>(A03.FR.08 OR A03.FR.24) AND The Charging Station successfully connected to the CSMS using either one of the certificates.</td><td>The Charging Station SHALL discard the client certificate that is NOT in use. (Same as A02.FR.10)</td><td>This is to prevent having multiple client certificates installed at the Charging Station, which the CSMS is unable to manage.</td></tr><tr><td>A03.FR.11</td><td>Upon receipt of a SignCertificateRequest AND It is able to process the request</td><td>The CSMS SHALL set status to Accepted in the SignCertificateResponse. (Same as A02.FR.11)</td><td></td></tr><tr><td>A03.FR.12</td><td>Upon receipt of a SignCertificateRequest AND It is NOT able to process the request</td><td>The CSMS SHALL set status to Rejected in the SignCertificateResponse. (Same as A02.FR.12)</td><td></td></tr><tr><td>A03.FR.13</td><td>When using different certificates for 15118 connections and the Charging Station to CSMS connection</td><td>The Charging Station SHALL include the certificateType field in the SignCertificateRequest to specify which certificate it wants to update. (Same as A02.FR.13)</td><td></td></tr><tr><td>A03.FR.14</td><td>When receiving a SignCertificateRequest with certificateType included</td><td>It is RECOMMENDED for the CSMS to set the certificateType field in the CertificateSignedRequest to the type of certificate in the SignCertificateRequest. (Same as A02.FR.14)</td><td></td></tr><tr><td>A03.FR.15</td><td>If the Charging Station contains more than one valid V2G certificate, derived from the same root certificate.</td><td>The Charging Station SHALL use the newest certificate, as measured by the start of the validity period. (Same as A02.FR.15)</td><td></td></tr><tr><td>A03.FR.16</td><td>If the configuration variable MaxCertificateChainSize is implemented AND The Charging Station receives a CertificateSignedRequest message with a certificate (chain) with a size that exceeds the set value configured at MaxCertificateChainSize</td><td>The Charging Station MAY respond with a CertificateSignedResponse message with status Rejected. (Same as A02.FR.16)</td><td></td></tr><tr><td>A03.FR.17</td><td>When the CSMS accepted the SignCertificateRequest for a CSR AND the Charging Station did not yet receive a CertificateSignedRequest for this CSR AND the number of seconds configured at CertSigningWaitMinimum has expired</td><td>The Charging Station SHALL send a new SignCertificateRequest for the CSR. Optionally, this CSR MAY be for a newly generated key pair. (Same as A02.FR.17)</td><td></td></tr><tr><td>A03.FR.18</td><td>A03.FR.17</td><td>The Charging Station SHALL double the previous back-off time, starting with the number of seconds configured at CertSigningWaitMinimum, every time the back-off time expires without having received the CertificateSignedRequest for this CSR. (Same as A02.FR.18)</td><td></td></tr><tr><td>A03.FR.19 (2.1)</td><td>A03.FR.18 AND The maximum number of increments is reached</td><td>The Charging Station SHALL stop resending the SignCertificateRequest, until it is requested by the CSMS via a TriggerMessageRequest for SignChargingStationCertificate, SignV2GCertificate, SignV2G20Certificate or SignCombinedCertificate. (Same as A02.FR.19)</td><td></td></tr><tr><td>A03.FR.20 (2.1)</td><td></td><td>Charging Station SHOULD add a requestId to SignCertificateRequest to be able to match the request to the resulting CertificateSignedRequest message. (Same as A02.FR.24)</td><td></td></tr><tr><td>A03.FR.21 (2.1)</td><td>When CSMS receives a SignCertificateRequest with a field requestId</td><td>CSMS SHALL include this requestId in the resulting CertificateSignedRequest message. (Same as A02.FR.25)</td><td></td></tr><tr><td>A03.FR.22 (2.1)</td><td>When Charging Station receives a CertificateSignedRequest with an unknown requestId</td><td>Charging Station SHALL respond with a CertificateSignedResponse with status = Rejected. (Same as A02.FR.26)</td><td></td></tr><tr><td>A03.FR.23 (2.1)</td><td>When certificateType in SignCertificateRequest is SignV2GCertificate or SignV2G20Certificata</td><td>Charging Station SHOULD include hashRootCertificate in SignCertificateRequest with the certificate hash of the Root CA to identify the Certificate Authority to use.</td><td></td></tr><tr><td>A03.FR.24</td><td>A03.FR.08 AND the charging station was not able to successfully connect to any of the configured entries of NetworkConfigurationPriority using the new certificate AND The Charging Station supports either one or both reconnection mechanisms described at requirements; B10.FR.07 and B10.FR.08.</td><td>The Charging Station SHALL for the reconnection mechanism described at B10.FR.07 fallback to the old client certificate AND for the reconnection mechanism described at B10.FR.08 alternate between using the old and new client certificate after all NetworkConfigurationPriority entries. (Same as A02.FR.28)</td><td>As described by requirement B10.FR.09, the Charging Station SHOULD NOT stop trying to reconnect to the CSMS. This is to prevent the Charging Station from becoming a stranded asset.</td></tr><tr><td>A03.FR.25</td><td>A03.FR.10 AND The Charging Station discarded the new client certificate.</td><td>The Charging Station SHOULD send a SecurityEventNotification DiscardedRenewedClientCertificate to the CSMS. (Same as A02.FR.29)</td><td>Otherwise the CSMS is not aware that the Charging Station discarded the new client certificate and the CSMS may need to trigger a new client certificate renewal.</td></tr></table>
+
+# A04 - Security Event Notification
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Security Event Notification</td></tr><tr><td>2</td><td>ID</td><td>A04</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS of critical security events.</td></tr><tr><td>4</td><td>Description</td><td>This use case allows the Charging Station to immediately inform the CSMS of changes in the system security.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. A critical security event happens.
+2. The Charging Station sends a SecurityEventNotificationRequest to the CSMS.
+3. The CSMS responds with SecurityEventNotificationResponse to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station successfully informs the CSMS of critical security events by sending a SecurityEventNotificationRequest to the CSMS.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>A list of security related events and their 'criticality' is provided in the Appendices (Appendix 1. Security Events)</td></tr></table>
+
+
+Figure 8. Security Event Notification
+
+# A04 - Security Event Notification - Requirements
+
+Table 29. A04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>A04.FR.01</td><td>When a critical security event happens</td><td>The Charging Station SHALL inform the CSMS of the security events by sending a SecurityEventNotificationRequest to the CSMS.</td><td></td></tr><tr><td>A04.FR.02</td><td>A04.FR.01 AND the Charging Station is disconnected.</td><td>Security event notifications MUST be queued with a guaranteed delivery at the CSMS.</td><td></td></tr><tr><td>A04.FR.03</td><td>A04.FR.01</td><td>The CSMS SHALL confirm the receipt of the notification using the SecurityEventNotificationResponse message.</td><td></td></tr><tr><td>A04.FR.04</td><td>When a security event happens (also non-critical)</td><td>The Charging Station SHALL store the security event in a security log.</td><td>It is recommended to implement this log in a rolling format.</td></tr></table>
+
+# A05 - Upgrade Charging Station Security Profile
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Upgrade Charging Station Security Profile</td></tr><tr><td>2</td><td>ID</td><td>A05</td></tr><tr><td>3</td><td>Objective(s)</td><td>The CSO wants to change the security of the OCPP connection between CSMS and a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>Use case when migrating from OCPP 1.6 without security profiles to OCPP 2.1. Before migrating to a security profile, the prerequisites, like installed certificates or password, need to be configured.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sets a new value for the NetworkConfigurationPriority Configuration Variable via SetVariablesRequest, such that the NetworkConnectionProfile for the new security profile becomes first in the list and the existing connection profile becomes second in the list.
+2. The Charging Station responds with a SetVariablesResponse with status Accepted
+3. The CSMS sends a ResetRequest(OnIdle)
+4. The Charging Station reboots and connects via the new primary NetworkConnectionProfile</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The CSO ensures that a NetworkConnectionProfile has been set using an allowed security profile AND that the prerequisite(s) for going to the new security profile are met before sending the command to change to the new security profile.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station was successfully upgraded to a new security profile.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>For security reasons it is by default not allowed to revert to a lower Security Profile using OCPP.
+Only when the variable AllowSecurityProfileDowngrade is implemented and is set to true, it is allowed to downgrade from profile 3 to profile 2. Even in that case, it is not allowed to revert from profile 2 or profile 3 to security profile 1 using OCPP.</td></tr></table>
+
+
+Figure 9. Upgrade Charging Station Security Profile
+
+# A05 - Upgrade Charging Station Security Profile - Requirements
+
+Table 30. A05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>A05.FR.02</td><td>The Charging Station receives SetVariablesRequest for NetworkConfigurationPriority containing a profile slot for a NetworkConnectionProfile with a 'securityProfile' value higher than the current value AND new value is 2 or 3 AND No valid CSMSRootCertificate installed</td><td>The Charging Station SHALL respond with SetVariablesResponse(Rejected), and not update the value for SecurityProfile and/or reconnect to the CSMS.</td></tr><tr><td>A05.FR.03</td><td>The Charging Station receives SetVariablesRequest for NetworkConfigurationPriority containing a profile slot for a NetworkConnectionProfile with a 'securityProfile' value higher than the current value AND new value is 3 AND No valid ChargingStationCertificate installed</td><td>The Charging Station SHALL respond with SetVariablesResponse(Rejected), and not update the value for SecurityProfile and/or reconnect to the CSMS.</td></tr><tr><td>A05.FR.04</td><td>The Charging Station receives SetVariablesRequest for NetworkConfigurationPriority containing profile slots for NetworkConnectionProfiles with a 'securityProfile' value equal to or higher than the current value AND all prerequisites are met</td><td>The Charging Station SHALL respond with SetVariablesResponse(Accepted)</td></tr><tr><td>A05.FR.05</td><td>A05.FR.04 AND After a reboot</td><td>The Charging Station SHALL begin connecting to the first entry of NetworkConfigurationPriority</td></tr><tr><td>A05.FR.06</td><td>A05.FR.05 AND The Charging Station successfully connected to the CSMS using the (new) NetworkConnectionProfile</td><td>The Charging Station SHALL update the value of the configuration variable SecurityProfile AND it SHALL remove all NetworkConnectionProfiles with a lower securityProfile than stored at SecurityProfile AND update NetworkConfigurationPriority accordingly.</td></tr><tr><td>A05.FR.07</td><td>A05.FR.06</td><td>The CSMS SHALL NOT allow the Charging Station to connect with a lower security profile anymore.</td></tr><tr><td>A05.FR.08</td><td>The variable AllowSecurityProfileDowngrade is implemented and set to true AND The currently active 'SecurityProfile' is 3 AND The Charging Station receives SetVariablesRequest for NetworkConfigurationPriority containing profile slots for NetworkConnectionProfiles with a 'securityProfile' value equal to 2.</td><td>The Charging Station SHALL respond with SetVariablesResponse(Accepted)</td></tr><tr><td>A05.FR.09</td><td>The variable AllowSecurityProfileDowngrade is implemented and set to true AND The currently active 'SecurityProfile' is higher than 1 AND The Charging Station receives SetVariablesRequest for NetworkConfigurationPriority containing profile slots for NetworkConnectionProfiles with a 'securityProfile' value equal to 1.</td><td>The Charging Station SHALL respond with SetVariablesResponse(Rejected)</td></tr><tr><td>A05.FR.10</td><td>The variable AllowSecurityProfileDowngrade is not implemented or implemented and set to false AND The Charging Station receives SetVariablesRequest for NetworkConfigurationPriority containing profile slots for NetworkConnectionProfiles with a 'securityProfile' value lower than the currently active security profile</td><td>The Charging Station SHALL respond with SetVariablesResponse(Accepted)</td></tr></table>
+
+# B. Provisioning
+
+# Chapter 1. Introduction
+
+This Functional Block describes the functionality that helps a CSO provision their Charging Stations: permitting them on their network, retrieving configuration information from these Charging Stations, making changes to their configuration etc. This chapter also covers resetting a Charging Station and migrating to a new NetworkConnectionProfile.
+
+# 1.1. Transactions before being accepted by a CSMS
+
+A Charging Station Operator MAY choose to configure a Charging Station to accept transactions before the Charging Station is accepted by a CSMS. Parties who want to implement this such behavior should realize that it is uncertain if those transactions can ever be delivered to the CSMS.
+
+After a restart (for instance due to a remote reset command, power outage, firmware update, software error etc.) the Charging Station MUST again contact the CSMS and SHALL send a BootNotification request. If the Charging Station fails to receive a BootNotificationResponse from the CSMS, and has no in-built non-volatile real-time clock hardware that has been correctly preset, the Charging Station may not have a valid date and time setting, making it difficult or even impossible to later determine the date and time of transactions.
+
+It might also be the case (e.g. due to configuration error) that the CSMS indicates a status other than Accepted for an extended period of time, or indefinitely.
+
+It is usually advisable to deny all charging services at a Charging Station if the Charging Station has never before been Accepted by the CSMS (using the current connection settings, URL, etc.) since users cannot be authenticated and running transactions could conflict with provisioning processes.
+
+If this is supported, this behaviour can be configured via the Configuration Variable: TxBeforeAcceptedEnabled.
+
+# Chapter 2. Use cases & Requirements
+
+# 2.1. Booting a Charging Station
+
+# B01 - Cold Boot Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Cold Boot Charging Station</td></tr><tr><td>2</td><td>ID</td><td>B01</td></tr><tr><td>3</td><td>Objective(s)</td><td>The objective of this use case is to enable a Charging Station that is powering up to register itself at a CSMS and provide the right state information.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS can control which Charging Stations access it. To be able to control Charging Stations connecting to a CSMS, Charging Stations are required to send BootNotificationRequest. This request contains some general information about the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station is powered up.
+2. The Charging Station sends BootNotificationRequest to the CSMS.
+3. The CSMS returns with BootNotificationResponse with the status Accepted.
+4. Optional: The Charging Station sends NotifyEventRequest with component.name Connector, variable.name AvailabilityState and actualValue Unavailable to the CSMS for each Connector.
+5. The Charging Station sends NotifyEventRequest with component.name Connector, variable.name AvailabilityState to the CSMS for each Connector. If the AvailabilityState was set to Unavailable or Reserved from the CSMS prior to the (re)boot, the Connector should return to this AvailabilityState, otherwise the AvailabilityState should be Available or, when it resumes a transaction that was ongoing, the AvailabilityState should be Occupied.
+6. Normal operation is resumed.
+7. The Charging Station sends HeartbeatRequest to the CSMS.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>B02 - Cold Boot Charging Station - Pending
+B03 - Cold Boot Charging Station - Rejected</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station is powered down.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station is in Idle status, and Accepted.
+Failure postcondition:
+The Charging Station received the status Rejected, B03 - Cold Boot Charging Station -Rejected applies.
+The Charging Station received the status Pending, B02 - Cold Boot Charging Station - Pending applies.</td></tr><tr><td>7</td><td>Error handling</td><td>1. No initial establishment of connection of communication between the CSMS and Charging Station: Retry Connection with the CSMS.
+2. No response / time-out from the CSMS: The Charging Station resends BootNotificationRequest after a waiting interval. The Charging Station chooses this interval on its own (since it dit not get a BootNotificationResponse containing this interval), in a way that avoids flooding the CSMS with requests.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Multiple options for a self check are possible: some Charging Stations boot and send status notifications with Unavailable, then perform a check of all the hardware and send new NotifyEvents with AvailabilityState Available when the Charging Station is up and running. However, there is no required order for a self check and sending a BootNotificationRequest. A Charging Stations can also do the self check before sending a BootNotificationRequest and determine the status before a (mobile) network connection is established and a BootNotificationRequest is sent.
+When something is wrong with the Charging Station or EVSE, the status SHALL be set to Faulted. Reserved and Unavailable states persist after a reboot.</td></tr></table>
+
+
+Figure 10. Sequence Diagram: Cold Boot Charging Station
+
+# B01 - Cold Boot Charging Station - Requirements
+
+Table 31. B01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B01.FR.01</td><td>After start-up.</td><td>The Charging Station SHALL send BootNotificationRequest to the CSMS with information about its configuration.</td><td>Information: e.g. version, vendor, etc.</td></tr><tr><td>B01.FR.02</td><td>B01.FR.01 The CSMS has received BootNotificationRequest from the Charging Station.</td><td>The CSMS SHALL respond to indicate whether it will accept the Charging Station.</td><td></td></tr><tr><td>B01.FR.03</td><td>After a reboot (for instance due to a remote reset command, power outage, firmware update, software error etc.)</td><td>The Charging Station SHALL again connect to the CSMS and SHALL send a BootNotificationRequest each time it boots or reboots.</td><td></td></tr><tr><td>B01.FR.04</td><td>When the CSMS responds with BootNotificationResponse with the status Accepted AND interval > 0</td><td>The Charging Station SHALL adjust the heartbeat interval in accordance with the interval from the response message.</td><td></td></tr><tr><td>B01.FR.05 (2.1)</td><td>When the CSMS responds with BootNotificationResponse with the status Accepted.</td><td>The Charging Station SHALL send a NotifyEventRequest with variable.name = "AvailabilityState" for each Connector with its current state.</td><td>Use of StatusNotificationRequest instead of NotifyEventRequest is still allowed, but StatusNotificationRequest is deprecated.</td></tr><tr><td>B01.FR.06</td><td>The Charging Station has received BootNotificationResponse. AND Charging Station is configured to use Heartbeats for time synchronization TimeSource</td><td>The Charging Station SHALL synchronize the Charging Station's internal clock with the supplied CSMS's current time.</td><td></td></tr><tr><td>B01.FR.07</td><td>When a Charging Station or an EVSE is set to status Unavailable by a Change Availability command.</td><td>The Unavailable status MUST be persistent across reboots.</td><td></td></tr><tr><td>B01.FR.08</td><td>Between the physical power-on/reboot and the successful completion of a BootNotification, where the CSMS returns Accepted or Pending.</td><td>The Charging Station SHALL NOT send any other OCPP requests to the CSMS (except BootNotificationRequest). This includes cached OCPP messages that are still present in the Charging Station from prior sessions.</td><td>Refer to B02 - Cold Boot Charging Station - Pending (for example B02.FR.02) for more details on sending messages on the Pending status.</td></tr><tr><td>B01.FR.09</td><td>B01.FR.01</td><td>The Charging Station SHALL indicate the reason for sending the BootNotificationRequest message in the reason field.</td><td>For which reason to use, see BootReasonEnumType.</td></tr><tr><td>B01.FR.10</td><td>The Charging Station has received a BootNotificationResponse in which status is not Accepted AND the Charging Station sends a RPC Framework: CALL message that is NOT a BootNotificationRequest or a message triggered by one of the following messages: TriggerMessageRequest, GetBaseReportRequest, GetReportRequest.</td><td>The CSMS SHALL respond with RPC Framework:CALLERROR: SecurityError.</td><td>The Charging Station is not allowed to initiate sending other messages before being accepted.</td></tr><tr><td>B01.FR.11</td><td>B01.FR.01 AND Security profile 3 is used</td><td>The CSMS SHALL check the SerialNumber in the BootNotificationRequest against the Serial Number in the Certificate Common Name.</td><td></td></tr><tr><td>B01.FR.12</td><td>B01.FR.11 AND the SerialNumber in the BootNotificationRequest does NOT equal the Serial Number in the Certificate Common Name</td><td>The CSMS SHALL close WebSocket connection.</td><td></td></tr><tr><td>B01.FR.13</td><td>When an EVSE has been reserved</td><td>The Reserved state MUST be persistent across reboots.</td><td></td></tr></table>
+
+# B02 - Cold Boot Charging Station - Pending
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Cold Boot Charging Station - Pending</td></tr><tr><td>2</td><td>ID</td><td>B02</td></tr><tr><td></td><td>Parent use case</td><td>B01 - Cold Boot Charging Station</td></tr><tr><td>3</td><td>Objective(s)</td><td>1. To inform the Charging Station that it is not yet accepted by the CSMS: Pending status.
+2. To give the CSMS a way to retrieve or set certain configuration information.
+3. To give the CSMS a way of limiting the load on the CSMS after e.g. a reboot of the CSMS.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes the behavior of the CSMS and a Charging Station when the Charging Station is informed by the CSMS that it is not yet accepted using the Pending status.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station is powered up.
+2. The Charging Station sends BootNotificationRequest to the CSMS.
+3. The CSMS responds with BootNotificationResponse with the status Pending.
+4. The CSMS then, is able to send messages to the Charging Station in order to change the configuration of the Charging Station.
+5. The Charging Station resends BootNotificationRequest after the number of seconds indicated by the interval field. (Interval from BootNotificationResponse)</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>1. The CSMS requires to set the Charging Station in Pending status.
+2. The Charging Station is starting up (i.e. powering up after being powered down).</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station is in Pending status.
+Failure postcondition:
+The Charging Station received the status Rejected, B03 - Cold Boot Charging Station -Rejected applies.</td></tr><tr><td>7</td><td>Error handling</td><td>1. When no initial connection established between CSMS and Charging Station: Retry Connection to the CSMS and rerend BootNotificationRequest.
+2. No response / time-out from the CSMS: The Charging Station resends BootNotificationRequest after a waiting interval. This waiting interval can be based on the interval from a previous BootNotificationResponse or chosen by the Charging Station itself. In the latter case, the Charging Station chooses this interval in a way that avoids flooding the CSMS with requests.</td></tr><tr><td>8</td><td>Remark(s)</td><td>When the CSMS returns with BootNotificationResponse with the status Accepted, B01 - Cold Boot Charging Station applies.</td></tr></table>
+
+
+Figure 11. Sequence Diagram: Cold Boot Charging Station - Pending
+
+# B02 - Cold Boot Charging Station - Pending - Requirements
+
+Table 32. B02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B02.FR.01</td><td>After the Charging Station received the Pending status.</td><td>The CSMS MAY send messages to retrieve information from the Charging Station (as described in use cases B06, B07, B08) or change its configuration by SetVariablesRequest (as described in use case B05). The Charging Station SHALL respond to these messages.</td><td>The Pending status can thus indicate that the CSMS wants to retrieve or set certain information on the Charging Station before it will accept the Charging Station.</td></tr><tr><td>B02.FR.02</td><td>While the CSMS has not yet responded to a BootNotificationRequest with an Accepted status in the BootNotificationResponse.</td><td>The Charging Station SHALL NOT send RPC Framework: CALL messages (Except BootNotificationRequest) to the CSMS, unless it has been instructed by the CSMS to do so, using one of the following messages: TriggerMessageRequest, GetBaseReportRequest, GetReportRequest.</td><td></td></tr><tr><td>B02.FR.03</td><td>While the CSMS has not yet responded to a BootNotificationRequest with an Accepted status in the BootNotificationResponse.</td><td>A Charging Station Operator MAY choose to configure a Charging Station to accept transactions and queue TransactionEventRequest messages to be sent to the CSMS</td><td>Parties who want to implement this behavior must realize that it is uncertain if those transactions can ever be delivered to the CSMS.</td></tr><tr><td>B02.FR.04</td><td>While the CSMS has not yet responded to a BootNotificationRequest with an Accepted status in the BootNotificationResponse.</td><td>A Charging Station SHALL NOT send BootNotificationRequest earlier than the value of the Interval field in BootNotificationResponse, unless requested to do so with TriggerMessageRequest.</td><td></td></tr><tr><td>B02.FR.05</td><td>While in Pending status AND receiving a RequestStartTransactionRequest or RequestStopTransactionRequest</td><td>The Charging Station SHALL respond with a RequestStartTransactionResponse or RequestStopTransactionResponse with status Rejected. (Even if the Charging Station is allowed to start transaction, see B02.FR.03. If the CSMS wants to use RequestStartTransaction etc. it SHALL first accept the Charging Station)</td><td></td></tr><tr><td>B02.FR.06</td><td>When the CSMS returns the Pending status</td><td>The communication channel SHALL NOT be closed by either the Charging Station or the CSMS.</td><td></td></tr><tr><td>B02.FR.07</td><td>If the interval in the BootNotificationResponse equals 0, and the status is other than Accepted,</td><td>The Charging Station SHALL choose a waiting interval on its own, in a way that avoids flooding the CSMS with requests.</td><td></td></tr><tr><td>B02.FR.08</td><td>If the interval in the BootNotificationResponse > 0, and the status is other than Accepted,</td><td>The Charging Station SHALL send a BootNotificationRequest after the set interval has past.</td><td></td></tr><tr><td>B02.FR.09</td><td>The Charging Station has received a BootNotificationResponse with status Pending AND the Charging Station sends a RPC Framework: CALL message that is NOT a BootNotificationRequest or a message triggered by one of the following messages: TriggerMessageRequest, GetBaseReportRequest, GetReportRequest.</td><td>The CSMS SHALL respond with RPC Framework: CALLERROR: SecurityError.</td><td>The Charging Station is not allowed to initiate sending other messages before being accepted.</td></tr></table>
+
+# B03 - Cold Boot Charging Station - Rejected
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Cold Boot Charging Station - Rejected</td></tr><tr><td>2</td><td>ID</td><td>B03</td></tr><tr><td></td><td>Parent use case</td><td>B01 - Cold Boot Charging Station</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the Charging Station that its not (yet) accepted by the CSMS: Rejected status.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes the behavior of the CSMS and a Charging Station, when the Charging Station is informed by the CSMS that it is not (yet) accepted using the Rejected status.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station is powered up.
+2. The Charging Station sends BootNotificationRequest to the CSMS.
+3 The CSMS responds with BootNotificationResponse with the status Rejected to the Charging Station.
+4. The Charging Station will resend BootNotificationRequest after the number of seconds indicated by the interval field. (Interval from BootNotificationResponse).</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>1. The CSMS requires to set the Charging Station in the Rejected status.
+2. The Charging Station is powered down.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station remains in the Rejected status.</td></tr><tr><td>7</td><td>Error handling</td><td>When there is no response or a time-out from the CSMS: The Charging Station resends BootNotificationRequest after a waiting interval. This waiting interval can be based on the interval from a previous BootNotificationResponse or chosen by the Charging Station itself. In the latter case, the Charging Station chooses this interval in a way that avoids flooding the CSMS with requests.</td></tr><tr><td>8</td><td>Remark(s)</td><td>During the status Rejected, the Charging Station may no longer be reachable from the CSMS. The Charging Station MAY e.g. close its communication channel or shut down its communication hardware.
+Additionally, the CSMS MAY close the communication channel, for instance to free up system resources.
+It is advised not to accept any transactions until the BootNotification of the Charging Station has been accepted by the CSMS. See: Transactions before being accepted by a CSMS
+When the CSMS returns with BootNotificationResponse with the status Accepted, B01 - Cold Boot Charging Station applies.</td></tr></table>
+
+
+Figure 12. Sequence Diagram: Cold Boot Charging Station - Rejected
+
+# B03 - Cold Boot Charging Station - Rejected - Requirements
+
+Table 33. B03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B03.FR.01</td><td>If the Charging Station is configured to accept Transactions before being accepted by a CSMS</td><td>The Charging Station MAY allow locally authorized transactions.</td></tr><tr><td>B03.FR.02</td><td>If the CSMS returns the status Rejected. For example when a Charging Station is blacklisted.</td><td>The Charging Station SHALL NOT send any OCPP message to the CSMS until the retry interval has expired.</td></tr><tr><td>B03.FR.03</td><td>When the CSMS has Rejected the BootNotificationRequest from the Charging Station.</td><td>The CSMS SHALL NOT initiate any messages.</td></tr><tr><td>B03.FR.04</td><td>B03.FR.03</td><td>The Charging Station MAY close the connection until it needs to send the next BootNotificationRequest.</td></tr><tr><td>B03.FR.05</td><td>If the interval in the BootNotificationResponse equals 0, and the status is other than Accepted</td><td>The Charging Station SHALL choose a waiting interval on its own, in a way that avoids flooding the CSMS with requests.</td></tr><tr><td>B03.FR.06</td><td>If the interval in the BootNotificationResponse is greater than 0, and the status is other than Accepted</td><td>The Charging Station SHALL send a BootNotificationRequest after the set interval has passed.</td></tr><tr><td>B03.FR.07</td><td>B03.FR.03 AND Charging Station sends a message that is not a BootNotificationRequest</td><td>CSMS SHALL respond with RPC Framework: CALLERROR:SecurityError.</td></tr><tr><td>B03.FR.08</td><td>B03.FR.03 AND CSMS sends a message that is not a response to a BootNotificationRequest from Charging Station</td><td>Charging Station SHALL respond with RPC Framework:CALLERROR:SecurityError.</td></tr></table>
+
+# B04 - Offline Behavior Idle Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Offline Behavior Idle Charging Station</td></tr><tr><td>2</td><td>ID</td><td>B04</td></tr><tr><td>3</td><td>Objective(s)</td><td>To attain stand-alone operation of the Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes that, in the event of unavailability of the communication, the Charging Station is designed to operate stand-alone. In that situation, the Charging Station is said to be Offline.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS or communication is unavailable.
+2. The Charging Station operates stand-alone.
+3. The connection is restored.
+4. If the Offline period exceeds the value of the OfflineThreshold Configuration Variable: the Charging Station sends a NotifyEventRequest with variable.name AvailabilityState to the CSMS for each connector. Otherwise it only sends a NotifyEventRequest with variable.name AvailabilityState for Connectors with a status change during the offline period.
+5. The Charging Station sends HeartbeatRequest to the CSMS.
+6. The CSMS responds with HeartbeatResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The BootNotification was previously accepted and the Charging Station is able to operate stand-alone.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>When connection is restored after a period of Offline behavior, the CSMS knows the Charging Stations' and EVSEs' state.</td></tr><tr><td>7</td><td>Error handling</td><td>The offline situation is a non-preferred mode of operation that needs to be handled by the Charging Station by trying to re-establish the connection.</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 13. Sequence Diagram: Offline Behavior Idle Charging Station
+
+# B04 - Offline Behavior Idle Charging Station - Requirements
+
+Table 34. B04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B04.FR.01 (2.1)</td><td>After having been Offline AND the Offline period exceeds the value of the OfflineThreshold Configuration Variable.</td><td>The Charging Station SHALL send NotifyEventRequest with variable.name AvailabilityState to report the current status of all its Connectors.</td></tr><tr><td>B04.FR.02 (2.1)</td><td>After having been Offline AND the Offline period does NOT exceed the value of the OfflineThreshold Configuration Variable.</td><td>The Charging Station SHALL send NotifyEventRequest with variable.name AvailabilityState to report the current status of only the Connectors for which a state change occurred.</td></tr></table>
+
+# 2.2. Configuring a Charging Station
+
+NOTE
+
+For managing the configuration of a Charging Station a basic understanding of Device Model concepts is essential. These concepts are explained in "OCPP 2.1: Part 1 - Architecture & Topology", chapter 4.
+
+# B05 - Set Variables
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set Variables</td></tr><tr><td>2</td><td>ID</td><td>B05</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to make changes to variables in the Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>A Charging Station can have a lot of variables that can be configured/changed by the CSMS. A CSMS can use these variables to for example influence the behavior of a Charging Station. This use case describes how the CSMS requests a Charging Station to set the value of variables of a component. The CSMS can request to set more than one value per request.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request setting one or more variables in a Charging Station.
+2. The CSMS sends a SetVariablesRequest to the Charging Station.
+3. The Charging Station responds with a SetVariablesResponse indicating whether it was able to executed the change(s).</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postconditions:
+1. The change was executed Successfully.
+Failure postconditions:
+1. The variable is supported, but setting could not be changed, the Charging Station responds with the status Rejected.
+2. The variable is not supported, the Charging Station responds with the status UnknownVariable.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The attributeType Actual corresponds with the actual value of the Variable, whereas the attributeTypes Target, MinSet and MaxSet correspond to the target, minimum and maximum values that have been set for this variable.
+This is best explained by an example: the cooling system is configured to operate with a fan speed between 1000 and 5000 rpm. These boundaries are represented by the MinSet and MaxSet attributes. The current fan speed is represented by the Actual attribute. The desired fan speed is represented by the Target attribute.</td></tr></table>
+
+
+Figure 14. Sequence Diagram: Set Variables
+
+# B05 - Set Variables - Requirements
+
+Table 35. B05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B05.FR.01</td><td>When the Charging Station receives a SetVariablesRequest with an X number of SetVariableData elements</td><td>The Charging Station SHALL respond with an SetVariablesResponse with an equal (X) number of SetVariableResult elements, one for every SetVariableData element in the SetVariablesRequest.</td></tr><tr><td>B05.FR.02</td><td>B05.FR.01</td><td>Every SetVariableResult element in the SetVariablesResponse SHALL contain the same component and variable combination as one of the SetVariableData elements in the SetVariablesRequest.</td></tr><tr><td>B05.FR.03</td><td>B05.FR.02 AND If the SetVariablesRequest contains an attributeType</td><td>The corresponding SetVariableResult element in the SetVariablesResponse SHALL also contain the same attributeType</td></tr><tr><td>B05.FR.04</td><td>When the Charging Station receives a SetVariablesRequest with an unknown Component in the SetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: UnknownComponent.</td></tr><tr><td>B05.FR.05</td><td>When the Charging Station receives a SetVariablesRequest with a Variable that is unknown for the given Component in the SetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: UnknownVariable.</td></tr><tr><td>B05.FR.06</td><td>When the Charging Station receives a SetVariablesRequest with an attributeType that is unknown for the given Variable in the SetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: NotSupportedAttributeType.</td></tr><tr><td>B05.FR.07</td><td>When the Charging Station receives a SetVariablesRequest with a value that is incorrectly formatted for the given Variable in the SetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: Rejected. (More information can be provided in the optional statusInfo element.)</td></tr><tr><td>B05.FR.08</td><td>When the Charging Station receives a SetVariablesRequest with a value that is lower or higher than the range of the given Variable in the SetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: Rejected. (More information can be provided in the optional statusInfo element.)</td></tr><tr><td>B05.FR.09</td><td>NOT (B05.FR.04 to B05.FR.08) AND When the Charging Station receives a SetVariablesRequest for a Variable in the SetVariableData, but is not able to set it</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: Rejected. (This happens if the variable is ReadOnly, but may also occur when setting the variable fails because of technical problems.)</td></tr><tr><td>B05.FR.10</td><td>When the Charging Station was able to set the given value from the SetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetVariableResult to: Accepted.</td></tr><tr><td>B05.FR.11</td><td></td><td>The CSMS SHALL NOT send more SetVariableData elements in a SetVariablesRequest than reported by the Charging Station via ItemsPerMessageSetVariables.</td></tr><tr><td>B05.FR.12</td><td>When the Charging Station receives a SetVariablesRequest without an attributeType.</td><td>The corresponding SetVariableResult element in the SetVariablesResponse SHALL contain the attributeType Actual.</td></tr><tr><td>B05.FR.13</td><td></td><td>The CSMS SHALL NOT include multiple SetVariableData elements, in a single SetVariablesRequest, with the same Component, Variable and AttributeType combination. Note that an omitted AttributeType counts as the value Actual.</td></tr></table>
+
+B06 - Get Variables
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Variables</td></tr><tr><td>2</td><td>ID</td><td>B06</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to retrieve the value of an attribute for one or more Variables of one or more Components.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests a Charging Station to send the value of an attribute for one or more variables of one or more components. It is not possible to get all attributes of all variables in one call.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request for a number of variables in a Charging Station.
+2. The CSMS request the Charging Station for a number of variables with GetVariablesRequest with a list of requested variables.
+3. The Charging Station responds with a GetVariablesResponse with the requested variables.
+4. The CSMS sends an optional notification to the CSO.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station was able to send all the requested variables.
+Failure postcondition:
+The Charging Station was not able to send all requested variables.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 15. Sequence Diagram: Get Variables
+
+# B06 - Get Variables - Requirements
+
+Table 36. B06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B06.FR.01</td><td>When the Charging Station receives a GetVariableRequest with an X number of GetVariableData elements</td><td>The Charging Station SHALL respond with an GetVariableResponse with an equal (X) number of GetVariableResult elements, one for every GetVariableData element in the GetVariablesRequest.</td></tr><tr><td>B06.FR.02</td><td>B06.FR.01</td><td>Every GetVariableResult element in the GetVariableResponse SHALL contain the same component and variable combination as one of the GetVariableData elements in the GetVariablesRequest.</td></tr><tr><td>B06.FR.03</td><td>B06.FR.02 AND If the GetVariableRequest contains an attributeType</td><td>The corresponding GetVariableResult element in the GetVariablesResponse SHALL also contain the same attributeType</td></tr><tr><td>B06.FR.04</td><td>B06.FR.01</td><td>Every GetVariableResult element in the GetVariablesResponse SHALL contain an attributeValue with the value of an attribute from the requested attributeType in the GetVariablesRequest.</td></tr><tr><td>B06.FR.05</td><td></td><td>The CSMS SHALL NOT send more GetVariableData elements in a GetVariablesRequest than reported by the Charging Station via ItemsPerMessageGetVariables.</td></tr><tr><td>B06.FR.06</td><td>When the Charging Station receives a GetVariablesRequest with an unknown Component in the GetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding GetVariableResult to: UnknownComponent AND SHALL omit the attributeValue.</td></tr><tr><td>B06.FR.07</td><td>When the Charging Station receives a GetVariablesRequest with a Variable that is unknown for the given Component in the GetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding GetVariableResult to: UnknownVariable AND SHALL omit the attributeValue.</td></tr><tr><td>B06.FR.08</td><td>When the Charging Station receives a GetVariablesRequest with an attributeType that is unknown for the given Variable in the GetVariableData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding GetVariableResult to: NotSupportedAttributeType AND SHALL omit the attributeValue.</td></tr><tr><td>B06.FR.09</td><td>When the Charging Station receives a GetVariablesRequest for a Variable in the GetVariableData that is WriteOnly</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding GetVariableResult to: Rejected.</td></tr><tr><td>B06.FR.10</td><td>When the Charging Station was able to get the value requested from a GetVariablesRequest</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding GetVariableResult to: Accepted and set the attributeValue to the found value.</td></tr><tr><td>B06.FR.11</td><td>When the Charging Station receives a GetVariablesRequest without an attributeType.</td><td>The corresponding GetVariableResult element in the GetVariablesResponse SHALL contain the attributeType Actual.</td></tr><tr><td>B06.FR.13</td><td>NOT B06.FR.08 AND the Charging Station has no attributeValue for the requested attributeType of the componentvariable</td><td>Charging Station SHALL return an empty string as attributeValue. Note: this can happen, for example, when the attributeType Target has not yet been set, even though it is supported.</td></tr><tr><td>B06.FR.14</td><td>B06.FR.01 AND a value for instance is provided in the component and/or variable in GetVariableData</td><td>Charging Station SHALL return the specified instance of that component and/or variable in GetVariableResult.</td></tr><tr><td>B06.FR.15</td><td>B06.FR.01 AND no value or an empty string is provided for instance in the component and/or variable in GetVariableData AND a component and/or variable without an instance does not exist</td><td>Charging Station SHALL return the attributeStatus UnknownComponent or UnknownVariable in the GetVariableResult entry for GetVariableData.</td></tr><tr><td>B06.FR.16</td><td>Charging Station receives a GetVariablesRequest with more GetVariableData elements than allowed by ItemsPerMessageGetVariables</td><td>The Charging Station MAY respond with a CALLERROR(OccurrenceConstraintViolation)</td></tr><tr><td>B06.FR.17</td><td>Charging Station receives a GetVariablesRequest with a length of more bytes than allowed by BytesPerMessageGetVariables</td><td>The Charging Station MAY respond with a CALLERROR(FormatViolation)</td></tr></table>
+
+B07 - Get Base Report
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Base Report</td></tr><tr><td>2</td><td>ID</td><td>B07</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to request a predefined report as defined in ReportBase.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests a Charging Station to send a predefined report as defined in ReportBase. The result will be returned asynchronously in one or more NotifyReportRequest messages.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request a report from a Charging Station.
+2. The CSMS requests the Charging Station for a report with GetBaseReportRequest.
+3. The Charging Station responds with GetBaseReportResponse.
+4. The Charging Station asynchronously sends the results in one or more NotifyReportRequest messages.
+5. The CSMS responds with NotifyReportResponse for each NotifyReportRequest.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station was able to send the requested report.
+Failure postcondition:
+The Charging Station was not able to send the requested report.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 16. Sequence Diagram: Get Base Report
+
+# B07 - Get Base Report - Requirements
+
+Table 37. B07 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B07.FR.01</td><td>When the Charging Station receives a getBaseReportRequest for a supported reportBase AND NOT B07.FR.13</td><td>The Charging Station SHALL send a getBaseReportResponse with Accepted.</td><td></td></tr><tr><td>B07.FR.02</td><td>When the Charging Station receives a getBaseReportRequest for a reportBase that is not supported</td><td>The Charging Station SHALL send a getBaseReportResponse with NotSupported.</td><td></td></tr><tr><td>B07.FR.03</td><td>B07.FR.01</td><td>The Charging Station SHALL send the requested information, excluding the value of WriteOnly variables, via one or more NotifyReportRequest messages to the CSMS.</td><td>It is good practice to send the report data in as few messages as possible in order to limit data overhead.</td></tr><tr><td>B07.FR.04</td><td>B07.FR.01 AND The getBaseReportRequest contained a requestId</td><td>Every NotifyReportRequest send for this getBaseReportRequest SHALL contain the same requestId.</td><td></td></tr><tr><td>B07.FR.05</td><td>B07.FR.02</td><td>The Charging Station SHALL NOT send a NotifyReportRequest to the CSMS.</td><td></td></tr><tr><td>B07.FR.07</td><td>B07.FR.01 AND When reportBase is ConfigurationInventory</td><td>Then the Charging Station SHALL respond with a NotifyReportRequest to report on all component-variables that can be set by the operator including their VariableCharacteristics.</td><td></td></tr><tr><td>B07.FR.08</td><td>B07.FR.01 AND When reportBase is FullInventory</td><td>Then the Charging Station SHALL respond with a NotifyReportRequest to report on all component-variables including their VariableCharacteristics.</td><td>As a minimum the required variables mentioned in Charging Infrastructure related shall be reported as well as the required variables in Section 1 Controller Components that are relevant to each functional block that has been implemented.</td></tr><tr><td>B07.FR.09</td><td>B07.FR.01 AND When reportBase is SummaryInventory</td><td>Then the Charging Station SHALL respond with a NotifyReportRequest to report on components and variables related to the availability and condition of the Charging Station, notably operationalStatus of the Charging Station, EVSE and Connectors and any error condition.</td><td>A (summary) report that lists Components/Variables relating to the Charging Station's current charging availability, and to any existing problem conditions.For the Charging Station Component:- AvailabilityState.For each EVSE Component:- AvailabilityState.For each Connector Component:- AvailabilityState (if known and different from EVSE).For all Components in an abnormal State:- Active (Problem, Tripped, Overload, Failback) variables.- Any other diagnostically relevant Variables of the Components.</td></tr><tr><td>B07.FR.10</td><td></td><td>The sequence number contained in the seqNo field of the NotifyReportRequest is incremental per report. So the NotifyReportRequest message which contains the first report part, SHALL have a seqNo with value 0.</td><td></td></tr><tr><td>B07.FR.11</td><td>B07.FR.08</td><td>All attribute types of a variable, that are supported by the Charging Station, SHALL be reported, even if they have no value (are unset).</td><td>This allows a CSMS to know which attribute types are supported by the Charging Station.</td></tr><tr><td>B07.FR.12</td><td></td><td>The Charging Station SHALL support at least the base reports: ConfigurationInventory and FullInventory.</td><td></td></tr><tr><td>B07.FR.13</td><td>When the Charging Station is temporarily unable to execute a report request</td><td>The Charging Station SHALL send a getBaseReportResponse with Rejected.</td><td></td></tr><tr><td>B07.FR.14</td><td>When a Charging Station connects to CSMS for the first time OR whenever CSMS suspects that the device model of the Charging Station has changed (e.g. after a firmware update or hardware change)</td><td>CSMS SHOULD request a GetBaseReportRequest with reportBase = FullInventory to retrieve a complete list of all its device model components and variables.</td><td>It is not mandated, because implementations may exist that are based on a known set of charging stations with fixed device models that will not change.</td></tr><tr><td>B07.FR.15</td><td>When the Charging Station is sending the requested information via one or more NotifyReportRequest messages to the CSMS</td><td>The Charging Station SHALL omit the value of readily variables</td><td></td></tr></table>
+
+B08 - Get Custom Report
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Custom Report</td></tr><tr><td>2</td><td>ID</td><td>B08</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to request a report of all Components and Variables limited to those that match ComponentCriteria and/or the list of ComponentVariables.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests a Charging Station to send a report of all Components and Variables limited to those that match ComponentCriteria and/or the list of ComponentVariables. The result will be returned asynchronously in one or more NotifyReportRequest messages.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request a report from a Charging Station.
+2. The CSMS requests the Charging Station for a report with a GetReportRequest.
+3. The Charging Station responds with a GetReportResponse.
+4. The Charging Station asynchronously sends the results in one or more NotifyReportRequest messages.
+5. The CSMS responds with a NotifyReportResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station was able to send the requested report.
+Failure postcondition:
+The Charging Station was not able to send the requested report.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 17. Sequence Diagram: Get Custom Report
+
+# B08 - Get Custom Report - Requirements
+
+Table 38. B08 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B08.FR.01</td><td>NOT B08.FR.15 AND NOT B08.FR.16 AND When the Charging Station receives a GetReportRequest for supported criteria</td><td>The Charging Station SHALL send a GetReportResponse with Accepted</td></tr><tr><td>B08.FR.02</td><td>When the Charging Station receives a GetReportRequest for not supported criteria</td><td>The Charging Station SHALL send a GetReportResponse with NotSupported</td></tr><tr><td>B08.FR.03</td><td>B08.FR.01</td><td>The Charging Station SHALL send the requested information, excluding the value of WriteOnly variables, via one or more NotifyReportRequest messages to the CSMS.</td></tr><tr><td>B08.FR.04</td><td>B08.FR.01 AND The GetReportRequest contained a requestId</td><td>Every NotifyReportRequest sent for this GetReportRequest SHALL contain the same requestId.</td></tr><tr><td>B08.FR.05</td><td>B08.FR.01 AND componentCriteria and componentVariables are NOT both empty.</td><td>Every NotifyReportRequest sent for this GetReportRequest SHALL be limited to the set componentCriteria and componentVariables.</td></tr><tr><td>B08.FR.06</td><td></td><td>CSMS SHALL NOT send more componentVariables in one GetReportRequest message than is configured in the ItemsPerMessageGetReport Configuration Variable</td></tr><tr><td>B08.FR.07</td><td>B08.FR.01 AND ComponentCriteria contains: Active</td><td>The Charging Station SHALL report every component that has the variable Active set to true, or does not have the Active variable in a NotifyReportRequest.</td></tr><tr><td>B08.FR.08</td><td>B08.FR.01 AND ComponentCriteria contains: Available</td><td>The Charging Station SHALL report every component that has the variable Available set to true, or does not have the Available variable, in a NotifyReportRequest.</td></tr><tr><td>B08.FR.09</td><td>B08.FR.01 AND ComponentCriteria contains: Enabled</td><td>The Charging Station SHALL report every component that has the variable Enabled set to true, or does not have the Enabled variable, in a NotifyReportRequest.</td></tr><tr><td>B08.FR.10</td><td>B08.FR.01 AND ComponentCriteria contains: Problem</td><td>The Charging Station SHALL report every component that has the variable Problem set to true in a NotifyReportRequest.</td></tr><tr><td>B08.FR.11</td><td>B08.FR.01 AND componentCriteria is absent AND componentVariables is NOT empty.</td><td>Every NotifyReportRequest sent for this GetReportRequest is limited to the set in componentVariables.</td></tr><tr><td>B08.FR.12</td><td>B08.FR.01</td><td>The reported variables in NotifyReportRequest SHALL contain variableCharacteristics.</td></tr><tr><td>B08.FR.13</td><td>B08.FR.01 AND More than one componentCriteria is given.</td><td>The Charging Station SHALL report all components that have at least one of the given criteria (logical OR).</td></tr><tr><td>B08.FR.14</td><td></td><td>The sequence number contained in the seqNo field of the NotifyReportRequest is incremental per report. So the NotifyReportRequest message which contains the first report part, SHALL have a seqNo with value 0.</td></tr><tr><td>B08.FR.15</td><td>When the Charging Station receives a GetReportRequest with a combination of criteria which results in an empty result set.</td><td>The Charging Station SHALL respond with a GetReportResponse(status=EmptyResultSet).</td></tr><tr><td>B08.FR.16</td><td>When the Charging Station is temporarily unable to execute a report request</td><td>The Charging Station SHALL send a getBaseReportResponse with Rejected.</td></tr><tr><td>B08.FR.17</td><td>Charging Station receives a GetReportRequest with more ComponentVariableType elements than allowed by ItemsPerMessageGetReport</td><td>The Charging Station MAY respond with a CALLERROR(OccurrenceConstraintViolation)</td></tr><tr><td>B08.FR.18</td><td>Charging Station receives a GetReportRequest with a length of more bytes than allowed by BytesPerMessageGetReport</td><td>The Charging Station MAY respond with a CALLERROR(FormatViolation)</td></tr><tr><td>B08.FR.20</td><td>When Charging Station receives a GetReportRequest with componentVariable elements in which variable is missing</td><td>The Charging Station SHALL report for every variable of the component in componentVariable.</td></tr><tr><td>B08.FR.21</td><td>When Charging Station receives a GetReportRequest with componentVariable elements in which variable is present, but instance is missing</td><td>The Charging Station SHALL report for every instance of the variable of the component in componentVariable.</td></tr><tr><td>B08.FR.22</td><td>B08.FR.11 AND When Charging Station receives a GetReportRequest with a component in a componentVariable element that has a component.evse.id, but component.evseconnector is missing</td><td>The Charging Station SHALL report the component(s) with this component.name, component.instance and component.evse.id for every component.evseconnector, whilst taking into account B08.FR.24.</td></tr><tr><td>B08.FR.23</td><td>B08.FR.11 AND When Charging Station receives a GetReportRequest with a component in a componentVariable element that has no component.evse.id</td><td>The Charging Station SHALL report the component(s) with this component.name, component.instance for every component.evse field (including top level component without component.evse), whilst taking into account B08.FR.24.</td></tr><tr><td>B08.FR.24</td><td>B08.FR.11 AND When Charging Station receives a GetReportRequest with a component in a componentVariable element that has a value for component.instance</td><td>The Charging Station SHALL report the component(s) with this component.name for every component.instance field, whilst taking into account B08.FR.22, B08.FR.23.</td></tr><tr><td>B08.FR.25</td><td>B08.FR.11 AND When Charging Station receives a GetReportRequest with a component in a componentVariable element that has no component.instance field</td><td>The Charging Station SHALL report the component(s) with this component.name for every component.instance field or the component(s) without component.instance field, whichever is the case, whilst taking into account B08.FR.22, B08.FR.23.</td></tr></table>
+
+# B09 - Setting a new NetworkConnectionProfile
+
+(Updated in OCPP 2.1)
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Setting a new NetworkConnectionProfile.</td></tr><tr><td>2</td><td>ID</td><td>B09</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to update the connection details on the Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>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.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>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 OCPPCommCtrl.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 data3. The Charging Station responds by sending a SetNetworkProfileResponse PDU, with status Accepted.</td></tr><tr><td></td><td>Alternative scenario(New in OCPP 2.1)</td><td>Setting network configuration via device modelThe changing of network configuration parameters must be done for a configuration slot that is currently not listed in the NetworkConfigurationPriority variable. This ensures that Charging Station cannot use an incompletely configured network configuration.All parameters of a SetNetworkProfileRequest for a configurationSlot are present as device model variables on component NetworkConfiguration with instance = configurationSlot and are set directly via a SetVariablesRequest. See NetworkConfiguration for a list of variables.1. If the configuration slot to be set is part of NetworkConfigurationPriority configuration variablea. CSMS will remove this configuration slot from the NetworkConfigurationPriority via a SetVariablesRequest, so that it can be updated.2. The CSMS sends one or multiple SetVariablesRequest(s) to set new values for the variables in the NetworkConfiguration component with instance configurationSlot.3. The Charging Station responds to each request with a SetVariablesResponse with status Accepted.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The data supplied by the CSMS matches the Charging Station's capabilities</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station was able to store the new connection data</td></tr><tr><td>7</td><td>Error Handling</td><td>Activation of a new NetworkConnectionProfile is described in B10 - Migrate to new CSMS. Errors during this use-case are not destructive to the current data connection. Error handling is further described in B10 - Migrate to new CSMS</td></tr><tr><td>8</td><td>Remarks</td><td>When changes are made to the currently active NetworkConnectionProfile using SetNetworkProfileRequest, these will not be used until a reconnect occurs, which can be triggered by resetting a Charging Station as described in B10 - Migrate to new CSMS.The existing SetNetworkProfileRequest has become deprecated and may be subject to removal in a future OCPP release.</td></tr></table>
+
+
+Figure 18. Sequence Diagram: Set Network Connection Profile
+
+# B09 - Requirements
+
+Table 39. B09 - Requirements when using SetNetworkProfileRequest
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B09.FR.01</td><td>On receipt of the SetNetworkProfileRequest</td><td>The Charging Station SHALL validate the content, store the new data and if successful, respond by sending a SetNetworkProfileResponse message, with status Accepted</td></tr><tr><td>B09.FR.02</td><td>On receipt of the SetNetworkProfileRequest</td><td>The Charging Station SHALL validate the content. If the content is invalid, the Charging Station SHALL respond by sending a SetNetworkProfileResponse message, with status Rejected</td></tr><tr><td>B09.FR.03</td><td>If setting the new networkprofile fails.</td><td>The Charging Station SHALL respond by sending a SetNetworkProfileResponse message, with status Failed</td></tr><tr><td>B09.FR.04</td><td>The variable AllowSecurityProfileDowngrade is not implemented or implemented and set to false AND The Charging Station receives a SetNetworkProfileRequest AND the NetworkConnectionProfile contains a lower securityProfile than the currently active security profile</td><td>The Charging Station SHALL respond by sending a SetNetworkProfileResponse message, with status Rejected</td></tr><tr><td>B09.FR.05</td><td>When the value of configurationSlot in SetNetworkProfileRequest does not match an entry in valuesList of NetworkConfigurationPriority</td><td>The Charging Station SHALL respond by sending a SetNetworkProfileResponse message with status Rejected</td></tr><tr><td>B09.FR.06</td><td></td><td>A Charging Station SHALL support at least two configuration slots for network connection profiles.</td></tr><tr><td>B09.FR.07 (2.1)</td><td></td><td>Charging Station and CSMS are strongly RECOMMENDED to use the highest security profile possible.</td></tr><tr><td>B09.FR.08 (2.1)</td><td>When receiving a GetBaseReportRequest</td><td>Charging Station SHALL include in the report the component NetworkConfiguration with instances for every configurationSlot that it supports with the variables it supports.</td></tr><tr><td>B09.FR.09 (2.1)</td><td>When Charging Station accepts a SetNetworkProfileRequest from CSMS for configurationSlot</td><td>Charging Station SHALL update all corresponding NetworkConfiguration component variables with instance configurationSlot.</td></tr><tr><td>B09.FR.10 (2.1)</td><td>If Charging Station supports setting network configuration via configuration keys in NetworkConfiguration</td><td>Charging Station SHALL report these variables as writeable (ReadWrite or WriteOnly in case of a password)</td></tr><tr><td>B09.FR.11 (2.1)</td><td>B09.FR.09 AND The SetNetworkProfileRequest does not contain the apn or the vpn field</td><td>Charging Station SHALL set variable ApnEnabled resp. VpnEnabled in NetworkConfiguration to False.</td></tr><tr><td>B09.FR.12 (2.1)</td><td>B09.FR.09 AND The SetNetworkProfileRequest contains the apn or the vpn field</td><td>Charging Station SHALL set variable ApnEnabled resp. VpnEnabled in NetworkConfiguration to True.</td></tr><tr><td>B09.FR.13 (2.1)</td><td>B09.FR.10 AND Charging Station does not support APN or VPN connections</td><td>Charging Station SHALL report the variable ApnEnabled resp. VpnEnabled in NetworkConfiguration as False and ReadOnly.</td></tr><tr><td>B09.FR.14 (2.1)</td><td></td><td>CSMS SHOULD use the SetNetworkProfileRequest to set the identity or BasicAuth password of the Charging Station. (See also B09.FR.26/27)</td></tr><tr><td colspan="3">When using SetVariablesRequest for NetworkConfiguration component</td></tr><tr><td>B09.FR.20(2.1)</td><td>B09.FR.10 ANDOn receipt of a SetVariablesRequest containing the variable NetworkConfigurationPriority ANDthe new value only removes configurationslot(s) from the current value</td><td>The Charging Station SHALL respond by sending aSetVariablesResponse with the corresponding setVariableResultcontaining status Accepted</td></tr><tr><td>B09.FR.21(2.1)</td><td>B09.FR.10</td><td>CSMS SHALL NOT send a SetVariablesRequest containing anyNetworkConfiguration component variable for which thecomponent instance matches any of the members in thecurrently configured NetworkConfigurationPriority</td></tr><tr><td>B09.FR.22(2.1)</td><td>B09.FR.10 ANDOn receipt of a SetVariablesRequest containing any NetworkConfiguration component variableANDthe component instance matches any of themembers in the currently configuredNetworkConfigurationPriority</td><td>The Charging Station SHOULD respond by sending aSetVariablesResponse with the corresponding setVariableResultcontaining status Rejected</td></tr><tr><td>B09.FR.23(2.1)</td><td>B09.FR.10 ANDOn receipt of a SetVariablesRequest containing any NetworkConfiguration component variableANDthe component instance matches none of themembers in the currently configuredNetworkConfigurationPriority</td><td>The Charging Station SHALL validate the value of the variable.</td></tr><tr><td>B09.FR.24(2.1)</td><td>B09.FR.23 ANDvariable validation was successful</td><td>The Charging Station SHALL store the value and respond bysending a SetVariablesResponse with the correspondingsetVariableResultcontaining status Accepted</td></tr><tr><td>B09.FR.25(2.1)</td><td>B09.FR.23 ANDvariable validation was not successful</td><td>The Charging Station SHALL respond by sending aSetVariablesResponse with the corresponding setVariableResultcontaining status Rejected</td></tr><tr><td>B09.FR.26(2.1)</td><td>B09.FR.10 ANDOn receipt of a SetVariablesRequest containing the variable SecurityCtrl.Identity ANDthe mutability of this variable is read/write</td><td>The Charging Station SHALL also set the variable of the samename in all NetworkConfiguration component instances to thesame value (if valid), including component instances which arecontained in the currently configuredNetworkConfigurationPriority. This is for backwardscompatibility only. CSMS SHOULD set the NetworkConfigurationcomponent variable instead.</td></tr><tr><td>B09.FR.27(2.1)</td><td>B09.FR.10 ANDOn receipt of a SetVariablesRequest containing the variable SecurityCtrl.BasicAuthPassword</td><td>The Charging Station SHALL also set the variable of the samename in all NetworkConfiguration component instances to thesame value (if valid), including component instances which arecontained in the currently configuredNetworkConfigurationPriority. This is for backwardscompatibility only. CSMS SHOULD set the NetworkConfigurationcomponent variable instead.</td></tr><tr><td>B09.FR.28(2.1)</td><td>B09.FR.10 ANDWhen Charging Station activates a new networkconfiguration</td><td>Charging Station SHALL ensure that the values ofSecurityCtrl.Identity and SecurityCtrl.BasicAuthPasswordmatch the corresponding variables ofNetworkConfiguration.Identity[configurationSlot] andNetworkConfiguration.BasicAuthPassword[configurationSlot] forthe currently active configurationSlot.</td></tr><tr><td>B09.FR.29(2.1)</td><td>When CSMS configures variables for an APN orVPN connection</td><td>CSMS SHALL set variable ApnEnabled resp. VpnEnabled ofNetworkConfiguration to True.</td></tr><tr><td>B09.FR.30(2.1)</td><td>When CSMS does not configure variables for anAPN or VPN connection</td><td>CSMS SHALL set variable ApnEnabled resp. VpnEnabled ofNetworkConfiguration to False.</td></tr><tr><td>B09.FR.31</td><td>The variable AllowSecurityProfileDowngrade isimplemented and set to true ANDThe currently active 'SecurityProfile' is 3 ANDThe Charging Station receives asetNetworkProfileRequest ANDthe NetworkConnectionProfile contains asecurityProfile with a value of 2.</td><td>The Charging Station SHALL respond withSetVariablesResponse(Accepted)</td></tr><tr><td>B09.FR.32</td><td>The variable AllowSecurityProfileDowngrade is implemented and set to true AND The currently active 'SecurityProfile' is higher than 1 AND The Charging Station receives a SetNetworkProfileRequest AND the NetworkConnectionProfile contains a securityProfile with a value of 1.</td><td>The Charging Station SHALL respond with SetVariablesResponse(Rejected)</td></tr></table>
+
+B10 - Migrate to new CSMS
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Migrate to new CSMS, using a different NetworkConnectionProfile.</td></tr><tr><td>2</td><td>ID</td><td>B10</td></tr><tr><td>3</td><td>Objective(s)</td><td>After completion of this use case, the Charging Station connects to a new CSMS.</td></tr><tr><td>4</td><td>Description</td><td>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.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS 1, CSMS 2</td></tr><tr><td></td><td>Scenario description</td><td>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 Idle.
+4. The Charging Station reboots and connects via the new primary NetworkConnectionProfile to CSMS 2.</td></tr><tr><td>5</td><td>Prerequisites</td><td>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</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station is connected via a different NetworkConnectionProfile.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>As in line with B12 - Reset - With Ongoing Transaction, when there are ongoing transactions, the Charging Station waits for these to be finished before performing the Reset and then connecting to a different CSMS.
+When an operator wants to perform an immediate switch, he should stop the transactions first.</td></tr></table>
+
+
+Figure 19. Sequence Diagram: Migrate to new ConnectionProfile
+
+# B10 - Migrate to new NetworkConnectionProfile - Requirements
+
+Table 40. B10 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>B10.FR.01</td><td>On receipt of a SetVariablesRequest, containing Configuration Variable NetworkConfigurationPriority AND the NetworkProfile slots in the message all contain valid configurations</td><td>The Charging Station SHALL send SetVariablesResponse with status Accepted, or RebootRequired.</td><td></td></tr><tr><td>B10.FR.02</td><td>On receipt of a SetVariablesRequest, containing Configuration Variable NetworkConfigurationPriority AND any of the NetworkProfile slots in the message does not contain a valid configuration</td><td>The Charging Station SHALL send SetVariablesResponse with status Rejected.</td><td>The optional element statusInfo can be used to provide more information.</td></tr><tr><td>B10.FR.03</td><td>B10.FR.04 AND When connecting fails</td><td>The Charging Station SHALL make the number of attempts as configured in NetworkProfileConnectionAttempts per entry of NetworkConfigurationPriority.</td><td></td></tr><tr><td>B10.FR.04</td><td>B10.FR.01 OR B09.FR.01 AND After a reboot</td><td>The Charging Station SHALL begin connecting to the first entry of NetworkConfigurationPriority</td><td>Same as A05.FR.05</td></tr><tr><td>B10.FR.05</td><td></td><td>It is RECOMMENDED to set the Charging Station to Inoperative (via ChangeAvailabilityRequest) to ensure that no new transactions can be started and wait until the transaction message queue in the Charging Station is empty before sending the ResetRequest. Otherwise the Charging Station might send transaction related messages to the new CSMS that has not received the start of the Transaction, and the old system will miss the ended messages. To determine if there are still transaction for an ongoing transaction in the queue, the getTransactionStatusRequest message can be used.</td><td></td></tr><tr><td>B10.FR.06</td><td></td><td>The Charging Station SHALL disconnect from the old CSMS, before trying to connect to the new CSMS.</td><td></td></tr><tr><td>B10.FR.07</td><td>B10.FR.09</td><td>The Charging Station SHOULD fallback and start 'reconnecting' to the NetworkConnectionProfile for which the last successful connection was made.</td><td>'reconnecting' in this requirement, refers to the reconnection mechanism described at section 5.3. Reconnecting from "Part 4 - JSON over WebSockets implementation guide".</td></tr><tr><td>B10.FR.08</td><td>B10.FR.09</td><td>The Charging Station SHOULD restart connecting with all configured entries of the NetworkConfigurationPriority</td><td></td></tr><tr><td>B10.FR.09</td><td>B10.FR.03 AND All NetworkProfileConnectionAttempts for every entry of NetworkConfigurationPriority failed.</td><td>The Charging Station SHOULD NOT stop trying to reconnect to the CSMS. The Charging Station SHOULD implement the reconnecting mechanism described at requirement B10.FR.07 or B10.FR.08.</td><td>This is to prevent the Charging Station from becoming a stranded asset.</td></tr></table>
+
+# 2.3. Resetting a Charging Station
+
+B11 - Reset - Without Ongoing Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reset - Without Ongoing Transaction</td></tr><tr><td>2</td><td>ID</td><td>B11</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to request a Charging Station to reset itself or an EVSE, while there is no ongoing transaction.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS can request the Charging Station to reset itself or an EVSE by sending ResetRequest. (If ResetRequest contains an optional paramater evseld, then only a reset of the specific EVSE is requested.) This could for example be necessary if the Charging Station is not functioning correctly.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO requests the CSMS to reset the Charging Station or EVSE.
+2. The CSMS sends ResetRequest requesting the Charging Station to reset itself or EVSE.
+3. The CSMS requests for an OnIdle or Immediate reset.
+4. The Charging Station responds with ResetResponse, indicating whether the Charging Station is able to reset itself or EVSE.
+5. The CSMS sends an optional notification to the CSO.
+6. Only if no evseld was supplied, then after the reset, the Charging Station will proceed as in use case B01.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>B12 - Reset With Ongoing Transaction</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>No transaction is ongoing.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station was able to reset itself or EVSE.
+Failure postcondition:
+The Charging Station not was able to reset itself or EVSE.</td></tr><tr><td>7</td><td>Error handling</td><td>n.a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Persistent states: for example, EVSE set to Unavailable SHALL persist.
+The Charging Station responds with ResetResponse.</td></tr></table>
+
+
+Figure 20. Sequence Diagram: Reset Without Transaction
+
+# B11 - Reset - Without Ongoing Transaction - Requirements
+
+Table 41. B11 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B11.FR.01</td><td>When the Charging Station receives a ResetRequest.</td><td>The Charging Station SHALL respond with a ResetResponse.</td></tr><tr><td>B11.FR.02</td><td>If the status was set to Inoperative by the CSMS.</td><td>After a reboot of the Charging Station, the EVSEs SHALL return to the state Unavailable as prior to the reboot.</td></tr><tr><td>B11.FR.03</td><td>B11.FR.01 AND no evseld parameter is supplied AND ResetResponse has status = Accepted.</td><td>The Charging Station MAY send a NotifyEventRequest for component = "Connector", variable = "AvailabilityState", actualValue = "Unavailable" and trigger = "Delta" for each EVSE, and SHALL start a reboot.</td></tr><tr><td>B11.FR.04</td><td>B11.FR.03</td><td>The Charging Station SHALL proceed as described in use case B01 - Cold Boot Charging Station.</td></tr><tr><td>B11.FR.05</td><td>If the status of an EVSE was Reserved.</td><td>After a reboot of the Charging Station or resetting of EVSE, the EVSE(s) SHALL return to the state Reserved.</td></tr><tr><td>B11.FR.06</td><td>B11.FR.01 AND Charging Station is at this moment not able to perform a reset.</td><td>The Charging Station SHALL respond with a status = Rejected.</td></tr><tr><td>B11.FR.07</td><td>B11.FR.01ANDCharging Station cannot perform the reset now, but has scheduled the reset for later</td><td>The Charging Station SHALL respond with a status = Scheduled.</td></tr><tr><td>B11.FR.08</td><td>B11.FR.01AND an evseld parameter is supplied ANDResetResponse has status = Accepted.</td><td>The Charging Station MAY send a NotifyEventRequest for component = "Connector", variable = "AvailabilityState", actualValue = "Unavailable" and trigger = "Delta" for the EVSE, and SHALL start a reset of the EVSE that is referred to by evseld parameter.</td></tr><tr><td>B11.FR.09</td><td>B11.FR.01AND an evseld parameter is supplied ANDCharging Station does not support resetting an individual EVSE</td><td>The Charging Station SHALL return a ResetResponse with status = Rejected</td></tr><tr><td>B11.FR.10</td><td>When the Charging Station supports resetting of an individual EVSE</td><td>The Charging Station SHOULD set the device model variable AllowReset to true for the EVSE.</td></tr></table>
+
+B12 - Reset - With Ongoing Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reset - With Ongoing Transaction</td></tr><tr><td>2</td><td>ID</td><td>B12</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to request a Charging Station to reset itself or EVSE, while there is an ongoing transaction.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS can request the Charging Station to reset itself or an EVSE by sending ResetRequest. (If ResetRequest contains an optional paramater evseld, then only a reset of the specific EVSE is requested.) This could for example be necessary if the Charging Station is not functioning correctly. The CSMS has the possibility to let the Charging Station end all transactions itself and reboot or wait until all ongoing transactions are ended normally (by an EV user) and then reboot.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO requests the CSMS to reset the Charging Station or EVSE.
+2. The CSMS sends ResetRequest requesting the Charging Station to reset itself or EVSE.
+3a. On receipt of an OnIdle reset, the Charging Station responds with ResetResponse(Scheduled), indicating the Charging Station will try to reset itself or EVSE after all ongoing transactions have ended. The Charging Station continues charging and sets all EVSEs (or only the one provided in the request, if evseld was supplied) that are Available to status Unavailable, waits until all transactions are finished and all TransactionEventRequest (eventType = Ended) messages are sent.
+3b. On receipt of an Immediate reset, the Charging Station responds with ResetResponse(Accepted), indicating the Charging Station will try to reset itself or EVSE. The Charging Station attempts to terminate any transaction (or only those running on the EVSE provided in the request, if evseld was supplied) in progress, and sending a TransactionEventRequest (eventType = Ended) message.
+4. Only if no evseld was supplied the Charging Station reboots and returns to a state as just having been booted, B01 - Cold Boot Charging Station applies.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>B11 - Reset Without Ongoing Transaction</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A transaction is ongoing.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station was able to reset itself or EVSE.
+Failure postcondition:
+The Charging Station not was able to reset itself or EVSE.</td></tr><tr><td>7</td><td>Error handling</td><td>After having accepted the ResetRequest, TransactionEventRequest messages that cannot be delivered to the CSMS MUST be queued.</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 21a: Sequence Diagram: Reset OnIdle With Ongoing Transaction
+
+
+Figure 21b: Sequence Diagram: Reset Immediate With Ongoing Transaction
+
+# B12 - Reset - With Ongoing Transaction - Requirements
+
+Table 42. B12 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B12.FR.01</td><td>When the Charging Station receives a ResetRequest(OnIdle) AND a transaction is ongoing</td><td>The Charging Station SHALL respond with a ResetResponse(Scheduled), to indicate whether the Charging Station will attempt to reset itself or EVSE after all transactions on Charging Station or EVSE have ended.</td></tr><tr><td>B12.FR.02</td><td>When the Charging Station receives a ResetRequest(Immediate) AND a transaction is ongoing</td><td>The Charging Station SHALL respond with a ResetResponse(Accepted), to indicate whether the Charging Station will attempt to reset itself or EVSE.</td></tr><tr><td>B12.FR.03</td><td>If no evsEd is supplied AND If any transaction is in progress and an OnIdle reset is received.</td><td>The transaction of the Charging Station SHALL be terminated normally, before the reboot, e.g. as in E06 - Stop Transaction.</td></tr><tr><td>B12.FR.04</td><td>If no evsEd is supplied AND If any transaction is in progress and an Immediate Reset is received.</td><td>The Charging Station SHALL attempt to terminate any transaction in progress and send a TransactionRequest (eventType = Ended) message with triggerReason = ResetCommand and transactionInfo.stoppedReason = ImmediateReset for each terminated transaction before performing a reboot.</td></tr><tr><td>B12.FR.05</td><td>If an Immediate Reset without evseld is received and the TransactionEventResponse is not received within timeout.</td><td>The Charging Station SHALL queue the TransactionRequest, reboot and resend the TransactionRequest after the reboot.</td></tr><tr><td>B12.FR.06</td><td>If the status was set to Inoperative by the CSMS.</td><td>After a reboot of the Charging Station or resetting of EVSE, the EVSE(s) SHALL return to the state Unavailable as prior to the reboot of Charging Station or reset of EVSE. (Same as B11.FR.02)</td></tr><tr><td>B12.FR.07</td><td>If an evseld is supplied AND If a transaction is in progress on the EVSE and an OnIdle reset is received.</td><td>The transaction on the EVSE SHALL be terminated normally, before the reset, e.g. as in E06 - Stop Transaction.</td></tr><tr><td>B12.FR.08</td><td>If an evseld is supplied AND If a transaction is in progress on the EVSE and an Immediate Reset is received.</td><td>The Charging Station SHALL attempt to terminate the transaction in progress on the EVSE and send a TransactionRequest (eventType = Ended) message with triggerReason = ResetCommand and transactionInfo.stoppedReason = ImmediateReset before resetting the EVSE.</td></tr><tr><td>B12.FR.09</td><td>B12.FR.01 AND an evseld parameter is supplied AND Charging Station does not support resetting an individual EVSE</td><td>The Charging Station SHALL return a ResetResponse with status = Rejected (Same as B11.FR.09)</td></tr><tr><td>B12.FR.10</td><td>B12.FR.02 AND Charging Station is at this moment not able to perform an Immediate reset for a reason other than the fact that a transaction is in progress</td><td>The Charging Station SHALL return a ResetResponse with status = Rejected</td></tr></table>
+
+# B13 - Reset - With Ongoing Transaction - Resuming Transaction
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reset - With Ongoing Transaction - Resuming Transaction</td></tr><tr><td>2</td><td>ID</td><td>B13</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to request a Charging Station to reset itself or EVSE, while a transaction is ongoing, that is to be resumed after reset.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS can request the Charging Station to reset itself or an EVSE by sending ResetRequest with type = ImmediateAndResume. (If ResetRequest contains an optional parameter evseld, then only a reset of the specific EVSE is requested.) This could for example be necessary if the Charging Station is not functioning correctly.
+The configuration variable TxAllowEnergyTransferResumption determines whether energy transfer is still allowed on the resumed transaction or not.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. CSMS sends ResetRequest with type = ImmediateAndResume to Charging Station.
+2. Charging Station responds with ResetResponse with status = Accepted.
+3. Charging Station sends a TransactionEventRequest with eventType = Updated and triggerReason = ResetCommand to signal that a reset will be performed.
+4. Charging Station remembers the charging state of ongoing transactions, stops energy transfer, and unlocks the connectors in case of detachable cables.
+5. Charging Station will not end the ongoing transaction(s), but resume them after the reset.
+6. Charging Station resets the entire Charging Station or EVSE
+ a. Only when no evseld was supplied, the Charging Station reboots and returns to a state as just having been booted, B01 - Cold Boot Charging Station applies.
+7. Charging Station locks the connectors again in case of detachable cables.
+8. Charging Station resumes connectivity with the EVs and resumes the transactions in the charging state they had before the reset.
+ a. If TxAllowEnergyTransferResumption = true, the energy transfer on the transaction will be resumed.
+ b. If TxAllowEnergyTransferResumption = false, the energy transfer on the transaction will not be resumed.
+9. Charging Station sends a TransactionEventRequest with eventType = Updated and triggerReason = TxResumed to signal that the transaction has been resumed.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>B11 - Reset Without Ongoing Transaction
+B12 - Reset With Ongoing Transaction.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A transaction is ongoing.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station was able to reset itself or EVSE.
+The transaction continues and energy transfer only continues when TxAllowEnergyTransferResumption = true.
+Failure postcondition:
+• The Charging Station was not able to reset itself or its EVSE,
+• The Charging Station was not able to resume the transaction,
+• The EV was not able to resume the energy transfer.</td></tr><tr><td>7</td><td>Error handling</td><td>After having accepted the ResetRequest, any TransactionEventRequest messages that cannot be delivered to the CSMS MUST be queued.</td></tr><tr><td>8</td><td>Remark(s)</td><td>The EVSE of the Charging Station will have to resume the charging session towards the EV.
+Depending on the type of connector and protocol (Mode 3, ISO 15118, CHAdeMO, etc.) this will involve different actions, which are not described in this specification.
+Only when the configuration variable TxResumptionTimeout exists and has a value greater than zero, a ResetRequest with type = ImmediateAndResume is supported. After the reset all transactions are resumed, regardless of the value of TxResumptionTimeout.
+Charging Station may reject the reset request when it is unable to perform it, for example when it is busy with a firmware update process.</td></tr></table>
+
+
+Figure 21. Sequence Diagram: Reset With Ongoing Transaction
+
+# B13- Reset - With Ongoing Transaction - Without Termination - Requirements
+
+Table 43. B13 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>B13.FR.01</td><td>When Charging Station receives a ResetRequest with type = ImmediateAndResume AND TxResumptionTimeout == 0 or non-existent</td><td>Charging Station SHALL respond with ResetResponse with status = Rejected. (When transaction resumption is not supported by this Charging Station)</td></tr><tr><td>B13.FR.02</td><td>When Charging Station receives a ResetRequest with type = ImmediateAndResume AND No transactions are ongoing on Charging Station</td><td>Charging Station SHALL respond with ResetResponse with status = Accepted and act according to use case B11 - Reset - Without Ongoing Transactions.</td></tr><tr><td>B13.FR.03</td><td>When Charging Station receives a ResetRequest with type = ImmediateAndResume AND Transactions are ongoing on Charging Station</td><td>Charging Station SHALL respond with ResetResponse with status = Accepted</td></tr><tr><td>B13.FR.04</td><td>B13.FR.03</td><td>Charging Station SHALL send TransactionEventRequest with eventType = Updated and triggerReason = ResetCommand and any other required parameters for each ongoing transaction.</td></tr><tr><td colspan="3">Reset of EVSE</td></tr><tr><td>B13.FR.10</td><td>B13.FR.04 AND parameter evseld had a value</td><td>Charging Station SHALL stop energy transfer for the transaction on evseld.</td></tr><tr><td>B13.FR.11</td><td>B13.FR.10</td><td>Charging Station SHALL reset the EVSE matching evseld without rebooting the entire Charging Station.</td></tr><tr><td>B13.FR.12</td><td>B13.FR.11 AND After reset is completed</td><td>Charging Station SHALL resume the transaction in the state it had before the reset, even when resetting took longer than TxResumptionTimeout.</td></tr><tr><td>B13.FR.13</td><td>B13.FR.12 AND TxAllowEnergyTransferResumption = true</td><td>Charging Station SHALL allow energy transfer in the resumed transaction.</td></tr><tr><td>B13.FR.14</td><td>B13.FR.12 AND TxAllowEnergyTransferResumption = false AND transactionInfo.chargingState = Charging</td><td>Charging Station SHALL resume the transaction in the chargingState = SuspendedEVSE (i.e. no energy transfer)</td></tr><tr><td colspan="3">Reset of Charging Station</td></tr><tr><td>B13.FR.20</td><td>B13.FR.04 AND parameter evseld is not present</td><td>Charging Station SHALL stop energy transfer for all transactions and unlock the connectors in case of detachable cables.</td></tr><tr><td>B13.FR.21</td><td>B13.FR.20</td><td>Charging Station SHALL reboot the entire Charging Station.</td></tr><tr><td>B13.FR.22</td><td>B13.FR.21 AND After reboot is completed</td><td>Charging Station SHALL lock the connectors that had ongoing transaction in case of detachable cables.</td></tr><tr><td>B13.FR.23</td><td>B13.FR.22</td><td>Charging Station SHALL resume each transaction in the state it had before the reset, even when resetting took longer than TxResumptionTimeout.</td></tr><tr><td>B13.FR.24</td><td>B13.FR.23 AND TxAllowEnergyTransferResumption = true</td><td>Charging Station SHALL allow energy transfer in resumed transactions.</td></tr><tr><td>B13.FR.25</td><td>B13.FR.23 AND TxAllowEnergyTransferResumption = false AND transactionInfo.chargingState of a transaction is Charging</td><td>Charging Station SHALL resume such a transaction in the chargingState SuspendedEVSE (i.e. no energy transfer)</td></tr><tr><td colspan="3">Signal resumption</td></tr><tr><td>B13.FR.30</td><td>B13.FR.12 OR B13.FR.23</td><td>Charging Station SHALL send a TransactionEventRequest with eventType = Updated and triggerReason = TxResumed for each resumed transaction.</td></tr><tr><td>B13.FR.31</td><td>B13.FR.30 AND CSMS has a charging profile of chargingProfilePurpose = TxProfile for transactions reported with triggerReason = TxResumed AND SmartChargingCtrl.ChargingProfilePersistence for instance = "TxProfile" = false or absent</td><td>CSMS SHALL send the SetChargingProfileRequest for chargingProfilePurpose = TxProfile for these transactions again.</td></tr></table>
+
+# C. Authorization
+
+# Chapter 1. Introduction
+
+This Functional Block describes all the authorization-related functionalities, it contains different ways of authorizing a user, online and/or offline and the AuthorizationRequest message handling/behavior, Authorization Cache functionality, etc.
+
+When a user wishes to unplug the electric vehicle from the Charging Station, the Charging Station needs to verify that the user is either the one that initiated the charging or that the user is in the same group and thus allowed to terminate the charging. Once authorized, the Charging Station informs the CSMS that the charging has been stopped.
+
+- To improve the experience for users, a Charging Station MAY support local authorization of identifiers, using an Authorization Cache.
+- The LocalAuthorizationOffline Configuration Variable controls whether a Charging Station will authorize a user when offline using the Authorization Cache.
+- The LocalPreAuthorization Configuration Variable controls whether a Charging Station will use the Authorization Cache to start a transaction without performing an authorization with the CSMS.
+
+# 1.1. ID Tokens
+
+This section is normative
+
+OCPP now makes it possible to use many different types of authorization. Where OCPP 1.x only supported RFID, OCPP now also supports things like: credit card, PIN-code, a simple start button etc.
+
+An IDTokenType contains the identifier to use for authorization. It is defined as a combination of a case insensitive string and a type. Message data elements of the IDTokenType class (including GroupId) MAY contain any data, that is meaningful to a CSMS (e.g. for the purpose of identifying the initiator of charging activity), and Charging Stations MUST NOT make any presumptions as to the format or content of such data, other than is provided in the description of the IdTokenType (e.g. by assuming that it is a UID-like value that must be hex characters only and/or an even number of digits). IdToken data acquired via local token reader hardware is usually a (4, 7 or 10 bytes) UID value of a physical IdToken, typically represented as 8, 14 or 20 hexadecimal digit characters.
+
+# NOTE
+
+To promote interoperability, based on common practice to date in the case of Id-TokenType data has type: ISO14443, it is RECOMMENDED that such UIDs be represented as hex representations of the UID bytes. According to ISO 14443-3, byte 0 should come first in the hex string. (Most significant nibble of byte 0 first)
+
+# 1.1.1. Additional Info
+
+Updated in OCPP 2.1
+
+The field additionInfo of IdTokenType can be used to send extra information about the Token to the CSMS. This can be used in specific situations. For example, when known, the license plate of the vehicle can be added as additionInfo, which can then be passed on to a parking service, or in the case of ad hoc payment with a credit card, the additionInfo can contain information about the credit card authorization.
+
+When comparing two idTokens, the additionalInfo is disregarded. This also means that the additionInfo should not be stored in the Local Authorization Cache as part of IdTokenType.
+
+The meaning of an additionalInfo field is determined by its type field. This is a free format string. The supported values need to be agreed upon between Charging Station and CSMS. A limited set of values for additionalInfo.type, related to ad hoc payment support, is defined in [OCPP2.1-PART2-APPENDIX].
+
+# 1.2. Group ID Tokens
+
+This section is normative
+
+A CSMS has the ability to treat a set of identity tokens as a "group", thereby allowing any one token in the group to start a transaction and for the same token, or another token in the same group, to stop the transaction. This supports the common usecases of families or businesses with multiple drivers using one or more shared electric vehicles on a single recharging contract account. IDTokenTypes used as "GroupId" may often use a shared central account identifier for the GroupId, instead of a UID of the first/master RFID card of an account.
+
+Tokens (idTags) are grouped for authorization purposes by specifying a common group identifier in the optional groupIdToken element in IdTokenInfo: two IdTokens are considered to be in the same group if their GroupIdTokens match (and they are not empty).
+
+# NOTE
+
+Even though the GroupId has the same nominal data type (IdTokenType) as an idToken, the value of this element may not be in the common format of IdTokenTypes and/or may not represent an actual valid IdTokenType (e.g. it may be a common shared "account number"): therefore, the GroupId value SHOULD NOT be used for comparison against a presented Token value (unless it also occurs as an idToken value).
+
+# 1.3. Authorization Cache
+
+A Charging Station MAY implement an Authorization Cache that autonomously maintains a record of previously presented identifiers that have been successfully authorized by the CSMS. The Authorization Cache can be used to speed up the authorization process at the Charging Station, since using a locally stored cache means that the user does not have to wait for the Charging Station to check the authorization at the CSMS. Operation of the Authorization Cache, when present, is reported (and controlled, where possible) by the AuthCacheEnabled Configuration Variable. The optional expiration time of general Authorization Cache entries can be set in the Configuration Variable AuthCacheLifeTime. If a different expiration time is desired for a specific entry, this can be set in the cacheExpiryDateTime that is returned in iDTokensInfo of, for example, the ActivateResponse.
+
+Please refer to the use cases C10 - Store Authorization Data in the Authorization Cache and C12 - Start Transaction - Cached Id for more information on how to implement / use the Authorization Cache functionality.
+
+A Charging Station MAY support the authorization of any presented identifier when offline, to avoid refusal of charging to bona fide users that cannot be explicitly authorized by Authorization Cache entries. This functionality is explained in more detail in Unknown Offline Authorization.
+
+It is RECOMMENDED to store personal information in the Authorization Cache securely, e.g. by only storing hashed Tokens in the cache.
+
+# 1.4. Local Authorization List
+
+The Local Authorization List is a list of identifiers that can be synchronized with the CSMS. It allows authorization of a user when offline and faster (apparent) authorization response time when communication between Charging Station and CSMS is slow. The CSMS can synchronize the list by either sending a complete list of identifiers to replace the Local Authorization List or by sending a list of changes (add, update, delete) to apply to the Local Authorization List. The operations to support this are GetLocalListVersion and SendLocalList.
+
+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.
+
+Please refer to the use cases D01 - Send Local Authorization List, C13 - Offline Authorization through Local Authorization List and C14 - Online Authorization through Local Authorization List for more information on how to implement / use the Local Authorization List functionality.
+
+# NOTE
+
+Please note the difference between the Authorization Cache and Local Authorization List mechanisms: the Authorization Cache is an autonomous mechanism at the Charging Station, whereas the Local Authorization List is a list that is synchronized between CSMS and Charging Station (originating from the CSMS).
+
+# NOTE
+
+The Authorization Cache and Local Authorization List are distinct logical data structures. When both Authorization Cache as well as Local Authorization List are supported, a Charging Station SHALL treat Local Authorization List entries as having priority over Authorization Cache entries for the same identifiers.
+
+The following Configuration Variables are used by the Charging Station to give information about the Local Authorization List
+
+- LocalAuthListEntries (Also reports the maximum amount of IdTokens in the Local Authorization List)
+- LocalAuthListEnabled
+- LocalAuthListAvailable
+- ItemsPerMessageSendLocalList
+- BytesPerMessageSendLocalList
+
+# 1.5. Unknown Offline Authorization
+
+When offline, a Charging Station MAY allow automatic authorization of any "unknown" identifiers that are not found in the Local Authorization List and/or Authorization Cache. Operation of the Unknown Offline Authorization capability, when supported, is
+
+reported (and controlled, where possible) by the OfflineTxForUnknownIdEnabled Configuration Variable. When connection to the CSMS is restored, the Charging Station has to send the queued TransactionRequest messages. These may contain transactions that were authorized offline, as explained in transaction-related message handling. Please refer to C15 - Unknown Offline Authorization for the options that the Charging Station has to continue / stop the transaction in this situation.
+
+# 1.6. Relationship between authorization and transaction
+
+This section is informative.
+
+The purpose of authorization is twofold. It ensures in the first place, that energy is only offered to a known user (represented by the idToken), which is essential for billing. In the second place, it ensures that only the user who was authorized in the first place (or a member of the same group of users) is allowed to unplug the cable. This is an important safeguard against cable theft in situations where the charging station does not have a fixed cable and the user brings its own charging cable.
+
+Authorization and the duration of the authorization period are not strictly tied to a transaction: it is possible to have transactions without explicit authorization, e.g. in the case of a charging station that can be started with a push button. In that case one could say that there is a permanent authorization for anyone to charge.
+
+The start of the authorization period:
+
+- can take place before a transaction is started (e.g. when a cable is not yet connected), or
+- can cause a transaction to be started (e.g. when authorization is defined as the start of a transaction by setting TxStartPoint = Authorized), or
+- can happen after a transaction has already started (e.g. when connection of the cable is defined as the start of a transaction by setting TxStartPoint = EVConnected).
+
+(See chapter E.1.1 "Flexible transaction start/stop" for a description of transaction start and stop points.)
+
+In any case, authorization (or authorization period) ends when the same Token is presented again for authorization, or when the transaction ends. This means that ending of the authorization period:
+
+- can happen during a transaction without ending the transaction (e.g. when idToken is presented again, but TxStopPoint = EVConnected), or
+- can cause the transaction to end (e.g. when idToken is presented again and TxStopPoint = Authorized), or
+- can be caused by the end of the transaction (e.g. when idToken is not presented for authorization, but the cable is disconnected and TxStopPoint = EVConnected), or
+- can be caused by cable plug-out if no transaction was started.
+
+A Charging Station defines when authorization starts (i.e. upon receiving theauthorizeResponse, or when authorizing locally via authorization cache or local authorization list) and when authorization ends (i.e. when idToken is presented a second time, or when the transaction ends). Charging Station notifies CSMS about this, as follows:
+
+- If authorization occurs before start of the transaction, Charging Station tells CSMS that authorization has taken place, by including the idToken in the first TransactionEventRequest of the transaction.
+- If authorization occurs within a transaction or at the start of a transaction, Charging Station reports this by including the Token in TransactionEventRequest together with a triggerReason = Authorized.
+- The end of authorization is reported in a TransactionEventRequest with a triggerReason = StopAuthorized or Deauthorized, or by reporting the end of the transaction.
+
+# Chapter 2. Use cases & Requirements
+
+# 2.1. Authorization options
+
+# C01 - EV Driver Authorization using RFID
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>EV Driver Authorization using RFID</td></tr><tr><td>2</td><td>ID</td><td>C01</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Charging Station to request the CSMS to authorize an EV Driver to start or stop charging.</td></tr><tr><td>4</td><td>Description</td><td>When a Charging Station needs to charge an EV, it needs to authorize the EV Driver first before the charging can be started or stopped.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver wants to start or stop charging the EV and presents an RFID card.
+2. The Charging Station sends AuthorizationRequest to the CSMS to request authorization.
+3. Upon receipt of AuthorizationRequest, the CSMS responds with AuthorizationResponse. This response message indicates whether or not the IdToken is accepted by the CSMS.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C02 - Authorization using a start button
+C03 - Authorization using credit/debit card
+C04 - Authorization using PIN-code
+C05 - Authorization for CSMS initiated transactions
+C06 - Authorization using local id type
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The EV Driver is authorized and can start or stop charging.
+Failure postcondition:
+If the authorize message is Invalid, Restricted, Expired or Unknown, the EV Driver can not start or stop charging, except in the case where the EV Driver presents the same token used to start the transaction.</td></tr><tr><td>7</td><td>Error handling</td><td>When the Authorization is not 'Accepted', the AuthorizationResponse contains an authorization status value indicating the reason for rejection.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Assuming idToken is valid for charging and the Charging Station has 3 EVSEs, what is the content of idTokenInfo, when idToken is allowed to charge:
+. at all EVES: idTokenInfo.status = Accepted.
+. at EVSE 1: idTokenInfo.status = Accepted, idTokenInfo.evseld = [1].
+. at EVSE 1 + 2: idTokenInfo.status = Accepted, idTokenInfo.evseld = [1, 2].
+. at none of the EVSEs: _idTokenInfo.status=NotAtThisLocation.</td></tr></table>
+
+
+Figure 22. Sequence Diagram: EV Driver Authorization
+
+# C01 - EV Driver Authorization using RFID - Requirements
+
+Table 44. C01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C01.FR.01</td><td>Configuration setting Enabled is true.</td><td>The Charging Station SHALL only offer energy after authorization.</td><td></td></tr><tr><td>C01.FR.02</td><td>If an idToken presented by the EV Driver is not present in the Local Authorization List or Authorization Cache</td><td>The Charging Station SHALL send AuthorizationRequest to the CSMS to request authorization.</td><td></td></tr><tr><td>C01.FR.03</td><td>When an idToken is presented during a transaction that has been authorized AND (a) the presented idToken is the same as the idToken that started the authorization OR (b) when the presented idToken is in the Local Authorization List or Authorization Cache AND is valid AND has the same GroupIdToken as the IdToken that started the authorization.</td><td>The Charging Station SHALL end the authorization of the transaction, without first sending an AuthorizationRequest</td><td>The idToken that started the authorization can always be used to end the authorization. Ending authorization will end delivery of energy. Depending on the TxStopPoint ending of the authorization may also end the transaction.</td></tr><tr><td>C01.FR.04</td><td></td><td>AuthorizationRequest SHALL only be used for the authorization of an identifier.</td><td></td></tr><tr><td>C01.FR.05</td><td>If an IdToken is present in the Local Authorization List or Authorization Cache.</td><td>The Charging Station MAY send AuthorizationRequest to the CSMS.</td><td></td></tr><tr><td>C01.FR.06</td><td>When CSMS receives an AuthorizationRequest for an idToken AND the idToken has an associated groupIdToken.</td><td>AuthorizationResponse sent by the CSMS to a Charging Station SHALL include the associated groupIdToken.</td><td></td></tr><tr><td>C01.FR.07</td><td></td><td>AuthorizationResponse SHALL include an authorization status value indicating acceptance or a reason for rejection.</td><td>See AuthorizationStatusEnu mType for the possible reasons of rejection.</td></tr><tr><td>C01.FR.08</td><td>If the field: language1 is set AND the Charging Station contains messages in that language.</td><td>The Charging Station SHALL show messages to the user in language1.</td><td></td></tr><tr><td>C01.FR.09</td><td>If the field: language1 is set AND the Charging Station does not contain messages in that language AND if the field: language2 is set AND the Charging Station contains messages in that language</td><td>The Charging Station SHALL show messages to the user in language2.</td><td></td></tr><tr><td>C01.FR.10</td><td>If the field: language1 is not set</td><td>The field: language2 SHALL NOT be set.</td><td></td></tr><tr><td>C01.FR.11</td><td></td><td>Field: language1 SHALL be different from field language2.</td><td></td></tr><tr><td>C01.FR.12</td><td></td><td>It is RECOMMENDED to implement messages in English as fall-back.</td><td></td></tr><tr><td>C01.FR.13</td><td>If both language1 AND language2 don't match installed languages in the Charging Station</td><td>It is RECOMMENDED to show messages to the EV Driver in English.</td><td></td></tr><tr><td>C01.FR.17</td><td></td><td>Language SHALL be specified as RFC-4646 tags, see: [RFC5646], example: US English is: "en-US".</td><td></td></tr><tr><td>C01.FR.18</td><td>If the IdToken is valid AND the EV driver is NOT allowed to charge at the type of EVSE(s) this Charging Station provides.</td><td>The CSMS SHALL send an AuthorizationResponse with idTokenInfo.status NotAllowedTypeEVSE.</td><td></td></tr><tr><td>C01.FR.19</td><td>idToken is allowed for any EVSE of the Charging Station</td><td>The CSMS SHALL send an AuthorizationResponse in which idTokenInfo has an empty (or absent) evseld list.</td><td>This will be the most common case. Even though the idToken might be allowed on any EVSE, the idTokenInfo.status still needs to be Accepted before charging is allowed.</td></tr><tr><td>C01.FR.20</td><td>idToken is allowed for a subset of EVSEs of the Charging Station</td><td>The CSMS SHALL send an AuthorizationResponse in which IdTokenInfo has an evseld list with the allowed EVSEs.</td><td>Note the difference between validity of an idToken and the fact whether this (type of) token is allowed on an EVSE. The idTokenInfo.status still needs to be Accepted before charging is allowed.</td></tr><tr><td>C01.FR.21</td><td>C01.FR.20</td><td>The Charging Station SHALL only allow charging on the EVSEs mentioned in the AuthorizationResponse.</td><td></td></tr><tr><td>C01.FR.22</td><td>idToken is not allowed for any EVSE of the Charging Station</td><td>The CSMS SHALL send an AuthorizationResponse in which idTokenInfo.status is NotAtThisLocation and evseld list is empty (or absent).</td><td>Status NotAtThisLocation needed in order to differentiate with the situation in which idToken is allowed on all EVSEs.</td></tr><tr><td>C01.FR.23</td><td>When a transaction is still active, that had been authorized earlier by an IdToken, but which is now no longer authorized for charging AND a new IdToken is presented to the Charging Station for authorization, that differs from the initial idToken</td><td>The Charging Station SHOULD NOT allow the authorization of a different idToken.</td><td>Multiple idTokens for a transaction are most likely not supported by a CSMS.</td></tr><tr><td>C01.FR.24</td><td>When a transaction is still active, that had been authorized earlier by an IdToken, but which is now no longer authorized for charging AND Charging Stations sends an AuthorizationRequest for a new IdToken, that differs from the initial idToken of the transaction</td><td>The CSMS IS RECOMMENDED to respond with an AuthorizationResponse with idTokenInfo.status = NotAtThisTime for this idToken.</td><td>If a second authorization is done by Charging Station then CSMS can reject the idToken.</td></tr><tr><td>C01.FR.25</td><td></td><td>Two IdTokenType elements are considered to be equal when they have the same value for the fields idToken.idToken and idToken.type</td><td>additionalInfo is not taken into account when comparing. See C01.FR.02, C01.FR.03, C01.FR.05 for idToken requirements where idTokens are compared.</td></tr><tr><td>C01.FR.26</td><td>When an idToken has been authorized and the EV Driver does not plug in the charging cable before the timeout set by the Configuration Variable: EVConnectionTimeOut</td><td>Charging Station SHALL end the authorization of idToken</td><td>See also E03.FR.05 and F02.FR.07/08 for additional behavior in case a transaction had already been started.</td></tr></table>
+
+C02 - Authorization using a start button
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization using a start button</td></tr><tr><td>2</td><td>ID</td><td>C02</td></tr><tr><td>3</td><td>Objective(s)</td><td>Make it possible for a Charging Station that has a start button to start charging.</td></tr><tr><td>4</td><td>Description</td><td>For some chargers authorization of a user might not be a requirement. A simple charger might have a button instead of a more expensive RFID reader to start charging. When such a Charging Station start charging, it is not needed to send an AuthorizationRequest. In the TransactionRequest (eventType = Started), IdTokenType information needs to be given, which the CSMS then cannot reject.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver plugs in the charging cable between EV and Charging Station.
+2. The Charging Station sends a NotifyEventRequest with component.name Connector, variable.name AvailabilityState, actualValue Occupied and TransactionRequest (eventType = Started) to notify the CSMS about the cable being plugged in.
+3. The EV Driver presses the start button to start Charging.
+4. The Charging Station starts Charging of the EV.
+5. The Charging Station sends a TransactionRequest (eventType = Updated) message with idToken.type = NoAuthorization to the CSMS to notify the CSMS of the charging that has started.
+6. Upon receipt of TransactionRequest (eventType = Updated), the CSMS responds with TransactionResponse with: IdTokenInfo.status set to Accepted</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFID
+C03 - Authorization using credit/debit card
+C04 - Authorization using PIN-code
+C05 - Authorization for CSMS initiated transactions
+C06 - Authorization using local id type
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station has a start button, instead of an RFID reader to start charging of an EV.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Transaction ongoing on Charging Station, CSMS is aware of transaction.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The start button might also be a mechanical key or something similar.
+Note that the start button can even be omitted if the Charging Station is configured to start charging upon cable connection.
+The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:
+TxStartPoint: EVConnected
+This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use case: E01 - Start Transaction options.</td></tr></table>
+
+# C02 - Authorization using a start button - Requirements
+
+Table 45. C02 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C02.FR.01</td><td>When a transaction is started with a button.</td><td>The Charging Station SHALL send TransactionRequest with an IdTokenType of type: NoAuthorization and the field idToken left empty (empty string).</td></tr><tr><td>C02.FR.02</td><td>CSMS receives a TransactionRequest with an IdTokenType of type: NoAuthorization</td><td>The CSMS SHALL respond with a TransactionResponse with IdTokenInfo.status set Accepted.</td></tr><tr><td>C02.FR.03</td><td>If the Charging Station has implemented an Authorization Cache AND the Charging Station receives IdTokenInfo for an IdTokenType of type NoAuthorization in any message</td><td>The Charging Station SHALL NOT store the information in its Authorization Cache.</td></tr></table>
+
+# C03 - Authorization using credit/debit card
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization using credit card</td></tr><tr><td>2</td><td>ID</td><td>C03</td></tr><tr><td>3</td><td>Objective(s)</td><td>Make it possible to start a transaction using a credit card.</td></tr><tr><td>NOTE</td><td colspan="2">This use case has been moved to section C24 - Ad hoc payment via stand-alone payment terminal as a new use case.</td></tr></table>
+
+# C04 - Authorization using PIN-code
+
+This is an informative use case. Its purpose is to demonstrate the use of the idToken.type KeyCode. Another use of KeyCode might be, for example, a licence plate number.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization using PIN-code</td></tr><tr><td>2</td><td>ID</td><td>C04</td></tr><tr><td>3</td><td>Objective(s)</td><td>To make it possible for a Charging Station that has a key entry terminal to authorize the PIN-code.</td></tr><tr><td>4</td><td>Description</td><td>When a Charging Station has a PIN-code entry terminal, an EV driver enters his/her PIN-code. This PIN-code is sent to the CSMS for validation using an AuthorizationRequest.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver wants to start or stop charging the EV and enters his/her PIN-code into the terminal.
+2. The Charging Station sends an AuthorizationRequest message, with the field idToken.type set to KeyCode, to the CSMS to request authorization.
+3. Upon receipt of the AuthorizationRequest, the CSMS responds with an AuthorizationResponse. This response indicates whether or not the KeyCode is accepted by the CSMS.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFID
+C02 - Authorization using a start button
+C03 - Authorization using credit/debit card
+C05 - Authorization for CSMS initiated transactions
+C06 - Authorization using local id type
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station has a PIN-code entry terminal to start charging of an EV.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Transaction ongoing on Charging Station, CSMS is aware of transaction.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>When the PIN-code is validated in the Charging Station, instead of the CSMS, use case C02 - Authorization Using a Start button applies.</td></tr></table>
+
+
+Figure 23. Sequence Diagram: Authorization using PIN-code
+
+# C04 - Authorization using PIN-code - Requirements
+
+Table 46. C04 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C04.FR.01</td><td>When the CSMS receives an AuthorizationRequest with a keyCode that is not valid at this Charging Station</td><td>The CSMS SHALL respond with an AuthorizationResponse message with status = Invalid.</td></tr><tr><td>C04.FR.02</td><td>When the CSMS receives an AuthorizationRequest with a keyCode that is valid and the EV Driver is allowed to charge at this Charging Station</td><td>The CSMS SHALL respond with an AuthorizationResponse message with status = Accepted.</td></tr><tr><td>C04.FR.03</td><td></td><td>A Charging Station MAY store keyCodes in the Authorization Cache.</td></tr><tr><td>C04.FR.04</td><td>If an idToken of type keyCode is used</td><td>The Charging Station or CSMS SHALL NOT show the IdToken in any logging. key codes should never appear in logs.</td></tr><tr><td>C04.FR.05</td><td></td><td>Language SHALL be specified as RFC-5646 tags, see: [RFC5646], for example: US English is: "en-US".</td></tr><tr><td>C04.FR.06</td><td>If an idToken of type keyCode is used</td><td>It is RECOMMENDED to take measures to prevent brute force attacks, for example by increasing backoff times after attempts to enter an incorrect keyCode.</td></tr></table>
+
+# C05 - Authorization for CSMS initiated transactions
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization for CSMS initiated transactions</td></tr><tr><td>2</td><td>ID</td><td>C05</td></tr><tr><td>3</td><td>Objective(s)</td><td>Enable the CSMS to start a transaction on a Charging Station with a server generated IdToken.</td></tr><tr><td>4</td><td>Description</td><td>When a CSMS needs to start a Transaction on a Charging Station for a Driver that has no RFID, or the RFID is not known. For Example, the EV Driver uses an App to start a transaction. The CSMS needs to determine an IdToken and tell the Charging Station this is not an RFID, so it should not be cached and an authorization is also not needed.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver uses his app to start a charging.
+2. The app sends a start request to the CSMS.
+3. The CSMS determines an IdToken. It can generate a unique id to be used as IdToken for this transaction or can use a token that is provided by the app (for example the ID of the contract of the user).
+4. The CSMS sends a RequestStartTransactionRequest with the IdToken from the previous step to the Charging Station.
+5. The Charging Station accepts the RequestStartTransactionRequest by sending a RequestStartTransactionResponse with Accepted.
+6. The Charging Station starts charging and sends a TransactionEventRequest (eventType = Updated) to notify the CSMS that chargingState has changed.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFID
+C02 - Authorization using a start button
+C03 - Authorization using credit/debit card
+C04 - Authorization using PIN-code
+C06 - Authorization using local id type
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Cable is plugged in.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Transaction ongoing on Charging Station</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>IdTokens MAY be (single use) virtual transaction authorization codes or virtual RFID tokens that deliberately use a non-standard UID format to avoid possible conflict with real UID values. These virtual single use IdTokens are sent with type Central and it is pointless to either cache or authorize these tokens.
+This use case uses an App as example, but this is not a requirement. This use case is valid for any RequestStartTransactionRequest with a server generated IdToken.
+The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:
+TxStartPoint: EVConnected
+This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use case: E01 - Start Transaction options.
+This use case assumes that the configuration variable AuthorizedRemoteStart is false. See use cases F01 and F02 for requirements with AuthorizedRemoteStart.
+Other idToken types can also be used to remote start charging, such an eMAID of the user that is provided by the app.</td></tr></table>
+
+
+Figure 24. Sequence Diagram: Authorization for CSMS initiated transactions
+
+# C05 - Authorization for CSMS initiated transactions Requirements
+
+Table 47. C05 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C05.FR.01</td><td>If the Charging Station receives a RequestStartTransactionRequest with an IdTokenType of type Central.</td><td>The Charging Station SHALL NOT send anauthorizeRequest for the received IdTokenType.</td></tr><tr><td>C05.FR.02</td><td>If the Charging Station has implemented an Authorization Cache AND the Charging Station receives IdTokenInfo for an IdTokenType of type Central in any message</td><td>The Charging Station SHALL NOT store the information in its Authorization Cache. (Same as C03.FR.02)</td></tr><tr><td>C05.FR.03</td><td></td><td>The RemoteStartId SHALL be provided at least once in a TransactionEventRequest.</td></tr><tr><td>C05.FR.04</td><td></td><td>Language SHALL be specified as RFC-4646 tags, see: [RFC5646], example: US English is: "en-US".</td></tr><tr><td>C05.FR.05</td><td></td><td>idToken SHALL also be provided once in the first TransactionEventRequest after a RequestStartTransactionRequest.</td></tr></table>
+
+# C06 - Authorization using local id type
+
+This is an informative use case. Its purpose is to demonstrate the use of the idToken type Local.
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization using local id type</td></tr><tr><td>2</td><td>ID</td><td>C06</td></tr><tr><td>3</td><td>Objective(s)</td><td>Enable the Charging Station to start charging with a locally generated IdToken.</td></tr><tr><td>4</td><td>Description</td><td>When a Charging Station needs to start a Transaction for a Driver that has no RFID, or the RFID is not known. For Example, the EV Driver uses a parking ticket to start charging.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Payment Terminal, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. An EV driver drives into a garage, takes a parking ticket at the barrier at the entrance.
+2. Parks his EV at a Charging Station.
+3. Plugs in the charging cable.
+4. Scans/inserts his parking ticket on the Charging Station to start Charging
+5. EV is charging, driver leaves.
+6. EV driver returns, inserts parking ticket into a payment kiosk
+7. Pays for parking and charging
+8. The Payment terminal/kiosk sends a stop command via the CSMS to the Charging Station.
+9. EV driver unplugs the charging cable and drives away.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFID
+C02 - Authorization using a start button
+C03 - Authorization using credit/debit card
+C04 - Authorization using PIN-code
+C05 - Authorization for CSMS initiated transactions
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Integrated parking & charging payment system</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The transaction has completed at the Charging Station and Transaction information is available at the CSMS.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>This use case uses an Parking Ticket as example, but this is not a requirement.
+The communication between the Payment Terminal and the CSMS is outside of scope of OCPP.
+The scenario description and sequence diagram above are based on the Configuration Variable for start & stop transaction being configured as follows:
+TxStartPoint: EVConnected
+TxStopPoint: ParkingBayOccupancy, EVConnected
+This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use cases: E01 - Start Transaction options and E06 - Stop Transaction options.</td></tr></table>
+
+
+Figure 25. Sequence Diagram: Authorization using local id type
+
+# C06 - Authorization using local id type - Requirements
+
+Table 48. C06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C06.FR.01</td><td></td><td>The Charging Station SHALL only offer energy after authorization. (Same as C01.FR.01)</td></tr><tr><td>C06.FR.02</td><td>If an IdTokenType with type Local is presented by the EV Driver.</td><td>The Charging Station SHALL send AuthorizationRequest to the CSMS to request authorization.</td></tr><tr><td>C06.FR.03</td><td></td><td>AuthorizationRequest SHOULD only be used for the authorization of an identifier for charging. (Same as C01.FR.04)</td></tr><tr><td>C06.FR.04</td><td>If the CSMS receives an AuthorizationRequest.</td><td>it SHALL respond with an AuthorizationResponse and SHALL include an authorization status value indicating acceptance or a reason for rejection.</td></tr></table>
+
+# 2.2. ISO 15118 Authorization
+
+This authorization section originates from ISO15118-1 for the use of Plug & Charge functionalities.
+
+# C07 - Authorization using Contract Certificates
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization using Contract Certificates</td></tr><tr><td>2</td><td>ID</td><td>C07</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 D2</td></tr><tr><td>3</td><td>Objective(s)</td><td>See ISO15118-1, use case Objective D2, page 26.</td></tr><tr><td>4</td><td>Description</td><td>See ISO15118-1, use case Description D2 (first bullet), page 26.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>15118:See ISO15118-1, use case Description D2, Scenario Description, first 2 bullets, page 26.OCPP:3. The Charging Station sends an AuthorizationRequest message to the CSMS containing the eMAID and data needed for an OCSP request with regards to the contract certificate and certificate chain.4. The CSMS replies with an agreement or non-agreement, and the certificate status.5. Service starts after successful authorization of the IDs.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFID C02 - Authorization using a start button C03 - Authorization using credit/debit card C04 - Authorization using PIN-code C05 - Authorization for CSMS initiated transactions C06 - Authorization using local id type C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM) C15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>A contract Certificate is installed in the EV.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The validity of the Contract Certificate is determined.</td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>In edition 1 of 15118, the message timeout of the PaymentDetailsReq/Res message is 5 seconds. In case certificate verification cannot be completed in that time it is possible to complete this during the AuthorizationReq/Res, which can be extended up to 60 seconds.When the Charging Station is offline, it is recommended to omit the payment option for ISO 15118 contract certificates from the ServiceDiscoveryRes and revert to External Identification Means (use case C08), because certificate status cannot be checked.</td></tr></table>
+
+
+Figure 26. Authorization using Contract Certificates with ISO 15118-2
+
+
+Figure 27. Authorization using contract certificates with ISO 15118-20
+
+# C07 - Authorization using Contract Certificates - Requirements
+
+Table 49. C07 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C07.FR.01</td><td>When Charging Station is online</td><td>The Charging Station SHALL send an AuthorizationRequest to the CSMS for validation.</td><td></td></tr><tr><td>C07.FR.02</td><td>C07.FR.01</td><td>The AuthorizationRequest SHALL contain the eMAID and data needed for an OCSP request with regards to the contract certificate and certificate chain.</td><td></td></tr><tr><td>C07.FR.04</td><td>If the CSMS receives an AuthorizationRequest.</td><td>It SHALL respond with an AuthorizationResponse and SHALL include an authorization status value indicating acceptance or a reason for rejection.</td><td></td></tr><tr><td>C07.FR.05</td><td>C07.FR.02</td><td>The CSMS SHALL verify validity of the certificate and certificate chain via real-time or cached OCSP data.</td><td></td></tr><tr><td>C07.FR.06</td><td>C07.FR.01 AND If Charging Station is not able to validate a contract certificate, because it does not have the associated root certificate AND CentralContractValidationAllowed is true</td><td>The Charging Station SHALL pass the contract certificate chain to the CSMS in certificate attribute (in PEM format) of AuthorizationRequest for validation by CSMS.</td><td></td></tr><tr><td>C07.FR.07</td><td>When Charging Station is offline AND ContractValidationOffline is false</td><td>The Charging Station SHALL NOT allow charging.</td><td></td></tr><tr><td>C07.FR.08</td><td>When Charging Station is offline AND ContractValidationOffline is true</td><td>The Charging Station SHALL try to validate the contract certificate locally.</td><td></td></tr><tr><td>C07.FR.09</td><td>C07.FR.08 AND Contract certificate is valid AND LocalAuthorizationOffline is true</td><td>The Charging Station SHALL lookup the eMAID in Local Authorization List or Authorization Cache.</td><td></td></tr><tr><td>C07.FR.10</td><td>C07.FR.09 AND eMAID found in Local Authorization List</td><td>The Charging Station SHALL behave according to use case C13 - Offline Authorization through Local Authorization List.</td><td></td></tr><tr><td>C07.FR.11</td><td>C07.FR.09 AND eMAID found in Authorization Cache</td><td>The Charging Station SHALL behave according to use case C12 - Start Transaction - Cached Id.</td><td></td></tr><tr><td>C07.FR.12</td><td>C07.FR.09 AND eMAID is not found AND OfflineTxForUnknownIdEnabled = true</td><td>The Charging Station SHALL allow charging according to use case C15 - Offline Authorization of unknown Id.</td><td></td></tr><tr><td>C07.FR.13</td><td>C07.FR.04 AND the certificate chain (provided in certificate or iso15118CertificateHashData) is valid AND authorization status of idToken is one of Restricted, Expiration, Invalid, Unknown</td><td>CSMS SHALL return an AuthorizationResponse containing a certificateStatus = ContractCancelled and the authorization status in idTokenInfo.status.</td><td>Certificate is valid, but EMAID is not accepted.</td></tr><tr><td>C07.FR.14</td><td>C07.FR.04 AND the certificate chain (provided in certificate or iso15118CertificateHashData) is valid AND authorization status of idToken is NOT one of Restricted, Expiration, Invalid, Unknown</td><td>CSMS SHALL return an AuthorizationResponse containing a certificateStatus = Accepted and the authorization status in idTokenInfo.status.</td><td>Charging can still not be allowed if idTokenInfo.status is other than Accepted (e.g. ConcurrentTx or NotAtThisLocation).</td></tr><tr><td>C07.FR.15</td><td>C07.FR.04 AND the certificate chain (provided in certificate or iso15118CertificateHashData) has expired</td><td>CSMS SHALL return an AuthorizationResponse containing a certificateStatus = CertificateExpired and an idTokenInfo.status = Expired</td><td>If certificate is expired, then status of idToken is also reported expired.</td></tr><tr><td>C07.FR.16</td><td>C07.FR.04 AND the certificate chain (provided in certificate or iso15118CertificateHashData) has been revoked</td><td>CSMS SHALL return an AuthorizationResponse containing a certificateStatus = CertificateRevoked and an idTokenInfo.status = Invalid</td><td>If certificate is revoked, then status of idToken is reported as invalid.</td></tr><tr><td>C07.FR.17</td><td>C07.FR.04 AND the certificate chain (provided in certificate or iso15118CertificateHashData) cannot be verified or is invalid</td><td>CSMS SHALL return an AuthorizationResponse containing a certificateStatus = CertChainError and an idTokenInfo.status = Invalid</td><td>If certificate cannot be verified, then status of idToken is reported as invalid.</td></tr></table>
+
+# C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)
+
+Updated in OCPP 2.1
+
+(EIM)
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization at EVSE using ISO 15118 External Identification Means (EIM)</td></tr><tr><td>2</td><td>ID</td><td>C08 / 15118-1 D4</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 D4</td></tr><tr><td>3</td><td>Objective(s)</td><td>To authorize the EV via the Charging Station, with help of the CSMS. Also see ISO15118-1, use case Objective D4, page 28.</td></tr><tr><td>4</td><td>Description</td><td>The Charging Station sends an AuthorizationRequest message based on information provided by the EV. Also see ISO15118-1, use case Description D4 up to and including "NOTE", page 28.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>15118See ISO15118-1, use case Description (Scenarios Description) D4, page 28.OCPP1. The Charging Station sends an AuthorizationRequest with an idToken containing the External Identification Means (EIM).2. The CSMS responds with an AuthorizationResponse.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFIDC02 - Authorization using a start buttonC03 - Authorization using credit/debit cardC04 - Authorization using PIN-codeC05 - Authorization for CSMS initiated transactionsC06 - Authorization using local id typeC07 - Authorization using Contract CertificatesC15 - Unknown Offline Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Communication between EV and EVSE SHALL be established successfully.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Authorization is successful. Also see ISO15118-1, use case End conditions D4, page 28.</td></tr><tr><td>7</td><td>Remark(s)</td><td>Please note that all identification means mentioned in the previous section can be applied to this use case. The only difference is the availability of 15118 communication.</td></tr></table>
+
+
+Figure 28. Sequence Diagram: Authorization using external identification means with ISO 15118-2
+
+
+Figure 29. Sequence Diagram: Authorization using external identification means with ISO 15118-20
+
+Source: ISO15118-1
+
+# C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM) - Requirements
+
+Table 50. C08 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C08.FR.01</td><td></td><td>The Charging Station SHALL send the identification to the CSMS for validation.</td></tr><tr><td>C08.FR.02</td><td></td><td>EV Driver SHALL activate the authorization within a specific time after connecting the EV to the EVSE or the EVSE SHALL have an HMI to authorize the restart of the identification process.</td></tr></table>
+
+# 2.3. Groupld
+
+# C09 - Authorization by Groupld
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization by GroupId</td></tr><tr><td>2</td><td>ID</td><td>C09</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable 2 EV drivers with different IdTokens to be authorized using the same GroupId.</td></tr><tr><td>4</td><td>Description</td><td>This use cases covers how a Charging Station can authorize an action for an EV Driver based on GroupId information. This could for example be used if 2 people regularly use the same EV: they can use their own IdToken (e.g. RFID card), and can deauthorize transactions that were started with the other idToken (with the same GroupId).</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver1, EV Driver2</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver 1 presents an IdToken.
+2. The Charging Station sends AuthorizationRequest to the CSMS to request authorization.
+3. Upon receipt of AuthorizationRequest, the CSMS responds with AuthorizationResponse. This response message includes the GroupId.
+4. The Charging Station stores the GroupIdToken with the authorization information of EV Driver 1.
+5. EV Driver 2 presents an IdToken.
+6. The Charging Station sends AuthorizationRequest to the CSMS to request authorization.
+7. Upon receipt of AuthorizationRequest, the CSMS responds with AuthorizationResponse. This response message includes the GroupId.
+8. Based on the matching GroupId information in both responses, the Charging Station authorizes the action.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>EV Driver 1 and EV Driver 2 have the same GroupId.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>GroupId is known by the Charging Station.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>IdTokenizerType data used as groupId may often use a shared central account identifier for the GroupId, instead of using one of the idTokens belonging to an account.
+The groupId mechanism as described in this use case also works when using the Authorization Cache, as the groupId is stored in the cache.</td></tr></table>
+
+
+Figure 30. Sequence Diagram: Authorization by Groupld
+
+# C09 - Authorization by Groupld - Requirements
+
+Table 51. C09 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C09.FR.02</td><td></td><td>IdTokens that are part of the same group for authorization purposes SHALL have a common group identifier in the optional groupIdToken element in IdTokenInfo</td></tr><tr><td>C09.FR.03</td><td>When a transaction has been authorized/started with a certain IdToken.</td><td>An EV Driver with a different, valid IdToken, but with the same groupldToken SHALL be authorized to stop the transaction.</td></tr><tr><td>C09.FR.04</td><td>C09.FR.03 AND If both IdTokens with their corresponding GroupIdTokens are present in either the Local Authorization List or Authorization Cache.</td><td>The Charging Station MAY send an Request to the CSMS.</td></tr><tr><td>C09.FR.05</td><td>C09.FR.03 AND (NOT C09.FR.07) AND If the newly presented IdToken with its corresponding GroupIdToken is not present in either the Local Authorization List or Authorization Cache.</td><td>The Charging Station SHALL send an Request to the CSMS.</td></tr><tr><td>C09.FR.07</td><td>When an idToken is presented during a transaction that has been authorized AND (a) the presented idToken is the same as the idToken that started the authorization OR (b) when the presented idToken is in the Local Authorization List or Authorization Cache AND is valid AND has the same GroupIdToken as the IdToken that started the authorization.</td><td>The Charging Station SHALL end the authorization of the transaction, without first sending an Request</td></tr><tr><td>C09.FR.09</td><td>If the IdToken in Request has an associated groupIdToken</td><td>AuthorizationResponse from CSMS SHALL include groupIdToken.</td></tr><tr><td>C09.FR.10</td><td></td><td>AuthorizationResponse SHALL include an authorization status value indicating acceptance or a reason for rejection.</td></tr><tr><td>C09.FR.11</td><td>C09.FR.03 AND A different IdToken is presented for stopping, which has the same GroupIdToken, but does not have status = Accepted</td><td>The Charging Station SHALL NOT stop the transaction.</td></tr><tr><td>C09.FR.12</td><td>If a TransactionEventRequest contains an IdToken and idToken has an associated groupIdToken</td><td>TransactionResponse from CSMS SHALL include groupIdToken.</td></tr><tr><td>C09.FR.13</td><td></td><td>The field idToken.type of a GroupIdToken SHALL be Central</td></tr></table>
+
+# 2.4. Authorization Cache
+
+# C10 - Store Authorization Data in the Authorization Cache
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Store Authorization Data in the Authorization Cache</td></tr><tr><td>2</td><td>ID</td><td>C10</td></tr><tr><td>3</td><td>Objective(s)</td><td>To store all the latest received IdTokens in the Authorization Cache.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the Charging Station autonomously stores a record of previously presented identifiers that have been successfully authorized by the CSMS in the Authorization Cache. (Successfully meaning: a response received on a message containing an IdToken)</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station receives a AuthorizationResponse, ReserveNowRequest or TransactionEventResponse response message from the CSMS.
+2. The Cache is updated by the Charging Station using all received IdTokenInfo from the response message from the CSMS.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>n/a</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>An Authorization Cache is implemented and and the value of the AuthCacheEnabled Configuration Variable is set to 'true'.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station stored the newly received IdTokenInfo data in the Authorization Cache.
+Failure postcondition:
+The Charging Station was not able to store the Authorization Cache.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 31. Sequence Diagram: Store Authorization Data in the Authorization Cache
+
+# C10 - Store Authorization Data in the Authorization Cache - Requirements
+
+Table 52. C10 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C10.FR.01</td><td></td><td>The Authorization Cache SHALL contain all the latest received identifiers (regardless of their status).</td><td></td></tr><tr><td>C10.FR.02</td><td></td><td>Cache values SHOULD be persistent across reboots and power outages.</td><td>Hence cache values SHOULD be stored in non-volatile memory.</td></tr><tr><td>C10.FR.03</td><td>When an IdToken is presented that is stored in the Authorization Cache with status other than Accepted, and the Charging Station is online.</td><td>AuthorizationRequest SHALL be sent to the CSMS to check the current state of the IdToken.</td><td>To check the current state of the identifier.</td></tr><tr><td>C10.FR.04</td><td>Upon receipt of AuthorizationResponse.</td><td>The Charging Station SHALL update the Authorisation Cache entry.</td><td>The update is to be done with the IdTokenInfo value from the response as described under Authorization Cache.</td></tr><tr><td>C10.FR.05</td><td>Upon receipt of TransactionEventResponse.</td><td>The Charging Station SHALL update the Authorisation Cache entry.</td><td>The update is to be done with the IdTokenInfo value from the response as described under Authorization Cache.</td></tr><tr><td>C10.FR.07</td><td></td><td>The Charging Station SHALL have a mechanism to accept new cache entries even when it is full, by deleting older entries.</td><td>It is suggested to remove any entries with status other than Accepted first, and then the oldest valid entries to make space for the new entry.</td></tr><tr><td>C10.FR.08</td><td>When IdTokenInfoType does not contain a value for cacheExpiryDateTime</td><td>The time a token is considered to be present in the cache is determined by the Configuration Variable AuthCacheLifeTime. This variable indicates how long it takes until a token expires in the Authorization Cache since it is last used.</td><td>This expiry of the cache is not the same as the expiration date that is set for the IdToken (e.g. RFID card expiry date).</td></tr><tr><td>C10.FR.10</td><td>NOT C10.FR.13 AND when more than AuthCacheLifeTime seconds have passed since idTokenInfo was last updated</td><td>The Authorization Cache entry SHALL be removed from the cache or changed to Expired.</td><td>A cacheExpiryDateTime in the past will prevent an IdToken from being stored in the authorization cache, or remove it from authorization cache if it was already present. This is used e.g. for prepaid accounts that should not be kept in authorization cache.</td></tr><tr><td>C10.FR.11</td><td></td><td>Whether the Authorization Cache is enabled or disabled SHALL be controlled by the AuthCacheEnabled Configuration Variable.</td><td></td></tr><tr><td>C10.FR.12</td><td></td><td>It is RECOMMENDED to store personal information in the Authorization Cache securely</td><td>E.g. by only storing hashed Tokens in the cache.</td></tr><tr><td>C10.FR.13</td><td>When IdTokenInfoType contains a value for cacheExpiryDateTime and current time is greater than idTokenInfo.cacheExpiryDateTime</td><td>The Authorization Cache entry SHALL be removed from the cache or changed to Expired.</td><td>This expiry of the cache is not the same as the expiration date that is set for the IdToken (e.g. RFID card expiry date).</td></tr><tr><td>C10.FR.14 (2.1)</td><td>C10.FR.04 OR C10.FR.05</td><td>Charging Station SHALL store all IdTokenType fields except for the additionalInfo field, together with all fields of IdTokenInfoType from AuthorizationResponse or TransactionResponse, except for the additionalInfo field in groupldToken.</td><td>additionalInfo of IdToken or groupldToken is not cached.</td></tr></table>
+
+C11 - Clear Authorization Data in Authorization Cache
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Clear Authorization Data in Authorization Cache</td></tr><tr><td>2</td><td>ID</td><td>C11</td></tr><tr><td>3</td><td>Objective(s)</td><td>To clear all IdTokens in the Authorization Cache.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS can request a Charging Station to clear its Authorization Cache.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS requests the Charging Station to clear its Authorization Cache by sending ClearCacheRequest.
+2. The Charging Station responds with the status Accepted.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Authorization Cache is supported and enabled by the AuthCacheEnabled Configuration Variable.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station Successfully cleared the Authorization Cache.
+Failure postcondition:
+The Charging Station was not able to clear the Authorization Cache.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 32. Sequence Diagram: Clear Authorization Data in Authorization Cache
+
+# C11 - Clear Authorization Data in Authorization Cache - Requirements
+
+Table 53. C11 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C11.FR.01</td><td>If the CSMS sends a ClearCacheRequest.</td><td>The Charging Station SHALL attempt to clear its Authorization Cache.</td></tr><tr><td>C11.FR.02</td><td>C11.FR.01</td><td>The Charging Station SHALL send ClearCacheResponse message indicating whether it was able to clear its Authorization Cache.</td></tr><tr><td>C11.FR.03</td><td>C11.FR.02 AND Charging Station successfully cleared its Authorization Cache.</td><td>The Charging Station SHALL send ClearCacheResponse message with the status Accepted.</td></tr><tr><td>C11.FR.04</td><td>C11.FR.02 AND Configuration variable AuthCacheEnabled is false</td><td>The Charging Station SHALL send ClearCacheResponse message with the status Rejected.</td></tr><tr><td>C11.FR.05</td><td>C11.FR.02 AND Charging Station failed to clear its Authorization Cache.</td><td>The Charging Station SHALL send ClearCacheResponse message with the status Rejected.</td></tr></table>
+
+C12 - Start Transaction - Cached Id
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Start Transaction - Cached Id</td></tr><tr><td>2</td><td>ID</td><td>C12</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the EV Driver to Online start a transaction by using the Authorization Cache. So the Charging Station can respond faster, as no AuthorizationRequest is being sent.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the EV Driver is authorized to start a transaction while the Charging Station uses Cached IdToken.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver plugs in the cable.
+2. The Charging Station starts the transaction.
+3. The EV Driver presents an IdToken.
+4. The Charging Station verifies the IdToken with the Authorization Cache.
+5. The Charging Station updates the transaction.
+6. The Charging Station starts charging.
+7. E02 - Start Transaction - Cable Plugin First applies.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>AuthCacheEnabled = true
+LocalPreauthorize = true
+The Id of the EV Driver is Cached in the Authorization Cache
+Id is valid</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The EV Driver is authorized to start a transaction by using the Authorization Cache.
+Failure postcondition:
+The UserId was not found in the Authorization Cache and:
+* Online Charging Station: the Charging Station issues an AuthorizationRequest and that fails too.
+* In an offline situation, behaviour of the Charging Station is defined by Configuration Variable OfflineTxForUnknownIdEnabled.</td></tr><tr><td>7</td><td>Error handling</td><td>When the Charging Station has an IdToken in the Authorization Cache, which is valid in the Authorization Cache, but is no longer valid in the CSMS: The Charging Station will receive the IdTokenInfo in the TransactionEventResponse which contains the newer invalid status. What happens in such a cases depends on the Configuration Variables: MaxEnergyOnInvalidId and StopTxOnInvalidId.</td></tr><tr><td>8</td><td>Remark(s)</td><td>If the Charging Station has implemented an Authorization Cache, then upon receipt of a AuthorizationResponse message the Charging Station updates the Cache entry.
+For a Cached valid IdToken it is not logical to send AuthorizationRequest. The TransactioneventResponse message also contains the IdToken information. If the IdToken has become no longer valid, the Charging Station will learn this from this TransactioneventResponse. So if the IdToken is no longer valid, the Charging Station might decide to stop the energy offering, and depending on the configuration even stop the transaction.
+The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:
+TxStartPoint: EVConnected
+This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use case: E01 - Start Transaction options.</td></tr></table>
+
+
+Figure 33. Sequence Diagram: Start Transaction - Cached Id
+
+# C12 - Start Transaction - Cached Id - Requirements
+
+Table 54. C12 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C12.FR.02</td><td>When an identifier is presented that is stored in the Authorization Cache as Accepted.</td><td>The Charging Station SHALL send a TransactionRequest with idToken to the CSMS.</td><td></td></tr><tr><td>C12.FR.03</td><td>C12.FR.02</td><td>The CSMS SHALL check the authorization status of the IdToken when processing this TransactionRequest.</td><td></td></tr><tr><td>C12.FR.04</td><td>C12.FR.02 AND The cable is plugged in.</td><td>The Charging Station SHALL start the energy offer.</td><td></td></tr><tr><td>C12.FR.05</td><td>When an identifier is presented that is stored in the Authorization Cache with status other than Accepted, and the Charging Station is online.</td><td>The Charging Station SHALL send anauthorizeRequest to the CSMS.</td><td>To check the current state of the identifier.</td></tr><tr><td>C12.FR.06</td><td>When IdTokenInfo is received for an identifier in the Cache.</td><td>The Authorization Cache SHALL be updated using the received IdTokenInfo.</td><td></td></tr><tr><td>C12.FR.09</td><td>IdTokens that have a groupId equal to MasterPassGroupId</td><td>SHALL NOT be allowed to start a transaction.</td><td></td></tr></table>
+
+# 2.5. Local Authorization list
+
+# C13 - Offline Authorization through Local Authorization List
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Offline Authorization through Local Authorization List</td></tr><tr><td>2</td><td>ID</td><td>C13</td></tr><tr><td>3</td><td>Objective(s)</td><td>To authorize an idToken by using the Local Authorization List while Offline.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how to authorize an IdToken, when communication with the CSMS is not possible.The Local Authorization List is a list of idTokens that can be synchronized with the CSMS. The list contains the authorization status of a selected set of idTokens as managed by the CSMS.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station is Offline2. The EV Driver presents IdToken.3. The Charging Station checks if the IdToken is known and has status Accepted in the Local Authorization List.4. The Charging Station start charging.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Local Authorization List is availableLocal Authorization List is enabled via LocalAuthListEnabledCharging Station is OfflineThe Id of the EV Driver is in the Local Authorization ListId is valid</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The Charging Station accepts tokens on the Local Authorization List when it is offline.Failure postcondition:The Charging Station does not accept tokens on the Local Authorization List when it is offline.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 34. Sequence Diagram: Offline Authorization through Local Authorization List
+
+# C13 - Offline Authorization through Local Authorization List - Requirements
+
+Table 55. C13 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C13.FR.01</td><td></td><td>Where both Authorization Cache and Local Authorization List are supported, a Charging Station SHALL treat Local Authorization List entries as having priority over Authorization Cache entries for the same identifiers.</td><td></td></tr><tr><td>C13.FR.02</td><td>If configuration variable OfflineTxForUnknownIdEnabled is false AND The Charging Station is offline AND LocalAuthListSupportsExpiryDateTime does not exist or is false</td><td>Only identifiers that are present in a Local Authorization List that have a status Accepted SHALL be allowed to authorize a transaction.</td><td>This means that Charging Station does not check for cacheExpiryDateTime.</td></tr><tr><td>C13.FR.03</td><td></td><td>The Charging Station MAY authorize the IdToken locally without involving the CSMS.</td><td>As described in Local Authorization List.</td></tr><tr><td>C13.FR.04</td><td>If configuration variable OfflineTxForUnknownIdEnabled is true AND The Charging Station is offline AND LocalAuthListSupportsExpiryDateTime does not exist or is false</td><td>Any identifier that is present in neither the Authorization Cache nor the Local Authorization List SHALL be allowed to authorize a transaction AND any identifiers that are present in a Local Authorization List that have a status Accepted SHALL be allowed to authorize a transaction.</td><td>This means that Charging Station does not check for cacheExpiryDateTime. See also C15.FR.08</td></tr><tr><td>C13.FR.05</td><td>If configuration variable OfflineTxForUnknownIdEnabled is false AND The Charging Station is offline AND LocalAuthListSupportsExpiryDateTime = true</td><td>Only identifiers that are present in a Local Authorization List that have a status Accepted and for which cacheExpiryDateTime has not passed SHALL be allowed to authorize a transaction.</td><td>When cacheExpiryDateTime is absent, the idToken will not expire in Local Authorization List.</td></tr><tr><td>C13.FR.06</td><td>If configuration variable OfflineTxForUnknownIdEnabled is true AND The Charging Station is offline AND LocalAuthListSupportsExpiryDateTime = true</td><td>Any identifier that is present in neither the Authorization Cache nor the Local Authorization List SHALL be allowed to authorize a transaction AND any identifiers that are present in a Local Authorization List that have a status Accepted and for which cacheExpiryDateTime has not passed SHALL be allowed to authorize a transaction.</td><td>This means that an expired token in the Local Authorization List is not authorized, because it is not an "unknown id".</td></tr></table>
+
+# C14 - Online Authorization through Local Authorization List
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Online Authorization through Local Authorization List</td></tr><tr><td>2</td><td>ID</td><td>C14</td></tr><tr><td>3</td><td>Objective(s)</td><td>To authorize an IdToken by using the Local Authorization List while Online.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how to authorize an IdToken via the Local Authorization List while the Charging Station is online. When online the Charging Station can then locally authorize the IdToken, and is not required to send an AuthorizationRequest for a known IdToken.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver presents IdToken
+2. The Charging Station checks if the IdToken is known and has status Accepted in the Local Authorization List.
+3. If the IdToken is not known, or the IdToken is not Accepted the Charging Station sends an AuthorizationRequest
+4. The Charging Station starts charging.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Local Authorization List is available
+Local Authorization List is enabled via LocalAuthListEnabled
+The Id of the EV Driver is in the Local Authorization List
+Id is valid LocalPreAuthorization is set to true</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station accepts tokens on the Local Authorization List.
+Failure postcondition:
+The Charging Station does not accept tokens on the Local Authorization List.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 35. Sequence Diagram: Online Authorization through Local Authorization List
+
+# C14 - Online Authorization through Local Authorization List - Requirements
+
+Table 56. C14 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C14.FR.01</td><td></td><td>Where both Authorization Cache and Local Authorization List are supported, a Charging Station SHALL treat Local Authorization List entries as having priority over Authorization Cache entries for the same identifiers.</td><td>Same as C13.FR.01</td></tr><tr><td>C14.FR.02</td><td>Identifier presented is in the Local Authorization List with a status Accepted AND LocalAuthListSupportsExpiryDateTime does not exist or is false</td><td>The Charging Station SHALL start charging without sending an InvalidateRequest.</td><td>This means that Charging Station does not check for cacheExpiryDateTime.</td></tr><tr><td>C14.FR.03</td><td>Identifiers presented is in the Local Authorization List with a status OTHER than Accepted</td><td>The Charging Station SHALL send an InvalidateRequest to try to authorize this IdToken.</td><td></td></tr><tr><td>C14.FR.04</td><td>Identifier presented is in the Local Authorization List with a status Accepted AND LocalAuthListSupportsExpiryDateTime = true AND the cacheExpiryDateTime has not passed</td><td>The Charging Station SHALL start charging without sending an InvalidateRequest.</td><td>When cacheExpiryDateTime is absent, the idToken will not expire in Local Authorization List.</td></tr><tr><td>C14.FR.05</td><td>Identifier presented is in the Local Authorization List with a status Accepted AND LocalAuthListSupportsExpiryDateTime = true AND the cacheExpiryDateTime has passed</td><td>The Charging Station SHALL send an InvalidateRequest to try to authorize this IdToken.</td><td>IdToken will be disregarded, as if not present in Local Authorization List, when cacheExpiryDateTime has passed.</td></tr></table>
+
+# 2.6. Offline Authorization
+
+C15 - Offline Authorization of unknown Id
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Offline Authorization of unknown Id</td></tr><tr><td>2</td><td>ID</td><td>C15</td></tr><tr><td></td><td>Parent use case</td><td>C12 - Start Transaction - Cached Id</td></tr><tr><td>3</td><td>Objective(s)</td><td>To allow automatic authorization of any "unknown" identifiers that cannot be explicitly authorized by Authorization Cache entries.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes the scenario of presented "unknown" identifiers, other than are present in an Authorization Cache or Local Cache entry using OfflineTxForUnknownIdEnabled.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver wants to start charging the EV and presents the IdToken.
+2. The Charging Station checks the Authorization Cache, the IdToken is not present in the Authorization Cache.
+3. The Charging Station checks the Local Authorization List, the IdToken is not present in the Local Authorization List.
+4. The Charging Station accepts the unknown IdToken if OfflineTxForUnknownIdEnabled is set True
+5. The Charging Station rejects the unknown IdToken if OfflineTxForUnknownIdEnabled is set False</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization using RFID
+C02 - Authorization using a start button
+C03 - Authorization using credit/debit card
+C04 - Authorization using PIN-code
+C05 - Authorization for CSMS initiated transactions
+C06 - Authorization using local id type
+C07 - Authorization using Contract Certificates
+C08 - Authorization at EVSE using ISO 15118 External Identification Means (EIM)</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station is Offline.
+Unknown IdToken presented (Not in the Authorization Cache and/or Local Authorization List).</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The authorization status in TransactionEventResponse, that is received once the Charging Station is online, is Accepted.
+Failure postcondition:
+The authorization status in TransactionEventResponse that is received once the Charging Station is online, is not Accepted, although OfflineTxForUnknownIdEnabled is True.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>This applies to all types of identifiers, including an eMAID that is presented as part of an ISO 15118 contract certificate.</td></tr></table>
+
+
+Figure 36. Sequence Diagram: Start Transaction - Unknown Offline Authorization
+
+# C15 - Offline Authorization of unknown Id - Requirements
+
+Table 57. C15 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C15.FR.01</td><td>If the identifier is authorized via OfflineTxForUnknownIdEnabled</td><td>The Charging Station SHALL NOT add the token to Authorization Cache</td><td></td></tr><tr><td>C15.FR.02</td><td>When connection to the CSMS is restored</td><td>The Charging Station SHALL send a TransactionRequest for any transaction that was authorized offline.</td><td>As explained in transaction-related message handling</td></tr><tr><td>C15.FR.03 (2.1)</td><td>C15.FR.02 AND The authorization status in TransactionResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is true AND TxStopPoint does NOT contain: (Authorized OR PowerPathClosed OR EnergyTransfer)</td><td>The Charging Station SHALL stop the energy transfer and send TransactionRequest (eventType = Updated) with triggerReason set to Deauthorized and chargingState set to EVConnected.</td><td>The use of chargingState SuspendedEVSE instead of EVConnected in this situation has been deprecated as of OCPP 2.1.</td></tr><tr><td>C15.FR.04</td><td>C15.FR.02 AND The authorization status in TransactionEventResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is true AND TxStopPoint does contain: (Authorized OR PowerPathClosed OR EnergyTransfer)</td><td>The Charging Station SHALL stop the transaction and send TransactionRequest (eventType = Ended) with triggerReason set to Deauthorized and stoppedReason set to DeAuthorized.</td><td></td></tr><tr><td>C15.FR.05</td><td>C15.FR.04 AND If the Charging Station has the possibility to lock the Charging Cable</td><td>The Charging Station SHOULD keep the Charging Cable locked until the owner presents his identifier.</td><td></td></tr><tr><td>C15.FR.06</td><td>C15.FR.02 AND The authorization status in TransactionEventResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is set to false AND MaxEnergyOnInvalidId is not implemented or has been exceeded. TxStopPoint does NOT contain: EnergyTransfer</td><td>The Charging Station SHALL stop the energy delivery to the EV immediately and send TransactionRequest (eventType = Updated) with triggerReason set to ChargingStateChanged and chargingState set to SuspendedEVSE</td><td></td></tr><tr><td>C15.FR.07</td><td>C15.FR.02 AND The authorization status in TransactionEventResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is set to false AND MaxEnergyOnInvalidId is set and has NOT been exceeded.</td><td>Energy delivery to the EV SHALL be allowed until the amount of energy specified in MaxEnergyOnInvalidId has been reached.</td><td></td></tr><tr><td>C15.FR.08</td><td>When an unknown identifier is presented AND OfflineTxForUnknownIdEnabled is set to true</td><td>The Charging Station SHALL accept the presented IdToken.</td><td></td></tr></table>
+
+# 2.7. Master Pass
+
+C16 - Stop Transaction with a Master Pass
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Stop Transaction with a Master Pass</td></tr><tr><td>2</td><td>ID</td><td>C16</td></tr><tr><td>3</td><td>Objective(s)</td><td>Enable stopping of transactions by use of a Master Pass (for example for: Law Enforcement officials).</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how somebody with a Master Pass (User) can stop (selected) ongoing transactions, so the cable becomes unlocked. This Master Pass can be configured in: MasterPassGroupId.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, User</td></tr><tr><td></td><td>Scenario description</td><td>1. The User (Law Enforcement official) presents his IdToken at the Charging Station.
+2. The Charging Station sends AuthorizationRequest to the CSMS to request authorization.
+3. Upon receipt of AuthorizationRequest, the CSMS responds with AuthorizationResponse. This response message contains a GroupId that equals the value of the Configuration Variable MasterPassGroupId and the idToken is valid.
+4a. If the Charging Station has a UI, then the Charging Station "Shows" the Master Pass UI.
+5a. The user selects which transactions to stop.
+6a. The Charging Station stops the selected transaction(s) AND sends a TransactionEventRequest (eventType = Ended, stopReason = MasterPass) to the CSMS for every stopped transaction.
+7a. Upon receipt of TransactionEventRequest the CSMS responds with TransactionEventResponse.
+4b. If the Charging Station does NOT have a UI, then the Charging Station stops all transactions AND sends a TransactionEventRequest (eventType = Ended, stopReason = MasterPass) to the CSMS for every stopped transaction.
+5b. Upon receipt of TransactionEventRequest the CSMS responds with TransactionEventResponse.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>C01 - EV Driver Authorization</td></tr><tr><td>5</td><td>Prerequisites</td><td>Ongoing Transaction(s)
+Configuration Variable: MasterPassGroupId set.
+Users IdToken has groupId equal to the configured MasterPassGroupId.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>(Selected) transaction(s) stopped.</td></tr><tr><td>7</td><td>Error Handling</td><td>When the user does not make a selection before an acceptable timeout, the Charging Station SHALL go back to normal operation.</td></tr><tr><td>8</td><td>Remarks</td><td>The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.
+TxStopPoint: Authorized, DataSigned, PowerPathClosed, EnergyTransfer
+This use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are send. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+
+Figure 37. Sequence Diagram: Stop Transaction with a Master Pass
+
+# C16 - Stop Transaction with a Master Pass - Requirements
+
+Table 58. C16 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>C16.FR.01</td><td>User presents an IdToken that has a groupld equal to MasterPassGroupId AND The Charging Station has a UI with input capabilities.</td><td>The Charging Station SHALL "show" the Master Pass UI to let user select which transaction to stop.</td></tr><tr><td>C16.FR.02</td><td>User presents an IdToken that has a groupld equal to MasterPassGroupId AND the Charging Station does NOT have a UI.</td><td>The Charging Station SHALL stop all ongoing transactions as described in use case E07.</td></tr><tr><td>C16.FR.03</td><td>IdTokens that have a groupld equal to MasterPassGroupId</td><td>SHALL NOT be allowed to start a transaction.</td></tr><tr><td>C16.FR.04</td><td>IdTokens that have a groupld equal to MasterPassGroupId present in the Authorization Cache.</td><td>The Charging Station MAY also allow authorization of "Master Pass" tokens based on information in the Authorization Cache.</td></tr><tr><td>C16.FR.05</td><td>IdTokens that have a groupld equal to MasterPassGroupId present in the Local Authorization List.</td><td>The Charging Station MAY also allow authorization of "Master Pass" tokens based on information in the Local Authorization List.</td></tr><tr><td>C16.FR.07</td><td>C16.FR.01</td><td>Charging Station SHALL stop the transaction as described in use case E07.</td></tr><tr><td>C16.FR.08</td><td>C16.FR.02 OR C16.FR.07</td><td>Charging Station SHALL set transactionInfo.stoppedReason = MasterPass in TransactionRequest with eventType = Ended.</td></tr></table>
+
+# 2.8. Authorization with prepaid card
+
+# C17 - Authorization with prepaid card
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization with prepaid card</td></tr><tr><td>2</td><td>ID</td><td>C17</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Charging Station to request the CSMS to authorize an EV Driver to start charging based on a prepaid balance.</td></tr><tr><td>4</td><td>Description</td><td>An EV Driver uses a prepaid card for charging. Charging Station ensures that no more energy is charged, than is covered by the prepaid balance.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>Authorization causes transaction to start, e.g. TxStartPoint = "Authorized", or "PowerPathClosed" and cable is already connected
+1. EV Driver presents an RFID card that is linked to an account with a prepaid balance.
+2. Charging Station sends AuthorizationRequest to CSMS with idToken that is read from the card.
+3. If card is not valid, CSMS responds with AuthorizationResponse with idTokenInfo.status = Invalid.
+a. Charging station does not start a transaction.
+b. Use case ends.
+4. If card is valid, but prepaid balance is not positive, CSMS responds with AuthorizationResponse with idTokenInfo.status = NoCredit and idTokenInfo.cacheExpiryDateTime set to now.
+a. Charging station does not start a transaction.
+b. Use case ends.
+5. If card is valid and prepaid balance is positive, CSMS responds with AuthorizationResponse with idTokenInfo.status = Accepted and idTokenInfo.cacheExpiryDateTime set to now.
+a. Charging station sends a TransactionEventRequest with eventType = Started, with idToken of the prepaid card
+b. CSMS responds with a TransactionEventResponse with transactionLimit.maxCost set to amount of credit left in account.
+c. Behavior according to use case E16 - Transactions with fixed cost, energy or time.</td></tr><tr><td></td><td>Scenario description #2</td><td>Transaction already started when authorizing, e.g. TxStartPoint = "EVConnected" and cable is connected1. EV Driver presents an RFID card that is linked to an account with a prepaid balance.2. Charging Station sends AuthorizationRequest to CSMS with idToken that is read from the card.3. If card is not valid, CSMS responds with AuthorizationResponse with idTokenInfo.status = Invalida. Charging station does not start energy transfer.b. Use case ends.(Transaction will be stopped when EV Driver disconnects the cable).4. CSMS checks prepaid balance of associated account.5. If card is valid, but prepaid balance is not positive, CSMS responds with AuthorizationResponse with idTokenInfo.status = NoCredit and idTokenInfo.cacheExpiryDateTime set to now.a. Charging station does not start energy transfer.b. Use case ends.(Transaction will be stopped when EV Driver disconnects the cable).6. If card is valid and prepaid balance is positive, CSMS responds with AuthorizationResponse with idTokenInfo.status = Accepted and idTokenInfo.cacheExpiryDateTime set to now.a. Charging station sends a TransactionEventRequest with eventType = Updated, with idToken of the prepaid card.b. CSMS responds with a TransactionEventResponse with transactionLimit.maxCost set to amount of credit left in account.c. Behavior according to use case E16 - Transactions with fixed cost, energy or time.</td></tr><tr><td></td><td>Scenario description #3</td><td>Transaction not started by authorizing, e.g. TxStartPoint = "EVConnected" or "PowerPathClosed", and cable is not yet connected1. EV Driver presents an RFID card that is linked to an account with a prepaid balance.2. Charging Station sends AuthorizationRequest to CSMS with idToken that is read from the card.3. If card is not valid, CSMS responds with AuthorizationResponse with idTokenInfo.status = Invalida. Use case ends.4. CSMS checks prepaid balance of associated account.5. If card is valid, but prepaid balance is not positive, CSMS responds with AuthorizationResponse with idTokenInfo.status = NoCredit and idTokenInfo.cacheExpiryDateTime set to now.a. Use case ends.6. If card is valid and prepaid balance is positive, CSMS responds with AuthorizationResponse with idTokenInfo.status = Accepted and idTokenInfo.cacheExpiryDateTime set to now.7. If EV Driver connects cable within timeout (EVConnectionTimeout), thena. Charging station sends a TransactionEventRequest with eventType = Started, with idToken of the prepaid card.b. CSMS responds with a TransactionEventResponse with transactionLimit.maxCost set to amount of credit left in account.c. Behavior according to use case E16 - Transactions with fixed cost, energy or time.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>CSMS supports prepaid cards.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Energy transfer is stopped when amount of prepaid balance is reached.</td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>Prepaid idTokens shall not be cached, because an AuthorizationRequest is needed to get the current balance. CacheExpiryDateTime is set to current time so that idToken does not remain in authorization cache.
+This is a version of use case C01 - EV Driver Authorization using RFID in which CSMS may return an authorization status NoCredit.
+The transaction with a maxCost limit is described in E16 - Transactions with fixed cost, energy, SoC or time.</td></tr></table>
+
+# NOTE
+
+Following diagram only shows parameters related to the use case. More parameters are required in these messages.
+
+
+Figure 38. Sequence diagram prepaid authorization
+
+# C17 - EV Driver Authorization using prepaid card - Requirements
+
+Table 59. C17 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>C17.FR.01</td><td>CSMS receives an AuthorizationRequest for an idToken that is valid and associated with a prepaid account that has a positive balance</td><td>CSMS SHALL respond with an AuthorizationResponse with idTokenInfo with status = Accepted and cacheExpiryDateTime set to current date/time.</td><td>Prepaid token is not allowed to remain in the local authorization cache.</td></tr><tr><td>C17.FR.02</td><td>CSMS receives an AuthorizationRequest for an idToken that is valid and associated with a prepaid account that does not have a positive balance</td><td>CSMS SHALL respond with an AuthorizationResponse with idTokenInfo that has status = NoCredit and cacheExpiryDateTime set to current date/time.</td><td>Prepaid token is not allowed to remain in the local authorization cache.</td></tr><tr><td>C17.FR.03</td><td>CSMS receives an TransactionEventRequest with an idToken that is valid and associated with a prepaid account that has a positive balance</td><td>CSMS SHALL include (only one time) the field transactionLimit.maxCost, set to the maximum amount that may be spent, in the TransactionEventResponse</td><td>See also E16 - Transactions with fixed cost, energy, SoC or time.</td></tr><tr><td>C17.FR.04</td><td>C17.FR.01</td><td>Charging Station SHALL offer energy</td><td>Authorization status of idToken is Accepted. See also C01 - EV Driver Authorization using RFID.</td></tr><tr><td>C17.FR.05</td><td>C17.FR.02</td><td>Charging Station SHALL NOT offer energy</td><td>Authorization status of idToken is NOT Accepted. See also C01 - EV Driver Authorization using RFID.</td></tr></table>
+
+NOTE Other requirements from C. Authorization also apply, notably C01 - EV Driver Authorization using RFID
+
+# 2.9. Ad hoc payments
+
+Ad hoc payment or direct payment refers to payment of a charging session with a debit or credit card. This requires a built-in or stand-alone payment terminal or site from a payment service provider (PSP) that the user can access with a mobile device. The payment terminal is a secure, closed box, that has its own secure connection to a payment service provider (PSP).
+
+# Integrated payment terminals
+
+Most use cases in this chapter are about an integrated payment terminal that is part of the Charging Station and provides authorization for a valid payment card to start a charging session. The payment terminal provides an API to communicate internally with the Charging Station. These are proprietary APIs that are not described in this document. The payment terminal requests authorization of the payment card via its own direct connection to the PSP.
+
+The use cases C18 - Authorization using locally connected payment terminal to C23 - Increasing authorization amount describe ad hoc payment via an integrated payment terminal.
+
+# Stand-alone payment terminals
+
+The payment terminal can also be a separate unit that is serving several Charging Stations. The latter is called a stand-alone payment terminal or payment kiosk in this specification, because it has no direct connection with the Charging Station(s). Once a payment card has been authorized, the stand-alone payment terminal will instruct CSMS to remotely start a charging transaction on a specified Charging Station.
+
+This scenario is described in use case C24 - Ad hoc payment via stand-alone payment terminal. The interface between a stand-alone payment terminal and CSMS is not described in this specification, because it is not related to Charging Station communication.
+
+# Ad hoc via QR code
+
+Charging Station that do not have an integrated or stand-alone payment terminal can still support ad hoc payment via a payment website. A common approach for this is to show a QR code on the Charging Station that provides the URL of the payment website, which the user can access using a mobile device. Once payment details are entered and validated, CSMS remotely starts a charging
+
+session for the user. In order to prevent fraud by pasting fake QR stickers on the Charging Station it is recommended to show a dynamic QR code on the Charging Station display.
+
+This is described in use case C25 - Ad hoc payment via a QR code.
+
+# C18 - Authorization using locally connected payment terminal
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Authorization using locally connected payment terminal</td></tr><tr><td>2</td><td>ID</td><td>C18</td></tr><tr><td>3</td><td>Objective</td><td>To start/authorize a transaction from a payment terminal connected directly to the Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>EV Driver presents a payment card to integrated payment terminal in Charging Station. Payment terminal authorizes payment card with Payment Service Provider. The PspRef from PSP is used as idToken with type = DirectPayment, card details are added in idToken additionInfo fields.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Payment Terminal, PSP, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>PaymentCtrl AuthorizationDirectPayment = false(A default ad hoc tariff exists on Charging Station)1. EV Driver presents payment card to payment terminal.2. Payment terminal requests PSP for authorization of the amount configured in PaymentCtrlAuthorization amount.3. Upon approval PSP returns an approved status and a unique reference for this payment in the PSP platform.a. This unique reference is called "PspRef" in OCPP.4. Payment Terminal sends payment details, such as PspRef, cardBin, cardLast4Digits, etc. to Charging Station controller.a. Prior to this use case the fields that need to be added as additionalInfo elements have been configured by CSMS in the actual value of PaymentCtrl PaymentDetails.b. The fields that Payment Terminal is able to provide have been reported in a device model report by Charging Station in the valuesList of PaymentCtrl PaymentDetails.5. Charging Station authorizes idToken with value <PspRef> and type = DirectPayment.6. When EV Driver plugs-in vehicle, Charging Station starts a transaction and sends a TransactionRequest with eventType = Started and idToken with the payment details in additionInfo element of IdTokenType, and with transactionLimit.maxCost set to the payment card authorization amount, as configured in PaymentCtrlAuthorizationAmount.a. CSMS responds with TransactionEventResponse.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>PaymentCtrl AuthorizationDirectPayment = trueSteps 1 to 4 identical to scenario above5. Charging Station sends AuthorizationRequest with idToken with value <PspRef> and type = DirectPayment and payment details in additionInfo element of IdTokenType.a. CSMS responds with AuthorizationResponse with status = Accepted and optionally a tariff to use (in case a default tariff is not applicable).6. When EV Driver plugs in vehicle, Charging Station starts a transaction and sends a TransactionRequest with eventType = Started and idToken with the payment details in additionInfo element of IdTokenType, and with transactionLimit.maxCost set to the payment card authorization amount, as configured in PaymentCtrlAuthorizationAmount.a. CSMS responds with TransactionEventResponse.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station has a payment terminal which is directly connected to the Charging Station. An ad hoc tariff has been set as the default tariff as described in use case I07 - Local Cost Calculation - Set Default Tariff.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>EV Driver is authorized to charge.</td></tr><tr><td>7</td><td>Error handling</td><td>When the payment service provider does not authorize the payment card, or when the payment terminal fails to communicate, then EV Driver is not authorized by Charging Station. This means that when PaymentCtrlr授权DirectPayment = true Charging Station will not send an AuthorizationRequest.</td></tr><tr><td>8</td><td>Remark(s)</td><td>The communication between PSP and payment terminal, and the API between payment terminal and Charging Station are only described at an abstract level in this use case.PspRef is the reference from PSP that is used within PSP platform and is used to settle the payment. A payment terminal may also have its own transaction or session ID, but for the OCPP use case only the reference that is needed to settle the payment is relevant.This use case assumes a default tariff and support for local cost calculation. It can also work when cost calculation is performed by CSMS, but in that case it will not be possible to stop exactly a the maxCost amount.Option VAT number validation:1. At any point in time before settlement the Charging Station may send aVatNumberValidationRequest to CSMS to verify a VAT number, that was entered by the EV Driver, to be included in the receipt.2. CSMS verifies the VAT number using a local database or online service, and returns aVatNumberValidationResponse with status = Accepted and optional companyname/address, when number is considered valid, or status = Rejected otherwise.</td></tr></table>
+
+
+Figure 39. Sequence diagram of an ad hoc authorization
+
+# C18 - Authorization using locally connected payment terminal - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>C18.FR.01</td><td></td><td>Charging Station SHALL configure payment terminal to reserve the amount specified in configuration variable PaymentCtrl authorizationAmount when authorizing a payment card.</td><td></td></tr><tr><td>C18.FR.02</td><td>When a payment card is presented</td><td>Charging Station SHALL instruct payment terminal to request authorization for this card from PSP.</td><td>Communication protocol between Charging Station and payment terminal and payment terminal and PSP is not part of OCPP.</td></tr><tr><td>C18.FR.03</td><td>When PSP authorizes the payment card AND PaymentCtrl AuthorizationDirectPayment is false</td><td>Charging Station SHALL authorize EV to charge.</td><td></td></tr><tr><td>C18.FR.04</td><td>When PSP authorizes the payment card AND PaymentCtrl+AuthorizeDirectPayment is true</td><td>Charging Station SHALL send an AuthorizationRequest with idToken = <PspRef>, type = DirectPayment, and additionalInfo containing a list of types configured in PaymentCtrl.PaymentDetails and associated values in additionalIdToken.</td><td>Charging Station requests explicit authorization from CSMS. This can be useful if CSMS needs to be able to reject ad hoc payments or provide a non-default tariff plan.</td></tr><tr><td>C18.FR.05</td><td>C18.FR.04 AND CSMS gives authorization by responding with AuthorizationResponse with status = Accepted</td><td>Charging Station SHALL authorize EV to charge.</td><td>Authorization is still denied when status = Accepted, but EVSE is not on list of allowed EVSEs (see C01.FR.21)</td></tr><tr><td>C18.FR.06</td><td>C18.FR.03 OR C18.FR.05</td><td>The next TransactionEventRequest from Charging Station SHALL contain idToken = <PspRef>, type = DirectPayment and additionInfo with a list of types and values in additionIdToken as configured in PaymentCtrl.PaymentDetails, and transactionLimit.maxCost set the to payment card authorization amount, as configured in PaymentCtrl.AuthorizationAmount.</td><td>This is in accordance with E03.FR.01. Other fields then those mentioned here may also be relevant in the TransactionEventRequest message.</td></tr><tr><td>C18.FR.07</td><td>C18.FR.04 AND CSMS denies authorization by responding with AuthorizationResponse with status <> Accepted</td><td>Charging Station SHALL instruct payment terminal to release the authorization amount and cancel the payment.</td><td>Authorization is also denied when status = Accepted, but EVSE is not on list of allowed EVSEs (see C01.FR.21)</td></tr><tr><td>C18.FR.08</td><td></td><td>Charging Station MAY send a VatNumberValidationRequest to CSMS any time before settlement to validate a VAT number entered by EV Driver to be included on receipt.</td><td>VAT number may be required in certain legislations to be entered at time of sales.</td></tr><tr><td>C18.FR.09</td><td>C18.FR.08</td><td>CSMS validates given VAT number and responds with VatNumberValidationResponse with status = Accepted if validated and Rejected when invalid.</td><td>Optionally the company address can be returned in company field.</td></tr><tr><td>C18.FR.10</td><td>If VatNumberValidationRequest received by CSMS contains an evseld</td><td>CSMS SHALL use the same evseld in VatNumberValidationResponse.</td><td>This can make it simpler for Charging Station to associate the data with the correct transaction.</td></tr></table>
+
+# C19 - Cancelation prior to transaction
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Cancelation prior to transaction</td></tr><tr><td>2</td><td>ID</td><td>C19</td></tr><tr><td>3</td><td>Objective</td><td>To inform the CSMS that payment has been canceled and the authorization amount has been released.</td></tr><tr><td>4</td><td>Description</td><td>The EV Driver cancels the payment prior to starting an actual OCPP transaction, or the EVConnectionTimeout occurs.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Payment Terminal, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>PaymentCtrl+r协助DirectPayment = false1. Payment card of EV Driver has been authorized by the payment service provider and an authorization amount has been reserved for the card.2. Charging Station has authorized idToken for charging.3. EV Driver decides to cancel the session before the EV is plugged-in, or EV Driver does not plug in EV and a EVConnectionTimeout occurs.4. Charging Station notifies payment terminal about cancelation.5. Payment terminal requests payment service provider to release the authorization reservation on the card.6. Charging Station ends authorization of idToken.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>PaymentCtrl授权DirectPayment = true1. Payment card of EV Driver has been authorized by the payment service provider and an authorization amount has been reserved on the card.2. Charging Station sends an AuthorizationRequest for idToken = <PspRef>, type = DirectPayment and associated additionalInfo.3. CSMS responds with AuthorizationResponse to authorize idToken for charging.4. EV Driver decides to cancel the session before the EV is plugged-in, or EV Driver does not plug in EV and a EVConnectionTimeout occurs.5. Payment terminal requests payment service provider to release the authorization reservation on the card.6. Charging Station ends authorization of idToken.7. Charging Station sends a NotifySettlementRequest with pspRef = idToken and status = Canceled to notify CSMS that the previously authorized idToken will not start a transaction and payment has been canceled.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The EV Driver has used the payment terminal to authorize. No TransactionEventRequest has yet been sent, because TxStartPoint = "PowerPathClosed" or "EVConnected" and EV is not plugged-in.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The payment transaction has been canceled.</td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>If PaymentCtrl授权DirectPayment is false, then CSMS is not notified of the payment canceling, because it will not be aware of the idToken.See use case C20 for cancelation when a transaction has already been started.</td></tr></table>
+
+
+Figure 40. Sequence diagram of canceling an ad hoc authorization
+
+# C19 - Cancelation prior to transaction - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>C19.FR.01</td><td>When EV Driver stops the session at Charging Station before a transaction has been started OR An EVConnectionTimeout occurs</td><td>Charging Station SHALL instruct payment terminal to release the authorization amount and cancel the payment.</td><td></td></tr><tr><td>C19.FR.02</td><td>C19.FR.01 AND PaymentCtrlr.AuthorizeDirectPayment = true</td><td>Charging Station SHALL send a NotifySettlementRequest with idToken = <pspRef> of the ad hoc payment and status = Canceled and settlementTime set to current time.</td><td>This notifies CSMS that the DirectPayment idToken will not be charged.</td></tr></table>
+
+# C20 - Cancelation after start of transaction
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Cancelation after start of transaction</td></tr><tr><td>2</td><td>ID</td><td>C20</td></tr><tr><td>3</td><td>Objective</td><td>To inform the CSMS that payment has been canceled and the authorization amount has been released.</td></tr><tr><td>4</td><td>Description</td><td>The EV Driver cancels the payment when a transaction has been started, but no energy has been delivered and no other costs have been made (e.g. no reservation fee).</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Payment Terminal, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>TxStartPoint = "PowerPathClosed" and charging does not start
+1. Payment card of EV Driver has been authorized by the payment service provider and an authorization amount has been reserved on the card.
+2. Charging Station has authorized idToken for charging.
+3. EV Driver connects EV.
+4. Charging Station sends a TransactionEventRequest with eventType = Started, triggerReason = CablePluggedIn and idToken information and other relevant fields.
+a. CSMS responds with TransactionEventResponse with idTokenInfo.
+5. Charging does not start, e.g. due to failure in either EV or Charging Station.
+6. EV Driver decides to cancel the session.
+7. Payment terminal requests payment service provider to release the authorization reservation on the card.
+8. Charging Station ends authorization of idToken.
+9. Charging Station sends TransactionEventRequest with eventType = Ended and triggerReason = StopAuthorized and other relevant fields.
+10. CSMS responds with TransactionEventResponse with totalCost = 0.
+11. Charging Station sends a NotifySettlementRequest with pspRef = idToken and status = Canceled to notify CSMS that the previously authorized idToken will not start a transaction and payment has been canceled.</td></tr><tr><td></td><td>Alternative scenario</td><td>TxStartPoint = "Authorized" and not plugged-in</td></tr><tr><td></td><td></td><td>1. Payment card of EV Driver has been authorized by the payment service provider and an authorization amount has been reserved on the card.</td></tr><tr><td></td><td></td><td>2. Charging Station has authorized idToken for charging.</td></tr><tr><td></td><td></td><td>3. Charging Station sends a TransactionRequest with eventType = Started and idToken information and other relevant fields.</td></tr><tr><td></td><td></td><td>a. CSMS responds with TransactionResponse with idTokenInfo.</td></tr><tr><td></td><td></td><td>4. EV Driver does not plug in EV and a EVConnectionTimeout occurs.</td></tr><tr><td></td><td></td><td>5. Payment terminal requests payment service provider to release the authorization reservation on the card.</td></tr><tr><td></td><td></td><td>6. Charging Station ends authorization of idToken.</td></tr><tr><td></td><td></td><td>7. Charging Station sends TransactionRequest with eventType = Ended and triggerReason = EVConnectTimeout and other relevant fields.</td></tr><tr><td></td><td></td><td>8. CSMS responds with TransactionResponse with totalCost = 0.</td></tr><tr><td></td><td></td><td>9. Charging Station sends a NotifySettlementRequest with pspRef = idToken and status = Canceled to notify CSMS that the previously authorized idToken will not start a transaction and payment has been canceled.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The EV Driver has used the payment terminal to authorize. A transaction was started, but no costs have been incurred yet.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The payment transaction has been canceled and transaction has been ended.</td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>See use case C19 for cancelation when a transaction has not yet been started.</td></tr></table>
+
+
+Figure 41. Sequence diagram of canceling an ad hoc authorization after start of transaction
+
+C20 - Cancelation after start of transaction - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>C20.FR.01</td><td>When EV Driver stops the session at Charging Station after a transaction has been started</td><td>Charging Station SHALL send a TransactionRequest with eventType = Ended and triggerReason = StopAuthorized and any other relevant fields.</td><td></td></tr><tr><td>C20.FR.02</td><td>When EV Driver does not connect EV in time after a transaction has been started, and an EVConnectionTimeout occurs</td><td>Charging Station SHALL send a TransactionRequest with eventType = Ended and triggerReason = EVConnectTimeout</td><td></td></tr><tr><td>C20.FR.03</td><td>C20.FR.01 OR C20.FR.02</td><td>CSMS SHALL respond with a TransactionResponse with totalCost = 0</td><td>Prerequisite of this use case is that no costs have been incurred.</td></tr><tr><td>C20.FR.04</td><td>C20.FR.03</td><td>Charging Station SHALL instruct payment terminal to release the authorization amount and cancel the payment.</td><td></td></tr><tr><td>C20.FR.05</td><td>C20.FR.04</td><td>Charging Station SHALL send a NotifySettlementRequest with transactionld of transaction, idToken of the ad hoc payment in pspRef, and status = Canceled and settlementTime set to current time.</td><td>This notifies CSMS that the DirectPayment idToken has not been charged for the transaction.</td></tr></table>
+
+# C21 - Settlement at end of transaction
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Settlement at end of transaction</td></tr><tr><td>2</td><td>ID</td><td>C21</td></tr><tr><td>3</td><td>Objective</td><td>Settle the amount of charging session and generate receipt for the EV Driver.</td></tr><tr><td>4</td><td>Description</td><td>When the transaction ends, the EV Driver is shown the total cost. The amount that is being settled, and the successful settlement status and time are sent to the CSMS and a receipt is provided.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Payment Terminal, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>URL to receipt is provided by CSMS: PaymentCtrlr.ReceiptByCSMS = true, SettlementByCSMS = false
+1. When transaction ends, Charging Station sends a TransactionEventRequest with eventType = Ended and costDetails to CSMS.
+2. Charging Station shows the cost breakdown in costDetails to EV Driver.
+3. Charging Station instructs payment terminal to settle the payment for the amount in costDetails.totalCost.
+4. When payment is settled, Charging Station sends a NotifySettlementRequest with transactionId of the transaction, pspRef with value of idToken, status = Settled, settlementAmount and settlementTime and optionally vatNumber, vatCompany.
+a. CSMS responds with a NotifySettlementResponse with receiptUrl.
+b. Charging Station displays receiptUrl from CSMS to EV Driver.</td></tr><tr><td></td><td>Alternative scenario</td><td>URL to receipt is provided by payment terminal: PaymentCtrl.RceiptByCSMS = false, SettlementByCSMS = false1. When transaction ends, Charging Station sends a TransactionRequest with eventType = Ended and costDetails to CSMS.2. Charging Station shows the cost breakdown in costDetails to EV Driver.3. Charging Station instructs payment terminal to settle the payment for the amount in costDetails.totalCost.4. When payment is settled, payment terminal sends the URL that points to the receipt.5. Charging Station sends a NotifySettlementRequest with transactionId of the transaction, pspRef with value of idToken, status = Settled, settlementAmount and settlementTime' and the receipt information from payment service provider: receiptID, receiptUrl.a. CSMS responds with a NotifySettlementResponse.b. Charging Station displays receiptUrl from payment terminal to EV Driver.</td></tr><tr><td rowspan="2"></td><td rowspan="2">Alternative scenario</td><td>Settlement by CSMS: SettlementByCSMS = true1. When transaction ends, Charging Station sends a TransactionRequest with eventType = Ended and costDetails to CSMS.2. Charging Station shows the cost breakdown in costDetails to EV Driver.3. Configuration variable PaymentCtrl.SettlementByCSMS = true, therefore settlement is performed directly with PSP, bypassing the payment terminal.a. CSMS instructs payment service provider to settle the payment for the amount in costDetails.totalCost.</td></tr><tr><td>In this scenario there is no feedback to EV Driver to provide a receipt. The CSO will need to offer the ability to retrieve a receipt via a website or app.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Transaction was started using ad hoc payment. Charging Station supports local cost calculation.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>CSMS knows of the settled status and the EV Driver has been shown the cost and means to retrieve a receipt.</td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>A receipt URL, e.g. as a QR code, might be shown on the payment terminal display.Showing the receipt URL after settlement is problematic if the TxStopPoint = ParkingBayOccupancy, because the EV Driver has left already at that moment.See chapter I. Tariff and Cost for details about the cost breakdown.</td></tr></table>
+
+
+Figure 42. Sequence diagram of payment settlement by Charging Station
+
+
+Figure 43. Sequence diagram of payment settlement by CSMS
+
+C21 - Settlement at end of transaction - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>C21.FR.01</td><td>When a locally started transaction ends that was authorized by an idToken of type = DirectPayment AND PaymentCtrl.SettlementByCSMS is absent or false</td><td>Charging Station SHALL settle the total cost of the transaction via the payment terminal.</td><td></td></tr><tr><td>C21.FR.02</td><td>When Charging Station receives the settlement status from payment terminal</td><td>Charging Station SHALL send a NotifySettlementRequest to CSMS with status, settlementAmount, settlementTime, transactionId and pspRef.</td><td>Optionally a vatNumber and vatCompany can be added.</td></tr><tr><td>C21.FR.03</td><td>C21.FR.02 AND PaymentCtrl.ReceiptByCSMS = true</td><td>CSMS SHALL respond with NotifySettlementResponse with receiptUrl.</td><td></td></tr><tr><td>C21.FR.04</td><td>C21.FR.02 AND PaymentCtrl.ReceiptByCSMS = false</td><td>Charging Station SHALL add the URL to the receipt in the NotifySettlementRequest in field receiptUrl and the ID of the receipt in receiptId.</td><td></td></tr><tr><td>C21.FR.05</td><td>When a locally started transaction ends that was authorized by an idToken of type = DirectPayment AND PaymentCtrl.SettlementByCSMS is true</td><td>CSMS SHALL settle the total cost of the transaction with the payment service provider.</td><td>The PSP reference to settle the payment session is in idToken.</td></tr><tr><td>C21.FR.06</td><td>C21.FR.05</td><td>Charging Station SHALL NOT settle the total cost of the transaction via the payment terminal.</td><td></td></tr><tr><td>C21.FR.07</td><td>C21.FR.05</td><td>Charging Station MAY display the value of PaymentCtrl.ReceiptServerUrl to the EV Driver as a location where a receipt can be retrieved at a later time.</td><td>This information can, for example, be shown immediately after authorization and/or when stopping the transaction.</td></tr></table>
+
+# C22 - Settlement is rejected or fails
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Settlement is rejected or fails</td></tr><tr><td>2</td><td>ID</td><td>C22</td></tr><tr><td>3</td><td>Objective</td><td>To inform the CSMS that the transaction settlement has been rejected or otherwise failed to be successfully settled.</td></tr><tr><td>4</td><td>Description</td><td>The Charging Station failed to settle the amount. Settlement can be rejected by the payment service provider, or it can fail for technical reasons.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Payment Terminal, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>PSP rejects settlement
+1. Charging Station requests payment terminal to settle payment.
+2. PSP rejects settlement.
+3. Payment terminal returns a rejection and error code.
+4. Charging Station sends a NotifySettlementRequest with transactionId, idToken, settlementAmount, settlementTime and status = Rejected and (optional) additional error information in statusInfo.</td></tr><tr><td></td><td>Alternative scenario</td><td>Settlement fails due to communication problems1. Charging Station requests payment terminal to settle payment.2. Payment terminal attempts to contact PSP, but fails.3. Payment terminal may be configured to autonomously perform a number of retries. (This is not an OCPP-related configuration).4. Payment terminal returns a Failed status5. Charging Station sends a NotifySettlementRequest with transactionId, idToken,settlementAmount, settlementTime and status = Failed and (optional) additional error information in statusInfo.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Transaction was started using ad hoc payment.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>CSMS knows of the rejected/failed settled status.</td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>In case of settlement failure CSO can try to capture the amount by contacting the payment service provider and providing the payment details, such as the PSP reference (which is the value of idToken).</td></tr></table>
+
+
+Figure 44. Sequence diagram of failing settlement of an ad hoc payment
+
+Payment Service Provider
+
+Integrated Payment Terminal
+
+Charging Station
+
+Assuming TxStopPoint is PowerPathClosed
+
+Adhoc transaction for idToken <PspRef> is ended.
+
+TransactionEventRequest(eventType = Ended, transactionId = "AB123", costDetails = ..., ...)
+
+TransactionEventResponse()
+
+Show cost breakdown
+
+settle payment(finalCost)
+
+settlement result(Rejected or Failed)
+
+Show settlement status
+
+settlement result(Rejected or Failed)
+
+NotifySettlementRequest transactionId = "AB123",
+
+pspRef = <idToken>
+
+settlementAmount = <finalCost>.
+
+status = Rejected/Failed, settlementTime = ...)
+
+NotifySettlementResponse()
+
+# C22 - Settlement is rejected or fails - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>C22.FR.01</td><td>When Charging Station receives a settlement status from payment terminal that is Rejected</td><td>Charging Station SHALL send a NotifySettlementRequest to CSMS with status = Rejected, settlementAmount, settlementTime, transactionId and pspRef without receipt information.</td><td>This means the payment service provider has rejected the settlement.</td></tr><tr><td>C22.FR.02</td><td>When Charging Station receives a settlement status from payment terminal that is Failed</td><td>Charging Station SHALL send a NotifySettlementRequest to CSMS with status = Failed, settlementAmount, settlementTime, transactionId and pspRef without receipt information.</td><td>This means that there are technical reasons why the settlement failed, e.g. a failure to communicate.</td></tr></table>
+
+# C23 - Increasing authorization amount
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Increasing authorization amount</td></tr><tr><td>2</td><td>ID</td><td>C23</td></tr><tr><td>3</td><td>Objective</td><td>To increase the authorization amount during the transaction when costs are exceeding the original authorization amount.</td></tr><tr><td>4</td><td>Description</td><td>Costs of the transaction are exceeding the authorization amount that was reserved when the payment session started. If it is supported by the payment terminal, the authorization amount can be increased. Support for incremental authorization by the payment terminal is indicated by PaymentCtrl.IncrementalAuthorizationAmount existing with a value > 0.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Payment Terminal, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. A transaction with an ad hoc payment is active.
+2. Payment terminal initially sets an authorization amount of PaymentCtrl AuthorizationAmount.
+3. When PaymentCtrl.IncrementalAuthorizationAmount > 0 and transaction costs exceed the current authorization amount minus PaymentCtrl.IncrementalAuthorizationThreshold
+a. Charging Station instructs payment terminal to increase authorization with PaymentCtrl.IncrementalAuthorizationAmount.
+b. Charging Station increases the transaction limit in transactionInfo.maxCost with the same amount.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Transaction was started using ad hoc payment and PaymentCtrl.IncrementalAuthorizationAmount exists and has a value > 0</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The authorization amount and transactionInfo.maxCost has been increased.</td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>If the maximum authorization amount is reached and PaymentCtrl.IncrementalAuthorizationAmount = 0 (or absent), then the energy flow will be halted, because transactionInfo.maxCost is reached.
+The authorization amount needs to be increased before it has been depleted in order to avoid interruption of the energy flow. The moment when to increase the amount is determined by PaymentCtrl.IncrementalAuthorizationThreshold.</td></tr></table>
+
+
+Figure 45. Sequence diagram showing incremental authorization
+
+# C23 - Incremental authorization - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>C23.FR.01</td><td>When configuration variable PaymentCtrlr.IncrementalAuthorizationAmount exists and has a value > 0</td><td>Charging Station SHALL request payment terminal to increase the authorization amount when total transaction costs exceed the current authorization amount minus PaymentCtrlr.IncrementalAuthorizationThreshold.</td><td>When PaymentCtrlr.IncrementalAuthorizationThreshold is absent this threshold is defined by the implementation.</td></tr><tr><td>C23.FR.02</td><td>C23.FR.01 AND Increasing the authorization with PaymentCtrlr.IncrementalAuthorizationAmount was successful</td><td>Charging Station SHALL send a TransactionEventRequest with triggerReason = LimitSet and a transactionLimit.maxCost that is increased by PaymentCtrlr.IncrementalAuthorizationAmount.</td><td></td></tr></table>
+
+# C24 - Ad hoc payment via stand-alone payment terminal
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Ad hoc payment via stand-alone payment terminal</td></tr><tr><td>2</td><td>ID</td><td>C24</td></tr><tr><td>3</td><td>Objective</td><td>To facilitate payment with a credit/debit card via a stand-alone payment terminal/kiosk (i.e. not integrated into the charging station).</td></tr><tr><td>4</td><td>Description</td><td>A Charging Station (or a group of Charging Stations) has a central payment terminal/kiosk. An EV Driver uses a credit/debit card to pay for charging. The transaction is authorized by the PSP, the CSMS receives a message from the PSP, and remotely starts the transaction on the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, Payment Kiosk, Payment Service Provider, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>Authorizing payment card
+1. EV Driver presents payment card at payment kiosk/terminal (PK) to initiate a charging session.
+2. PK communicates with the Payment Service Provider (PSP).
+3. Upon approval PSP returns an approved status to PK and a unique reference for this payment in the PSP platform.
+a. This unique reference is called "pspRef" in OCPP.
+4. PK sends charging station/evse and payment details, such as pspRef, cardBin, cardLast4Digits, etc. to CSMS.
+5. CSMS sends a RequestStartTransactionRequest (optionally with evseld) to Charging Station with idToken having value <pspRef> and type = DirectPayment.
+6. Charging Station continues as per use cases F07 "Remote start with fixed cost". (User input may be required at Charging Station to select the EVSE to use.)</td></tr><tr><td></td><td>Scenario description</td><td>Settlement when transaction has finished1. If cost calculated locallya. Charging Station sends a TransactionRequest with eventType = Ended and costDetails to CSMS.b. CSMS responds with TransactionResponse.c. Charging Station shows the cost breakdown in costDetails to EV Driver.2. If cost calculated centrallya. Charging Station sends a TransactionRequest with eventType = Ended to CSMS.b. CSMS responds with TransactionResponse with totalCost and an updatedPersonalMessage.c. Charging Station shows the cost breakdown in updatedPersonalMessage to EV Driver.3. If settlement with PSP via PKa. CSMS sends total cost to PK for settling with PSPb. PSP sends receipt data or a URL to a receipt to PK.c. PK returns receipt data or a URL to the receipt to CSMS.4. If settlement with PSP via CSMAea. CSMS performs settlement directly with PSP based on the <pspRef>.b. PSP returns a receipt data or a URL to a receipt to CSMS.5. CSMS may use SetDisplayMessageRequest to display a URL or QR code to a location where the EV Driver can retrieve a receipt.</td></tr><tr><td>5</td><td>Prerequisites</td><td>PK is able to communicate with CSMS.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>CSMS remotely starts a transaction for EV Driver.</td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>This was use case C03 in OCPP 2.0.1.The communication between CSMS and PK is out of scope of this document.</td></tr></table>
+
+
+C24 - Ad hoc payment via stand-alone payment terminal - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>C24.FR.01</td><td>When CSMS receives a message from Payment Kiosk that payment is authorized with authorization reference<PspRef> for Charging Station with identity<CS> and optionally an EVSE<evse></td><td>CSMS SHALL send a RequestStartTransactionRequest to Charging Station with identity<CS> and EVSE<evse>(when present) and having idToken.idToken = <PspRef> and idToken.type = DirectPayment</td><td>There is need to include additionalInfo elements for payment details, like cardBin, cardLast4Digits, towards Charging Station.
+The protocol between Payment Kiosk and CSMS is not specified in this document.</td></tr><tr><td>C24.FR.02</td><td>C24.FR.01 AND Charging Station sends a TransactionEventRequest with eventType = Started</td><td>CSMS SHALL respond with a TransactionEventResponse with transactionLimit set to the required limit.</td><td>transactionLimit uses maxCost for cost limit, maxEnergy for energy limit, maxTime for time limit or maxSoC for SoC limit.</td></tr><tr><td>C24.FR.03</td><td>C24.FR.02</td><td>Charging Station SHALL include this limit in the field transactionInfo transactionLimit (once) in the next TransactionEventRequest</td><td></td></tr><tr><td>C24.FR.04</td><td></td><td>Charging Station SHALL behave as in use case E16 - Transactions with fixed cost, energy, SoC or time.</td><td></td></tr><tr><td colspan="4">Settlement</td></tr><tr><td>C24.FR.10</td><td>After CSMS received a TransactionEventRequest with eventType = Ended or the transaction</td><td>CSMS SHALL send a message to Payment Kiosk or PSP to settle the cost</td><td>Whether settling is done via Payment Kiosk or directly with PSP is depending on the implementation. Cost may have been calculated locally or centrally.</td></tr><tr><td>C24.FR.11</td><td>When CSMS receives receipt information or a URL to a receipt from Payment Kiosk or PSP</td><td>CSMS MAY send a SetDisplayMessageRequest with a URL where EV Driver can download the receipt.</td><td>Other methods to find and download receipts may also be offered by CSO.</td></tr></table>
+
+# C25 - Ad hoc payment via a QR code
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Ad hoc payment via a QR code</td></tr><tr><td>2</td><td>ID</td><td>C25</td></tr><tr><td>3</td><td>Objective</td><td>To provide a static or dynamic QR code with a URL for ad hoc payment</td></tr><tr><td>4</td><td>Description</td><td>Static QR code: The Charging Station has a static QR code (often a sticker) to scan to start a transaction.
+Dynamic QR code: The Charging Station displays a dynamic QR code with a time-based one-time password that is based on a shared secret between Charging Station and CSMS.
+The EV Driver scans the QR code to access a website where the EV Driver can enter payment credentials for the charging service. In case of a dynamic QR code the CSMS checks that the URL scanned from the QR code is authentic. Upon successful payment authorization CSMS issues a remote start of a transaction on the Charging Station (and optional EVSE) that is encoded in the URL.</td></tr><tr><td></td><td>Actors</td><td>EV Driver, PSP, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description #1</td><td>Scanning a dynamic QR code</td></tr><tr><td></td><td></td><td>1. Charging Station displays a QR code with a time-based one-time password.</td></tr><tr><td></td><td></td><td>a. Optionally, Charging Station requests input from EV Driver to specify a maximum time, energy or cost prior to displaying the QR code</td></tr><tr><td></td><td></td><td>b. The input is added as query parameters to the URL in the QR code.</td></tr><tr><td></td><td></td><td>2. EV Driver scans QR code with URL to access a web page of CSMS to initiate a charging session.</td></tr><tr><td></td><td></td><td>3. CSMS decodes URL according to the configured URL template and validates the time-based one-time password.</td></tr><tr><td></td><td></td><td>a. The URL contains as a minimum the Charging Station identity, one time password and version, and optionally the EVSE number, but other parameters can be configured in the URL template as well.</td></tr><tr><td></td><td></td><td>b. If URL validation or decoding fails no charging session will be started. Use case ends here.</td></tr><tr><td></td><td></td><td>4. CSMS optionally sends a NotifyWebPaymentStartedRequest message with evsId and timeout to notify Charging Station of the event.</td></tr><tr><td></td><td></td><td>a. Charging Station displays feedback to EV Driver and prevents that a transaction is started locally on the EVSE in evsId for as long as timeout seconds, or until the RequestStartTransactionRequest from CSMS is received.</td></tr><tr><td></td><td></td><td>5. CSMS diverts EV Driver to website of PSP (Payment Service Provider).</td></tr><tr><td></td><td></td><td>6. EV Driver enters payment credentials in web page shown by PSP.</td></tr><tr><td></td><td></td><td>7. Upon approval PSP returns an approved status and a unique reference for this payment in the PSP platform.</td></tr><tr><td></td><td></td><td>a. This unique reference is called "pspRef" in OCPP.</td></tr><tr><td></td><td></td><td>b. PSP sends payment details, such as PspRef, cardBin, cardLast4Digits, etc. to CSMS.</td></tr><tr><td></td><td></td><td>8. CSMS sends a RequestStartTransactionRequest to Charging Station and EVSE from the URL and with idToken having value <pspRef> and type = DirectPayment.</td></tr><tr><td></td><td></td><td>9. Use case continues as per use case "F07 Remote start with cost limit" in which CSMS will provide a transactionLimit.maxCost set to the payment card authorization amount, which acts as a ceiling for the cost, independent of a value entered bij EV Driver in step 1.</td></tr><tr><td></td><td>Scenario description #2</td><td>Scanning a static QR code</td></tr><tr><td></td><td></td><td>WARNING A static QR code is susceptible to fraud. A new QR sticker that points to a fake payment site can be pasted over the original QR sticker.</td></tr><tr><td></td><td></td><td>1. Charging Station displays a static QR code (often a sticker).</td></tr><tr><td></td><td></td><td>2. EV Driver scans QR code with URL to access a web page of CSMS to initiate a charging session.</td></tr><tr><td></td><td></td><td>3. CSMS decodes URL.</td></tr><tr><td></td><td></td><td>a. The URL contains the Charging Station identity and optional EVSE number.</td></tr><tr><td></td><td></td><td>b. (The URL format is known by CSMS and does not need to be configured in the Charging Station.)</td></tr><tr><td></td><td></td><td>c. If URL validation or decoding fails no charging session will be started. Use case ends here.</td></tr><tr><td></td><td></td><td>4. The remaining steps 4 to 9 are identical to scenario description #1 above.</td></tr><tr><td></td><td>Scenario description #3</td><td>Settlement when transaction has finished1. If cost calculated locallya. Charging Station sends a TransactionRequest with eventType = Ended and costDetails to CSMS.b. CSMS responds with TransactionResponse.c. Charging Station shows the cost breakdown in costDetails to EV Driver.2. If cost calculated centrallya. Charging Station sends a TransactionRequest with eventType = Ended to CSMS.b. CSMS responds with TransactionResponse with totalCost and an updatedPersonalMessage.c. Charging Station shows the cost breakdown in updatedPersonalMessage to EV Driver.3. CSMS performs settlement directly with PSP based on the <pspRef>.4. PSP returns a receipt data or a URL to a receipt to CSMS.5. CSMS may use SetDisplayMessageRequest to display a URL to the receipt to the EV Driver.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Dynamic QR code: The Charging Station has been configured with dynamic QR code configuration variables in WebPaymentsCtrl, and Charging Station periodically displays a QR code with a new time-based one-time password.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>CSMS remotely starts a transaction for EV Driver.</td></tr><tr><td>7</td><td>Error handling</td><td>If the time-based one-time password verification fails, then CSMS will not start a transaction.</td></tr><tr><td rowspan="2">8</td><td rowspan="2">Remark(s)</td><td>The communication between CSMS and PSP, as well as the manner how a receipt is communicated to the EV Driver, is out of scope of this document.This use case resembles use case C24 "Ad hoc payment via stand-alone payment terminal" with the difference that the credit/debit card terminal is replaced by the web page that the URL in the QR code points to.</td></tr><tr><td>NOTE The mechanism to provide a URL for web payment via a QR code, as described in this use case, also applies to other mechanisms that can provide a URL, such as NFC tags or Bluetooth Beacons.This use case assumes that the CSMS of the CSO handles URL validation and communication with PSP, as is also the case in the other ad hoc payment use cases (directly or indirectly via a payment terminal).It is also possible to involve an EMSP in the use case to handle payment. In that case the URL points to the EMSP system that executes steps 2 to 7 of the use case after which it requests CSMS (via a roaming protocol) to start a session on the charging station.</td></tr></table>
+
+
+Figure 46. Ad hoc payment via QR code
+
+# URL definition for dynamic QR code
+
+The QR code contains the URL to the ad hoc payment web page for the CSMS. This web page can be provided by a third party, like a PSP, but it is responsibility of the CSO. The format of the URL is up to the CSO, as long as certain mandatory URL parameters exist that are needed to support the use case.
+
+The URL is a defined as a template that contains parts ("variables") that are filled in by the Charging Station. These variables are put between curly braces as path parameters in the URL template. For example:
+
+# Example URL without EVSE ID
+
+```javascript
+https://qr.mycmsms.com/{totp}/\{version\}/\{chargingstationid\}/
+```
+
+# Example URL with EVSE
+
+```txt
+https://qr.mycmsms.com/{chargingstationid}/\{evse\}/\{totp\}/\{version\}
+```
+
+The URL template is defined in WebPaymentsCtrlURLTemplate.
+
+# URL pointing to CSMS
+
+In the situation as described in the use case the URL will point to the CSMS. CSMS will use a PSP to handle the payment, but CSMS is responsible for coordination and initiating the transaction. In the URL template the Charging Station will replace the variables:
+
+- chargingstationid with its Charging Station identity,
+- evse with the evse for which the payment is requested.
+- totp with the calculated time-based one-time password,
+- version with the version of the time-based one-time password algorithm,
+
+A URL may contain additional query parameters that are filled in by the Charging Station based upon user input. This would allow an EV driver to specify, for example, a maximum amount of energy to charge. The following variables are defined, and when supported by the Charging Station, are reported in the variable named WebPaymentsCtrlr URLs Parameters.
+
+- maxenergy for maximum energy (in Wh) to be charged
+- maxtime for maximum charging time (in seconds)
+- maxcost for the maximum cost (in currency of charging station)
+
+Example URL for EVSE #1 of CS1000 with maximum energy of 20 kWh
+
+https://qr.mycmsms.com/CS1000/1/aHicux89/v1/?maxenergy=20000
+
+The only purpose of this is to communicate a maximum energy/time/cost request to CSMS before the authorization takes place. Once the transaction is started, this data will be communicated to CSMS as part of the transactionLimit field in the TransactionEventRequest.
+
+# URL pointing to external party
+
+In the case that the URL points to an external party, such as an EMSP, the external party is responsible for coordination and initiating the start of a transaction. The external party will decode the URL.
+
+Instead of a Charging Station identity, this URL will have to contain the roaming EVSE ID for the EVSE of the Charging Station. CSMS has to set the variable RoamingEvseld in WebPaymentsCtrlr to the roaming EVSE ID.
+
+In the URL template the Charging Station will replace the variables:
+
+- roamingevseid with the roaming EVSE id,
+- totp with the calculated time-based one-time password,
+- version with the version of the time-based one-time password algorithm,
+
+Example URL template using a roaming ID of charging station
+
+https://qr.mycsms.com/{roamingevseid}/\{totp}/\{version\}
+
+This requires a WebPaymentsCtrlr at the EVSE tier of the device model, i.e. each EVSE has its own WebPaymentsCtrlr such that CSMS can configure the roaming EVSE ID in WebPaymentCtrlr.RoamingEvseld for each EVSE.
+
+The roaming EVSE ID needs to have been agreed upon by and communicated to the external party. A common standard is the format of eMI3/ISO15118 [ref-ISOIEC15118-2].
+
+# C25 - Ad hoc payment via static or dynamic QR code - Requirements
+
+NOTE For a static QR code any requirements related to a one-time password (TOTP) are not applicable.
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td colspan="4">URL validation for dynamic QR code</td></tr><tr><td>C25.FR.01</td><td>When component WebPaymentsCtrlr exists and has "Enabled" = true</td><td>Charging Station SHALL display a dynamic QR code according to configuration variables in WebPaymentsCtrlr.</td><td>See URL definition for dynamic QR code for description of URL template.</td></tr><tr><td>C25.FR.03</td><td>If Charging Station supports WebPaymentsCtrlurlParameters</td><td>Charging Station SHALL allow input from EV Driver for these parameters (e.g. maximum time, energy or cost) to be added as query parameters to the URL in the QR code.</td><td>This requires that the users inputs values before the QR code is displayed.</td></tr><tr><td>C25.FR.04</td><td>C25.FR.03 AND URL parameter "maxtime" is supported EV Driver specified a maximum time</td><td>CS SHALL append the query variable "maxtime" with the time in seconds to the URL and enforce the maximum transaction duration.</td><td>This also means that CS will add a transactionLimit.maxTime for this value to the TransactionRequest messages. (See E16).</td></tr><tr><td>C25.FR.05</td><td>C25.FR.03 AND URL parameter "maxenergy" is supported EV Driver specified a maximum energy to charge</td><td>CS SHALL append the query variable "maxenergy" with the energy in Wh and enforce the maximum charging energy.</td><td>This also means that CS will add a transactionLimit.maxEnergy for this value to the TransactionRequest messages. (See E16).</td></tr><tr><td>C25.FR.06</td><td>C25.FR.03 AND URL parameter "maxcost" is supported EV Driver specified a maximum cost for charging</td><td>CS SHALL append the query variable "maxcost" to the URL and enforce the maximum charging cost.</td><td>This also means that CS will add a transactionLimit.maxCost for this value to the TransactionRequest messages. (See E16).</td></tr><tr><td>C25.FR.07</td><td>When EV Driver visits the web page of CSMS using the URL in the QR code</td><td>CSMS SHALL validate the time-based one-time password in the URL</td><td>See description in Validation of TOTP.</td></tr><tr><td>C25.FR.08</td><td>If the time-based one-time password in the URL is not valid</td><td>CSMS SHALL NOT forward EV Driver to a web page of PSP to enter payment credentials and SHALL NOT authorize EV Driver to charge</td><td>No payment is authorized and no transaction is started.</td></tr><tr><td>C25.FR.09</td><td>If the time-based one-time password in the URL is valid</td><td>CSMS SHALL decode the URL parameters as defined in URL definition for dynamic QR code.</td><td>URL parameters must at least include an identity of the Charging Station and optionally an EVSE number.</td></tr><tr><td colspan="4">Payment authorization</td></tr><tr><td>C25.FR.20</td><td>If URL successfully decoded</td><td>CSMS SHALL forward EV Driver to a web page of PSP to enter payment credentials</td><td>The protocol between PSP and CSMS is not specified in this document.</td></tr><tr><td>C25.FR.21</td><td>C25.FR.20</td><td>CSMS MAY send a NotifyWebPaymentStartedRequest message with evseld having the EVSE number that was decoded from the URL and timeout the time in seconds that Charging Station may lock the EVSE to prevent locally started transactions.</td><td>After timeout seconds Charging Station should free the EVSE again for local transactions.</td></tr><tr><td>C25.FR.22</td><td>C25.FR.21</td><td>Charging Station SHOULD provide feedback to EV Driver that the QR code was successfully scanned and SHOULD prevent further local interactions with the EVSE referred to in evseld for as long as timeout seconds or until a RequestStartTransactionRequest is received from CSMS.</td><td></td></tr><tr><td>C25.FR.23</td><td>When CSMS receives a message from Payment Kiosk that payment is authorized with authorization reference <PspRef> for Charging Station with identity <CS> and optionally an EVSE <evse></td><td>CSMS SHALL send a RequestStartTransactionRequest to Charging Station with identity <CS> and EVSE <evse> (when present) and having idToken.idToken = <PspRef> and idToken.type = DirectPayment</td><td>There is need to include additionalInfo elements for payment details, like cardBin, cardLast4Digits, towards Charging Station. The protocol between Payment Kiosk and CSMS is not specified in this document.</td></tr><tr><td>C25.FR.24</td><td>C25.FR.23 AND Charging Station sends a TransactionEventRequest with eventType = Started</td><td>CSMS SHALL respond with a TransactionEventResponse with transactionLimit set to the required limit.</td><td>transactionLimit uses maxCost for cost limit, maxEnergy for energy limit, maxTime for time limit or maxSoC for SoC limit.</td></tr><tr><td>C25.FR.25</td><td>C25.FR.24</td><td>Charging Station SHALL include this limit in the field transactionInfo transactionLimit (once) in the next TransactionEventRequest</td><td></td></tr><tr><td>C25.FR.26</td><td></td><td>Charging Station SHALL behave as in use case E16 - Transactions with fixed cost, energy, SoC or time.</td><td></td></tr><tr><td>C25.FR.27</td><td>Upon receiving a NotifyWebPaymentStartedRequest</td><td>Charging Station SHALL respond with a NotifyWebPaymentStartedResponse without any parameters.</td><td></td></tr><tr><td colspan="4">Settlement</td></tr><tr><td>C25.FR.40</td><td>After CSMS received a TransactionEventRequest with eventType = Ended or the transaction</td><td>CSMS SHALL send a message to PSP to settle the cost</td><td>Cost may have been calculated locally or centrally.</td></tr><tr><td>C25.FR.41</td><td>When CSMS receives receipt information or a URL to a receipt from PSP</td><td>CSMS MAY send a SetDisplayMessageRequest with a URL where EV Driver can download the receipt.</td><td>Other methods to find and download receipts may also be offered by CSO.</td></tr><tr><td colspan="4">URL requirements for dynamic QR code</td></tr><tr><td>C25.FR.50</td><td></td><td>The URL template for the dynamic QR code SHALL contain the following placeholder for URL parameters:
+• {chargingstationid} or {roamingevseid}
+• {totp} for the generated TOTP
+• {version} for the TOTPVersion</td><td></td></tr><tr><td>C25.FR.51</td><td>If the WebPaymentsCtrlurlTemplate contains {chargingstationid}</td><td>Charging Station SHALL replace placeholder {chargingstationid} in the URL template by the value of SecurityCtrl.Identity</td><td></td></tr><tr><td>C25.FR.52</td><td>If the WebPaymentsCtrlurlTemplate contains {evse}</td><td>Charging Station SHALL replace placeholder {evse} in the URL template by the number of the EVSE for which the payment request is done</td><td></td></tr><tr><td>C25.FR.53</td><td>If the WebPaymentsCtrlurlTemplate contains {roamingevseid}</td><td>Charging Station SHALL replace placeholder {roamingevseid} in the URL template by the value of WebPaymentsCtrl.RoamingEvseid</td><td></td></tr><tr><td>C25.FR.56</td><td>If Charging Station wishes to communicate a maximum energy amount for the QR code authorization</td><td>Charging Station SHALL add the query parameter "maxenergy=XXX" to the URL, where XXX is the maximum energy (in Wh) to be charged.</td><td></td></tr><tr><td>C25.FR.57</td><td>If Charging Station wishes to communicate a maximum charging time for the QR code authorization</td><td>Charging Station SHALL add the query parameter "maxtime=XXX" to the URL, where XXX is the maximum charging time (in seconds).</td><td></td></tr><tr><td>C25.FR.58</td><td>If Charging Station wishes to communicate a maximum cost for the QR code authorization</td><td>Charging Station SHALL add the query parameter "maxcost=XXX" to the URL, where XXX is the maximum cost (in currency of tariff at charging station).</td><td></td></tr><tr><td>C25.FR.59</td><td></td><td>CSMS SHALL accept the query parameters maxenergy, maxtime and maxcost in a QR code authorization URL.</td><td></td></tr><tr><td>C25.FR.60</td><td></td><td>CSMS MAY ignore a non-supported query parameter in the QR code authorization URL.</td><td>If a maximum limit was provided, Charging Station will apply this to the transaction, regardless whether CSMS has support for it.</td></tr></table>
+
+# Time-based One-Time password algorithm
+
+The algorithm to calculate the time-based one-time password uses the HMAC-SHA256 hash function on the byte representation of the start of the current time interval in seconds. The bytes are mapped to digits and characters. For added security the mapping starts not at the first byte, but at a semi-random offset that is calculated from the last byte of the hash.
+
+The configuration parameters for the time-based one-time password are set in the WebPaymentsCtrl: ValidityTime, SharedSecret and Length.
+
+# TOTP algorithm, version 1
+
+The algorithm is defined in pseudocode as follows:
+
+TOTP v1 algorithm in pseudocode
+
+```asm
+// Input parameters
+set validityTime to <parameter ValidityTime>
+set totpLength to <parameter Length>
+set sharedSecret to <parameter SharedSecret>
+set base62 to "0123456789abcdefghijklmnpqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
+// Get time interval
+calculate timeSeconds as current UTC time - Unix Epoch (01-01-1970)
+calculate timeInterval as floor of timeSeconds / validityTime
+convert timeInterval to bytes and store in timeBytes
+if system's byte order is Little Endian then reverse byte order of timeBytes
+// Calculate hash
+create new HMAC-SHA256 hash function with sharedSecret as the key (converted to bytes using UTF-8 encoding)
+calculate hash of timeBytes using HMAC-SHA256 and store in hash variable
+// Convert hash bytes to characters starting at random offset
+calculate offset as (last byte of hash) bitwise AND 0x0F
+create a new empty string builder
+for i from 0 to totpLength do find the character at position (hash value at index (offset + i) modulo length of hash) modulo length of base62 in the base62 string append this character to the string builder
+end for
+return string builder as string
+```
+
+The following is a C# version of this algorithm:
+
+TOTP v1 algorithm in C#
+
+```javascript
+// Input parameters
+var validityTime = TimeSpan.FromSeconds(ValidityTime) // parameter from URL
+var totpLength = Length // parameter from URL
+var sharedSecret = SharedSecret // parameter from URL
+```
+
+```javascript
+var base62 = "0123456789abcdefghijklmnpqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"; // Get time interval
+var timeSeconds = DateTime.UtcNow - new DateTime(1970, 1, 1);
+var timeInterval = (UInt64) (timeSeconds.TotalSeconds / validityTime.TotalSeconds);
+var timeBytes = BitConverter.GetBytes(timeInterval);
+if (BitConverter.IsLittleEndian)
+Array Reverse(timeBytes);
+using (var hmac = new HMACSHA256(ENCoding.UTF8.GetBytes(sharedSecret))) {
+// Calculate hash
+var hash = hmac.ComputeHash(timeBytes);
+// Convert hash bytes to characters starting at random offset
+var offset = hash[^1] & 0x0F;
+var stringBuilder = new StringBuilder();
+for (var i = 0; i < totpLength; i++)
+stringBuilder.Add(base62[hash[(offset + i) % hash.Length] % base62.Length]);
+return stringBuilder.ToString();
+```
+
+# Validation of TOTP
+
+CSMS validates the time-based one-time password (TOTP) in the URL against the TOTP that CSMS calculates for the current time.
+
+The TOTP in the URL (URL-TOTP) is considered valid if it equals the TOTP calculated by CSMS (CSMS-TOTP). If the TOTPs are not equal CSMS shall try to compare the URL-TOTP against a CSMS-TOTP for the previous time interval and the next time interval. This overcomes failed validation as a result processing delays or small differences in clock time.
+
+If URL-TOTP and CSMS-TOTP still do not match in any of these cases, then CSMS shall consider the URL as invalid.
+
+# D. Local Authorization List Management
+
+# Chapter 1. Introduction
+
+As explained in C1.4 - Local Authorization List, the Local Authorization List is a list of identifiers that can be synchronized with the CSMS. It allows authorization of a user when offline and when online it can be used to reduce authorization response time. This Functional Block is for enabling the CSMS to synchronize the list by either sending a complete list of identifiers to replace the Local Authorization List or by sending a list of changes (add, update, delete) to apply to the Local Authorization List. The operations to support this are GetLocalListVersion and SendLocalList.
+
+The 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.
+
+# Chapter 2. Use cases & Requirements
+
+# D01 - Send Local Authorization List
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Send Local Authorization List</td></tr><tr><td>2</td><td>ID</td><td>D01</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to send a Local Authorization List which a Charging Station can use for the authorization of idTokens.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS sends a Local Authorization List which a Charging Station can use for the authorization of idTokens. The list MAY be either a full list to replace the current list in the Charging Station or it MAY be a differential list with updates to be applied to the current list in the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a SendLocalListRequest to install or update the Local Authorization List.
+2. Upon receipt of the SendLocalListRequest the Charging Station responds with a SendLocalListResponse with its status.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Local Authorization List is enabled with Configuration Variable LocalAuthListEnabled.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+- A new Local Authorization List is installed on the Charging Station.
+Failure postcondition:
+- The Local Authorization List on the Charging Station stays as it was.
+- If the status is Failed or VersionMismatch.</td></tr><tr><td>7</td><td>Error handling</td><td>If the status is Failed or VersionMismatch and the updateType was Differential, the CSMS will transmit the full Local Authorization List. When this list is too large for one message, it will start by sending an initial list with updateType Full and adding identifiers using updateType Differential until the list is completely sent (the amount of identifiers that can be sent in a single SendLocalListRequest is limited as described in requirement D01.FR.11).</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 47. Sequence Diagram: Send Local Authorization List
+
+# D01 - Send Local Authorization List - Requirements
+
+Table 60. D01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>D01.FR.01</td><td></td><td>SendLocalListRequest SHALL contain the type of update (updateType) and a version number (versionNumber) that the Charging Station MUST associate with the Local Authorization List after it has been updated.</td><td></td></tr><tr><td>D01.FR.02</td><td></td><td>SendLocalListResponse SHALL indicate whether the Charging Station has accepted the update of the Local Authorization List</td><td></td></tr><tr><td>D01.FR.03</td><td>If the status in SendLocalListResponse is Failed or VersionMismatch and the updateType was Differential</td><td>It is RECOMMENDED that the CSMS sends the full Local Authorization List.</td><td>When this list is too large for one message (see D01.FR.11), it shall start by sending an initial list with updateType Full and adding identifiers using updateType Differential until the list is completely sent.</td></tr><tr><td>D01.FR.04</td><td>If no localAuthorizationList is given and the updateType is Full.</td><td>The Charging Station SHALL remove all IdTokens from the list.</td><td>Note, that the version number of the list is still updated to value of versionNumber in the request.</td></tr><tr><td>D01.FR.05</td><td></td><td>Requesting a Differential update without or with empty localAuthorizationList SHALL have no effect on the list.</td><td>Note, that the version number of the list is still updated to value of versionNumber in the request.</td></tr><tr><td>D01.FR.06</td><td></td><td>All IdTokens in the Local Authorization List SHALL be unique.</td><td>No duplicate values are allowed.</td></tr><tr><td>D01.FR.09</td><td></td><td>The Charging Station SHALL NOT modify the contents of the Authorization List by any other means than upon a the receipt of a SendLocalList message from the CSMS.</td><td></td></tr><tr><td>D01.FR.10</td><td></td><td>The Local Authorization List SHOULD be maintained by the Charging Station in non-volatile memory, and SHOULD be persisted across reboots and power outages.</td><td></td></tr><tr><td>D01.FR.11</td><td></td><td>The size of a single SendLocalListRequest is limited by the Configuration Variables ItemsPerMessageSendLocalList and BytesPerMessageSendLocalList.</td><td></td></tr><tr><td>D01.FR.12</td><td></td><td>A Charging Station that supports Local Authorization List SHALL implement the Configuration Variable: LocalAuthListEntries.</td><td>This gives the CSMS a way to know the current amount and maximum possible number of Local Authorization List elements in a Charging Station.</td></tr><tr><td>D01.FR.13</td><td></td><td>The Charging Station indicates whether the Local Authorization List is enabled. This is reported and controlled by the LocalAuthListEnabled Configuration Variable.</td><td></td></tr><tr><td>D01.FR.15</td><td>If the Charging Station receives a SendLocalListRequest with updateType is Full AND localAuthorizationList is non-empty</td><td>The Charging Station SHALL replace its current Local Authorization List with the one in the SendLocalListRequest and set the version number to the value specified in the message</td><td>Otherwise, there is no way to sync the initial Charging Station and CSMS lists. When this list is too large for one message (see D01.FR.11), it shall start by sending an initial list with_updateType_Full and adding identifiers using updateType Differential until the list is completely sent.</td></tr><tr><td>D01.FR.16</td><td>If the Charging Station receives a SendLocalListRequest with updateType is Differential AND localAuthorizationList contains AuthorizationData elements with idTokenInfo</td><td>The Charging Station SHALL update its Local Authorization List with these elements and set the version number to the value specified in the message.</td><td>Add them if not yet present, update with new information when already present in the Local Authorization List.</td></tr><tr><td>D01.FR.17</td><td>If the Charging Station receives a SendLocalListRequest with upgradeType is Differential AND localAuthorizationList contains AuthorizationData elements without idTokenInfo</td><td>The Charging Station SHALL remove these elements from its Local Authorization List and set the version number to the value specified in the message.</td><td></td></tr><tr><td>D01.FR.18</td><td></td><td>versionNumber in a SendLocalListRequest SHALL be greater than 0.</td><td>In GetLocalListVersionResponse the versionNumber = 0 has a special meaning: No Local List installed. So the value 0 should never be used.</td></tr><tr><td>D01.FR.19</td><td>If the Charging Station receives a SendLocalListRequest with upgradeType = Differential AND versionNumber is less or equal to the version number of its Local Authorization List</td><td>The Charging Station SHALL refuse to update its Local Authorization List and SHALL return a SendLocalListResponse with status set to VersionMismatch.</td><td></td></tr></table>
+
+D02 - Get Local List Version
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Local List Version</td></tr><tr><td>2</td><td>ID</td><td>D02</td></tr><tr><td></td><td>Parent use case</td><td>D01 - Send Local Authorization List</td></tr><tr><td>3</td><td>Objective(s)</td><td>To support synchronization of Local Authorization List.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS can request a Charging Station for the version number of the Local Authorization List by sending a GetLocalListVersionRequest.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a GetLocalListVersionRequest to request this value.
+2. Upon receipt of the GetLocalListVersionRequest Charging Station responds with a GetLocalListVersionResponse containing the version number of its Local Authorization List.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td></td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS received the GetLocalListVersionResponse with the Local Authorization List version.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>A versionNumber of 0 (zero) is reserved to indicate that no local authorization list exists, either because it is not enabled or because it has not yet received any update from CSMS and thus does not have a version number to return.
+In contrast, a local authorization list that was emptied, because CSMS sent a SendLocalListRequest with an empty localAuthorizationList, does have a versionNumber > 0.</td></tr></table>
+
+
+Figure 48. Sequence Diagram: Get Local List Version
+
+# D02 - Get Local List Version - Requirements
+
+Table 61. D02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>D02.FR.01</td><td>LocalAuthListEnabled is true</td><td>When Charging Station receives GetLocalListVersionRequest then Charging Station SHALL respond with a GetLocalListVersionResponse containing the version number of its Local Authorization List.</td></tr><tr><td>D02.FR.02</td><td>LocalAuthListEnabled is true AND the CSMS has not yet sent any update to the Charging Station for Local Authorization List (via SendLocalListRequest)</td><td>When Charging Station receives GetLocalListVersionRequest then Charging Station SHALL respond with a GetLocalListVersionResponse with versionNumber is 0 (zero) to indicate that there is no Local Authorization List.</td></tr><tr><td>D02.FR.03</td><td>LocalAuthListEnabled is not true</td><td>When Charging Station receives GetLocalListVersionRequest then Charging Station SHALL respond with a GetLocalListVersionResponse with versionNumber is 0 (zero) to indicate that there is no Local Authorization List.</td></tr></table>
+
+# E. Transactions
+
+# Chapter 1. Introduction
+
+This Functional Block describes the OCPP Transaction related functionalities. Transactions are started/stopped on the Charging Station. Note that at most one transaction can be active on an EVSE at any point in time.
+
+# 1.1. Flexible transaction start/stop
+
+To support as many business cases as possible, and to prevent sending too many messages when not needed for certain business cases, OCPP 2.1 supports flexible configuration of the start and stop of a transaction.
+
+For this the following Configuration Variables are defined:
+
+-TxStartPoint
+
+- TxStopPoint
+
+These 2 Configuration Variables make it possible to define when a transaction should start: TransactionRequest (eventType = Started) and when a transaction should stop: TransactionRequest (eventType = Ended)
+
+For the flexible start/stop points of a transaction it is important to provide a definition of a transaction.
+
+A transaction is the portion of a charging session that is recorded by CSMS. It is a single time frame with a start and stop time. This information can be used by the operator for billing.
+
+It is up to the Charging Station Operator to define the values for TxStartPoint and TxStopPoint (unless these are preset as read-only values in the charging station), but not all combinations make sense.
+
+The following three variants are most common:
+
+- If connection time is billed, then start and stop points should be EVConnected.
+- If time of use is billed, then the start points should be EVConnected, Authorized and the stop point EVConnected. (Such that upon authorization first, the charger is already seen as 'in use').
+- If charging time is billed, then start and stop points should be PowerPathClosed. (This starts as soon as charger is ready to provide power and stops when authorization is revoked or vehicle disconnected.) Pauses in between (i.e. SuspendedEV(SE)) do not end the transaction. Billing on the amount of energy or power can be done based on the meter values that are collected during the transaction.
+
+# WARNING
+
+Certain combinations of start and stop points can lead to a situation where a started transaction is never stopped. For example: when the start point is ParkingBayOccupancy and the stop point is EVConnected, then a transaction starts when an EV occupies the parking bay, but when the user never connects the EV, but simply drives away, then the transaction will remain open, because ParkingBayOccupancy is not configured as a stop point.
+
+# 1.1.1. Readonly or Read/Write
+
+OCPP 2.1 supports 2 options for the transaction start/stop Configuration Variables. They can either be: RW (read-write) or R (read-only).
+
+When a Charging Station supports RW, the CSO can configure the settings. To support all possible settings, the software in the Charging Station has to be more flexible.
+
+With only R, the settings are fixed in firmware, the CSO can read the settings to learn how a Charging Station will behave, but cannot configure it. This makes for a simpler implementation. When the needs of the target market are well known there might be no need to implement the flexible model.
+
+# 1.1.2. OCPP 1.6 Transaction compatibility
+
+If transactions similar to OCPP 1.6 are wanted, this section describes how the transaction start and stop point should be configured.
+
+In OCPP 1.x the moment a Charging Station should send StartTransaction.req was not defined very precise, generally this was done
+
+when the Charging Station was ready to deliver energy: cable is connected and user is authorized.
+
+To support similar transaction start behaviour, the value: PowerPathClosed is to be used.
+
+Table 62. The settings for an OCPP 1.6 compatible transaction
+
+<table><tr><td>Configuration Variable</td><td>Values</td></tr><tr><td>TxStartPoint</td><td>PowerPathClosed</td></tr><tr><td>TxStopPoint</td><td>EVConnected, Authorized</td></tr></table>
+
+# 1.2. TransactionId generation
+
+New in OCPP 2.x generation: Transaction IDs are now generated by the Charging Station.
+
+In OCPP 1.x this was done by the CSMS. This had some drawbacks. When a Charging Station was offline it had a transaction which did not have a transactionId.
+
+The TransactionId generated by a Charging Station has to be unique for this Charging Station. During the lifetime of a Charging Station it should never use the same TransactionId twice. Also when the Charging Station is rebooted, power cycled, firmware updated, repaired etc.
+
+OCPP does not specify an algorithm to use, but it is RECOMMENDED to use UUIDs.
+
+# 1.3. Delivering transaction-related messages
+
+The primary purpose of TransactionEventRequest messages is to give the CSMS the information that it will later use to bill the transaction. To be sure that the CSMS receives all the necessary information for billing a transaction, OCPP uses two mechanisms: retrying and sequence numbers.
+
+# 1.3.1. Retrying
+
+The Charging Station sends TransactionEventRequest messages to the CSMS System as soon as possible after the events they report on have occurred.
+
+If the Charging Station is offline, or if an error occurs processing the message in transport, the CSMS will be missing billing information. In order to repair the missing information in the CSMS, the Charging Station should retry to deliver this information. When the Charging Station fails to receive a TransactionEventResponse for a TransactionRequest message within the message timeout period, the Charging Station should follow the retry procedure described in use case E13 - Transaction-related message not accepted by CSMS.
+
+# 1.3.2. Sequence numbers
+
+When delivery of TransactionEventRequest messages fails and will be retracted later, the result is that TransactionEventRequest messages may arrive in the CSMS in a different order from the one in which the transaction events occurred at the Charging Station. This in turn would make it difficult for the CSMS to know if it received all TransactionEventRequest messages about a transaction, which the CSMS may want to know before it starts billing the transaction.
+
+In order to make it possible to know that all TransactionEventRequest messages about a transaction were received, OCPP uses sequence numbers in TransactionEventRequest messages. For every EVSE, the Charging Station maintains a counter of the number of TransactionEventRequest messages generated about that EVSE. When generating a new TransactionEventRequest message, the Charging Station includes the current value of the EVSE's counter in the seqNo field of the request, and then increments the counter. With this mechanism, a CSMS can check if it has full information about a transaction by checking that:
+
+- It received a TransactionEventRequest about the start of the transaction, with a seqNo a
+- It received a TransactionEventRequest about the stop of the transaction, with a seqNo o greater than a.
+- It received a TransactionEventRequest about the transaction with seqNo $n$ for every integer $n$ between $a$ and $o$
+
+# 1.3.2.1. Sequence number generation
+
+This section is normative.
+
+When a transaction starts, the Charging Station SHOULD set the seqNo field for the TransactionRequest message to 0.
+
+(Implementations with a continuously increasing seqNo are still allowed.)
+
+After each TransactionEventRequest Charging Station SHALL increase the seqNo by 1.
+
+# 1.4. Authorization
+
+To simplify the use cases in this functional block, the way an EV Driver is authorized is not part of these use cases. It will simply be called something like: "User authorization successful" or "The EV Driver is authorized by the Charging Station and/or CSMS." This may be any way of authorizing an EV Driver. See functional block: C Authorization for all the options and requirements for authorization.
+
+# 1.5. Clarification for optional fields in TransactionRequest
+
+This section is informative.
+
+The TransactionEventRequest contains several optional fields. Some of these fields should only be sent once and should not be repeated in every TransactionEventRequest. The following summary points to the requirements related to these optional fields.
+
+# evse
+
+(E01.FR.16) The field evse is only provided in the first TransactionEventRequest that occurs after the EV has connected. It is not repeated in all future TransactionEventRequests.
+
+# idToken
+
+(E03.FR.01) The field idToken is provided once in the first TransactionEventRequest that occurs after the transaction has been authorized.
+(E07.FR.02) The field idToken is provided once in the TransactionEventRequest that occurs when the authorization of the transaction has been ended.
+(C12.FR.02) The above is also the case when authorization was granted because the idToken is present in the authorization cache with a Accepted status.
+(F02.FR.05): The above is also the case when the idToken is provided by a RequestStartTransactionRequest.
+
+# reservationId
+
+(E03.FR.03/H01.FR.15) The field reservationId is only provided in the first TransactionEventRequest that occurs when the transaction has been authorized by the idToken for which a reservation existed in the charging station.
+(F02.FR.06) The above is also the case when the idToken is provided by a RequestStartTransactionRequest.
+
+# meterValue
+
+(E02.FR.09) The TransactionEventRequest(eventType=Started) must contain the meter values that have been configured in SampledDataCtrl.TxStartedMeasurands.
+(E02.FR.10) A TransactionEventRequest(eventType=Updated) must be sent at every interval configured in SampledDataCtrlTxUpdatedInterval and contain the meter values that have been configured in
+
+SampledDataCtrlr.TxUpdatedMeasurands. If TxUpdatedInterval == 0, then no meter values are sent.
+
+(E06.FR.11) The TransactionEventRequest(eventType=Ended) must contain the meter values that have been configured in SampledDataCtrl.TxEndedMeasurands. If SampledDataCtrl.TxEndedInterval == 0, then only the values taken at start and end of the transaction are included.
+
+# transactionInfo.chargingState
+
+(E02.FR.13) Whenever the charging state changes, the Charging Station must send a TransactionRequest containing chargingState. This implies that a TransactionRequest(eventType = Started) always has a chargingState, because 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.
+
+# transactionInfo.stoppedReason
+
+(B12.FR.04, B12.FR.08) stoppedReason ImmediateReset is sent when transaction ended as result of a reset.
+(C15.FR.04, C16.FR.08) stoppedReason DeAuthorized or MasterPass
+(E03.FR.05, E05.FR.10, E06.FR.08/09, E07.FR.04/05/06, E15.FR.04, E17.FR.21/22, E18.FR.25) The stoppedReason must be provided in the TransactionEventRequest(eventType=Ended), unless the value is Local, in which case it may be omitted.
+(F02.FR.07, F03.FR.03, F04.FR.03) The above also applies to transactions that are stopped by a
+
+RequestStopTransactionRequest, however in this case the stoppedReason value must be Remote.
+
+(K18.FR.23, K19.FR.16, Q01.FR.05) stoppedReason ReqEnergyTransferRejected is sent when transaction is ended, because requested energy transfer type is not granted.
+
+# transactionInforemoteStartId
+
+(C05.FR.03, F01.FR.25, F02.FR.01) The remoteStartId must be sent in the next TransactionEventRequest after the RequestStartTransactionRequest with the same remoteStartId.
+
+# transactionInfo operationMode
+
+(K01.FR.110) Whenever the operation mode changes, the Charging Station must send a TransactionEventRequest containing an transactionInfo element with operationMode. A TransactionEventRequest with triggerReason = OperationModeChanged must contain operationMode.
+
+# transactionInfo transactionLimits
+
+(E16.FR.02, E16.FR.03, E16.FR.10, C17.FR.03, C18.FR.06) When CSMS or Charging Station provide a limit in time, energy, SoC or cost, then this must be included once in the transactionInfo element.
+
+# transactionInfo.tariffld
+
+(I08.FR.13) When a tariff applies to the transaction, then the id of the tariff in use, is added to the transactionInfo element.
+
+# costDetails
+
+(112.FR.01, 112.FR.02) When Charging Station has calculated transaction cost locally, it must provide the field costDetails in TransactionEventRequests.
+
+# Chapter 2. Use cases & Requirements
+
+# 2.1. OCPP transaction mechanism
+
+# E01 - Start Transaction options
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Start Transaction options</td></tr><tr><td>2</td><td>ID</td><td>E01</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS that a transaction at the Charging Station has started.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes the different moments a Charging Station can start a transaction (send TransactionRequest with eventType = Started), depending on the configuration of the Charging Station.</td></tr><tr><td>5</td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td>S1</td><td>Scenario objective</td><td>To start a transaction when a parking bay occupancy detector detects an "EV".</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver parks his "EV" at a Charging Station with a parking bay occupancy detector, which triggers the detector.
+2. The Charging Station sends a TransactionRequest (eventType = Started) notifying the CSMS about a transaction that has started (even when the driver is not yet known.
+3. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>No transaction is ongoing on the EVSE.
+Configuration Variable: TxStartPoint contains: ParkingBayOccupancy</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing, or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 49. Sequence Diagram: Start Transaction options - ParkingBayOccupancy
+
+<table><tr><td>S2</td><td>Scenario objective</td><td>To start a transaction when communication is set up between the Charging Station and an EV (for example: cable plugged in correctly on both sides)</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sets up a connection with the EV.
+2. The Charging Station sends a TransactionRequest (eventType = Started) notifying the CSMS about a transaction that has started (even when the driver is not yet known).
+3. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>No transaction is ongoing on the EVSE.
+Configuration Variable: TxStartPoint: EVConnected</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing, or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 50. Sequence Diagram: Start Transaction options - EVConnected
+
+<table><tr><td>S3</td><td>Scenario objective</td><td>To start a transaction when the EV Driver is authorised to charge.</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver provides his identification
+2. The Charging Station validates the provided identification (for example via the Authorization Cache or an InvalidateRequest).
+3. The Charging Station sends a TransactionEventRequest (eventType = Started) notifying the CSMS about a transaction that has started.
+4. The CSMS responds with a TransactionResponse, confirming that the TransactionEventRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>No transaction is ongoing on the EVSE.
+Configuration Variable: TxStartPoint: Authorized.</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing, or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 51. Sequence Diagram: Start Transaction options - Authorized
+
+<table><tr><td>S4</td><td>Scenario objective</td><td>To start a transaction when the meter has provided the first signed meter values before starting with charging.</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver plugs in the cable at the Charging Station and the EV.
+2. The Charging Station request the Meter for a signed value.
+3. The Meter provides a signed value (this might take some time).
+4. The Charging Station sends a TransactionRequest (eventType = Started) notifying the CSMS about a transaction that has started.
+5. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>No transaction is ongoing on the EVSE.
+Configuration Variable: TxStartPoint: DataSigned.
+The Charging Station has a meter that can sign measured values
+Configuration Variable: SampledDataSignReadings set to true.</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing, or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 52. Sequence Diagram: Start Transaction options - DataSigned
+
+<table><tr><td>S5</td><td>Scenario objective</td><td>To start a transaction when all preconditions have been met to start charging (authorized and connected), but energy does not yet have to be transferred.</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver is authorized by the Charging Station and/or CSMS.
+2. The Charging Station is connected to the EV.
+3. The Charging Station sends a TransactionRequest (eventType = Started) notifying the CSMS about a transaction that has started.
+4. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>No transaction is ongoing on the EVSE.
+Configuration Variable: TxStartPoint: PowerPathClosed.
+Charging Cable plugged in.</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing, or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 53. Sequence Diagram: Start Transaction options - PowerPathClosed
+
+<table><tr><td>S6</td><td>Scenario objective</td><td>To start a transaction when the energy flow starts.</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver is authorized by the Charging Station and/or CSMS.
+2. The Charging Station closes the power relay.
+3. The EV starts charging, energy flow starts.
+4. The Charging Station sends a TransactionRequest (eventType = Started) notifying the CSMS about a transaction that has started.
+5. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>Configuration Variable: TxStartPoint: EnergyTransfer.</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing, or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 54. Sequence Diagram: Start Transaction options - EnergyTransfer
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# E01 - Start Transaction options - Requirements
+
+Table 63. E01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E01.FR.01</td><td>TxStartPoint contains: ParkingBayOccupancy AND Parking Bay Detector detects an "EV" AND No transaction has started yet</td><td>The Charging Station SHALL start a transaction and send a TransactionRequest (eventType = Started) to the CSMS.</td></tr><tr><td>E01.FR.02</td><td>TxStartPoint contains: EVConnected AND The Charging Station has a connection with the EV AND No transaction has started yet on this EVSE</td><td>The Charging Station SHALL start a transaction and send a TransactionRequest (eventType = Started) to the CSMS.</td></tr><tr><td>E01.FR.03</td><td>TxStartPoint contains: Authorized AND The EV Driver is authorized AND No transaction has started yet</td><td>The Charging Station SHALL start a transaction and send a TransactionRequest (eventType = Started) to the CSMS.</td></tr><tr><td>E01.FR.04</td><td>TxStartPoint contains: DataSigned AND The Charging Station has a meter that can sign measured values AND Configuration Variable: SampledDataSignReadings set to true. AND The Charging Station has retrieved a signed meter value AND No transaction has started yet</td><td>The Charging Station SHALL start a transaction and send a TransactionRequest (eventType = Started) to the CSMS.</td></tr><tr><td>E01.FR.05</td><td>TxStartPoint contains: PowerPathClosed AND The EV Driver is authorized AND The Charging Station has connection with the EV AND No transaction has started yet on this EVSE</td><td>The Charging Station SHALL start a transaction and send a TransactionRequest (eventType = Started) to the CSMS.</td></tr><tr><td>E01.FR.06</td><td>TxStartPoint contains: EnergyTransfer AND Energy flow starts AND No transaction has started yet on this EVSE</td><td>The Charging Station SHALL start a transaction and send a TransactionRequest (eventType = Started) to the CSMS.</td></tr><tr><td>E01.FR.07</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td></tr><tr><td>E01.FR.08</td><td></td><td>The transactionId generated by the Charging Station MUST be unique for each transaction started by that Charging Station, even when the Charging Station is rebooted, repaired, firmware is updated etc, it SHALL ensure that it never generates the same TransactionId twice.</td></tr><tr><td>E01.FR.09</td><td>When configured to send meter data in the TransactionRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is known at start of transaction</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td></tr><tr><td>E01.FR.10</td><td>After the EV Driver is authorized for this transaction</td><td>The Charging Station SHALL send a TransactionRequest that contains IdTokenType information.</td></tr><tr><td>E01.FR.11</td><td>E01.FR.10</td><td>The CSMS SHALL verify the validity of the identifier in TransactionRequest.</td></tr><tr><td>E01.FR.12</td><td>E01.FR.11</td><td>The CSMS SHALL send a TransactionResponse that includes in idTokenInfo an authorization status value and the groupIdToken if one exists for the idToken.</td></tr><tr><td>E01.FR.13</td><td>This transaction ends a reservation</td><td>The next TransactionRequest SHALL contain the reservationId.</td></tr><tr><td>E01.FR.14</td><td>After TransactionRequest(eventType = Started) has been sent for a specific EVSE and Connector</td><td>The Charging Station SHALL NOT start another transaction on a different Connector of the same EVSE until this transaction has ended.</td></tr><tr><td>E01.FR.15</td><td>When sending a TransactionRequest</td><td>The Charging Station SHALL set the triggerReason to inform the CSMS about what triggered the event. What reason to use is described in the description of TriggerReasonEnumType.</td></tr><tr><td>E01.FR.16</td><td>After the EV is connected with the Charging Station.</td><td>The next TransactionRequest SHALL contain evse.id AND evseconnectorId.</td></tr></table>
+
+E02 - Start Transaction - Cable Plugin First
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E01.FR.17</td><td>When configured to send meter data in the TransactionEventRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is not known at start of transaction</td><td>The Charging Station SHALL add the measurands for eventType = Started to the optional meterValue field with context = Transaction.Begin in the TransactionEventRequest(eventType = Updated) that occurs when charging starts.</td></tr><tr><td>E01.FR.18</td><td>If the charging state changes</td><td>The Charging Station SHALL send a TransactionEventRequest including the chargingState element.</td></tr><tr><td>E01.FR.19</td><td>When EV temporarily suspends the energy transfer</td><td>The Charging Station SHOULD send a TransactionEventRequest with chargingState = SuspendedEV</td></tr><tr><td>E01.FR.20</td><td>E01.FR.19 AND The Charging Station is not able to handle temporary suspension of energy transfer</td><td>The Charging Station SHOULD send a TransactionEventRequest with chargingState = EVConnected.</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Start Transaction - Cable Plugin First</td></tr><tr><td>2</td><td>ID</td><td>E02</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS that a transaction at the Charging Station has started.</td></tr><tr><td>4</td><td>Description</td><td>The EV Driver begins the interaction with the Charging Station by plugging in the charging cable first. The CSMS is notified about this. Then, when the communication between EV and EVSE is established, the transaction is started and the CSMS is notified of this. The EV starts charging.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver plugs in the cable at the Charging Station.
+2. The Charging Station sends a NotifyEventRequest with component.name Connector, variable.name AvailabilityState and actualValue Occupied to the CSMS to inform it about a Connector that became Occupied
+3. The Charging Station sends a TransactionEventRequest (eventType = Started) notifying the CSMS about a transaction that has started (even when the driver is not yet known.)
+4. The CSMS responds with a TransactionResponse, confirming that the TransactionEventRequest was received.
+5. The EV Driver is authorized by the Charging Station and/or CSMS.
+6. The energy offer starts.
+7. The Charging Station sends a TransactionEventRequest (eventType = Updated) with the authorized idToken information to the CSMS to inform about the charging status and which idToken belongs to the transaction.
+8. The CSMS responds with a TransactionResponse to the Charging Station with the IdTokenInfo.status Accepted.
+9. During the charging process, the Charging Stations continue to send TransactionEventRequest (Updated) messages for transaction-related notifications.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>E02 - Start Transaction - IdToken First
+E04 - Offline Start Transaction
+E05 - Start Transaction - Id not Accepted</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Cable is plugged in first.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ongoing and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is not ongoing. or
+The CSMS is not informed. or
+Start Transaction - Id not accepted.</td></tr><tr><td>7</td><td>Error handling</td><td>Failing to respond with TransactionResponse will only cause the Charging Station to try the same message again as specified in E12 - Transaction-related message not accepted by CSMS.</td></tr><tr><td>8</td><td>Remark(s)</td><td>If the Charging Station has implemented an Authorization Cache, then upon receipt of TransactionEventResponse, the Charging Station updates the cache entry.The scenario description and sequence diagram above are based on the Configuration Variable for start & stop transaction being configured as follows:TxStartPoint: EVConnectedThis use-case is also valid for other configurations, but then the transaction might start at another moment, which might change the sequence in which message are sent. For more details see the use cases: E01 - Start Transaction options and E06 - Stop Transaction options.</td></tr></table>
+
+
+Figure 55. Sequence Diagram: Start Transaction - Cable Plugin First
+
+# E02 - Start Transaction - Cable Plugin First - Requirements
+
+Table 64. E02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E02.FR.01</td><td>After the EV Driver is authorized for this transaction.</td><td>The next TransactionRequest SHALL contain triggerReason: Authorized AND IdotoninType information.</td><td></td></tr><tr><td>E02.FR.02</td><td>E02.FR.01</td><td>The CSMS SHALL send a TransactionResponse that includes an authorization status value.</td><td></td></tr><tr><td>E02.FR.03</td><td>This transaction ends a reservation.</td><td>The next TransactionRequest SHALL contain the reservationId.</td><td>See H. Reservation. (Same as E01.FR.13)</td></tr><tr><td>E02.FR.04</td><td></td><td>The CSMS SHALL verify the validity of the identifier in TransactionRequest.</td><td>Because the identifier might have been authorized locally by the Charging Station using outdated information.</td></tr><tr><td>E02.FR.05 (2.1)</td><td>When a cable is plugged in</td><td>The Charging Station SHALL send a NotifyRequest message for component( name = 'Connector', evse.id = <x>, evseconnectorld = <y> ), variable( name = 'AvailabilityState' ), and actualValue = 'Occupied' to signal that Connector <y> of EVSE <x> is now occupied.</td><td>Alternatively, the old StatusNotificationRequest with status: Occupied can still be sent.</td></tr><tr><td>E02.FR.06</td><td>When a cable is plugged in AND TxStartPoint contains EVConnected</td><td>The Charging Station SHALL send a TransactionRequest.</td><td></td></tr><tr><td>E02.FR.07</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information. (Same as E01.FR.07)</td></tr><tr><td>E02.FR.08</td><td></td><td>The transactionId generated by the Charging Station MUST be unique for each transaction started by that Charging Station, even when the Charging Station is rebooted, repaired, firmware is updated etc, it SHALL ensure that it never generates the same TransactionId twice.</td><td>(Same as E01.FR.08)</td></tr><tr><td>E02.FR.09</td><td>When configured to send meter data in the TransactionRequest(eventType = Started), See: Meter Values - Configuration AND EVSE is known at start of transaction</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td><td>(Same as E01.FR.09)</td></tr><tr><td>E02.FR.10</td><td>When configured to send meter data in the TransactionRequest(eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction.</td><td>(Same as E01.FR.11)</td></tr><tr><td>E02.FR.11</td><td>E02.FR.10 AND Amount of meter data is too much for 1 TransactionRequest(eventType = Updated)</td><td>The Charging Station MAY split meter data over multiple TransactionRequest(eventType = Updated) messages with the same timestamp.</td><td>(Same as E01.FR.14)</td></tr><tr><td>E02.FR.13</td><td>If the charging state changes</td><td>The Charging Station SHALL send a TransactionRequest including the chargingState element.</td><td>(Same as E01.FR.18)</td></tr><tr><td>E02.FR.14</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td></td></tr><tr><td>E02.FR.15</td><td>When sending a TransactionRequest</td><td>The Charging Station SHALL set the triggerReason to inform the CSMS about what triggered the event. What reason to use is described in the description of TriggerReasonEnumType.</td><td>(Same as E01.FR.15)</td></tr><tr><td>E02.FR.16</td><td>After a transaction has been started</td><td>The Charging Station MAY send additional TransactionRequest(eventType = Updated) messages during the transaction when a trigger event occurs.</td><td></td></tr><tr><td>E02.FR.17</td><td>When a transaction-related trigger event occurs, listed in TriggerReasonEnumType AND the transaction is ongoing.</td><td>The Charging Station SHALL send a TransactionRequest with a triggerReason corresponding to the occurred event.</td><td>When two trigger reasons overlap, the more specific one 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 TransactionRequest messages for each trigger, though.</td></tr><tr><td>E02.FR.18</td><td>When the energy transfer starts AND If the Charging Station is able to report the number of phases used</td><td>The Charging Station SHALL provide the number of phases used, using the numberOfPhasesUsed field.</td><td></td></tr><tr><td>E02.FR.19</td><td>E02.FR.18 AND during the transaction the number of phases used changes</td><td>The Charging Station SHALL provide the adjusted number of phases used, using the numberOfPhasesUsed field, in the next TransactionRequest.</td><td></td></tr><tr><td>E02.FR.20</td><td>When a transaction has not been authorized before AND the Charging Station authorizes an idToken to start charging</td><td>The next TransactionEventRequest from Charging Station SHALL contain the idToken and have triggerReason = Authorized.</td><td>If authorization is not successful, then no TransactionEventRequest is sent, because this event has no effect on the running transaction. (For authorization to stop charging, see E07).</td></tr><tr><td>E02.FR.21</td><td>When configured to send meter data in the TransactionEventRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is not known at start of transaction</td><td>The Charging Station SHALL add the measurands for eventType = Started to the optional meterValue field with context = Transaction.Start in the TransactionEventRequest(eventType = Updated) that occurs when charging starts.</td><td>(Same as E01.FR.17)</td></tr></table>
+
+E03 - Start Transaction - IdToken First
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Start Transaction - IdToken First</td></tr><tr><td>2</td><td>ID</td><td>E03</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the EV Driver to start a transaction by first presenting an IdToken at the Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the EV Driver is first authorized by presenting an IdToken before the cable is plugged in and a transaction starts.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver is authorized by the Charging Station and/or CSMS.
+2. The Charging Station informs the CSMS that a transaction has started by sending a TransactionRequest (eventType = Started).
+3. The EV Driver plugs in the Charging Cable at the Charging Station.
+4. The Charging Station sends NotifyEventRequest with component.name Connector, variable.name AvailabilityState and actualValue Occupied to, and receives NotifyResponse from the CSMS.
+5. The Charging Station informs the CSMS that the EV started charging by sending a TransactionRequest (eventType = Updated, chargingState = Charging).
+6. The CSMS responds with TransactionResponse, accepting the transaction.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>IdToken is presented prior to plugin cable.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+A transaction is started and the ChargingState is Charging
+Failure postcondition:
+No transaction is started</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>It is likely that the CSMS applies sanity checks to the data contained in TransactionRequest messages it received. The outcome of such sanity checks SHALL NOT ever cause the CSMS to not respond with a TransactionResponse. Failing to do so will only cause the Charging Station to try the same message again as specified in E12 - Transaction-related message not accepted by CSMS.
+The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:
+TxStartPoint: Authorized
+This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are sent. For more details see the use cases: E01 - Start Transaction options.</td></tr></table>
+
+
+Figure 56. Sequence Diagram: Start Transaction - IdToken First
+
+# E03 - Start Transaction - IdToken First - Requirements
+
+Table 65. E03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E03.FR.01</td><td>When the IdToken information is known.</td><td>The next TransactionRequest SHALL contain IdTokenType information.</td><td>(Same as E01.FR.13)</td></tr><tr><td>E03.FR.02</td><td>E03.FR.01</td><td>The CSMS SHALL send a TransactionResponse that includes an authorization status.</td><td></td></tr><tr><td>E03.FR.03</td><td>This transaction ends a reservation for the specific IdToken.</td><td>The next TransactionRequest SHALL contain the reservationId.</td><td>See H. Reservation.</td></tr><tr><td>E03.FR.05</td><td>When the EV Driver does not plug-in the charging cable before the timeout set by the Configuration Variable: EVConnectionTimeOut AND TxStopPoint does not contain ParkingBayOccupancy</td><td>The Charging Station SHOULD end the transaction and send a TransactionRequest (eventType = Ended, stoppedReason = Timeout, triggerReason = EVConnectionTimeout) to the CSMS.</td><td>This requirement is an additional safety measure to make sure the transaction is ended when the EVConnectionTimeOut is triggered. However it is up to the CSMS to make sure that sensible TxStartPoint / TxStopPoint combinations are configured. E.g. if Authorized is used as TxStartPoint, it should also be used as TxStopPoint.</td></tr><tr><td>E03.FR.06</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information. (Same as E01.FR.07)</td></tr><tr><td>E03.FR.07</td><td>When configured to send meter data in the TransactionRequest(eventType = Started), See: Meter Values - Configuration AND EVSE is known at start of transaction</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td><td>(Same as E01.FR.09)</td></tr><tr><td>E03.FR.08</td><td>When configured to send meter data in the TransactionRequest(eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction.</td><td>(Same as J02.FR.11)</td></tr><tr><td>E03.FR.09</td><td>E03.FR.08 AND Amount of meter data is too much for 1 TransactionRequest(eventType = Updated)</td><td>The Charging Station MAY split meter data over multiple TransactionRequest(eventType = Updated) messages with the same timestamp.</td><td>(Same as J02.FR.14)</td></tr><tr><td>E03.FR.10</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td>(Same as E02.FR.14)</td></tr><tr><td>E03.FR.11</td><td>When configured to send meter data in the TransactionRequest(eventType = Started), See: Meter Values - Configuration AND EVSE is not known at start of transaction</td><td>The Charging Station SHALL add the measurands for eventType = Started to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Updated) that occurs when charging starts.</td><td>(Same as E01.FR.17)</td></tr><tr><td>E03.FR.12</td><td>When a transaction-related trigger event occurs, listed in TriggerReasonEnumType AND the transaction is ongoing.</td><td>The Charging Station SHALL send a TransactionRequest with a triggerReason corresponding to the occurred event.</td><td>When two trigger reasons overlap, the more specific one 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 TransactionRequest messages. This is to prevent information loss, when something goes wrong. (Same as E02.FR.17)</td></tr><tr><td>E03.FR.13</td><td>When the energy transfer starts AND If the Charging Station is able to report the number of phases used</td><td>The Charging Station SHALL provide the number of phases used, using the numberOfPhasesUsed field.</td><td>(Same as E02.FR.18)</td></tr><tr><td>E03.FR.14</td><td>E03.FR.13 AND during the transaction the number of phases used changes</td><td>The Charging Station SHALL provide the adjusted number of phases used, using the numberOfPhasesUsed field in the next TransactionRequest.</td><td>(Same as E02.FR.19)</td></tr><tr><td>E03.FR.15</td><td>When the EV Driver does not plug-in the charging cable before the timeout set by the Configuration Variable: EVConnectionTimeout AND TxStopPoint contains ParkingBayOccupancy</td><td>The Charging Station SHALL deauthorize the transaction and send a TransactionRequest (triggerReason = EVConnectionTimeout) to the CSMS.</td><td>Transaction will be ended normally when driver leaves the parking bay.</td></tr></table>
+
+# E04 - Transaction started while Charging Station is offline
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Transaction started while Charging Station is offline</td></tr><tr><td>2</td><td>ID</td><td>E04</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the EV Driver to start a transaction while the Charging Station is Offline.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the Charging Station, while Offline, is able to start a transaction using the Local Authorization List or the Authorization Cache.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The transaction starts.
+2. The TransactionRequest (eventType = Started) is stored/queued by the Charging Station.
+3. The connection between Charging Station and CSMS is restored.
+4. The Charging Station starts to send queued messages
+5. The stored TransactionRequest is sent, notifying the CSMS about the transaction that was started.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>E10 - Connection Loss During Transaction</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station is Offline.
+The EV Driver is offline/locally authorized by the Charging Station.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The TransactionRequest has been responded to by the CSMS AND has been removed from the queue of the Charging Station.
+Failure postcondition:
+The TransactionRequest was NOT responded to by the CSMS AND remains in the queue of the Charging Station.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The scenario description and sequence diagram above are not based on a specific TxStartPoint. For more details see the use cases: E01 - Start Transaction options.</td></tr></table>
+
+
+Figure 57. Sequence Diagram: Transaction started while Charging Station is offline
+
+# E04 - Transaction started while Charging Station is offline - Requirements
+
+Table 66. E04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E04.FR.01</td><td>When Offline.</td><td>The Charging Station MUST queue any TransactionRequest messages.</td><td>Same as E12.FR.01</td></tr><tr><td>E04.FR.02</td><td>After the connection is restored.</td><td>The Charging Station MUST send queued TransactionRequest messages.</td><td>Same as E12.FR.02</td></tr><tr><td>E04.FR.03</td><td>E04.FR.02</td><td>The flag: "offline" SHALL be set to TRUE for any TransactionRequest that occurred while the Charging Station was offline.</td><td>Same as E12.FR.02</td></tr><tr><td>E04.FR.04</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information. Same E01.FR.07</td></tr><tr><td>E04.FR.05</td><td>When configured to send meter data in the TransactionRequest(eventType = Started), See: Meter Values - Configuration AND EVSE is known at start of transaction</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td><td>Same as E01.FR.09</td></tr><tr><td>E04.FR.06</td><td>When configured to send meter data in the TransactionRequest(eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction.</td><td>Same as J02.FR.11</td></tr><tr><td>E04.FR.07</td><td>E04.FR.06 AND Offline AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop TransactionRequest(eventType = Updated) messages.</td><td>Same as J02.FR.12</td></tr><tr><td>E04.FR.08</td><td>E04.FR.07</td><td>When dropping TransactionRequest(eventType = Updated) messages, the Charging Station SHALL drop intermediate messages first (1st message, 3th message, 5th message etc.), not start dropping messages from the start or stop adding messages to the queue.</td><td>Same as J02.FR.13</td></tr><tr><td>E04.FR.09</td><td>E04.FR.06 AND Amount of meter data is too much for 1 TransactionRequest(eventType = Updated)</td><td>The Charging Station MAY split meter data over multiple TransactionRequest(eventType = Updated) messages with the same timestamp.</td><td>Same as J02.FR.14</td></tr><tr><td>E04.FR.10</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td>Same as E02.FR.14</td></tr><tr><td>E04.FR.11</td><td>When configured to send meter data in the TransactionRequest(eventType = Started), See: Meter Values - Configuration AND EVSE is not known at start of transaction</td><td>The Charging Station SHALL add the measurands for eventType = Started to the optional meterValue field with context = Transaction.Begin in the TransactionRequest(eventType = Updated) that occurs when charging starts.</td><td>Same as E01.FR.17</td></tr></table>
+
+# E05 - Start Transaction - ld not Accepted
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Start Transaction - Id not Accepted</td></tr><tr><td>2</td><td>ID</td><td>E05</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Charging Station to suspend a transaction when the IdToken has an AuthorizationStatus that does not allow charging.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the Charging Station wants to start a transaction while the IdToken is not accepted by the CSMS. Since the identifier might have been authorized locally by the Charging Station using outdated information, the CSMS has to validate the IdTokenType in every TransactionEventRequest message it receives that contains an idToken. When receiving a TransactionEventResponse message with idTokenInfo.status is not Accepted, the Charging Station must stop the energy delivery to the EV.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends TransactionEventRequest (eventType = Started) that contains the IdToken provided by the EV Driver. 2. The CSMS responds with TransactionEventResponse, with an idTokenInfo.status that does not allow charging. 3. The Charging Station suspends the energy offer. (Taking into account: MaxEnergyOnInvalidId, if supported) 4. If StopTxOnInvalidId = false, then 4a. The Charging Station sends TransactionEventRequest (eventType = Updated) with triggerReason = ChargingStateChanged and the chargingState = SuspendedEVSE and receives TransactionEventResponse from the CSMS. 5. If StopTxOnInvalidId = true, then 5a. If TxStopPoint = "EVConnected" the Charging Station sends TransactionEventRequest (eventType = Updated) with triggerReason = Deauthorized and the chargingState = EVConnected and receives TransactionEventResponse from the CSMS. else 5b. If TxStopPoint = "Authorized" the Charging Station sends TransactionEventRequest (eventType = Ended) with triggerReason = Deauthorized and the chargingState = EVConnected and receives TransactionEventResponse from the CSMS.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The EV Driver is offline/locally authorized by the Charging Station. The IdToken is not allowed to charge by the CSMS.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition: The transaction is kept ongoing, and the cable remains locked, but no energy is delivered. Failure postcondition: n/a</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The scenario description and sequence diagram above are based on the Configuration Variable for start & stop transaction being configured as follows: TxStartPoint: PowerPathClosed TxStopPoint: either EVConnected or Authorized/PowerPathClosed This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are sent. For more details see the use cases: E01 - Start Transaction options and E06 - Stop Transaction options. NOTE: The configuration parameter MaxEnergyOnInvalidId only plays a role when StopTxOnInvalidId is set to false.</td></tr></table>
+
+
+Figure 58. Sequence Diagram: Start Transaction - Id not Accepted
+
+# E05 - Start Transaction - Id not Accepted - Requirements
+
+Table 67. E05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E05.FR.01</td><td></td><td>The CSMS MUST verify validity of the identifier in the TransactionRequest message.</td><td>The identifier might have been authorized locally by the Charging Station using outdated information. The identifier, for instance, may have been blocked since it was added to the Charging Station's Authorization Cache.</td></tr><tr><td>E05.FR.02</td><td>E05.FR.01 AND The authorization status in TransactionResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is set to false AND MaxEnergyOnInvalidId is not implemented or has been exceeded. TxStopPoint does NOT contain: EnergyTransfer</td><td>The Charging Station SHALL stop the energy delivery to the EV immediately and send TransactionRequest (eventType = Updated) with triggerReason set to ChargingStateChanged and chargingState set to SuspendedEVSE</td><td>The transaction is not deauthorized, but transfer of energy stops, since MaxEnergyOnInvalidId has been exceeded or is not set. If TxStopPoint contains EnergyTransfer then this would have ended the transaction.</td></tr><tr><td>E05.FR.03</td><td>E05.FR.01 AND The authorization status in TransactionEventResponse is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is set to false AND MaxEnergyOnInvalidId is set and has NOT been exceeded.</td><td>Energy delivery to the EV SHALL be allowed until the amount of energy specified in MaxEnergyOnInvalidId has been reached.</td><td></td></tr><tr><td>E05.FR.04</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information. Same as E01.FR.07</td></tr><tr><td>E05.FR.05</td><td>When configured to send meter data in the TransactionRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is known at start of transaction</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction.Starting in the TransactionRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td><td>Same as E01.FR.09</td></tr><tr><td>E05.FR.06</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td>Same as E01.FR.14</td></tr><tr><td>E05.FR.08</td><td>When configured to send meter data in the TransactionRequest (eventType = Started), See: Meter Values - Configuration AND EVSE is not known at start of transaction</td><td>The Charging Station SHALL add the measurands for eventType = Started to the optional meterValue field with context = Transaction.Starting in the TransactionRequest(eventType = Updated) that occurs when charging starts.</td><td>Same as E01.FR.17</td></tr><tr><td>E05.FR.09 (2.1)</td><td>E05.FR.01 AND The authorization status in TransactionRequest is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is true AND TxStopPoint does NOT contain: (Authorized OR PowerPathClosed OR EnergyTransfer)</td><td>The Charging Station SHALL stop the energy transfer and send TransactionRequest (eventType = Updated) with triggerReason set to Deauthorized and in the same or next TransactionRequest report chargingState set to EVConnected.</td><td>If the physical change of charging state in the Charging Station does not occur at (practically) the same time as the trigger Deauthorized, then the chargingState change may be reported separately as a triggerReason = ChargingStateChanged. Use of charging state SuspendedEVSE in this situation has become deprecated as of OCPP 2.1.</td></tr><tr><td>E05.FR.10</td><td>E05.FR.01 AND The authorization status in TransactionRequest is not Accepted AND The transaction is still ongoing AND StopTxOnInvalidId is true AND TxStopPoint does contain: (Authorized OR PowerPathClosed OR EnergyTransfer)</td><td>The Charging Station SHALL stop the transaction and send TransactionRequest (eventType = Ended) with triggerReason set to Deauthorized and stoppedReason set to DeAuthorized.</td><td></td></tr><tr><td>E05.FR.11</td><td>E05.FR.10 AND If the Charging Station has the possibility to lock the Charging Cable</td><td>The Charging Station SHOULD keep the Charging Cable locked until the owner presents his identifier.</td><td></td></tr></table>
+
+# E06 - Stop Transaction options
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Stop Transaction options</td></tr><tr><td>2</td><td>ID</td><td>E06</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS that a transaction at the Charging Station has stopped.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes the different moment a Charging Station can stop a transaction (send TransactionRequest(eventType=Ended), depending on the configuration of the Charging Station.</td></tr><tr><td>5</td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td>S1</td><td>Scenario objective</td><td>Stop a transaction when a parking bay occupancy no longer detector detects the EV.</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Stations parking bay occupancy detector stops detecting the EV.
+2. The Charging Station sends a TransactionRequest(eventType=Ended) notifying the CSMS about a transaction that has ended.
+3. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+Configuration Variable: TxStopPoint contains: ParkingBayOccupancy</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ended and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is still ongoing. or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 59. Sequence Diagram: Stop Transaction options - ParkingBayOccupancy
+
+<table><tr><td>S2</td><td>Scenario objective</td><td>Stop a transaction when communication between the Charging Station and the EV is lost. (for example: cable unplugged)</td></tr><tr><td></td><td>Scenario description</td><td>1. Communication between Charging Station and the EV is lost (Charging cable is unplugged).
+2. If charging cable unplugged on the Charging Station side: send NotifyEventRequest with component.name Connector, variable.name AvailabilityState and actualValue Available to the CSMS to inform it about a Connector that became Available
+3. The Charging Station sends a TransactionEventRequest (eventType = Ended) notifying the CSMS about a transaction that has ended.
+4. The CSMS responds with a TransactionEventResponse, confirming that the TransactionEventRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+Configuration Variable: TxStopPoint contains: EVConnected</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ended and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is still ongoing. or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 60. Sequence Diagram: Stop Transaction options - EVConnected
+
+<table><tr><td>S3</td><td>Scenario objective</td><td>Stop a transaction when the driver is no longer authorized.</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends a TransactionEventRequest to the CSMS.
+2. An invalid IdToken is received in a TransactionEventResponse.
+3. The Charging Station sends a TransactionEventRequest (eventType = Ended) notifying the CSMS about a transaction that has ended.
+4. The CSMS responds with a TransactionEventResponse, confirming that the TransactionEventRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+Configuration Variable: TxStopPoint contains: Authorized</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ended and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is still ongoing. or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 61. Sequence Diagram: Stop Transaction options - Deauthorized
+
+<table><tr><td>S5</td><td>Scenario objective</td><td>Stop a transaction when the EV driver is no longer authorized and/or the EV is disconnected.</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station is disconnected from EV and/or the EV driver is no longer authorized.
+2. The Charging Station sends a TransactionRequest (eventType = Ended) notifying the CSMS about a transaction that has ended.
+3. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+Configuration Variable: TxStopPoint contains: PowerPathClosed</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ended and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is still ongoing. or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 62. Sequence Diagram: Stop Transaction options - PowerPathClosed
+
+<table><tr><td>S6</td><td>Scenario objective</td><td>Stop a transaction when energy transfer stops. This will also mean the transaction stops when the EV stops taking energy, for example when the battery is to hot.</td></tr><tr><td></td><td>Scenario description</td><td>1. The energy transfer between EV and the Charging Station stops (for example: EV stops charging).
+2. The Charging Station sends a TransactionRequest (eventType = Ended) notifying the CSMS about a transaction that has ended.
+3. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+Configuration Variable: TxStopPoint contains: EnergyTransfer</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ended and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is still ongoing. or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 63. Sequence Diagram: Stop Transaction options - EnergyTransfer
+
+<table><tr><td>S7</td><td>Scenario objective</td><td>Stop a transaction when EV driver ends authorization</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV drivers presents an IdToken to end the charging.
+2. The Charging Station sends a TransactionRequest (eventType = Ended) notifying the CSMS about a transaction that has ended.
+3. The CSMS responds with a TransactionResponse, confirming that the TransactionRequest was received.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+Configuration Variable: TxStopPoint contains: Authorized (or PowerPathClosed).</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction is ended and the CSMS is Successfully informed.
+Failure postcondition:
+The transaction is still ongoing. or
+The CSMS is not informed.</td></tr></table>
+
+
+Figure 64. Sequence Diagram: Stop Transaction options - Authorized
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# E06 - Stop Transaction options - Requirements
+
+Table 68. E06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E06.FR.01</td><td>TxStopPoint contains: ParkingBayOccupancy AND Parking Bay Detector no longer detects the "EV"</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.02</td><td>TxStopPoint contains: EVConnected AND Connection between Charging Station and EV is lost.</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.03</td><td>TxStopPoint contains: Authorized AND EV Driver is authorized to stop a transaction.</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.04</td><td>TxStopPoint contains: Authorized AND CSMS returns a non-valid idTokenInfo in a TransactionResponse</td><td>See use case E05 - Start Transaction - Id not Accepted,</td></tr><tr><td>E06.FR.05</td><td>TxStopPoint contains: DataSigned AND Charging Station can no longer retrieve signed meter values.</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.06</td><td>TxStopPoint contains: PowerPathClosed AND ( Connection between Charging Station and EV is lost OR Authorization has ended or idToken is deauthorized )</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.07</td><td>TxStopPoint contains: EnergyTransfer AND Energy transfer stops</td><td>The Charging Station SHALL stop the transaction and send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>E06.FR.08</td><td>If a transaction is not ended by the EV Driver at the Charging Station</td><td>The Charging Station SHALL include the stoppedReason element in the TransactionRequest(eventType = Ended). What reason to use is described in the description of reasonEnumType.</td></tr><tr><td>E06.FR.09</td><td>If a transaction is ended by the EV Driver at the Charging Station (e.g. EV Driver presented IdToken to stop the transaction)</td><td>The Charging Station MAY omit the stoppedReason element in the TransactionRequest(eventType = Ended) (hence the CSMS can interpret the reason as local when omitted).</td></tr><tr><td>E06.FR.10</td><td>As part of the normal transaction termination.</td><td>The Charging Station SHALL unlock the cable (if not permanently attached).</td></tr><tr><td>E06.FR.11</td><td>When configured to send meter data in the TransactionRequest(eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction. End in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td></tr><tr><td>E06.FR.12</td><td>E06.FR.11 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message.</td></tr><tr><td>E06.FR.13</td><td>E06.FR.12</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td></tr><tr><td>E06.FR.14</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation. (Same as E01.FR.07)</td></tr><tr><td>E06.FR.15</td><td>When sending a TransactionRequest</td><td>The Charging Station SHALL set the triggerReason to inform the CSMS about what triggered the event. What reason to use is described in the description of TriggerReasonEnumType. (Same as E01.FR.15)</td></tr><tr><td>E06.FR.16</td><td>A transaction was stopped by an Abnormal Error or Fault Condition.</td><td>The Charging Station SHALL send TransactionRequest(eventType = Ended, triggerReason=AbnormalCondition)_to the CSMS.</td></tr></table>
+
+# E07 - Transaction locally stopped by IdToken
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Transaction locally stopped by IdToken</td></tr><tr><td>2</td><td>ID</td><td>E07</td></tr><tr><td>3</td><td>Objective(s)</td><td>The EV Driver wants to stop an ongoing transaction, by locally presenting his IdToken.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the EV Driver can stop a transaction when he wants to leave the charging station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario descriptionReportingStopAuthorized withend of transaction</td><td>TxStopPoint = Authorized (or PowerPathClosed)1. The EV Driver presents IdToken a second time to end charging.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 TransactionRequest (eventType = Ended) with triggerReason = StopAuthorized and stoppedReason = Local.4. The CSMS responds with a TransactionResponse.</td></tr><tr><td></td><td>Alternative scenario(s)ReportingStopAuthorized inUpdate event first, thenend transaction</td><td>TxStopPoint = Authorized (or PowerPathClosed)1. The EV Driver presents IdToken a second time to end charging.2. The Charging Station sends a TransactionRequest (eventType = Updated) with triggerReason = StopAuthorized3. The CSMS responds with a TransactionResponse.4. The Charging Station stops the energy transfer and if the cable is not permanently attached, the Charging Station unlocks the cable.5. The Charging Station sends a TransactionRequest (eventType = Ended) with triggerReason = ChargingStateChanged, transactionInfo.chargingState = EVConnected6. The CSMS responds with a TransactionResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A transaction is ongoing.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The CSMS has received all relevant information about the transaction and the Charging Station is in Idle status.
+Failure postcondition:
+The transaction is still ongoing or the Charging Station is in Idle status and still holds information about the transaction that it has to deliver to the CSMS.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The scenario descriptions are based on TxStopPoint containing Authorized or PowerPathClosed. The sequence diagrams also show behavior for other TxStopPoint values in the alt-blocks.
+The CSMS cannot prevent a transaction from stopping.</td></tr></table>
+
+
+Figure 65. Sequence Diagram: Transaction locally stopped by IdToken with TransactionEventRequest reported strictly by TxStopPoint configuration
+
+
+Figure 66. Sequence Diagram: Transaction locally stopped by IdToken with delayed TransactionRequest eventType = Ended for TxStopPoint = Authorized OR PowerPathClosed
+
+# E07 - Transaction locally stopped by IdToken - Requirements
+
+Table 69. E07 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E07.FR.01</td><td>When an idToken is presented during a transaction that has been authorized AND (a) the presented idToken is the same as the idToken that started the authorization OR (b) when the presented idToken is in the Local Authorization List or Authorization Cache AND is valid AND has the same GroupIdToken as the IdToken that started the authorization.</td><td>The Charging Station SHALL end the authorization of the transaction, without first sending an AuthorizationRequest</td><td>The idToken that started the authorization can always be used to end the authorization. Ending authorization will end delivery of energy. Depending on the TxStopPoint ending of the authorization may also end the transaction. (See C01.FR.03)</td></tr><tr><td>E07.FR.02</td><td>E07.FR.01</td><td>The Charging Station SHALL send a TransactionRequest with triggerReason = StopAuthorized and SHOULD include the idToken used to stop authorization.</td><td>The stopping idToken may differ from the starting idToken, when they share the same Groupid.</td></tr><tr><td>E07.FR.04</td><td>If a transaction is stopped on request of the EV driver at the Charging Station.</td><td>Charging Station MAY omit the stoppedReason element from the final TransactionRequest with eventType = Ended</td><td>e.g. EV-driver presented IdToken to stop the transaction or pressed a "stop" button (not the emergency stop). See use case F03 for remotely stopping.</td></tr><tr><td>E07.FR.05</td><td>If a transaction is stopped on request of the EV driver at the Charging Station.</td><td>Charging Station SHOULD use a stoppedReason = Local in the final TransactionRequest with eventType = Ended.</td><td>e.g. EV-driver presented IdToken to stop the transaction or pressed a "stop" button (not the emergency stop). See use case F03 for remotely stopping.</td></tr><tr><td>E07.FR.06</td><td>If a transaction is stopped, but not on request of the EV driver at the Charging Station.</td><td>Charging Station SHOULD use the most appropriate value from ReasonEnumType for stoppedReason in the final TransactionRequest with eventType = Ended.</td><td>Apart from remotely stopping (Remote), CSMS revoking authorization (DeAuthorized) or disconnecting the EV (EVDisconnected), most other reasons are related to technical faults or energy limitations.</td></tr><tr><td>E07.FR.07</td><td>As part of the normal transaction termination.</td><td>The Charging Station SHALL unlock the cable (if not permanently attached).</td><td></td></tr><tr><td>E07.FR.08</td><td>When configured to send meter data in the TransactionRequest (eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field with context = Transaction. End in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td><td>Same as E06.FR.11</td></tr><tr><td>E07.FR.09</td><td>E07.FR.08 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message.</td><td>Same as E06.FR.12</td></tr><tr><td>E07.FR.10</td><td>E07.FR.09</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td><td>Same as E06.FR.13</td></tr><tr><td>E07.FR.11</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information. Same as E01.FR.07</td></tr><tr><td>E07.FR.12</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td>Same as E02.FR.14</td></tr></table>
+
+# E08 - Transaction stopped while Charging Station is offline
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Transaction stopped while Charging Station is offline</td></tr><tr><td>2</td><td>ID</td><td>E08</td></tr><tr><td></td><td>Parent use case</td><td>E07 - Local Stop Transaction</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the EV Driver to stop a transaction while the Charging Station is Offline.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how an EV Driver can stop a transaction while the Charging Station is Offline. While a transaction is ongoing and the Charging Station is Offline, the EV Driver presents his IdToken, if the Charging Stations knows locally (without asking the CSMS) that this IdToken is allowed to stop the transaction, it will stop the ongoing transaction. When the Charging Station restores the connection with the CSMS, it needs to send the information about this Offline stop transaction to the CSMS.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver presents IdToken to stop the transaction.
+2. When this is the same IdToken as was used to start the transaction, or via the Local Authorization List and / or Authorization Cache the GroupId can be validated: the transaction is stopped.
+3. The Charging Station stops the energy offer.
+4. The TransactionRequest (eventType = Ended) is stored/queued by the Charging Station.
+5. The connection between Charging Station and CSMS is restored.
+6. The Charging Station starts to send queued messages
+7. The stored TransactionRequest is sent, notifying the CSMS about the transaction that was stopped.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Transaction ongoing and connection lost.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Charging Station is in Idle status.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>groupld check must be done on Local Authorization List and / or Authorization Cache if available.
+The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.
+TxStopPoint: ParkingBayOccupancy, EVConnected, Authorized
+This use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are sent. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+
+Figure 67. Sequence Diagram: Transaction stopped while Charging Station is offline
+
+# E08 - Transaction stopped while Charging Station is offline - Requirements
+
+Table 70. E08 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E08.FR.01</td><td>If the IdToken presented is the same as the IdToken used to start the transaction.</td><td>The Charging Station SHALL stop the energy offering.</td><td></td></tr><tr><td>E08.FR.02</td><td>If the IdToken presented has the same GroupId as the IdToken used to start the transaction.</td><td>The Charging Station SHALL stop the energy offering.</td><td></td></tr><tr><td>E08.FR.03</td><td>(E08.FR.01 OR E08.FR.02) AND Cable not permanently attached</td><td>The Charging Station SHALL unlock the connector.</td><td></td></tr><tr><td>E08.FR.04</td><td>(E08.FR.01 OR E08.FR.02)</td><td>The Charging Station SHALL "generate" a TransactionRequest (eventType = Ended).</td><td></td></tr><tr><td>E08.FR.05</td><td>When Offline.</td><td>The Charging Station MUST queue any TransactionRequest messages.</td><td>Same as E12.FR.01</td></tr><tr><td>E08.FR.06</td><td>After the connection is restored.</td><td>The Charging Station MUST send queued TransactionRequest messages.</td><td>E12.FR.02</td></tr><tr><td>E08.FR.07</td><td></td><td>The flag: offline SHALL be set to TRUE for any TransactionRequest that occurred while the Charging Station was offline.</td><td>E12.FR.02</td></tr><tr><td>E08.FR.08</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information. Same E01.FR.07</td></tr><tr><td>E08.FR.09</td><td>When configured to send meter data in the TransactionRequest(eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td><td></td></tr><tr><td>E08.FR.10</td><td>E08.FR.09 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message.</td><td>Same as E06.FR.12</td></tr><tr><td>E08.FR.11</td><td>E08.FR.10</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td><td>Same as E06.FR.13</td></tr><tr><td>E08.FR.12</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td>Same as E02.FR.14</td></tr></table>
+
+# E09 - When cable disconnected on EV-side: Stop Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>When cable disconnected on EV-side: Stop Transaction</td></tr><tr><td>2</td><td>ID</td><td>E09</td></tr><tr><td></td><td>Parent use case</td><td>E07 - Local Stop Transaction</td></tr><tr><td>3</td><td>Objective(s)</td><td>To stop an ongoing transaction when the Charging Cable is unplugged on the EV side.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how a transaction is stopped when the EV Driver unplugs the cable at the EV side. In this use case the Configuration Variable: StopTxOnEVSideDisconnect = true.The Charging Cable is unplugged at the EV side. This is detected by the Charging Station. The Charging Station stops the transaction and sends a TransactionRequest to the CSMS. The Charging Cable, if locked and UnlockOnEvSideDisconnect = false, will remain locked at the Charging Station until the EV Driver returns and presents his/hers IdToken. Otherwise it will unlock the cable.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The cable is unplugged at the EV.2. The energy offer is suspended.3. The Charging Station sends TransactionRequest (eventType = Ended, stoppedReason = EVDisconnected) to the CSMS.4. The CSMS responds with TransactionResponse.5. The EV Driver is authorized and unplants the cable.6. The Charging Station sends NotifyEventRequest with component.name Connector, variable.name AvailabilityState and actualValue Available to the CSMS.7. The CSMS responds with NotifyEventResponse.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>E10 - When cable disconnected on EV-side: Suspend Transaction</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Configuration Variable: StopTxOnEVSideDisconnect = trueA transaction is ongoing</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The Charging Station is in Idle status.Failure postcondition:n/a</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>When the Charging Cable is plugged back in, the charging will not resume/continue.The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.TxStopPoint: AuthorizedThis use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are sent. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+
+Figure 68. Sequence Diagram: When cable disconnected on EV-side: Stop Transaction
+
+# E09 - When cable disconnected on EV-side: Stop Transaction - Requirements
+
+Table 71. E09 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E09.FR.01</td><td>If StopTxOnEVSideDisconnect = true .</td><td>The transaction SHALL be deauthorized when the cable is disconnected from the EV. If the EV is reconnected, energy transfer is not allowed until the transaction is authorized once again.</td><td>Setting StopTxOnEVSideDisc onnect to true will prevent sabotage acts when unplugging not locked cables on EV side.</td></tr><tr><td>E09.FR.02</td><td>E09.FR.01 AND the cable is not permanently attached AND UnlockOnEvSideDisconnect = true.</td><td>The Charging Station SHALL unlock the Charging Cable.</td><td></td></tr><tr><td>E09.FR.03</td><td>E09.FR.01 AND the cable is not permanently attached AND UnlockOnEvSideDisconnect = false.</td><td>The Charging Station SHALL unlock the Charging Cable only after authorization by the EV Driver.</td><td></td></tr><tr><td>E09.FR.04</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information. Same as E01.FR.07</td></tr><tr><td>E09.FR.05</td><td>When configured to send meter data in the TransactionRequest (eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td><td>Same as E08.FR.09</td></tr><tr><td>E09.FR.06</td><td>E09.FR.05 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message.</td><td>Same as E06.FR.12</td></tr><tr><td>E09.FR.07</td><td>E09.FR.06</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td><td>Same as E06.FR.13</td></tr><tr><td>E09.FR.08</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td>Same as E02.FR.14</td></tr></table>
+
+# E10 - When cable disconnected on EV-side: Suspend Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>When cable disconnected on EV-side: Suspend Transaction</td></tr><tr><td>2</td><td>ID</td><td>E10</td></tr><tr><td></td><td>Parent use case</td><td>E07 - Local Stop Transaction</td></tr><tr><td>3</td><td>Objective(s)</td><td>To suspend an ongoing transaction when the Charging Cable is unplugged on the EV side.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how a transaction is suspended when the EV Driver unplants the cable at the EV side. In this use case the Configuration Variable: StopTxOnEVSideDisconnect = false.The Charging Cable is unplugged at the EV side. This is detected by the Charging Station. The Charging Station stops the energy offering (safety), but does not stop the transaction. The Charging Cable, if locked, will remain locked at the Charging Station until the EV Driver returns and presents his/hers IdToken.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver unplants the cable at the EV while a transaction is ongoing.2. The energy offer is suspended.When the EV Driver plugs the cable back in, the transaction is resumed.A1. The Charging Station sends a TransactionRequest (eventType = Updated, trigger = CablePluggedIn)A2. The CSMS responds with a TransactionResponse.If cable not permanently attachedB1. The EV Driver is authorized by the Charging Station and/or CSMS to unlock the charging cable.B2. The cable is unlocked.B3. The Charging Station sends a TransactionRequest (eventType = Ended, trigger = StopAuthorized).B4. The EV Driver removes the charging cable.B5. The Charging Station sends a NotifyEventRequest with component.name Connector, variable.name AvailabilityState and actualValue Available to the CSMS.B6. The CSMS responds with a NotifyResponse.If cable permanently attachedC1. The cable is not plugged in within timeout.C2. The Charging Station sends a TransactionRequest (eventType = Ended, trigger = EVCommunicationLost, stoppedReason = EVDisconnected).C3. The Charging Station sends a NotifyEventRequest with component.name Connector, variable.name AvailabilityState and actualValue Available to the CSMS.C4. The CSMS responds with a NotifyResponse.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>E09 - When cable disconnected on EV-side: Stop Transaction</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Configuration Variable: StopTxOnEVSideDisconnect = falseA transaction is ongoing</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The Charging Station is in Idle status.The regular transaction is resumed.Failure postcondition:n/a</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>When the Charging Cable is plugged back in, the charging is resumed.When the cable is permanently attached and the cable is not plugged in within a certain timeout, the Charging Station stops the transaction. This timeout is not defined by OCPP, it is left to the implementor of the Charging Station.The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.TxStopPoint: ParkingBayOccupancy, AuthorizedThis use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are sent. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+
+Figure 69. Sequence Diagram: When cable disconnected on EV-side: Suspend Transaction
+
+# E10 - When cable disconnected on EV-side: Suspend Transaction - Requirements
+
+Table 72. E10 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E10.FR.01</td><td>Cable not permanently attached</td><td>The Connector SHALL remain locked at the Charging Station until the EV Driver presents the IdToken.</td><td></td></tr><tr><td>E10.FR.02</td><td>Cable permanently attached AND Cable not plugged in within timeout</td><td>The Charging Station SHALL deauthorize the transaction.</td><td></td></tr><tr><td>E10.FR.03</td><td>When a TransactionRequest has to be created</td><td>The Charging Station SHALL set the message's seqNo field as specified in Sequence Number Generation.</td><td>This enables the CSMS to track the completeness of transaction information. Same as E01.FR.07</td></tr><tr><td>E10.FR.04</td><td>When configured to send meter data in the TransactionRequest(eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td><td>Same as E08.FR.09</td></tr><tr><td>E10.FR.05</td><td>E10.FR.04 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message.</td><td>Same as E06.FR.12</td></tr><tr><td>E10.FR.06</td><td>E10.FR.05</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td><td>Same as E06.FR.13</td></tr><tr><td>E10.FR.07</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues.</td><td>Same as E02.FR.14</td></tr></table>
+
+# E11 - Connection Loss During Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Connection Loss During Transaction</td></tr><tr><td>2</td><td>ID</td><td>E11</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable a Charging Station to continue a transaction while the Charging Station loses its connection</td></tr><tr><td>4</td><td>Description</td><td>This use cases describes how a Charging Station can continue an ongoing transaction while losing and regaining the connection with the CSMS.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The connection of the Charging Station is lost, while a transaction is ongoing.
+2. The transaction events of the Charging Station are stored.
+3. The connection with the CSMS is restored.
+4. The Charging Station sends the stored transaction events to the CSMS using TransactionRequest (offline = TRUE).
+5. The Charging Station resumes regular communication.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>E04 - Offline Start Transaction</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Transaction ongoing and connection lost.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station resumes regular communication.
+Failure postcondition:
+n/a</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 70. Sequence Diagram: Connection Loss During Transaction
+
+# E11 - Connection Loss During Transaction - Requirements
+
+Table 73. E11 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E11.FR.01</td><td>When Offline</td><td>The Charging Station MUST queue all TransactionEventRequest messages, that it would have sent to the CSMS if the Charging Station had been online. (Same as E12.FR.01)</td></tr><tr><td>E11.FR.02</td><td>After the connection is restored.</td><td>The Charging Station MUST send queued TransactionRequest messages with the flag offline set to TRUE. (Same as E12.FR.02)</td></tr><tr><td>E11.FR.03</td><td>When configured to send meter data in the TransactionRequest(eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction. (Same as J02.FR.11)</td></tr><tr><td>E11.FR.04</td><td>E11.FR.03 AND Offline AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop TransactionRequest(eventType = Updated) messages. (Same as J02.FR.12)</td></tr><tr><td>E11.FR.05</td><td>E11.FR.04</td><td>When dropping TransactionRequest(eventType = Updated) messages, the Charging Station SHALL drop intermediate messages first (1st message, 3th message, 5th message etc.), not start dropping messages from the start or stop adding messages to the queue. (Same as J02.FR.13)</td></tr><tr><td>E11.FR.06</td><td>E11.FR.03 AND Amount of meter data is too much for 1 TransactionRequest(eventType = Updated)</td><td>The Charging Station MAY split the meter data over multiple TransactionRequest(eventType = Updated) messages with the same timestamp. (Same as J02.FR.14)</td></tr><tr><td>E11.FR.07</td><td></td><td>If the Charging Station goes offline, every message that is still in the queue SHALL be set Offline.</td></tr><tr><td>E11.FR.08</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues. (Same as E02.FR.14)</td></tr></table>
+
+E12 - Inform CSMS of an Offline Occurred Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Inform CSMS of an Offline Occurred Transaction</td></tr><tr><td>2</td><td>ID</td><td>E12</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Charging Station to inform the CSMS that a transaction occurred while the Charging Station was Offline.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the Charging Station starts and stops a transaction since connection loss.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The connection with the CSMS is restored.
+2. The Charging Station sends a Heartbeat message to the CSMS.
+3. The Charging Station sends TransactionRequest (eventType = Started, offline = TRUE) to the CSMS.
+4. The CSMS responds with TransactionResponse, accepting the transaction.
+5. The Charging Station sends TransactionRequest (eventType = Updated, offline = TRUE)
+6. The CSMS responds with TransactionResponse.
+7. The Charging Station sends TransactionRequest (eventType = Ended, offline = TRUE)
+8. The CSMS responds with TransactionResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>At least one Offline transaction has taken place.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The CSMS has processed all transactions that occurred Offline.
+Failure postcondition:
+n/a</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 71. Sequence Diagram: Inform CSMS of an Offline Occurred Transaction
+
+# E12 - Inform CSMS of an Offline Occurred Transaction - Requirements
+
+Table 74. E12 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E12.FR.01</td><td>When Offline</td><td>The Charging Station MUST queue all TransactionRequest messages, that it would have sent to the CSMS if the Charging Station had been online.</td></tr><tr><td>E12.FR.02</td><td>After the connection is restored.</td><td>The Charging Station MUST send queued TransactionRequest messages with the flag offline set to TRUE.</td></tr><tr><td>E12.FR.03</td><td>When configured to send meter data in the TransactionRequest(eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction. (Same as J02.FR.11)</td></tr><tr><td>E12.FR.04 (2.1)</td><td>E12.FR.03 AND Charging station is offline AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop TransactionRequest(eventType = Updated) messages that do not have triggerReason LimitSet, CostLimitReached, EnergyLimitReached, TimeLimitReached or SoCLimitReached.</td></tr><tr><td>E12.FR.05</td><td>E12.FR.04</td><td>When dropping TransactionRequest(eventType = Updated) messages, the Charging Station SHALL drop intermediate messages first (1st message, 3th message, 5th message etc.), not start dropping messages from the start or stop adding messages to the queue. (Same as J02.FR.13)</td></tr><tr><td>E12.FR.06</td><td>E12.FR.03 AND Amount of meter data is too much for 1 TransactionRequest(eventType = Updated)</td><td>The Charging Station MAY split the meter data over multiple TransactionRequest(eventType = Updated) messages with the same timestamp. (Same as J02.FR.14)</td></tr><tr><td>E12.FR.07</td><td>When configured to send meter data in the TransactionRequest(eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage. (Same as E08.FR.09)</td></tr><tr><td>E12.FR.08</td><td>E12.FR.07 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message. (Same as E06.FR.12)</td></tr><tr><td>E12.FR.09</td><td>E12.FR.08</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list. (Same as E06.FR.13)</td></tr><tr><td>E12.FR.10</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values and put them in the signedMeterValue field of sampledValues. (Same as E06.FR.14)</td></tr></table>
+
+# E13 - Transaction-related message not accepted by CSMS
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Transaction-related message not accepted by CSMS</td></tr><tr><td>2</td><td>ID</td><td>E13</td></tr><tr><td>3</td><td>Objective(s)</td><td>To define how a Charging Station shall handle not accepted messages.</td></tr><tr><td>4</td><td>Description</td><td>There are situations/issues why a CSMS might not accept a transaction related message, or does not reply within the MessageTimeout. Most are error scenarios. When something like this happens, the Charging Station SHALL retry the messages a couple of times.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends a transaction-related message to the CSMS.
+2. The message is not accepted and MessageAttemptsTransactionEvent not reached.
+3. The Charging Station waits the number of preceding transmissions of this same message times MessageAttemptIntervalTransactionEvent seconds.
+4. The Charging Station resends the transaction-related message to the CSMS.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+MessageAttemptsTransactionEvent is not reached AND the transaction-related message is accepted. MessageAttemptsTransactionEvent is reached AND the transaction-related message is disposed.
+Failure postcondition:
+MessageAttemptsTransactionEvent is not reached AND the transaction-related message is disposed. MessageAttemptsTransactionEvent is reached AND the transaction-related message is accepted.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>This use case describes the expected behaviour when the CSMS does not accept a message, or does not reply within the message timeout, this is different from a situation where the communication between Charging Station and CSMS is Offline.</td></tr></table>
+
+
+Figure 72. Sequence Diagram: Transaction-related message not accepted by CSMS
+
+# E13 - Transaction-related message not accepted by CSMS - Requirements
+
+Table 75. E13 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E13.FR.01</td><td></td><td>The number of times and the interval with which the Charging Station should retry such failed transaction-related messages MAY be configured using the MessageAttemptsTransactionEvent and MessageAttemptIntervalTransactionEvent Configuration Variables.</td></tr><tr><td>E13.FR.02</td><td>When the Charging Station encounters a first failure to deliver a certain transaction-related message.</td><td>The Charging Station SHALL send this message again as long as it keeps resulting in a failure to process this message and it has not yet encountered as many failures to process this message for this message as specified in its MessageAttemptsTransactionEvent Configuration Variable.</td></tr><tr><td>E13.FR.03</td><td>The CSMS does not accept a transaction-related message.</td><td>The Charging Station SHALL wait as many seconds as specified in its MessageAttemptIntervalTransactionEvent key, multiplied by the number of preceding transmissions of this same message.</td></tr><tr><td>E13.FR.04</td><td>If the final attempt fails.</td><td>The Charging Station SHALL discard the message and continue with the next transaction-related message, if there is any.</td></tr></table>
+
+# E13 - Transaction-related message not accepted by CSMS - Example
+
+As an example, consider a Charging Station that has the value "3" for the MessageAttemptsTransactionEvent Configuration Variable and the value "60" for the MessageAttemptIntervalTransactionEvent Configuration Variable. It sends a TransactionEventRequest message and detects a failure to process the message in the CSMS. The Charging Station SHALL wait for 60 seconds, and resend the message. In the case when there is a second failure, the Charging Station SHALL wait for 120 seconds, before resending the message. If this final attempt fails, the Charging Station SHALL discard the message and continue with the next transaction-related message, if there is any.
+
+E14 - Check transaction status
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Check transaction status</td></tr><tr><td>2</td><td>ID</td><td>E14</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to request the status of a transaction and to find out whether there are queued transaction-related messages.</td></tr><tr><td>4</td><td>Description</td><td>There are scenarios where a CSMS needs to know whether there are still messages for a transaction that need to be delivered. For example: A CSMS receives a TransactionRequest (eventType = Ended), it wants to start the billing process for this transaction but detects it is still missing some intermediate messages (it can check this via the sequence number in the messages). It can ask if the Charging Station has still messages in the queue for this transaction with the GetTransactionStatusRequest specifying the transactionId. Depending on the result the CSMS might for example: wait for the messages to be delivered, or start the billing process without the information. It may also need to know whether a transaction is still ongoing. If the CSMS wants to know if there are transaction-related messages in the queue at all (not just for a specific transaction), it can send a GetTransactionStatusRequest without a transactionId.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a GetTransactionStatusRequest with or without a transactionId to the Charging Station.
+2. The Charging Station responds with a GetTransactionStatusResponse.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The CSMS knows the transactionId of a transaction it wants to know the status of.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The CSMS knows the status of the requested transaction.
+Failure postcondition:
+The CSMS does not know the status of the requested transaction.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>When the CSMS receives a GetTransactionStatusResponse with both fields (ongoingIndicator and messagesInQueue) set to false, this might mean that the transaction is finished and there are no more messages in the queue for this transaction, or the Charging Station doesn't know anything about this transaction (anymore).</td></tr></table>
+
+
+Figure 73. Sequence Diagram: Check transaction status
+
+E14 - Check transaction status - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td></tr><tr><td>E14.FR.01</td><td>The Charging Station receives a GetTransactionStatusRequest with a transactionId AND It did not do a transaction with that transactionId</td><td>The Charging Station SHALL respond with ongoingIndicator = false AND messagesInQueue = false.</td></tr><tr><td>E14.FR.02</td><td>The Charging Station receives a GetTransactionStatusRequest with a transactionId AND The transaction with that transactionId has not stopped yet</td><td>The Charging Station's response SHALL have ongoingIndicator = true.</td></tr><tr><td>E14.FR.03</td><td>The Charging Station receives a GetTransactionStatusRequest with a transactionId AND The transaction with that transactionId has stopped</td><td>The Charging Station's response SHALL have ongoingIndicator = false.</td></tr><tr><td>E14.FR.04</td><td>The Charging Station receives a GetTransactionStatusRequest with a transactionId AND It has transaction-related messages to be delivered about the transaction with that transactionId</td><td>The Charging Station's response SHALL have messagesInQueue = true.</td></tr><tr><td>E14.FR.05</td><td>The Charging Station receives a GetTransactionStatusRequest with a transactionId AND It has no transaction-related messages to be delivered about the transaction with that transactionId</td><td>The Charging Station's response SHALL have messagesInQueue = false.</td></tr><tr><td>E14.FR.06</td><td>The Charging Station receives a GetTransactionStatusRequest without a transactionId</td><td>The Charging Station's response SHALL NOT have ongoingIndicator set.</td></tr><tr><td>E14.FR.07</td><td>The Charging Station receives a GetTransactionStatusRequest without a transactionId AND It has transaction-related messages to be delivered</td><td>The Charging Station's response SHALL have messagesInQueue = true.</td></tr><tr><td>E14.FR.08</td><td>The Charging Station receives a GetTransactionStatusRequest without a transactionId AND It has no transaction-related messages to be delivered</td><td>The Charging Station's response SHALL have messagesInQueue = false.</td></tr></table>
+
+# 2.2. Interrupting and Stopping ISO 15118 Charging
+
+E15 - End of charging process
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>End of charging process.</td></tr><tr><td>2</td><td>ID</td><td>E15</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 H1 - End of charging process</td></tr><tr><td>3</td><td>Objective(s)</td><td>See ISO15118-1, use case Objective H1, page 44.</td></tr><tr><td>4</td><td>Description</td><td>See ISO15118-1, use case Description H1, page 44.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>See ISO15118-1, use case Description H1, Basic elementary use case description, first 5 bullets and last 2 remarks, page 44.6. The EV driver unplugs the cable from the EV7. The Charging Station sends a TransactionRequest with eventType/eventType = Ended to the CSMS.</td></tr><tr><td>5</td><td>Prerequisites</td><td>See ISO15118-1, use case Prerequisites H1, page 44.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS has received all relevant information about the transaction.See ISO15118-1, use case End Conditions H1, page 44.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>See ISO15118-1, use case Requirements H1, page 44 for the trigger.
+The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.
+TxStopPoint: ParkingBayOccupancy, EVConnected, Authorized, PowerPathClosed
+This use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are sent. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+
+Figure 74. End of charging process
+
+Source: ISO15118-1
+
+# E15 - End of charging process - Requirements
+
+Table 76. E15 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>E15.FR.01</td><td>When configured to send meter data in the TransactionRequest (eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest (eventType = Ended) sent to the CSMS to provide more details about transaction usage. (Same as E08.FR.09)</td></tr><tr><td>E15.FR.02</td><td>E15.FR.01 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data in the TransactionRequest(eventType = Ended) message. (Same as E06.FR.12)</td></tr><tr><td>E15.FR.03</td><td>E15.FR.02</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list. (Same as E06.FR.13)</td></tr><tr><td>E15.FR.04</td><td>When TxStopPoint contains "Authorized" or "PowerPathClosed" or "EnergyTransfer" AND Charging Station has not yet sent a TransactionRequest with triggerReason = StopAuthorized when it receives a ISO 15118 SessionStopReq(Terminate) message from the EV</td><td>Charging Station SHALL send a TransactionRequest message with eventType = Ended and triggerReason = StopAuthorized and stoppedReason = StoppedByEV to inform the CSMS that the charging transaction has been stopped (by the EV).</td></tr><tr><td>E15.FR.05</td><td>When TxStopPoint does not contain "Authorized" or "PowerPathClosed" or "EnergyTransfer" AND Charging Station has not yet sent a TransactionRequest with triggerReason = StopAuthorized when it receives a ISO 15118 SessionStopReq(Terminate) message from the EV</td><td>Charging Station SHALL send a TransactionRequest message with eventType = Updated and triggerReason = StopAuthorized to inform the CSMS that the authorization has ended.</td></tr></table>
+
+# 2.3. Transactions with limits
+
+# E16 - Transactions with fixed cost, energy, SoC or time
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Transactions with fixed cost, energy, SoC or time</td></tr><tr><td>2</td><td>ID</td><td>E16</td></tr><tr><td>3</td><td>Objective(s)</td><td>EV Driver or CSMS specifies a limit in cost, energy, state of charge or time for transaction</td></tr><tr><td>4</td><td>Description</td><td>An EV Driver or CSMS specifies a limit in cost, energy, SoC or time. The limit can be updated during a transaction.A cost limit is most likely to be used for a prepaid charging session, or for a direct payment in which case the cost limit is set to the pre-authorized amount for the direct payment.An energy or time limit can also be provided by EV Driver or CSMS. Note that it is the energy transfer that is limited. It is not possible to limit the duration of a transaction, because the end of a transaction is determined by the configured TxStopPoint.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>EV Driver specifies an energy limit1. EV Driver has input a maximum energy amount to charge via UI of Charging Station.2. Charging Station includes transactionInfo transactionLimit.maxEnergy with the specified maximum once in the next TransactionEventRequests for this transaction.3. When the amount of energy imported by EV reaches transactionInfo transactionLimit.maxEnergy, Charging Station stops the energy transfer and sends a TransactionRequest with chargingState = SuspendedEVSE and triggerReason = EnergyLimitReached.a. If the transactionLimit is increased when in this state, then Charging Station will resume the energy transfer.</td></tr><tr><td></td><td>Scenario description #2</td><td>CSMS specifies a cost limit1. CSMS has a cost limit for the transaction on this Charging Station.(This can be a fixed setting, a reservation amount for an adhoc payment, or the balance of a prepaid card as in use case C17 - Authorization with prepaid card).2. In order to communicate this cost limit to the Charging Station, CSMS responds to a TransactionRequest with a TransactionResponse that has a transactionLimit.maxCost with the cost limit. This is only done once for every change in cost limit.3. Charging Station will take note of this cost limit, and add the transactionLimit.maxCost element to transactionInfo of the next TransactionRequest message for this transaction as a confirmation towards CSMS of the received limit.4. When the cost for energy transfer reaches transactionInfo transactionLimit.maxCost, Charging Station stops the energy transfer and sends a TransactionRequest with chargingState = SuspendedEVSE and triggerReason = CostLimitReached.a. If the transactionLimit is increased when in this state, then Charging Station will resume the energy transfer.b. If Charging Station does not calculate the cost locally, then it stops the energy transfer as soon as totalCost in a TransactionResponse or CostUpdatedRequest reaches or is near the maximum cost.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Station supports the limits maxEnergy and maxCost.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Energy transfer in transaction is only allowed up to maximum cost, energy, state of charge or time limitation.</td></tr><tr><td>7</td><td>Error handling</td><td>Charging Station confirms a transaction limit from CSMS by returning the limit in the next TransactionRequest. If CSMS provides a transaction limit that Charging Station does not support, it will not be returned in the next TransactionRequest.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Only two scenarios are shown in the use case (energy limit and cost limit), but the same scenario is also valid for limits of time and state of charge that are supplied by either Charging Station or CSMS.It is possible to change the limit of a transaction even when energy transfer is already in progress, and it can be done more than once.If more than one limit is given, for example both a time and an energy limit, then whichever limit is reached first, determines the end of energy transfer.In order for a Charging Station to stop exactly on time when a cost limit is given, cost will have to be calculated locally at the Charging Station. If Charging Station does not support local cost calculation, and a cost limit is given, then it will use the value of the cost updates from CSMS (in TransactionEventResponse or CostUpdatedRequest) to determine when the cost limit is reached or exceeded.See section I Tariff and Cost for information on tariffs and cost calculation.A Charging Station reports the limits that it supports in configuration key "TxCtrl.SupportedLimits".</td></tr></table>
+
+# NOTE
+
+Following diagrams only show parameters related to the use case. More parameters are required in these messages.
+
+Two examples are shown. All limits can be set by either Charging Station or CSMS.
+
+
+Figure 75. Sequence diagram for transaction with limited energy
+
+
+Figure 76. Sequence diagram for transaction with limited cost
+
+# E16 - Transactions with fixed cost, energy, SoC or time - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>E16.FR.01</td><td>When Charging Station sets or changes a limit to the transaction in cost, energy, SoC or time</td><td>Charging Station SHALL send a TransactionEventRequest with triggerReason = LimitSet and include this limit once in the field transactionInfo_transactionLimit.</td><td>This is usually a limit entered by EV Driver. Sending transactionLimit may be part of another triggerReason if multiple triggers apply, see E02.FR.17.</td></tr><tr><td>E16.FR.02</td><td>When CSMS sets or changes a limit to the transaction in cost, energy, SoC or time</td><td>CSMS SHALL include the field transactionLimit once in the first possible TransactionEventResponse message.</td><td>transactionLimit uses maxCost for cost limit, maxEnergy for energy limit, maxTime for time limit or maxSoC for SoC limit.</td></tr><tr><td>E16.FR.03</td><td>E16.FR.02 AND at least one of the limits in transactionLimit is supported by the Charging Station</td><td>Charging Station SHALL send a TransactionEventRequest with triggerReason = LimitSet and include the supported limit(s) once in the field transactionInfo_transactionLimit.</td><td>This confirms to CSMS that the limit is set. For example, a prepaid cost limit. See also E16.FR.13.</td></tr><tr><td>E16.FR.04</td><td>E16.FR.02</td><td>Charging Station SHALL NOT send a TransactionEventRequest with a transactionInfo_transactionLimit that exceeds a limit that was previously set by CSMS</td><td>For example, when CSMS has set a prepaid balance as a maximum cost, then CS must not allow EV Driver set the maximum cost to a higher limit.</td></tr><tr><td>E16.FR.05</td><td>During a transaction the transactionLimit is reached AND TxStopPoint does not contain "EnergyTransfer"</td><td>Charging Station SHALL suspend energy transfer AND send a TransactionEventRequest with chargingState = SuspendedEVSE and triggerReason CostLimitReached, EnergyLimitReached, TimeLimitReached or SoCLimitReached, depending on the reached limit.</td><td>The triggerReason for xxxLimitReached must be used, otherwise there is no way to know whether SuspendedEVSE is caused by smart charging or by a transaction limit.</td></tr><tr><td>E16.FR.06</td><td>During a transaction the transactionLimit is reached AND TxStopPoint contains "EnergyTransfer"</td><td>Charging Station SHALL end the transaction AND send a TransactionEventRequest with eventType = Ended and triggerReason CostLimitReached, EnergyLimitReached, TimeLimitReached or SoCLimitReached, depending on the reached limit.</td><td>The triggerReason for xxxLimitReached must be used, otherwise there is no way to know that end of transaction is caused by a transaction limit.</td></tr><tr><td>E16.FR.07</td><td>E16.FR.01 AND CSMS also wishes to set one or more of the same limits</td><td>CSMS MAY respond with TransactionEventResponse with an updated transactionLimit .</td><td>CSMS always has the last word and can overrule the limit from Charging Station.</td></tr><tr><td>E16.FR.08</td><td>E16.FR.07 AND The limit(s) reported by Charging Station are lower or equal to the limit(s) that CSMS requires</td><td>CSMS SHALL NOT respond with TransactionEventResponse with an updated transactionLimit .</td><td>The Charging Station limit is already below the limit that CSMS requires.</td></tr><tr><td>E16.FR.09</td><td></td><td>The timer for a time limit SHALL be relative to the start of the transaction (TransactionEventRequest(Started))</td><td>Purpose of a time limit is usually to limit the time that a station is kept occupied. Depending on TxStartPoint the start of a transaction can be some time before energy transfer.</td></tr><tr><td>E16.FR.10</td><td>When a transactionLimit is set at the time when the actual value already exceeds the limit</td><td>Charging Station SHALL immediately suspend energy transfer or stop the transaction according to E16.FR.05 or E16.FR.06.</td><td>Immediately act on exceeded limit. This also applies when a negative limit has been given.</td></tr><tr><td>E16.FR.11</td><td>When a transactionLimit.maxCost is active AND ( TariffCostCtrl[Tariff] = false OR when CSMS has not provided a (default) tariff plan )</td><td>CSMS SHALL provide cost updates to Charging Station in TransactionEventResponse or CostUpdatedRequest.</td><td>Central cost calculation is used.</td></tr><tr><td>E16.FR.12</td><td></td><td>CSMS SHALL NOT send a transactionLimit in a TransactionEventResponse that is not reported by the Charging Station in configuration key TxCtrlr.SupportedLimits.</td><td></td></tr><tr><td>E16.FR.13</td><td>E16.FR.01 AND the limit is not supported by the Charging Station</td><td>Charging Station SHALL NOT return this element in the transactionInfo transactionLimit field of the next TransactionEventRequest.</td><td>This tells CSMS that the limit is not supported.</td></tr><tr><td>E16.FR.14</td><td>When chargingState = SuspendedEVSE as a result of reaching a transactionLimit (E16.FR.06) AND The transactionLimit is increased (either by EV Driver or CSMS)</td><td>Charging Station SHALL resume energy transfer.</td><td></td></tr><tr><td>E16.FR.15</td><td>E16.FR.11</td><td>Charging Station SHALL use the cost update from CSMS to determine whether cost limit has been reached or exceeded.</td><td></td></tr><tr><td>E16.FR.16</td><td>When a transactionLimit.maxCost is active AND ( TariffCostCtrl[Tariff] = true AND CSMS has provided a (default) tariff plan )</td><td>Charging Station SHALL NOT use the cost updates from CSMS in TransactionEventResponse or CostUpdatedRequest to determine the cost, but use local cost calculation via the tariff plan.</td><td>Local cost calculation is used.</td></tr><tr><td>E16.FR.17</td><td>If CSMS or Charging Station wish to remove a certain transaction limit</td><td>CSMS or Charging Station SHALL set the value of this limit to a high enough value, such that it is no longer relevant as a limit.</td><td>Once a limit is set in a transaction, it cannot be upset, only changed.</td></tr><tr><td>E16.FR.18</td><td>When CSMS sends a TransactionResponse with a transactionLimit in response to a TransactionRequest message with offline = true</td><td>CSMS SHOULD NOT expect a confirmation from Charging Station for the transactionLimit in TransactionRequest messages that have offline = true.</td><td>The queued messages with offline = true are historical messages from the offline period and not a response to setting the transactionLimit. See also E16.FR.03.</td></tr><tr><td>E16.FR.19</td><td>When the granularity of the measurements on Charging Station of transactionLimit values is such that it may not be possible to stop exactly on the limit</td><td>Charging Station SHOULD try to avoid exceeding the transactionLimit values.</td><td>For example, if an energy meter only reports in 1000 Wh increments and the maxEnergy limit is set to 2300 Wh, then Charging Station should stop at 2000 Wh.</td></tr><tr><td>E16.FR.20</td><td>When Charging Station receives TransactionResponse with a transactionLimit that is does not support</td><td>Charging Station MAY report this as a NotifyEventRequest message with trigger = Alerting and eventNotificationType = HardwiredNotification for component = "TxCtrl", variable = "SupportedLimits" and actualValue set to the not-supported limit: "maxEnergy", "maxCost", "maxTime" or "maxSoC".</td><td>See also E16.FR.12</td></tr></table>
+
+# 2.4. Resuming transactions
+
+# E17 - Resuming transaction after forced reboot
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Resuming transaction after forced reboot</td></tr><tr><td>2</td><td>ID</td><td>E17</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show how a transaction can be resumed after it has been interrupted as a result of a forced reboot of the Charging Station. This allows a transaction to survive interruptions, such as power outages or critical software faults.</td></tr><tr><td>4</td><td>Description</td><td>A transaction is running at the Charging Station. The Charging Station gets shut down unexpectedly, e.g. due to a software fault, watchdog event, maintenance mode activation or power loss at the Charging Station. If the interruption lasts no longer than the configured TxResumptionTimeout, then the Charging Station will resume the transaction. If the interruption exceeds the timeout, then the transaction will end. The configuration variable TxAllowEnergyTransferResumption can be set to false if for a resumed transaction the automatic resumption of energy transfer to the vehicle is not allowed.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description #1</td><td>Resuming transaction before TxResumptionTimeout seconds
+1. Configuration variable TxResumptionTimeout has been set to a value > 0.
+2. An ongoing transaction is interrupted, for example as a result of power loss.
+3. Charging Station reboots when power is restored.
+4. If the interruption occurred less (or equal) than TxResumptionTimeout seconds ago, then Charging Station resumes the transaction in the charging state from before the interruption.
+a. If TxAllowEnergyTransferResumption = false then energy transfer is not allowed anymore on the resumed transaction.
+b. Charging State sends TransactionEventRequest with eventType = Updated and triggerReason = TxResumed.</td></tr><tr><td></td><td>Scenario description #2</td><td>Ending transaction after TxResumptionTimeout seconds1. Configuration variable TxResumptionTimeout has been set to a value > 0.2. An ongoing transaction is interrupted, for example as a result of power loss.3. Charging Station reboots when power is restored.4. If the interruption occurred more than TxResumptionTimeout seconds ago, thenCharging Station ends the transaction.a. Charging Station sends TransactionEventRequest with eventType = Ended and triggerReason = AbnormalCondition and stoppedReason = PowerLoss (orReboot if Charging Station rebooted because of a local issue).</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>TxResumptionTimeout has been set.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Transactions survive forced reboot.Failure postcondition:· The Charging Station was not able to resume the transaction,· The EV was not able to resume the energy transfer.</td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>The EVSE of the Charging Station will have to resume the charging session towards the EV.Depending on the type of connector and protocol (Mode 3, ISO 15118, CHAdeMO, etc.) this will involve different actions, which are not detailed in this specification.Charging profiles of type TxProfile are not required to be stored in persistent memory. If such a charging profile is applicable to the resumed transaction(s), then CSMS will have to send the charging profile again.TxAllowEnergyTransferResumption = false can be used to protect the user from a scenario where e.g. the plug has been removed and inserted into another vehicle during the interruption, therefore enabling another EV driver to charge based on a different EV driver's transaction and authorization.</td></tr></table>
+
+
+Figure 77. Sequence diagram for resuming an interrupted transaction
+
+# E17 - Resuming transaction after interruption - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td colspan="4">Generic</td></tr><tr><td>E17.FR.01</td><td>If TxResumptionTimeout > 0</td><td>Charging Station SHALL store transaction state in persistent memory</td><td>This is needed in order to resume transactions after a power loss.</td></tr><tr><td>E17.FR.02</td><td>E17.FR.01</td><td>The timer for TxResumptionTimeout starts from the moment that Charging Station detected or had recorded the unexpected shutdown</td><td>It is up to the implementer how time of shutdown is determined after restarting.</td></tr><tr><td colspan="4">Within timeout</td></tr><tr><td>E17.FR.10</td><td>When Charging Station reboots after interruption AND Interruption was not longer than TxResumptionTimeout seconds</td><td>Charging Station SHALL resume the transactions that were ongoing before the interruption.</td><td></td></tr><tr><td>E17.FR.11</td><td>E17.FR.10 AND TxAllowEnergyTransferResumption = true AND the EV and EVSE are not disconnected</td><td>Charging Station SHALL resume such a transaction in the charging state it had before the interruption.</td><td></td></tr><tr><td>E17.FR.12</td><td>E17.FR.10 AND
+TxAllowEnergyTransferResumption = false AND
+Charging state was Charging AND the EV and EVSE are not disconnected</td><td>Charging Station SHALL resume such a transaction in the charging state SuspendedEVSE or EVConnected.</td><td></td></tr><tr><td>E17.FR.13</td><td>E17.FR.10 AND
+TxAllowEnergyTransferResumption = false AND
+Charging state was not (Charging or SuspendedEV) AND the EV and EVSE are not disconnected</td><td>Charging Station SHALL resume such a transaction in the charging state it had before the interruption.</td><td></td></tr><tr><td>E17.FR.14</td><td></td><td>For each resumed transaction Charging Station SHALL send a TransactionEventRequest with eventType = Updated and triggerReason = TxResumed and its chargingState as well as other relevant parameters.</td><td></td></tr><tr><td>E17.FR.15</td><td>E17.FR.14 AND
+CSMS has a charging profile of chargingProfilePurpose = TxProfile for transactions reported with triggerReason = TxResumed AND SmartChargingCtrl.ChargingProfilePersistence for instance = "TxProfile" = false or absent</td><td>CSMS SHALL send the SetChargingProfileRequest for chargingProfilePurpose = TxProfile for these transactions again.</td><td>The charging profiles are identical to those sent at start of transaction, since start time of the resumed transaction has not changed.</td></tr><tr><td>E17.FR.16</td><td>E17.FR.10 AND
+the EV and EVSE are disconnected AND the TxStopPoint conditions are not met</td><td>Charging Station SHALL resume such a transaction in the charging state Idle.</td><td></td></tr><tr><td>E17.FR.17</td><td>E17.FR.10 AND
+the EV and EVSE are disconnected AND the TxStopPoint conditions are met</td><td>The transaction will end normally, as described by E06 - Stop Transaction options</td><td></td></tr><tr><td>E17.FR.18</td><td>E17.FR.11 AND
+Before interruption the charging state was Charging AND The EV and EVSE are not disconnected</td><td>The Charging Station SHALL delay resuming energy transfer for a random amount of seconds, with a maximum of the value configured at EnergyTransferResumptionRandomRange.</td><td>If after a power outage all Charging Stations in an area start resuming energy transfer at the exact same time, this may result in issues with the energy grid.</td></tr><tr><td colspan="4">After timeout</td></tr><tr><td>E17.FR.20</td><td>When Charging Station reboots after interruption AND Interruption was longer than TxResumptionTimeout seconds</td><td>Charging Station SHALL end the transactions that were ongoing before the interruption.</td><td></td></tr><tr><td>E17.FR.21</td><td>E17.FR.20 AND Interruption was caused by a power loss</td><td>Charging Station SHALL send a TransactionEventRequest with eventType = Ended and triggerReason = AbnormalCondition and stoppedReason = PowerLoss.</td><td></td></tr><tr><td>E17.FR.22</td><td>E17.FR.20 AND Interruption was caused by Charging Station (e.g. software fault or watch dog timer)</td><td>Charging Station SHALL send a TransactionEventRequest with eventType = Ended and triggerReason = AbnormalCondition and stoppedReason = Reboot.</td><td></td></tr></table>
+
+# F. Remote Control
+
+# Chapter 1. Introduction
+
+This Functional Block describes three types of use cases for remote control management from the CSMS:
+
+1. Remote Transaction Control. These use cases describe the functionality which enable the CSO (or indirect a third party) to start/stop a transaction with a remote command.
+2. Unlocking a Connector. These use cases describe the functionality that enables the CSO (or indirect a third party) to unlock the Connector with a remote command. This can for example be used to assist customers when they have problems unplugging their cable.
+3. Remote Trigger. These use cases describe all the remote trigger functionality of OCPP. This functionality enables remote triggering of messages. For example, requesting messages to be resend or request current status of some ongoing processes in the Charging Station.
+
+# Chapter 2. Use cases & Requirements
+
+# 2.1. Remote Transaction Control
+
+# F01 - Remote Start Transaction - Cable Plugin First
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remote Start Transaction - Cable Plugin First</td></tr><tr><td>2</td><td>ID</td><td>F01</td></tr><tr><td>3</td><td>Objective(s)</td><td>1. To remotely start a transaction by the CSMS.
+2. To enable a CSO to help an EV Driver that has problems starting a transaction.
+3. To enable third parties (e.g. mobile apps) to control charging transactions via the CSMS.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS remotely requests the Charging Station to start a transaction by sending RequestStartTransactionRequest. Upon receipt, the Charging Station responds with RequestStartTransactionResponse and a status indicating whether it is able to try to start a transaction or not.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver plugs in the cable at the Charging Station.
+2. The Charging Station sends a NotifyEventRequest with component.name Connector, variable.name AvailabilityState and actualValue Occupied to the CSMS to inform it about a Connector that became Occupied
+3. The CSMS responds with a NotifyEventResponse, confirming that the NotifyEventRequest was received.
+4. The Charging Station sends a TransactionEventRequest (eventType = Started) notifying the CSMS about a transaction that has started (even when the driver is not yet known.)
+5. The CSMS responds with a TransactionEventResponse, confirming that the TransactionEventRequest was received.
+6. An external trigger (as example in this use case: EV Driver) triggers the remote start.
+7. The CSMS sends a RequestStartTransactionRequest to the Charging Station.
+8. The Charging Station responds with a RequestStartTransactionResponse with the transactionId of the already started transaction to the CSMS.
+9. Optionally: the EV Driver is authorized by the CSMS.
+10. The Charging Station sends a TransactionEventRequest (eventType = Updated, chargingState = Charging) message to inform the CSMS that the charging has started.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>Remote Start Transaction - Remote Start First F02 - Remote Start Transaction - Remote Start First</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Cable plugged in first.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station offers energy. If the value of AuthorizedRemoteStart is true, the Charging Station will only offer energy when it successfully authorized the IdToken, using Local Authorization List, Authorization Cache and/or an AuthorizedRequest.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>An external trigger can be e.g. a Charging Station Operator or an EV Driver app.
+The RequestStartTransactionResponse contains a status which indicates whether the Charging Station has accepted the request and will attempt to start a transaction.
+The CSMS is allowed to send a RequestStartTransactionRequest with IdTokenType of type: NoAuthorization. The operator should be aware that if the Charging Station supports local stop transaction, this transaction can be stopped by anyone.
+The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:
+TxStartPoint: EVConnected
+This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use cases: E01 - Start Transaction options.</td></tr></table>
+
+
+Figure 78. Sequence Diagram: Remote Start Transaction - Cable Plugged in First
+
+# F01 - Remote Start Transaction - Cable Plugin First - Requirements
+
+Table 77. F01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F01.FR.01</td><td>If the value of authorizeRemoteStart = true AND Charging Station receives a RequestStartTransactionRequest</td><td>The Charging Station SHALL behave as if in response to a local action at the Charging Station to allow energy transfer after successful authorization of the IdToken given in RequestStartTransactionRequest message.</td><td>Charging Station will first respond to the request and then try to authorize the IdToken, using the Local Authorization List, Authorization Cache and/or anauthorizeRequest. Energy transfer is only allowed after authorization was obtained.</td></tr><tr><td>F01.FR.02</td><td>If the value of authorizeRemoteStart = false AND Charging Station receives a RequestStartTransactionRequest</td><td>The Charging Station SHALL allow energy transfer for the IdToken given in RequestStartTransactionRequest message without checking authorization.</td><td>Charging Station will first respond to the request, and send a TransactionEventRequest with the idToken to the CSMS, and the CSMS will check the authorization status of the IdToken when processing this TransactionRequest.</td></tr><tr><td>F01.FR.03</td><td>F01.FR.01 OR F01.FR.02</td><td>The Charging Station SHALL send a TransactionRequest to the CSMS, and the CSMS will check the authorization status of the IdToken when processing this TransactionRequest.</td><td>If CSMS returns an authorization status that is not Accepted, then Charging Station must stop energy transfer as per use case E05.</td></tr><tr><td>F01.FR.04</td><td></td><td>RequestStartTransactionRequest SHALL contain an IdToken, which Charging Station SHALL use, if it is able to start a transaction, in the TransactionRequest sent to the CSMS.</td><td></td></tr><tr><td>F01.FR.05</td><td></td><td>The transaction SHALL be started in the same way as described in E01 - Start Transaction - Cable Plugin First.</td><td></td></tr><tr><td>F01.FR.06</td><td></td><td>RequestStartTransactionRequest MAY contain an evseld if the transaction is to be started on a specific EVSE.</td><td>When no evseld is provided, the Charging Station is in control of the EVSE selection.</td></tr><tr><td>F01.FR.07</td><td>If the RequestStartTransactionRequest does not contain an evseld.</td><td>The Charging Station MAY reject the RequestStartTransactionRequest.</td><td></td></tr><tr><td>F01.FR.08</td><td></td><td>The CSMS MAY include a ChargingProfile in the RequestStartTransactionRequest.</td><td></td></tr><tr><td>F01.FR.09</td><td>F01.FR.08</td><td>The purpose of this ChargingProfile SHALL be set to TxProfile.</td><td></td></tr><tr><td>F01.FR.10</td><td>F01.FR.08</td><td>The Charging Station SHALL use this ChargingProfile for the transaction that is started by this RequestStartTransaction.</td><td></td></tr><tr><td>F01.FR.11</td><td>F01.FR.08</td><td>The transactionId in the ChargingProfile SHALL NOT be set.</td><td></td></tr><tr><td>F01.FR.12</td><td>If a Charging Station without support for Smart Charging receives a RequestStartTransactionRequest with a ChargingProfile.</td><td>The Charging Station SHALL ignore the specified ChargingProfile.</td><td>The device model variable SmartChargingCtrl.Enabl ed tells CSMS whether smart charging is supported.</td></tr><tr><td>F01.FR.13</td><td>When a transaction is created on the Charging Station, but has not been authorized. AND RequestStartTransactionRequest is received.</td><td>The Charging Station SHALL return the transactionId in the RequestStartTransactionResponse.</td><td></td></tr><tr><td>F01.FR.14</td><td>When configured to send meter data in the TransactionEventRequest (eventType = Started), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionEventRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td><td></td></tr><tr><td>F01.FR.15</td><td>When configured to send meter data in the TransactionEventRequest (eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionEventRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction.</td><td>Same as J02.FR.11</td></tr><tr><td>F01.FR.16</td><td>F01.FR.15 AND Amount of meter data is too much for 1 TransactionEventRequest (eventType = Updated)</td><td>The Charging Station MAY split meter data over multiple TransactionEventRequest(eventType = Updated) messages with the same timestamp.</td><td>Same as J02.FR.14</td></tr><tr><td>F01.FR.17</td><td>When sending a TransactionEventRequest</td><td>The Charging Station SHALL set the triggerReason to inform the CSMS about what triggered the event. What reason to use is described in the description of TriggerReasonEnumType.</td><td>Same as E01.FR.15</td></tr><tr><td>F01.FR.18</td><td>After a transaction has been started</td><td>The Charging Station MAY send additional TransactionEventRequest(eventType = Updated) messages during the transaction when a trigger event occurs.</td><td></td></tr><tr><td>F01.FR.19</td><td>When a RequestStartTransactionRequest is received.</td><td>The next TransactionEventRequest SHALL contain triggerReason: RemoteStart.</td><td></td></tr><tr><td>F01.FR.20</td><td>If the RequestStartTransactionRequest does not contain an evseld AND the Charging Station is capable of selecting an EVSE</td><td>The Charging Station SHALL select an EVSE to be used as a value for evseld for the operation</td><td>See also F01.FR.07 if Charging Station does not support starting at an arbitrary EVSE.</td></tr><tr><td>F01.FR.21</td><td>When the evseld for RequestStartTransactionRequest is Reserved for an idToken that differs from idToken in the request AND has no reservation for a groupldToken</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td></td></tr><tr><td>F01.FR.22</td><td>When the evseld for RequestStartTransactionRequest is Reserved for an idToken that differs from idToken in the request AND is Reserved for a groupldToken that differs from groupldToken in the request</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td>EV is not allowed to use station if neither idToken nor idGroupToken match the reservation.</td></tr><tr><td>F01.FR.23</td><td>When the evse for RequestStartTransactionRequest is Unavailable or Faulted</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td></td></tr><tr><td>F01.FR.24</td><td>When the evseld for RequestStartTransactionRequest is Occupied AND this evseld has a transaction that has been authorized</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td>Only an EVSE with no transaction or with a transaction that has not yet been authorized can be matched with the RequestStartTransaction Request</td></tr><tr><td>F01.FR.25</td><td>F01.FR.13</td><td>The Charging Station SHALL put the remoteStartId in the next TransactionEventRequest it sends for the associated transaction.</td><td></td></tr><tr><td>F01.FR.26</td><td>If a Charging Station with support for Smart Charging receives a RequestStartTransactionRequest with an invalid ChargingProfile.</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected and optionally with reasonCode = "InvalidProfile" or "InvalidSchedule".</td><td>The device model variable SmartChargingCtrl.Enabling tells CSMS whether smart charging is supported.</td></tr></table>
+
+# F02 - Remote Start Transaction - Remote Start First
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remote Start Transaction - Remote Start first</td></tr><tr><td>2</td><td>ID</td><td>F02</td></tr><tr><td></td><td>Parent use case</td><td>F01 - Remote Start Transaction - Cable Plugin First</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to remotely start a transaction while the RequestStartTransactionRequest is sent first, before the connection between Charging Station and EV is established.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS is able to remotely start a transaction for the User.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, External Trigger</td></tr><tr><td></td><td>Scenario description</td><td>1. An External Trigger triggers the remote start.
+2. The CSMS sends RequestStartTransactionRequest to the Charging Station.
+3. The Charging Station responds with RequestStartTransactionResponse to the CSMS.
+4. The EV Driver is authorized by the CSMS, dependent on the Configuration Variable settings.
+5. The Charging Station sends a TransactionEventRequest (eventType = Started) notifying the CSMS about a transaction that has started
+6. The cable is plugged in.
+7. The charging Station sends a NotifyEventRequest with component.name Connector, variable.name AvailabilityState and actualValue Occupied
+8. CSMS sends a NotifyEventResponse to the Charging Station
+9. The energy offer is started.
+10. The Charging Station sends a TransactionEventRequest (eventType = Updated, chargingState = Charging) message to inform the CSMS that the charging has started.
+11. The CSMS sends TransactionEventResponse to the Charging Station</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Cable not plugged in.
+Remote start first.
+Enable mobile apps to control charging transactions via the CSMS.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction for which a start was request has started and the EV is charging.
+Failure postcondition:
+The transaction for which a start was request did not start or the EV is not charging.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>An external trigger can be e.g. a Charging Station Operator or an EV Driver app.
+It is advised not to start transactions remotely without evseld due to the uncertainty which EVSE is started. In case of a Logic Controller with many EVSEs, the EV Driver might not be in front of the activated EVSE.
+The CSMS is allowed to send a RequestStartTransactionRequest with IdTokenType of type: NoAuthorization. The operator should be aware that if the Charging Station supports local stop transaction, this transaction can be stopped by anyone.
+The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:
+TxStartPoint: either EVConnected or Authorized
+This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use cases: E01 - Start Transaction options.</td></tr></table>
+
+
+Figure 79. Sequence Diagram: Remote Start Transaction - Remote Start First with TxStartPoint=Authorized
+
+
+Figure 80. Sequence Diagram: Remote Start Transaction - Remote Start First with TxStartPoint=EVCntected
+
+# F02 - Remote Start Transaction - Remote Start First - Requirements
+
+Table 78. F02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F02.FR.01</td><td>When a transaction is started as a result of a RequestStartTransactionRequest.</td><td>The Charging Station SHALL put the remoteStartId in the first TransactionRequest it sends for this new transaction.</td><td></td></tr><tr><td>F02.FR.02</td><td>When configured to send meter data in the TransactionRequest(eventType = Started), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Started) sent to the CSMS to provide more details during the transaction.</td><td>Same as F01.FR.14</td></tr><tr><td>F02.FR.03</td><td>When configured to send meter data in the TransactionRequest(eventType = Updated), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Updated) sent to the CSMS to provide more details during the transaction.</td><td>Same as J02.FR.11</td></tr><tr><td>F02.FR.04</td><td>F02.FR.03 AND Amount of meter data is too much for 1 TransactionRequest(eventType = Updated)</td><td>The Charging Station MAY split meter data over multiple TransactionRequest(eventType = Updated) messages with the same timestamp.</td><td>Same as J02.FR.14</td></tr><tr><td>F02.FR.05</td><td>When the IdToken information is known.</td><td>The next TransactionRequest SHALL contain IdTokenType information.</td><td>Same as E03.FR.01</td></tr><tr><td>F02.FR.06</td><td>This transaction ends a reservation for the specific IdToken.</td><td>The next TransactionRequest SHALL contain the reservationId.</td><td>See H. Reservation.</td></tr><tr><td>F02.FR.07</td><td>When the EV Driver does not plug-in the charging cable before the timeout set by the Configuration Variable: EVConnectionTimeOut AND TxStopPoint does not contain ParkingBayOccupancy</td><td>The Charging Station SHALL end the transaction and send a TransactionRequest (eventType = Ended, stoppedReason = Timeout, triggerReason = EVConnectionTimeout) to the CSMS.</td><td>Otherwise the transaction would not be ended in case the TxStopPoint does not contain Authorized. Same as E03.FR.05</td></tr><tr><td>F02.FR.08</td><td>When the EV Driver does not plug-in the charging cable before the timeout set by the Configuration Variable: EVConnectionTimeOut AND TxStopPoint contains ParkingBayOccupancy</td><td>The Charging Station SHALL deauthorize the transaction and send a TransactionRequest (triggerReason = EVConnectionTimeout) to the CSMS.</td><td>Transaction will be ended normally when driver leaves the parking bay. Same as E03.FR.15</td></tr><tr><td>F02.FR.09</td><td>If the value of AuthorizationRemoteStart = true AND Charging Station receives a RequestStartTransactionRequest</td><td>The Charging Station SHALL behave as if in response to a local action at the Charging Station to start a transaction after successful authorization of the IdToken given in RequestStartTransactionRequest message.</td><td>Charging Station will first respond to the request and then try to authorize the IdToken, using the Local Authorization List, Authorization Cache and/or an AuthorizationRequest. A transaction is only started after authorization was obtained. Same as F01.FR.01</td></tr><tr><td>F02.FR.10</td><td>If the value of AuthorizationRemoteStart = false AND Charging Station receives a RequestStartTransactionRequest</td><td>The Charging Station SHALL start a transaction for the IdToken given in RequestStartTransactionRequest message without checking authorization.</td><td>Note that after the transaction has been started, the Charging Station will send a TransactionRequest with the idToken to the CSMS, and the CSMS will check the authorization status of the IdToken when processing this TransactionRequest. Same as F01.FR.02</td></tr><tr><td>F02.FR.11</td><td>F02.FR.09 OR F02.FR.10</td><td>The Charging Station SHALL send a TransactionRequest to the CSMS, and the CSMS will check the authorization status of the IdToken when processing this TransactionRequest.</td><td>Same as F01.FR.03</td></tr><tr><td>F02.FR.12</td><td></td><td>RequestStartTransactionRequest SHALL contain an IdToken, which Charging Station SHALL use, if it is able to start a transaction, in the TransactionRequest sent to the CSMS.</td><td>Same as F01.FR.04</td></tr><tr><td>F02.FR.13</td><td></td><td>The transaction SHALL be started in the same way as described in E03 - Start Transaction - Id Token First.</td><td></td></tr><tr><td>F02.FR.14</td><td></td><td>RequestStartTransactionRequest MAY contain an evsold if the transaction is to be started on a specific EVSE.</td><td>When no evsold is provided, the Charging Station is in control of the EVSE selection. Same as F01.FR.06</td></tr><tr><td>F02.FR.15</td><td>If the RequestStartTransactionRequest does not contain an evsold.</td><td>The Charging Station MAY reject the RequestStartTransactionRequest.</td><td>Same as F01.FR.07</td></tr><tr><td>F02.FR.16</td><td></td><td>The CSMS MAY include a ChargingProfile in the RequestStartTransactionRequest.</td><td>Same as F01.FR.08</td></tr><tr><td>F02.FR.17</td><td>F02.FR.16</td><td>The purpose of this ChargingProfile SHALL be set to TxProfile.</td><td>Same as F01.FR.09</td></tr><tr><td>F02.FR.18</td><td>F02.FR.16</td><td>The Charging Station SHALL use this ChargingProfile for the transaction that is started by this RequestStartTransaction.</td><td>Same as F01.FR.10</td></tr><tr><td>F02.FR.19</td><td>F02.FR.16</td><td>The transactionId in the ChargingProfile SHALL NOT be set.</td><td>Same as F01.FR.11</td></tr><tr><td>F02.FR.20</td><td>If a Charging Station without support for Smart Charging receives a RequestStartTransactionRequest with a ChargingProfile.</td><td>The Charging Station SHALL ignore the specified ChargingProfile.</td><td>The device model variable SmartChargingCtrl.Enabling tells CSMS whether smart charging is supported. Same as F01.FR.12</td></tr><tr><td>F02.FR.21</td><td>When a RequestStartTransactionRequest is received.</td><td>The next TransactionEventRequest SHALL contain triggerReason: RemoteStart and the remoteStartId from the RequestStartTransactionRequest.</td><td>This is to notify CSMS that this is the result of RequestStartTransaction. Note, that if TxStartPoint=EVCNNected the transaction will be started upon cable connection, but the triggerReason = RemoteStart must still be sent. The connection event is reported by the fact that chargingState = EVConnected.</td></tr><tr><td>F02.FR.22</td><td>If the RequestStartTransactionRequest does not contain an evseld AND the Charging Station is capable of selecting an EVSE</td><td>The Charging Station SHALL select an EVSE to be used as a value for evseld for the operation</td><td>See also F02.FR.15 if Charging Station does not support starting at an arbitrary EVSE. Same as F01.FR.20</td></tr><tr><td>F02.FR.23</td><td>When the evseld for RequestStartTransactionRequest is Reserved for an idToken that differs from idToken in the request AND has no reservation for a groupIdToken</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td>Same as F01.FR.21</td></tr><tr><td>F02.FR.24</td><td>When the evseld for RequestStartTransactionRequest is Reserved for an idToken that differs from idToken in the request AND is Reserved for a groupIdToken that differs from groupIdToken in the request</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td>EV is not allowed to use station if neither idToken nor idGroupToken match the reservation. Same as F01.FR.22</td></tr><tr><td>F02.FR.25</td><td>When the evseld for RequestStartTransactionRequest is Unavailable or Faulted</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td>Same as F01.FR.23</td></tr><tr><td>F02.FR.26</td><td>When the evseld for RequestStartTransactionRequest is Occupied AND this evseld has a transaction that has been authorized</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected.</td><td>Only an EVSE with no transaction or with a transaction that has not yet been authorized can be matched with the RequestStartTransaction Request. Same as F01.FR.24</td></tr><tr><td>F02.FR.27</td><td>If a Charging Station with support for Smart Charging receives a RequestStartTransactionRequest with an invalid ChargingProfile.</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected and optionally with reasonCode = "InvalidProfile" or "InvalidSchedule".</td><td>The device model variable SmartChargingCtrl.Enabling tells CSMS whether smart charging is supported. Same as F01.FR.26</td></tr></table>
+
+F03 - Remote Stop Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remote Stop Transaction</td></tr><tr><td>2</td><td>ID</td><td>F03</td></tr><tr><td>3</td><td>Objective(s)</td><td>1. To enable a CSO to help an EV Driver who has problems stopping a transaction. or
+2. Enable mobile apps to control transactions via the CSMS.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests the Charging Station to stop a transaction.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. An External Trigger triggers a remote stop.
+2. The CSMS requests a Charging Station to stop a transaction by sendingRequestStopTransactionRequest to the Charging Station with the transactionId of the transaction.
+3. The Charging Station responds with RequestStopTransactionResponse and a status indicating whether it has accepted the request and a transaction with the given transactionId is ongoing and will be stopped.
+4. Charging is stopped, the Charging Station sends TransactionEventRequest (eventType = Updated) and, if applicable, unlocks the Connector.
+5. After the EV Driver unplugs the cable, the Charging Station sendsNotifyEventRequest with component.name Connector, variable.name AvailabilityState and actualValue Available
+6. The Charging Station ends the transaction and sends a TransactionEventRequest (eventType = Ended, stoppedReason = Remote) message to the CSMS.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A transaction is ongoing.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The transaction for which a stop was request has ended.
+Failure postcondition:
+The transaction for which a stop was requested is still ongoing.</td></tr><tr><td>7</td><td>Remark(s)</td><td>This remote request to stop a transaction is equal to a local action to stop a transaction.
+The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.
+TxStopPoint: ParkingBayOccupancy, EVConnected
+This use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are send. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+
+Figure 81. Sequence Diagram: Remote Stop Transaction
+
+# F03 - Remote Stop Transaction - Requirements
+
+Table 79. F03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F03.FR.01</td><td>When the CSMS receives a remote stop transaction trigger (For example when terminating using a smartphone app, exceeding a (non local) prepaid credit.)</td><td>The CSMS SHALL send a RequestStopTransactionRequest to the Charging Station with the transactionId of the transaction.</td><td></td></tr><tr><td>F03.FR.02</td><td>F03.FR.01 AND TxStopPoint configuration does not cause transaction to end (E.g. TxStopPoint is NOT Authorized or PowerPathClosed)</td><td>The Charging Station SHALL stop the energy offer and send a TransactionEventRequest (eventType = Updated, triggerReason = RemoteStop) to the CSMS.</td><td>For example when TxStopPoint = EVConnected the transaction will not be ended until EV is disconnected.</td></tr><tr><td>F03.FR.03</td><td>F03.FR.01 AND TxStopPoint configuration causes transaction to end (E.g. TxStopPoint is Authorized or PowerPathClosed)</td><td>The Charging Station SHALL send a TransactionEventRequest (eventType = Ended, triggerReason = RemoteStop, stoppedReason = Remote) to the CSMS.</td><td></td></tr><tr><td>F03.FR.04</td><td>When configured to send meter data in the TransactionEventRequest (eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionEventRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td><td>Same as E08.FR.09</td></tr><tr><td>F03.FR.05</td><td>F03.FR.04 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data.</td><td>Same as E06.FR.12</td></tr><tr><td>F03.FR.06</td><td>F03.FR.05</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td><td>Same as E06.FR.13</td></tr></table>
+
+F04 - Remote Stop ISO 15118 Charging from CSMS
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F03.FR.07</td><td>When the Charging Station receives a RequestStopTransactionRequest</td><td>And the TransactionId can be matched to an active transaction; the Charging Station SHALL respond with a RequestStopTransactionResponse with status set to Accepted.</td><td></td></tr><tr><td>F03.FR.08</td><td>When the Charging Station receives a RequestStopTransactionRequest</td><td>And the TransactionId cannot be matched to an active transaction; the Charging Station SHALL respond with a RequestStopTransactionResponse with status set to Rejected.</td><td></td></tr><tr><td>F03.FR.09</td><td>When sending a TransactionEventRequest</td><td>The Charging Station SHALL set the triggerReason to inform the CSMS about what triggered the event. What reason to use is described in the description of TriggerReasonEnumType.</td><td>Same as E06.FR.15</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remote Stop ISO 15118 Charging from CSMS</td></tr><tr><td>2</td><td>ID</td><td>F04</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 F2 Charging loop with interrupt from the SECC.</td></tr><tr><td>3</td><td>Objective(s)</td><td>See ISO15118-1, use case Objective F2, page 38.</td></tr><tr><td>4</td><td>Description</td><td>See ISO15118-1, use case Description F2, page 38.</td></tr><tr><td></td><td>Actors</td><td>EV, CSMS, Charging Station</td></tr><tr><td></td><td>Combined scenario description</td><td>OCPP:1. The CSMS sends a RequestStopTransactionRequest to the Charging Station.2. The Charging Station responds with a RequestStopTransactionResponse.ISO 15118-2:3. The EV sends a ChargingStatus (in case of AC charging) or CurrentDemandReq (in case of DC Charging) PDU to the Charging Station.4. The Charging Station responds with an EVSENotification = StopCharging.ISO 15118-20:3. The EV sends a AC_ChargeLoopRes (in case of AC charging) or DC_ChargeLoopRes (in case of DC charging) PDU to the Charging Station.4. The Charging Station responds with an EVSENotification = Terminate.</td></tr><tr><td>5</td><td>Prerequisites</td><td>- If authorization according use cases in Functional Block C is applied, it SHALL be finished successfully.See ISO15118-1, use case Prerequisites F2, page 38.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>See ISO15118-1, use case End conditions F2, page 38.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 82. Charging loop with interrupt from the Charging Station
+
+# F04 - Remote Stop ISO 15118 Charging from CSMS - Requirements
+
+These requirements are normative.
+
+Table 80. F04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F04.FR.01</td><td>When the CSMS receives a remote stop transaction trigger (For example when terminating using a smartphone app, exceeding a (non local) prepaid credit.)</td><td>The CSMS SHALL send a RequestStopTransactionRequest to the Charging Station with the transactionId of the transaction.</td><td>Same as F03.FR.01</td></tr><tr><td>F04.FR.02</td><td>F04.FR.01</td><td>The Charging Station SHALL stop the energy offer, unlock the cable and send a TransactionRequest (eventType = Updated) to the CSMS.</td><td>Cable unlocked if not permanently attached. Same as F03.FR.02</td></tr><tr><td>F04.FR.03</td><td>F04.FR.02 AND When the EV Driver unplants the cable.</td><td>The Charging Station SHALL send a TransactionRequest (eventType = Ended, stoppedReason = Remote) to the CSMS.</td><td>Same as F03.FR.03</td></tr><tr><td>F04.FR.04</td><td>When configured to send meter data in the TransactionRequest (eventType = Ended), See: Meter Values - Configuration</td><td>The Charging Station SHALL add the configured measurands to the optional meterValue field in the TransactionRequest(eventType = Ended) sent to the CSMS to provide more details about transaction usage.</td><td>Same as E08.FR.09</td></tr><tr><td>F04.FR.05</td><td>F04.FR.04 AND The Charging Station is running low on memory</td><td>The Charging Station MAY drop meter data.</td><td>Same as E06.FR.12</td></tr><tr><td>F04.FR.06</td><td>F04.FR.05</td><td>When dropping meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the start of the list or stop adding values to the list.</td><td>Same as E06.FR.13</td></tr></table>
+
+# 2.2. Unlock Connector
+
+# F05 - Remotely Unlock Connector
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remotely Unlock Connector</td></tr><tr><td>2</td><td>ID</td><td>F05</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSO to help an EV-driver that has problems unplugging his charging cable because the locked failed after the transaction has ended.</td></tr><tr><td>4</td><td>Description</td><td>It sometimes happens that a connector of a Charging Station socket does not unlock correctly. This happens most of the time when there is tension on the charging cable. This means the driver cannot unplug his charging cable from the Charging Station. To help a driver, the CSO can send a UnlockConnectorRequest to the Charging Station. The Charging Station will then try to unlock the connector again.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, External Trigger</td></tr><tr><td></td><td>Scenario description</td><td>1. An External Trigger (probably the CSO) request the unlocking of a specific connector of a Charging Station.
+2. The CSMS sends an UnlockConnectorRequest to the Charging Station.
+3. Upon receipt of UnlockConnectorRequest, the Charging Station responds with UnlockConnectorResponse.
+4. The response message indicates whether the Charging Station was able to unlock its Connector.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>No ongoing transaction on the specified connector
+The Charging Station has a connector lock.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station was able to unlock the Connector.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>An external trigger, triggering the Unlock command, can be e.g. a Charging Station Operator or an EV Driver app.
+UnlockConnectorRequest is intended only for unlocking the cable retention lock on the Connector, not for unlocking a Connector access door.</td></tr></table>
+
+
+Figure 83. Sequence Diagram: Unlock Connector
+
+# F05 - Remotely Unlock Connector - Requirements
+
+Table 81. F05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>F05.FR.01</td><td>Upon receipt of an UnlockConnectorRequest.</td><td>The Charging Station SHALL respond with UnlockConnectorResponse.</td></tr><tr><td>F05.FR.02</td><td>F05.FR.01ANDThere is a authorized transaction ongoing on the specified connector.</td><td>The Charging Station SHALL NOT try to unlock the connector (or stop the transaction) but use the status: OngoingAuthorizedTransaction in the UnlockConnectorResponse.</td></tr><tr><td>F05.FR.03</td><td>F05.FR.01ANDSpecified connector unknown.</td><td>The Charging Station SHALL use the status: UnknownConnector in the UnlockConnectorResponse.</td></tr><tr><td>F05.FR.04</td><td>F05.FR.01ANDThe Charging Station was able to unlock the specified connector.</td><td>The Charging Station SHALL use the status: Unlocked in the UnlockConnectorResponse.</td></tr><tr><td>F05.FR.05</td><td>F05.FR.01ANDThe Charging Station was NOT able to unlock the specified connector.</td><td>The Charging Station SHALL use the status: UnlockFailed in the UnlockConnectorResponse.</td></tr><tr><td>F05.FR.06</td><td>F05.FR.01 ANDNo cable is connected to the connector.</td><td>The Charging Station SHALL attempt to unlock the connector, even if no cable is detected and SHALL return the result of the unlock attempt.</td></tr></table>
+
+# 2.3. Remote Trigger
+
+# F06 - Trigger Message
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Trigger Message</td></tr><tr><td>2</td><td>ID</td><td>F06</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to request a Charging Station to send a Charging Station-initiated message.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes the use of the TriggerMessageRequest message: how a CSMS can request a Charging Station to send Charging Station-initiated messages. In the request the CSMS indicates which message it wishes to receive.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a TriggerMessageRequest to the Charging Station.
+2. The Charging Station responds with a TriggerMessageResponse, indicating whether it will send it or not, by returning Accepted, Rejected or NotImplemented.
+3. Message, requested by the CSMS, that the Charging Station marked as Accepted, is being sent.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Functional Block Remote Trigger is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postconditions:
+1. The CSMS has Successfully received a TriggerMessageResponse message.
+2. The CSMS has Successfully received a TriggerMessageResponse message with status Accepted AND has Successfully received the requested message.
+Failure postconditions:
+1. The CSMS has NOT received a TriggerMessageResponse message.
+2. The CSMS has Successfully received a TriggerMessageResponse message with status Accepted AND has NOT received the requested message.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The TriggerMessage mechanism is not intended to retrieve historic data.</td></tr></table>
+
+
+Figure 84. Sequence Diagram: Trigger Message
+
+
+Figure 85. Sequence Diagram: Trigger Message Example
+
+# F06 - Trigger Message - Requirements
+
+Table 82. F06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F06.FR.01</td><td></td><td>In the TriggerMessageRequest message, the CSMS SHALL indicate which message(s) it wishes to receive.</td><td></td></tr><tr><td>F06.FR.02</td><td>F06.FR.01.For every such requested message.</td><td>The CSMS MAY indicate to which EVSE this request applies.</td><td></td></tr><tr><td>F06.FR.03</td><td>F06.FR.02</td><td>The requested message SHALL be leading. If the specified evseld is not relevant to the message, it SHALL be ignored. In such cases the requested message SHALL still be sent.</td><td></td></tr><tr><td>F06.FR.04</td><td>If a Charging Station receives a TriggerMessageRequest.</td><td>The Charging Station SHALL first send the TriggerMessage response, before sending the requested message.</td><td></td></tr><tr><td>F06.FR.05</td><td>F06.FR.04</td><td>In the TriggerMessageResponse the Charging Station SHALL indicate whether it will send the requested message or not, by returning Accepted or Rejected.</td><td>It is up to the Charging Station if it accepts or rejects the request to send.</td></tr><tr><td>F06.FR.06</td><td>If a Charging Station accepts a TriggerMessageRequest with requestedMessage set to: MeterValues</td><td>The Charging Station SHALL send a MeterValuesRequest to the CSMS with the most recent measurements for all measurands configured in Configuration Variable: AlignedDataMeasurands.</td><td></td></tr><tr><td>F06.FR.07</td><td>If a Charging Station accepts a TriggerMessageRequest with requestedMessage set to: TransactionEvent</td><td>The Charging Station SHALL send a TransactionEventRequest to the CSMS with triggerReason = Trigger, transactionInfo with at least the chargingState, and meterValue with the most recent measurements for all measurands configured in Configuration Variable: SampledDataTxUpdatedMeasurands.</td><td></td></tr><tr><td>F06.FR.08</td><td>When the Charging Station receives a TriggerMessageRequest with a requestedMessage that it has not implemented</td><td>The Charging Station SHALL respond with TriggerMessageResponse with status NotImplemented.</td><td></td></tr><tr><td>F06.FR.09</td><td></td><td>The messages it triggers SHALL only give current information.</td><td></td></tr><tr><td>F06.FR.10</td><td></td><td>Messages that the Charging Station marks as Accepted SHALL be sent.</td><td>E.g. the situation could occur that, between accepting the request and actually sending the requested message, that same message gets sent because of normal operations. In such cases the message just sent MAY be considered as complying with the request.</td></tr><tr><td>F06.FR.11</td><td>If the field evse is relevant but absent in the TriggerMessageRequest.</td><td>The Charging Station SHALL interpret this as "for all allowed evse values".</td><td>StatusNotifications can only be requested for a specific connector, see F06.FR.12/13</td></tr><tr><td>F06.FR.12</td><td>If a Charging Station receives a TriggerMessageRequest with requestedMessage set to: StatusNotification AND (evse is omitted OR evseconnectorId is omitted)</td><td>The Charging Station MAY respond with a TriggerMessageResponse with status Rejected.</td><td>StatusNotification messages can only be requested at connector level.</td></tr><tr><td>F06.FR.13</td><td>When sending a TriggerMessageRequest with requestedMessage set to: StatusNotification</td><td>The CSMS SHALL set the connectorId field</td><td>StatusNotification messages can only be sent at connector level.</td></tr><tr><td>F06.FR.14</td><td>If a Charging Station receives a TriggerMessageRequest with requestedMessage set to: LogStatusNotification AND The Charging Station is uploading a log file</td><td>The Charging Station SHALL send a LogStatusNotificationRequest to the CSMS with status Uploading.</td><td></td></tr><tr><td>F06.FR.15</td><td>If a Charging Station receives a TriggerMessageRequest with requestedMessage set to: LogStatusNotification AND The Charging Station is NOT uploading a log file</td><td>The Charging Station SHALL send a LogStatusNotificationRequest to the CSMS with status Idle.</td><td></td></tr><tr><td>F06.FR.16</td><td>If a Charging Station receives a TriggerMessageRequest with requestedMessage set to: FirmwareStatusNotification AND The Charging Station is not performing firmware update related tasks.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest to the CSMS with status Idle.</td><td></td></tr><tr><td>F06.FR.17</td><td>If Charging Station receives a TriggerMessageRequest with requestedMessage set to: BootNotification AND the response it received from CSMS to the last BootNotificationRequest was: Accepted</td><td>Charging Station SHALL respond with a TriggerMessageResponse with status Rejected.</td><td>A trigger to request a Charging Station to send a BootNotification is only meant to be used when the BootNotification has not yet been accepted.</td></tr><tr><td>F06.FR.18 (2.1)</td><td>If Charging Station receives a TriggerMessageRequest with requestedMessage = CustomTrigger AND Charging Station supports the message type in customTrigger</td><td>Charging Station SHALL reply with status = Accepted and send the message corresponding to customTrigger.</td><td>Supported custom triggers are reported in CustomTriggers.</td></tr><tr><td>F06.FR.19 (2.1)</td><td>If Charging Station receives a TriggerMessageRequest with requestedMessage = CustomTrigger AND Charging Station does not support the message type in customTrigger</td><td>Charging Station SHALL reply with TriggerMessageResponse with status = NotImplemented.</td><td></td></tr></table>
+
+# F07 - Remote start with fixed cost, energy, SoC or time
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remote start with fixed cost, energy, SoC or time</td></tr><tr><td>2</td><td>ID</td><td>F07</td></tr><tr><td>3</td><td>Objective(s)</td><td></td></tr><tr><td>4</td><td>Description</td><td>An EV Driver or CSMS specifies a limit in cost, energy, SoC or time. A cost limit is usually related to a prepaid balance or a reservation amount for adhoc payment. An energy or time limit can also be provided.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>CSMS specifies a cost limit at remote start
+1. CSMS has a cost limit for the transaction it wants to start on this Charging Station.
+2. CSMS sends a RequestStartTransactionRequest to the Charging Station.
+3. Charging Station starts a transaction as per use case F01 or F02.
+4. In order to communicate the cost limit to the Charging Station, CSMS adds the transactionLimit.maxCost element to the first TransactionEventResponse message for this transaction.
+5. Charging Station adds transactionInfo transactionLimit.maxCost (once) in the next TransactionEventRequest message.
+6. When the cost for energy transfer reaches transactionInfo transactionLimit.maxCost, Charging Station stops the energy transfer and sends a TransactionEventRequest with chargingState = SuspendedEVSE.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td></td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Charging Station starts a transaction with given limit(s).</td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>If more than one limit is given, for example both a time and an energy limit, then whichever limit is reached first, determines the end of energy transfer.
+In order for a Charging Station to stop exactly on time when a cost limit is given, cost will have to be calculated locally at the Charging Station.</td></tr></table>
+
+# NOTE
+
+Following diagrams only show parameters related to the use case. More parameters are required in these messages.
+
+
+Figure 86. Sequence diagram for remotely started transaction with limited cost
+
+# F07 - Remote start transactions with fixed cost, energy or time - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>F07.FR.01</td><td>CSMS wishes to start a transaction with a limit in cost, energy, SoC or time at Charging Station</td><td>CSMS SHALL send a RequestStartTransactionRequest message to Charging Station</td><td>The limit is sent in the TransactionEvent messages in accordance with E16.</td></tr><tr><td>F07.FR.02</td><td>F07.FR.01 AND Charging Station sends a TransactionEventRequest with eventType = Started</td><td>CSMS SHALL respond with a TransactionEventResponse with transactionLimit set to the required limit.</td><td>transactionLimit uses maxCost for cost limit, maxEnergy for energy limit, maxTime for time limit or maxSoC for SoC limit.</td></tr><tr><td>F07.FR.03</td><td>F07.FR.02</td><td>Charging Station SHALL include this limit in the field transactionInfo transactionLimit (once) in the next TransactionEventRequest</td><td></td></tr><tr><td>F07.FR.04</td><td></td><td>Charging Station SHALL behave as in use case E16 - Transactions with fixed cost, energy, SoC or time.</td><td></td></tr></table>
+
+# NOTE
+
+Other requirements from F. Remote Control also apply, notably F01 and F02, as well as E16 - Transactions with fixed cost, energy, SoC or time.
+
+# G. Availability
+
+# Chapter 1. Introduction
+
+This Functional Block specifies how the Charging Station can inform the CSMS of its current availability for starting new transactions.
+
+For the CSO it is important to know if a Charging Station is available for new EVs to be charged. The CSO wants to know this information so they can tell EV Drivers whether the Charging Station is available. To know this, the Charging Station should send any status changes of itself or one of its EVSEs to the CSMS. See for an example: B04 - Offline Behavior Idle Charging Station.
+
+For the CSO it is very helpful to know the status of the transaction, therefore the Charging Station can send detailed statuses to the CSMS. This can be very useful when helping an EV Driver when he experiences problems during charging.
+
+When a fault is detected by the Charging Station it can send a message notifying the CSMS about the fault.
+
+When the CSO wants the Charging Station to no longer start new transactions, it can change the availability. For example: they need to do maintenance on the Charging Station, and for this reason they don't want the Charging Station to be in use.
+
+The CSO can also change the availability for one or more EVSEs. For example: A customer calls, complaining about a broken EVSE on the Charging Station. The CSO can then set the Connector to unavailable, making it impossible for an EV Driver to use that Connector.
+
+Obviously, it is also possible to make the Charging Station or a Connector available again with a command from the CSMS.
+
+NOTE An overview of the Connectors Statuses can be found in: ConnectorStatusEnumType.
+
+# Chapter 2. Use cases & Requirements
+
+# G01 - Report connector AvailabilityState
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Report connector AvailabilityState</td></tr><tr><td>2</td><td>ID</td><td>G01</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS about a Connector status change.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers the functionality that a Charging Station sends a notification to the CSMS to inform the CSMS about a Connector status change.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. 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 evseconnectorId, and variable = "AvailabilityState" with the value of the new status to the CSMS.
+1a. Optionally, Charging Station can also include the state of component = "ChargingStation" and component = "EVSE" in the NotifyEventRequest.
+2. The CSMS responds with NotifyEventResponse to the Charging Station.</td></tr><tr><td></td><td>Alternative scenario</td><td>1. Instead of a NotifyEventRequest a Charging Station can still choose to send the previously used StatusNotificationRequest to the CSMS to inform the CSMS about the new connector status.
+2. The CSMS responds with StatusNotificationResponse to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postconditions:
+The CSMS is Successfully informed about the status change.
+Failure postconditions:
+n/a</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The Charging Station MAY use the Unavailable status internally for other purposes (e.g. while updating firmware or waiting for an initial Accepted RegistrationStatus). When one of the connectors on an EVSE is Reserved/Occupied, the CSMS has to take care of the status of the other connectors when presenting availability information to another system or user. The CSMS knows which connectors belong to the same EVSE.
+Notifying a connector status from Charging Station to CSMS via NotifyEventRequest is the preferred method. The old StatusNotificationRequest message is still available for use, but has been deprecated and will be removed in a future release.</td></tr></table>
+
+# Charging Station
+
+# CSMS
+
+NotifyEventRequestcomponent $=$ {name $=$ "Connector",evse $=$ {id $= 2$ ,connectorId $= 1\}\} ,$ variable $=$ {name $=$ "AvailabilityState"},actualValue $=$ "Occupied",trigger $=$ "Delta")
+
+NotifyEventResponse()
+
+Figure 87. Sequence Diagram: Report connector AvailabilityState
+
+# G01 - Report connector AvailabilityState - State transition overview for connecting/disconnecting
+
+<table><tr><td>Initial</td><td>Cable plugin</td><td>Cable unplug</td></tr><tr><td>Available</td><td>→ Occupied</td><td>-</td></tr><tr><td>Occupied</td><td>-</td><td>→ Available
+(→ Unavailable, if scheduled to become Unavailable)</td></tr><tr><td>Reserved</td><td>-</td><td>-</td></tr><tr><td>Unavailable</td><td>-</td><td>-</td></tr><tr><td>Faulted</td><td>-</td><td>-</td></tr></table>
+
+# NOTE
+
+In the table below the text: for component = "Connector"
+
+should be read as a shorthand notation for:
+
+for component.name = "Connector", component.evse.id = <evse id>, component.evseconnectorld = <connector id>
+
+# G01 - Report connector AvailabilityState - Requirements
+
+Table 83. G01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>G01.FR.01</td><td></td><td>A Charging Station Connector MUST have one of the valid statuses from the ConnectorStatus enumeration.</td></tr><tr><td>G01.FR.02</td><td>When an EVSE is set to status Unavailable by a ChangeAvailabilityRequest message.</td><td>The EVSE's Unavailable status SHALL be persistent across reboots.</td></tr><tr><td>G01.FR.03</td><td>The connector is Available when an EV is connecting</td><td>The Charging Station SHALL send a NotifyEventRequest for component = "Connector", variable = "AvailabilityState", actualValue = "Occupied" and trigger = "Delta" or a StatusNotificationRequest with connectorStatus = Occupied.</td></tr><tr><td>G01.FR.04</td><td>The connector is Occupied when an EV is disconnecting AND connector is not scheduled to become Unavailable (G03.FR.05)</td><td>The Charging Station SHALL send a NotifyEventRequest for component = "Connector", variable = "AvailabilityState", actualValue = "Available" and trigger = "Delta" when an EV is disconnected or a StatusNotificationRequest with connectorStatus = Available.</td></tr><tr><td>G01.FR.05</td><td>The connector is Occupied when an EV is disconnecting AND connector is scheduled to become Unavailable (G03.FR.05)</td><td>The Charging Station SHALL send a NotifyEventRequest for component = "Connector", variable = "AvailabilityState", actualValue = "Unavailable" and trigger = "Delta" when an EV is disconnected or a StatusNotificationRequest with connectorStatus = Unavailable.</td></tr><tr><td>G01.FR.06</td><td>The connector is Reserved when an EV is connecting AND EV driver presents an IdToken matching the reservation</td><td>The Charging Station SHALL send a NotifyEventRequest for component = "Connector", variable = "AvailabilityState", actualValue = "Occupied" and trigger = "Delta" or a StatusNotificationRequest with connectorStatus = Occupied.</td></tr><tr><td>G01.FR.07</td><td>When a ChangeAvailabilityRequest leads to a connector status change</td><td>The Charging Station SHALL send a NotifyEventRequest for component = "Connector", variable = "AvailabilityState", trigger = "Delta" and the corresponding actualValue of "AvailabilityState" or a StatusNotificationRequest with the corresponding connectorStatus.</td></tr><tr><td>G01.FR.08</td><td>When a cable is plugged in to a connector of an EVSE AND the EVSE has multiple connectors</td><td>The Charging Station SHOULD NOT send a NotifyEventRequest or StatusNotificationRequest for the other connector(s), even though they are no longer usable.</td></tr><tr><td>G01.FR.09</td><td>The connector is Reserved when an EV is connecting AND (No IdToken is presented OR EV driver presents an IdToken not matching the reservation)</td><td>Connector status SHALL NOT change.</td></tr></table>
+
+G02 - Heartbeat
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Heartbeat</td></tr><tr><td>2</td><td>ID</td><td>G02</td></tr><tr><td>3</td><td>Objective(s)</td><td>To let the CSMS know that a Charging Station is still connected, optionally the Heartbeat can be used for time synchronisation.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes a way to let the CSMS know the Charging Station is still connected, a Charging Station sends a heartbeat after a configurable time interval. Depending on the configuration the Heartbeat can be used for time synchronisation.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. If there is no activity for a certain time, the Charging Station sends HeartbeatRequest for ensuring that the CSMS knows that a Charging Station is still alive.
+2. Upon receipt of HeartbeatRequest, the CSMS responds with HeartbeatResponse. The response message contains the current time of the CSMS, which the Charging Station MAY use to synchronize its internal clock.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The heartbeat interval is set.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postconditions::The CSMS knows the Charging Station is still connected.
+Failure postconditions:The CSMS concludes that the Charging Station is Offline.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>With JSON over WebSocket, sending heartbeats is not instrumental to keeping web sockets alive, since web sockets already provide a mechanism for this. However, if the Charging Station uses the heartbeat for time synchronization, it is advised to at least send one heartbeat per 24 hours.</td></tr></table>
+
+
+Figure 88. Sequence Diagram: Heartbeat
+
+# G02 - Heartbeat - Requirements
+
+Table 84. G02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>G02.FR.01</td><td>When the CSMS responds with BootNotificationResponse with a status Accepted.</td><td>The Charging Station SHALL adjust the heartbeat interval in accordance with the interval from the response message.</td><td></td></tr><tr><td>G02.FR.02</td><td></td><td>The Charging Station SHALL send HeartbeatRequest after a configurable time interval.</td><td>To ensure that the CSMS knows that a Charging Station is still alive.</td></tr><tr><td>G02.FR.03</td><td></td><td>The HeartbeatResponse message SHALL contain the current time of the CSMS.</td><td></td></tr><tr><td>G02.FR.04</td><td>Whenever a message from a Charging Station has been received.</td><td>The CSMS SHALL assume availability of that Charging Station.</td><td></td></tr><tr><td>G02.FR.05</td><td></td><td>It is RECOMMENDED that the Charging Station resets its heartbeat interval timer when another message has been sent to the CSMS.</td><td></td></tr><tr><td>G02.FR.06</td><td>When the Charging Station receives a HeartbeatResponse.</td><td>It is RECOMMENDED that the Charging Station uses the current time to synchronize its internal clock.</td><td></td></tr><tr><td>G02.FR.07</td><td>When the heartbeat interval timer is continuously reset because of continuous sending of messages AND HeartbeatRequest is used for time synchronisation</td><td>It is RECOMMENDED that the Charging Station sends a HeartbeatRequest at least once every 24 hours to synchronise the clock.</td><td></td></tr></table>
+
+# G03 - Change Availability EVSE/Connector
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Change Availability EVSE/Connector</td></tr><tr><td>2</td><td>ID</td><td>G03</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to change the availability of an EVSE or Connector to Operative or Inoperative .</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS requests the Charging Station to change the availability of one of the EVSEs or Connectors to Operative or Inoperative. An EVSE/Connector is considered Operative in any status other than Faulted and Unavailable.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends ChangeAvailabilityRequest requesting a Charging Station to change the availability of an EVSE or Connector.
+2. The Charging Station changes the availability to the EVSE/Connector to the requested operationalStatus from the ChangeAvailabilityRequest.
+3. Upon receipt of ChangeAvailabilityRequest, the Charging Station responds with ChangeAvailabilityResponse. In case that the status 'Scheduled' is reported in the ChangeAvailabilityResponse, a transaction was running and this will be finished first.
+4. The Charging Station reports the status of the EVSE/Connector using a NotifyEventRequest.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>G04 - Change Availability Charging Station</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+When changing the availability of an EVSE/Connector to Operative, the status of the EVSE has changed to Available, Occupied or Reserved.
+When changing the availability of an EVSE/Connector to Inoperative, the status of the EVSE has changed to Unavailable.
+Failure postcondition:
+The status of the EVSE is as it was just before the Charging Station received ChangeAvailabilityRequest and not according to the requested Availability.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Persistent states, for example:
+EVSE set to Available SHALL persist a reboot.</td></tr></table>
+
+
+Figure 89. Sequence Diagram: Change Availability
+
+# G03 - Change Availability EVSE - Requirements
+
+Table 85. G03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>G03.FR.01</td><td>Upon receipt of ChangeAvailabilityRequest.</td><td>The Charging Station SHALL respond with ChangeAvailabilityResponse.</td><td></td></tr><tr><td>G03.FR.02</td><td>G03.FR.01</td><td>This response message SHALL indicate whether the Charging Station is able to change to the requested availability.</td><td></td></tr><tr><td>G03.FR.03</td><td>In the event that CSMS requests the Charging Station to change an EVSE or Connector to the state it is already in.</td><td>The Charging Station SHALL respond with availability status Accepted.</td><td></td></tr><tr><td>G03.FR.04</td><td>When an availability change request with ChangeAvailabilityRequest has changed the state of a Connector.</td><td>The Charging Station SHALL inform the CSMS of its new Connector availability status with StatusNotificationRequest or NotifyEventRequest.</td><td>As described in ChangeAvailabilityStatus EnumType</td></tr><tr><td>G03.FR.05</td><td>When a transaction is in progress AND NOT G03.FR.03</td><td>The Charging Station SHALL respond with availability status Scheduled to indicate that it is scheduled to occur after the transaction has finished.</td><td></td></tr><tr><td>G03.FR.06</td><td>When the availability of an EVSE becomes Inoperative (Unavailable, Faulted)</td><td>All operative connectors (i.e. not Faulted) of that EVSE SHALL become Unavailable.</td><td></td></tr><tr><td>G03.FR.07</td><td>When the availability of an EVSE becomes Operative</td><td>The Charging Station SHALL revert the status of all connectors of that EVSE to their original status.</td><td>See Note 1.</td></tr><tr><td>G03.FR.08</td><td>When the availability of an EVSE or Connector has been set explicitly via ChangeAvailabilityRequest</td><td>The set availability state SHALL be persistent across reboot/power loss.</td><td></td></tr></table>
+
+# NOTE
+
+1. The Charging Station, EVSEs and Connectors have separate / individual states. This means (for example) that when setting a connector to Inoperative, then setting the connected EVSE to Inoperative and thereafter change the EVSE back to operative, the connector will remain Inoperative.
+
+# NOTE
+
+2. It is only required to report a status change of a connector. StatusNotificationRequest only supports the reporting of connector statuses.
+
+# G04 - Change Availability Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Change Availability Charging Station</td></tr><tr><td>2</td><td>ID</td><td>G04</td></tr><tr><td></td><td>Parent use case</td><td>G03 - Change Availability EVSE/Connector</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to change the availability of a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests the Charging Station to change the availability.A Charging Station is considered Operative when it is charging or ready for charging.A Charging Station is considered Inoperative when it does not allow any charging.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a ChangeAvailabilityRequest for requesting a Charging Station to change its availability.2. Upon receipt of a ChangeAvailabilityRequest, the Charging Station responds with ChangeAvailabilityResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The CSMS was able to change the availability of the Charging Station.When changing the availability of a Charging Station to Operative, the status of the Charging Station has changed to Available.When changing the availability of a Charging Station to Inoperative, the status of the Charging Station has changed to Unavailable.Failure postcondition:The CSMS was not able to change the requested Charging Station's availability.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Persistent states: for example, Charging Station set to Unavailable SHALL persist a reboot.</td></tr></table>
+
+
+Figure 90. Sequence Diagram: Change Availability Charging Station
+
+# G04 - Change Availability Charging Station - Requirements
+
+Table 86. G04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>G04.FR.01</td><td>In the case the evse field is omitted in ChangeAvailabilityRequest.</td><td>The Charging Station status change SHALL apply to the whole Charging Station.</td><td></td></tr><tr><td>G04.FR.02</td><td>Upon receipt of ChangeAvailabilityRequest.</td><td>The Charging Station SHALL respond with ChangeAvailabilityResponse.</td><td></td></tr><tr><td>G04.FR.03</td><td>G04.FR.02</td><td>This response message SHALL indicate whether the Charging Station is able to change to the requested availability.</td><td></td></tr><tr><td>G04.FR.04</td><td>In the event that CSMS requests the Charging Station to change to the state it is already in.</td><td>The Charging Station SHALL respond with availability status Accepted.</td><td></td></tr><tr><td>G04.FR.05</td><td>When an availability change request with ChangeAvailabilityRequest has happened.</td><td>The Charging Station SHALL inform the CSMS by sending the status of each of the changed connectors via a NotifyEventRequest or a StatusNotificationRequest.</td><td>As described in ConnectorStatusEnumType</td></tr><tr><td>G04.FR.06</td><td>When a transaction is in progress.</td><td>The Charging Station SHALL respond with availability status Scheduled to indicate that it is scheduled to occur after the transaction has finished.</td><td></td></tr><tr><td>G04.FR.07</td><td>When the availability of the Charging Station becomes Inoperative (Unavailable, Faulted)</td><td>All operative EVSEs and connectors (i.e. not Faulted) SHALL become Unavailable.</td><td></td></tr><tr><td>G04.FR.08</td><td>When the availability of the Charging Station becomes Operative</td><td>The Charging Station SHALL revert the status of all EVSEs and connectors to their original status.</td><td>See Note 1.</td></tr><tr><td>G04.FR.09</td><td>When the availability of a Charging Station has been set explicitly via ChangeAvailabilityRequest</td><td>The set availability state SHALL be persistent across reboot/power loss.</td><td></td></tr></table>
+
+# NOTE
+
+1. The Charging Station, EVSEs and Connectors have separate / individual states. This means (for example) that when setting a connector to Inoperative, then setting the connected EVSE to Inoperative and thereafter change the EVSE back to operative, the connector will remain Inoperative.
+
+# NOTE
+
+2. It is only required to report a status change of a connector. StatusNotificationRequest only supports the reporting of connector statuses.
+
+G05 - Lock Failure
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Lock Failure</td></tr><tr><td>2</td><td>ID</td><td>G05</td></tr><tr><td>3</td><td>Objective(s)</td><td>To prevent the EV Driver from charging because the Connector is not properly locked.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the EV Driver is prevented from starting a charge session at the Charging Station because the Connector is not locked properly.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver is authorized by the Charging Station and/or CSMS.
+2. The lock Connector attempt fails.
+3. A NotifyEventRequest for the ConnectorPlugRetentionLock component, variable = Problem, value = true.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Cable plugged in (status = Occupied)
+Charging Station has the ConnectorPlugRetentionLock component defined in its Device Model.
+MonitoringLevel is set to a level that a connector lock event failure will be reported.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Transaction is not started and connector lock event failure is reported.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>It is advisable to provide some sort of notification to the EV Driver ("cable cannot be locked"). A lock failure can also be reported when unlocking of the connector fails.</td></tr></table>
+
+
+Figure 91. Sequence Diagram: Lock Failure
+
+# G05 - Lock Failure - Requirements
+
+Table 87. G05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>G05.FR.01</td><td>If the locking of the connector retention lock fails.</td><td>The Charging Station SHALL NOT start charging.</td><td></td></tr><tr><td>G05.FR.02</td><td>G05.FR.01</td><td>The Charging Station SHALL send a NotifyEventRequest to the CSMS for the ConnectorPlugRetentionLock component with variable = Problem, Value = True.</td><td></td></tr><tr><td>G05.FR.03</td><td>G05.FR.02</td><td>The CSMS SHALL respond with a NotifyEventResponse.</td><td></td></tr><tr><td>G05.FR.04</td><td>G05.FR.01</td><td>The Charging Station MAY show an optional notification to the EV Driver.</td><td>To notify the EV driver of the lock failure.</td></tr></table>
+
+# H. Reservation
+
+# Chapter 1. Introduction
+
+This Functional Block describes the reservation functionality of OCPP. The reservation functionality enables an EV Driver to reserve an EVSE at a Charging Station until a certain time in order to ensure that this EVSE cannot be occupied by another user.
+
+OCPP allows to reserve a specific EVSE at a Charging Station or a specific connector type. The EV Driver can also reserve an unspecified EVSE, in which case the Charging Station will make sure that at least one EVSE remains available for the EV Driver.
+
+Only available EVSEs can be reserved, since a Charging Station cannot know in advance when an occupied EVSE will become available again. This makes it impossible to guarantee a reservation for an EVSE that is currently occupied.
+
+# NOTE
+
+A CSMS would still be able to support the reservation functionality for occupied EVSEs by delaying the sending of the reservation message to the Charging Station until the EVSE becomes available, but there is no guarantee that it is available in time.
+
+# Chapter 2. Use cases & Requirements
+
+# H01 - Reservation
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reservation</td></tr><tr><td>2</td><td>ID</td><td>H01</td></tr><tr><td>3</td><td>Objective(s)</td><td>To ensure the EV Driver can charge his EV at a Charging Station, the EV Driver can make a reservation until a certain expiry time.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a Charging Station can be reserved for a specific IdTokenType.</td></tr><tr><td>5</td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td>S1</td><td>Scenario objective</td><td>Reserve an unspecified EVSE at a Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver asks the CSMS to reserve an unspecified EVSE at the Charging Station.
+2. The CSMS sends ReserveNowRequest without evseld to a Charging Station.
+3. Upon receipt of ReserveNowRequest, the Charging Station responds with ReserveNowResponse with status Accepted.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>The Charging Station has at least one available EVSE</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station has accepted the ReserveNowRequest
+Failure postcondition:
+The Charging Station has rejected the ReserveNowRequest</td></tr></table>
+
+
+Figure 92. Sequence Diagram: S1 - Reserve a unspecified EVSE at a Charging Station
+
+<table><tr><td>S2</td><td>Scenario objective</td><td>Reserve a specific EVSE at a Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>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 a NotifyEventRequest with trigger = Delta for component.name = "Connector" and the EVSE number in evse.id and the connector number in evseconnectorId, variable = "AvailabilityState" and actualValue = "Reserved".</td></tr><tr><td></td><td>Alternative scenario</td><td>Steps 1, 2 and 3 as above.
+4. Instead of a NotifyEventRequest a Charging Station can still send the old StatusNotificationRequest with the status Reserved for all Connectors of that EVSE.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>The specified EVSE of the Charging Station has status Available</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station has accepted the ReserveNowRequest
+AND
+sent NotifyEventRequest with component.name Connector, variable.name AvailabilityState and actualValue Reserved
+Failure postcondition:
+The Charging Station has rejected the ReserveNowRequest
+OR
+The Charging Station has NOT sent NotifyEventRequest with component.name Connector, variable.name AvailabilityState and actualValue Reserved</td></tr></table>
+
+
+Figure 93. Sequence Diagram: S2 - Reserve a specified EVSE at a Charging Station
+
+<table><tr><td>S3</td><td>Scenario objective</td><td>Reserve a connector type at a Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver asks the CSMS to reserve a connector type at the Charging Station.
+2. The CSMS sends ReserveNowRequest with a connector type to a Charging Station.
+3. Upon receipt of ReserveNowRequest, the Charging Station responds with ReserveNowResponse with status Accepted.</td></tr><tr><td></td><td>Prerequisite(s)</td><td>The Charging Station has at least one available EVSE with the specified connector type</td></tr><tr><td></td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station has accepted the ReserveNowRequest
+Failure postcondition:
+The Charging Station has rejected the ReserveNowRequest</td></tr></table>
+
+
+Figure 94. Sequence Diagram: S3 - Reserve a connector type at a Charging Station
+
+<table><tr><td>6</td><td>Error handling</td><td></td></tr><tr><td>7</td><td>Remark(s)</td><td>It is RECOMMENDED to validate the Identifier with anauthorizeRequest after reception of ReserveNowRequest and before the start of the transaction.</td></tr></table>
+
+# H01 - Reservation - Requirements
+
+Table 88. H01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>H01.FR.01</td><td>If the Charging Station is configured not to accept reservations.</td><td>The Charging Station SHALL return Rejected.</td><td></td></tr><tr><td>H01.FR.02</td><td>If the id in the ReserveNowRequest matches a reservation in the Charging Station.</td><td>The Charging Station SHALL replace that reservation with the new reservation in the request.</td><td></td></tr><tr><td>H01.FR.03</td><td>If the id in the ReserveNowRequest does not match any reservation in the Charging Station.</td><td>The Charging Station SHALL return the status value Accepted if it succeeds in reserving an EVSE.</td><td></td></tr><tr><td>H01.FR.04</td><td>If the Charging Station receives a ReserveNowRequest without evseld AND at least one EVSE is Available AND H01.FR.18</td><td>The Charging Station SHALL accept the reservation AND respond with a ReserveNowResponse with status Accepted.</td><td></td></tr><tr><td>H01.FR.06</td><td>If the Charging Station receives a ReserveNowRequest with a connector type AND at least one EVSE with the specified connector type is Available AND H01.FR.18</td><td>The Charging Station SHALL accept the reservation AND respond with a ReserveNowResponse with status Accepted.</td><td></td></tr><tr><td>H01.FR.07</td><td>When the Charging Station has Accepted a ReserveNowRequest without evseld</td><td>The Charging Station SHALL make sure that at any time during the validity of the reservation, one EVSE remains available for the reserved IdTokenType.</td><td></td></tr><tr><td>H01.FR.09</td><td>When the Charging Station has Accepted a ReserveNowRequest with a connector type</td><td>The Charging Station SHALL make sure that at any time during the validity of the reservation, one Connector with the specified type remains available for the reserved IdTokenType.</td><td></td></tr><tr><td>H01.FR.11</td><td>When receiving a ReserveNowRequest AND (all) targeted EVSEs have status Reserved or Occupied</td><td>The Charging Station SHALL return Occupied.</td><td></td></tr><tr><td>H01.FR.12</td><td>When receiving a ReserveNowRequest AND (all) targeted EVSEs have status Faulted</td><td>The Charging Station SHALL return Faulted.</td><td></td></tr><tr><td>H01.FR.14</td><td>When receiving a ReserveNowRequest AND (all) targeted EVSEs have status Unavailable</td><td>The Charging Station SHALL return Unavailable.</td><td></td></tr><tr><td>H01.FR.15</td><td>If a transaction for the reserved IdTokenType is started.</td><td>The Charging Station SHALL send the reservationId in a TransactionRequest.</td><td>To notify the CSMS that the reservation is terminated. See E. Transactions.</td></tr><tr><td>H01.FR.16</td><td>When the status of a targeted EVSE changes to Faulted</td><td>The Charging Station SHALL cancel the reservation AND send a ReservationStatusUpdate with status Removed.</td><td></td></tr><tr><td>H01.FR.17</td><td>When the status of a targeted EVSE changes to Unavailable</td><td>The Charging Station SHALL cancel the reservation AND send a ReservationStatusUpdate with status Removed.</td><td></td></tr><tr><td>H01.FR.18</td><td>If the Configuration Variable: ReservationNonEvseSpecific is set to true.</td><td>The Charging Station SHALL accept reservations on an unspecified EVSE.</td><td></td></tr><tr><td>H01.FR.19</td><td>If the Configuration Variable: ReservationNonEvseSpecific is not set or set to false.</td><td>The Charging Station SHALL reject reservations on an unspecified EVSE.</td><td></td></tr><tr><td>H01.FR.20</td><td>H01.FR.04 AND amount of EVSEs available equals the amount of reservations</td><td>The Charging Station SHALL send for all connectors of the EVSE: - a NotifyEventRequest with component = "Connector", variable = "AvailabilityState", trigger = "Delta", actualValue = "Reserved", OR - a StatusNotificationRequest with connectorStatus = Reserved.</td><td>If an EVSE is reserved, all of its connectors are reported as reserved.</td></tr><tr><td>H01.FR.23</td><td>If the Charging Station receives a ReserveNowRequest for evseld AND this EVSE is Available</td><td>The Charging Station SHALL respond with a ReserveNowResponse with status Accepted AND SHALL send for all connectors of the EVSE: - a NotifyEventRequest with component = "Connector", variable = "AvailabilityState", trigger = "Delta", actualValue = "Reserved" OR - a StatusNotificationRequest with connectorStatus = Reserved.</td><td>If an EVSE is reserved, all of its connectors are reported as reserved.</td></tr><tr><td>H01.FR.24</td><td>H01.FR.06 AND amount of reservations for a specific connectorType equals the amount of available EVSEs with that specific connectorType</td><td>The Charging Station SHALL send for all connectors of the EVSEs that have the specific connectorType - a NotifyEventRequest with component = "Connector", variable = "AvailabilityState", trigger = "Delta", actualValue = "Reserved" OR - a StatusNotificationRequest with connectorStatus = Reserved.</td><td>If an EVSE is reserved for a specific connectorType, all connectors on the EVSE are reported as reserved.</td></tr></table>
+
+H02 - Cancel Reservation
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Cancel Reservation</td></tr><tr><td>2</td><td>ID</td><td>H02</td></tr><tr><td>3</td><td>Objective(s)</td><td>To cancel a reservation on a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how an EV Driver can cancel an existing reservation. The CSMS can cancel the reservation the EV Driver has on a Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver asks the CSMS to cancel a reservation.
+2. To cancel a reservation, the CSMS sends CancelReservationRequest to the Charging Station.
+3. If the Charging Station has a reservation matching the reservationId in the request PDU, it returns the status Accepted.
+4. If a specific EVSE was reserved for this reservation, the Charging Station sends a NotifyEventRequest with variable "AvailabilityState" set to "Available" for all the Connectors of that EVSE.
+5. The CSMS responds with a NotifyEventResponse to the Charging Station.
+6. The reservation is canceled.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>- The Functional Block Reservation is installed.
+- EV Driver has a reservation at the Charging Station.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The CSMS was able to cancel the EV Driver's reservation at the Charging Stations.
+Failure postcondition:
+n/a.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The Charging Station does not send a ReservationStatusUpdate, because it was explicitly canceled by CSMS, so it is already aware of the event.
+Use of StatusNotificationRequest instead of NotifyEventRequest is deprecated, but still allowed.</td></tr></table>
+
+
+Figure 95. Sequence Diagram: Cancel Reservation
+
+# H02 - Cancel Reservation - Requirements
+
+Table 89. H02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>H02.FR.01</td><td>The Charging Station has received a CancelReservationRequest and no matching reservationId.</td><td>The Charging Station SHALL return Rejected.</td></tr><tr><td>H02.FR.02</td><td>If a Charging Station receives a CancelReservationRequest with a valid, known reservationId.</td><td>The reservation SHALL be canceled.</td></tr></table>
+
+H03 - Use a reserved EVSE
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Use a reserved EVSE</td></tr><tr><td>2</td><td>ID</td><td>H03</td></tr><tr><td>3</td><td>Objective(s)</td><td>Use a reserved EVSE</td></tr><tr><td>4</td><td>Description</td><td>This use cases covers how a reserved EVSE can be used based on IdToken and GroupIdToken information.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td>S1</td><td>Scenario objective</td><td>Use an EVSE with connector status Reserved, that is reserved for this IdToken</td></tr><tr><td></td><td>Scenario description</td><td>TxStartPoint = "Authorized"; IdToken presented first
+1. The EV Driver presents an IdTokenType at the Charging Station that is the same as the reservation's IdTokenType.
+2. Charging Station matches IdTokenType with the reservation.
+3. Connector status becomes Available, since reservation has now been consumed.
+4. Charging Station optionally authorizes the IdTokenType via anauthorizeRequest.
+5. If authorization accepted, or authorization step was skipped:
+a. Charging Station starts a transaction as in E03 - Start Transaction - IdToken First.
+b. Connector status will become Occupied when cable is connected.</td></tr><tr><td></td><td>Scenario description #2</td><td>TxStartPoint = "EVConnected"; Cable plugged in first
+1. The EV Driver connects the cable.
+2. Charging Station starts a transaction, but EVSE connector status remains Reserved.
+3. The EV Driver presents an IdTokenType at the Charging Station that is the same as the reservation's IdTokenType
+4. Charging Station matches IdTokenType with the reservation
+5. Connector status becomes Occupied, since reservation has now been consumed
+6. Charging Station optionally authorizes the IdTokenType via anauthorizeRequest
+7. If authorization accepted, or authorization step was skipped:
+a. Charging Station starts a transaction as in E02 - Start Transaction - Cable Plugin First</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>EVSE has been reserved for IdToken and connector status is Reserved.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr></table>
+
+
+Figure 96. Sequence Diagram: Use a reserved EVSE with IdToken
+
+<table><tr><td>S2</td><td>Scenario objective</td><td>Use an EVSE with connector status Reserved, that is reserved for this GroupIdToken</td></tr><tr><td></td><td>Scenario description</td><td>TxStartPoint = "Authorized"; IdToken presented first
+1. The EV Driver presents an IdTokenType at the Charging Station that is not the same as the reservation's IdTokenType, but the reservation contains a groupIdToken.
+2. Charging Station authorizes the IdTokenType via anauthorizeRequest, Local Authorization List or Authorization Cache, and checks if the groupIdToken of the IdTokenType matches with the reservation.
+3. If groupIdTokens match:
+a. Connector status becomes Available, since reservation has now been consumed.
+b. Charging Station starts a transaction as in E03 - Start Transaction - IdToken First
+c. Connector status will become Occupied when cable is connected</td></tr><tr><td></td><td>Scenario description #2</td><td>TxStartPoint = "EVConnected", Cable plugged in first
+1. The EV Driver connects the cable.
+2. Charging Station starts a transaction, but connector status remains Reserved.
+3. The EV Driver presents an IdTokenType at the Charging Station that is not the same as the reservation's IdTokenType, but the reservation contains a groupIdToken.
+4. Charging Station authorizes the IdTokenType via anauthorizeRequest, Local Authorization List or Authorization Cache, and checks if the groupIdToken of the IdTokenType matches with the reservation.
+5. If groupIdTokens match:
+a. Connector status becomes Occupied, since reservation has now been consumed.
+b. Charging Station starts a transaction as in E02 - Start Transaction - Cable Plugin First</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>EVSE has been reserved for GroupIdToken. EVSE connectorStatus = Reserved.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr></table>
+
+
+Figure 97. Sequence Diagram: Use a reserved EVSE with GroupId
+
+<table><tr><td>S3</td><td>Scenario objective</td><td>Use an EVSE when Charging Station has a reservation for idToken, but connector status is Available. This happens when reservation is for an unspecified EVSE and multiple EVSEs are available.</td></tr><tr><td></td><td>Scenario description</td><td>TxStartPoint = "Authorized"; IdToken presented first Identical to scenario S1 above.</td></tr><tr><td></td><td>Scenario description #2</td><td>TxStartPoint = "EVConnected"; Cable plugged in first1. The EV Driver connects the cable2. Charging Station reports connector status as Occupied3. Charging Station starts a transaction4. The EV Driver presents an IdTokenType at the Charging Station that is the same as the reservation's IdTokenType5. Charging Station matches IdTokenType with the reservation6. Charging Station optionally authorizes the IdTokenType via an Request7. If authorization accepted, or authorization step was skipped:a. Charging Station starts a transaction as in E02 - Start Transaction - Cable Plugin First</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Unspecified EVSE has been reserved for idToken. EVSE connector status is Available.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr></table>
+
+<table><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>It is RECOMMENDED to validate the Identifier with an InvalidateRequest after reception of ReserveNowRequest and before the start of the transaction.
+If an idToken is presented that does not match the reservation (and groupldTokens do not match either), then this idToken is not authorized to charge.
+If TxStartPoint = Authorized or PowerPathClosed then a transaction would not be started in this case.
+If TxStartPoint = EVConnected or ParkingBayOccupancy then a transaction would be started by cable plug-in or occupancy of parking bay, but charging would not start. Assuming a TxStopPoint of EVConnected the transaction would be ended at cable plug-out.</td></tr></table>
+
+# H03 - Use a reserved EVSE - Requirements
+
+Table 90. H03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>H03.FR.01</td><td>Reservation is pending for a specific idToken for a specific evseld</td><td>The Charging Station SHALL allow charging on that EVSE when IdToken presented for authorization matches the specific idToken from the reservation.</td><td></td></tr><tr><td>H03.FR.02</td><td>Reservation is pending for a specific idToken for a specific connectorType</td><td>The Charging Station SHALL allow charging on an EVSE with a connector of type connectorType when IdToken presented for authorization matches the specific idToken from the reservation.</td><td></td></tr><tr><td>H03.FR.03</td><td>Reservation is pending for a specific idToken without a specific evseld or connectorType</td><td>The Charging Station SHALL allow charging on an EVSE when IdToken presented for authorization matches the specific idToken from the reservation.</td><td></td></tr><tr><td>H03.FR.04</td><td>H03.FR.01 AND attribute groupldToken in reservation has a value</td><td>The Charging Station SHALL allow charging on that EVSE when IdToken presented for authorization matches the specific idToken from the reservation or when the associated groupldToken matches.</td><td></td></tr><tr><td>H03.FR.05</td><td>H03.FR.02 AND attribute groupldToken in reservation has a value</td><td>The Charging Station SHALL allow charging on an EVSE with a connector of type connectorType when IdToken presented for authorization matches the specific idToken from the reservation or when the associated groupldToken matches.</td><td></td></tr><tr><td>H03.FR.06</td><td>H03.FR.03 AND attribute groupldToken in reservation has a value</td><td>The Charging Station SHALL allow charging on any EVSE when IdToken presented for authorization matches the specific idToken from the reservation or when the associated groupldToken matches.</td><td></td></tr><tr><td>H03.FR.07</td><td>If attribute groupldToken in the reservation has a value (it is optional).</td><td>In order to determine the groupldToken that is associated with an incoming IdToken, the Charging Station MAY look it up in its Local Authorization List or Authorization Cache.</td><td></td></tr><tr><td>H03.FR.08</td><td>H03.FR.07 AND If the incoming IdToken is not found in the Local Authorization List or Authorization Cache.</td><td>The Charging Station SHALL send an AuthorizationRequest for the incoming IdToken to the CSMS in order to get its associated groupldToken. (Note: This AuthorizationRequest may already have been performed when the idToken was presented for authorization.)</td><td></td></tr><tr><td>H03.FR.09</td><td>When an idToken or groupldToken is presented that matches a reservation</td><td>Charging Station SHALL consider the reservation to be used (consumed)</td><td>The (group)IdToken can be presented locally at a card reader, but can also be part of a RequestStartTransaction.</td></tr><tr><td>H03.FR.10</td><td>H03.FR.09 AND Connector associated with reservation has status Reserved</td><td>Charging Station SHALL set connector status to Available if no cable has been plugged-in, or Occupied if a cable has already been plugged-in.</td><td></td></tr><tr><td>H03.FR.11 (2.1)</td><td>When an idToken or groupldToken is presented that matches a reservation AND No transaction is started within EVConnectionTimeout</td><td>The Charging Station IS RECOMMENDED to send a ReservationStatusUpdateRequest with status = NoTransaction.</td><td>This can happen when cable is never plugged in and TxStartPoint is EVConnected or PowerPathClosed.</td></tr></table>
+
+H04 - Reservation Ended, not used
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reservation Ended, not used</td></tr><tr><td>2</td><td>ID</td><td>H04</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable a Charging Station to notify the CSMS about a reservation that has expired.</td></tr><tr><td>4</td><td>Description</td><td>This use cases covers how the Charging Station notifies the CSMS about a reservation, that has ended/timed out before the EV Driver starts using the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station has a reservation.
+2. The expiryDate of the reservation is reached.
+3. The Charging Station removes the reservation.
+4. If a specific EVSE was reserved for this reservation, the Charging Station makes the EVSE available again and notifies the CSMS about this by sending a NotifyEventRequest with variable "AvailabilityState" set to "Available" for all the Connectors of that EVSE.
+5. The CSMS responds with a NotifyEventResponse.
+6. The Charging Station sends a ReservationStatusUpdateRequest with status Expired to the CSMS.
+7. The CSMS responds with a ReservationStatusUpdateResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Use of StatusNotificationRequest instead of NotifyEventRequest is deprecated, but still allowed.</td></tr></table>
+
+
+Figure 98. Sequence Diagram: Reservation Ended, not used
+
+# H04 - Reservation Ended, not used - Requirements
+
+Table 91. H04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>H04.FR.01</td><td>The reservation ends (expirationDateTime reached)</td><td>The Charging Station SHALL send a ReservationStatusUpdateRequest with status Expired.</td></tr><tr><td>H04.FR.02</td><td>H04.FR.01 AND If a specific EVSE was reserved for this reservation</td><td>The Charging Station SHALL allow charging again on this EVSE.</td></tr><tr><td>H04.FR.03</td><td>H04.FR.02</td><td>The Charging Station SHALL send a StatusNotificationRequest with status Available or a NotifyEventRequest with AvailabilityState set to Available to the CSMS for each connector, notifying the CSMS that all the connectors of this EVSE are available again for any EV Driver.</td></tr></table>
+
+# I. Tariff And Cost
+
+# Chapter 1. Introduction
+
+Updated in OCPP 2.1
+
+This Functional Block specifies how to provide tariff and cost information to an EV Driver, when a Charging Station is capable of showing this on a display.
+
+Earlier versions of OCPP only allowed for central cost calculation to be performed by CSMS. OCPP 2.1 adds the possibility to provide a tariff plan to the Charging Station to enable it to do local cost calculation. Local cost calculation adds complexity to the Charging Station, but it offers the advantage that it is easy to provide a real-time running cost display, and it lets you stop the charge at a preset amount (e.g. for prepaid charging).
+
+The OCPP tariff structure that describes the price structure to use for local cost calculation, is a list of components, like energy and time, with restrictions describing when they apply, like time of day, power, etc. A similar format is used in the common roaming protocols, OCPI (peer-to-peer, Gireve), OCHP (e-clearing.net) and OICP (Hubject). OCPI and OCHP both use tariff elements with components and restrictions. OICP uses pricing products with product availability times and a maximum charging power. All three formats can be mapped straightforwardly onto the OCPP tariff format.
+
+# 1.1. Configuration Settings
+
+Support for local cost calculation is controlled via the TariffCostCtrlr component. Local cost calculation is enabled by setting TariffCostCtrlr.Enabled[Tariff] to true (see TariffEnabled). The frequency by which variations in current, power and energy need to be monitored for tariff calculation is determined by TariffCostCtrlrInterval[Tariff] (see TariffInterval). The maximum supported complexity of a tariff can be limited by TariffCostCtrlr.MaxElements[Tariff] (see TariffMaxElements).
+
+The sending of intermediate running cost updates is enabled by setting TariffCostCtrl.Enabled[Cost] to true (see CostEnabled). How frequent running cost updates must be sent, is determined by TariffCostCtrlInterval[Cost] (see CostInterval).
+
+# NOTE
+
+Charging Station stores a driver-specific tariff, that is received in an AuthorizationResponse, in the Authorization Cache. A CSO is recommended to either disable the use of an Authorization Cache or clear the authorization cache whenever new tariffs become available.
+
+# WARNING
+
+A Local Authorization List cannot be used in conjunction with local cost calculation, because an AuthorizedRequest is needed to get the driver-specific tariff. Only when the default tariff applies to all drivers can a Local Authorization List be used.
+
+# 1.2. Tariff Structures
+
+A tariff is described by the TariffType, which consists of fields with prices for:
+
+energy,
+
+- charging time,
+- idle time,
+- fixed fee.
+
+Each of these fields may have (optional) conditions that specify when a price is applicable. A reservation is billed as a fixed fee or based on time.
+
+The energy field is of type TariffEnergyType which has a TariffEnergyPriceType with a price per kWh for the energy and an optional TariffConditionsType (date, time of day, power, current, energy) that describes under which conditions this TariffEnergyPriceType is to be applied.
+
+The charging time and idle time fields are of type TariffTimeType which has a TariffTimePriceType with a price per minute for the time and an optional TariffConditionsType.
+
+Similarly, a fixed fee is described by a TariffFixedType with an optional TariffConditionsFixedType, which does not contain conditions for energy, power, current or time, since it is applied at the start of a transaction.
+
+A Tariff{Energy/Time/Fixed}PriceType without a TariffConditions(Fixed)Type is always applicable. In case multiple prices are applicable, then only the first applicable element in the list is applied.
+
+A Charging Station implementation can opt to not support the TariffConditions(Fixed)Type element. If this is the case, then it must report TariffCostCtrlr CONDITIONSSupported[Tariff] as false, so that CSMS is aware that it cannot use conditions in tariff plans.
+
+# 1.2.1. Simple kWh tariff
+
+The following is a basic example of a JSON tariff structure that describes a kWh-based price for a transaction:
+
+Simple kWh tariff of $0.25 per kWh
+
+```json
+{ "id": "10", "currency": "USD", "energy": { "taxRates": [ { "type": "federal", "tax": 6.0 }, { "type": "state", "tax": 4.0 } ], "prices": [ { "priceKwh": 0.25 } ] }
+```
+
+# 1.2.2. Time-of-day kWh tariff with idle fee
+
+The following example describes a tariff with a higher price during office hours (8-18h) and an idle fee for staying connected without charging, and a lower price without idle fee during evening and night.
+
+Time-of-day kWh tariff with idle fee
+
+```json
+{ "id": "11", "currency": "EUR", "energy": { "taxRates": [ { "type": "vat", "tax": 4 } ], "prices": [ { "priceKwh": 0.4, "conditions": { "startTimeOfDay": "08:00", "endTimeOfDay": "18:00" } }, { "priceKwh": 0.25 } ] }, " idleTime": { "taxRates": [ { "type": "vat", "tax": 4 } ],
+```
+
+```json
+"prices": [ { "priceMinute": 1, "conditions": { "startTimeOfDay": "08:00", "endTimeOfDay": "18:00" } } ] } } }
+```
+
+# NOTE
+
+startTimeOfDay andEndTimeOfDay in TariffConditions(Fixed)Type are in local time (without time zone).
+
+Tariff shows times as presented to driver. This is always local time. This also avoids the complexities of separate tariffs for summer and winter time and how to deal with switching between them. A Charging Station can easily convert times to the internally used time zone. This is not required to be UTC, as described in Section 3.1: "It is strongly RECOMMENDED to exchange all time values between CSMS and Charging Station as UTC"
+
+# 1.2.3. Complex hourly tariff
+
+The following describes a time-based tariff, that includes a higher start fee for credit cards and an hourly fee that depends on time of the day and day of the week.
+
+Complex hourly tariff with conditions based on time and day of week and an idle fee
+
+```json
+{
+ "id": "12",
+ "currency": "EUR",
+ "fixedFee": {
+ "taxRates": [ { "type": "vat", "tax": 10.0 } ],
+ "prices": [
+ "priceFixed": 3.00, -- start fee for credit card
+ "conditions": {
+ "paymentRecognition": "CC"
+ }
+ ],
+ "priceFixed": 2.50 -- start fee other payment methods
+ }
+},
+"chargingTime": {
+ "taxRates": [ { "type": "vat", "tax": 15.0 } ],
+ "prices": [
+ "priceMinute": 1.00, -- price per minute
+ "conditions": {
+ "maxPower": 11000 -- when charging speed < 11.0 kW.
+ }
+ ],
+ "priceMinute": 2.00,
+ "conditions": {
+ "minPower": 11000 -- when charging speed >= 11.0 kW
+ }
+}
+```
+
+```txt
+"prices":[{ "priceMinute":1.00，-- price per minute "conditions": { "startTimeOfDay": "09:00", "endTimeOfDay": "18:00", "minIdleTime":300，-- after 5 mins of idle time "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday", "Friday"] } }, { "priceMinute":0.60，-- price per minute "conditions":{ "startTimeOfDay": "10:00", "endTimeOfDay": "17:00", "dayOfWeek": ["Saturday"] } -- No idle fee on other days (Sunday) or hours } ] }
+```
+
+# NOTE
+
+When tariff conditions are used, it is recommended to add a field without any condition at the bottom of the list as a fallback to use when none of the conditions are met.
+
+# 1.2.4. Idle fee based on charging location occupancy
+
+When an operator only wants to charge an idle fee when the charging location is occupied for more than a certain percentage, then this is something that cannot be captured in a static tariff, since one charging station is not aware of activity at other charging stations. Therefore, CSMS will update the tariff to use, depending on the occupancy of the charging location.
+
+When the charging location is quiet, for example less than half of the station is in use, CSMS uses the following tariff:
+
+kWh tariff for low occupancy (no idle fee)
+
+```json
+{
+ "id": "21",
+ "description": [
+ "format": "ASCII", "language": "en",
+ "content": "0.44 ct/kWh (currently no idle fees, but will apply at busy times, 5 minutes after end of charging). Price incl. VAT"
+ ],
+ "currency": "EUR",
+ "energy": [
+ "prices": [
+ "pricekWh": 0.40, -- per kWh
+ "taxRates": [ { "type": "vat", "tax": 10.0 } ]
+ ]
+ ]
+}
+```
+
+At the moment that more than half of the stations at this location are in use, CSMS will use below tariff for new charging sessions, but also update the tariff for existing charging sessions with this tariff. The kWh price remains the same, but idle time will now be charged after 5 minutes.
+
+kWh tariff for high occupancy (with idle fee)
+
+```txt
+{
+```
+
+```txt
+"id": "22",
+"description": [ { "format": "ASCII", "language": "en", "content": "0.44 ct/kWh (idle fees of 1 euro per minute apply 5 minutes after end of charging, until location becomes less busy). Price incl. VAT" } ],
+"currency": "EUR",
+"energy": [( prices": [[ priceKwh]: 0.40, -- per kWh "taxRates": [ { "type": "vat", "tax": 10.0} ] } ], { idleTime": [[ priceMinute": 0.909, "taxRates": [ { "type": "vat", "tax": 10.0} ] } ], "conditions": { minIdleTime": 300 -- 5 minutes } ]
+```
+
+The change of tariff will be reflected in the CostDetailsType as a new ChargingPeriodType, and it will be reported in the transaction events as a triggerReason = TariffChanged.
+
+# 1.3. CostDetails
+
+At the end of a transaction the Charging Station includes a break-down of the calculated cost in the last TransactionEventRequest in a CostDetailsType.
+
+The CostDetailsType contains a list of ChargingPeriodType that each represent a period during the transaction to which the same TariffEnergyPriceType and [tarifftimepricetype] was applied. Whenever a different TariffEnergyPriceType or [tarifftimepricetype] becomes valid, because conditions change and a different TariffConditionsType applies, a new ChargingPeriodType is created. Note, that a TariffFixedPriceType is only evaluated at start of the transaction.
+
+A simple energy or time-based tariff without conditions will result in a CostDetailsType with only one ChargingPeriodType.
+
+CostDetails example for tariff 10 (see above) when charging $10\mathrm{kWh}$
+
+```json
+{ "chargingPeriods":[{ "tariffId": "10", "startPeriod": "2023-04-05T14:01:02Z", "dimensions":[{ "type": "energy", -- energy is relevant dimension for tariff "volume": 10000 }]} }, "totalCost": { "currency": "EUR", "energy": { "exclTax": 2.50, "inclTax": 2.75, "taxRates": [ { "type": "federal", "tax": 6.0 }, { "type": "state", "tax": 4.0 } ]
+```
+
+```json
+}，"total":{"exclTax":2.50，"inclTax":2.75}1"totalUsage":{"energy":10000}
+```
+
+The start of a charging period is a timestamp, rather than seconds since start of a transaction. This makes it easier for a CSO or EMSP to validate the price against the tariff. Start and stop time of transaction are not part of CostDetailsType, because that information is already part of the TransactionEventRequest messages. Similarly, unit prices and conditions are not part of it either, because that information is already in the TariffType referred to by tariffId.
+
+Below is an example of a transaction with two ChargingPeriodType that started at 17:30h for the low price and continued after 18:00h for the higher price.
+
+NOTE In this example the local time is in Zulu (or GMT)timezone for simplicity.
+
+CostDetails example for tariff 11 (above) when charging $10\mathrm{kWh}$ in which 6 kWh have a high and 4 kWh have a low price
+
+```jsonl
+{ "chargingPeriods": [ { "tariffId": "11", "startPeriod": "2023-04-05T17:30:00Z", "dimensions": [ { "type": "energy", "volume": 6000 -- 6 kWh @ 0,25 }]} }, { "tariffId": "11", "startPeriod": "2023-04-05T18:00:00Z", "dimensions": [ { "type": "energy", "volume": 4000 -- 4 kWh @ 0.40 }]} ], "totalCost": { "currency": "EUR", "energy": { "exclTax": 3.10, "inclTax": 3.41, "taxRates": [ { "type": "vat", "tax": 10.0} ] }, "total": { "exclTax": 3.10, "inclTax": 3.41 } }, "totalUsage": { "energy": 10000 } }
+```
+
+Following is an example with one ChargingPeriodType that has two CostDimensionType, because price was determined by both
+
+charging time ("ChargingTime") and maximum power ("MaxPower").
+
+CostDetails example for tariff 12 (above) when charging 1 hour below $11\mathrm{kW}$ and half hour above $11\mathrm{kW}$
+
+```json
+{
+ "chargingPeriods": [
+ "tariffId": "12",
+ "startPeriod": "2023-04-05T14:00:00Z",
+ "dimensions": [
+ "type": "ChargingTime",
+ "volume": 3600
+ ],
+ "type": "MinPower",
+ "volume": 0,
+ "type": "MaxPower", -- determines price level
+ "volume": 10500
+ ],
+ {
+ "tariffId": "12",
+ "startPeriod": "2023-04-05T15:00:00Z",
+ "dimensions": [
+ "type": "ChargingTime",
+ "volume": 3600
+ ],
+ "type": "MinPower", -- determines price level
+ "volume": 11000
+ ],
+ "type": "MaxPower", -- recorded, but not relevant for price
+ "volume": 22000
+ ]
+},
+"totalCost": {
+ "currency": "EUR",
+ "fixed": {
+ "exclTax": 2.50,
+ "inclTax": 2.875,
+ "taxRates": [ { "type": "vat", "tax": 15.0 } ]
+ },
+ "chargingTime": {
+ "exclTax": 2.00,
+ "inclTax": 2.40,
+ "taxRates": [ { "type": "vat", "tax": 20.0 } ]
+ },
+ "total": {
+ "exclTax": 4.50,
+ "inclTax": 5.275
+ }
+},
+"totalUsage": {
+ "chargingTime": 4800
+}
+```
+
+# Chapter 2. Use cases & Requirements
+
+# I01 - Show EV Driver-specific Tariff Information
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Show EV Driver-specific Tariff Information</td></tr><tr><td>2</td><td>ID</td><td>I01</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show an EV Driver-specific tariff before the start of a transaction.</td></tr><tr><td>4</td><td>Description</td><td>When an EV Driver wants to charge an EV he wants to know how much charging will cost him at the Charging Station he is at. The EV Driver is authenticated by his (RFID) token. The Charging Station asks the CSMS for information about the presented token. The CSMS returns information about the token, including the tariff applicable to this EV Driver.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver wants to charge an EV, he presents his IdTokenType.
+2. The Charging Station sends AuthorizationRequest to the CSMS to request authorization.
+3. Upon receipt of AuthorizationRequest, the CSMS responds with AuthorizationResponse. This response message indicates whether or not the IdTokenType is accepted by the CSMS, and reports the EV Driver-specific tariff in the personalMessage field.
+4. The Charging Station shows the EV Driver-specific tariff to the EV Driver.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>I04 - Show Fallback Tariff Information</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station supports Tariff Information</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The EV Driver is authorized, knows which tariff is applicable for him/her and can start charging.
+Failure postcondition:
+If the authorization status is other than Accepted, the EV Driver can not start and might not know the tariff.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks
+Updated in OCPP 2.1</td><td>This use case is only about displaying a textual representation of the tariff. This can be used when support for the TariffType structure for tariffs from I07 - Local Cost Calculation - Set Default Tariff is not supported.
+The tariff information presented might be the same for any token presented.
+If known, and applicable, it is advisable to show the tariff information in a language understood by the EV Driver.
+It is advisable to give the driver the option to cancel the transaction when he does not agree with the tariff. This could be not plugging in the cable, or a cancel button in the user interface etc. As long as it is clear to the driver how a transaction can be canceled.</td></tr></table>
+
+
+Figure 99. Sequence Diagram: Show EV Driver-specific tariff information
+
+# I01 - Show EV Driver-specific Tariff Information - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I01.FR.01</td><td></td><td>The CSMS MAY send EV Driver-specific tariff information in the PersonalMessage field of an AnswerizeResponse message.</td></tr><tr><td>I01.FR.02</td><td></td><td>The CSMS SHALL only send the tariff information if the Charging Station supports the tariff or DisplayMessage functionality.</td></tr><tr><td>I01.FR.03</td><td>I01.FR.01</td><td>The Charging Station SHALL show the EV Driver-specific tariff information to the EV Driver.</td></tr></table>
+
+# 102 - Show EV Driver Running Total Cost During Charging
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Show EV Driver Running Total Cost During Charging</td></tr><tr><td>2</td><td>ID</td><td>I02</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show an EV Driver the running total cost during charging</td></tr><tr><td>4</td><td>Description</td><td>While a transaction is ongoing, the driver wants to know how much the running total cost is, updated at a relevant interval.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. Every Y seconds the CSMS sends a CostUpdatedRequest to the Charging Station to update the current total cost.
+2. Upon receipt of the CostUpdatedRequest, the Charging Station responds with a CostUpdatedResponse.
+3. The Charging Station shows the current total cost to the EV Driver.</td></tr><tr><td></td><td>Alternative scenario</td><td>1. Upon receipt of a TransactionEventRequest with eventType = Updated the CSMS returns the running cost corresponding to the timestamp and meterValue in the field totalCost in the TransactionEventResponse.
+2. The Charging Station shows the current total cost to the EV Driver.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station supports Tariff Information Ongoing transaction</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The EV Driver knows the running total cost during charging.
+Failure postcondition:
+Total cost not known to the EV Driver during charging.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>Updating the running cost very often will create a lot of messages, which might result in high mobile data cost.</td></tr></table>
+
+
+Figure 100. Sequence Diagram: Show EV Driver Running Total Cost During Charging
+
+# I02 - Show EV Driver Running Total Cost During Charging - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I02.FR.01</td><td></td><td>The CSMS SHALL send either a CostUpdatedRequest at a relevant interval/moment or return the running cost in a TransactionEventResponse. This might depend on the charging speed, running cost, etc.</td></tr><tr><td>I02.FR.02</td><td>Upon receipt of a CostUpdatedRequest message.</td><td>The Charging Station SHALL respond with a CostUpdatedResponse message.</td></tr><tr><td>I02.FR.03</td><td>I02.FR.02</td><td>The Charging Station SHALL show the current total cost to the EV Driver.</td></tr><tr><td>I02.FR.04</td><td>When running cost is reported in TransactionEventResponse</td><td>The Charging Station SHALL show the current running cost to the EV Driver.</td></tr></table>
+
+# 103 - Show EV Driver Final Total Cost After Charging
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Show EV Driver Final Total Cost After Charging</td></tr><tr><td>2</td><td>ID</td><td>I03</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show an EV Driver the total cost after the transaction is finished.</td></tr><tr><td>4</td><td>Description</td><td>An EV Driver stops an ongoing transaction by presenting his identification token (for example RFID). The transaction is stopped and the total cost of the transaction is shown to the EV Driver.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver presents an IdTokenType to stop the transaction.
+2. The Charging Station sends TransactionEventRequest (eventType = Ended)
+3. The CSMS responds with TransactionResponse containing the total cost of the transaction.
+4. The Charging Station shows the total cost to the EV Driver.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>I05 - Show Fallback Total Cost Message</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station supports Tariff Information Ongoing transaction</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The EV Driver knows the total cost of the transaction.
+Failure postcondition:
+The EV Driver does NOT know the total cost of the transaction.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>If the Charging Station was offline when the transaction ended and the TransactionEventResponse with total/Cost is received when the Charging Station comes back online some time after that, then there is no use in displaying the cost, because the driver has likely left already. A similar situation applies when TxStopPoint is defined as ParkingBayOccupancy, in which case the EV must leave the Charging Station to cause the transaction to end.The scenario description and sequence diagram above are based on the Configuration Variable for stop transaction being configured as follows.TxStopPoint: ParkingBayOccupancy, EVConnected, AuthorizedThis use-case is also valid for other configurations, but then the transaction might stop at another moment, which might change the sequence in which message are send. For more details see the use case: E06 - Stop Transaction options</td></tr></table>
+
+
+Figure 101. Sequence Diagram: Show EV Driver Final Total Cost After Charging
+
+# I03 - Show EV Driver Final Total Cost After Charging - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I03.FR.01</td><td>When transaction is stopped</td><td>The Charging Station SHALL send a TransactionRequest (eventType = Ended) to the CSMS.</td></tr><tr><td>I03.FR.02</td><td>I03.FR.01 AND When Total Cost is known to the CSMS.</td><td>The CSMS SHALL send the total cost of the transaction in the totalCost field of the TransactionResponse message.</td></tr><tr><td>I03.FR.03</td><td>I03.FR.02 AND Charging Station was online when transaction stopped</td><td>The Charging Station SHALL display the total cost to the EV Driver.</td></tr><tr><td>I03.FR.04</td><td></td><td>To indicate a free transaction, the CSMS SHALL set totalCost to 0.00. Thus omitting totalCost does not imply that the transaction was free.</td></tr><tr><td>I03.FR.05</td><td>I02.FR.02 AND TxStopPoint is defined as ParkingBayOccupancy</td><td>The Charging Station SHOULD NOT display the total cost to the EV Driver. (Driver has left already).</td></tr></table>
+
+# 104 - Show Fallback Tariff Information
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Show Failback Tariff Information</td></tr><tr><td>2</td><td>ID</td><td>I04</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show an EV Driver some information, generic tariff, a message etc., when the Charging Station cannot retrieve tariff information for this EV Driver.</td></tr><tr><td>4</td><td>Description</td><td>When an EV Driver wants to charge an EV, he wants an indication of how much charging will cost him at the Charging Station he is at, but the Charging Station cannot get a specific tariff for this EV Driver (for example: the Charging Station is Offline, or no EV Driver-specific tariff is available). For such scenarios, a fallback tariff information message can be configured in the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver wants to charge an EV, he presents his IdTokenType.
+2. The Charging Station authorizes the EV Driver against the Authorization Cache
+3. The Charging Station shows the TariffFallbackMessage to the EV Driver.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>I01 - Show EV Driver-specific Tariff Information</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station supports Tariff Information
+the Configuration Variable: TariffFallbackMessage is configured.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+EV Driver has been shown the fallback tariff information message
+Failure postcondition:
+EV Driver has no information about the tariff at this Charging Station.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>n/a</td></tr></table>
+
+
+Figure 102. Sequence Diagram: Show Fallback Tariff Information
+
+# 104 - Show Fallback Tariff Information - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I04.FR.01</td><td>When the Charging Station cannot get a specific tariff for the EV Driver (for example: the Charging Station is Offline, or no EV Driver-specific tariff is available.)</td><td>The Charging Station SHALL display a fallback tariff information message to the EV Driver, which is configured in the Configuration Variable: TariffFallbackMessage.</td></tr><tr><td>I04.FR.02</td><td></td><td>The CSMS MAY configure the TariffFallbackMessage via the Configuration Variable: TariffFallbackMessage.</td></tr></table>
+
+I05 - Show Fallback Total Cost Message
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Show Failback Total Cost Message</td></tr><tr><td>2</td><td>ID</td><td>I05</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show an EV Driver a message instead of the actual total cost when the Charging Station is Offline when a transaction is stopped.</td></tr><tr><td>4</td><td>Description</td><td>When an EV Driver wants to stop an ongoing transaction, but the Charging Station is Offline. The transaction will be stopped as described earlier. The Charging Station cannot retrieve the total cost for the stopped transaction. The EV Driver needs to be given some message, this message can be configured in the Configuration Variable: TotalCostFallbackMessage.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The EV Driver presents IdTokenType to stop the transaction.
+2. The Charging Station stops the energy offer.
+3. The Charging Station shows the TotalCostFallbackMessage to the EV Driver.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>I03 - Show EV Driver Final Total Cost After Charging</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station supports Tariff Information
+The Charging Station is Offline
+the Configuration Variable: TotalCostFallbackMessage is configured.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The EV Driver has received a pre-configured fallback message.
+Failure postcondition:
+The EV Driver has not received a pre-configured fallback message.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>n/a</td></tr></table>
+
+
+Figure 103. Sequence Diagram: Show Fallback Total Cost Message
+
+I05 - Show Fallback Total Cost Message - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I05.FR.01</td><td></td><td>The CSMS MAY configure the fallback total cost information message via the Configuration Variable: TotalCostFallbackMessage.</td></tr><tr><td>I05.FR.02</td><td>When the Charging Station cannot retrieve the total cost for the stopped transaction, because the Charging Station is offline.</td><td>The Charging Station SHALL show a fallback total cost information message to the EV Driver.</td></tr></table>
+
+# 106 - Update Tariff Information During Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Update Tariff Information During Transaction</td></tr><tr><td>2</td><td>ID</td><td>I06</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show an EV Driver updated tariff information during a transaction.</td></tr><tr><td>4</td><td>Description</td><td>During charging (especially DC fast charging) it might be useful to show the EV driver updated tariff information when it becomes available.
+Example: If a tariff has a bandwidth: charging will cost between 0,25 and 0,40 euro/kWh depending on current energy price. Current price is 0,28 euro/kWh.
+Then when the price changing, this tariff information needs to be updated: charging will cost between 0,25 and 0,40 euro/kWh depending on current energy price. Current price is 0,32 euro/kWh.</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends TransactionRequest (eventType = Updated) messages during the transaction.
+2. When the CSMS receives a TransactionRequest message it checks if there is updated tariff information available.
+3. The CSMS acknowledges with a TransactionResponse message, which contains the updated tariff information if available.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station supports Tariff Information
+There is a transaction ongoing</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The updated tariff information is shown to the EV Driver.
+Failure postcondition:
+The EV Driver has not been shown the updated tariff information.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>There may be a policy or a legal requirement in place, that the tariff communicated at the start of the transaction must be used for the entire transaction, in which case no updated tariff information should be sent during the transaction.</td></tr></table>
+
+
+Figure 104. Sequence Diagram: Update Tariff Information During Transaction
+
+# I06 - Update Tariff Information During Transaction - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I06.FR.01</td><td>When the CSMS receives a TransactionRequest (eventType = Updated) from the Charging Station.</td><td>The CSMS SHALL check if there is updated tariff information available.</td></tr><tr><td>I06.FR.02</td><td>I06.FR.01 AND When there is updated tariff information available.</td><td>The CSMS SHALL respond with a TransactionResponse message to the Charging Station, containing the updated tariff information in the default language in the updatedPersonalMessage field and optionally other languages of this in updatedPersonalMessageExtra fields.</td></tr><tr><td>I06.FR.03</td><td>I06.FR.02</td><td>The Charging Station SHALL display the updated tariff information to the EV Driver.</td></tr></table>
+
+# 107 - Local Cost Calculation - Set Default Tariff
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Local Cost Calculation - Set Default Tariff</td></tr><tr><td>2</td><td>ID</td><td>I07</td></tr><tr><td>3</td><td>Objective(s)</td><td>To set the default tariff on the charging station, for example for ad hoc charging, or when there is no driver-specific tariff.</td></tr><tr><td>4</td><td>Description</td><td>CSMS provides a tariff structure that Charging Station must use to calculate the cost. This use case assumes a Charging Station with 4 EVSEs.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>Same tariff for all 4 EVSEs1. CSMS sends SetDefaultTariffRequest to Charging Station with evseld = 0 (to install at all EVSEs) and a tariff with tariffld = "Tariff1" that describes the tariff structure Tariff1.2. Charging Station responds with SetDefaultTariffResponse to CSMS with status = Accepted.3. Charging Station displays tariff description, tariff.description on display for all 4 EVSEs.</td></tr><tr><td></td><td>Scenario description #2</td><td>Same tariff for all EVSEs, except #41. CSMS sends SetDefaultTariffRequest to Charging Station with evseld = 0 (to install at all EVSEs) and a tariff with tariffld = "Tariff1" that describes the Tariff1 structure for all EVSEs.2. Charging Station responds with SetDefaultTariffResponse to CSMS with status = Accepted.3. CSMS sends SetDefaultTariffRequest to Charging Station with evseld = 4 (install only at EVSE #4) and a tariff with tariffld = "Tariff2" that describes the Tariff2 structure that replaces the previously installed Tariff1.4. Charging Station responds with SetDefaultTariffResponse to CSMS with status = Accepted.5. Charging Station displays Tariff1 description on display for EVSE #1, #2 and #3.6. Charging Station displays Tariff2 description on display for EVSE #4.</td></tr><tr><td></td><td>Scenario description #3</td><td>Update a default tariff1. CSMS sends SetDefaultTariffRequest to Charging Station for evseld = 0 with a tariff with tariffld = "Tariff3" and validFrom set to tomorrow 0:00h that describes the new tariff structure Tariff3 to become valid tomorrow.2. Charging Station responds with SetDefaultTariffResponse to CSMS with status = Accepted.3. At tomorrow 0:00h the new Tariff3 will become active and replace the existing default tariffs on all EVSEs.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station supports local cost calculation</td></tr><tr><td>6</td><td>Postcondition(s)</td><td></td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>Only one tariff structure can be sent in a message, because a tariff structure can potentially be large.Sending a SetDefaultTariffRequest with evseld = 0 basically copies the tariff to each EVSE of the Charging Station.A tariffld uniquely identifies the tariff for the Charging Station. An updated default tariff must therefore have a new tariffld. In order to update the default tariff per a certain date, a new default tariff can be installed with a validFrom date after which it becomes valid and replaces the existing default tariff.</td></tr></table>
+
+
+Figure 105. Sequence diagram when using default tariff
+
+# 107 - Set Default Tariff - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>I07.FR.01</td><td>Upon receiving a SetDefaultTariffRequest when TariffCostCtrIr is absent or TariffCostCtrIr.Enabled[Tariff] = false (i.e. Charging Station does not support local cost calculation)</td><td>Charging Station SHALL respond with an RPC CALLERROR "NotSupported"</td><td>Or "NotImplemented" if the message has not been implemented.</td></tr><tr><td>I07.FR.02</td><td>Upon receiving a SetDefaultTariffRequest with a tariff structure in which the total count of TariffEnergyType, TariffTimeType and TariffFixedType elements is more than Charging Station is able to process</td><td>Charging Station SHALL respond with SetDefaultTariffResponse with status = TooManyElements</td><td></td></tr><tr><td>I07.FR.03</td><td>Upon receiving a SetDefaultTariffRequest with a tariff structure that contains elements with a TariffConditionsType or TariffConditionsFixedType AND TariffCostCtrIr CONDITIONSSupported = false (i.e. Charging Station does not support conditions)</td><td>Charging Station SHALL respond with SetDefaultTariffResponse with status = ConditionNotSupported.</td><td></td></tr><tr><td>I07.FR.04</td><td>Upon receiving a SetDefaultTariffRequest with a tariff that has a tariffId that is already present in the Charging Station</td><td>Charging Station SHALL respond with SetDefaultTariffResponse with status = DuplicateTariffId.</td><td></td></tr><tr><td>I07.FR.05</td><td>Upon receiving a SetDefaultTariffRequest with an invalid tariff structure</td><td>Charging Station SHALL respond with SetDefaultTariffResponse with status = Rejected, optionally with a statusInfo element withreasonCode = "InvalidValue".</td><td></td></tr><tr><td>I07.FR.06</td><td>Upon receiving a SetDefaultTariffRequest with an invalid evseld</td><td>Charging Station SHALL respond with SetDefaultTariffResponse with status = Rejected, optionally with a statusInfo element withreasonCode = "UnknownEVSE".</td><td></td></tr><tr><td>I07.FR.10</td><td>Upon receiving a SetDefaultTariffRequest with a valid tariff structure AND NOT I07.FR.01-06</td><td>Charging Station SHALL respond with SetDefaultTariffResponse with status = Accepted</td><td></td></tr><tr><td>I07.FR.11</td><td>I07.FR.10 AND Charging Station receives a SetDefaultTariffRequest with a tariff and evseld > 0</td><td>Charging Station SHALL install tariff as the default tariff at EVSE evseld.</td><td></td></tr><tr><td>I07.FR.12</td><td>I07.FR.10 AND Charging Station receives SetDefaultTariffRequest with a tariff and evseld = 0</td><td>Charging Station SHALL install tariff as the default tariff at each EVSE.</td><td>This is exactly the same as sending a SetDefaultTariffRequest for each individual EVSE of the Charging Station.</td></tr><tr><td>I07.FR.13</td><td>I07.FR.10</td><td>Charging Station SHALL store the default tariff in persistent memory.</td><td></td></tr><tr><td>I07.FR.14</td><td>If a default tariff has been installed for an EVSE AND No driver-specific tariff has been received for the idToken for which a transaction has started or will be started.</td><td>Charging Station SHALL show and use the default tariff for cost calculation.</td><td>A default tariff may also be communicated through other means than the Charging Station display.</td></tr><tr><td>I07.FR.17</td><td></td><td>AstartTimeOfDay,EndTimeOfDay, validFromDate and validToDate in a TariffConditionsType or TariffConditionsFixedType SHALL be in local time.</td><td>This is a five character time notation in "hh:mm" format.</td></tr><tr><td>I07.FR.18</td><td></td><td>A validFrom in TariffType SHALL be specified in system time.</td><td>This is usually in UTC ("Z" time zone).</td></tr><tr><td>I07.FR.19</td><td>If TariffType has a value for validFrom</td><td>Charging Station SHALL NOT consider this tariff for use until the current time is equal or later than validFrom.</td><td></td></tr><tr><td>I07.FR.20</td><td>If a tariff A is present on EVSE X with no validFrom AND a tariff B is present on EVSE X with a value for validFrom AND current time is equal or later than B.validFrom (i.e. B is now valid)</td><td>Charging Station SHALL replace the tariff A on EVSE X with the new tariff B.</td><td></td></tr><tr><td>I07.FR.21</td><td>If a tariff A is present on EVSE X with A.validFrom = T1 AND a tariff B is present on EVSE X with a value for B.validFrom = T2 AND current time is equal or later than B.validFrom (i.e. B is now valid) AND A.validFrom <= B.validFrom</td><td>Charging Station SHALL replace the tariff A on EVSE X with the new tariff B.</td><td></td></tr><tr><td>I07.FR.22</td><td>If a tariff A is present on EVSE X with no validFrom AND a tariff B is installed on EVSE X with no validFrom</td><td>Charging Station SHALL replace the tariff A on EVSE X with the new tariff B.</td><td></td></tr><tr><td>I07.FR.23</td><td>If a tariff A is present on EVSE X with A.validFrom = T1 AND a tariff B is present on EVSE X with a value for B.validFrom = T2 AND current time is less than A.validFrom (i.e. A is not yet valid) AND A.validFrom > B.validFrom</td><td>Charging Station SHALL NOT replace the tariff A on EVSE X with the new tariff B.</td><td>A becomes valid after B, so must not be removed.</td></tr><tr><td>I07.FR.24</td><td>(I07.FR.20 OR I07.FR.21 OR I07.FR.22) AND the tariff A is used in an active transaction on EVSE X</td><td>Charging Station SHALL continue to use the tariff A for the transaction on EVSE X until the transaction has ended.</td><td>The tariff cannot change during a transaction, unless explicitly requested via ChangeTransactionTariffRequest.</td></tr><tr><td colspan="4">Tariff acceptance</td></tr><tr><td>I07.FR.30</td><td>I07.FR.14 AND EV Driver does not accept the tariff AND Charging Station has already started a transaction</td><td>Charging Station SHALL deauthorize the idToken of the transaction and send a TransactionEventRequest with triggerReason = "TariffNotAccepted".</td><td>There will be no tariffId and no cost associated with transaction. Without authorization, no energy will be delivered. If TxStopPoint contains "Authorized" or "PowerPathClosed" this situation will end the transaction with stoppedReason = DeAuthorized.</td></tr><tr><td>I07.FR.31</td><td>I07.FR.14 AND EV Driver does not accept the tariff AND Charging Station has not yet started a transaction</td><td>Charging Station SHALL deauthorize the idToken of EV Driver.</td><td>A transaction can still be started after this when a cable is plugged in and TxStartPoint = "EVConnected", but without authorization, no energy will be delivered.</td></tr><tr><td>I07.FR.32</td><td>I07.FR.14 AND EV Driver has implicitly or explicitly accepted the tariff</td><td>Charging Station SHALL associate the default tariff with the transaction by including transactionInfo.tariffld once in the next TransactionEventRequest message.</td><td></td></tr></table>
+
+NOTE A "default tariff" is a tariff installed via a SetDefaultTariffRequest message.
+
+# 108 - Local Cost Calculation - Receive Driver Tariff
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Local Cost Calculation - Receive Driver Tariff</td></tr><tr><td>2</td><td>ID</td><td>I08</td></tr><tr><td>3</td><td>Objective(s)</td><td>To receive the driver-specific tariff in response to an InvalidateRequest.</td></tr><tr><td>4</td><td>Description</td><td>CSMS provides a tariff structure in a InvalidateResponse that Charging Station must use to calculate the cost. This implies that Authorization Cache or Local Authorization List cannot be used.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description #1</td><td>Driver authorizes first (TxStartPoint = PowerPathClosed)1. Driver presents idToken for authorization.a. Charging Station sends an AuthorizationRequest for idToken.b. CSMS determines that a driver-specific tariff exists for this idToken and responds with an AuthorizationResponse with idTokenInfo which has status = Accepted and the tariff for the driver in tariff.2. Charging Station shows the tariff to driver.3. Driver connects the charging cable and accepts the tariff.4. Charging Station starts a transaction and associates it with the driver-specific tariff.a. Charging Station sends a TransactionEventRequest with eventType = Started, triggerReason = CablePluggedIn, the idToken, the evse that is used, chargingState = Charging and transactionInfo.tariffld set to the driver-specific tariff (plus any other relevant fields).b. CSMS responds with a TransactionEventResponse with idTokenInfo.status = Accepted.</td></tr><tr><td></td><td>Scenario description #2</td><td>Driver plugs-in first (TxStartPoint = EVConnected)1. Driver connects the charging cable.a. Charging Station sends a TransactionEventRequest with eventType = Started, triggerReason = CablePluggedIn, the evse that is used, chargingState = EVConnected (and any other relevant fields).b. CSMS responds with a TransactionEventResponse.2. Driver presents idToken for authorization.a. Charging Station sends an AuthorizationRequest for idToken.b. CSMS determines that a driver-specific tariff exists for this idToken and responds with an AuthorizationResponse with idTokenInfo which has status = Accepted and the tariff for the driver in tariff.c. Charging Station sends a TransactionEventRequest with eventType = Updated, triggerReason = Authorized, chargingState = EVConnected (and any other relevant fields).d. CSMS responds with a TransactionEventResponse with idTokenInfo.status = Accepted.3. Charging Station delays the charging until driver accepts tariff.4. Charging Station shows the tariff to driver.5. Driver accepts tariff.6. Charging Station associates the transaction with the tariff.a. Charging Station sends a TransactionEventRequest with eventType = Updated, triggerReason = ChargingStateChanged, chargingState = Charging and transactionInfo.tariffld set to the driver-specific tariff (plus any other relevant fields).b. CSMS responds with a TransactionEventResponse.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Authorization Cache or Local Authorization List are not enabled.Ccharging Station supports local cost calculation.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Charging Station does local cost calculation for transaction.</td></tr><tr><td>7</td><td>Error Handling</td><td>A tariff structure in field tariff of AuthorizationResponse can be complex. If Charging Station fails to parse tariff (for whatever reason), it will respond with an RPC FrameworkCALLRESPTERROR(FormatViolation or InternalError). Charging Station will not allow idToken to start charging.</td></tr><tr><td>8</td><td>Remarks</td><td>A tariff is returned for the idToken at a point in time where the EVSE to be used may not yet be known. In the situation where a Charging Station has a low power and a high power EVSE with different pricing, then a tariff with restrictions on min/max power or EVSE type AC/DC needs to be used to differentiate the pricing.
+How a driver accepts the tariff is up to user interface of the Charging Station. If the Charging Station does not have any method to accept user input (e.g. no buttons), then a work-around can be to request the driver to present the idToken once more to confirm.</td></tr></table>
+
+
+
+
+Figure 106. Sequence diagram TxStartPoint = PowerPathClosed, authorize first
+
+
+Figure 107. Sequence diagram TxStartPoint = PowerPathClosed, plug-in first
+
+
+Figure 108. Sequence diagram TxStartPoint = EVConnected, plug-in first
+
+# 108 - Receive Driver Tariff - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Notes</td></tr><tr><td>I08.FR.01</td><td>When CSMS receives an AuthorizationRequest for an idToken that is accepted for charging and for which a driver-specific tariff exists</td><td>CSMS SHALL respond with an AuthorizationResponse with a tariff field and any other relevant fields (like idTokenInfo).</td><td>The details of the authorization process are described in chapter C. Authorization.</td></tr><tr><td>I08.FR.04</td><td>When Charging Station receives an AuthorizationResponse in which idTokenInfo.status = Accepted and with a tariff field which it is able to process</td><td>Charging Station SHALL use this driver-specific tariff only for the duration of the transaction that has started or will be started for idToken.</td><td>Depending on TxStartPoint and order of events the transaction may have started already.</td></tr><tr><td>I08.FR.05</td><td>I08.FR.04 AND AuthCacheEnabled = true</td><td>Charging Station SHALL store the driver-specific tariff for idToken in the Authorization Cache.</td><td>Be aware that as long as idToken is valid in Authorization Cache, no authorization and therefore no new tariff will be requested for the EV Driver.</td></tr><tr><td>I08.FR.06</td><td>After a transaction has ended, that has an associated driver-specific tariff in transactionInfo.tariffld AND This driver-specific tariff is no longer in use at Charging Station</td><td>Charging Station SHALL remove the associated tariff with tariffld = transactionInfo.tariffld.</td><td>If the tariff is also in use at another EVSE it cannot be removed.</td></tr><tr><td>I08.FR.07</td><td></td><td>A driver-specific tariff is considered to be "in use" at a Charging Station after an ActivateResponse with a tariff has been received, and until an EVConnectionTimeout occurs or the transaction that is started for the idToken has finished.</td><td></td></tr><tr><td>I08.FR.08</td><td></td><td>CSMS SHALL ensure that TariffTypes with a different content have a different tariffld, such that the tarifflds in CostDetailsType records from historical transactions remain valid.</td><td>See use case I12 about reporting cost details at end of transaction. Choice of tariffld is up to CSMS. It can, for example, be a sequential number, a UUID or a hash value of tariff contents.</td></tr><tr><td>I08.FR.09</td><td>I08.FR.01</td><td>CSMS SHALL NOT provide the field validFrom in a TariffType in ActivateResponse.</td><td>Driver-specific tariffs have no validFrom date.</td></tr><tr><td>I08.FR.10</td><td>I08.FR.04 AND TariffType in ActivateResponse has a value for validFrom</td><td>ChargingStation SHALL ignore the value of validFrom.</td><td></td></tr><tr><td colspan="4">Tariff acceptance</td></tr><tr><td>I08.FR.20</td><td>I08.FR.04 AND EV Driver does not accept the tariff AND Charging Station has already started a transaction</td><td>Charging Station SHALL deauthorize the idToken of the transaction and send a TransactionEventRequest with triggerReason = "TariffNotAccepted".</td><td>There will be no tariffId and no cost associated with transaction. Without authorization, no energy will be delivered. If TxStopPoint contains "Authorized" or "PowerPathClosed" this situation will end the transaction with stoppedReason = DeAuthorized. (Same as I07.FR.30)</td></tr><tr><td>I08.FR.21</td><td>I08.FR.04 AND EV Driver does not accept the tariff AND Charging Station has not yet started a transaction</td><td>Charging Station SHALL deauthorize the idToken of EV Driver.</td><td>A transaction can still be started, for example, with TxStartPoint = "EVConnected" upon cable plug-in, but without authorization, no energy will be delivered. (Same as I07.FR.31)</td></tr><tr><td>I08.FR.22</td><td>I08.FR.04 AND EV Driver has implicitly or explicitly accepted the tariff</td><td>Charging Station SHALL associate the tariff with the transaction by including transactionInfo.tariffld once in the next TransactionEventRequest message.</td><td>Implicit acceptance of tariff can, for example, be plugging cable into EV. (Same as I07.FR.32)</td></tr><tr><td colspan="4">Failure to process driver-specific tariff</td></tr><tr><td>I08.FR.30</td><td>When Charging Station receives an AuthorizationResponse in which idTokenInfo.status = Accepted, but with a tariff field which it cannot process</td><td>Charging Station SHALL set device model variable TariffCostCtrlr.Problem to "true"</td><td>Set the Problem indicator for TariffCostCtrlr when tariff could not be processed.</td></tr><tr><td>I08.FR.31</td><td>I08.FR.30 AND Charging Station does not have a Delta monitor installed on TariffCostCtrlr.Problem</td><td>Charging Station SHALL send a NotifyEventRequest with trigger = Alerting, eventNotificationType = HardWiredNotification, component = "TariffCostCtrlr", variable = "Problem", actualValue = "true" and techCode optionally set to the applicable reason code from Appendix 5, to notify CSMS that it cannot support the tariff in the response.</td><td>techCode can be, for example, one of "TooManyElements", "OutOfMemory", "InternalError", "UnsupportedParam", etc.</td></tr><tr><td>I08.FR.31</td><td>I08.FR.30 AND HandleFailedTariff = "Deauthorize"</td><td>Charging Station SHALL NOT authorize idToken for charging.</td><td>Depending on TxStartPoint a transaction may already have started, but no energy will be delivered.</td></tr><tr><td>I08.FR.32</td><td>I08.FR.30 AND HandleFailedTariff = "UseDefault"</td><td>Charging Station SHALL authorize idToken for charging and SHALL use the default tariff</td><td>This is the same as if no tariff had been returned in AuthorizationResponse.</td></tr><tr><td>I08.FR.33</td><td>I08.FR.30 AND HandleFailedTariff = "CentralCost"</td><td>Charging Station SHALL authorize idToken for charging and SHALL NOT do local cost calculation</td><td>Cost will be calculated by CSMS.</td></tr><tr><td>I08.FR.34</td><td>I08.FR.33</td><td>CSMS SHALL do cost calculation for the transaction, as described in use cases I02 - Show EV Driver Running Total Cost During Charging and I03 - Show EV Driver Final Total Cost After Charging.</td><td>Cost will be calculated by CSMS.</td></tr><tr><td>I08.FR.35</td><td>I08.FR.04 AND the device model variable TariffCostCtrlr.Problem = "true"</td><td>Charging Station SHALL set device model variable TariffCostCtrlr.Problem to "false"</td><td>Remove previous Problem indicator for TariffCostCtrlr when tariff successfully received.</td></tr><tr><td>I08.FR.36</td><td>I08.FR.35 AND Charging Station does not have a Delta monitor installed on TariffCostCtrlr.Problem</td><td>Charging Station SHALL send a NotifyEventRequest with trigger = Alerting, eventNotificationType = HardWiredNotification, component = "TariffCostCtrlr", variable = "Problem", actualValue = "false"</td><td></td></tr></table>
+
+NOTE
+
+A "driver-specific tariff" is a tariff that was installed via anauthorizeResponse or ChangeTransactionTariffRequest message.
+
+# 109 - Local Cost Calculation - Get Tariffs
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Local Cost Calculation - Get Tariffs</td></tr><tr><td>2</td><td>ID</td><td>I09</td></tr><tr><td>3</td><td>Objective(s)</td><td>To get a list of tariffs (both default and driver-specific) currently in the Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>CSMS requests a list of tariffs from Charging Station. The response lists per EVSE which default tariff is installed. (A default tariff that was set on EVSE #0 is installed on every EVSE of the Charging Station). Driver-specific tariffs are reported with an idToken (after authorization) and also with an EVSE if already associated with a transaction.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>Charging Station has 2 EVSEs</td></tr><tr><td></td><td></td><td>1. CSMS sends SetDefaultTariffRequest for tariffld = "Default01" with validFrom = "2024-01-01T00:00:00Z" to evseld = 0 (all EVSEs).a. Charging Station accepts with SetDefaultTariffResponse.</td></tr><tr><td></td><td></td><td>2. Charging Station sends AuthorizationRequest for idToken = "ABCD1234".a. CSMS responds with AuthorizationResponse with tariffld = "MSP01" and authorizes idToken.b. Charging Stations starts a transaction for idToken on EVSE #1.</td></tr><tr><td></td><td></td><td>3. Charging Station sends AuthorizationRequest for idToken = "FBFB0000".a. CSMS responds with AuthorizationResponse with tariffld = "MSP02" and authorizes idToken.</td></tr><tr><td></td><td></td><td>4. CSMS sends GetTariffsRequest with evseld = 0 to Charging Station before a transaction is started on EVSE #2 and before and EVConnectionTimeout has occurred.</td></tr><tr><td></td><td></td><td>5. Charging Station returns a GetTariffsResponse with all default tariffs and driver-specific tariffs that are present on the Charging Station in an array of tariffAssignments:。tariffld = "Default01", tariffKind = DefaultTariff, validFrom = "2024-01-01T00:00:00Z", evselds = [1, 2]。tariffld = "MSP01", tariffKind = DriverTariff, evselds = [1], idTokens = ["ABCD1234"]。tariffld = "MSP02", tariffKind = DriverTariff, idTokens = ["FBFB0000"]</td></tr><tr><td>5</td><td>Prerequisites</td><td>Local cost calculation is supported.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td></td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td></td></tr></table>
+
+
+Figure 109. Sequence diagram GetTariffsRequest
+
+I09 - Get Tariffs - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I09.FR.01</td><td>Upon receiving a GetTariffsRequest with evseld = 0 and tariffs are present in Charging Station</td><td>Charging Station SHALL respond with GetTariffsResponse with status = Accepted and a list of tariffAssignments for all EVSEs.</td></tr><tr><td>I09.FR.02</td><td>Upon receiving a GetTariffsRequest with evseld > 0 and tariffs are present at EVSDEVeld</td><td>Charging Station SHALL respond with GetTariffsResponse with status = Accepted and a list of tariffAssignments for only the tariffs present in EVSDEVeld.</td></tr><tr><td>I09.FR.03</td><td>Upon receiving a GetTariffsRequest and no tariffs are present in Charging Station or provided EVSDEVeld</td><td>Charging Station SHALL respond with GetTariffsResponse without a tariffAssignments field and with a status = NoTariff</td></tr><tr><td>I09.FR.04</td><td>If GetTariffsResponse contains tariffs with tariffKind = DefaultTariff</td><td>tariffAssignments in the GetTariffsResponse SHALL contain for each tariffId the list of evselds where this tariff is installed.</td></tr><tr><td>I09.FR.05</td><td>If GetTariffsResponse contains tariffs with tariffKind = DriverTariff</td><td>tariffAssignments in the GetTariffsResponse SHALL contain for each tariffId the list of evselds where this tariff is installed.</td></tr><tr><td>I09.FR.06</td><td>I09.FR.05 AND An active transaction is associated with the tariff, i.e. transaction has transactionInfo.tariffld = tariffId</td><td>tariffAssignments element SHALL also contain the EVSE where transaction is active in evselds .</td></tr><tr><td>I09.FR.07</td><td>If GetTariffsResponse contains tariffs that have a value for validFrom</td><td>The tariffAssignments element in GetTariffsResponse SHALL contain validFrom for these tariffs.</td></tr></table>
+
+# I10 - Local Cost Calculation - Clear Tariffs
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Local Cost Calculation - Clear Tariffs</td></tr><tr><td>2</td><td>ID</td><td>I10</td></tr><tr><td>3</td><td>Objective(s)</td><td>To clear (remove) one or more default tariffs from a Charging Station</td></tr><tr><td>4</td><td>Description</td><td>CSMS requests to clear one or more default tariffs from a Charging Station.ClearTariffsRequest only applies to default tariffs. Driver-specific tariffs are automatically removed when no longer in use. A default tariff that is currently in use can be cleared, but remains valid where it is used.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>Charging Station has 2 EVSEs1. A transaction is active on EVSE #1 with default tariff "Default01" and a transaction with a driver-specific tariff for idToken "FBFB0000" is active on EVSE #2.2. The following tariffs are present, as would be shown by a GetTariffsResponse:。tariffld = "Default01", tariffKind = DefaultTariff, evselds = [1, 2]。tariffld = "MSP01", tariffKind = DriverTariff, idTokens = ["FBFB0000"], evselds = [2]3. CSMS removes default tariffs "Default01" via ClearTariffsRequest with tarifflds = ["Default01"].a. Charging Station clears "Default01" from both EVSE #1 and EVSE #2, but the tariff remains in use for the currently active transaction on EVSE #1.i. The driver-specific tariff "MSP01" in use on EVSE #2 is not affected.b. Charging Station responds with ClearTariffsResponse with 1 clearTariffResult item with status = Accepted for tariffld "Default01".</td></tr><tr><td>5</td><td>Prerequisites</td><td>Local cost calculation is supported.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>One or more tariffs are cleared from Charging Station, but running transactions are not affected.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td></td></tr></table>
+
+
+Figure 110. Sequence diagram ClearTariffsRequest
+
+I10 - Clear Tariffs - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td></tr><tr><td>I10.FR.01</td><td>Upon receiving a ClearTariffsRequest without parameters and tariffs are present in Charging Station</td><td>Charging Station SHALL clear all tariffs in Charging Station and respond with ClearTariffsResponse with a list of clear TariffResult for each cleared tariffId and status = Accepted.</td></tr><tr><td>I10.FR.02</td><td>Upon receiving a ClearTariffsRequest with the parameter tarifflds</td><td>Charging Station SHALL clear all tariffs in Charging Station that have a tariffId that is present in the parameter tarifflds, and respond with ClearTariffsResponse with a list of cleared tarifflds and status = Accepted.</td></tr><tr><td>I10.FR.03</td><td>Upon receiving a ClearTariffsRequest with the parameter evseld</td><td>Charging Station SHALL clear all tariffs in Charging Station that have been set for EVSE evseld, and respond with ClearTariffsResponse with a list of cleared tarifflds and status = Accepted.</td></tr><tr><td>I10.FR.05</td><td>Upon receiving a ClearTariffsRequest with both parameters tarifflds and evseld</td><td>Charging Station SHALL only clear tariffs that match both parameters, and respond with ClearTariffsResponse with a list of cleared tarifflds and status = Accepted.</td></tr><tr><td>I10.FR.06</td><td>Upon receiving a ClearTariffsRequest AND no tariffs exist, or no tariffss exist that match the parameters tarifflds and/or evseld.</td><td>Charging Station SHALL respond with ClearTariffsResponse without tarifflds and with status = NoTariff.</td></tr><tr><td>I10.FR.07</td><td>Upon receiving a ClearTariffsRequest that affects a tariff is associated with a transaction, i.e. transaction has transactionInfo.tariffld = tariffId</td><td>Charging Station SHALL clear this tariff and report this tariff in clear TariffsResult with tariffId and status = Accepted, but SHALL continue to use this tariff in the transaction until it ends.</td></tr></table>
+
+# I11 - Local Cost Calculation - Change transaction tariff
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Local Cost Calculation - Change transaction tariff</td></tr><tr><td>2</td><td>ID</td><td>I11</td></tr><tr><td>3</td><td>Objective(s)</td><td>Change the tariff to use during a transaction</td></tr><tr><td>4</td><td>Description</td><td>CSMS changes the tariff that is associated with a transaction. This may be needed when dealing with unexpected price changes.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>A transaction is in progress1. CSMS sends a ChangeTransactionTariffRequest for transactionId with a new tariff.2. Charging Station responds with ChangeTransactionTariffResponse with status = Accepted.3. Charging Station starts applying the new tariff to the transaction.a. Charging Stations sends a TransactionEventRequest with triggerReason = TariffChanged and transactionInfo.tariffld with the id of the new tariff (and other relevant fields).4. Charging Station optionally displays the new tariff that is being used. (This depends on UI design and regulations).</td></tr><tr><td>5</td><td>Prerequisites</td><td>A transaction and associated tariff are active on the Charging Station.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Charging Station continues local cost calculation with the new tariff.</td></tr><tr><td>7</td><td>Error Handling</td><td>If Charging Station does not accept the ChangeTransactionTariffRequest then the existing tariff remains active.</td></tr><tr><td>8</td><td>Remarks</td><td>Changing a tariff during a transaction may not be allowed at all in certain legislations, or only unless specifically agreed upon by the customer.Dynamic prices based on day-ahead energy prices can already be part of a tariff with restrictions based on time of day, and do not require the tariff to be changed during a transaction.Changing of a tariff is done for a transaction and not for a driver (idToken), because the same driver could have a transaction on another EVSE as well for which no tariff update is needed.</td></tr></table>
+
+# Charging Station
+
+CSMS changes tariff for transaction 1234
+
+ChangeTransactionTariffRequest( transactionId = 1234, tariff = { ... } )
+
+ChangeTransactionTariffResponse( status = Accepted )
+
+Figure 111. Sequence diagram Change TransactionTariffRequest
+
+# I11 - Change Transaction Tariff - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Notes</td></tr><tr><td>I11.FR.01</td><td>When a Charging Station receives a ChangeTransactionTariffRequest and does not support local cost calculation</td><td>Charging Station SHALL respond with an RPC CALLERROR "NotSupported" (or "NotImplemented" if the message has not been implemented).</td><td></td></tr><tr><td>I11.FR.02</td><td>When a Charging Station receives a ChangeTransactionTariffRequest and tariff has more elements than TariffMaxElements</td><td>Charging Station SHALL respond with ChangeTransactionTariffResponse with status = TooManyElements.</td><td></td></tr><tr><td>I11.FR.03</td><td>Upon receiving a ChangeTransactionTariffRequest with a tariff structure that contains elements with a TariffConditionsType or TariffConditionsFixedType AND TariffCostCtrl CONDITIONSSupported = false (i.e. Charging Station does not support conditions)</td><td>Charging Station SHALL respond with ChangeTransactionTariffResponse with status = ConditionNotSupported.</td><td></td></tr><tr><td>I11.FR.04</td><td>When a Charging Station receives a ChangeTransactionTariffRequest and transactionId does not exist or is no longer active</td><td>Charging Station SHALL respond with ChangeTransactionTariffResponse with status = TxNotFound.</td><td></td></tr><tr><td>I11.FR.05</td><td>When a Charging Station receives a ChangeTransactionTariffRequest and tariff has a value for currency that differs from the currently active tariff</td><td>Charging Station SHALL respond with ChangeTransactionTariffResponse with status = NoCurrencyChange.</td><td>It is not allowed to switch currency within a transaction.</td></tr><tr><td>I11.FR.06</td><td>When a Charging Station receives a ChangeTransactionTariffRequest AND NOT (I11.FR.01 to I11.FR.05)</td><td>Charging Station SHALL respond with ChangeTransactionTariffResponse with status = Accepted.</td><td>Change of tariff is accepted when none of the above error conditions apply.</td></tr><tr><td>I11.FR.07</td><td>I11.FR.06</td><td>Charging Station SHALL send a TransactionEventRequest with triggerReason = TariffChanged and transactionInfo.tariffld set to the id of the new tariff (and include any other relevant fields).</td><td>The new tariff is applied regardless whether a tariff was already associated with transaction or not.</td></tr><tr><td>I11.FR.08</td><td>I11.FR.07</td><td>Charging Station SHALL from this moment on apply the new tariff to the transaction.</td><td>There is no retroactive calculation of tariffs.</td></tr></table>
+
+# I12 - Local Cost Calculation - Cost Details of Transaction
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Local Cost Calculation - Cost Details of Transaction</td></tr><tr><td>2</td><td>ID</td><td>I12</td></tr><tr><td>3</td><td>Objective(s)</td><td>To calculate cost and provide CSMS with details about the cost</td></tr><tr><td>4</td><td>Description</td><td>Charging Station calculates cost of the transaction locally and returns a break-down of the cost at end of the transaction for every charging period for which a different tariff element was active. CSMS can use this to generate invoices or Charge Detail Records for EMSPs.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>Cost calculation during transaction
+1. EV Driver starts charging
+2. If a driver-specific tariff was provided at authorization, use the driver-specific tariff.
+3. Else use the default tariff.
+4. Charging Station continuously displays running cost to EV Driver.
+5. While the transaction is active Charging Station provides running cost updates in TransactionEventRequest messages, depending on RunningCostEnabled.
+6. During the transaction Charging Station may include (depending on RunningCostEnabled) in the TransactionEventRequest with eventType = Updated a costDetails field of type CostDetailsType with a breakdown of the cost of the transaction.
+a. chargingPeriods are omitted from costDetails that are sent during a transaction in order to limit the amount of data.
+b. costDetails includes the running total price for time, energy, fixed fee, reservation and the overall running total price of the transaction.
+7. When the transaction ends Charging Station includes in the TransactionEventRequest with eventType = Ended a costDetails field of type CostDetailsType with a breakdown of the cost of the transaction.
+a. costDetails has a list of one or more chargingPeriods, where each period corresponds to a period with different pricing.
+b. costDetails also includes the total price for time, energy, fixed fee, reservation and the overall total price of the transaction.</td></tr><tr><td>5</td><td>Prerequisites</td><td>A tariff was set via SetDefaultTariffRequest or in response to an AuthorizationRequest. TariffEnabled = true and CostEnabled = true.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>CSMS received a costDetails with a breakdown of costs at end of transaction.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>The running cost sent with a TransactionRequest with eventType = Updated serves to provide details on running cost during a transaction. CSMS can, for example, communicate these values to the driver via an app. The field costDetails when sent as running cost does not contain any chargingPeriods to limit data usage during frequent updates.</td></tr></table>
+
+
+Figure 112. Sequence diagram for cost details
+
+# I12 - Cost Details of Transaction - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Notes</td></tr><tr><td>I12.FR.01</td><td>When a transaction.transactionInfo.tariffld is set AND TariffCostCtrl.Enabled[Cost] = true AND TariffCostCtrl.Enabled[Tariff] = true</td><td>Charging Station SHALL provide a cost breakdown in the costDetails field of type CostDetailsType in the final TransactionEventRequest with eventType = Ended of the transaction.</td><td>Tariffs and local cost calculation are supported and a tariff is associated with transaction. Tariff can be set by SetDefaultTariffRequest,authorizeResponse or ChangeTransactionTariffRequest.</td></tr><tr><td>I12.FR.02</td><td>I12.FR.01 AND TariffCostCtrl.Enabled[RunningCost] = true</td><td>Charging Station SHALL provide a costDetails field of type CostDetailsType in TransactionEventRequest with eventType = Started and every TariffCostCtrlInterval[Cost] seconds during the transaction for eventType = Updated.</td><td>Providing running cost updates needs to be enabled via TariffCostCtrl.Enabled[Running Cost]. See RunningCostEnabled and CostInterval.</td></tr><tr><td>I12.FR.03</td><td>I12.FR.02 AND If a TransactionEventRequest is sent only to report a running cost update</td><td>The TransactionEventRequest SHALL contain a triggerReason = RunningCost.</td><td>A running cost update is sent every CostInterval seconds, which can be part of a TransactionEventRequest that is sent for another triggerReason.</td></tr><tr><td>I12.FR.04</td><td>I12.FR.01</td><td>Each chargingPeriods element in costDetails SHALL contain a reference in the field tariffId to the tariff that was used.</td><td></td></tr><tr><td>I12.FR.05</td><td>When costs are calculated from a TariffFixedPriceType</td><td>The total of these costs SHALL be in totalCostfixed element</td><td></td></tr><tr><td>I12.FR.06</td><td>If the transaction was authorized by an idToken or groupldToken that was related to a reservation, as defined in Introduction</td><td>Charging Station SHALL evaluate TariffType.reservationTime and TariffType.reservationFixed elements, once at start of the transaction.</td><td>Reservation cost are applied once at start of transaction. See H03.FR.09.</td></tr><tr><td>I12.FR.07</td><td>I12.FR.06 AND Costs are calculated from TariffType.reservationTime</td><td>The total amount of reservation time, calculated as the duration from the time the ReserveNowRequest was received until start of the transaction, SHALL be in the totalUsage.reservationTime field and total of these costs SHALL be in totalCost.reservationTime element</td><td>This is a time-based reservation cost</td></tr><tr><td>I12.FR.08</td><td>I12.FR.06 AND Costs are calculated from a TariffType.reservationFixed</td><td>The total of these costs SHALL be in totalCost.reservationFixed element</td><td>This is a fixed reservation cost.</td></tr><tr><td>I12.FR.09</td><td>When costs are calculated from TariffEnergyPriceType</td><td>The total amount of energy SHALL be in the totalUsage.energy field and total of these costs SHALL be in totalCost.energy element</td><td></td></tr><tr><td>I12.FR.10</td><td>When costs are calculated from TariffType.chargingTime</td><td>The total amount of charging time SHALL be in the totalUsage.chargingTime field and total of these costs SHALL be in totalCost.chargingTime element</td><td></td></tr><tr><td>I12.FR.11</td><td>When costs are calculated from TariffType.idleTime</td><td>The total amount of idle time SHALL be in the totalUsage.idleTime field and total of these costs SHALL be in totalCost.idleTime element</td><td></td></tr><tr><td>I12.FR.12</td><td></td><td>PriceType SHALL have the cost excluding tax in the exclTax field.</td><td></td></tr><tr><td>I12.FR.13</td><td>When a PriceType has one or more associated TaxRateType</td><td>The inclTax field in PriceType SHALL be calculated as exclTax * taxRates-tax for the taxRates element with stack = 0 (or absent), and then the taxRates element(s) with stack = 1 is/are applied to the result for stack = 0, and then the element(s) taxRates with stack = 2 is/are applied to the result for stack = 1, etc.</td><td>For example, an "energy tax" (stack 0) is applied to the net price, and a "VAT" (stack 1) is applied on top of the net price including "energy tax". There can be multiple taxRates elements with the same stack value.</td></tr><tr><td>I12.FR.14</td><td>When Charging Station is not able to calculate the CostDetailsType (partly or entirely)</td><td>Charging Station SHALL set the field failureToCalculate to true and optionally add a failureReason with a human-readable text about the reason. Charging Station MAY include any values that it was able to calculate.</td><td></td></tr><tr><td>I12.FR.15</td><td>I12.FR.14</td><td>Charging Station MAY stop sending CostDetailsType elements in TransactionEventRequest messages for the remainder of the transaction.</td><td></td></tr><tr><td>I12.FR.16</td><td></td><td>The field currency in TotalCostType SHALL match the currency of the tariff that was used.</td><td></td></tr><tr><td>I12.FR.17</td><td></td><td>The field TotalCostType.total SHALL contain the totals of all exclTax and inclTax parts of fixed, energy, chargingTime, idleTime, reservationTime and reservationFixed fields.</td><td>total is the sum of all costs.</td></tr><tr><td>I12.FR.18</td><td>I12.FR.14</td><td>Charging Station SHALL set device model variable TariffCostCtrl.Problem to "true"</td><td>Set the Problem indicator for TariffCostCtrl when tariff could not be calculated.</td></tr><tr><td>I12.FR.19</td><td>I12.FR.14 AND Charging Station does not have a Delta monitor installed on TariffCostCtrl.Problem</td><td>Charging Station SHALL send a NotifyEventRequest with trigger = Alerting, eventNotificationType = HardWiredNotification, component = "TariffCostCtrl", variable = "Problem", actualValue = "true"</td><td></td></tr><tr><td colspan="4">Tariff evaluation</td></tr><tr><td>I12.FR.30</td><td>I12.FR.01</td><td>Charging Station SHALL evaluate the conditions of the TariffFixedPriceType once at start of the transaction.</td><td>Fixed fee is only applied once in transaction.</td></tr><tr><td>I12.FR.31</td><td>I12.FR.01 AND TariffCostCtrlInterval[Tariff] > 0</td><td>Charging Station SHALL evaluate the conditions of a TariffEnergyPriceType and TariffTimePriceType for current, power and energy at least every TariffCostCtrlInterval[Tariff] seconds</td><td>Conditions for date and time need to be followed exactly (as these are predictable), but changes in current, power and energy only need to be monitored every TariffInterval seconds. The use of tariffs requires that TariffCostCtrl.Enabled[Tariff] = true</td></tr><tr><td>I12.FR.32</td><td>I12.FR.01 AND TariffCostCtrlInterval[Tariff] = 0</td><td>Charging Station SHALL evaluate the conditions of a TariffEnergyPriceType, TariffTimePriceType for current, power and energy as frequent as possible.</td><td>See TariffInterval.</td></tr><tr><td>I12.FR.33</td><td>I12.FR.31 OR I12.FR.32</td><td>Charging Station SHALL create lists existing of all TariffEnergyPriceType and TariffTimePriceType for which TariffConditionsType is applicable at the moment.</td><td>This is the "applicable element list" in which multiple conditions may be applicable at this point in time.</td></tr><tr><td>I12.FR.34</td><td>I12.FR.33</td><td>Charging Station SHALL select for each TariffEnergyPriceType (energy) and TariffTimePriceType (chargingTime, idleTime) the first Tariff(Energy/Time)PriceType element from the "applicable element list" to contribute to the cost calculation.</td><td>This is the "used element list".</td></tr><tr><td>I12.FR.35</td><td>Whenever the "used element list" changes, because new TariffConditionsType apply</td><td>Charging Station SHALL end the current chargingPeriods entry (ChargingPeriodType) of CostDetailsType, and SHALL fill the dimensions fields with data of the CostDimensionType.</td><td>Based on the values in dimensions and the tariffId it is possible to verify/recalculate the cost.</td></tr><tr><td>I12.FR.36</td><td>I12.FR.35</td><td>Charging Station SHALL start a new chargingPeriods entry in CostDetailsType with startPeriod set to current time.</td><td></td></tr><tr><td>I12.FR.37</td><td>When a TariffType is in use for cost calculation at the moment that local time shifts as a result of beginning or ending of daylight saving time</td><td>The execution of cost calculation SHALL follow local time for startTimeOfDay and endTimeOfDay in TariffConditionsType.</td><td>This means, for example, that a TariffEnergyPriceType that had ended at 02:30h suddenly becomes valid again half an hour later, when local time jumps back to 02:00h because daylight-saving time ends.</td></tr><tr><td>I12.FR.38</td><td>When TariffType contains a minCost AND (at the end of the transaction the total cost excluding taxes (in costsDetails) is lower than the cost defined in minCost.exclTax OR at the end of the transaction the total cost including taxes is lower than the cost defined in minCost.inclTax )</td><td>Charging Station SHALL replace the totalCost element in CostDetailsType with a new TotalCostType field that has its PriceType field fixed set to the value of minCost, typeOfCost to MinCost, and currency set to currency of the tariff.</td><td>This replaces the calculated cost with the minimum minCost. chargingPeriods and totalUsage fields in CostDetailsType remain unaffected.</td></tr><tr><td>I12.FR.39</td><td>When TariffType contains a maxCost AND (during the transaction the total cost excluding taxes reaches the cost defined in maxCost.exclTax OR during the transaction the total cost including taxes reaches the cost defined in maxCost.inclTax )</td><td>Charging Station SHALL stop calculating any more costs and freeze the values in TotalCostType and set the field typeOfCost = MaxCost.</td><td>No more costs are added during the remainder of the transaction. Total amounts of prices and taxes stay at the value they had at the moment that maxCost was reached.</td></tr><tr><td>I12.FR.40</td><td>I12.FR.39</td><td>Charging Station SHALL continue to calculate usage and fill chargingPeriods and totalUsage fields in CostDetailsType</td><td>This ensures that proper usage data can be displayed on the receipt.</td></tr><tr><td>I12.FR.41</td><td>NOT (I12.FR.38 OR I12.FR.39)</td><td>Charging Station SHALL set typeOfCost in TotalCostType = NormalCost.</td><td>Calculation can start with typeOfCost = NormalCost and overrule by Min/MaxCost when applicable.</td></tr><tr><td>I12.FR.42</td><td>When a transaction is ending AND before Charging Station sends the TransactionEventRequest with eventType = Ended</td><td>Charging Station SHALL finish the tariff calculation and update the CostDetailsType element to be included in the TransactionEventRequest</td><td></td></tr><tr><td>I12.FR.43</td><td>I12.FR.42 AND cost calculation was successful AND the device model variable TariffCostCtrl.Problem = "true"</td><td>Charging Station SHALL set device model variable TariffCostCtrl.Problem to "false"</td><td>Remove previous Problem indicator for TariffCostCtrl when tariff successfully calculated.</td></tr><tr><td>I12.FR.44</td><td>I12.FR.43 AND Charging Station does not have a Delta monitor installed on TariffCostCtrl.Problem</td><td>Charging Station SHALL send a NotifyEventRequest with trigger = Alerting, eventNotificationType = HardWiredNotification, component = "TariffCostCtrl", variable = "Problem", actualValue = "false"</td><td></td></tr></table>
+
+# J. Meter Values
+
+# Chapter 1. Introduction
+
+This Functional Block describes the functionality that enables a Charging Station to send periodic, possibly clock-aligned MeterValues.
+
+The transfer of the MeterValues from the Charging Station to the CSMS will be taken over by the new Device Management Monitoring feature, however this mechanism has not been proven in the field yet. So the old MeterValuesRequest message remains available for use for now.
+
+Extensive metering data relating to transactions can be recorded and transmitted in different ways depending on its intended purpose. There are two obvious use cases (but the use of meter values is not limited to these two):
+
+Transaction Meter Values
+
+- Clock-Aligned Meter Values
+
+Both types of meter readings MAY be reported in the meterValue element of the TransactionEventRequest message. Clock-Aligned Meter Values MAY be reported in standalone MeterValuesRequest messages.
+
+# Chapter 2. Configuration
+
+This section is normative.
+
+# 2.1. Transaction Meter Values
+
+Updated in OCPP 2.1
+
+Frequent (e.g. 1-5 minute interval) meter readings taken and transmitted (usually in "real time") to the CSMS, to allow it to provide information updates to the EV user (who is usually not at the Charging Station), via web, app, SMS, etc., as to the progress of the transaction. In OCPP, this is called "sampled meter data", as the exact frequency and time of readings is not very significant, as long as it is "frequent enough". "Sampled meter data" can be configured with the following Configuration Variables:
+
+- SampledDataTxStartedMeasurands
+- SampledDataTxUpdatedMeasurands
+- SampledDataTxUpdatedInterval
+- SampledDataTxEndedMeasurands
+- SampledDataTxEndInterval
+- SampledDataUpstreamMeasurands
+- SampledDataUpstreamInterval
+
+SampledDataTxUpdatedInterval is the time (in seconds) between sampling of metering (or other) data, intended to be transmitted by TransactionEventRequest (eventType = Updated) messages during a transaction. A value of "0" (numeric zero), by convention, is to be interpreted to mean that no sampled data should be transmitted.
+
+SampledDataTxEndInterval is the time (in seconds) between sampling of metering (or other) data, intended to be transmitted in the TransactionRequest (eventType = Ended) message.
+
+SampledDataTxStartedMeasurands is a comma separated list that prescribes the set of measurands to be included in the meterValues field of a TransactionRequest (eventType = Started).
+
+SampledDataTxUpdatedMeasurands is a comma separated list that prescribes the set of measurands to be included in the meterValues field of a TransactionRequest (eventType = Updated), every SampledDataTxUpdatedInterval seconds.
+
+SampledDataTxEndesaand is a comma separated list that prescribes the sampled measurands to be included in the meterValues field of a TransactionRequest (eventType = Ended), these measurands have to be taken every SampledDataTxEndeaInterval seconds from the start of the transaction, and will only be sent in the TransactionRequest (eventType = Ended).
+
+SampledDataUpstreamMeasurands is a comma separated list that prescribes the set of measurands to be included in the meterValues field of a TransactionEventRequest (eventType = Started/Updated), every SampledDataUpstreamInterval seconds.
+
+# WARNING
+
+Upstream measurands may be considered to be privacy-sensitive data. As such, this may be subject to regulation and may have legal liability implications. An explicit agreement may be required to allow this.
+
+Care should be taken to ensure that the amount of measurands that is expected at the end of a transaction fits in one TransactionEventRequest(eventType=Ended) message. Keep the number of measurands in SampledDataTxEndesa to a minimum and configure a large interval in SampledDataTxEndInterval to keep the number of samples small.
+
+# NOTE
+
+Please note: Transaction related MeterValues are never transmitted in MeterValuesRequest.
+
+# 2.2. Clock-Aligned Meter Values
+
+Updated in OCPP 2.1
+
+Grid Operator might require meter readings to be taken from fiscally certified energy meters, at specific Clock aligned times (usually every quarter hour, or half hour).
+
+"Clock-Aligned Meter Values" can be configured with the following Configuration Variables:
+
+- AlignedDataMeasurands
+- AlignedDataInterval
+- AlignedDataTxEndedMeasurands
+- AlignedDataTxEndedInterval
+- AlignedDataSendDuringIdle
+- AlignedDataUpstreamMeasurands
+- AlignedDataUpstreamInterval
+
+AlignedDataInterval is the size of the clock-aligned data interval (in seconds). This defines the set of evenly spaced meter data aggregation intervals per day, starting at 00:00:00 (midnight), at which time the Charging Station should take measurements and send them to the CSMS in a MeterValuesRequest message. A value of "0" (numeric zero), by convention, is to be interpreted to mean that no clock-aligned data should be transmitted.
+
+AlignedDataTxEndPeriod is the size of the clock-aligned data interval (in seconds). This defines the set of evenly spaced meter data aggregation intervals per day, starting at 00:00:00 (midnight) intended to be transmitted in the TransactionRequest (eventType = Ended) message.
+
+For example, a value of 900 (15 minutes) indicates that every day should be broken into 96 15-minute intervals, starting at 0:00 and then measured every 15 minutes: 0:15, 0:30, 0:45, 1:00, 1:15 etc.
+
+AlignedDataMeasurands is a comma separated list that prescribes the set of measurands to be included in a MeterValuesRequest PDU, every AlignedDataInterval seconds.
+
+AlignedDataTxEndeMeasurands is a comma separated list that prescribes the set of clock-aligned periodic measurands to be included in the meterValue elements of TransactionRequest (eventType = Ended) PDU for every
+
+AlignedDataTxEndInterval of the transaction.
+
+- AlignedDataUpstreamMeasurands
+- AlignedDataUpstreamInterval
+
+AlignedDataSendDuringIdle can be used to only send clock aligned meter values when there are no ongoing transactions.
+
+# NOTE
+
+Clock-aligned meter values for an EVSE that is involved in a transaction MAY be transmitted in TransactionEventRequests with context = Sample. Clock instead of in MeterValuesRequests.
+
+# 2.3. Multiple Locations/Phases
+
+Updated in OCPP 2.1
+
+When a Charging Station has measurands configured in SampledDataTxStarted/Updated/EndedMeasurands and/or AlignedDataMeasurands/AlignedDataTxEndedMeasurands, that can be measured on multiple locations or phases, then all possible locations and/or phases SHALL be reported. This does not include location Upstream. Measurands to be reported for Upstream are configured in SampledData/AlignedDataUpstreamMeasurands.
+
+For example: A Charging Station capable of measuring Current.Import on Inlet (all 3 phases) (grid connection) and Outlet (3 phases per EVSE on both its EVSEs). Current.Import is set in AlignedDataMeasurands. AlignedDataInterval is set to 900 (seconds). Then the Charging Station should send: (every 15 minutes)
+
+- a MeterValuesRequest with: evseld = 0; with 3 SampledValue elements, one per phase with location = Inlet.
+- a MeterValuesRequest with: evseld = 1; with 3 SampledValue elements, one per phase with location = Outlet.
+- a MeterValuesRequest with: evsold = 2; with 3 SampledValue elements, one per phase with location = Outlet.
+
+# NOTE
+
+When the configuration variable SampleDataRegisterValuesWithoutPhases has the value true, then meter values of measurand Energy.Active.Import.Register will only report the total energy over all phases without reporting the individual phase values.
+
+# 2.4. Signed Meter Values
+
+OCPP 2.1 supports signed meter values. When a Charging Station supports signed meter values it can use the Configuration Variables AlignedDataSignReadings and SampledDataSignReadings to report this. The CSMS can then use this same
+
+variables to turn the use of signed meter values on or off.
+
+When enabled, the Charging Station shall put the signed meter value in the SignedMeterValue field of the SampledValue.
+
+# 2.5. Configuration Examples
+
+Below are a few examples of configurations for transaction-related measurands:
+
+# Only sampled energy register values for start/stop at end of transaction
+
+- SampledDataCtrl.TxStartedMeasurands and TxUpdatedMeasurands are left empty.
+- SampleDataCtrl.TxEndedMeasurands = "Energy.Active.Import.Register"
+- SampledDataCtrl.TxEndInterval = 0
+
+# Values of energy register at start, during and end of transaction
+
+- SampledDataCtrl.TxStartedMeasurands = "Energy.Active.Import.Register"
+- SampledDataCtrl.TxUpdatedMeasurands = "Energy.Active.Importantly/register"
+- SampledDataCtrl.TxUpdatedInterval = 300 (every 5 minutes)
+- SampleDataCtrl.TxEndedMeasurands = "Energy.Active.Importantly.
+- SampledDataCtrl.TxEndInterval = 0
+
+# Only clock-aligned register values during transaction and start/stop at end
+
+- SampledDataCtrl.TxStartedMeasurands and TxUpdatedMeasurands are left empty.
+- SampleDataCtrl.TxEndedMeasurands = "Energy.Active.Import.Register"
+- SampledDataCtrl.TxEndInterval = 0
+- AlignedDataCtrl.Measurands = "Energy.Active.Import.Register"
+- AlignedDataCtrlInterval = 300 (every 5 minutes)
+
+# Chapter 3. Use cases & Requirements
+
+# 3.1. MeterValues
+
+# J01 - Sending Meter Values not related to a transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Sending Meter Values not related to a transaction</td></tr><tr><td>2</td><td>ID</td><td>J01</td></tr><tr><td>3</td><td>Objective(s)</td><td>To sample the electrical meter or other sensor/transducer hardware to provide information about the Charging Stations' Meter Values.</td></tr><tr><td>4</td><td>Description</td><td>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.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends a MeterValuesRequest message, for offloading Meter Values to the CSMS.
+2. Upon receipt of a MeterValuesRequest message, the CSMS responds with a MeterValuesResponse message.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station is configured to send Meter values every XX seconds. No transaction is running.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+n/a
+Failure postcondition:
+n/a</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The phase field is not applicable to all Measurands.
+The phase rotation of a Connector relative to the grid connection can be derived by querying the PhaseRotation Configuration Variables of all components in the chain from grid connection up to Connector.
+The nature of each sampledValue is determined by the optional Measurand, context, location, unit and phase fields.
+The optional SignedMeterValue field can contain digitally signed binary meter value data.</td></tr></table>
+
+
+Figure 113. Sequence Diagram: Sending Meter Values
+
+# J01 - Sending Meter Values not related to a transaction - Requirements
+
+Table 92. J01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>J01.FR.01</td><td></td><td>The Charging Station MAY sample the energy meter (or other sensor/transducer hardware) to provide extra information about its Meter Values.</td><td>It is up to the Charging Station when it will send Meter Values. This can be configured using the SetVariablesRequest message to data acquisition intervals and specify data to be acquired & reported.</td></tr><tr><td>J01.FR.02</td><td></td><td>The MeterValuesRequest message SHALL contain the id of the EVSE from which samples were taken.</td><td></td></tr><tr><td>J01.FR.03</td><td>J01.FR.02 AND The evseld is 0.</td><td>The MeterValuesRequest message SHALL be associated with the entire Charging Station.</td><td></td></tr><tr><td>J01.FR.04</td><td>J01.FR.03 AND Measurand is energy related.</td><td>The sample SHALL be taken from the main energy meter.</td><td></td></tr><tr><td>J01.FR.05</td><td>If all captured at the same point in time.</td><td>Each MeterValue element SHALL contain a timestamp.</td><td></td></tr><tr><td>J01.FR.06</td><td>If all captured at the same point in time.</td><td>Each MeterValue(s) element SHALL contain a set of one or more individual SampledValue elements.</td><td></td></tr><tr><td>J01.FR.07</td><td></td><td>The optional measurand field SHALL specify the type of value being measured/reported.</td><td></td></tr><tr><td>J01.FR.08</td><td></td><td>The optional context field SHALL specify the reason/event triggering the reading.</td><td></td></tr><tr><td>J01.FR.09</td><td></td><td>The optional location field SHALL specify where the measurement is taken.</td><td>(e.g. Inlet, Outlet).</td></tr><tr><td>J01.FR.10</td><td></td><td>The optional phase field SHALL specify to which phase or phases of the electric installation the value applies.</td><td></td></tr><tr><td>J01.FR.11</td><td></td><td>The Charging Station SHALL report all phase number dependent values from the electrical meter (or grid connection when absent) point of view.</td><td></td></tr><tr><td>J01.FR.13</td><td>When reporting phase rotation of a component</td><td>The Charging Station SHALL report the phase rotation relative to the grid connection</td><td></td></tr><tr><td>J01.FR.14</td><td>When AlignedDataCtrlInterval > 0 AND EVSE for which measurands are sent, is not involved in a transaction</td><td>The Charging Station SHALL send a MeterValuesRequest message to the CSMS for the measurands in AlignedDataCtrl.Measurands at every AlignedDataCtrlInterval for all evselds, locations and phases for which a configured measurand is supported.</td><td>It is possible that certain measurands are not available for every location. For example, evseld = 0 (grid meter) will not have a "Current.Offered" or "SoC" measurand. See also J01.FR.22</td></tr><tr><td>J01.FR.15</td><td>J01.FR.14 AND Amount of measurands is too much for 1 MeterValuesRequest</td><td>The Charging Station MAY use multiple MeterValuesRequest messages to send all measurands.</td><td></td></tr><tr><td>J01.FR.17</td><td></td><td>The timestamp of a MeterValue SHALL apply to all its SampledValues.</td><td></td></tr><tr><td>J01.FR.18</td><td>When CSMS receives a MeterValuesRequest</td><td>CSMS SHALL respond with MeterValuesResponse.</td><td>Failing to respond with MeterValuesResponse might cause the Charging Station to try the same message again.</td></tr><tr><td>J01.FR.19</td><td>If AlignedDataSendDuringIdle is set to true for an EVSE AND the specified EVSE has an ongoing transaction.</td><td>The Charging Station SHALL stop sending the clock aligned meter values for this EVSE.</td><td></td></tr><tr><td>J01.FR.20</td><td>If AlignedDataSendDuringIdle is set to true for a Charging Station AND the Charging Station has an ongoing transaction.</td><td>The Charging Station SHALL stop sending the clock aligned meter values for all EVSEs and the main power meter.</td><td></td></tr><tr><td>J01.FR.21</td><td>AlignedDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values from components that support data signing and put them in the signedMeterValue field.</td><td></td></tr><tr><td>J01.FR.22</td><td>When AlignedDataCtrlInterval > 0 AND EVSE for which measurands are sent, is involved in a transaction</td><td>The Charging Station SHALL send either: - a MeterValuesRequest message or - a TransactionEventRequest with triggerReason = Sample.Clock to the CSMS for the measurands in AlignedDataCtrl.Measurands at every AlignedDataCtrl.Interval.</td><td>See also J01.FR.14</td></tr></table>
+
+# J02 - Sending transaction related Meter Values
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Sending transaction related Meter Values</td></tr><tr><td>2</td><td>ID</td><td>J02</td></tr><tr><td>3</td><td>Objective(s)</td><td>To sample the energy meter or other sensor/transducer hardware to provide information about the Charging Stations' transaction related Meter Values.</td></tr><tr><td>4</td><td>Description</td><td>The Charging Station samples the energy meter or other sensor/transducer hardware to provide information about its transaction related Meter Values. Depending on configuration settings, the Charging Station will send Meter Values during a transaction.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends a TransactionRequest (eventType = Updated) message, for offloading Meter Values to the CSMS.
+2. Upon receipt of a TransactionRequest message, the CSMS responds with a TransactionResponse message.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station is configured to send Meter Values every XX seconds.
+A transaction is running.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+n/a
+Failure postcondition:
+n/a</td></tr><tr><td>7</td><td>Error handling</td><td>When Offline, the Charging Station MUST queue any transaction-related messages (Meter Values belonging to a transaction) that it would have sent to the CSMS if the Charging Station had been online.</td></tr><tr><td>8</td><td>Remark(s)</td><td>The phase field is not applicable to all Measurands.
+The phase rotation of a Connector relative to the grid connection can be derived by querying the PhaseRotation Configuration Variables of all components in the chain from grid connection up to Connector.
+The nature of each sampledValue is determined by the optional Measurand, context, location, unit and phase fields.
+The optional SignedMeterValue field can contain digitally signed binary meter value data.</td></tr></table>
+
+
+Figure 114. Sequence Diagram: Sending transaction related Meter Values
+
+# J02 - Sending transaction related Meter Values - Requirements
+
+Table 93. J02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>J02.FR.01</td><td></td><td>The Charging Station MAY sample the energy meter (or other sensor/transducer hardware) to provide extra information about its Meter Values.</td><td>It is up to the Charging Station when it will send Meter Values. This can be configured using the SetVariablesRequest message to data acquisition intervals and specify data to be acquired & reported.</td></tr><tr><td>J02.FR.02</td><td>If all captured at the same point in time.</td><td>Each MeterValue element SHALL contain a set of one or more individual SampledValue elements.</td><td></td></tr><tr><td>J02.FR.03</td><td></td><td>The optional measurand field SHALL specify the type of value being measured/reported.</td><td></td></tr><tr><td>J02.FR.04</td><td></td><td>The optional context field SHALL specify the reason/event triggering the reading.</td><td></td></tr><tr><td>J02.FR.05</td><td></td><td>The optional location field SHALL specify where the measurement is taken.</td><td>(e.g. Inlet, Outlet).</td></tr><tr><td>J02.FR.06</td><td></td><td>The optional phase field SHALL specify to which phase or phases of the electric installation the value applies.</td><td></td></tr><tr><td>J02.FR.07</td><td></td><td>The Charging Station SHALL report all phase number dependent values from the power meter (or grid connection when absent) point of view.</td><td></td></tr><tr><td>J02.FR.09</td><td>When reporting phase rotation of a component</td><td>The Charging Station SHALL report the phase rotation relative to the grid connection.</td><td></td></tr><tr><td>J02.FR.10</td><td>If a TransactionRequest message with eventType = Started or eventType = Update contains multiple meterValue elements, rather than one meterValue with one or more sampledValue elements</td><td>All meterValue elements SHALL have a timestamp that is within the current sampling interval, i.e.: (transaction event timestamp - SampledDataTxUpdatedInterval) < meterValue.timestamp <= transaction event timestamp</td><td>Only for eventType = Ended can a TransactionRequest have meter values for multiple intervals.</td></tr><tr><td>J02.FR.11</td><td>When SampledDataTxUpdatedInterval > 0</td><td>The Charging Station SHALL send a TransactionRequest(eventType = Updated with triggerReason = MeterValuePeriodic with the measurands configured in SampledDataCtrl.TxUpdatedMeasurands in the meterValue field at every SampledDataCtrl.TxUpdatedInterval.</td><td>See E01 for sending of SampledDataCtrl.TxStartedMeasurands and E06 for SampledDataCtrl.TxEndedMeasurands.</td></tr><tr><td>J02.FR.12 (2.1)</td><td>J02.FR.11 AND Charging Station is offline AND Charging Station is running low on memory</td><td>The Charging Station MAY drop TransactionRequest(eventType = Updated) messages with triggerReason = MeterValueClock or MeterValuePeriodic.</td><td>See E12.FR.04 for dropping of other TransactionEvent messages.</td></tr><tr><td>J02.FR.13</td><td>J02.FR.12</td><td>When dropping TransactionRequest(eventType = Updated) messages, the Charging Station SHALL drop intermediate messages first (1st message, 3th message, 5th message etc.), not start dropping messages from the start or stop adding messages to the queue.</td><td></td></tr><tr><td>J02.FR.14</td><td>J02.FR.11 AND Amount of meter data is too much for 1 TransactionRequest (eventType = Updated)</td><td>The Charging Station MAY use multiple TransactionRequest(eventType = Updated) messages with the same timestamp to send all measurands.</td><td></td></tr><tr><td>J02.FR.16</td><td></td><td>All "Register" values relating to a single charging transaction, or a non-transactional consumer (e.g. Charging Station internal power supply, overall supply) MUST be monotonically increasing in time.</td><td>Except in the case of a meter replacement. See MeasurandEnumType.</td></tr><tr><td>J02.FR.17</td><td></td><td>For improved auditability, "Register" values SHOULD be reported exactly as they are directly read from a non-volatile register in the electrical metering hardware, and SHOULD NOT be re-based to zero at the start of transactions</td><td>This allows any "missing energy" between sequential transactions, due to hardware fault, meter replacement, wiring, fraud, etc. to be identified, by allowing the CSMS to confirm that the starting register value of any transaction is identical to the finishing register value of the preceding transaction on the same connector.</td></tr><tr><td>J02.FR.18</td><td></td><td>The timestamp of a MeterValue SHALL apply to all its SampledValues.</td><td></td></tr><tr><td>J02.FR.19</td><td>When CSMS receives a TransactionRequest</td><td>CSMS SHALL respond with TransactionResponse.</td><td>Failing to respond with TransactionEventResponse might cause the Charging Station to try the same message again.</td></tr><tr><td>J02.FR.20</td><td>When configured to send meter data in the TransactionRequest (eventType = Ended) AND amount of meter data is too much for one TransactionRequest (eventType = Ended) message</td><td>Charging Station MAY remove samples until it fits in a message. When removing samples, the Charging Station SHOULD remove intermediate samples first (for example: 2nd sample, 4th sample, 6th sample etc.).</td><td>Samples should be removed in a way that it does not affect billing. See also E06.FR.12.</td></tr><tr><td>J02.FR.21</td><td>SampledDataSignReadings is true</td><td>The Charging Station SHALL retrieve signed meter values from components that support data signing and put them in the signedMeterValue field.</td><td></td></tr><tr><td>J02.FR.22</td><td></td><td>Meter values reported in a TransactionEventRequest message SHALL all be related to EVSE on which the transaction is taking place.</td><td></td></tr><tr><td>J02.FR.23 (2.1)</td><td>When a signedMeterValue is provided</td><td>The field publicKey, when present, IS RECOMMENDED to have the format "<marker>:"<encoding>:"content-type":"printed-public-key>" to allow proper decoding, where <marker> = "oca" <encoding> = "base16", "base32" or "base64" <content-type> = "asn1" <printed-public-key> = <the public key as printed on the certified meter>.</td><td>For example: oca:base16:asn1: 3056301006072a8648ce 3d020106052b8104000a 03420004460a02ba2766 d9c44f023ecc0e4e5864 4a87add1aadd6317e5fe 4ddcdb29b163a01d8a62 97c84bc530f86431e92f 8d46ab37830247c05cbd 92fac252929e7f61 (line breaks added for readability)</td></tr><tr><td>J02.FR.24 (2.1)</td><td>J02.FR.23 AND signedMeterValue does not specify the method used to create the digital signature</td><td>signingMethod SHOULD contain the method used to create the digital signature.</td><td>A list of standardized values is provided in the Appendix as SigningMethodEnumStri ngType.</td></tr></table>
+
+# 3.2. ISO 15118 MeterValue signing
+
+# J03 - Charging Loop with metering information exchange
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Charging Loop with metering information exchange</td></tr><tr><td>2</td><td>ID</td><td>J03</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 F1</td></tr><tr><td>3</td><td>Objective(s)</td><td>See ISO15118-1, use case Objective F1, page 37.</td></tr><tr><td>4</td><td>Description</td><td>See ISO15118-1, use case Description F1, page 37.</td></tr><tr><td></td><td>Actors</td><td>EV, CSMS, Charging Station</td></tr><tr><td></td><td>Combined scenario description</td><td>15118
+1a. The EV sends a ChargingStatusReq (in case of AC charging) message to the Charging Station, upon which EVSE returns a ChargingStatusRes containing the meter value from the fiscal meter.
+1b. The EV sends a CurrentDemandReq (in case of DC charging) message to the Charging Station, upon which EVSE returns a CurrentDemandRes containing the meter value from the fiscal meter.
+2. The EV sends a MeteringReceiptReq to the Charging Station to acknowledge receipt of the meter value.</td></tr><tr><td>5</td><td>Prerequisites</td><td>- If authorization according use cases in Functional Block C is applied, it SHALL be finished successfully.
+See ISO15118-1, use case Prerequisites F1, page 37.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>See ISO15118-1, use case End conditions F1, page 37.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 115. Charging Loop with metering information exchange
+
+# J03 - Charging Loop with metering information exchange - Requirements
+
+Table 94. J03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>J03.FR.04</td><td>When the Charging Station receives ISO 15118 signed MeteringReceiptReq message from EV</td><td>The Charging Station SHOULD NOT pass the meter value from the MeteringReceiptReq message to CSMS in a TransactionEventRequest (eventType = Updated) message. Instead, Charging Station sends transaction-related meter values as described in use case J02.</td><td>This does not imply that a Charging Station cannot require EV to send MeteringReceiptReq messages. An implementation at a Charging Station can be such, that every meter value from the fiscal meter that is sent to CSMS (as per use case J02) must first have been acknowledged by a MeterReceiptReq from the EV.</td></tr></table>
+
+# K. Smart Charging
+
+# Chapter 1. Introduction
+
+This Functional Block describes all the functionalities that enable the CSO (or a third party) to influence the charging current/power transferred during a transaction, or set limits to the amount of current/power a Charging Station can draw from the grid.
+
+Smart Charging in general has more than one definition. It can mean that the grid capacity is used in such a manner that consumers are able to charge their batteries fully at any time, even if large groups of consumers wish to 'fill up' simultaneously. Smart can also mean that energy prices can be taken into consideration when charging. Or again smart can be taken as using a local supply of sustainable energy from solar panels. And it is even 'smarter' when the Electric Vehicle (EV) driver wishes to be part of the solution. Within OCPP, Smart Charging means that a CSMS gains the ability to influence the (de-)charging power or current of a specific EV, or the total allowed energy consumption on an entire Charging Station / a group of Charging Stations. Different setups can be used. The following four typical kinds of smart charging will be used to illustrate the possible behavior of smart charging using OCPP:
+
+- Internal Load Balancing
+- Central Smart Charging
+- Local Smart Charging
+- External Smart Charging Control Signals
+
+These types will be explained in Types of Smart Charging. Of course, more complex use cases are possible in which two or more of the above use cases are combined into one more complex system.
+
+NOTE A mapping of the ISO 15118 and OCPP terminology is provided in ISO 15118 and OCPP terminology mapping
+
+# Chapter 2. Types of Smart Charging
+
+This section is informative.
+
+# 2.1. Internal Load Balancing
+
+The simplest form of smart charging is the Load Balancing use case. This concerns internal load balancing within the Charging Station, where the Charging Station controls current/power per EVSE. The Charging Station is configured with a fixed limit, e.g. the maximum current of the connection to the grid. The Charging Station in this case is responsible for optimizing charging for all its EVSEs. When a charging station is not directly connected to the grid, the energy system of a client will be responsible for the power supply.
+
+This setup is typically used to set limits that are necessary due to known physical limits.
+
+
+Figure 116. Internal Load Balancing Smart Charging Topology
+
+# 2.2. Central Smart Charging
+
+The next level in smart charging is when the CSMS has the ability to influence the charging power or current of a specific EV, the total allowed energy consumption on an entire Charging Station or a group of Charging Stations. Central Smart Charging assumes that charge limits are controlled by the CSMS. This could for example be based on a grid connection, energy availability on the grid (e.g. capacity forecast from the grid operator (DSO)) or the wiring of a building. In this setup, the CSMS can optimize charging not only on one Charging Station, but one level "up": it can optimize more than one Charging Station that share a connection and thus calculate a more efficient schedule for charging.
+
+
+Figure 117. Central Smart Charging Topology
+
+Central Smart Charging can be done with a Control Pilot signal, albeit with some limitations, because an EV cannot communicate its charging needs via the Control Pilot signal. In analogy to the Local Smart Charging use case, an EVSE can execute a charging schedule by the Control Pilot signal.
+
+# 2.3. Local Smart Charging
+
+Local Smart Charging describes a use case in which smart charging enabled Charging Stations have charging limits controlled locally by a Local Controller, not the CSMS. This type of smart charging assumes the existence of a Local Controller, which is a
+
+logical component that controls a group of Charging Stations. A typical use would be a number of Charging Stations in a parking garage where the rating of the connection to the grid is less than the sum the ratings of the Charging Stations. Another application might be that the Local Controller receives information about the availability of power from a DSO or a local smart grid node.
+
+
+Figure 118. Local Smart Charging Topology
+
+# 2.4. External Smart Charging Control Signals
+
+Updated in OCPP 2.1
+
+The OCPP protocol is developed for communication between a CSMS and one or more Charging Stations. As described in the above, this means that a CSMS of a Charging Station Operator (CSO) controls a Charging Station and, based on the charging limits of both the EV and the Charging Station, the CSO controls how fast the EV is charged. In some situations there are other factors that might control charging power: A DSO can send signals to change charging power (e.g. via IEC 61850 [IEC61850-7-420], IEC 60870 [IEC60870-5-104], DNP3 [DNP3] or OpenADR [OPENADR]), or a Home Energy Management System or a smart meter may be in place to limit charging power.
+
+An external actor can connect to a Charging Station with any protocol that is supported by the Charging Station for this purpose, like Modbus, EEBUS, and even OCPP. This control signal can be a single limit value or a schedule. In both cases Charging Station will represent the limit internally as a charging profile of purpose ChargingStationExternalConstraints.
+
+A CSMS may need to be informed of changes in charging rate as a result of external signals. OCPP provides a NotifyChargingLimitRequest message to report such changes.
+
+The figures below presents topologies with an Energy Management System, where the external signals (from EMS) are sent directly to the Charging Stations, and a configuration where the signals are sent to a Local Controller.
+
+
+Figure 119. EMS control directly to Charging Stations
+
+
+Figure 120. EMS control via Local Controller
+
+See [ref-ocpp21-part1] for a description of common topologies with an EMS.
+
+# Chapter 3. Charging profiles
+
+# 3.1. Introduction
+
+Influencing the charge power or current is based on sending energy transfer limits at specific points in time to a Charging Station. Those limits are combined in a ChargingProfile. A ChargingProfile holds the ChargingSchedule which defines a block of charging Power or Current limits and can contain a start time and duration. These can be applied to Charging Stations as well as to EVSEs of the Charging Stations. In Example ChargingProfile an example of a ChargingProfile is given to illustrate how these charging profiles can be used.
+
+A CSMS can send a charging profile to a Charging Station using the message SetChargingProfileRequest, in the following situations:
+
+- At the start of a transaction to set the charging profile for the transaction
+- In a RequestStartTransaction request sent to a Charging Station
+- During a transaction to change the active profile for the transaction
+- Outside the context of a transaction as a separate message to set a charging profile to a local controller, Charging Station, or a default charging profile to an EVSE.
+
+# 3.2. Charging profile purposes
+
+Updated in OCPP 2.1
+
+This section describes a number of types of charging profiles that are supported in OCPP. There are six different types of charging profiles, depending on their purpose:
+
+<table><tr><td>ChargingProfilePurpose</td><td>Description</td></tr><tr><td>ChargingStationMaxProfile</td><td>A charging profile of purpose ChargingStationMaxProfile limits the maximum power or current of the entire Charging Point. A ChargingStationMaxProfile is always for evseld = 0. It is kept in persistent storage.</td></tr><tr><td>TxProfile</td><td>A transaction-specific profile with purpose TxProfile overrules the TxDefaultProfile for the duration of the current transaction only or until the TxProfile expires, whichever occurs earlier.</td></tr><tr><td>TxDefaultProfile</td><td>Default schedules for new transactions that MAY be used to impose charging policies. An example could be a policy that prevents charging during the day. It is kept in persistent storage.</td></tr><tr><td>ChargingStationExternalConstraints</td><td>When an external system, not the CSMS, sets a charging limit or schedule, the Charging Station uses this purpose to report such a limit/schedule. If the external systems uses OCPP to set the charging profile, then it SHALL use this charging profile purpose when setting the charging profile.A charging schedule in a ChargingStationExternalConstraints charging profile is allowed to have schedule periods with setpoints, when these periods have operationMode = ExternalSetpoint. By default, the ExternalSetpoint of a ChargingStationExternalConstraints profile takes precedence, unless this is overruled by the configuration variable SmartChargingCtrl.SetpointPriority.</td></tr><tr><td>PriorityCharging</td><td>A charging profile with purpose PriorityCharging is used to overrule the currently active TxProfile or TxDefaultProfile charging restrictions with a charging profile that provides the maximum possible power under the circumstances, and avoids discharging operations.It has charging schedule periods with operationMode = ChargingOnly and the charging schedule has no duration, since it remains valid until end of the transaction.It is kept in persistent storage.</td></tr><tr><td>LocalGeneration</td><td>A charging profile that describes locally available power, that adds on top of the active charging profiles of a charging station. It is usually originating from an external system, or a local controller, that is aware of the amount of local generation, but can also be provided by a CSMS.</td></tr></table>
+
+See Limits and setpoints per operation mode for an overview of parameters per operationMode.
+
+NOTE
+
+A charging profile from an external system is usually received via another protocol than OCPP. The charging station converts the data from the external protocol to an OCPP ChargingProfileType for internal use.
+
+NOTE
+
+Charging profile purposes TxProfile, LocalGeneration and ChargingStationExternalConstraints
+
+are not required to be stored persistently. If any of these purposes is stored persistently by the Charging Station, then it should report this fact in the configuration variable ChargingProfilePersistence.
+
+Table 95. operationMode for various ChargingProfilePurposes
+
+<table><tr><td>ChargingProfilePurpose</td><td>operationMode</td></tr><tr><td>Tx(Default)Profile</td><td>ChargingOnly
+CentralSetpoint
+ExternalSetpoint
+ExternalLimits
+CentralFrequency
+LocalFrequency
+LocalLoadBalancing
+Idle</td></tr><tr><td>PriorityCharging</td><td>ChargingOnly</td></tr><tr><td>ChargingStationMaxProfile</td><td>ChargingOnly</td></tr><tr><td>ChargingStationExternalConstraints</td><td>ChargingOnly
+ExternalLimits
+ExternalSetpoint</td></tr><tr><td>LocalGeneration</td><td>ChargingOnly
+ExternalLimits</td></tr></table>
+
+# 3.3. Charging profile kind
+
+Updated in OCPP 2.1
+
+This section explains the different kinds of charging schedules that can be used in a charging profile, as defined by the value of the attribute chargingProfileKind:
+
+<table><tr><td>ChargingProfile Kind</td><td>Description</td></tr><tr><td>Absolute</td><td>The charging schedule periods are relative to an absolute point in time defined in the schedule. This requires that startSchedule is set to a starting point in time. Use this, for example, to define a schedule that reduces charging between 17:00h and 21:00h, regardless of when charging session was started.</td></tr><tr><td>Recurring</td><td>The charging schedule restarts periodically at the first schedule period. To be most useful, this requires that startSchedule is set to a starting point in time. Use this in combination with concurrencyKind = Daily, for example, to define a schedule that reduces charging between 17:00h and 21:00h every day, regardless of when charging session was started.</td></tr><tr><td>Relative</td><td>Charging schedule periods start when the EVSE is ready to deliver energy. i.e. when the EV driver is authorized and the EV is connected (i.e. "PowerPathClosed"). When a ChargingProfile is received for a transaction that is already charging, then the charging schedule periods remain relative to the PowerPathClosed moment of the transaction. No value for startSchedule must be supplied.</td></tr><tr><td>Dynamic</td><td>The schedule consists of only one charging schedule period, in which the limits or setpoints are updated dynamically by CSMS or an external actor. NOTE: This is not related to the ISO 15118-20 dynamic control mode.</td></tr></table>
+
+# 3.4. Smart Charging Operation Modes
+
+New in OCPP 2.1
+
+New in OCPP 2.1 is the concept of a smart charging operation mode, that defines a specific mode of operation during a charging schedule period. This operation mode determines for example whether the setpoint of a period can be set dynamically by CSMS or an external system.
+
+This mode of operation is defined by the variable OperationMode that is part of a ChargingSchedulePeriodType.
+
+The following operation modes exist, of which only the first three operation modes apply to regular smart charging. The others are specific to bidirectional charging. See Introduction.
+
+# Unidirectional (charging)
+
+1. ChargingOnly
+2. ExternalSetpoint
+3. ExternalLimits
+
+# Bidirectional (charging/discharging)
+
+1. CentralSetpoint
+2. CentralFrequency
+3. LocalFrequency
+4. LocalLoadBalancing
+5. Idle
+
+# ChargingOnly
+
+This operation mode allows charging only. This is also the default operation mode when the field operationMode is missing. Behavior of a charging schedule in this mode is identical to OCPP 2.0.1.
+
+The field limit is used to specify the maximum allowed charging limit. The fields dischargeLimit and setpoint are not used.
+
+# ExternalSetpoint
+
+This control mode tells the charging station that the setpoint parameter is to be determined by some external actor, such as an EMS. A setpoint is a charging rate that the EV must try to follow as closely as possible.
+
+If the information for the charging profile comes from the external actor (possibly via a different protocol) then the charging station converts it to a ChargingProfileType with chargingProfilePurpose set to ChargingStationExternalConstraints and setpoint set to the received value.
+
+It is also possible that CSMS submits a Tx(Default)Profile with an operationMode = ExternalSetpoint. In that case the setpoint parameter will be empty. Its value should then be received by the charging station from the external system through some other means of communication and not via OCPP. How this is done will differ for different applications and is out of scope of OCPP.
+
+If the chargingProfileKind = Dynamic, then the value of setpoint can be changed by the external actor during the charging schedule period without having to submit a new charging profile. Whenever the external actor provides a new setpoint, this value is automatically used as the setpoint in the charging schedule period. This is especially suited for rapidly changing conditions.
+
+Optionally the parameter limit can be set by CSMS as an upper limit of the range of the external setpoint.
+
+NOTE Only ISO 15118-20 supports the sending of a setpoint to an EV.
+
+# ExternalLimits
+
+This control mode is similar to ExternalSetpoint with the difference that it is not the setpoint that is controlled, but it is the limit parameter that is determined by the external actor, such as an EMS.
+
+# 3.5. Stacking charging profiles
+
+It is allowed to stack charging profiles of the same ChargingProfile purpose in order to describe complex calendars. For example, one can define ChargingProfile of purpose TxDefaultProfile with a duration and recurrence of one week that allows full power or current charging on weekdays from 23:00h to 06:00h and from 00:00h to 24:00h in weekends and reduced power or current charging at other times. On top of that, one can define other TxDefaultProfiles that define exceptions to this rule, for example for holidays.
+
+A ChargingProfile holds a ChargingSchedule that defines limits for a certain time interval. Precedence of ChargingSchedules is determined by the stackLevel of their ChargingProfile. When more than one ChargingProfile with the same chargingProfilePurpose is valid, then a ChargingSchedule of a ChargingProfile with a higher stack level overrules a ChargingSchedule from a ChargingProfile with a lower stack level.
+
+To avoid conflicts, it is not allowed to have multiple charging profiles with the same stackLevel and same chargingProfilePurpose to be valid on the same EVSE at a given time. Note, that a charging profile for EVSE #0 is considered to be active on all EVSEs!
+
+# 3.6. Combining Charging Profile Purposes
+
+Updated in OCPP 2.1
+
+IMPORTANT Highlighted text in the following paragraphs of this section has been changed.
+
+As mentioned before, for each charging profile purpose, at any point in time, the leading charging schedule for that purpose is the charging schedule that has a schedule period defined for that time and that belongs to a charging profile with the highest stack level that is valid at that time, as determined by their validFrom and validTo parameters. The Composite Schedule is then calculated by taking the lowest charging limit and setpoint (taking the different chargingRateUnits into account) among the leading profiles of the different purposes for each time interval. If a charging profile of chargingProfilePurpose = LocalGeneration is active for the EVSE, then this capacity is added on top of the calculated composite schedule.
+
+When a PriorityCharging profile has been activated (either locally or via a UsePriorityChargingRequest), then this will overrule the TxDefaultProfile or TxProfile.
+
+In case the Charging Station is equipped with more than one EVSE, the limit value of ChargingStationMaxProfile for EVSE 0 is the limit for all EVSEs combined.
+
+The two figures below will be used to give an example of combining multiple charging profiles with different stackLevels and Purposes.
+
+
+Figure 121. Multiple valid charging profiles - situation 1
+
+Suppose that at a certain time interval the valid charging profiles are as in the above figure (situation 1). The composite schedule for this time interval will then be the lowest of the charging limits given in the ChargingStationMaxProfile with stackLevel 0, the TxDefaultProfile with stackLevel 2 and the ChargingStationExternalConstraints profile with stackLevel 1.
+
+
+Figure 122. Multiple valid charging profiles - situation 2
+
+On the other hand, consider the situation in which for a certain time interval the valid charging profiles are as in the above figure (situation 2). The composite schedule for this time interval will then be the lowest of the charging limits given in the ChargingStationMaxProfile with stackLevel 0, the TxProfile with stackLevel 1 and the ChargingStationExternalConstraints profile with stackLevel 1. Note that in this situation the TxProfile overrules the TxDefaultProfile.
+
+# 3.7. Example Charging Profile
+
+This section is informative.
+
+The following data structure describes a daily default profile that limits the power to 6 kW between 08:00h and 20:00h and to 11 kW between 00:00h and 08:00h and between 20:00h and 00:00h.
+
+<table><tr><td>ChargingProfile</td><td></td><td></td><td></td></tr><tr><td>chargingProfileId</td><td>100</td><td></td><td></td></tr><tr><td>stackLevel</td><td>0</td><td></td><td></td></tr><tr><td>chargingProfilePurpose</td><td>TxDefaultProfile</td><td></td><td></td></tr><tr><td>chargingProfileKind</td><td>Recurring</td><td></td><td></td></tr><tr><td>recurrencyKind</td><td>Daily</td><td></td><td></td></tr><tr><td>chargingSchedule</td><td colspan="3">(List of 1 ChargingSchedule elements)</td></tr><tr><td></td><td>ChargingSchedule</td><td></td><td></td></tr><tr><td></td><td>duration</td><td>86400 (= 24 hours)</td><td></td></tr><tr><td></td><td>startSchedule</td><td>2013-01-01T00:00Z</td><td></td></tr><tr><td></td><td>chargingRateUnit</td><td>W</td><td></td></tr><tr><td></td><td>chargingSchedulePeriod</td><td colspan="2">(List of 3 ChargingSchedulePeriod elements)</td></tr><tr><td></td><td></td><td>ChargingSchedulePeriod</td><td></td></tr><tr><td></td><td></td><td>startPeriod</td><td>0 (=00:00)</td></tr><tr><td></td><td></td><td>limit</td><td>11000</td></tr><tr><td></td><td></td><td>numberPhases</td><td>3</td></tr><tr><td></td><td></td><td>ChargingSchedulePeriod</td><td></td></tr><tr><td></td><td></td><td>startPeriod</td><td>28800 (=08:00)</td></tr><tr><td></td><td></td><td>limit</td><td>6000</td></tr><tr><td></td><td></td><td>numberPhases</td><td>3</td></tr><tr><td></td><td></td><td>ChargingSchedulePeriod</td><td></td></tr><tr><td></td><td></td><td>startPeriod</td><td>72000 (=20:00)</td></tr><tr><td></td><td></td><td>limit</td><td>11000</td></tr><tr><td></td><td></td><td>numberPhases</td><td>3</td></tr></table>
+
+# IMPORTANT
+
+The amount of phases used during charging is limited by the capabilities of: The Charging Station, EV and Cable between CS and EV. If any of these three is not capable of 3 phase charging, the EV will be charged using the number of phases that is supported by all three.
+
+# IMPORTANT
+
+Switching the number of used phases during a schedule or transaction should be done with care. Some EVs MAY not support this and changing the amount of phases MAY result in physical damage. With the Configuration Variable: Phases3to1 The Charging Station can tell if it supports switching the amount of phases during a transaction.
+
+# TIP
+
+On days on which daylight saving goes into or out of effect, a special profile might be needed (e.g. for relative profiles).
+
+# 3.7.1. Example Using Stacked Charging Profiles
+
+A CSO wishes to limit charging to $2\mathrm{kW}$ during the peak hours of the day from 17:00h to 20:00h. This limit does not apply to Sundays and this limit does not apply to Christmas Day either.
+
+If this applies to a large number or charging stations, then it is not practical to delete the charging profile every Sunday and then add it again on Monday. A possible solution is to add profiles with higher stack level for the exceptions to the base profile. See the following JSON examples where stack levels #2 and #3 are used to define exceptions for Sunday and Christmas.
+
+(1) TxDefaultProfile, stack #1: time-of-day limitation to 2 kW, recurring every day from 17:00h to 20:00h.
+
+```txt
+"chargingProfile": { "id": 10, "stkLevel": 1, "chargingProfilePurpose": "TxDefaultProfile", "chargingProfileKind": "Recurring", "reccuracyKind": "Daily", "chargingSchedule": [ { "id": 1, "startSchedule": "2020-01-09T17:00:00", "duration": 1080, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 2000} ] } ]
+```
+
+(2) TxDefaultProfile, stack #2: overruling Sundays to no limit, recurring every week starting 2020-01-05.
+
+```txt
+"chargingProfile": { "id": 11, "stkLevel": 2, "chargingProfilePurpose": "TxDefaultProfile", "chargingProfileKind": "Recurring", "reccurcyKind": "Weekly", "chargingSchedule": [ { "id": 1, "startSchedule": "2020-01-05T00:00:00", "duration": 86400, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 999999} ] } ]
+```
+
+(3) TxDefaultProfile, stack #3: overruling Christmas Day 2020 to no limit, fixed date 2020-12-25.
+
+Note, that this profile is only valid in the year 2020.
+
+```javascript
+"chargingProfile": { "id": 12, "stkLevel": 3, "chargingProfilePurpose": "TxDefaultProfile", "chargingProfileKind": "Absolute", "validFrom": "2020-01-01T00:00:00", "validTo": "2021-01-01T00:00:00", "chargingSchedule": [ { "id": 1, "startSchedule": "2020-12-25T00:00:00", "duration": 86400, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 999999} ] } ]
+```
+
+# NOTE
+
+Normally, when no limits are desired for charging, one will not define a charging schedule period for those hours (see stack level #1 for hours outside 17:00h - 20:00h). However, when overruling a charging schedule by one from a profile with a higher stack level, it is not possible to define a charging schedule period that has no limit.
+
+Therefore, the charging schedules for stack #2 and #3 in the above example use a (arbitrary) high value of 999999.
+
+# 3.8. Avoiding Phase Conflicts
+
+In the situation where a ChargingStationMaxProfile or a ChargingStationExternalConstraints define a value for numberPhases or phaseToUse, then a possible conflict might arise if such values are also specified in a TxDefaultProfile or TxProfile. The following rules apply in that case:
+
+# numberPhases
+
+The lowest value for a schedule period of all applicable profiles is used for the composite schedule period. If ChargingStationMaxProfile has numberPhases = 2 or 3 and TxProfile has numberPhases = 1, then the value 1 is used. The same applies to the reverse situation.
+
+# phaseToUse
+
+When there is a conflicting value of phaseToUse between the schedule periods of applicable profiles, then there is no way to create a composite schedule period. For example, a CSMS should not submit a charging profile of purpose
+
+ChargingStationMaxProfile for phaseToUse = 1 and then a TxProfile for phaseToUse = 3, because the charging station will not know which value has preference. Therefore, a SetChargingProfileRequest that causes such a conflict will have to be rejected.
+
+When a relative TxProfile is being used and different phases occur in various schedule periods, then it may become difficult to detect if and where such a phase conflict occurs. A charging station should only accept a SetChargingProfileRequest when it can be certain, that there is a no risk of a phase conflict. This means, that when the charging station is not able to verify that no phase conflict occurs in any schedule period (which can happen when the TxProfile is received for a transaction, but charging has not yet started, so that start time of the first schedule period is not known), that it cannot accept a charging profile if any of the schedule periods contains a value for phaseToUse that differs from the value used in the ChargingStationMaxProfile or ChargingStationExternalConstraints.
+
+NOTE A value of phaseToUse may only be used when numberOfPhases = 1.
+
+# 3.9. Using randomized delays in schedule periods
+
+(New in OCPP 2.1)
+
+A charging profile of type TxDefaultProfile is especially useful to define hours for peak and off-peak charging. Suppose that charging during peak hours is not allowed or has to be at a lower charging rate, then TxDefaultProfile can define a standard schedule for every charging transaction using a list of allowed charging rates over time. The rate is set to zero when no charging is allowed in a period.
+
+The peak/off-peak charging schedule is configured as a so-called "recurring profile": it has a schedule for a period of 24 hours and then repeats every day.
+
+When an EV driver starts a transaction during peak hours, the charging will be suspended until the period of off-peak hours starts, after which charging is allowed normally. If charging still continues when peak hours begin, the energy transfer will be suspended again until end of peak hours. If such a standard TxDefaultProfile is used for a large population of charging stations, for example for all residential chargers in a city or region, then suspending or resuming charging for all those EVs at exactly the same time will have a negative impact on the electric grid.
+
+A charging schedule with a value for randomizedDelay, will automatically delay the start of each period with a random time between 0 and randomizedDelay. The first charging schedule period will, however, not be delayed to avoid introducing a gap between the start of the charging schedule (at startSchedule or start of energy transfer in case of a relative charging profile) and the first period becoming active. The duration, when present, will not be affected either.
+
+The above means that randomizedDelay will not affect starting and stopping of charging schedules and will not affect recurrence of charging schedules. In case a random delay is required at start of a schedule, then this can be achieved by inserting a short period of limit = 0 as the first period with startPeriod = 0.
+
+Example 1. Example TxDefaultProfile: peak hours from 8.00h to 11.00h and 16.00h to 22.00h.
+
+```json
+"chargingProfile": { "id": 10, "stkLevel": 1, "chargingProfilePurpose": "TxDefaultProfile", "chargingProfileKind": "Recurring", "recurrencyKind": "Daily", "chargingSchedule": [ { "id": 1, "startSchedule": "2022-06-30T00:00:00", "duration": 86400, // 24 hrs "chargingRateUnit": "W", "randomizedDelay": 600, "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 999999 }, // 0:00h { "startPeriod": 28800, "limit": 0 }, // 8:00h { "startPeriod": 39600, "limit": 999999 }, // 11:00h { "startPeriod": 57600, "limit": 0 }, // 16:00h { "startPeriod": 79200, "limit": 999999 } ] // 22:00h } ]
+```
+
+This defines peak hours as: [28800, 39600] and [57600, 79200] seconds since midnight with a randomized delay, which is calculated for each period at the time the transaction starts as a value between 0 and 600 seconds. This can become something like this:
+
+- for transaction X: $[28800 + 123, 39600 + 345]$ and $[57600 + 234, 79200 + 456]$ , and
+- for transaction Y: [28800+555, 39600+111] and [57600+333, 79200+222]
+
+in which the bold numbers represent the random delays.
+
+# Chapter 4. Smart Charging Signals to a Charging Station from Multiple Actors
+
+Updated in OCPP 2.1
+
+This section is normative.
+
+Within OCPP, multiple mechanism are supported for Smart Charging, i.e. multiple mechanisms are available that can add a limit when charging an EV:
+
+1. The CSMS can influence charging by sending a SetChargingProfile message to the Charging Station. See K01 - SetChargingProfile.
+2. The EV can influence charging based on the PlugAndCharge functionality: the ISO 15118 enables EV initiated Charging Limits. See Section 5.3. ISO 15118 based Smart Charging.
+3. Some local input, for example a Home Energy Management System (HEMS) or DSO, can influence the charging, for example via an External Smart Charging Control signal. See K11 - Set / Update External Charging Limit.
+4. A Charging Station can limit charging when it is load balancing when more than 1 EV is charging.
+
+The assumption is that all parties that might be involved in setting limits for charging an EV will use one of the above mechanisms directly or indirectly.
+
+To determine how a Charging Station should respond to simultaneous smart charging signals from multiple actors, the following rules should be followed:
+
+Table 96. Smart Charging rules for multiple actor situation
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>SC.01(2.1)</td><td></td><td>At any point in time, the charging limit and setpoint, which are the result of merging the schedules from external sources and the CSMS charging profiles with the highest stackLevel from each of the purposesChargingStationMaxProfile,ChargingStationExternalConstraintsand TxDefaultProfile (or TxProfile or PriorityCharging), SHALL be less than or equal to the lowest value of available power or current in any of the merged schedules.If a charging profile with purposeLocalGeneration is active, this capacity is added on top of the calculated charging limit based on the above-mentioned merged schedules.</td><td>For safety purposes.For PriorityCharging, see use cases K21, K22.For LocalGeneration, see use case K23.</td></tr><tr><td>SC.02</td><td>When theChargingProfile has changed</td><td>The Charging Station SHALL always inform the CSMS.</td><td>The message used for this varies depending on the which of the mechanisms mentioned at the start of this section is applicable:1. n/a2. NotifyEVChargingScheduleRequest3. NotifyChargingLimitRequest4. TransactionEventRequest</td></tr><tr><td>SC.03</td><td></td><td>Reporting to the CSMS concerning a changed limit or setpoint in the ChargingProfile for mechanisms 3 and 4 as described in SC.02 MAY be skipped if the change in the limit or setpoint is smaller than the percentage defined in the Configuration Variable:LimitChangeSignificance.</td><td>This is to prevent the Charging Station to send a lot of messages for small fluctuations (e.g. due to EMS / smart meter input at the Charging Station)</td></tr><tr><td>SC.04 (2.1)</td><td></td><td>The GetCompositeScheduleResponse message SHALL always report the expected charging schedule, i.e. the lowest limit and setpoint when charging or the highest dischargingLimit and setpoint when discharging. This means that when a transaction has a charging limit X, and EV indicates (via NotifyEVChargingScheduleRequest) that it will use less energy than offered, amount Y, the Charging Station SHALL report limit Y.</td><td>Note, that setpoint is negative when discharging, and dischargingLimit is always negative. (A setpoint = -1000 is higher than a setpoint = -2000). Therefore, when values are negative, the "highest" value represents the least amount of energy being transferred.</td></tr></table>
+
+# Chapter 5. Use cases & Requirements
+
+# 5.1. General Smart Charging
+
+# K01 - SetChargingProfile
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>SetChargingProfile</td></tr><tr><td>2</td><td>ID</td><td>K01</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by EVs. The CSMS calculates a ChargingSchedule to stay within certain limits, which MAY be imposed by any external system.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sets charging limits by sending SetChargingProfileRequest to the Charging Station.
+2. The Charging Station responds with SetChargingProfileResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station Successfully influences the charging power or current of a specific EV, following the SetChargingProfileRequest sent by the CSMS.
+Failure postcondition:
+The Charging Station was not able to influence the charging power or current of a specific EV, following the SetChargingProfileRequest sent by the CSMS.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 123. Sequence Diagram: SetChargingProfile
+
+# K01 - SetChargingProfile - Requirements
+
+# IMPORTANT
+
+Requirements for charging profile fields dischargingLimit, setpoint and setpointReactive are part of section Introduction.
+
+Table 97. K01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K01.FR.01</td><td></td><td>The CSMS MAY choose to set charging limits to a transaction using TxProfile.</td><td></td></tr><tr><td>K01.FR.02</td><td></td><td>The CSMS MAY send a new charging profile for the EVSE that SHALL be used as a limit schedule for the EV.</td><td></td></tr><tr><td>K01.FR.03</td><td></td><td>The CSMS SHALL include the transactionId in the SetChargingProfileRequest when setting a TxProfile.</td><td>The transactionId is used to match the profile to a specific transaction.</td></tr><tr><td>K01.FR.04</td><td>K01.FR.03 AND the given transactionId is known</td><td>The Charging Station SHALL apply the sent TxProfile to the transaction with the specified transactionId.</td><td></td></tr><tr><td>K01.FR.05</td><td>When a SetChargingProfileRequest with an already known ChargingProfile.id is received AND the existing ChargingProfile does NOT have chargingProfilePurpose = ChargingStationExter nalConstraints</td><td>The Charging Station SHALL replace the existing ChargingProfile with the one specified.</td><td>ChargingStationExternalCon straints profile cannot be replaced.</td></tr><tr><td>K01.FR.06</td><td>When chargingProfilePurpose is NOT TxProfile</td><td>The CSMS SHALL NOT send a ChargingProfile with a stackLevel - chargingProfilePurpose - evseld combination that already exists in another ChargingProfile (with different id) on the Charging Station and has an overlapping validity period.</td><td>This is to ensure that no two charging profiles with same stack level and purpose can be valid at the same time.</td></tr><tr><td>K01.FR.07</td><td>When the Charging Station accepts a SetChargingProfileRequest</td><td>The Charging Station SHALL re-evaluate its collection of charging profiles to determine which ChargingProfile will become active.</td><td></td></tr><tr><td>K01.FR.08</td><td></td><td>The CSMS MAY send charging profiles to a Charging Station that are to be used as default charging profiles.</td><td></td></tr><tr><td>K01.FR.09</td><td>When a SetChargingProfileRequest with a TxProfile is received AND there is no transaction active on the specified EVSE</td><td>The Charging Station SHALL send a SetChargingProfileResponse with status Rejected.</td><td>It is recommended to include reasonCode = "TxNotFound".</td></tr><tr><td>K01.FR.10</td><td>When validFrom and validTo of a ChargingProfile are not set</td><td>The Charging Station SHALL consider the ChargingProfile to be valid indefinitely until it is explicitly replaced.</td><td></td></tr><tr><td>K01.FR.11</td><td>If ChargingSchedule has a duration AND ChargingSchedulePeriod.sta rtPeriod >= ChargingSchedule.duration</td><td>The Charging Station SHALL NOT execute the ChargingSchedulePeriod, because it is past the duration of the ChargingSchedule.</td><td></td></tr><tr><td>K01.FR.12</td><td></td><td>A ChargingSchedulePeriod remains active until the next ChargingSchedulePeriod in the list starts or until ChargingSchedule.duration has elapsed.</td><td></td></tr><tr><td>K01.FR.13</td><td>When concurrencyKind is used in combination with a ChargingSchedule duration shorter than concurrencyKind period.</td><td>The Charging Station SHALL fall back to default behavior after ChargingSchedule duration ends.</td><td></td></tr><tr><td>K01.FR.14</td><td>When a SetChargingProfileRequest with a TxDefaultProfile and evseld = 0 is received AND No other TxDefaultProfile with the same stackLevel is installed on any specific EVSE.</td><td>The Charging Station SHALL apply, but not copy, this profile to all EVSEs.</td><td>A TxDefaultProfile charging profile on EVSE #0 is "owned by" EVSE #0, but has effect on all EVSEs.</td></tr><tr><td>K01.FR.15</td><td>When a SetChargingProfileRequest with a TxDefaultProfile and evseld > 0 is received AND No TxDefaultProfile with the same stackLevel is installed on EVSE #0.</td><td>The Charging Station SHALL only apply this profile to the specified EVSE.</td><td></td></tr><tr><td>K01.FR.16</td><td></td><td>TxProfile SHALL only be used with evseld >0.</td><td></td></tr><tr><td>K01.FR.17</td><td></td><td>When more than one ChargingProfile with the same chargingProfilePurpose is valid, as determined by their validFrom and validTo fields, then a ChargingSchedule from a ChargingProfile with a higher stackLevel overrules a ChargingSchedule from a ChargingProfile with a lower stackLevel.</td><td></td></tr><tr><td>K01.FR.19</td><td></td><td>The CSMS SHALL NOT set phaseToUse in a SetChargingProfileRequest when numberPhases is other than 1.</td><td></td></tr><tr><td>K01.FR.20</td><td></td><td>The CSMS SHALL NOT set phaseToUse in a SetChargingProfileRequest when the EVSE does not have ACPPhaseSwitchingSupported defined and set to true.</td><td></td></tr><tr><td>K01.FR.21</td><td></td><td>The optional ChargingSchedule field minChargingRate MAY be used by the Charging Station to optimize the power distribution between the EVSEs.</td><td>The parameter informs the Local Controller that charging below minChargingRate is inefficient, giving the possibility to select another balancing strategy.</td></tr><tr><td>K01.FR.22</td><td></td><td>The CSMS SHALL NOT set chargingProfilePurpose to ChargingStationExternalConstraints in a SetChargingProfileRequest.</td><td>This purpose is only used when an external system has set a charging limit/schedule.</td></tr><tr><td>K01.FR.26</td><td>When a SetChargingProfileRequest is received with a value for chargingRateUnit, that is not configured in the configuration variable ChargingScheduleChargingRateUnit.</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status Rejected.</td><td>It is recommended to include reasonCode = "UnsupportedRateUnit".</td></tr><tr><td>K01.FR.27 (2.1)</td><td></td><td>ChargingProfiles set via SetChargingProfileRequest with chargingProfilePurpose = ChargingStationMaxProfile, TxDefaultProfile or PriorityCharging SHALL be persistent across reboots/power cycles,</td><td>Charging profiles TxProfile, LocalGeneration or ChargingStation-ExternalConstraints potentially change often and might eventually wear out persistent memory. They are therefore not required to be persistent.</td></tr><tr><td>K01.FR.28</td><td>When a SetChargingProfileRequest is received for an evseld that does not exist.</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status Rejected</td><td>It is recommended to include reasonCode = "UnknownEVSE".</td></tr><tr><td>K01.FR.29</td><td>When Charging Station does not support smart charging.</td><td>Charging Station SHALL respond with RPC Framework CALLERROR: NotSupported or NotImplemented.</td><td></td></tr><tr><td>K01.FR.30</td><td>chargingProfile has a chargingSchedule with startSchedule set to a time in the future</td><td>The Charging Station SHALL only start imposing the limitation of this schedule as of point in time set by startSchedule</td><td></td></tr><tr><td>K01.FR.31</td><td></td><td>The startPeriod of the first chargingSchedulePeriod in a chargingSchedule SHALL always be 0.</td><td></td></tr><tr><td>K01.FR.32</td><td>(K01.FR.14 OR K01.FR.15) AND a transaction is active on the specified EVSE(s) (evseld = 0 refers to all EVSEs.)</td><td>The Charging Station SHALL continue the transaction on the specified EVSE(s), but switch to using the new/updated TxDefaultProfile.</td><td></td></tr><tr><td>K01.FR.33</td><td>K01.FR.03 AND the given transactionId is not known</td><td>The Charging Station SHALL reject the SetChargingProfileRequest.</td><td></td></tr><tr><td>K01.FR.34</td><td>The CSMS has not received a NotifyEVChargingNeedsRequest for the current transaction, i.e. charging session is not using ISO 15118</td><td>The ChargingProfile in the SetChargingProfileRequest SHALL contain only one ChargingScheduleType.</td><td>See use cases K15-K17 for ISO 15118 smart charging.</td></tr><tr><td>K01.FR.35</td><td></td><td>The list of ChargingSchedulePeriod elements in a chargingSchedule SHALL be ordered by increasing values of ChargingSchedulePeriod.startPeriod.</td><td>This means the list is in chronological order</td></tr><tr><td>K01.FR.36</td><td>When validFrom of a ChargingProfile is set</td><td>The Charging Station SHALL consider the ChargingProfile to be valid when current time >= validFrom.</td><td></td></tr><tr><td>K01.FR.37</td><td>When validTo of a ChargingProfile is set</td><td>The Charging Station SHALL consider the ChargingProfile to be valid when current time < validTo.</td><td></td></tr><tr><td>K01.FR.38</td><td>When chargingProfilePurpose = ChargingStationMaxPr ofile</td><td>chargingProfileKind SHALL NOT be Relative</td><td></td></tr><tr><td>K01.FR.39</td><td>When chargingProfilePurpose is TxProfile</td><td>The CSMS SHALL NOT send a ChargingProfile with a stackLevel - transactionId combination that already exists in another ChargingProfile (with different id) with purpose TxProfile.</td><td>This is to ensure that no two charging profiles with same stack level and purpose can be valid at the same time.</td></tr><tr><td>K01.FR.40</td><td>When chargingProfileKind of a ChargingProfile is Absolute or Recurring</td><td>A value for startSchedule SHALL exist in the ChargingSchedule of the ChargingProfile.</td><td>This determines start date-time of the schedule and of the concurrency sequence.</td></tr><tr><td>K01.FR.41</td><td>When chargingProfileKind of a ChargingProfile is Relative</td><td>The field startSchedule SHALL be absent in the ChargingSchedule of the ChargingProfile.</td><td>A relative profile starts from when the profile is activated. (See K01.FR.42)</td></tr><tr><td>K01.FR.42 (2.1)</td><td>K01.FR.41</td><td>Charging Station SHALL start the first ChargingSchedulePeriod at the moment the Charging Station is ready to deliver energy, i.e. when the EV driver is authorized and the EV is connected.</td><td>If PowerPathClosed is a TxStartPoint, then this will concur with the start of a transaction.</td></tr><tr><td>K01.FR.43</td><td>When a SetChargingProfileRequest with a value for numberPhases is received AND the EVSE is of type AC AND the Charging Station cannot ensure that no more than the received numberPhases will be used</td><td>The Charging Station SHALL respond with status = Rejected</td><td>Is is recommended to include reasonCode = "InvalidSchedule". Note that even when for example the ChargingProfile defines 3 phases and the Charging Station is able to charge with 3 phases, it is not guaranteed that the EV or cable are able to charge with 3 phases. Based on received MeterValues the CSMS can determine the used number of phases. Please refer to requirement K01.FR.50 and K01.FR.51, for correctly calculating the limits per phase.</td></tr><tr><td>K01.FR.44 (2.1)</td><td>When a SetChargingProfileRequest with a value for numberPhases or phaseToUse is received AND the EVSE is of type DC AND DCInputPhaseControl is false or does not exist</td><td>The Charging Station SHOULD respond with SetChargingProfileResponse with status = Rejected andreasonCode = "NoPhaseForDC"</td><td>A Charging Station may accept the charging profile when it is capable of using the phase information to control the DC EVSE input phases from the grid. See K01.FR.54.</td></tr><tr><td>K01.FR.45</td><td>When a SetChargingProfileRequest with a value for numberPhases is received AND the EVSE is of type AC AND the received numberPhases is NOT supported by the Charging Station and higher than the numberPhases that are supported by the Charging Station</td><td>The Charging Station MAY respond with status = Accepted, instead of Rejected and impose the limits to a lower numberPhases</td><td>Please refer to requirement K01.FR.50 and K01.FR.51, for correctly calculating the limits per phase.</td></tr><tr><td>K01.FR.46</td><td>When a SetChargingProfileRequest with numberPhases = 1 and a value for phaseToUse is received AND the EVSE is of type AC AND the EVSE is capable of switching the phase connected to the EV, which is indicated by ACPPhaseSwitchingSupporte d defined as true OR the EVSE is already going to use the received phaseToUse</td><td>The Charging Station SHALL use the phase indicated by the received phaseToUse to connect to the EV.</td><td></td></tr><tr><td>K01.FR.47</td><td>When a SetChargingProfileRequest with numberPhases = 1 and phaseToUse is omitted is received AND the EVSE is of type AC</td><td>The Charging Station SHALL select the phase on its own.</td><td></td></tr><tr><td>K01.FR.48</td><td>When a SetChargingProfileRequest with a value for phaseToUse is received AND the EVSE is NOT capable of switching the phase connected to the EV, which is indicated by ACPPhaseSwitchingSupporte d not being implemented or defined as false AND the EVSE is NOT going to use the received phaseToUse</td><td>The Charging Station SHALL respond with status = Rejected.</td><td>It is recommended to include reasonCode = "InvalidSchedule".</td></tr><tr><td>K01.FR.49</td><td>When a SetChargingProfileRequest without a value for numberPhases is received AND the EVSE is of type AC</td><td>The Charging Station SHALL assume numberPhases = 3 as a default value.</td><td></td></tr><tr><td>K01.FR.50</td><td>When a SetChargingProfileRequest with a chargingRateUnit = W is received AND The ChargingSchedule is used for AC charging</td><td>The Charging Station SHOULD calculate the phase current limit via: Current per phase = Power / (Line Voltage * Number of Phases).</td><td>The "Line Voltage" used in the calculation is not the measured voltage, but the set voltage for the area (for example, 230 or 110 V). The "Number of Phases" is the numberPhases from the ChargingSchedulePeriod. It is usually more convenient to use chargingRateUnit = A for AC charging.</td></tr><tr><td>K01.FR.51</td><td>When a SetChargingProfileRequest with a chargingRateUnit = A is received</td><td>The Charging Station SHALL use the provided limits, to limit the amount of Ampere per phase, not the sum of all phases.</td><td></td></tr><tr><td>K01.FR.52</td><td>When a SetChargingProfileRequest with a TxDefaultProfile and evseld = 0 is received AND A TxDefaultProfile with the same stackLevel is installed on a specific EVSE and its chargingProfile.id does NOT equal the received chargingProfile.id</td><td>The Charging Station SHALL respond with a SetChargingProfileResponse with status Rejected and optionally with reasonCode = DuplicateProfile.</td><td></td></tr><tr><td>K01.FR.53</td><td>When a SetChargingProfileRequest with a TxDefaultProfile and evseld > 0 is received AND A TxDefaultProfile with the same stackLevel is installed on EVSE #0 and its chargingProfile.id does NOT equal the received chargingProfile.id</td><td>The Charging Station SHALL respond with a SetChargingProfileResponse with status Rejected and optionally with reasonCode = DuplicateProfile.</td><td></td></tr><tr><td>K01.FR.54 (2.1)</td><td>When Charging Station receives a ChargingProfileType with a ChargingSchedulePeriodTyp e with a value for numberPhases or phaseToUse AND the EVSE is of type DC AND DCInputPhaseControl is true</td><td>The Charging Station SHALL use numberPhases and phaseToUse to select the input phases from the grid for the DC EVSE.</td><td>See also K01.FR.44</td></tr><tr><td>K01.FR.55 (2.1)</td><td>When Charging Station stores charging profiles of purpose TxProfile, LocalGeneration or ChargingStationExter nalConstraints in persistent memory</td><td>Charging Station SHOULD report ChargingProfilePersistence with the instance set to the charging profile purpose, to true.</td><td>This tells CSMS that these charging profiles remain present after a reboot.</td></tr><tr><td>K01.FR.56(2.1)</td><td>When Charging Station receives a SetChargingProfileRequest for a ChargingProfileType with a chargingProfilePurpose that is to be stored persistently AND the previous SetChargingProfileRequest for this chargingProfilePurpose was less than ChargingProfileUpdatereRateLimit seconds ago</td><td>Charging Station MAY respond with SetChargingProfileResponse with status = Rejected andreasonCode = "RateLimitExceeded"</td><td>See also K01.FR.55 and K01.FR.27. IfChargingProfileUpdatereRateLimit does not exist, there is no rate limit.</td></tr><tr><td colspan="4">PriorityCharging</td></tr><tr><td>K01.FR.70(2.1)</td><td>Charging Station receives a SetChargingProfileRequest with chargingProfilePurpose = PriorityCharging and a chargingSchedule that has a value for duration</td><td>Charging Station responds with SetChargingProfileResponse with status = Rejected and an optional reasonCode = "InvalidSchedule"</td><td>A PriorityChargingprofile cannot have aduration. It lasts until end oftransaction, unless it isexplicitly ended by EV Driverat the Charging Station orvia a request to CSMS.</td></tr><tr><td>K01.FR.71(2.1)</td><td>Charging Station receives a SetChargingProfileRequest with chargingProfilePurpose = PriorityCharging and an operationMode that is not ChargingOnly</td><td>Charging Station responds with SetChargingProfileResponse with status = Rejected and an optional reasonCode = "InvalidSchedule"</td><td>A PriorityChargingprofile must only supportcharging.</td></tr><tr><td colspan="4">Max External Constraints Id</td></tr><tr><td>K01.FR.80(2.1)</td><td>When configuration variable MaxExternalConstraintsId is set</td><td>CSMS SHALL choose a value for the id of aChargingProfileType that is higher thanMaxExternalConstraintsId.</td><td>This ensures there will notbe a conflict with chargingprofile id's generated atCharging Station torepresentChargingStationExternalConstraints profiles.</td></tr><tr><td>K01.FR.81(2.1)</td><td>When configuration variable MaxExternalConstraintsId is set AND Charging Station receives a SetChargingProfileRequest with a chargingProfile.id that is less or equal to MaxExternalConstraintsId</td><td>Charging Station SHALL respond withSetChargingProfileResponse with status = Rejectedand add a statusInfo withreasonCode = "InvalidProfileId"</td><td></td></tr><tr><td>K01.FR.82(2.1)</td><td>When configuration variable MaxExternalConstraintsId is set AND Charging Station creates a charging profile of chargingProfilePurpose =ChargingStationExternalConstraints</td><td>Charging Station SHALL use a value for chargingProfile.idthat is less or equal to MaxExternalConstraintsId</td><td>A Charging Station createsa charging profileChargingStationExternalConstraints torepresent limits from anexternal source, e.g an EMS.</td></tr><tr><td colspan="4">Use Local Time / Randomized Delay</td></tr><tr><td>K01.FR.90(2.1)</td><td>When useLocalTime inChargingScheduleType is true</td><td>Charging Station SHALL treat the time in startSchedule asan unqualified local time, disregarding any time zoneoffset or "Z" postfix</td><td>What local time is, isconfigured at ChargingStation via TimeOffset orTimeZone. This allows thesame Absolute orRecurring chargingprofile to be used in bothsummer and winter time.</td></tr><tr><td>K01.FR.91(2.1)</td><td>K01.FR.90 AND A ChargingScheduleType is active at the moment that the local time shifts as a result of beginning or ending of daylight saving time</td><td>The execution of the ChargingScheduleType SHALL follow local time, i.e. part of the active chargingSchedulePeriod(s) will be skipped or repeated depending on the direction of the change.</td><td>This may affect more than one chargingSchedulePeriod.</td></tr><tr><td>K01.FR.92(2.1)</td><td>When randomizedDelay > 0 in ChargingScheduleType</td><td>Charging Station SHALL postpone the start of each chargingSchedulePeriod, except the first one that has startPeriod = 0, by a randomly chosen number of seconds between 0 and randomizedDelay.</td><td>In situations where all charging stations receive the same (recurring) charging profile, this avoids a peak in the grid that would occur when all charging stations change the power limit at exactly the same time.The first period is not delayed to avoid a gap between activation of the charging profile and the first schedule period becoming active.Since the start of the next period defines the end of the current period, this randomization also affects the end of the current period.</td></tr><tr><td>K01.FR.93(2.1)</td><td>K01.FR.92</td><td>Charging Station SHALL calculate random delays for chargingSchedulePeriods of the ChargingProfileType at the start of a transaction or when a new ChargingProfileType is submitted during a transaction.</td><td>This is to fix the actual start of charging schedule periods during a transaction, such that a GetCompositeScheduleRequest can calculate an accurate composite schedule.</td></tr><tr><td>K01.FR.94(2.1)</td><td></td><td>A randomizedDelay SHALL NOT affect the startSchedule and duration of a ChargingScheduleType.</td><td>Only startPeriod values of ChargingSchedulePeriodTypes are affected, with the exception of the first ChargingSchedulePeriodType that has startPeriod = 0.</td></tr><tr><td>K01.FR.95(2.1)</td><td>When a SetChargingProfileRequest is received from CSMS with chargingProfilePurpose that is NOT (TxProfile or TxDefaultProfile) AND a chargingSchedule with a randomizedDelay greater than 0</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status Rejected and optionally areasonCode = "InvalidSchedule".</td><td>From CSMS only Tx(Default)Profiles can have randomized delay.A ChargingStationExternalConstraints charging profile from an external system may also have a randomized delay.</td></tr><tr><td colspan="4">Limit Beyond SoC / Offline validity</td></tr><tr><td>K01.FR.100(2.1)</td><td>When limitAtSoC is present in ChargingScheduleType and the state of charge of the EV is greater than or equal to limitAtSoC.soc</td><td>Charging Station SHALL cap the limit or setpoint in the ChargingSchedulePeriodType by the value of limitAtSoClimit.</td><td>This allows to reduce charging power to EVs above a certain SoC. When absent or if SoC measurements are unavailable, Charging Station shall apply the charging schedule without additional limits. Unit of the limit is defined by chargingRateUnit.</td></tr><tr><td>K01.FR.101(2.1)</td><td>When fieldmaxOfflineDuration ispresent inChargingProfileType ANDCharging Station is offlinefor more thanmaxOfflineDuration seconds</td><td>Charging Station SHALL consider thisChargingProfileType to be not valid as long as it remainsoffline</td><td>If a valid charging profilewith a lower stack levelexists for whichmaxOfflineDuration has notyet expired or is not set,then that will be selected tobe used instead.</td></tr><tr><td>K01.FR.102(2.1)</td><td>When Charging Station'sconnection is restored</td><td>Charging Station SHALL consider theChargingProfileTypes that had been invalid while offlineto be (potentially) valid again, unless it hasinvalidAfterOfflineDuration = true, and recalculate whichChargingSchedulePeriodType to execute</td><td>It is possible that somecharging profiles may haveexpired during the offlineperiod.A missinginvalidAfterOfflineDuration isthe same asinvalidAfterOfflineDuration =false.</td></tr><tr><td>K01.FR.103(2.1)</td><td>When fieldmaxOfflineDuration is notpresent inChargingProfileType</td><td>Charging Station SHALL NOT consider thisChargingProfileType to be invalid during an offlinesituation.</td><td>There may be other reasonswhy the charging profilebecomes invalid, though.</td></tr><tr><td colspan="4">OperationMode</td></tr><tr><td>K01.FR.110(2.1)</td><td>When a newChargingSchedulePeriodType starts in aChargingProfileType thatapplies to this transaction,and the (optional)operationMode differs fromthat of the previousChargingSchedulePeriodType</td><td>Charging Station SHALL send a TransactionRequestwith triggerReason = OperationModeChanged and atransactionInfo element containing the newoperationMode.</td><td>The default value (whenabsent) of operationMode isChargingOnly.</td></tr><tr><td colspan="4">Checking optional support</td></tr><tr><td>K01.FR.120(2.1)</td><td>When Charging Stationreceives aSetChargingProfileRequestwith achargingProfilePurposePriorityChargingorLocalGeneration ANDThis chargingProfilePurposeis not inSupportedAdditionalPurposes</td><td>Charging Station SHALL respond withSetChargingProfileResponse with status = Rejectedand optionally withreasonCode = "UnsupportedPurpose".</td><td></td></tr><tr><td>K01.FR.121(2.1)</td><td>When Charging Stationreceives aSetChargingProfileRequestwith a chargingProfileKindDynamic ANDSupportsDynamicProfil es is false or absent</td><td>Charging Station SHALL respond withSetChargingProfileResponse with status = Rejectedand optionally withreasonCode = "UnsupportedKind".</td><td></td></tr><tr><td>K01.FR.122(2.1)</td><td>When Charging Stationreceives aSetChargingProfileRequestwith a dynUpdateInterval ordynUpdateTimeField ANDchargingProfileKind is notDynamic</td><td>Charging Station SHALL respond withSetChargingProfileResponse with status = Rejectedand optionally withreasonCode = "InvalidProfile".</td><td></td></tr><tr><td>K01.FR.123(2.1)</td><td>When Charging Stationreceives aSetChargingProfileRequestwith useLocalTime = trueANDSupportsLocalTime isfalse or absent</td><td>Charging Station SHALL respond withSetChargingProfileResponse with status = Rejectedand optionally withreasonCode = "InvalidSchedule".</td><td></td></tr></table>
+
+K02 - Central Smart Charging
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K01.FR.124(2.1)</td><td>When Charging Station receives a SetChargingProfileRequest with randomizedDelay > 0 AND SupportsRandomizedDelay is false or absent</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status = Rejected and optionally with reasonCode = "InvalidSchedule".</td><td></td></tr><tr><td>K01.FR.125(2.1)</td><td>When Charging Station receives a SetChargingProfileRequest with field limitAtSoC AND SupportsLimitAtSoC is false or absent</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status = Rejected and optionally with reasonCode = "InvalidSchedule".</td><td></td></tr><tr><td>K01.FR.126(2.1)</td><td>When Charging Station receives a SetChargingProfileRequest with evseSleep = true AND SupportsEvseSleep is false or absent</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status = Rejected and optionally with reasonCode = "InvalidSchedule".</td><td></td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Central Smart Charging</td></tr><tr><td>2</td><td>ID</td><td>K02</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to influence the charging power or current drawn from a specific EVSE or the entire Charging Station over a period of time.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by the EV. The CSMS calculates a ChargingSchedule to stay within limits which MAY be imposed by any external system.See: Central Smart Charging</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. After authorization the Charging Station will set a maximum current, that an EV might draw via the Control Pilot signal. This limit is based on (default) ChargingProfiles that the Charging Station previously received from the CSMS.2. The EV starts charging and a TransactionEventRequest is sent to the CSMS.3. The CSMS responds with a TransactionEventResponse.4. In response to a TransactionEventRequest the CSMS MAY choose to set charging limits to the transaction using a SetChargingProfileRequest.5. The Charging Station responds with a SetChargingProfileResponse.6. While charging is in progress the EVSE will continuously adapt the maximum current or power according to the installed ChargingProfiles.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>K03 - Local Smart ChargingK04 - Internal Load Balancing</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Functional Block Smart Charging is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The Charging Station Successfully influences the charging power or current of a specific EV, following the SetChargingProfileRequest sent by the CSMS.Failure postcondition:The Charging Station was not able to influence the charging power or current of a specific EV, following the SetChargingProfileRequest sent by the CSMS.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The CSMS determines the constraints on ChargingSchedule per transaction.The CSMS imposes charging limits on EVSEs. In response to a TransactionRequest the CSMS may choose to set charging limits to the transaction using the TxProfile. It is RECOMMENDED to check the offline flag in TransactionRequest prior to sending a charging profile to check if the transaction is likely to be still ongoing, the TransactionRequest might have been cached during an Offline period.The final schedule constraints that apply to a transaction are determined by merging the profiles with purposes ChargingStationMaxProfile with the profile TxProfile or TxDefaultProfile in case no profile of purpose TxProfile is provided. Zero or more of the following ChargingProfile purposes MAY have been previously received from the CSMS: ChargingStationMaxProfile or TxDefaultProfile.It is recommended to omit the duration field of the ChargingSchedule from a TxProfile, so that it automatically lasts until the end of the transaction. If the TxProfile expires before the transaction ends, it falls back to the lowest limit of the active TxDefaultProfile and ChargingStationMaxProfile. If there are no other active profiles, it falls back to the local limit of the Charging Station.The scenario description and sequence diagram above are not based on a specific TxStartPoint.The TxStopPoint is: EVConnectedThis use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use case: E01 - Start Transaction options.</td></tr></table>
+
+
+Figure 124. Sequence Diagram: Central Smart Charging
+
+Explanation for the above figure:
+
+- After authorization the EVSE will set a maximum current to use via the Control Pilot signal. This limit is based on a (default) charging profile that the EVSE had previously received from the CSMS. The EV starts charging and a TransactionEventRequest is sent to the CSMS.
+- While charging is in progress the EVSE will continuously adapt the maximum current or power according to the charging profile. Optionally, at any point in time the CSMS may send a new charging profile for the EVSE. The Charging Station will then also take this new schedule into account when calculating a new composite schedule. This way the CSMS can influence the charging of an ongoing transaction.
+
+# K02 - Central Smart Charging - Requirements
+
+Table 98. K02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K02.FR.01</td><td></td><td>The CSMS SHALL use charging profiles to stay within the limits imposed by any external system.</td><td></td></tr><tr><td>K02.FR.02</td><td>After authorization.</td><td>The EVSE will set a maximum current to use via the Control Pilot signal.</td><td>This requirement only applies to AC chargers that use 61851. The limit may be based on a (default) charging profile that the EVSE previously received from the CSMS.</td></tr><tr><td>K02.FR.03</td><td></td><td>In order to ensure that an updated ChargingProfile applies only to the current transaction, the CSMS SHALL set the chargingProfilePurpose of the ChargingProfile to TxProfile.</td><td>An updated charging profile can be sent by the CSMS by sending a ChargingProfile with the same chargingProfileId.</td></tr><tr><td>K02.FR.04</td><td>If a transaction-specific profile with purpose TxProfile is present.</td><td>The TxProfile SHALL overrule the default charging profile with purpose TxDefaultProfile for the duration of the current transaction only.</td><td></td></tr><tr><td>K02.FR.05</td><td>K02.FR.04 After the transaction is stopped</td><td>The TxProfile SHALL be deleted.</td><td></td></tr><tr><td>K02.FR.06</td><td></td><td>The optional ChargingSchedule field minChargingRate MAY be used by the Charging Station to optimize the power distribution between the EVSEs.</td><td>The parameter informs the Local Controller that charging below minChargingRate is inefficient, giving the possibility to select another balancing strategy. (Same as K01.FR.21)</td></tr><tr><td>K02.FR.07</td><td></td><td>The CSMS SHALL NOT set chargingProfilePurpose to ChargingStationExternalConstraints in a SetChargingProfileRequest.</td><td>This purpose is only used when an external system has set a charging limit/schedule. (Same as K01.FR.22)</td></tr><tr><td>K02.FR.08</td><td>K02.FR.04 AND The charging schedule of TxProfile ends, before the transaction ends, because the set duration or validTo period expired</td><td>The Charging Station SHALL fall back to using the lowest limit of the active TxDefaultProfile and ChargingStationMaxProfile. If there are no other active profiles, it falls back to the local limit of the Charging Station</td><td></td></tr></table>
+
+K03 - Local Smart Charging
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Local Smart Charging</td></tr><tr><td>2</td><td>ID</td><td>K03</td></tr><tr><td>3</td><td>Objective(s)</td><td>To illustrate the process of local load-balancing by a Local Cluster.</td></tr><tr><td>4</td><td>Description</td><td>This use case is an example of how local load-balancing can be performed. It does not imply that other approaches would not be correct. The process has been simplified for clarity and should not be regarded as prescriptive.A Local Controller is configured with a value for maximum current for the total cluster by CSMS via a charging profile of type ChargingStationMaxProfile to the Local Controller, or an EMS may have set a ChargingStationExternalConstraints charging profile.The Local Controller divides the maximum current among the active transactions. Whenever a transaction starts or finishes, the Local Controller will update the charging profiles of the remaining transactions to divide the maximum current equally.For simplicity's sake, this use case does not differentiate on departure time or state of charge of vehicles, nor does it take the actual energy consumption of vehicles into account.</td></tr><tr><td></td><td>Actors</td><td>Charging Station (CS01, CS02), Local Controller (LC), CSMS</td></tr><tr><td></td><td>Scenario description</td><td>Assume no transactions are active in the local cluster and the maximum current for the local cluster has been configured to be 100 A. The charging stations all have a TxDefaultProfile that allows a current of only 6 A, so that vehicles cannot immediately start charging at full power before the LC had the chance to set a charging profile.1. A transaction starts on charging station CS01. It sends a TransactionEventRequest(Started) to LC.2. LC is configured to do local load-balancing (i.e. its SmartChargingCtrl.Enabled = true), so it registers the transaction id TX1 of the transaction that has been started on CS01, before forwarding the message on the websocket for CS01 towards CSMS.3. LC sends a SetChargingProfileRequest to CS01 with chargingProfilePurpose = TxProfile, chargingProfileKind = Relative, transactionId = TX1 and a chargingSchedule with a chargingRateUnit = A that contains one chargingSchedulePeriod with a limit of 94 A, so that the entire quota is available to this transaction minus the TxDefaultProfile amount for new transactions.4. Another transaction starts on charging station CS02. It sends a TransactionEventRequest(Started) to LC.5. LC registers the new transaction id TX2 and forwards the message on the websocket for CS02 to CSMS.6. LC divides the available quota by allowing each transaction a maximum of 47 A.7. LC sends a SetChargingProfile message to CS01 that updates the existing TxProfile and sets the limit to 47 A.8. LC sends new SetChargingProfile to CS02 with chargingProfilePurpose = TxProfile, chargingProfileKind = Relative, transactionId = TX2 and a chargingSchedule with a chargingRateUnit = A that contains one chargingSchedulePeriod with a limit of 47 A.9. The transaction of CS01 finishes. It sends a TransactionEventRequest(Ended) to LC.10. LC registers that transaction TX1 on CS01 has finished and forwards the message on the websocket for CS01 to CSMS.11. LC now allows the maximum to TX2. It sends a SetChargingProfile message to CS02 that updates the existing TxProfile and sets the limit to 94 A. (Note, that the TxProfile for TX1 on CS01 has automatically ceased to exist upon termination of the transaction.)</td></tr><tr><td>5</td><td>Prerequisites</td><td>The LC has been configured with a fixed maximum current level.The SmartChargingCtrl component of Local Controller has been Enabled, which will trigger the Local Controller to read and interpret TransactionEventRequest messages from connected Charging Stations.</td></tr><tr><td>6</td><td>Post conditions</td><td></td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>As described in Part 1, a Local Controller replicates all web sockets from Charging Stations in the cluster towards CSMS, and forwards messages from Charging Station to CSMS on the appropriate web socket (and vice versa). This allows the Local Controller to read messages, such as a TransactionRequest message, from the Charging Station.The Local Controller for local smart charging can be implemented in different ways, for example: as a separate physical component or as part of a "master" Charging Station controlling a number of other Charging Stations. The Local Controller MAY or MAY NOT have any EVSEs of its own.The limits on Charging Stations in a Local Smart Charging group can either be pre-configured in the Local Controller in one way or another, or they can be set by the CSMS. The Local Controller contains the logic to distribute this capacity among the connected EVSEs by adjusting their limits as needed.</td></tr></table>
+
+
+Figure 125. Local Controller performing local load-balancing
+
+# K03 - Local Smart Charging - Requirements
+
+Table 99. K03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K03.FR.01</td><td></td><td>The Local Controller MAY impose charging limits on a Charging Station.</td><td></td></tr><tr><td>K03.FR.02</td><td>K03.FR.01</td><td>These limits MAY be changed dynamically during the charging process in order to keep the power consumption of the group of Charging Stations within the group limits.</td><td></td></tr><tr><td>K03.FR.03</td><td>If at any point in time the Local Controller sends a new ChargingProfile to an EVSE</td><td>The Charging Station SHALL take this new ChargingProfile into account when calculating a new composite schedule that it will use to charge the EV.</td><td></td></tr><tr><td>K03.FR.04</td><td></td><td>A Transaction with a chargingPriority that is higher than other transactions SHALL be fulfilled as long as possible, even if other transactions have to be suspended.</td><td></td></tr><tr><td>K03.FR.05</td><td>If a chargingPriority is given in a TransactionEventResponse that is different from the chargingPriority in the IdTokenInfo.</td><td>The chargingPriority from the TransactionEventResponse SHALL be used for this transaction and for this transaction only.</td><td>It shall therefore not be stored e.g. in the Authorization Cache.</td></tr><tr><td>K03.FR.06</td><td>When no chargingPriority is known.</td><td>The Transaction or IdToken SHALL be assumed to have chargingPriority 0.</td><td></td></tr><tr><td>K03.FR.07</td><td></td><td>The optional ChargingSchedule field minChargingRate MAY be used by the Charging Station to optimize the power distribution between the EVSEs.</td><td>The parameter informs the Local Controller that charging below minChargingRate is inefficient, giving the possibility to select another balancing strategy. (Same as K01.FR.21)</td></tr><tr><td>K03.FR.08</td><td></td><td>The Local Controller SHALL NOT set chargingProfilePurpose to ChargingStationExternalConstraints in a SetChargingProfileRequest.</td><td>This purpose is only used when an external system has set a charging limit/schedule. (Same as K01.FR.22)</td></tr></table>
+
+K04 - Internal Load Balancing
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Internal Load Balancing</td></tr><tr><td>2</td><td>ID</td><td>K04</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable internal load balancing within the Charging Station and between EVSEs.</td></tr><tr><td>4</td><td>Description</td><td>The Load Balancing use case is about internal load balancing within the Charging Station, where the Charging Station controls current/power per EVSE.The Charging Station is configured with a fixed limit, e.g. the maximum current of the connection to the grid.See K01 - Set Charging Profile</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sets known physical grid connection limits by sending a ChargingProfile.2. The Charging Station controls current/power per EVSE.3. The EVSE sends a Control Pilot signal to the EV.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Functional Block Smart Charging is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The Charging Station Successfully balances the current/power between the different EVSEs,based on what the CSMS is sending.Failure postcondition:ChargingProfile is not Accepted. Charging is possible, although the Charging Station will not adhere to the ChargingProfile.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+# K04 - Internal Load Balancing - Requirements
+
+Table 100. K04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K04.FR.01</td><td></td><td>The Charging Station SHALL control the ChargingSchedule per EVSE.</td><td></td></tr><tr><td>K04.FR.02</td><td></td><td>The Charging Station SHALL be configured with a fixed limit.</td><td>e.g. the maximum current of the connection to the grid.</td></tr><tr><td>K04.FR.03</td><td></td><td>A ChargingProfile with the purpose ChargingStationMaxProfile can only be set at Charging Station EVSE with Id 0.</td><td>EVSE 0 refers to entire Charging Station.</td></tr><tr><td>K04.FR.04</td><td></td><td>The optional ChargingSchedule field minChargingRate MAY be used by the Charging Station to optimize the power distribution between the EVSEs.</td><td>The parameter informs the Local Controller that charging below minChargingRate is inefficient, giving the possibility to select another balancing strategy. (Same as K01.FR.21)</td></tr><tr><td>K04.FR.05 (2.1)</td><td></td><td>The combined energy flow of all EVSEs (and the Charging Station hardware itself) SHALL NOT be greater than the combined limit set by ChargingStationMaxProfile + LocalGeneration.</td><td>For details about LocalGeneration see use case K27 - Smart Charging with EMS and LocalGeneration.</td></tr></table>
+
+# K05 - Remote Start Transaction with Charging Profile
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Remote Start Transaction with Charging Profile</td></tr><tr><td>2</td><td>ID</td><td>K05</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to remotely start a transaction by directly including a ChargingProfile, in order to assure that the transaction will use the right ChargingProfile.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers how the CSMS can remotely start a transaction with purpose TxProfile. This assures that the right TxProfile is used. Also, when the Charging Station goes Offline after receiving RequestStartTransactionRequest.
+This is also needed, as switching from three phase- to one phase charging is not always possible and the transaction needs to start at the right phase.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, External Trigger</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS requests a Charging Station to remotely start a transaction by sending a RequestStartTransactionRequest with a ChargingProfile with purpose TxProfile.
+2. The Charging Station responds with a RequestStartTransactionResponse indicating that it is able to start the transaction and will use the ChargingProfile.
+3. The Charging Station informs the CSMS that a transaction has started by sending a TransactionEventRequest (eventType = Started) message.
+4. The transaction is started in the same way as described in E. Transaction.
+5. The Charging Station sends a TransactionEventRequest (eventType = Updated) to inform the CSMS that it is charging.
+6. The Charging Station continues the regular smart charging session, following the set ChargingProfiles.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Functional Block Smart Charging is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station Successfully charges taking into account the provided ChargingProfile.
+Failure postcondition:
+The transaction is not started.
+The Charging Station Unsuccessfully charges taking into account the provided ChargingProfile.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The scenario description and sequence diagram above are based on the Configuration Variable for start transaction being configured as follows:
+TxStartPoint: EVConnected or PowerPathClosed
+This use-case is also valid for other configurations, but then the transaction might start/stop at another moment, which might change the sequence in which message are send. For more details see the use case: E01 - Start Transaction options.
+When a ChargingProfile with purpose TxProfile is provided as part of a RequestStartTransactionRequest, then a transactionId cannot be provided in the ChargingProfile, because it is not known at the time.</td></tr></table>
+
+
+Figure 126. Sequence Diagram: Remote Start Transaction with Charging Profile
+
+# K05 - Remote Start Transaction with Charging Profile - Requirements
+
+Table 101. K05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K05.FR.01</td><td></td><td>The CSMS MAY include a ChargingProfile in a RequestStartTransactionRequest.</td><td></td></tr><tr><td>K05.FR.02</td><td>K05.FR.01</td><td>The Purpose of the ChargingProfile SHALL always be TxProfile.</td><td></td></tr><tr><td>K05.FR.03</td><td>K05.FR.01 AND NOT K05.FR.04</td><td>The Charging Station SHALL use the given profile to calculate its composite schedule.</td><td></td></tr><tr><td>K05.FR.04</td><td>If a Charging Station without support for Smart Charging receives a RequestStartTransactionRequest with a ChargingProfile.</td><td>The Charging Station SHALL ignore the specified ChargingProfile.</td><td>The device model variable SmartChargingCtrlr.Enabled tells CSMS whether smart charging is supported. Same as F01.FR.12</td></tr><tr><td>K05.FR.05</td><td>If a Charging Station with support for Smart Charging receives a RequestStartTransactionRequest with an invalid ChargingProfile.</td><td>The Charging Station SHALL respond with RequestStartTransactionResponse with status = Rejected and optionally with reasonCode = "InvalidProfile" or "InvalidSchedule".</td><td>The device model variable SmartChargingCtrlr.Enabled tells CSMS whether smart charging is supported. Same as F01.FR.26</td></tr></table>
+
+# K06 - Offline Behavior Smart Charging During Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Offline Behavior Smart Charging During Transaction</td></tr><tr><td>2</td><td>ID</td><td>K06</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Charging Station to continue to use the current ChargingProfile for the duration of the transaction while it is Offline.</td></tr><tr><td>4</td><td>Description</td><td>If a Charging Station goes Offline after having received a transaction-specific ChargingProfile with purpose TxProfile, then it continues to use this profile for the duration of the transaction.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a SetChargingProfileRequest to the Charging Station with a TxProfile.
+2. The Charging Station responds with a SetChargingProfileResponse.
+3. While charging is in progress the EVSE will continuously adapt the maximum current or power according to the installed ChargingProfiles.
+4. The Charging Station is Offline and operates stand-alone.
+5. While charging is in progress the EVSE will continuously adapt the maximum current or power according to the already installed ChargingProfiles.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A transaction is ongoing.
+The Functional Block Smart Charging is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station continues to use the charging profiles which are available.
+Failure postcondition:
+n/a</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 127. Sequence Diagram: Offline Behavior Smart Charging
+
+# K06 - Offline Behavior Smart Charging During Transaction - Requirements
+
+Table 102. K06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>K06.FR.01</td><td>If the Charging Station goes Offline after having received a transaction-specific ChargingProfile with purpose TxProfile.</td><td>The Charging Station SHALL continue to use this profile for the duration of the transaction.</td></tr><tr><td>K06.FR.02</td><td>If the Charging Station goes Offline, without having any charging profiles.</td><td>The Charging Station SHALL execute the transaction as if no constraints apply.</td></tr></table>
+
+# K07 - Offline Behavior Smart Charging at Start of Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Offline Behavior Smart Charging at Start of Transaction</td></tr><tr><td>2</td><td>ID</td><td>K07</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the Charging Station to continue to use a ChargingProfile for a transaction which is started Offline.</td></tr><tr><td>4</td><td>Description</td><td>By setting a TxDefaultProfile on a Charging Station, the CSMS can assure that any transaction, which is started while the communication with the CSMS is Offline, uses this profile.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EV, EV Driver</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a SetChargingProfileRequest to the Charging Station with a TxDefaultProfile.
+2. The Charging Station responds with a SetChargingProfileResponse.
+3. The Charging Station goes Offline and operates stand-alone.
+4. The Charging Station allows automatic authorization of any presented IdToken by either:
+a. The Local Authorization List; a list of identifiers that can be synchronized with the CSMS.
+b. Authorization Cache entries; which autonomously maintains a record of previously presented identifiers that have been successfully authorized by the CSMS. (Successfully meaning: a response received on a message containing an IdToken).
+c. Configuration Variable: OfflineTxForUnknownIdEnabled = TRUE
+5. The transaction is started in the same way as described in E. Transactions.
+6. While charging is in progress the EVSE will continuously adapt the maximum current or power according to the already installed ChargingProfiles.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station is Offline.
+The Functional Block Smart Charging is installed.
+The IdToken is known in the Local Authorization List, the IdToken is known in the Authorization Cache, or unknown offline authorization is enabled.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station uses the installed TxDefaultProfile which are available for the Offline started transaction.
+Failure postcondition:
+n/a</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>See section Combining Charging Profile Purposes for a description on how to combine different charging profile purposes.</td></tr></table>
+
+
+Figure 128. Sequence Diagram: Offline Behavior Smart Charging
+
+# K07 - Offline Behavior Smart Charging at Start of Transaction - Requirements
+
+Table 103. K07 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K07.FR.01</td><td>If a Charging Station goes Offline before a transaction is started or before a transaction-specific ChargingProfile with purpose TxProfile was received.</td><td>The Charging Station SHALL use the charging profiles which are available.</td><td>With purpose TxDefaultProfile for the duration of the current transaction only.</td></tr></table>
+
+# K08 - Get Composite Schedule
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Composite Schedule</td></tr><tr><td>2</td><td>ID</td><td>K08</td></tr><tr><td>3</td><td>Objective(s)</td><td>To request the Charging Station to report the composite charging schedule.</td></tr><tr><td>4</td><td>Description</td><td>This use cases describes how the CSMS requests the Charging Station to report the Composite Charging Schedule, as calculated by the Charging Station, by sending GetCompositeScheduleRequest.The CompositeSchedule is the result of the calculation of all active schedules and possible local limits present in the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS requests the Charging Station to report the Composite Charging Schedule by sending a GetCompositeScheduleRequest.2. The Charging Station calculates the schedule.3. The Charging Station responds with a GetCompositeScheduleResponse with the status and ChargingSchedule.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Functional Block Smart Charging is installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The CSMS Successfully received the composite schedule from the Charging Station.Failure postcondition:The CSMS did not receive the composite schedule from the Charging Station.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Please note that the charging schedule sent by the Charging Station is only indicative for that point in time. This schedule might change over time due to external causes (e.g. local balancing based on grid connection capacity is active and one EVSE becomes available).The Composite Schedule that will guide the charging level is a combination of the prevailing Charging Profiles of the different chargingProfilePurposes.This Composite Schedule is calculated by taking the minimum value for each time interval (see:Smart Charging signals to a Charging Station from multiple actors). Time intervals do not have to be of fixed length, nor do they have to be the same for every charging profile purpose. This means that a resulting Composite Schedule MAY contain intervals of different lengths.The reported schedule, in GetCompositeScheduleResponse, is the result of the calculation of all active schedules and possible local limits present in the Charging Station.The composite schedule reports the expected power or current the Charging Station expects to consume from the grid, for the requested EVSE, during the requested time period.When requested for evseid=0, the Charging Station will calculate the total expected consumption for the grid connection.</td></tr></table>
+
+CSMS
+
+Charging Station
+
+GetCompositeScheduleRequest(heveld, duration)
+
+calculate schedule
+
+GetCompositeScheduleResponse(status, schedule)
+
+Figure 129. Sequence Diagram: Get Composite Schedule
+
+# K08 - Get Composite Schedule - Requirements
+
+Table 104. K08 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>K08.FR.01</td><td></td><td>The CSMS MAY request the Charging Station to report the CompositeSchedule by sending GetCompositeScheduleRequest.</td></tr></table>
+
+K09 - Get Charging Profiles
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>K08.FR.02</td><td>Upon receipt of GetCompositeScheduleRequest.</td><td>The Charging Station SHALL calculate the scheduled time intervals, from the moment of message receipt up to the Duration (in seconds) and send them to the CSMS.</td></tr><tr><td>K08.FR.03</td><td>If the evseld in the GetCompositeScheduleRequest is set to '0'</td><td>The Charging Station SHALL report the total expected power or current the Charging Station expects to consume from the grid during the requested time period.</td></tr><tr><td>K08.FR.04 (2.1)</td><td></td><td>At any point in time, the charging limit, dischargingLimit or setpoint, reactiveSetpoint in the CompositeSchedule which are the result of merging the schedules from all valid charging profiles with the highest stackLevel from each of the purposes ChargingStationMaxProfile, ChargingStationExternalConstraints and TxDefaultProfile (or TxProfile or PriorityCharging), SHALL be less than or equal to the lowest value of available power or current in any of the merged schedules. If a charging profile with purpose LocalGeneration is active, this capacity is added on top of the calculated charging limit based on above-mentioned merged schedules. (See also SC.01)</td></tr><tr><td>K08.FR.05</td><td>If the Charging Station is not able to report the requested schedule, for instance if the evseld is unknown</td><td>The Charging Station SHALL respond with the status Rejected.</td></tr><tr><td>K08.FR.06 (2.1)</td><td>K08.FR.02 AND When there is no transaction active on an EVSE</td><td>The Charging Station SHALL calculate the CompositeSchedule as if there is a transaction ongoing on the EVSE that is using the TxDefaultProfile (if this profile purpose is set) with a randomizedDelay = 0.</td></tr><tr><td>K08.FR.07</td><td>When receiving a GetCompositeScheduleRequest with a chargingRateUnit, which is not configured in the configuration variable ChargingScheduleChargingRat eUnit</td><td>The Charging Station SHALL respond with GetCompositeScheduleResponse with status Rejected.</td></tr><tr><td>K08.FR.08 (2.1)</td><td>K08.FR.04 AND the result of merging schedules from all charging profiles contains limit or dischargingLimit values as well as setpoint values</td><td>Charging Station SHALL cap negative values of setpoint to the value of dischargingLimit and positive values of setpoint to the value of limit. (See V2X.03 and V2X.04)</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Charging Profile</td></tr><tr><td>2</td><td>ID</td><td>K09</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to view the Charging Schedules/limits installed in a Charging Station, these can be installed by the CSMS or some other source.</td></tr><tr><td>4</td><td>Description</td><td>With the GetChargingProfilesRequest message the CSMS can ask a Charging Station to report all, or a subset of all the install Charging Profiles from the different possible sources. This can be used for some automatic smart charging control system, or for debug purposes by a CSO.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1 The CSMS asks the Charging Station for the installed charging profiles by sending a GetChargingProfilesRequest message.
+2 The Charging Station responds, indicating if it can report Charging Schedules by sending a GetChargingProfilesResponse message.
+3 Charging Station sends a number of ReportChargingProfilesRequest messages to CSMS.
+4 The CSMS acknowledges reception of the reports by sending a ReportChargingProfilesResponse to the Charging Station for every ReportChargingProfilesRequest.</td></tr><tr><td>5</td><td>Prerequisites</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS knows which charging profiles have been installed in the Charging Station that match the requested parameters.</td></tr><tr><td>7</td><td>Error Handling</td><td>When the Charging Station has no charging profiles that match the parameters in the GetChargingProfilesRequest the Charging Station SHALL respond with: NoProfiles.</td></tr><tr><td>8</td><td>Remarks</td><td>The charging profiles report can be split over multiple ReportChargingProfilesRequest messages, this can be because charging profiles for different charging sources need to be reported, or because there is just to much data for one message. To indicate that more reports will follow the flag tbc can be used.</td></tr></table>
+
+
+Figure 130. Sequence diagram of the use case "Get Charging Profiles"
+
+# K09 - Get Charging Profiles - Requirements
+
+Table 105. K09 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K09.FR.01</td><td>When requestId is set in the GetChargingProfilesRequest</td><td>The Charging Station SHALL set the requestId in every ReportChargingProfilesRequest that is sent as a result of this GetChargingProfilesRequest.</td><td></td></tr><tr><td>K09.FR.02</td><td>When the charging profiles are reported in more than one ReportChargingProfilesRequest</td><td>The Charging Station SHALL set the tbc flag to true for all ReportChargingProfilesRequest messages except the last.</td><td></td></tr><tr><td>K09.FR.03</td><td></td><td>The CSMS SHALL specify in chargingProfile criteria in GetChargingProfilesRequest either: - a (list of) chargingProfileId(s) OR - one or more of the fields stackLevel, chargingLimitSource, chargingProfilePurpose.</td><td>These fields are filter values of equal importance, but because a chargingProfileId uniquely identifies a charging profile, the other fields are not needed if chargingProfiles are used.</td></tr><tr><td>K09.FR.04</td><td>If evseld is set to a value greater than 0 in the GetChargingProfilesRequest</td><td>The Charging Station SHALL report the installed charging profiles for the specified EVSE that match all fields in chargingProfile.</td><td></td></tr><tr><td>K09.FR.05</td><td>If evseld is set to 0 in GetChargingProfilesRequest</td><td>The Charging Station SHALL only report charging profiles installed on the Charging Station itself (the grid connection) that match all fields in chargingProfile.</td><td>EVSE #0 can have a ChargingStation MaxProfile, ChargingStation ExternalConstraints or a TxDefaultProfile. Note, that a TxDefaultProfile is not applied to EVSE #0 but to all individual EVSEs (see K01.FR.14).</td></tr><tr><td>K09.FR.06</td><td>If evseld is NOT set in the GetChargingProfilesRequest</td><td>The Charging Station SHALL report all installed charging profiles that match all fields in chargingProfile.</td><td></td></tr></table>
+
+# K10 - Clear Charging Profile
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Clear Charging Profile</td></tr><tr><td>2</td><td>ID</td><td>K10</td></tr><tr><td>3</td><td>Objective(s)</td><td>To clear some or all of the charging profiles.</td></tr><tr><td>4</td><td>Description</td><td>If the CSMS wishes to clear some or all of the charging profiles that were previously sent to the Charging Station, then the CSMS sends a ClearChargingProfileRequest to the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a ClearChargingProfileRequest to the Charging Station.
+2. The Charging Station responds with a ClearChargingProfileResponse specifying whether it was able to process the request in the status.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>One or more ChargingProfiles are installed.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The requested charging profiles are Successfully cleared.
+Failure postcondition:
+The requested charging profiles are not cleared, as no ChargingProfile is found.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 131. Sequence Diagram of the use case "Clear Charging Profile"
+
+# K10 - Clear Charging Profile - Requirements
+
+Table 106. K10 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>K10.FR.01</td><td>If the Charging Station does not have any matching ChargingProfile.</td><td>Upon receipt of a ClearChargingProfileRequest, the Charging Station SHALL respond with the status Unknown.</td><td></td></tr><tr><td>K10.FR.02</td><td></td><td>The CSMS SHALL either specify a chargingProfile.id OR include one or more of the fields stackLevel, evseld and chargingProfilePurpose in the ClearChargingProfileRequest to specify which Charging Profiles need to be cleared.</td><td></td></tr><tr><td>K10.FR.03</td><td>Upon receipt of a ClearChargingProfileRequest with a specified chargingProfileId AND the chargingProfilePurpose of the referenced ChargingProfile is NOT ChargingStationExternalConstraints</td><td>The Charging Station SHALL clear the Charging Profile with the matching id and respond with a ClearChargingProfileResponse message with status = Accepted.</td><td></td></tr><tr><td>K10.FR.04 (2.1)</td><td>NOT K10.FR.03 AND NOT K10.FR.08 AND Upon receipt of a ClearChargingProfileRequest, with optional values for evseld, chargingProfilePurpose, stackLevel</td><td>The Charging Station SHALL clear the ChargingProfile(s) that match (as logical AND) the values in the request, except those for that have ChargingProfilePurpose = ChargingStationExternalConstraints or LocalGeneration and respond with a ClearChargingProfileResponse message with status = Accepted.</td><td></td></tr><tr><td>K10.FR.05</td><td>After clearing one or more Charging Profiles.</td><td>The Charging Station SHALL recalculate its composite schedule and set the resulting maximum power/current values to all ongoing transactions.</td><td></td></tr><tr><td>K10.FR.06</td><td></td><td>The CSMS SHALL NOT set chargingProfilePurpose to ChargingStationExternalConstraints in a ClearChargingProfileRequest.</td><td></td></tr><tr><td>K10.FR.06 (2.1)</td><td></td><td>The CSMS SHALL NOT set chargingProfilePurpose to ChargingStationExternalConstraints or LocalGeneration in a ClearChargingProfileRequest.</td><td></td></tr><tr><td>K10.FR.07</td><td>K10.FR.05 AND the cleared profile has chargingProfilePurpose = TxDefaultProfile</td><td>The Charging Station SHALL continue any active transaction, that started with a TxDefaultProfile, as if it was started without a TxDefaultProfile.</td><td></td></tr><tr><td>K10.FR.08 (2.1)</td><td>Upon receipt of a ClearChargingProfileRequest, with optional values for evseld, chargingProfilePurpose, stackLevel AND the matched ChargingProfile(s) all have ChargingProfilePurpose = ChargingStationExter nalConstraints or LocalGeneration</td><td>The Charging Station SHALL respond with a ClearChargingProfileResponse message with status = Unknown.</td><td>Charging profiles for external constraints are disregarded by ClearChargingProfile message.</td></tr><tr><td>K10.FR.09 (2.1)</td><td>Upon receipt of a ClearChargingProfileRequest with a specified chargingProfileId AND the chargingProfilePurpose of the referenced ChargingProfile = ChargingStationExter nalConstraints or LocalGeneration</td><td>The Charging Station SHALL respond with a ClearChargingProfileResponse message with status = Unknown.</td><td>Charging profiles for external constraints are disregarded by ClearChargingProfile message.</td></tr></table>
+
+# 5.2. External Charging Limit based Smart Charging
+
+# K11 - Set / Update External Charging Limit With Ongoing Transaction
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set / Update External Charging Limit With Ongoing Transaction</td></tr><tr><td>2</td><td>ID</td><td>K11</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS of a charging schedule or charging limit imposed by an External Control System on the Charging Station with ongoing transaction(s).</td></tr><tr><td>4</td><td>Description</td><td>An External Control System sends a charging limit/schedule to a Charging Station. This limit is sent to the CSMS. The External Control System can be a DSO, but also a smart meter or a home energy management system. The interface between External Control System and Charging Station is not specified. It can be any protocol that is supported by Charging Station for this purpose, even OCPP.</td></tr><tr><td></td><td>Actors</td><td>External Control System, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. External control system sends charging limit/schedule to Charging Station.
+2. Optional: Charging Station calculates new charging schedule.
+3. Charging Station adjusts the charging speed of the ongoing transaction(s).
+4. If the charging limit changed by more than: LimitChangeSignificance, the Charging Station sends a NotifyChargingLimitRequest message to CSMS with optionally the set charging limit/schedule.
+5. The CSMS responds with NotifyChargingLimitResponse to the Charging Station.
+6. If the charging rate changes by more than: LimitChangeSignificance, the Charging Station sends a TransactionEventRequest message to inform the CSMS.
+7. The CSMS responds with TransactionEventResponse to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station is not in error state.
+The external system can set/clear a charging limit/schedule on the Charging Station via a direct connection to the Charging Station.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The ongoing transaction will be limited by the received charging limit from the external system. The CSMS is informed of the new limit/schedule imposed by the external system.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The external system could, for example, use IEC 61850 [IEC61850-7-420] or OpenADR [OPENADR] to communicate the grid limit to the Charging Station, but this could be any protocol. An example of an external system is given, in this case a smart meter that might set an external charging limit to protect against overloading the local grid connection, but this could be any other external system that sets a charging limit.
+It is up to the Charging Station implementation to decide whether to represent the external limits for ChargingStationExternalConstraints as an Absolute or Relative charging profile or as a Dynamic charging profile with an operationMode = ExternalLimits.</td></tr></table>
+
+
+Figure 132. Sequence diagram of the use case "Setting / Updating External Charging Limit with Ongoing Transaction"
+
+# K11 - Set / Update External Charging Limit With Ongoing Transaction - Requirements
+
+Table 107. K11 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K11.FR.01(2.1)</td><td>When an external charging limit/schedule is received during an ongoing transaction AND ExternalConstraintsProfileDisallowed is false or absent</td><td>The Charging Station SHALL NOT charge the ongoing transaction faster than this given limit/schedule.</td><td></td></tr><tr><td>K11.FR.02</td><td>K11.FR.01ANDCharging limit changed by more than:LimitChangeSignifica nce</td><td>The Charging Station SHALL inform the CSMS of the new charging limit/schedule imposed by the external system by sending a NotifyChargingLimitRequest.</td><td></td></tr><tr><td>K11.FR.03</td><td>K11.FR.02ANDEnableNotifyCharging LimitWithSchedules is true</td><td>The NotifyChargingLimitRequest SHALL contain the charging limits/schedules as set by the external system.</td><td></td></tr><tr><td>K11.FR.04</td><td>K11.FR.01ANDCharging rate changed by more than:LimitChangeSignifica nce</td><td>The Charging Station SHALL send a TransactionEventRequest message to the CSMS with trigger = ChargingRateChanged</td><td></td></tr><tr><td>K11.FR.05</td><td>K11.FR.02</td><td>The Charging Station SHALL NOT set the chargingLimitSource to cso in the NotifyChargingLimitRequest.</td><td></td></tr><tr><td>K11.FR.06 (2.1)</td><td>K11.FR.01</td><td>The Charging Station SHALL use purpose ChargingStationExternalConstraints when reporting about this limit (i.e. in a ReportChargingProfilesRequest).</td><td>It is RECOMMENDED to use negative values for the id of a ChargingStationExter nalConstraints profile, to minimize the risk of a clash with an id that CSMS might use for a (future) charging profile. See use case K29 for the use of Dynamic charging profiles and external limits.</td></tr><tr><td>K11.FR.07 (2.1)</td><td>When an external charging limit/schedule is received during an ongoing transaction AND ExternalConstraintsProfileDisallowed is true</td><td>The Charging Station SHALL ignore the external charging limit/schedule.</td><td>CSMS will need to set a charging profile with operationMode = ExternalLimits to allow this. See use case K29.</td></tr></table>
+
+# K12 - Set / Update External Charging Limit Without Ongoing Transaction
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set / Update External Charging Limit Without Ongoing Transaction</td></tr><tr><td>2</td><td>ID</td><td>K12</td></tr><tr><td>3</td><td>Objective(s)</td><td>To inform the CSMS of a charging schedule or charging limit imposed by an external system on the Charging Station for new transactions or on the grid connection.</td></tr><tr><td>4</td><td>Description</td><td>To inform the CSMS of a charging schedule or charging limit imposed by an external system on the Charging Station for new transactions or on the grid connection. The External Control System can be a DSO, but also a smart meter or a home energy management system. The interface between External Control System and Charging Station is not specified. It can be any protocol that is supported by Charging Station for this purpose, even OCPP.</td></tr><tr><td></td><td>Actors</td><td>External Control System, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. External Control System sends a charging limit to Charging Station (not during a transaction).2. Optional: Charging Station calculates new charging schedule.3. Charging Station adjusts the charging speed.4. If the charging limit changed by more than: LimitChangeSignificance, the Charging Station sends a NotifyChargingLimitRequest message to CSMS with optionally the set charging limit/schedule.5. The CSMS responds with a NotifyChargingLimitResponse to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station is not in error state.The external system can set/clear a charging limit/schedule on the Charging Station via a direct connection to the Charging Station.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>New transactions will be limited by the received charging limit from the external system.The CSMS is informed of the new limit/schedule imposed by the external system.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The external system could, for example, use IEC 61850 [IEC61850-7-420] or OpenADR [OPENADR] to communicate the grid limit to the Charging Station, but this could be any protocol. An example of an external system is given, in this case a smart meter that might set an external charging limit to protect against overloading the local grid connection, but this could be any other external system that sets a charging limit.It is up to the Charging Station implementation to decide whether to represent the external limits for ChargingStationExternalConstraints as an Absolute or Relative charging profile or as a Dynamic charging profile with an operationMode = ExternalLimits.</td></tr></table>
+
+
+Figure 133. Sequence diagram of the use case "Set / Update External Charging Limit Without Ongoing Transaction"
+
+# K12 - Set / Update External Charging Limit Without Ongoing Transaction - Requirements
+
+Table 108. K12 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K12.FR.01</td><td>When an external charging limit/schedule is received while no transactions are ongoing</td><td>The total load of all EVSEs SHALL NOT exceed this given limit.</td><td></td></tr><tr><td>K12.FR.02</td><td>K12.FR.01 AND Charging limit changed by more than: LimitChangeSignificance</td><td>The Charging Station SHALL inform the CSMS of the new charging limit/schedule imposed by the external system by sending a NotifyChargingLimitRequest.</td><td>Same as K11.FR.02</td></tr><tr><td>K12.FR.03</td><td>K12.FR.02 AND EnableNotifyCharging LimitWithSchedules is true</td><td>The NotifyChargingLimitRequest SHALL contain the charging limit/schedule as set by the external system.</td><td>Same as K11.FR.03</td></tr><tr><td>K12.FR.04</td><td>K12.FR.02</td><td>The Charging Station SHALL NOT set the chargingLimitSource to CSO in the NotifyChargingLimitRequest.</td><td>Same as K11.FR.05</td></tr><tr><td>K12.FR.05</td><td>When an external charging limit/schedule is received</td><td>The Charging Station SHALL use purpose ChargingStationExternalConstraints when reporting about this limit (i.e. in a ReportChargingProfilesRequest).</td><td>It is RECOMMENDED to use negative values for the id of a ChargingStationExter nalConstraints profile, to minimize the risk of a clash with an id that CSMS might use for a (future) charging profile.See use case K29 for the use of Dynamic charging profiles and external limits. Same as K11.FR.06.</td></tr></table>
+
+# K13 - Reset / Release External Charging Limit
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Reset / Release External Charging Limit</td></tr><tr><td>2</td><td>ID</td><td>K13</td></tr><tr><td>3</td><td>Objective(s)</td><td>To release a charging limit that was previously imposed.</td></tr><tr><td>4</td><td>Description</td><td>An external control system sends a signal to release a previously imposed charging limit to a Charging Station. The Charging Station notifies the CSMS about this.</td></tr><tr><td></td><td>Actors</td><td>External control system, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. External control system releases/remove a charging limit/schedule on the Charging Station
+2. When a transaction is ongoing, the Charging Station calculates the new Charging Schedule and adjusts charging speed.
+3. The Charging Station sends a ClearedChargingLimitRequest to notify the CSMS.
+4. The CSMS acknowledges with a ClearedChargingLimitResponse to the Charging Station.
+5. When the change has impact on an ongoing charging transaction and is more than: LimitChangeSignificance, the Charging Station sends a TransactionEventRequest to notify the CSMS.
+6. The CSMS acknowledges with a TransactionEventResponse to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Previously, a charging limit was sent to the Charging Station under consideration.
+An external system that can set/clear a charging limit/schedule on the Charging Station via another connection than OCPP.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The previously received charging limit is not limiting charging anymore.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The external system could, for example, IEC 61850 [IEC61850-7-420] or OpenADR [OPENADR] to release the grid limit, but this could be any protocol. Furthermore, an example of an external system is given, in this case a DSO that might set an external charging limit in case of grid problems, but this could be any other external system or reason to set a charging limit.</td></tr></table>
+
+
+Figure 134. Sequence diagram of the use case "Release / Reset External Charging Limit"
+
+# K13 - Reset / Release External Charging Limit - Requirements
+
+Table 109. K13 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td></tr><tr><td>K13.FR.01</td><td>External charging limit is released/removed</td><td>The Charging Station SHALL NOT limit charging anymore based on the previously received limit.</td></tr><tr><td>K13.FR.02</td><td>K13.FR.01</td><td>The Charging Station SHALL notify the CSMS by sending a ClearedChargingLimitRequest message.</td></tr><tr><td>K13.FR.03</td><td>K13.FR.01 AND A transaction is ongoing AND Charging rate changed by more than: LimitChangeSignificance</td><td>The Charging Station SHALL send a TransactionEventRequest message to the CSMS with trigger = ChargingRateChanged.</td></tr></table>
+
+# K14 - External Charging Limit with Local Controller
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Handle external charging limit with a local controller</td></tr><tr><td>2</td><td>ID</td><td>K14</td></tr><tr><td>3</td><td>Objective(s)</td><td>To adjust the charging limits according to the External Control System requirements.</td></tr><tr><td>4</td><td>Description</td><td>An external control system sends a charging limit to the Local Controller. The Local Controller notifies the CSMS, calculates the new charging schedules and sends a SetChargingProfileRequest messages to all Charging Stations for which the charging profile has changed.</td></tr><tr><td></td><td>Actors</td><td>External control system, Local Controller, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. External control system sends a charging limit/schedule to Local Controller.
+2. Local Controller sends a NotifyChargingLimitRequest message to the CSMS.
+3. Local Controller calculates new Charging Profiles for all connected Charging Stations.
+4. Local Controller sends a SetChargingProfileRequest message to all Charging Stations for which the charging profile has changed.
+5. External control releases a charging limit/schedule to Local Controller.
+6. Local Controller sends a ClearedChargingLimitRequest message to the CSMS.
+7. Local Controller clears Charging Profiles for all connected Charging Stations.
+8. Local Controller sends a ClearChargingProfileRequest messages to all affected Charging Stations.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Ongoing transaction(s).
+An external system that can set/clear a charging limit/schedule on Local Controller via another connection than OCPP.
+Configuration variable ExternalControlSignalsEnabled = true.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The ongoing transactions will be limited by the received charging limit from the external system.
+The CSMS is informed of the new limit/schedule imposed by the external system.
+Failure postcondition:
+The CSMS is not informed about the changed charging limit.
+The External Control System is not able to change the charging limit.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 135. Sequence Diagram: External Charging Limit with Local Controller.
+
+# K14 - External Charging Limit with Local Controller - Requirements
+
+Table 110. K14 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>K14.FR.01</td><td>When an external charging limit/schedule is received</td><td>The total load of all Charging Stations SHALL NOT exceed this given limit.</td></tr><tr><td>K14.FR.02</td><td>K14.FR.01 AND Charging limit changed by more than: LimitChangeSignificance</td><td>The Local Controller SHALL inform the CSMS of the new charging limit/schedule imposed by the external system by sending a NotifyChargingLimitRequest.</td></tr><tr><td>K14.FR.03</td><td>When an external charging limit/schedule is released</td><td>The local controller SHALL notify the CSMS by sending a ClearedChargingLimitRequest.</td></tr><tr><td>K14.FR.04</td><td>K14.FR.03</td><td>The local controller SHALL clear the hard limit on Charging Stations by sending a ClearChargingProfileRequest message to the Charging Stations.</td></tr><tr><td>K14.FR.05</td><td>When the Local Controller receives an external charging limit/schedule</td><td>It SHALL send a SetChargingProfileRequest to all Charging Stations for which the charging profile has changed.</td></tr><tr><td>K14.FR.06</td><td>K14.FR.05</td><td>The Local Controller SHALL NOT set chargingProfilePurpose to ChargingStationExternalConstraints.</td></tr></table>
+
+# K23 - Smart Charging with EMS connected to Charging Stations
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Smart Charging with EMS connected to Charging Stations</td></tr><tr><td>2</td><td>ID</td><td>K23 (see also K11, K12)</td></tr><tr><td>3</td><td>Objective(s)</td><td>To describe how smart charging can be performed by an EMS that has a direct connection to a Charging Station.The setting of the charging limits is described in detail in use cases K11 and K12 for any External Control System. This use case describes the specific situation where the External Control System is an EMS in a building.</td></tr><tr><td>4</td><td>Description</td><td>EMS is managing the load within a site. It regularly updates current or power limitations for the Charging Stations based on other loads within the site, such that the local grid connection is not overloaded.</td></tr><tr><td></td><td></td><td>Site
+DSO
+Grid_connection
+EMS
+control
+Charging Station 1
+Charging Station 2
+NotifyChargingLimit
+NotifyChargingLimit
+CSMS</td></tr><tr><td></td><td>Actors</td><td>EMS, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. EMS measures power consumption from other loads in the building
+2. EMS determines available power for Charging Stations based on the capacity of the local grid connection, other loads and the amount of locally generated energy (e.g. PV panels)
+3. EMS sets power (or current) limit to Charging Stations via a direct connection. (The protocol between EMS and Charging Station is not relevant for the use case).
+4. Charging Station internally represents the given limitation as a charging profile with chargingProfilePurpose = ChargingStationExternalConstraints. (Depending on EMS this can be a single limit value or a schedule of limits over time).
+5. Charging Station notifies CSMS of the received limit if it changed by more than the configured threshold: LimitChangeSignificance, by sending a NotifyChargingLimitRequest message with chargingLimitSource = EMS and (optionally) a chargingSchedule that represents the limit(s).
+6. If a transaction is ongoing, Charging Station will send a TransactionEventRequest message with trigger = ChargingRateChanged to record that a power limitation occurred during the transaction.</td></tr><tr><td>5</td><td>Prerequisites</td><td>EMS is able to control power level of Charging Stations.
+Configuration variable ExternalControlSignalsEnabled = true.</td></tr><tr><td>6</td><td>Post conditions</td><td>Charging power is reduced when needed to avoid overloading local grid connection.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>If the other loads in the building consume less than the amount of locally generated energy, then EMS might be able to let the Charging Stations use this as additional capacity on top of the capacity of the local grid connection. This situation is described in K27 - Smart Charging with EMS and LocalGeneration.</td></tr></table>
+
+
+
+# K23 - Smart Charging with EMS connected to Charging Stations - Requirements
+
+The requirements for this use case are already covered in use cases K11 and K12.
+
+# K24 - Smart Charging with EMS connected to Local Controller
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Smart Charging with EMS connected to Local Controller</td></tr><tr><td>2</td><td>ID</td><td>K24 (see also K14)</td></tr><tr><td>3</td><td>Objective(s)</td><td>To describe how smart charging can be performed by an EMS that is connected to a Local Controller that manages Charging Stations in the building.
+The setting of the charging limits to a Local Controller is described in detail in use case K14 for any External Control System. This use case describes the specific situation where the External Control System is an EMS in a building.</td></tr><tr><td>4</td><td>Description</td><td>EMS is managing the load within a site. It regularly updates a current or power limitation for the cluster of Charging Stations that is managed by a Local Controller, such that the local grid connection is not overloaded.</td></tr><tr><td></td><td></td><td>Site
+Grid_connection
+EMS
+ExternalConstraints,
+LocalGeneration
+MaxProfile 1,
+LocalGeneration 1,
+TxProfile 1
+Charging Station 1
+Charging Station 2
+CSMS
+TS
+DSO
+MaxProfile 2,
+LocalGeneration
+TxProfile 2
+MaxProfile 2,
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS
+MaxProfile 2
+TS</td></tr><tr><td></td><td>Actors</td><td>EMS, Local Controller, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. EMS measures power consumption from other loads in the building
+2. EMS determines available power for EV charging based on the capacity of the local grid connection, other loads and the amount of locally generated energy (e.g. PV panels)
+3. EMS sets power (or current) limit to the Local Controller via a direct connection. (The protocol between EMS and Local Controller is not relevant for the use case).
+4. Local Controller internally represents the given limitation as charging profile with chargingProfilePurpose = ChargingStationExternalConstraints. (Depending on EMS this can be a single limit value or a schedule of limits over time).
+5. Local Controller notifies CSMS of the received limit if it changed by more than the configured threshold: LimitChangeSignificance, by sending a NotifyChargingLimitRequest message with chargingLimitSource = EMS and (optionally) a chargingSchedule that represents the limit(s).
+6. Local Controller balances the available current or power across all connected Charging Stations by sending each Charging Station an (updated) charging profile via a SetChargingProfileRequest message with chargingProfilePurpose = ChargingStationMaxProfile.
+7. If a transaction is ongoing, and the received charging profile limits have changed more than LimitChangeSignificance, Charging Station will send a TransactionEventRequest message with trigger = ChargingRateChanged to record that a power limitation occurred during the transaction.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Local Controller is able to load-balance across Charging Stations at site.</td></tr><tr><td>6</td><td>Post conditions</td><td>Charging power is reduced when needed to avoid overloading local grid connection.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>A Local Controller acts as a local CSMS for the site. The chargingProfilePurpose must therefore not be ChargingStationExternalConstraints, because the Local Controller is not seen as an External Control System.
+A NotifyChargingLimitRequest is only sent by the Local Controller (not by the individual Charging Stations), since that is the component that receives the external charging limit.</td></tr></table>
+
+
+
+# K24 - Smart Charging with EMS connected to Local Controller - Requirements
+
+The requirements for this use case are already covered in use case K14.
+
+# K25 - Smart Charging with EMS acting as a Local Controller
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Smart Charging with EMS acting as a Local Controller</td></tr><tr><td>2</td><td>ID</td><td>K25 (see also K14)</td></tr><tr><td>3</td><td>Objective(s)</td><td>To describe how smart charging can be performed by an EMS that is acting as a Local Controller that manages Charging Stations in the building.
+The setting of the charging limits to a Local Controller is described in detail in use case K14 for any External Control System. This use case describes the specific situation where the functionality of EMS and Local Controller are combined in a single component.</td></tr><tr><td>4</td><td>Description</td><td>EMS is managing the load within a site and also acting as a Local Controller for Charging Stations. It controls charging profiles for the Charging Stations on site, such that the local grid connection is not overloaded.
+More advanced scheduling is possible, since this component is a Local Controller and all OCPP traffic passes through it, which allows the EMS-part of this component to be aware of the state of ongoing transactions, such as charging schedules imposed by CSMS, state of charge of the EV, and planned time of departure.</td></tr><tr><td></td><td>Actors</td><td>EMS, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. EMS measures power consumption from other loads in the building.
+2. EMS optionally collects data from OCPP traffic about ongoing transactions, state of charge and planned time of departure, when available.
+3. EMS calculates a power profile for each Charging Station based on the state of charging transactions, other loads, the capacity of the local grid connection and the amount of locally generated energy (e.g. PV panels)
+4. EMS (as Local Controller) sends each power profile as a charging profile of chargingProfilePurpose = ChargingStationMaxProfile to the Charging Stations, in addition to charging profiles (if any) from CSMS towards Charging Stations.
+5. EMS (as Local Controller) notifies CSMS of a power limit if it changed by more than the configured threshold: LimitChangeSignificance, by sending a NotifyChargingLimitRequest message with chargingLimitSource = EMS and (optionally) a chargingSchedule that represents the limit(s).
+6. If a transaction is ongoing, and the received charging profile limits have changed more than LimitChangeSignificance, Charging Station will send a TransactionEventRequest message with trigger = ChargingRateChanged to record that a power limitation occurred during the transaction.</td></tr><tr><td>5</td><td>Prerequisites</td><td>EMS and Local Controller are integrated and Local Controller part has load-balancing capabilities.</td></tr><tr><td>6</td><td>Post conditions</td><td>Charging power is reduced when needed to avoid overloading local grid connection.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>A Local Controller acts as a local CSMS for the site. The chargingProfilePurpose must therefore not be ChargingStationExternalConstraints, because the Local Controller is not seen as an External Control System.
+A NotifyChargingLimitRequest is only sent by the Local Controller (not by the individual Charging Stations), since that is the component that receives the external charging limit.</td></tr></table>
+
+
+
+# K25 - Smart Charging with EMS acting as a Local Controller - Requirements
+
+The requirements for this use case are already covered in use case K14.
+
+# K26 - Smart Charging with Hybrid Local & Cloud EMS
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Smart Charging with Hybrid Local & Cloud EMS</td></tr><tr><td>2</td><td>ID</td><td>K26 (see also K14)</td></tr><tr><td>3</td><td>Objective(s)</td><td>To describe how smart charging can be performed by an EMS in the cloud that is acting as a Local Controller that manages Charging Stations in the building.
+This use case is similar to K25. The difference is, that in this case EMS has cloud component and a local component.</td></tr><tr><td>4</td><td>Description</td><td>In this use case EMS exists in both a cloud and a local instance. It has two alternative topologies:
+1. The part running in the cloud is responsible for scheduling and Local Controller functionality, and the other part running locally on site measures local loads and acts as a fail-safe protection against overloading the local grid connection.
+2. The part running in the cloud is only responsible for scheduling, and the other part running locally on site acts as a Local Controller and measures local loads and acts as a fail-safe protection against overloading the local grid connection.</td></tr><tr><td></td><td>Actors</td><td>Cloud EMS, Local EMS, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>Cloud EMS as Local Controller
+EMS in the cloud can easily connect to external sources of information, such as weather forecasts and inputs from a DSO or TSO. Since this component is also a Local Controller and all OCPP traffic passes through it, this allows the EMS-part of this component to be aware of the state of ongoing transactions, such as charging schedules imposed by CSMS, state of charge of the EV, and planned time of departure. Together with information of external sources, this enables advanced scheduling.</td></tr><tr><td></td><td></td><td>Aggregator
+Site
+DSO
+CSMS
+Local PV Generation
+Other loads
+Grid_connection
+Cloud EMS as Local Controller
+Charging Station 1
+Charging Station 2</td></tr><tr><td></td><td></td><td>1. Local EMS measures power consumption from other loads in the building, and passes this on to Cloud EMS.
+2. Cloud EMS collects data from external inputs, like weather forecasts and DSO/TSO input.
+3. Cloud EMS (as Local Controller) optionally collects data from OCPP traffic about ongoing transactions, state of charge and planned time of departure, when available.
+4. Cloud EMS calculates a power profile for each Charging Station based on the state of charging transactions and information received from Local EMS, such as local loads, capacity of the local grid connection and the amount of locally generated energy (e.g. PV panels)
+5. Cloud EMS (as Local Controller) sends each power profile as a charging profile of chargingProfilePurpose = ChargingStationMaxProfile to the Charging Stations, in addition to charging profiles (if any) from CSMS towards Charging Stations.
+6. Cloud EMS (as Local Controller) notifies CSMS of a power limit if it changed by more than the configured threshold: LimitChangeSignificance, by sending a NotifyChargingLimitRequest message with chargingLimitSource = EMS and (optionally) a chargingSchedule that represents the limit(s).
+7. If a transaction is ongoing, and the received charging profile limits have changed more than LimitChangeSignificance, Charging Station will send a TransactionEventRequest message with trigger = ChargingRateChanged to record that a power limitation occurred during the transaction.</td></tr><tr><td></td><td>Scenario description #2</td><td>Local EMS as Local Controller
+The Local EMS acts as a Local Controller and all OCPP traffic passes through it. As such, it is aware of the state of ongoing transactions, such as charging schedules imposed by CSMS, state of charge of the EV, and planned time of departure.
+EMS in the cloud can easily connect to external sources of information, such as weather forecasts and inputs from a DSO or TSO, but since it is not acting as a Local Controller, it will not be aware of the state on ongoing transactions, unless this information is passed on between Local EMS and Cloud EMS.</td></tr><tr><td></td><td></td><td>Site
+Aggregator
+CSMS
+DSO
+Cloud EMS as Scheduler
+Charging Station 1
+Charging Station 2</td></tr><tr><td></td><td></td><td>1. Local EMS measures power consumption from other loads in the building, and passes this on to Cloud EMS.
+2. Local EMS (as Local Controller) optionally collects data from OCPP traffic about ongoing transactions, state of charge and planned time of departure, when available, but since scheduling takes place in the Cloud EMS, this information cannot be taking into account, unless it Local EMS sends it to Cloud EMS.
+3. Cloud EMS collects data from external inputs, like weather forecasts and DSO/TSO input.
+4. Cloud EMS calculates a power profile for each Charging Station based on information received from Local EMS, such as local loads, capacity of the local grid connection and the amount of locally generated energy (e.g. PV panels) and optionally information about ongoing transactions.
+5. Cloud EMS sends power profiles to Local EMS.
+6. Local EMS (as Local Controller) sends each power profile as a charging profile of chargingProfilePurpose = ChargingStationMaxProfile to the Charging Stations, in addition to charging profiles (if any) from CSMS towards Charging Stations.
+7. Local EMS (as Local Controller) notifies CSMS of a power limit if it changed by more than the configured threshold: LimitChangeSignificance, by sending a NotifyChargingLimitRequest message with chargingLimitSource = EMS and (optionally) a chargingSchedule that represents the limit(s).
+8. If a transaction is ongoing, and the received charging profile limits have changed more than LimitChangeSignificance, Charging Station will send a TransactionEventRequest message with trigger = ChargingRateChanged to record that a power limitation occurred during the transaction.</td></tr><tr><td>5</td><td>Prerequisites</td><td>EMS and Local Controller are integrated and Local Controller part has load-balancing capability.</td></tr><tr><td>6</td><td>Post conditions</td><td>Charging power is reduced when needed to avoid overloading local grid connection.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>Although the Local Controller functionality of EMS can either run in the cloud or locally, it is often more convenient to run it in the cloud, because a cloud instance has more processing power, can more easily be connected to a cloud CSMS and Charging Stations, and the interface between Cloud EMS and Local EMS is simpler, because no transaction data needs to be exchanged.</td></tr></table>
+
+# K26 - Smart Charging with Hybrid Local & Cloud EMS - Requirements
+
+The requirements for this use case are already covered in use case K14.
+
+# K27 - Smart Charging with EMS and LocalGeneration
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Smart Charging with EMS and LocalGeneration</td></tr><tr><td>2</td><td>ID</td><td>K27</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show how locally available capacity can be taken into account.</td></tr><tr><td>4</td><td>Description</td><td>In the situation where more power is available for the Charging Station due to the local power generation which is not known by CSMS, e.g. from solar panels, this extra capacity can be specified in a charging profile of type LocalGeneration. In this use case 2 kW is available from local solar panels on top of a 5 kW TxDefaultProfile.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, EMS</td></tr><tr><td></td><td>Scenario description</td><td>Using a predicted local generation schedule
+1. Assume CSMS has set a ChargingProfile with chargingProfilePurpose = TxDefaultProfile, chargingProfileKind = Relative and a chargingSchedule with chargingRateUnit = w and 1 chargingSchedulePeriod that defines a limit = 5000.
+2. An external energy management system provides a schedule for the local generation by means of a protocol. The schedule contains two periods: first period for 2 kW, second period for 1 kW. (Duration of the periods is required, but not relevant to this example.) Charging Station represents this input internally as a ChargingProfile with chargingProfilePurpose = LocalGeneration, chargingProfileKind = Absolute and a chargingSchedule with chargingRateUnit = w and 2 chargingSchedulePeriods that define a limit = 2000 and a limit = 1000.
+3. First period:
+a. If the charging limit changed by more than: LimitChangeSignificance, the Charging Station sends a NotifyChargingLimitRequest message to CSMS with a chargingLimit that has chargingLimitSource = EMS and isLocalGeneration = true, and the local generation charging schedule from that moment onwards.
+b. Charging Station internally calculates a composite schedule that allows for a maximum power consumption of 7000 W.
+4. Second period, the local generation drops to 1 kW:
+a. If the charging limit changed by more than: LimitChangeSignificance, the Charging Station sends a NotifyChargingLimitRequest message to CSMS with a chargingLimit that has chargingLimitSource = EMS and isLocalGeneration = true, and the local generation charging schedule from that moment onwards.
+b. Charging Station internally calculates a composite schedule that allows for a maximum power consumption of 6000 W.</td></tr><tr><td></td><td>Scenario description #2</td><td>Using Dynamic charging schedule
+1. Assume CSMS has set a ChargingProfile with chargingProfilePurpose = TxDefaultProfile, chargingProfileKind = Relative and a chargingSchedule with chargingRateUnit = w and 1 chargingSchedulePeriod that defines a limit = 5000.
+2. An external energy management system provides a (dynamic) value for the local generation by means of a protocol. Charging Station represents this input internally as a ChargingProfile with chargingProfilePurpose = LocalGeneration, chargingProfileKind = Dynamic and a chargingSchedule with chargingRateUnit = w and 1 chargingSchedulePeriod with operationMode = ExternalLimits.
+3. The value for limit in the LocalGeneration charging profile is continuously updated with the value from the external system.
+a. If the charging limit changed by more than: LimitChangeSignificance, the Charging Station sends a NotifyChargingLimitRequest message to CSMS with a chargingLimit that has chargingLimitSource = EMS and isLocalGeneration = true, and the local generation charging schedule from that moment onwards.
+b. Charging Station internally calculates a composite schedule that allows for a maximum power consumption of 5000 W (from TxDefaultProfile) plus limit from LocalGeneration.</td></tr><tr><td>5</td><td>Prerequisites</td><td>EMS is able to measure (and possibly predict) the amount of local generation, and send it to Charging Station in a way that it can recognize it as local generation.
+Configuration variable ExternalControlSignalsEnabled = true.</td></tr><tr><td>6</td><td>Post conditions</td><td>Charging Station can use available energy from local generation in addition to the local grid capacity.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>If the external system provides a limit via a protocol that is not OCPP, e.g. ModBus, then Charging Station can represent this as an Absolute charging profile, that is replaced when the limit changes, or as a Dynamic charging profile with a single charging schedule period with operationMode = ExternalLimits in which the limit is dynamically updated.
+It is up to the Charging Station implementation to decide whether to represent the external limits for LocalGeneration as an Absolute or as a Dynamic charging profile with an operationMode = ExternalLimits.</td></tr></table>
+
+
+Figure 136. Using LocalGeneration
+
+# K27 - Smart Charging with EMS and LocalGeneration - Requirements
+
+Table 111. K27 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K27.FR.01</td><td>When an external charging limit/schedule is received that represents locally generated capacity</td><td>Charging Station SHALL treat this internally as a charging profile with chargingProfilePurpose = LocalGeneration</td><td>External limits can be a single value or a schedule.</td></tr><tr><td>K27.FR.02</td><td>K27.FR.01 AND
+Charging Station receives a
+GetChargingProfilesRequest
+from CSMS</td><td>Charging Station SHALL include the charging
+profile with chargingProfilePurpose =
+LocalGeneration in the reported charging
+profiles (if it exists).</td><td></td></tr><tr><td>K27.FR.03</td><td>When the charging limit has
+changed by more than:
+LimitChangeSignificance
+and this is caused by a charging
+profile with
+chargingProfilePurpose =
+LocalGeneration</td><td>Charging Station SHALL send a
+NotifyChargingLimitRequest message to CSMS
+with a chargingLimit that has chargingLimitSource =
+EMS or Other and isLocalGeneration = true.</td><td>Limit can change every
+charging schedule period, or
+can be changed dynamically in
+a Dynamic charging profile.</td></tr><tr><td>K27.FR.04</td><td>K27.FR.03 AND
+NotifyChargingLimitWith
+Schedules is true</td><td>The NotifyChargingLimitRequest SHALL contain
+the charging limits/schedules as set by the external
+system.</td><td></td></tr><tr><td>K27.FR.05</td><td>K27.FR.03 AND
+When Charging Station receives
+charging profiles from external
+system(s) that have a
+chargingProfilePurpose =
+LocalGeneration as well as
+a chargingProfilePurpose =
+ChargingStation-
+ExternalConstraints</td><td>Charging Station SHALL send the
+chargingSchedules for the charging profiles with
+chargingProfilePurpose = LocalGeneration
+together in a NotifyChargingLimitRequest message
+with isLocalGeneration = true AND
+Charging Station SHALL send the
+chargingSchedules for the charging profiles with
+chargingProfilePurpose = ChargingStation-
+ExternalConstraints together in a
+NotifyChargingLimitRequest message with
+isLocalGeneration = false or absent.</td><td>This is needed, because CSMS
+cannot deduce from the
+charging schedule that a
+schedule represents local
+generation or a limit.</td></tr></table>
+
+# 5.3. ISO 15118 based Smart Charging
+
+# K15 - ISO 15118-2 Charging with load leveling
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>ISO 15118-2 Charging with load leveling</td></tr><tr><td>2</td><td>ID</td><td>K15</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 E1 AC Charging with load leveling based on High Level Communication, and E4 DC charging with load leveling based on High Level Communication.</td></tr><tr><td>3</td><td>Objective(s)</td><td>See ISO15118-1, use case Objective E1, page 29.</td></tr><tr><td>4</td><td>Description</td><td>See ISO15118-1, use case Description E1, page 29.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS.</td></tr><tr><td></td><td>Combined scenario description</td><td>1. The EV sends a ChargeParameterDiscoveryReq message to the Charging Station.
+2. The Charging Station sends a NotifyEVChargingNeedsRequest message to the CSMS.
+3. The CSMS sends a NotifyEVChargingNeedsResponse message to the Charging Station.
+4. The CSMS sends a SetChargingProfileRequest message to the Charging Station.
+5. The Charging Station sends a SetChargingProfileResponse message to the CSMS.
+6. The Charging Station responds to the EV with a ChargeParameterDiscoveryRes message to the EV.
+7. The EV sends a PowerDeliveryReq message to the Charging Station with ChargeProgress=Start. This marks the point in time when the EVSE provides voltage to its output power outlet and the EV can start to recharge its battery.
+8. The contactor is closed.
+9. The transaction is updated with a TransactionEventRequest message.
+10. A PowerdeliveryRes message is sent to the EV.
+11. Optionally, the Charging Station sends a NotifyEVChargingScheduleRequest message to the CSMS.</td></tr><tr><td>5</td><td>Prerequisites</td><td>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.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>See ISO15118-1, use case End conditions E1, page 29.</td></tr><tr><td>7</td><td>Error handling</td><td>The Charging Station needs to use the information from the SetChargingProfileRequest message to create the response to the ISO 15118 ChargeParameterDiscoveryReq towards the EV. This message has a timeout of 60 seconds, which means the SetChargingProfileRequest has to be sent well within 60 seconds after receiving the NotifyEVChargingNeedsRequest. If the Charging Station does not receive the SetChargingProfileRequest in time or when the NotifyEVChargingNeedsResponse has status = Processing, then the Charging Station will return a schedule in ChargeParameterDiscoverRes that matches the capabilities of the EVSE. When CSMS sends the SetChargingProfileRequest at a later time, then this will trigger a renegotiation according to use case K16 - Renegotiation initiated by CSMS.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Signed SalesTariffs are supported in OCPP 2.1 via the signatureValue field in ChargingProfileType.
+Charging with ISO 15118-20 is described in use cases K18 - ISO 15118-20 Scheduled Control Mode and K19 - ISO 15118-20 Dynamic Control Mode.
+NOTE: For an ISO 15118-2 session CSMS is not recommended to send a charging profile with chargingProfileKind = Dynamic for which it intends to send frequent updates, because every update of the limit in the charging schedule period will trigger a renegotiation with EV for a new schedule.</td></tr></table>
+
+
+Figure 137. Sequence Diagram: Charging with load leveling based on High Level Communication
+
+# K15 - ISO 15118-2 Charging with load leveling - Requirements
+
+Table 112. K15 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K15.FR.01</td><td>When the Charging Station receives charging needs from the EV</td><td>The Charging Station SHALL send a NotifyEVChargingNeedsRequest to the CSMS.</td><td>See also K15.FR.20</td></tr><tr><td>K15.FR.02</td><td>K15.FR.01</td><td>In response to a NotifyEVChargingNeedsRequest the CSMS SHALL send a NotifyEVChargingNeedsResponse.</td><td></td></tr><tr><td>K15.FR.03</td><td>K15.FR.02</td><td>If the CSMS is able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to Accepted.</td><td></td></tr><tr><td>K15.FR.04</td><td>K15.FR.02</td><td>If the CSMS is not going to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to Rejected.</td><td>Charging Station will use a TxDefaultProfile or provide a schedule with unlimited power.</td></tr><tr><td>K15.FR.05</td><td>K15.FR.02</td><td>If the CSMS is able to provide a charging schedule; but needs processing time, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to Processing.</td><td>The Charging Station does not have to wait for the SetChargingProfileRequest. CSMS will send it later and trigger a renegotiation as per use case K16.</td></tr><tr><td>K15.FR.06</td><td></td><td>A NotifyEVChargingNeedsRequest SHALL contain either ACChargingParameters or DCChargingParameters.</td><td></td></tr><tr><td>K15.FR.07</td><td>K15.FR.03 or K15.FR.05</td><td>The CSMS SHALL send a SetChargingProfileRequest with chargingProfilePurpose = TxProfile and a transactionId and at most three chargingSchedule and optional salesTariff elements, that each contain no more periods than specified by maxScheduleTuples in NotifyEVChargingNeedsRequest and by device model variable SmartChargingCtrl.PeriodsPerSched ule.</td><td>The Charging Station will calculate the composite schedule(s) for the EVSE (taking into account a ChargingStationMaxProfile or ChargingStationExternalConstraints if present) and will convert that to the SAScheduleList format for ISO 15118.</td></tr><tr><td>K15.FR.08</td><td>K15.FR.01</td><td>The CSMS SHOULD send a SetChargingProfileRequest to the Charging Station within 60 seconds.</td><td>This is to satisfy the ISO 15118 ChargeParameterDiscoveryReq timeout.</td></tr><tr><td>K15.FR.09</td><td>K15.FR.07 AND EV returns a charging profile</td><td>Charging Station SHALL verify that provided charging profile is within boundaries of the ChargingSchedule from CSMS.</td><td>In ISO 15118 EV can sent its charging profile as part of PowerDeliveryReq.</td></tr><tr><td>K15.FR.10</td><td>K15.FR.09</td><td>Charging Station SHALL send the EV charging profile in a NotifyEVChargingScheduleRequest message to CSMS.</td><td></td></tr><tr><td>K15.FR.11</td><td>K15.FR.10 AND EV charging profile is within limits of CSMS ChargingSchedule</td><td>CSMS responds with NotifyEVChargingScheduleResponse with status Accepted to Charging Station.</td><td>Note: Already checked by Charging Station, but CSMS does its own check.</td></tr><tr><td>K15.FR.12</td><td>K15.FR.10 AND EV charging profile is NOT within limits of CSMS ChargingSchedule</td><td>CSMS responds with NotifyEVChargingScheduleResponse with status Rejected to Charging Station.</td><td></td></tr><tr><td>K15.FR.13</td><td>K15.FR.12</td><td>CSMS starts new renegotiation as per use case K16.</td><td></td></tr><tr><td>K15.FR.14</td><td>K15.FR.11</td><td>The Charging Station SHOULD take the schedule from the NotifyEVChargingScheduleRequest into account when calculating the actual Composite schedule.</td><td></td></tr><tr><td>K15.FR.15</td><td>K15.FR.01 AND Charging Station is offline</td><td>The Charging Station SHALL use the TxDefaultProfile (if present) and generate a charging schedule within the limits of its composite schedule.</td><td></td></tr><tr><td>K15.FR.16</td><td>K15.FR.07</td><td>It is RECOMMENDED to configure the Charging Station, such that a TransactionEvent with idToken has been sent prior to the NotifyEVChargingNeedsRequest Message, so that CSMS can take the user into account when creating a charging schedule.</td><td></td></tr><tr><td>K15.FR.17</td><td>When Charging Station receives a SetChargingProfileRequest immediately after the transaction has started and before it has sent the NotifyEVChargingNeed sRequest to CSMS</td><td>The Charging Station SHOULD respond with SetChargingProfileResponse with status = Rejected and a statusInfo withreasonCode=InvalidMessageSeq.</td><td>CSMS sent profile too early. It does not harm if CS accepts the charging profile instead of rejecting it, as long as it sends a charging profile again when it receives the NotifyEVChargingNeedsRequest.</td></tr><tr><td>K15.FR.18</td><td>K15.FR.03 OR K15.FR.05</td><td>CSMS IS RECOMMENDED to use only one chargingSchedule in a SetChargingProfileRequest.</td><td>This ensures that there is no doubt about which schedule the EV will follow, even when no NotifyEVChargingScheduleRequest is received.</td></tr><tr><td>K15.FR.19</td><td>K15.FR.07 AND EV does not return a charging profile</td><td>Charging Station IS RECOMMENDED to return an EV charging profile as a chargingSchedule in a NotifyEVChargingScheduleRequest message to CSMS that matches the charging schedule that was selected by the EV (i.e. the OCPP charging schedule that is represented by the SAScheduleTupled that EV sent in the PowerDeliveryReq.)</td><td>In ISO 15118-2 the EV charging profile and the selected schedule are returned as ChargingProfile and SAScheduleTupled in PowerDeliveryReq. See also K15.FR.21.</td></tr><tr><td>K15.FR.20</td><td>K15.FR.01 AND Charging Station is offline</td><td>Charging Station SHOULD add timestamp to the NotifyEVChargingNeedsRequest with the time when charging needs were received from EV</td><td>This will tell CSMS how old this data is, if it was not immediately sent because of an offline period.</td></tr><tr><td>K15.FR.21 (2.1)</td><td>K15.FR.10</td><td>Charging Station SHOULD set selectedChargingScheduleId in NotifyEVChargingScheduleRequest to the Id of the chargingSchedule that EV selected from the provided ChargingProfileType(s).</td><td></td></tr></table>
+
+# K16 - Renegotiation initiated by CSMS
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Renegotiation initiated by CSMS.</td></tr><tr><td>2</td><td>ID</td><td>K16</td></tr><tr><td>3</td><td>Objective(s)</td><td>To control the charging power or current of a Charging Station</td></tr><tr><td>4</td><td>Description</td><td>The CSMS sends a SetChargingProfileRequest to the Charging Station to influence the power or current drawn by the EV. The CSMS calculates a ChargingSchedule to stay within limits which MAY be imposed by an external system.
+Note: Description of actions between EV and Charging Station is informative only and not mandated by OCPP.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1 CSMS sends a SetChargingProfileRequest to the Charging Station.
+2 Charging Station responds with a SetChargingProfileResponse to the CSMS.
+3 When EV sends the next CurrentDemandReq (for DC) or ChargingStatusReq (for AC), the Charging Station will respond with evseNotification = ReNegotiation.
+4 EV sends a PowerDeliveryReq with chargeProgress = ReNegotiate to confirm this.
+5 Charging Station responds with a PowerDeliveryRes.
+6 EV sends a ChargeParameterDiscoveryReq.
+7 Charging Station responds with a ChargeParameterDiscoveryRes with an SAScheduleList that contains the ChargingSchedule data from the SetChargingProfileRequest.
+8 EV sends a PowerDeliveryReq with chargeProgress = Start (with an optional charging profile) to confirm this.
+9 Charging Station responds with PowerDeliveryRes and, if charging was suspended at start of the renegotiation, will resume power delivery.
+10 If EV provided a charging profile in the previous step, then Charging Station will send a NotifyEVChargingScheduleRequest to the CSMS.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging session started according to use case K15.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Charging session uses the new charging profile.</td></tr><tr><td>7</td><td>Remark(s)</td><td>Signed SalesTariffs are supported in OCPP 2.1 via the signatureValue field in ChargingProfileType.
+Charging with ISO 15118-20 is described in use cases K18 - ISO 15118-20 Scheduled Control Mode and K19 - ISO 15118-20 Dynamic Control Mode.</td></tr></table>
+
+
+Figure 138. Renegotiation initiated by CSMS when using ISO 15118-2
+
+
+Figure 139. Renegotiation initiated by CSMS when using ISO 15118-20
+
+# K16 - Renegotiation initiated by CSMS - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>NOTE</td></tr><tr><td>K16.FR.01</td><td>CSMS sends a new SetChargingProfileRequest</td><td>Charging Station SHALL respond with a SetChargingProfileResponse with status = Accepted.</td><td></td></tr><tr><td>K16.FR.02 (2.1)</td><td>K16.FR.01</td><td>Charging Station SHALL initiate schedule renegotiation with EV.</td><td>In ISO 15118-2 this is done by replying with EVSENotification=ReNegotiation to a CurrentDemandReq (for DC) or ChargingStatusReq (for AC) message. In ISO 15118-20 this is done by replying with EVSENotification=ScheduleRenegotiation in ChargeLoopRes.</td></tr><tr><td>K16.FR.03</td><td>K16.FR.02</td><td>Charging Station SHALL provide the ChargingSchedule data to the EV.</td><td>In ISO 15118 this is done in the ChargeParameterDiscoverRes message.</td></tr><tr><td>K16.FR.04 (2.1)</td><td>EV returns a charging profile AND EV is not using dynamic control mode</td><td>Charging Station SHALL verify that provided charging profile is within boundaries of the ChargingSchedule from CSMS.</td><td>In ISO 15118 EV may provide this as part of the PowerDeliveryReq message.</td></tr><tr><td>K16.FR.05 (2.1)</td><td>K16.FR.04</td><td>Charging Station SHALL send the EV charging profile in a NotifyEVChargingScheduleRequest message to CSMS.</td><td></td></tr><tr><td>K16.FR.06</td><td>K16.FR.05ANDEV charging profile is within limits of CSMSChargingSchedule</td><td>CSMS responds withNotifyEVChargingScheduleResponse withstatus Accepted to Charging Station.</td><td>Note: Already checked by Charging Station, but CSMS does its own check.</td></tr><tr><td>K16.FR.07</td><td>K16.FR.05ANDEV charging profile is NOT within limits ofCSMSChargingSchedule</td><td>CSMS responds withNotifyEVChargingScheduleResponse withstatus Rejected to Charging Station.</td><td></td></tr><tr><td>K16.FR.08</td><td>K16.FR.07</td><td>CSMS starts new renegotiation as per use case K16.</td><td></td></tr><tr><td>K16.FR.09</td><td>When the Charging Station receives charging needs from the EV</td><td>The Charging Station SHOULD NOT send a NotifyEVChargingNeedsRequest to the CSMS.</td><td>CSMS initiated the renegotiation and has just sent a new charging profile, based on the initial charging needs from EV, energy already consumed by EV and whatever information has caused CSMS to update the charging profile.In ISO 15118 charging needs are sent via ChargeParameterDiscoveryReq.</td></tr><tr><td>K16.FR.10</td><td>K16.FR.04</td><td>The Charging Station SHOULD take the schedule from the NotifyEVChargingScheduleRequest into account when calculating the actual Composite schedule.</td><td></td></tr><tr><td>K16.FR.11(2.1)</td><td>K16.FR.02ANDcurrent or power in new charging schedule is lower than actual current or power</td><td>The Charging Station SHALL request EV to lower current or power to a value matching the new charging schedule at the first possible opportunity.</td><td>In ISO 15118 this can be communicated in CurrentDemandRes (for DC) or ChargingStatusRes (for AC).In ISO 15118-20 this is done with EVTARGETActivePower in AC_ChangeLoopRes (for AC) and EVSEMaximumChargePower in Dynamic/Scheduled_CLResControlModeType(for DC).</td></tr><tr><td>K16.FR.12</td><td>K16.FR.09ANDCharging Station sends a NotifyEVChargingNeedssRequest</td><td>The CSMS SHALL send a SetChargingProfileRequest.</td><td>This situation is not desirable, because charging profile will likely be the same as in K16.FR.01, but this is added for robustness when Charging Station is not adhering to K16.FR.09.</td></tr><tr><td>K16.FR.13(2.1)</td><td>EV does not return a charging profile AND EV is not using dynamic control mode</td><td>Charging Station IS RECOMMENDED to return an EV charging profile as a chargingSchedule in a NotifyEVChargingScheduleRequestmessage to CSMS that matches the schedule that was selected by the EV (i.e. the OCPP charging schedule that is represented by the SelectedScheduleTupled that EV sent in PowerDeliveryReq).</td><td>In ISO 15118-2 the EV charging profile and the selected schedule are returned as ChargingProfile and SAScheduleTupled in PowerDeliveryReq.In ISO 15118-20 the EV charging profile and the selected schedule are returned as EVPowerProfile and SelectedScheduleTupled in PowerDeliveryReq. (See also K16.FR.14).</td></tr><tr><td>K16.FR.14(2.1)</td><td>K16.FR.05</td><td>Charging Station SHOULD set selectedChargingScheduleId in NotifyEVChargingScheduleRequest to the Id of the chargingSchedule that EV selected from the provided ChargingProfileType(s).</td><td></td></tr></table>
+
+# K17 - Renegotiation initiated by EV
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Renegotiation initiated by EV.</td></tr><tr><td>2</td><td>ID</td><td>K16</td></tr><tr><td>3</td><td>Objective(s)</td><td>To let an EV request a new charging schedule.</td></tr><tr><td>4</td><td>Description</td><td>The EV signals the Charging Station that it wants to renegotiate and it provides new charging needs, which the Charging Station sends to the CSMS. Based on this and other parameters, the CSMS calculates a new charging schedule and sends it via SetChargingProfileRequest to Charging Station, which communicates it to the EV.
+Note: Description of actions between EV and Charging Station is informative only and not mandated by OCPP.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1 When EV sends a ChargeParameterDiscoveryReq with with charging needs parameters, then Charging Station sends this information in a NotifyEVChargingNeedsRequest to CSMS.
+2 CSMS responds with NotifyEVChargingNeedsResponse to Charging Station.
+3 CSMS calculates new charging schedule, that tries to accommodate the EV charging needs and still fits within the schedule boundaries imposed by other parameters.
+4 CSMS sends a SetChargingProfileRequest with the new schedule to the Charging Station.
+5 Charging Station responds with SetChargingProfileResponse with status Accepted.
+6 Charging Station sends new charging schedule to EV in a ChargeParameterDiscoveryRes message.
+7 EV sends a PowerDeliveryReq with chargeProgress = Start (with an optional charging profile) to confirm this.
+8 Charging Station responds with PowerDeliveryRes and, if charging was suspended at start of the renegotiation, will resume power delivery.
+9 If EV provided a charging profile in the previous step, then Charging Station will send a NotifyEVChargingScheduleRequest to the CSMS.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging session started according to use case K15.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Charging session uses the new charging profile.</td></tr><tr><td>7</td><td>Remark(s)</td><td>Signed SalesTariffs are supported in OCPP 2.1 via the signatureValue field in ChargingProfileType.
+Charging with ISO 15118-20 is described in use cases K18 - ISO 15118-20 Scheduled Control Mode and K19 - ISO 15118-20 Dynamic Control Mode.</td></tr></table>
+
+
+Figure 140. Renegotiation initiated by EV when using ISO 15118-2
+
+
+Figure 141. Renegotiation initiated by EV when using ISO 15118-20
+
+# K17 - Renegotiation initiated by EV - Requirements
+
+Table 113. K17 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K17.FR.01</td><td>EV triggers a renegotiation and sends new charging needs</td><td>The Charging Station SHALL send a NotifyEVChargingNeedsRequest to the CSMS.</td><td></td></tr><tr><td>K17.FR.02</td><td>K17.FR.01</td><td>In response to a NotifyEVChargingNeedsRequest the CSMS SHALL send a NotifyEVChargingNeedsResponse.</td><td></td></tr><tr><td>K17.FR.03</td><td>K17.FR.02 AND If the CSMS is able to provide a charging schedule now</td><td>CSMS SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Accepted'.</td><td></td></tr><tr><td>K17.FR.04</td><td>K17.FR.02 AND If the CSMS is not able to provide a charging schedule now</td><td>CSMS SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to 'Rejected'.</td><td></td></tr><tr><td>K17.FR.05</td><td>K17.FR.02 ANDIf the CSMS is able toprovide a chargingschedule, but needsprocessing time</td><td>CSMS SHALL indicate this by setting thestatus field in theNotifyEVChargingNeedsResponse to‘Processing’.</td><td></td></tr><tr><td>K17.FR.06(2.1)</td><td></td><td>A NotifyEVChargingNeedsRequest SHALLcontain either ACChargingParameters orDCChargingParameters when Charging Stationis using ISO 15118-2, orV2XChargingParameters when using ISO15118-20.</td><td></td></tr><tr><td>K17.FR.07(2.1)</td><td>(K17.FR.03 ORK17.FR.05)AND controlMode isScheduledControlor absent</td><td>The CSMS SHALL send aSetChargingProfileRequest withchargingProfilePurpose = TxProfile and atmost three chargingSchedule and optionalprice schedule elements, that each contain moreperiods than specified bymaxScheduleTuples inNotifyEVChargingNeedsRequest and by devicemodel variableSmartChargingCtrlr.PeriodsPerSchedule.</td><td></td></tr><tr><td>K17.FR.08</td><td>K17.FR.01</td><td>The CSMS SHOULD send aSetChargingProfileRequest to the ChargingStation within 60 seconds.</td><td>This is to satisfy the ISO 15118ChargeParameterDiscoveryReq timeout.</td></tr><tr><td>K17.FR.09</td><td>K17.FR.07ANDEV returns a chargingprofile</td><td>Charging Station SHALL verify that providedcharging profile is within boundaries of theChargingSchedule from CSMS.</td><td>In ISO 15118 EV can sent its charging profileas part of PowerDeliveryReq.</td></tr><tr><td>K17.FR.10</td><td>K17.FR.09</td><td>Charging Station SHALL send the EV chargingprofile in a NotifyEVChargingScheduleRequestmessage to CSMS.</td><td></td></tr><tr><td>K17.FR.11(2.1)</td><td>K17.FR.10ANDEV charging profile iswithin limits of CSMSChargingSchedule</td><td>CSMS responds withNotifyEVChargingScheduleResponse withstatus Accepted to Charging Station.</td><td>Note: Already checked by Charging Station,but CSMS does its own check. Not applicable indynamic control mode.</td></tr><tr><td>K17.FR.12(2.1)</td><td>K17.FR.10ANDEV charging profile isNOT within limits ofCSMChargingSchedule</td><td>CSMS responds withNotifyEVChargingScheduleResponse withstatus Rejected to Charging Station.</td><td>Not applicable in dynamic control mode.</td></tr><tr><td>K17.FR.13</td><td>K17.FR.12</td><td>CSMS starts new renegotiation as per usecase K16.</td><td></td></tr><tr><td>K17.FR.14</td><td>K17.FR.11</td><td>The Charging Station SHOULD take theschedule from theNotifyEVChargingScheduleRequest intoaccount when calculating the actualComposite schedule.</td><td></td></tr><tr><td>K17.FR.15</td><td>K17.FR.01AND(K17.FR.04 ORCharging Station isoffline)</td><td>The Charging Station SHALL use theTxDefaultProfile (if present) and generate acharging schedule within the limits of itscomposite schedule.</td><td></td></tr><tr><td>K17.FR.16(2.1)</td><td>K17.FR.07EV does not return a charging profile AND EV is not using dynamic control mode</td><td>Charging Station IS RECOMMENDED to return an EV charging profile as a chargingSchedule in a NotifyEVChargingScheduleRequest message to CSMS that matches the charging schedule that was selected by the EV (i.e. the OCPP charging schedule that is represented by the SelectedScheduleTupled that EV sent in PowerDeliveryReq).</td><td>In ISO 15118-2 the EV charging profile and the selected schedule are returned as ChargingProfile and SAScheduleTupled in PowerDeliveryReq.In ISO 15118-20 the EV charging profile and the selected schedule are returned as EVPowerProfile and SelectedScheduleTupled.(See also K17.FR.18)</td></tr><tr><td>K17.FR.17</td><td>K17.FR.01 AND Charging Station is offline</td><td>Charging Station SHOULD add timestamp to the NotifyEVChargingNeedsRequest with the time when charging needs were received from EV</td><td>This will tell CSMS how old this data is, if it was not immediately sent because of an offline period.</td></tr><tr><td>K17.FR.18(2.1)</td><td>K17.FR.10</td><td>Charging Station SHOULD set selectedChargingScheduleId in NotifyEVChargingScheduleRequest to the Id of the chargingSchedule that EV selected from the provided ChargingProfileType(s).</td><td></td></tr><tr><td>K17.FR.19(2.1)</td><td>(K17.FR.03 OR K17.FR.05) AND controlMode is DynamicControl</td><td>The CSMS SHALL send a SetChargingProfileRequest with chargingProfilePurpose = TxProfile and a transactionId and one chargingSchedule element with one or more chargingSchedulePeriods, and optionally an absolutePriceSchedule or priceLevelSchedule element, that each contain no more periods than specified by maxScheduleTuples in NotifyEVChargingNeedsRequest and by device model variable SmartChargingCtrlr.PeriodsPerSchedule.</td><td>The Charging Station will calculate the composite schedule for the EVSE (taking into account a ChargingStationMaxProfile or ChargingStationExternalConstraints if present).</td></tr></table>
+
+# K18 - ISO 15118-20 Scheduled Control Mode
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>ISO 15118-20 Scheduled Control Mode</td></tr><tr><td>2</td><td>ID</td><td>K18</td></tr><tr><td>3</td><td>Objective(s)</td><td>To describe the charging process when Charging Stations uses ISO 15118-20 with scheduled control mode</td></tr><tr><td>4</td><td>Description</td><td>CSMS provides a charging profile with up to three charging schedules and optional price information that try to match the energy needs of EV. EV selects a charging schedule to follow and returns its calculated charging schedule back to Charging Station.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS.</td></tr><tr><td></td><td>Scenario description</td><td>1. EV and Charging Station exchange charge parameters with an AC/DC_ChargeParameterDiscovery message.2. EV sends energy needs and departure time to Charging Station with a ScheduleExchangeReq message.3. Charging Station sends a NotifyEVChargingNeedsRequest message to CSMS with controlMode = ScheduledControl.4. CSMS responds with status = Accepted.5. CSMS sends a charging profile with one or more charging schedules and optional price information to Charging Station via a SetChargingProfileRequest.6. Charging station responds with status = Accepted.7. Charging Station returns offered charging schedule(s) to EV via the ScheduleExchangeRes response.8. EV selects a charging schedule to follow, and calculates its expected charging profile in EVPowerProfile.9. EV sends a PowerDeliveryReq with Id of the selected schedule to follow and its EVPowerProfile to Charging Station.10. Charging Station sends this Id an EVPowerProfile as a NotifyEVChargingScheduleRequest to CSMS.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Both the Charging Station and the EV support ISO 15118-20 Scheduled Control Mode.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td></td></tr><tr><td>7</td><td>Error handling</td><td>Charging Station needs to use the information from the SetChargingProfileRequest message from CSMS to create the response to the ISO 15118-20 ScheduleExchangeReq message from EV. This message has a timeout of 60 seconds, which means the SetChargingProfileRequest has to be sent well within 60 seconds after receiving the NotifyEVChargingNeedsRequest. If the Charging Station does not receive the SetChargingProfileRequest in time or when the NotifyEVChargingNeedsResponse has status = Processing, then the Charging Station will return a schedule in ScheduleExchangeRes that matches charging profiles that are already active at EVSE, e.g. TxDefaultProfile or ChargingStationMaxProfile.When CSMS sends the SetChargingProfileRequest at a later time, then this will trigger a renegotiation according to use case K16 - Renegotiation initiated by CSMS.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Signed PriceSchedules (ISO 15118-20) are supported in OCPP 2.1 via the signatureValue field in ChargingProfileType.When the Charging Station uses ISO 15118-20 "scheduled control mode", it sends charging schedules to the EV. The EV selects one and returns its calculated EVPowerProfile that fits in selected schedule to Charging Station in a PowerDeliveryReq message. Charging Station sends this to CSMS in a NotifyEVChargingScheduleRequest. NOTE: When NotifyEVChargingNeedsRequest has controlMode = ScheduledControl CSMS is not recommended to send a charging profile with chargingProfileKind = Dynamic for which it intends to send frequent updates, because every update of the limit in the charging schedule period will trigger a renegotiation with EV for a new schedule.</td></tr></table>
+
+
+Figure 142. Charging with load-leveling using ISO 15118-20 Scheduled Control Mode
+
+# K18 - ISO 15118-20 Scheduled Control Mode - Requirements
+
+Table 114. K18 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K18.FR.01</td><td>When the Charging Station receives charging needs from the EV in ScheduleExchangeReq for scheduled control mode</td><td>The Charging Station SHALL send a NotifyEVChargingNeedsRequest with controlMode = ScheduledControl to the CSMS.</td><td></td></tr><tr><td>K18.FR.02</td><td>K18.FR.01</td><td>In response to a NotifyEVChargingNeedsRequest the CSMS SHALL send a NotifyEVChargingNeedsResponse.</td><td></td></tr><tr><td>K18.FR.03</td><td>K18.FR.02</td><td>If the CSMS is able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to Accepted.</td><td></td></tr><tr><td>K18.FR.04</td><td>K18.FR.02</td><td>If the CSMS is not able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to NoChargingProfile.</td><td>(Note, status value differs from K15.FR.04). Charging Station will use a TxDefaultProfile or provide a schedule with unlimited power.</td></tr><tr><td>K18.FR.05</td><td>K18.FR.02</td><td>If the CSMS is able to provide a charging schedule; but needs processing time, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to Processing.</td><td>The Charging Station does not have to wait for the SetChargingProfileRequest. CSMS will send it later and trigger a renegotiation as per use case K16.</td></tr><tr><td>K18.FR.06</td><td></td><td>The NotifyEVChargingNeedsRequest SHALL contain V2XChargingParametersType instead of ACChargingParametersType or DCChargingParametersType</td><td>ISO 15118-20 charging parameters are contained in V2XChargingParametersType.</td></tr><tr><td>K18.FR.07</td><td>K18.FR.01 AND (K18.FR.03 OR K18.FR.05)</td><td>The CSMS SHALL send a SetChargingProfileRequest with chargingProfilePurpose = TxProfile and a transactionId and at most three chargingSchedule elements with one or more chargingSchedulePeriods (at most SmartChargingCtrlr.PeriodsPerSchedule periods), and optionally an absolutePriceSchedule or priceLevelSchedule element, that each contain no more entries than specified by maxScheduleTuples in NotifyEVChargingNeedsRequest.</td><td>The Charging Station will calculate the composite schedule(s) for the EVSE (taking into account a ChargingStationMaxProfi le or ChargingStationExternal Constraints if present) and will convert that to the ScheduleTupleType format for ISO 15118-20. Maximum number of entries is determined by MaximumSupportedPoints from ScheduleExchangeReq message.</td></tr><tr><td>K18.FR.08</td><td>K18.FR.01</td><td>The CSMS SHOULD send a SetChargingProfileRequest to the Charging Station within 60 seconds.</td><td>This is to satisfy the ISO 15118-20 ScheduleExchangeReq timeout. See also K18.FR.20</td></tr><tr><td>K18.FR.09</td><td>K18.FR.20 AND EV returns the Id of the selected charging schedule and an EVPowerProfile in PowerDeliveryReq</td><td>Charging Station SHALL verify that provided charging profile is within boundaries of the selected ChargingSchedule from CSMS.</td><td></td></tr><tr><td>K18.FR.10</td><td>K18.FR.09</td><td>Charging Station SHALL send the EVPowerProfile from EV as a chargingSchedule in a NotifyEVChargingScheduleRequest message to CSMS and set the field selectedChargingScheduleId to the Id of the charging schedule selected by EV.</td><td></td></tr><tr><td>K18.FR.11</td><td>K18.FR.10 AND EV charging profile is within limits of CSMS ChargingSchedule</td><td>CSMS responds with NotifyEVChargingScheduleResponse with status Accepted to Charging Station.</td><td>Note: Already checked by Charging Station, but CSMS does its own check.</td></tr><tr><td>K18.FR.12</td><td>K18.FR.10 AND chargingSchedule in NotifyEVChargingScheduleRequest is NOT within limits of CSMS ChargingSchedule</td><td>CSMS responds with NotifyEVChargingScheduleResponse with status Rejected to Charging Station.</td><td></td></tr><tr><td>K18.FR.13</td><td>K18.FR.12</td><td>CSMS starts new renegotiation as per use case K16.</td><td></td></tr><tr><td>K18.FR.14</td><td>K18.FR.11</td><td>The Charging Station SHOULD take the schedule from the NotifyEVChargingScheduleRequest into account when calculating the actual composite schedule.</td><td></td></tr><tr><td>K18.FR.15</td><td>K18.FR.03 AND (K18.FR.04 OR Charging Station is offline)</td><td>The Charging Station SHALL use the TxDefaultProfile (if present) and generate a charging schedule within the limits of its composite schedule.</td><td></td></tr><tr><td>K18.FR.16</td><td>K18.FR.07</td><td>It is RECOMMENDED to configure the Charging Station, such that a TransactionEvent with idToken has been sent prior to the NotifyEVChargingNeedsRequest Message, so that CSMS can take the user into account when creating a charging schedule.</td><td>This can be achieved by setting TxStartPoint to Authorized, EVConnected or PowerPathClosed.</td></tr><tr><td>K18.FR.17</td><td>When Charging Station receives a SetChargingProfileRequest immediately after the transaction has started and before it has sent the NotifyEVChargingNeedsRequest to CSMS</td><td>The Charging Station SHOULD respond with SetChargingProfileResponse with status = Rejected and a statusInfo withreasonCode=InvalidMessageSequence.</td><td>CSMS sent profile too early. It does not harm if CS accepts the charging profile instead of rejecting it, as long as it sends a charging profile again when it receives the NotifyEVChargingNeedsRequest.</td></tr><tr><td>K18.FR.18</td><td>K18.FR.03 OR K18.FR.05</td><td>CSMS IS RECOMMENDED to use only one chargingSchedule in a SetChargingProfileRequest.</td><td>This ensures that there is no doubt about which schedule the EV will follow, even when no NotifyEVChargingScheduleRequest is received.</td></tr><tr><td>K18.FR.19</td><td>K18.FR.07 AND EV does not return EVPowerProfile</td><td>Charging Station IS RECOMMENDED to return an EV charging profile as a chargingSchedule in a NotifyEVChargingScheduleRequest message to CSMS that matches the charging schedule that was selected by the EV (i.e. the OCPP charging schedule that is represented by the SelectedScheduleTupled that EV sent in the PowerDeliveryReq.)</td><td>This situation should not occur, because EV is required to send an EVPowerProfile.</td></tr><tr><td>K18.FR.20</td><td>K18.FR.08</td><td>The Charging Station SHALL return the charging (and optional price) schedule(s) to EV in the ScheduleExchangeRes response.</td><td></td></tr><tr><td>K18.FR.21</td><td>K18.FR.01 AND Charging Station is offline</td><td>Charging Station SHOULD add timestamp to the NotifyEVChargingNeedsRequest with the time when charging needs were received from EV</td><td>This will tell CSMS how old this data is, if it was not immediately sent because of an offline period.</td></tr><tr><td>K18.FR.22</td><td>K18.FR.02 AND CSMS does not accept the requestedEnergyTransfer in NotifyEVChargingNeedsRequest</td><td>CSMS SHALL respond with NotifyEVChargingNeedsResponse with status = Rejected.</td><td>Charging station will then stop the transaction.</td></tr><tr><td>K18.FR.23</td><td>K18.FR.22</td><td>Charging Station SHALL terminate the transaction and send a TransactionEventRequest with eventType = Ended, triggerReason = AbnormalCondition, stoppedReason = ReqEnergyTransferRejected.</td><td></td></tr></table>
+
+# K19 - ISO 15118-20 Dynamic Control Mode
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>ISO 15118-20 Dynamic Control Mode</td></tr><tr><td>2</td><td>ID</td><td>K19</td></tr><tr><td>3</td><td>Objective(s)</td><td>To describe the charging process when Charging Stations uses ISO 15118-20 with dynamic control mode</td></tr><tr><td>4</td><td>Description</td><td>CSMS provides a charging profile with one charging schedule and optional price information that tries to match the energy needs of EV. Charging Station only sends the pricing schedule to EV. EV returns its fastest possible charging schedule back to Charging Station.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS.</td></tr><tr><td></td><td>Scenario description</td><td>1. EV and Charging Station exchange charge parameters with an AC/DC_ChargeParameterDiscovery message.2. EV sends energy needs and departure time to Charging Station with a ScheduleExchangeReq message.3. Charging Station sends a NotifyEVChargingNeedsRequest message with controlMode = DynamicControl to CSMS.4. CSMS responds with status = Accepted.5. CSMS sends a charging profile with one charging schedule and optional price information to Charging Station via a SetChargingProfileRequest.6. Charging station responds with status = Accepted.7. Charging Station returns the offered pricing schedule (but not the charging schedule) to EV via a ScheduleExchangeRes response.8. EV sends a PowerDeliveryReq with its EVPowerProfile that describes its fastest possible charging schedule to Charging Station.9. Charging Station ignores this EVPowerProfile and sends the charging schedule provided by CSMS as a NotifyEVChargingScheduleRequest to CSMS.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Both the Charging Station and the EV support ISO 15118-20 Dynamic Control Mode.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td></td></tr><tr><td>7</td><td>Error handling</td><td>Charging Station needs to use the information from the SetChargingProfileRequest message from CSMS to create the response to the ISO 15118-20 ScheduleExchangeReq message from EV. This message has a timeout of 60 seconds, which means the SetChargingProfileRequest has to be sent well within 60 seconds after receiving the NotifyEVChargingNeedsRequest. If the Charging Station does not receive the SetChargingProfileRequest in time or when the NotifyEVChargingNeedsResponse has status = Processing, then the Charging Station will return a schedule in ScheduleExchangeRes that matches charging profiles that are already active at EVSE, e.g. TxDefaultProfile or ChargingStationMaxProfile.When CSMS sends the SetChargingProfileRequest at a later time, then this will trigger a renegotiation according to use case K16 - Renegotiation initiated by CSMS.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Signed PriceSchedules (ISO 15118-20) are supported in OCPP 2.1 via the signatureValue field in ChargingProfileType.When the Charging Station uses ISO 15118-20 "dynamic control mode", it does not send any charging schedules to the EV (only an optional price schedule). Instead, it will dynamically update the power limit over time to match the charging profile from CSMS.The EV still returns an EVPowerProfile to the Charging Station in PowerDeliveryReq. This EVPowerProfile is the fastest way the EV can charge given the charge parameters, and it disregards the charging profile provided to the Charging Station by CSMS. Therefore this should not be returned as a NotifyEVChargingSchedule to CSMS.Instead, Charging Station returns the CSMS charging schedule in NotifyEVChargingSchedule, since this is the schedule that EV will be made to follow.NOTE: ISO 15118-20 "dynamic control mode" does not require a charging profile from CSMS with chargingProfileKind = Dynamic. For example, CSMS can send an Absolute charging profile with several charging schedule periods, that the Charging Station executes towards the EV using dynamic control mode.</td></tr></table>
+
+
+Figure 143. Charging with load-leveling using ISO 15118-20 Dynamic Control Mode
+
+# K19 - ISO 15118-20 Dynamic Control Mode - Requirements
+
+Table 115. K19 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K19.FR.01</td><td>When the Charging Station receives charging needs from the EV in ScheduleExchangeReq for dynamic control mode</td><td>The Charging Station SHALL send a NotifyEVChargingNeedsRequest with controlMode = DynamicControl to the CSMS.</td><td></td></tr><tr><td>K19.FR.02</td><td>K19.FR.01</td><td>In response to a NotifyEVChargingNeedsRequest the CSMS SHALL send a NotifyEVChargingNeedsResponse.</td><td></td></tr><tr><td>K19.FR.03</td><td>K19.FR.02</td><td>If the CSMS is able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to Accepted.</td><td></td></tr><tr><td>K19.FR.04</td><td>K19.FR.02</td><td>If the CSMS is not able to provide a charging schedule, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to NoChargingProfile.</td><td>(Note, status value differs from K15.FR.04). Charging Station will use a TxDefaultProfile or provide a schedule with unlimited power.</td></tr><tr><td>K19.FR.05</td><td>K19.FR.02</td><td>If the CSMS is able to provide a charging schedule; but needs processing time, it SHALL indicate this by setting the status field in the NotifyEVChargingNeedsResponse to Processing.</td><td>The Charging Station does not have to wait for the SetChargingProfileRequest. CSMS will send it later and trigger a renegotiation as per use case K16.</td></tr><tr><td>K19.FR.06</td><td></td><td>The NotifyEVChargingNeedsRequest SHALL contain V2XChargingParametersType instead of ACChargingParametersType or DCChargingParametersType</td><td>ISO 15118-20 charging parameters are contained in V2XChargingParametersType.</td></tr><tr><td>K19.FR.07</td><td>K19.FR.01 AND (K19.FR.03 OR K19.FR.05)</td><td>The CSMS SHALL send a SetChargingProfileRequest with chargingProfilePurpose = TxProfile and a transactionId and one chargingSchedule element with one or more chargingSchedulePeriods, and optionally an absolutePriceSchedule or priceLevelSchedule element, that in total contain no more periods than specified by maxScheduleTuples in NotifyEVChargingNeedsRequest and by device model variable SmartChargingCtrl.PeriodsPerSchedule.</td><td>The Charging Station will calculate the composite schedule for the EVSE (taking into account a ChargingStationMaxProfi le or ChargingStationExternal Constraints if present). maxScheduleTuples provides a maximum for charging schedule periods, price schedule entries and price rules. (see ISO 15118-20 [V2G20-2175]).</td></tr><tr><td>K19.FR.08</td><td>K19.FR.01</td><td>The CSMS SHOULD send a SetChargingProfileRequest to the Charging Station within 60 seconds.</td><td>This is to satisfy the ISO 15118-20 ScheduleExchangeReq timeout.</td></tr><tr><td>K19.FR.09</td><td>K19.FR.08</td><td>The Charging Station SHALL return the optional price schedule to EV in the ScheduleExchangeRes response.</td><td></td></tr><tr><td>K19.FR.10</td><td>EV sends an EVPowerProfile in PowerDeliveryReq</td><td>Charging Station SHALL disregard the EVPowerProfile from EV and use the charging schedule received from CSMS as the chargingSchedule in the NotifyEVChargingScheduleRequest message to CSMS and set the field selectedChargingScheduleId to the Id of this charging schedule.</td><td>Charging Station will ensure that EV follows the CSMS charging schedule.</td></tr><tr><td>K19.FR.11</td><td>K19.FR.01 AND (K19.FR.04 OR Charging Station is offline)</td><td>The Charging Station SHALL use the TxDefaultProfile (if present) and generate a charging schedule within the limits of its composite schedule.</td><td></td></tr><tr><td>K19.FR.12</td><td>K19.FR.07</td><td>It is RECOMMENDED to configure the Charging Station, such that a TransactionEvent with idToken has been sent prior to the NotifyEVChargingNeedsRequest Message, so that CSMS can take the user into account when creating a charging schedule.</td><td>This can be achieved by setting TxStartPoint to Authorized, EVConnected or PowerPathClosed.</td></tr><tr><td>K19.FR.13</td><td>When Charging Station receives a SetChargingProfileRequest immediately after the transaction has started and before it has sent the NotifyEVChargingNeedsRequest to CSMS</td><td>The Charging Station SHOULD respond with SetChargingProfileResponse with status = Rejected and a statusInfo withreasonCode=InvalidMessageSequence.</td><td>CSMS sent profile too early. It does not harm if CS accepts the charging profile instead of rejecting it, as long as it sends a charging profile again when it receives the NotifyEVChargingNeedsRequest t.</td></tr><tr><td>K19.FR.14</td><td>K19.FR.01 AND Charging Station is offline</td><td>Charging Station SHOULD add timestamp to the NotifyEVChargingNeedsRequest with the time when charging needs were received from EV</td><td>This will tell CSMS how old this data is, if it was not immediately sent because of an offline period.</td></tr><tr><td>K19.FR.15</td><td>K19.FR.02 AND CSMS does not accept the requestedEnergyTransfer in NotifyEVChargingNeedsRequest</td><td>CSMS SHALL respond with NotifyEVChargingNeedsResponse with status = Rejected.</td><td>Charging station will then stop the transaction.</td></tr><tr><td>K19.FR.16</td><td>K19.FR.15</td><td>Charging Station SHALL terminate the transaction and send a TransactionRequest with eventType = Ended, triggerReason = AbnormalCondition, stoppedReason = ReqEnergyTransferRejected.</td><td></td></tr></table>
+
+# K20 - ISO 15118-20 Adjusting charging schedule when energy needs change
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>ISO 15118-20 Adjusting charging schedule when energy needs change</td></tr><tr><td>2</td><td>ID</td><td>K20</td></tr><tr><td>3</td><td>Objective(s)</td><td>To adjust the charging schedule when EV reports a change in departure time or energy need.</td></tr><tr><td>4</td><td>Description</td><td>The user has changed the departure time or requested energy amount, either via EV or charging station. This means that the charging profile may have to be updated for these needs. The charging station notifies CSMS of this situation.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description #1</td><td>Via EV when using ISO 15118-20 Scheduled Control mode
+1. EV sends a ScheduleExchangeReq message with new DepartureTime and/or EVTargetEnergyRequest.
+2. CS sends a NotifyEVChargingNeedsRequest with given departureTime and evTargetEnergyRequest to CSMS.
+3. CSMS calculates a new charging profile and sends a SetChargingProfileRequest to the Charging Station.
+4. CS returns the new charging schedule to EV in the ScheduleExchangeRes response message.
+5. EV sends its projected charging schedule (EVPowerProfile) in a PowerDeliveryReq to the Charging Station.
+6. CS sends this EV charging schedule to CSMS as a NotifyEVChargingScheduleRequest.</td></tr><tr><td></td><td>Scenario description #2</td><td>Via EV when using ISO 15118-20 Dynamic Control mode
+1. EV sends an AC/DC_ChargeLoopReq message with new DepartureTime and/or EVTargetEnergyRequest.
+2. CS sends a NotifyEVChargingNeedsRequest with given departureTime and evTargetEnergyRequest to CSMS.
+3. CSMS calculates a new charging profile and sends a SetChargingProfileRequest to the Charging Station.
+4. CS controls charging of EV via the AC/DC_ChargeLoopRes message to match the provided charging profile.</td></tr><tr><td></td><td>Scenario description #3</td><td>Via charging station when using ISO 15118-20 Dynamic Control mode
+1. CS respond to an AC/DC_ChargeLoopReq message with an AC/DC_ChargeLoopRes message with a new DepartureTime.
+2. CS sends a NotifyEVChargingNeedsRequest with given departureTime and evTargetEnergyRequest to CSMS.
+3. CSMS calculates a new charging profile and sends a SetChargingProfileRequest to the Charging Station.
+4. CS controls charging of EV via the AC/DC_ChargeLoopRes message to match the provided charging profile.</td></tr><tr><td>5</td><td>Prerequisites</td><td>A charging session based on ISO 15118-20 is already active.</td></tr><tr><td>6</td><td>Post conditions</td><td>EV is charging according to an updated charging profile.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td></td></tr></table>
+
+
+
+# K20 - ISO 15118-20 Adjusting charging schedule when energy needs change - Requirements
+
+Table 116. K20 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K20.FR.01</td><td>Charging Station receives a new departure time and/or target energy amount from EV</td><td>Charging Station sends a NotifyEVChargingNeedsRequest with a chargingNeeds element with new departureTime and/or a v2xChargingParameters element with new evTargetEnergyRequest to CSMS</td><td></td></tr><tr><td>K20.FR.02</td><td>K20.FR.01 AND EV and Charging Station use ISO 15118-20 "Scheduled Control Mode"</td><td>Behavior is as described in K17 - Renegotiation initiated by EV</td><td></td></tr><tr><td>K20.FR.03</td><td>K20.FR.01 AND EV and Charging Station use ISO 15118-20 "Dynamic Control Mode"</td><td>CSMS calculates a new charging profile and sends a SetChargingProfileRequest to Charging Station</td><td></td></tr><tr><td>K20.FR.04</td><td>K20.FR.03</td><td>Charging Stations controls charging of EV via the AC/DC_ChargeLoopRes message to match the given charging profile limit or setpoint.</td><td></td></tr><tr><td>K20.FR.05</td><td>K20.FR.01 AND Charging Station is offline</td><td>Charging Station SHOULD add timestamp to the NotifyEVChargingNeedsRequest with the time when charging needs were received from EV</td><td>This will tell CSMS how old this data is, if it was not immediately sent because of an offline period.</td></tr></table>
+
+# 5.4. Priority Charging
+
+# K21 - Requesting priority charging remotely
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Requesting priority charging remotely</td></tr><tr><td>2</td><td>ID</td><td>K21</td></tr><tr><td>3</td><td>Objective(s)</td><td>To let a user request immediate charging via CSMS (e.g. via smartphone app)</td></tr><tr><td>4</td><td>Description</td><td>The user requests CSMS to charge the EV immediately and avoid V2X discharging. CSMS instructs CS to charge the EV with the highest power possible under the circumstances. Note, that his may be less than the maximum capacity of the CS when other restrictions (e.g. load-balancing) are in effect.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS is triggered to request priority charging for the active transaction at the EVSE (how this is done is outside scope of OCPP).2. The CSMS sends a UsePriorityChargingRequest message with activate = true for transaction transactionId.3. If Charging Station has an PriorityCharging profile, then it will respond with UsePriorityChargingResponse Accepted.4. The Charging Station stops applying the TxDefaultProfile or TxProfile charging profile (if active) to this transaction, and applies the PriorityCharging profile instead.5. The Charging Station responds with a NotifyPriorityChargingRequest with activated = true and transactionId set to the transaction to confirm that it now applies the instant charging profile.6. The CSMS confirms receipt with a NotifyPriorityChargingResponse.</td></tr><tr><td>5</td><td>Prerequisites</td><td>CSMS has sent a charging profile with chargingProfilePurpose = PriorityCharging to the Charging Station for this EVSE or for EVSE #0. The Charging Station is online and a transaction is active.</td></tr><tr><td>6</td><td>Post conditions</td><td>The transaction continues using the PriorityCharging profile.</td></tr><tr><td>7</td><td>Error Handling</td><td>If Charging Station has no PriorityCharging profile, then it responds with NoProfile. If it cannot activate for other reasons, (e.g. because transactionId does not exist) then it responds with Rejected. In both cases, the use case ends.</td></tr><tr><td>8</td><td>Remarks</td><td>The priority charging profile remains in effect for the duration of the transaction. It ceases to be active when the charging session is terminated, or when CSMS requests priority charging to stop.The use of priority charging is not restricted to V2X operations only. A priority charging profile can also be requested for non-V2X transactions.A priority charging profile can be deactivated by sending a NotifyPriorityChargingRequest with activated = false.It is possible to provide a PriorityCharging profile with a maxOfflineDuration and a high stack level and another PriorityChargingProfile with no maxOfflineDuration and a lower stack level. The first one is then only used as long as the charging station is online and can therefore utilize higher power levels. The second profile becomes active when the charging station goes offline and utilizes safer lower power levels.</td></tr></table>
+
+
+Figure 144. Requesting PriorityCharging remotely
+
+# K21 - Requesting priority charging remotely - Requirements
+
+Table 117. K21 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K21.FR.01</td><td>Charging Station receives a UsePriorityChargingRequest with transactionId that matches an ongoing transaction AND Charging Station does not have a PriorityCharging charging profile installed on EVSE #0 or the EVSE of the transaction</td><td>Charging Station SHALL respond with UsePriorityChargingResponse with status = NoProfile and an optional reasonCode = "NotFound"</td><td>A PriorityCharging profile on EVSE #0 applies to all EVSEs.</td></tr><tr><td>K21.FR.02</td><td>Charging Station receives a UsePriorityChargingRequest with transactionId that does not match an ongoing transaction</td><td>Charging Station SHALL respond with UsePriorityChargingResponse with status = Rejected and an optional reasonCode = "TxNotFound"</td><td></td></tr><tr><td>K21.FR.03</td><td>Charging Station receives a UsePriorityChargingRequest with transactionId that matches an ongoing transaction AND Charging Station has a PriorityCharging charging profile installed on EVSE #0 or the EVSE of the transaction</td><td>Charging Station SHALL respond with UsePriorityChargingResponse with status = Accepted</td><td></td></tr><tr><td>K21.FR.04</td><td>K21.FR.03</td><td>Charging Station SHALL stop applying the TxDefaultProfile or TxProfile charging profile (if active) to this transaction and applies the PriorityCharging profile instead.</td><td>ChargingStationMaxProfil e charging profiles remains in effect.</td></tr><tr><td>K21.FR.05</td><td>K21.FR.04</td><td>Charging Station SHALL send a NotifyPriorityChargingRequest with activated = true and transactionId set to the associated transaction</td><td></td></tr><tr><td>K21.FR.06</td><td>Charging Station receives a UsePriorityChargingRequest with transactionId that matches an ongoing transaction and activate = false</td><td>Charging Station SHALL respond with UsePriorityChargingResponse with status = Accepted</td><td>If no PriorityCharging profile was active, then this has no effect.</td></tr><tr><td>K21.FR.07</td><td>K21.FR.06 AND PriorityCharging is active for the transaction</td><td>Charging Station SHALL stop applying the PriorityCharging profile and reapply the TxDefaultProfile or TxProfile charging profile (if existing) to this transaction.</td><td></td></tr><tr><td>K21.FR.08</td><td>K21.FR.07</td><td>Charging Station SHALL send a NotifyPriorityChargingRequest with activated = false and transactionId set to the associated transaction</td><td></td></tr><tr><td>K21.FR.09</td><td>K21.FR.05 OR K21.FR.08</td><td>CSMS SHALL respond with NotifyPriorityChargingResponse.</td><td></td></tr></table>
+
+# K22 - Requesting priority charging locally
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Requesting priority charging locally</td></tr><tr><td>2</td><td>ID</td><td>K22</td></tr><tr><td>3</td><td>Objective(s)</td><td>To let a user request immediate charging at the Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>The user requests to charge the EV immediately and avoid V2X discharging. Charging Station switches to a priority charging schedule to charge the EV with the highest power possible under the circumstances. Note, that this may be less than the maximum capacity of the CS when other restrictions (e.g. load-balancing) are in effect.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. User instructs Charging Station (via button or display) to request a priority charging for the transaction.
+2. The Charging Station stops applying the TxDefaultProfile or TxProfile charging profile (if active) to this transaction, and applies the PriorityCharging profile instead.
+3. The Charging Station responds with a NotifyPriorityChargingRequest with activated = true and transactionId set to the transaction to tell CSMS that it now applies the priority charging profile.
+4. The CSMS confirms receipt with a NotifyPriorityChargingResponse.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station is online and a transaction is active.</td></tr><tr><td>6</td><td>Post conditions</td><td>Transaction using the priority charging profile with the highest possible power profile that CSMS deems possible under the circumstances.</td></tr><tr><td>7</td><td>Error Handling</td><td>If Charging Station has no PriorityCharging profile, then it cannot switch to priority charging.</td></tr><tr><td>8</td><td>Remarks</td><td>If the Charging Station is offline, it switches to the PriorityCharging profile and queues the NotifyPriorityChargingRequest message to be transmitted when it is back online.
+The priority charging profile remains in effect for the duration of the transaction. It ceases to be active when the charging session is terminated, or when priority charging is requested to stop.
+The use of priority charging is not restricted to V2X operations only. A priority charging profile can also be requested for non-V2X transactions.</td></tr></table>
+
+
+Figure 145. Requesting PriorityCharging locally
+
+# K22 - Requesting priority charging locally - Requirements
+
+Table 118. K22 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K22.FR.01</td><td>User instructs Charging Station (via button or display) to request a priority charging for the transaction AND No PriorityCharging profile is present, that is valid for the associated EVSE</td><td>Charging Station SHALL notify user it is not capable of PriorityCharging.</td><td></td></tr><tr><td>K22.FR.02</td><td>User instructs Charging Station (via button or display) to request a priority charging for the transaction AND a PriorityCharging profile, that is valid for the associated EVSE, has been installed earlier.</td><td>Charging Station SHALL stop applying the TxDefaultProfile or TxProfile charging profile (if active) to this transaction and apply the PriorityCharging profile instead</td><td>ChargingStationMaxProfi le charging profile remains in effect.</td></tr><tr><td>K22.FR.03</td><td>K22.FR.02</td><td>Charging Station SHALL send a NotifyPriorityChargingRequest with activated = true and transactionId set to the affected transaction</td><td></td></tr><tr><td>K22.FR.04</td><td>User instructs Charging Station (via button or display) to end priority charging for the transaction</td><td>Charging Station SHALL stop applying the PriorityCharging charging profile and reapply the TxDefaultProfile or TxProfile charging profile (if active) to this transaction instead.</td><td>Charging Station UI should not allow this option when priority charging was not in effect.</td></tr><tr><td>K22.FR.05</td><td>K22.FR.04</td><td>Charging Station SHALL send a NotifyPriorityChargingRequest with activated = false and transactionId set to the affected transaction</td><td></td></tr><tr><td>K22.FR.06</td><td>K22.FR.03 OR K22.FR.05</td><td>CSMS SHALL respond with NotifyPriorityChargingResponse.</td><td></td></tr></table>
+
+# 5.5. Dynamic Charging Profiles
+
+Dynamic charging profiles are a way to provide dynamic charging limit updates without a charging schedule. The mechanism of a charging profile with a charging schedule is still used, but the schedule only consists of a single period for which the limits or setpoints can be changed dynamically via the UpdateDynamicScheduleRequest or PullDynamicScheduleUpdateResponse message from CSMS.
+
+Dynamic charging profiles are useful for changes in (dis)charging limits that cannot be scheduled, because of their unpredictable nature. It matches well with the ISO 15118-20 "dynamic control mode", which does not use a schedule either.
+
+The use of dynamic charging profiles is suboptimal in combination with ISO 15118-20 "scheduled control mode" or ISO 15118-2, which both rely on charging schedules. Any change in a limit or setpoint of the dynamic charging profile will cause a renegotiation between EV and Charging Station for a new charging schedule.
+
+# K28 - Dynamic charging profiles from CSMS
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Dynamic charging profiles from CSMS</td></tr><tr><td>2</td><td>ID</td><td>K28</td></tr><tr><td>3</td><td>Objective(s)</td><td>To allow a dynamically changing limit in a charging profile.</td></tr><tr><td>4</td><td>Description</td><td>A dynamic ChargingProfileType consists of a single schedule period in which the limit or setpoint can be updated without having to replace the charging profile. The updated value is either sent by CSMS or pulled by Charging Station via messages.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, external system (EMS)</td></tr><tr><td></td><td>Scenario description #1</td><td>Updates sent by CSMS
+1. CSMS sends a SetChargingProfileRequest with a ChargingProfileType with chargingProfileKind = Dynamic and a single chargingSchedule with one chargingSchedulePeriod with a limit and without a dynUpdateTimeInterval.
+2. Charging Station responds with SetChargingProfileResponse with status = Accepted and applies limit to charging, and sets dynUpdateTime to current time.
+3. When CSMS wishes to update the limit it sends a UpdateDynamicScheduleRequest with the chargingProfileId of the charging profile and a ChargingScheduleUpdateTime with a new value of limit.
+4. Charging stations responds with UpdateDynamicScheduleResponse with status = Accepted, sets dynUpdateTime in ChargingProfileType to current time, and applies the new limit.</td></tr><tr><td></td><td>Scenario description #2</td><td>Updates requested by Charging Station
+1. CSMS sends a SetChargingProfileRequest with a ChargingProfileType with chargingProfileKind = Dynamic and a single chargingSchedule with one chargingSchedulePeriod with a limit and with a dynUpdateTimeInterval of 60 seconds, which tells Charging Station to pull for updates every 60 seconds.
+2. Charging Station responds with SetChargingProfileResponse with status = Accepted and applies limit to charging, and sets dynUpdateTime to current time.
+3. When the time is dynUpdateTime + dynUpdateTimeInterval Charging Station requests an update by sending a PullDynamicScheduleUpdateRequest with the chargingProfileId of the charging profile.
+4. CSMS responds with PullDynamicScheduleUpdateResponse with status = Accepted and a ChargingScheduleUpdateTime with a new value for limit.
+5. Charging Station sets dynUpdateTime in ChargingProfileType to current time, and applies the new limit.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station supports Dynamic charging profiles.</td></tr><tr><td>6</td><td>Post conditions</td><td></td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td></td></tr></table>
+
+
+Figure 146. Sequence Diagram: Dynamic charging profile
+
+# K28 - Dynamic charging profiles from CSMS - Requirements
+
+Table 119. K28 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K28.FR.01</td><td></td><td>A ChargingProfileType with chargingProfileKind = Dynamic SHALL consist of only 1 ChargingScheduleType with only 1 ChargingSchedulePeriodType</td><td></td></tr><tr><td>K28.FR.02</td><td></td><td>The ChargingSchedulePeriodType in a ChargingProfileType with chargingProfileKind = Dynamic SHALL have a startPeriod = 0</td><td>It becomes immediately active upon receipt of the message.</td></tr><tr><td>K28.FR.03</td><td>When Charging Station receives a SetChargingProfileRequest in which chargingSchedule does not obey K28.FR.01 or K28.FR.02</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status = Rejected and optionally a statusInforeasonCode = "InvalidSchedule"</td><td></td></tr><tr><td>K28.FR.04</td><td>When Charging Station receives a SetChargingProfileRequest with a chargingProfileKind that is not Dynamic and with a field dynUpdateTimeInterval</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status = Rejected and optionally a statusInforeasonCode = "InvalidProfile".</td><td>dynUpdateTimeInterval only applies to Dynamic profiles.</td></tr><tr><td>K28.FR.05</td><td>When Charging Station receives a SetChargingProfileRequest with chargingProfileKind = Dynamic AND dynUpdateTimeTime is not set</td><td>Charging Station SHALL set dynUpdateTimeTime in ChargingProfileType to current time.</td><td></td></tr><tr><td>K28.FR.06</td><td>When Charging Station receives a UpdateDynamicScheduleRequest for a charging profile that has chargingProfileKind = Dynamic</td><td>Charging Station SHALL respond with status = Accepted and immediately apply the values from UpdateDynamicScheduleRequest to the charging profile.</td><td></td></tr><tr><td>K28.FR.07</td><td>When CSMS receives a PullDynamicScheduleUpdateRequest for a charging profile that has chargingProfileKind = Dynamic</td><td>CSMS SHALL respond with PullDynamicScheduleUpdateResponse with status = Accepted and the limits/setpoints to use in the charging profile.</td><td></td></tr><tr><td>K28.FR.08</td><td>When Charging Station receives a PullDynamicScheduleUpdateResponse for a charging profile that has chargingProfileKind = Dynamic</td><td>Charging Station SHALL immediately apply the values from PullDynamicScheduleUpdateResponse to the charging profile.</td><td></td></tr><tr><td>K28.FR.09</td><td>K28.FR.06 OR K28.FR.07 OR K28.FR.08</td><td>Charging Station SHALL set dynUpdateTime to current time.</td><td></td></tr><tr><td>K28.FR.10</td><td>When chargingProfileKind = Dynamic and dynUpdateTimeInterval > 0 in chargingProfile</td><td>Charging Station SHALL send a PullDynamicScheduleUpdateRequest with chargingProfileId = chargingProfile.id to request an update of the chargingSchedulePeriod.</td><td></td></tr><tr><td>K28.FR.11</td><td>When Charging Station receives a UpdateDynamicScheduleRequest for a charging profile that does not have chargingProfileKind = Dynamic</td><td>Charging Station SHALL respond with a status = Rejected and optionally a statusInfoReasonCode = InvalidProfile</td><td></td></tr><tr><td>K28.FR.12</td><td>When CSMS receives a PullDynamicScheduleUpdateRequest for a charging profile that does not exist or does not have chargingProfileKind = Dynamic</td><td>CSMS SHALL respond with a status = Rejected and optionally a statusInfoReasonCode = InvalidProfile</td><td></td></tr></table>
+
+# K29 - Dynamic charging profiles from external system
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Dynamic charging profiles from external system</td></tr><tr><td>2</td><td>ID</td><td>K29</td></tr><tr><td>3</td><td>Objective(s)</td><td>To allow a dynamically changing limit in a charging profile from an external system.</td></tr><tr><td>4</td><td>Description</td><td>A dynamic ChargingProfileType consists of a single schedule period in which the limit or setpoint can be updated without having to replace the charging profile. operationMode is set to ExternalLimits or ExternalSetpoint, which means that the limit or setpoint is set directly by an external system, e.g. an energy management system.
+This can be a charging limit or schedule that is received from an energy management system (via any interface) and which is represented by Charging Station as a charging profile of purpose ChargingStationExternalConstraints.
+If ExternalConstraintsProfileDisallowed is true, then an external system is not allowed to set a ChargingStationExternalConstraints profile. In that case CSMS decides when the limits from the external system are taken into account by submitting a charging profile of purpose TxProfile or TxDefaultProfile with a chargingSchedulePerioc that has operationMode = ExternalLimits or ExternalSetpoint.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, external system (EMS)</td></tr><tr><td></td><td>Scenario description #1</td><td>Charging profile from external system with dynamic updates
+1. The external system provides limits, which the Charging Station internally represents as a ChargingProfileType with chargingProfilePurpose = ChargingStationExternalConstraints, chargingProfileKind = Dynamic and a single chargingSchedule with one chargingSchedulePeriod with an operationMode = ExternalLimits (or ExternalSetpoint)
+2. Charging Station applies limit (or setpoint) to charging.
+3. Whenever the external system updates the limit (or setpoint), Charging Station applies the new limit (or setpoint).
+4. If the charging limit changed by more than LimitChangeSignificance, the Charging Station sends a NotifyChargingLimitRequest message to CSMS with optionally the set charging limit, as described in use case K11.</td></tr><tr><td></td><td>Scenario description #2</td><td>Charging profile from CSMS with dynamic updates from external system
+1. CSMS sends a SetChargingProfileRequest with a ChargingProfileType with chargingProfilePurpose = TxProfile (or TxDefaultProfile), chargingProfileKind = Dynamic and a single chargingSchedule with one chargingSchedulePeriod with an operationMode = ExternalLimits (or ExternalSetpoint), which tells Charging Station that an external system (e.g. an EMS) will provide updates to the limit (or setpoint) to use in this _chargingSchedulePeriod.
+2. Charging Station responds with SetChargingProfileResponse with status = Accepted and applies limit to charging.
+3. Whenever the external system updates the limit (or setpoint), Charging Station applies the new limit (or setpoint).
+4. If the charging limit changed by more than LimitChangeSignificance, the Charging Station sends a NotifyChargingLimitRequest message to CSMS with optionally the set charging limit, as described in use case K11.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station supports Dynamic charging profiles, and is able to receive power limits from an external system.</td></tr><tr><td>6</td><td>Post conditions</td><td>External system can dynamically update the power limit in the charging profile.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>When an EMS provides frequent updates to a power limit, instead of providing a schedule, then each update would result in Charging Station having to replace the existing ChargingStationExternalConstraints charging profile by a new one. When using a Dynamic charging profile Charging Station only has to update the value of limit or setpoint of the existing charging profile.</td></tr></table>
+
+
+Figure 147. Sequence Diagram: Dynamic charging profile
+
+# K29 - Dynamic charging profiles by external system - Requirements
+
+Table 120. K29 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>K29.FR.01</td><td></td><td>A ChargingProfileType with chargingProfileKind = Dynamic SHALL consist of only 1 ChargingScheduleType with only 1 ChargingSchedulePeriodType</td><td>(Same as K28.FR.01)</td></tr><tr><td>K29.FR.02</td><td></td><td>The ChargingSchedulePeriodType in a ChargingProfileType with chargingProfileKind = Dynamic SHALL have a startPeriod = 0</td><td>It becomes immediately active upon receipt of the message. (Same as K28.FR.02)</td></tr><tr><td>K29.FR.03</td><td>When Charging Station receives a SetChargingProfileRequest from CSMS with a ChargingProfileType with chargingProfilePurpose = TxProfile or TxDefaultProfile, chargingProfileKind = Dynamic and operationMode = ExternalLimits or ExternalSetpoint</td><td>Charging Station SHALL represent the limit or setpoint that it receives from an external system as the limit or setpoint of this charging profile.</td><td></td></tr><tr><td>K29.FR.04</td><td>NOT K29.FR.03 AND ExternalConstraintsProfileDisallowed is false or absent AND An external system provides a current or power limit (i.e. single value, not a schedule)</td><td>Charging Station SHALL represent this as a ChargingProfileType with a single chargingSchedulePeriod, and having a chargingProfilePurpose = ChargingStationExternalConstraints with a chargingProfileKind = Dynamic.</td><td>The alternative, using a chargingProfileKind = Absolute, is described in K11.FR.06.</td></tr><tr><td>K29.FR.05</td><td>When external system updates a limit AND Charging Station represents this as a Dynamic charging profile</td><td>Charging Station SHALL update the limit or setpoint in this charging profile.</td><td></td></tr><tr><td>K29.FR.06</td><td>K29.FR.05</td><td>Charging Station SHALL set dynUpdateTime in ChargingProfileType to current time.</td><td></td></tr></table>
+
+# L. Firmware Management
+
+# Chapter 1. Introduction
+
+This Functional Block describes the functionality that enables a CSO to update the firmware of a Charging Station.
+
+When a Charging Station needs to be updated with new firmware, the CSMS informs the Charging Station of the time at which the Charging Station can start downloading the new firmware. The Charging Station SHALL notify the CSMS after each step as it downloads and installs the new firmware.
+
+# Chapter 2. Use cases & Requirements
+
+# L01 - Secure Firmware Update
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Secure Firmware Update</td></tr><tr><td>2</td><td>ID</td><td>L01</td></tr><tr><td>3</td><td>Objective(s)</td><td>Download and install a Secure firmware update.</td></tr><tr><td>4</td><td>Description</td><td>Illustrate how a Charging Station processes a Secure firmware update.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends an Update FirmwareRequest message that contains the location of the firmware, the time after which it should be retrieved, and information on how many times the Charging Station should retry downloading the firmware.
+2. The Charging Station verifies the validity of the certificate against the Manufacturer root certificate.
+3. If the certificate is valid AND the retrieveDateTime has passed, the Charging Station starts downloading the firmware, and sends a FirmwareStatusNotificationRequest with status Downloading.
+If the certificate is not valid or could not be verified, the Charging Station aborts the firmware update process and sends a Update FirmwareResponse with status InvalidCertificate and a SecurityEventNotificationRequest with the security event InvalidFirmwareSigningCertificate (See part 2 appendices for the full list of security events).
+4. If the Firmware successfully downloaded, the Charging Station sends a FirmwareStatusNotificationRequest with status Downloaded.
+Otherwise, it sends a FirmwareStatusNotificationRequest with status DownloadFailed.
+5. If the verification is successful AND the installDateTime has passed, the Charging Station sends a FirmwareStatusNotificationRequest with status Installing.
+If the verification of the firmware fails or if a signature is missing entirely, the Charging Station sends a FirmwareStatusNotificationRequest with status InvalidSignature and a SecurityEventNotificationRequest with the security event InvalidFirmwareSignature (See part 2 appendices for the full list of security events).
+6. If the installation is successful, the Charging Station sends a FirmwareStatusNotificationRequest with status Installed.
+Otherwise, it sends a FirmwareStatusNotificationRequest with status InstallationFailed.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>L02 - Non-Secure Firmware Update</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station Manufacturer provided a firmware update.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The firmware is updated and the Charging Station is in Installed status.
+Failure postconditions:
+The certificate is not valid or could not be verified and the Charging Station is in InvalidCertificate status.
+Downloading the firmware failed and the Charging Station is in DownloadFailed status.
+The verification of the firmware's digital signature failed and the Charging Station is in InvalidSignature status.
+The installation of the firmware is not successful and the Charging Station is in InstallationFailed status.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>As an example in this use case the requestId = 123, but this could be any value.Measures SHOULD be taken to secure the firmware when it is stored on a server or workstation.The Charging Station has a required Configuration Variable that reports which file transfer protocols it supports: FileTransferProtocolsWhen migrating to a new version of OCPP it is RECOMMENDED to install a fallback NetworkConnectionProfile with the new configuration.The requirements for the Firmware Signing Certificate are described in the: Certificate Properties section.The manufacturer SHALL NOT use intermediate certificates for the firmware signing certificate in the Charging Station.FTP needs to be able to use Passive FTP, to be able to transverse over as many different typologies as possible.</td></tr></table>
+
+
+Figure 148. Sequence diagram secure firmware upgrade (happy flow)
+
+
+Figure 149. Firmware status transitions
+
+# L01 - Secure Firmware Update - Requirements
+
+Table 121. L01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>L01.FR.01</td><td>Whenever the Charging Station enters a new state in the firmware update process.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest message to the CSMS with this new status. What reason to use is described in the description of FirmwareStatusEnumType.</td><td></td></tr><tr><td>L01.FR.02</td><td>When the Charging Station enters the Invalid Certificate state in the firmware process.</td><td>The Charging Station SHALL send a SecurityEventNotificationRequest message to the CSMS with the security event InvalidFirmwareSigningCertificate (See part 2 appendices for the full list of security events).</td><td></td></tr><tr><td>L01.FR.03</td><td>When the Charging Station enters the Invalid Signature state.</td><td>The Charging Station SHALL send a SecurityEventNotificationRequest message to the CSMS with the security eventInvalid FirmwareSignature (See part 2 appendices for the full list of security events).</td><td></td></tr><tr><td>L01.FR.04</td><td>When the Charging Station has successfully downloaded the new firmware</td><td>The signature SHALL be validated, by calculating the signature over the entire firmware file using the RSA-PSS or ECSchnorr algorithm for signing, and the SHA256 algorithm for calculating hash values.</td><td></td></tr><tr><td>L01.FR.05</td><td>L01.FR.04 AND (installDateTime is not set OR current time >= installDateTime)</td><td>The Charging Station SHALL install the new firmware as soon as it is able to.</td><td></td></tr><tr><td>L01.FR.06</td><td>L01.FR.05 AND The Charging Station has ongoing transactions AND When it is not possible to start installation of firmware while a transaction is ongoing</td><td>The Charging Station SHALL wait until all transactions have ended, before commencing installation.</td><td></td></tr><tr><td>L01.FR.07</td><td>L01.FR.06 or L01.FR.33 AND configuration variable AllowNewSessionsPendingFirmwareUpdate is false or does not exist</td><td>The Charging Station SHALL set all EVSE that are not in use to UNAVAILABLE while the Charging Station waits for the ongoing transactions to end. Until the firmware is installed, any EVSE that becomes available SHALL be set to UNAVAILABLE.</td><td></td></tr><tr><td>L01.FR.08</td><td></td><td>It is RECOMMENDED that the firmware is sent encrypted to the Charging Station. This can either be done by using a secure protocol (such as HTTPS, SFTP, or FTPS) to send the firmware, or by encrypting the firmware itself before sending it.</td><td></td></tr><tr><td>L01.FR.09</td><td></td><td>Firmware updates SHALL be digitally protected to ensure authenticity and to provide proof of origin.</td><td>This protection is achieved by applying a digital signature over the hash value of the firmware image. Ideally, this signature is already computed by the manufacturer. This way proof of origin of the firmware image can be tracked back to the original author of the firmware.</td></tr><tr><td>L01.FR.10</td><td></td><td>Every FirmwareStatusNotificationRequest sent for a firmware update SHALL contain the same requestId as the UpdateFirmwareRequest that started this firmware update.</td><td></td></tr><tr><td>L01.FR.11</td><td></td><td>For security purposes the CSMS SHALL include the Firmware Signing certificate (see Keys used in OCPP) in the UpdateFirmwareRequest.</td><td></td></tr><tr><td>L01.FR.12</td><td></td><td>For verifying the certificate (see Certificate Hierarchy) use the rules for X.509 certificates [19]. The Charging Station MUST verify the file's digital signature using the Firmware Signing certificate.</td><td></td></tr><tr><td>L01.FR.13</td><td>When the Charging Station does not start downloading firmware, because it is busy charging or because retrieveDateTime is in the future</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status DownloadScheduled.</td><td></td></tr><tr><td>L01.FR.14</td><td>When the Charging Station enters the Download Paused state.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status DownloadPaused.</td><td>For example when the Charging Station has tasks with higher priorities.</td></tr><tr><td>L01.FR.15</td><td>When a Charging Station needs to reboot before installing the downloaded firmware.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status InstallRebooting, before rebooting.</td><td></td></tr><tr><td>L01.FR.16</td><td>L01.FR.04 AND When installDateTime is set to a time in the future</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status InstallScheduled and install the firmware at the specified installation time.</td><td></td></tr><tr><td>L01.FR.20</td><td></td><td>The field requestId in FirmwareStatusNotificationRequest is mandatory, unless status = Idle.</td><td></td></tr><tr><td>L01.FR.21</td><td>When the Charging Station receives an UpdateFirmwareRequest</td><td>The Charging Station SHALL validate the certificate before accepting the message.</td><td></td></tr><tr><td>L01.FR.22</td><td>L01.FR.21 AND the certificate is invalid</td><td>The Charging Station SHALL respond with UpdateFirmwareResponse with status InvalidCertificate.</td><td></td></tr><tr><td>L01.FR.23</td><td>When the Charging Station needs to reboot during a firmware update AND the bootloader is unable to send OCPP messages</td><td>The Charging Station MAY omit the FirmwareStatusNotificationRequest message with status Installing.</td><td></td></tr><tr><td>L01.FR.24</td><td>When a Charging Station is installing new Firmware OR is going to install new Firmware, but has received an UpdateFirmware command to install it at a later time AND the Charging Station receives a new UpdateFirmwareRequest</td><td>The Charging Station SHOULD cancel the ongoing firmware update AND respond with status AcceptedCanceled.</td><td>The Charging Station SHOULD NOT first check if the new firmware file exists, this way the CSMS will be able to cancel an ongoing firmware update without starting a new one. The Charging Station may send a FirmwareStatusNotificationRequest with status DownloadFailed or InstallationFailed for the firmware update that has now been canceled.</td></tr><tr><td>L01.FR.25</td><td>Charging Station receives a TriggerMessageRequest for FirmwareStatusNotification AND last sent FirmwareStatusNotificationRequest had status = Installed</td><td>Charging Station SHALL return a FirmwareStatusNotificationRequest with status = Idle.</td><td></td></tr><tr><td>L01.FR.26</td><td>Charging Station receives a TriggerMessageRequest for FirmwareStatusNotification AND last sent FirmwareStatusNotificationRequest had NOT status Installed</td><td>Charging Station SHALL return a FirmwareStatusNotificationRequest with the last sent status.</td><td></td></tr><tr><td>L01.FR.27</td><td>L01.FR.24 AND the Charging Station is unable to cancel the firmware installation</td><td>The Charging Station MAY respond with status = Rejected.</td><td></td></tr></table>
+
+L02 - Non-Secure Firmware Update
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>L01.FR.28</td><td>When the Charging Station has successfully installed the new firmware</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status Installed AND The Charging Station SHOULD have activated the new firmware already or do so immediately.</td><td>Activating the new firmware MAY involve an automatic reboot, but not necessarily so.</td></tr><tr><td>L01.FR.29</td><td>If the verification of the new firmware (e.g. using a checksum or some other means) fails</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status InstallVerificationFailed</td><td></td></tr><tr><td>L01.FR.30</td><td>When the Charging Station has failed all retry attempts to download the firmware.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status DownloadFailed.</td><td>A Charging Station MAY send a new Downloading status upon each retry attempt.</td></tr><tr><td>L01.FR.31</td><td>L01.FR.28</td><td>The Charging Station SHALL send a SecurityEventNotificationRequest message with type = "FirmwareUpdated".</td><td></td></tr><tr><td>L01.FR.32</td><td>When a Charging Station has successfully installed the new firmware AND the Charging Station needs to reboot before activating the new firmware</td><td>The Charging Station SHALL either: (a) send an optional FirmwareStatusNotificationRequest with status = InstallRebooting before rebooting and send a mandatory FirmwareStatusNotificationRequest with status = Installed by the newly activated firmware, or (b) only send a FirmwareStatusNotificationRequest with status set to Installed without reporting the reboot and activation of the new firmware.</td><td>Option (a) is preferred, because it notifies CSMS of an upcoming reboot of the Charging Station, and the final status = Installed is sent by the new firmware image, so that CSMS can be sure that the new firmware is active. This is not guaranteed by option (b) when rebooting of the new firmware should fail.</td></tr><tr><td>L01.FR.33(2.1)</td><td>L01.FR.05ANDThe Charging Station has ongoing transactionsANDa reboot is needed to activate the installed firmware</td><td>The Charging Station SHALL wait until all transactions have ended, before activating the installed firmware.</td><td>E.g. in case of A/B firmware updates. To notify the CSMS when the new firmware is active it is recommended to follow the flow of option (a) in L01.FR.32.</td></tr><tr><td>L01.FR.34</td><td>L01.FR.04 ANDinstallDateTime is not set ANDCharging Station is waiting for a transaction to finish</td><td>The Charging Station MAY send a FirmwareStatusNotificationRequest with status InstallScheduled.</td><td>The case where installDateTime is set is covered by L01.FR.16.</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Non-Secure Firmware Update</td></tr><tr><td>2</td><td>ID</td><td>L02</td></tr><tr><td>3</td><td>Objective(s)</td><td>Download and install a Non-Secure firmware update.</td></tr><tr><td>4</td><td>Description</td><td>Illustrate how a Charging Station processes a Non-Secure firmware update.</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends an UpdateFirmwareRequest message that contains the location of the firmware, the time after which it should be retrieved, and information on how many times the Charging Station should retry downloading the firmware.
+2. The Charging station responds with an UpdateFirmwareResponse.
+3. The Charging station sends a FirmwareStatusNotificationRequest with status Downloading.
+4. The CSMS responds with a FirmwareStatusNotificationResponse.
+5. The Charging station sends a FirmwareStatusNotificationRequest with status Downloaded.
+6. The CSMS responds with a FirmwareStatusNotificationResponse.
+7. The Charging station sends a FirmwareStatusNotificationRequest with status Installing.
+8. The CSMS responds with a FirmwareStatusNotificationResponse.
+9. The Charging station sends a FirmwareStatusNotificationRequest with status Installed.
+10. The CSMS responds with a FirmwareStatusNotificationResponse.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>L01 - Secure Firmware Update</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station Manufacturer provided a firmware update.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+Firmware update was successfully installed.
+Failure postcondition:
+Firmware update failed.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Measures SHOULD be taken to secure the firmware when it is stored on a server or workstation.
+When migrating to a new version of OCPP it is RECOMMENDED to install a fallback NetworkConnectionProfile with the new configuration.
+FTP needs to be able to use Passive FTP, to be able to transverse over as many different typologies as possible.</td></tr></table>
+
+
+Figure 150. Sequence diagram Non-Secure firmware upgrade
+
+# L02 - Non-Secure Firmware Update - Requirements
+
+Table 122. L02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>L02.FR.01</td><td>Whenever the Charging Station enters a new status in the firmware update process.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest message to the CSMS with this new status.</td><td>Same as L01.FR.01</td></tr><tr><td>L02.FR.02</td><td>When the Charging Station has successfully downloaded the new firmware AND (installDateTime is not set OR current time >= installDateTime)</td><td>The Charging Station SHALL install the new firmware as soon as it is able to.</td><td>Same as L01.FR.04 and L01.FR.05</td></tr><tr><td>L02.FR.03</td><td>L02.FR.02 AND The Charging Station has ongoing transactions AND When it is not possible to start installation of firmware while a transaction is ongoing</td><td>The Charging Station SHALL wait until all transactions have ended, before commencing installation.</td><td>Same as L01.FR.06</td></tr><tr><td>L02.FR.04</td><td>L02.FR.03 or L02.FR.22 AND configuration variable AllowNewSessionsPendingFirmwareUpdate is false or does not exist</td><td>The Charging Station SHALL set all EVSE that are not in use to UNAVAILABLE while the Charging Station waits for the ongoing transactions to end. Until the firmware is installed, any EVSE that becomes available SHALL be set to UNAVAILABLE.</td><td>Same as L01.FR.07</td></tr><tr><td>L02.FR.05</td><td></td><td>It is RECOMMENDED that the firmware is sent encrypted to the Charging Station. This can either be done by using a secure protocol (such as HTTPS, SFTP, or FTPS) to send the firmware, or by encrypting the firmware itself before sending it.</td><td>Same as L01.FR.08</td></tr><tr><td>L02.FR.06</td><td></td><td>Every FirmwareStatusNotificationRequest sent for a firmware update SHALL contain the same requestid as the UpdateFirmwareRequest that started this firmware update.</td><td>Same as L01.FR.10</td></tr><tr><td>L02.FR.07</td><td>When the Charging Station does not start downloading firmware, because it is busy charging or because retrieveDateTime is in the future</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status DownloadScheduled.</td><td>Same as L01.FR.13</td></tr><tr><td>L02.FR.08</td><td>When the Charging Station enters the Download Paused state.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status DownloadPaused.</td><td>For example when the Charging Station has tasks with higher priorities. Same as L01.FR.14</td></tr><tr><td>L02.FR.09</td><td>When a Charging Station needs to reboot before installing the downloaded firmware.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status InstallRebooting, before rebooting.</td><td>Same as L01.FR.15</td></tr><tr><td>L02.FR.10</td><td>When the Charging Station has successfully downloaded the new firmware AND installDateTime is set to time in the future</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status InstallScheduled and install the firmware at the specified installation time.</td><td>Same as L01.FR.04 and L01.FR.16</td></tr><tr><td>L02.FR.14</td><td></td><td>The field requestId in FirmwareStatusNotificationRequest is mandatory, unless status = Idle.</td><td>Same as L01.FR.20</td></tr><tr><td>L02.FR.15</td><td>When a Charging Station is installing new Firmware OR is going to install new Firmware, but has received an UpdateFirmware command to install it at a later time AND the Charging Station receives a new UpdateFirmwareRequest</td><td>The Charging Station SHOULD cancel the ongoing firmware update AND respond with status AcceptedCanceled.</td><td>The Charging Station SHOULD NOT first check if the new firmware file exists, this way the CSMS will be able to cancel an ongoing firmware update without starting a new one. Same as L01.FR.24</td></tr><tr><td>L02.FR.16</td><td>Charging Station receives a TriggerMessageRequest for FirmwareStatusNotification AND last sent FirmwareStatusNotificationRequest had status = Installed</td><td>Charging Station SHALL return a FirmwareStatusNotificationRequest with status = Idle.</td><td>Same as L01.FR.25</td></tr><tr><td>L02.FR.17</td><td>Charging Station receives a TriggerMessageRequest for FirmwareStatusNotification AND last sent FirmwareStatusNotificationRequest had NOT status Installed</td><td>Charging Station SHALL return a FirmwareStatusNotificationRequest with the last sent status.</td><td>Same as L01.FR.26</td></tr><tr><td>L02.FR.18</td><td>L02.FR.15 AND the Charging Station is unable to cancel the firmware installation</td><td>The Charging Station MAY respond with status = Rejected.</td><td>Same as L01.FR.27</td></tr><tr><td>L02.FR.19</td><td>When the Charging Station has failed all retry attempts to download the firmware.</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status DownloadFailed.</td><td>A Charging Station MAY send a new Downloading status upon each retry attempt. Same as L01.FR.30</td></tr><tr><td>L02.FR.20</td><td>When the Charging Station has successfully installed and activated the new firmware</td><td>The Charging Station SHALL send a FirmwareStatusNotificationRequest with status Installed.</td><td>Activation of the new firmware may involve a reboot.</td></tr><tr><td>L02.FR.21</td><td>When the Charging Station has successfully installed the new firmware AND the Charging Station needs to reboot before activating the new firmware</td><td>The Charging Station SHALL either: (a) send an optional FirmwareStatusNotificationRequest with status = InstallRebooting before rebooting and send a mandatory FirmwareStatusNotificationRequest with status = Installed by the newly activated firmware, or (b) only send a FirmwareStatusNotificationRequest with status set to Installed without reporting the reboot and activation of the new firmware.</td><td>Option (a) is preferred, because it notifies CSMS of an upcoming reboot of the Charging Station, and the final status = Installed is sent by the new firmware image, so that CSMS can be sure that the new firmware is active. This is not guaranteed by option (b) when rebooting of the new firmware should fail.</td></tr><tr><td>L02.FR.22</td><td>L02.FR.02 AND The Charging Station has ongoing transactions AND a reboot is needed to activate the installed firmware</td><td>The Charging Station SHALL wait until all transactions have ended, before activating the installed firmware.</td><td>E.g. in case of A/B firmware updates.</td></tr><tr><td>L02.FR.23</td><td>When the Charging Station has successfully downloaded the firmware AND installDateTime is not set AND Charging Station is waiting for a transaction to finish</td><td>The Charging Station MAY send a FirmwareStatusNotificationRequest with status InstallScheduled.</td><td>The case where installDateTime is set is covered by L02.FR.10.</td></tr></table>
+
+# L03 - Publish Firmware file on Local Controller
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Publish Firmware file on Local Controller.</td></tr><tr><td>2</td><td>ID</td><td>L03</td></tr><tr><td>3</td><td>Objective(s)</td><td>To allow Charging Stations to download a firmware update directly from the Local Controller.</td></tr><tr><td>4</td><td>Description</td><td>The Local Controller downloads and publishes a firmware update at the specified URL. This allows the CSMS to send UpdateFirmwareRequests with the URI pointing to the Local Controller, to any Charging Station connected to the Local Controller. This allows the site to save bandwidth and data on the WAN interface.</td></tr><tr><td></td><td>Actors</td><td>Local Controller, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a PublishFirmwareRequest to instruct the Local Controller to download and publish the firmware, including an MD5 checksum of the firmware file.2. Upon receipt of PublishFirmwareRequest, the Local Controller responds with PublishFirmwareResponse.3. The Local Controller starts downloading the firmware.4. The Local Controller verifies the MD5 checksum.5. The Local Controller publishes the firmware file at the URI(s) stated in PublishFirmwareStatusNotificationRequest.6. The CSMS instructs Charging Stations to update their firmware, as described in Use Case L01 - Secure Firmware Update</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:The firmware is successfully published by the Local Controller.Failure postcondition:The Local Controller could not download the firmware file, and has sent the DownloadFailed status.The Local Controller could not verify the MD5 checksum, and has sent the InvalidChecksum status.The Local Controller could not publish the firmware file, and has sent the PublishFailed status.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>For information about MD5 checksum see RFC-1321 [RFC1321].</td></tr></table>
+
+
+Figure 151. Sequence Diagram: showing publishing of firmware (happy flow)
+
+# L03 - Publish Firmware file on Local Controller - Requirements
+
+Table 123. L03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>L03.FR.01</td><td></td><td>Whenever the Local Controller enters a new status in the publishing process, it SHALL send a PublishFirmwareStatusNotificationRequest message to the CSMS.</td></tr><tr><td>L03.FR.02</td><td></td><td>The MD5 checksum SHALL be calculated over the entire firmware file.</td></tr><tr><td>L03.FR.03</td><td></td><td>The Local Controller SHALL publish the firmware file using all its supported protocols (e.g. HTTP, HTTPS, and FTP)</td></tr><tr><td>L03.FR.04</td><td></td><td>The Local Controller SHALL set URI's for all supported protocols (e.g. HTTP, HTTPS, and FTP) in the location field of the PublishFirmwareStatusNotificationRequest message with status Published.</td></tr><tr><td>L03.FR.05</td><td>Upon receipt of a PublishFirmwareRequest message.</td><td>The Local Controller SHALL respond with a PublishFirmwareResponse message, indicating whether it has accepted the request.</td></tr><tr><td>L03.FR.06</td><td>If the Local Controller cannot download the firmware file.</td><td>The Local Controller SHALL send a PublishFirmwareStatusNotificationRequest with status DownloadFailed.</td></tr><tr><td>L03.FR.07</td><td>If the Local Controller cannot verify the MD5 checksum.</td><td>The Local Controller SHALL send a PublishFirmwareStatusNotificationRequest with status InvalidChecksum.</td></tr><tr><td>L03.FR.08</td><td>If the Local Controller cannot publish the firmware file.</td><td>The Local Controller SHALL send a PublishFirmwareStatusNotificationRequest with status PublishFailed.</td></tr><tr><td>L03.FR.09</td><td>After successfully publishing the firmware file.</td><td>The Local Controller SHALL send a PublishFirmwareStatusNotificationRequest with status Published.</td></tr><tr><td>L03.FR.10</td><td>Charging Station receives a TriggerMessageRequest for PublishFirmwareStatusNotifi cation AND last sent PublishFirmwareStatusNotificationR equest had status = Published</td><td>Charging Station SHALL return a PublishFirmwareStatusNotificationRequest with status = Idle.</td></tr><tr><td>L03.FR.11</td><td>Charging Station receives a TriggerMessageRequest for PublishFirmwareStatusNotifi cation AND last sent PublishFirmwareStatusNotificationR equest had NOT status Published</td><td>Charging Station SHALL return a PublishFirmwareStatusNotificationRequest with the last sent status.</td></tr></table>
+
+# L04 - Unpublish Firmware file on Local Controller
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Unpublish Firmware file on Local Controller.</td></tr><tr><td>2</td><td>ID</td><td>L04</td></tr><tr><td>3</td><td>Objective(s)</td><td>Stop the Local Controller from publishing a firmware update to Charging Stations.</td></tr><tr><td>4</td><td>Description</td><td>Stop serving a firmware update to connected Charging Stations.</td></tr><tr><td></td><td>Actors</td><td>Local Controller, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends an Unpublish FirmwareRequest to instruct the local controller to unpublished the firmware.
+2. The Local Controller unpublishes the firmware.
+3. The local Controller responds with an Unpublish FirmwareResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A firmware successfully published by the Local Controller.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+Firmware file no longer published.
+Failure postcondition:
+n/a</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The CSMS uses a MD5 checksum over the entire firmware file as a unique identifier to indicate which firmware file needs to be unpublished.</td></tr></table>
+
+
+Figure 152. Sequence Diagram: Unpublishing a firmware file
+
+# L04 - Unpublish Firmware file on Local Controller - Requirements
+
+Table 124. L04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>L04.FR.01</td><td>If the Local Controller receives an UnpublishFirmwareRequest message AND There is no ongoing download.</td><td>The firmware file SHALL be unpublished.</td></tr><tr><td>L04.FR.02</td><td>After successfully unpublished the firmware file.</td><td>The local controller SHALL send an UnpublishFirmwareResponse message with status Unpublished.</td></tr><tr><td>L04.FR.03</td><td>If the Local Controller receives an UnpublishFirmwareRequest message AND There is no published file.</td><td>The Local Controller SHALL send an UnpublishFirmwareResponse message with status NoFirmware.</td></tr><tr><td>L04.FR.04</td><td>If the Local Controller receives an UnpublishFirmwareRequest message AND If a Charging Station is downloading the firmware file.</td><td>The Local Controller SHALL respond with the Downloading status AND not unpublished the firmware file.</td></tr></table>
+
+# M. Certificate Management
+
+# Chapter 1. Introduction
+
+The ISO/IEC JWG 15118 for the Vehicle to Grid Communication Interface (V2G CI) was founded in 2009 with means to the need of a complementary international standard to IEC 61851-1 [IEC61851-1] providing bidirectional digital communication based on Internet protocols. The major purpose of 15118 is to establish a more advanced and autonomously working charge control mechanism between EVs and charging infrastructures. The standard is currently under development and will ultimately provide means for various authentication schemes (e.g. plug charge vs. external identification means, like RFID cards), automatic handling of charging services as well as (proprietary) value added services, charge scheduling and advance planning, etc.
+
+The 15118 standard is of interest to the Open Charge Alliance, as it provides the exchange of charging schedules and enables to control the amount of power that an EV may draw from a Charging Station, in which some form of vehicle to grid communication is necessary. Especially the second part, which specifies the messages to be exchanged between the communication partners (Application Layer), the associated data and data types (Presentation Layer) via TCP/IP based Transport and Network Layer, is important to acknowledge in this specification. The authorization for charging is provided either by External Identification Means (EIM), such as an RFID card, or by the Plug and Charge (PnC) mechanism using a contract certificate stored in the EV, handled by the certificate handling process in use case elements "C", eliminating the need of other authorization means.
+
+This 15118 OCPP Functional Block has been designed to meet a number of alignment objectives:
+
+- To allow the communication between an EV (BEV or a PHEV) and an EVSE.
+ To allow the support of certificate-based authentication and authorization at the Charging Station, i.e. plug and charge.
+
+For illustration purposes: the figure below shows a complete sequence with authorization and scheduling.
+
+# NOTE
+
+To the below figures: these sequences only apply for AC charging, although the certificate handling (which is the focus in this section) does not differ in AC or DC.
+
+
+
+
+Figure 153. Sequence with Authorization and Scheduling with ISO 15118-2
+
+NOTE
+
+The time-out on the ChargeParameterDiscoveryReq is 2 seconds, but this can be prolonged up to 60 seconds to wait for charging profile (SAScheduleList) to be provided by the CSMS. See ISO 15118-2 [ISO15118-2].
+
+
+Figure 154. Sequence for authorization and scheduling with ISO 15118-20
+
+# NOTE
+
+Please note that it is highly RECOMMENDED to use one of the TLS based security profiles from functional block A, not doing this might "break" the ISO 15118 security.
+
+In order to control the amount of power that an EV may draw from a Charging Station, some form of vehicle to grid communication is necessary. OCPP has been designed to support the ISO 15118 standard for communication between the EV and Charging Station (EVSE). However, it is anticipated that for the coming years, the majority of EVs will only support the control pilot PWM signal IEC61851, so care has been taken to support smart charging with this as well.
+
+# NOTE
+
+A mapping of the ISO 15118 and OCPP terminology is provided in ISO 15118 and OCPP terminology mapping and abbreviations used in ISO 15118 are listed in ISO 15118 Abbreviations.
+
+# Chapter 2. ISO 15118 Certificates
+
+# 2.1. ISO 15118 Certificate structure
+
+The ISO 15118 standard provides a Plug & Charge mechanism. This is an identification and authorization mode where the customer just has to plug his electric vehicle into the EVSE and all aspects of authentication, authorization, load control and billing are automatically taken care of without the need for further user interaction. This is facilitated by the application of digital signatures and exchange of X.509 certificates bound to a Public Key Infrastructures (PKI) model.
+
+The PKI structure defined by ISO 15118 is shown in the figure below. In general, four PKIs need to be in place.
+
+- PKI for the Charging Station Operator (CSO)
+- PKI for the Certificate Provisioning Service (CPS)
+- PKI for the Mobility Operator (MO)
+- PKI for the car manufacturer (OEM)
+
+The trust anchor (root CA) for the CSO and CPS is the so-called V2G Root CA. On the other hand, it is up to the respective OEM and MO to operate a Root CA of their own or derive their certificates from a V2G Root CA (indicated by the dotted lines between V2G Root and MO Sub-CA 1 and OEM Sub-CA 1, respectively).
+
+
+Figure 155. PKIs applied for Plug & Charge identification mode
+
+If only one Sub-CA layer is used, i.e. a Sub-CA signed by a Root CA directly signs leaf certificates, the profile of Sub-CA 2 shall apply for that Sub-CA (Source: ISO15118-2)
+
+OCPP needs to make sure that the necessary information can be exchanged between the EV, the Charging Station and a backend IT infrastructure to facilitate the contract provisioning. Contract provisioning is a process defined within ISO 15118 that describes how an EV can retrieve a valid contract certificate during a communication session in order to authenticate and authorize itself for the charging process.
+
+Given the PKI structure in the figure above, OCPP must provide messages which are able to transmit the following certificates:
+
+- CPS certificate chain
+
+Comprised of Prov Sub-CA 1, Prov Sub-CA 2 and leaf provisioning certificate. Sent with the CertificateInstallationRes and CertificateUpdateRes message.
+
+MO certificate chain
+
+Comprised of MO Sub-CA 1, MO Sub-CA 2 and contract certificate. Sent with the messages CertificateInstallationRes, CertificateUpdateReq, and CertificateUpdateRes.
+
+OEM provisioning certificate
+
+Sent with the CertificateInstallationReq message.
+
+Furthermore, some ISO 15118 messages require digital XML-based signatures. Those signatures need to be validated by the receiving party by using the corresponding certificate chain and verifying the chain of signatures all the way up to the respective
+
+trust anchor (V2G root, MO root or OEM root). Table 13 on page 45 of ISO15118-2 provides an overview of applied XML-based signatures in ISO 15118. As you can see in there, the Charging Station (EVSE is part of a Charging Station) needs to verify the signature of the following messages.
+
+# - AuthorizationReq
+
+Certificate chain needed to verify signature is provided with PaymentDetailsReq.
+
+# - MeteringReceipts
+
+Certificate chain needed to verify signature is provided with PaymentDetailsReq.
+
+# CertificateUpdateReq
+
+Certificate chain needed to verify signature is provided with this message.
+
+The signature verification as well as the check of the validity of each certificate provided by the EV can be done offline. These three messages are signed with the private key belonging to the public key of the contract certificate that is installed in the EV. The CSO needs to make sure that the corresponding MO root CA certificate (MO trust anchor) is installed on the Charging Station to enable signature verification offline (the chain of contract certificates and sub-CA certificates is already fulfilled by the EV in the PaymentDetailsReq message so only the MO root CA is required).
+
+The PaymentDetailsReq message is sent before the AuthorizationReq and MeteringReceiptReq message. Therefore, the Charging Station must temporarily save the certificate chain provided with the PaymentDetailsReq message as long as the current transaction is active in order to be able to verify the signature created by the EV. After the transaction has been terminated, the temporarily saved certificate chain must be deleted on the Charging Station side.
+
+Please note that the Charging Station only needs to check the contract certificate upon the receipt of the PaymentDetailsReq message from the EV which delivers the ContractSignatureCertChain, containing the contract certificate and possible sub-CA certificates, excluding the root CA certificate. However, it does not need to check the contract certificate upon installation or update of the contract certificate, upon delivery to the EV.
+
+On the contrary, the signature provided with the CertificateInstallationReq needs to be verified by a so-called secondary actor, a market stakeholder communicating with the CSO backend. This means that OCPP needs to provide means for transmitting the complete CertificateInstallationReq message.
+
+The CertificateUpdateRes and CertificateInstallationRes need to be sent from the CSO backend to the charging station as Base64 encoded binary data. The Charging Station removes the Base64 encoding and sends it to the EV as a binary EXI message.
+
+Finally, the Charging Station certificate (labelled as EVSE Leaf Certificate in figure 1) together with its private key is used to establish a secure connection between EV and EVSE via TLS. According to ISO 15118, this certificate should be valid for only 2 to 3 months. To install or update the Charging Station certificate, please refer to Certificate installation Charging Station.
+
+While the Charging Station can verify the signature and validity period of each certificate in the MO contract certificate chain offline, there are two things which the Charging Station cannot verify offline:
+
+# 1. The authorization status of the EMAID
+
+The EMAID is a unique identifier issued by the MO together with the contract certificate. Therefore, only the MO can provide information on whether the user is authorized for charging based on this EMAID or not. The Charging Station needs to forward the EMAID to the CSO after having checked that the signature of each certificate in the contract certificate chain is valid. This order of steps is necessary because the contract certificate protects the EMAID against manipulation by means of the digital signature of its issuer. The Charging Station could also work with a white list of EMAIDs cached locally. However, white lists need to be frequently updated to ensure that the authorization information used is not outdated.
+
+# 2. The revocation status of each certificate
+
+Reasons for revoking a certificate are e.g. that the private key belonging to the public key of a certificate has been corrupted or that the algorithm used to create a signature is not considered to be secure anymore. Revocation status is checked using an OCSP responder whose address is given as an attribute value of an X.509 certificate.
+
+# 2.2. Using ISO 15118 Certificates in OCPP
+
+From an OCPP perspective, based on the above paragraph, the Charging Station needs to have one or more of each of the following certificate types:
+
+<table><tr><td>Type</td><td>Description</td></tr><tr><td>V2GChargingStation Certificate</td><td>Certificate of the Charging Station. In 15118 this is called the SECC Certificate (or EVSE Leaf Certificate). This certificate is used during the set-up of the TLS connection between the Charging Station and the EV.</td></tr><tr><td>V2GRootCertificate</td><td>Certificate of the ISO15118 V2G Root. The V2G Charging Station Certificate MUST BE derived from this root.</td></tr><tr><td>MORootCertificate</td><td>Certificate from an eMobility Service provider. To support PnC charging with contracts from service providers that not derived their certificates from the V2G root.</td></tr></table>
+
+# NOTE
+
+The V2G Charging Station Certificate might be the same as the certificate used for securing the connection between the Charging Station and the CSMS. For this to work, this certificate MUST BE to be derived from a V2G Root.
+
+A Contract Certificate can be derived from a V2G root, or an eMobility root. This means the Charging Station needs to be in possession of the corresponding root certificate to be able to authenticate the driver by means of the Contract Certificate and the associated certificate chain.
+
+# NOTE
+
+When a Charging Station is online this does not have to be the case, because it can send an AuthorizationRequest message with the Contract Certificate to be validated by the CSMS.
+
+The V2G Charging Station Certificate needs to be derived from a V2G root. If this root is not known by the EV, no connection via 15118 is possible, so charging controlled by 15118 is NOT possible. In the event a Charging Station needs to support more than one V2G root, multiple V2G Charging Station Certificates are needed.
+
+# 2.3. 15118 communication set-up
+
+At the beginning of a 15118 communication session the EV will initiate a TLS Connection. In this request, the car presents its known V2G root certificates.
+
+During the TLS handshake, the EVCC can request the OCSP status of the Charging Station and intermediate certificates using OCSP stapling as defined in IETF RFC 6961. The Charging Station can retrieve this information by sending a GetCertificateStatusRequest to the CSMS, see use case M06 - Get Charging Station Certificate status.
+
+
+Figure 156. Communication set-up
+
+# 2.4. Certificate - Use Case mapping
+
+The following table contains the use cases that can be used to manage the certificates needed for ISO 15118 charging from OCPP:
+
+Table 125. Certificates relevant for 15118
+
+<table><tr><td>Certificate</td><td>Used for</td><td>Use Case</td><td>Remark</td></tr><tr><td>ChargingStationCertificate</td><td>Charging Station - CSMS connection</td><td>A02 and A03</td><td>Used for OCPP security in general. Certificate chain must also be available and can be retrieved by the Charging Station when installing the certificate.</td></tr><tr><td>CPS Certificate Chain</td><td>Plug & Charge authentication</td><td>M03, M04 and M05</td><td></td></tr><tr><td>EVContractCertificate</td><td>Plug & Charge authentication</td><td>M01 and M02</td><td>Shorter life time certificate (for plug & charge)</td></tr><tr><td>MORootCertificate</td><td>Plug & Charge authentication</td><td>M03, M04 and M05</td><td></td></tr><tr><td>MO Certificate Chain</td><td>Plug & Charge authentication</td><td>N.a.</td><td>It is only necessary to install MO root certificate for Plug & Charge authentication, other intermediate certificates are offered by the EV</td></tr><tr><td>OEMProvisioningCertificate</td><td>Installing Certificates in the EV</td><td>M01 and M02</td><td>Long life time installed in EV by OEM</td></tr><tr><td>V2GChargingStationCertificate</td><td>EV - Charging Station TLS connection</td><td>A02 and A03</td><td>Certificate chain must also be available and can be retrieved by the Charging Station when installing the certificate.</td></tr><tr><td>V2GRootCertificate</td><td>EV - Charging Station TLS connection</td><td>M03, M04 and M05</td><td>It is only necessary to install a V2G root certificate for Plug & Charge authentication.</td></tr><tr><td>V2GIntermediateCertificate</td><td>Plug & Charge authentication</td><td>A02, A03, M03 and M04</td><td>Intermediate certificates between the V2GChargingStationCertificate and V2GRootCertificate. May be used during TLS setup between EV and Charging Station.</td></tr></table>
+
+# Chapter 3. Use cases from ISO 15118 relevant for OCPP
+
+See ISO15118-1 page 17 for a list of all elementary use cases. The bold indicated use case component are identified as of influence of the OCPP communication following ISO15118-1.
+
+Table 126. 15118 use cases relevant for OCPP (Source original table: ISO15118-1)
+
+<table><tr><td>No.</td><td>Use case element name / grouping</td></tr><tr><td>A1</td><td>Begin of charging process with forced High Level Communication</td></tr><tr><td>A2</td><td>Begin of charging process with concurrent IEC61851-1 and High Level Communication</td></tr><tr><td>B1</td><td>EV/Charging Station communication setup</td></tr><tr><td>C1</td><td>Certificate update</td></tr><tr><td>C2</td><td>Certificate installation</td></tr><tr><td>D1</td><td>Authorization using Contract Certificates performed at the EVSE</td></tr><tr><td>D2</td><td>Authorization using Contract Certificates performed with help of SA</td></tr><tr><td>D3</td><td>Authorization at EVSE using external credentials performed at the EVSE</td></tr><tr><td>D4</td><td>Authorization at EVSE using external credentials performed with help of SA</td></tr><tr><td>E1</td><td>AC charging with load leveling based on High Level Communication</td></tr><tr><td>E2</td><td>Optimized charging with scheduling to Secondary Actor</td></tr><tr><td>E3</td><td>Optimized charging with scheduling at EV</td></tr><tr><td>E4</td><td>DC charging with load leveling based on High Level Communication</td></tr><tr><td>E5</td><td>Resume to Authorized Charge Schedule</td></tr><tr><td>F0</td><td>Charging loop</td></tr><tr><td>F1</td><td>Charging loop with metering information exchange</td></tr><tr><td>F2</td><td>Charging loop with interrupt from the Charging Station</td></tr><tr><td>F3</td><td>Charging loop with interrupt from the EV or user</td></tr><tr><td>F4</td><td>Reactive power compensation</td></tr><tr><td>F5</td><td>Vehicle to grid support</td></tr><tr><td>G1</td><td>Value added services</td></tr><tr><td>G2</td><td>Charging details</td></tr><tr><td>H1</td><td>End of charging process</td></tr></table>
+
+# NOTE
+
+Not all 15118 related OCPP use cases are described in this functional block. This functional block describes installing and updating certificates in the EV and CA certificate handling (also for non 15118 related purposes). Please refer to ISO 15118 Authorization for the authorization related use cases. The Smart Charging related use cases are described in the section 5.3. ISO 15118 based Smart Charging.
+
+# Chapter 4. Use cases & Requirements
+
+# M01 - Certificate installation EV
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Certificate Installation</td></tr><tr><td>2</td><td>ID</td><td>M01</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 C2</td></tr><tr><td>3</td><td>Objective(s)</td><td>To install a new certificate from the CSMS in the EV.</td></tr><tr><td>4</td><td>Description</td><td>The EV initiates installing a new certificate. The Charging Station forwards the request for a new certificate to the CSMS.See also ISO15118-1, use case Description C2, page 22.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>15118:See ISO15118-1, use case Description C2, Scenario Description, first 3 bullets, page 22.OCPP:- The Charging Station sends Get15118EVCertificateRequest message with action = Install to the CSMS.- The CSMS responds with Get15118EVCertificateResponse to the Charging Station.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>n/a</td></tr><tr><td>5</td><td>Prerequisites</td><td>- Communication between EV and EVSE SHALL be established successfully.- Online connection between Charging Station and CSMS SHALL be possible.- CSMS should be able to communicate with a third party that can process the CertificateInstallationRequest, for example a contract certificate pool.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>See ISO15118-1, use case End conditions C2, page 23.</td></tr><tr><td>7</td><td>Error handling</td><td>In case the CSMS is not able to respond within the specified time, the Charging Station SHALL indicate failure to the EV.</td></tr><tr><td>8</td><td>Remark(s)</td><td>The message timeout in ISO15118-2 for CertificateInstallationReq is 5 seconds.There may be alternative communication paths for doing a certificate installation. However, these are outside the scope of this standard.</td></tr></table>
+
+
+Figure 157. Certificate installation with ISO 15118-2
+
+
+Figure 158. Getting multiple contract certificates with ISO 15118-20
+
+Source: ISO15118-1
+
+# M01 - Certificate installation - Requirements
+
+Table 127. M01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>M01.FR.01</td><td>Upon receiving an ISO 15118 CertificateInstallationReq</td><td>The Charging Station SHALL forward the request to the CSMS using the Get15118EVCertificateRequest message with action = Install.</td><td>The CSMS is responsible for forwarding it to the secondary actor which will process the CertificateUpdateRequest. This could be a contract certificate pool as outlined in application guide VDE-AR-2802-100-1.</td></tr><tr><td>M01.FR.02 (2.1)</td><td>When EV uses ISO 15118-2</td><td>Charging Station SHALL NOT include the field maximumContractCertificateChains in the Get15118EVCertificateRequest message.</td><td></td></tr></table>
+
+M02 - Certificate Update EV
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>M01.FR.03(2.1)</td><td>When EV uses ISO 15118-20</td><td>Charging Station SHALL set field maximumContractCertificateChains in the Get15118EVCertificateRequest to the value of MaximumContractCertificateChains in the ISO 15118-20 CertificateInstallationReq message.</td><td></td></tr><tr><td>M01.FR.04(2.1)</td><td>When maximumContractCertificateChains is present in Get15118EVCertificateRequest AND CSMS has received all CertificatInstallationRes responses from the contract certificate pool(s)</td><td>CSMS SHALL return the first CertificateInstallationRes response and the total number of available contracts in remainingContracts in Get15118EVCertificateResponse.</td><td>Presence of field maximumContractCertificateChains means that this is for ISO 15118-20.</td></tr><tr><td>M01.FR.05(2.1)</td><td>When EV uses ISO 15118-20 AND Upon receiving a Get15118EVCertificateResponse from CSMS</td><td>Charging station SHALL update the value of RemainingContractCertificateChains in the ISO 15118-20 CertificateInstallationRes message to EV to the value of remainingContracts of the OCPP Get15118EVCertificateResponse message.</td><td></td></tr><tr><td>M01.FR.06(2.1)</td><td>When EV uses ISO 15118-20 AND As long as remainingContracts in Get15118EVCertificateResponse is larger than 0</td><td>Charging station SHALL send the same Get15118EVCertificateRequest to CSMS</td><td>CSMS will send the next CertificateInstallationRes in the Get15118EVCertificateResponse.</td></tr><tr><td>M01.FR.07(2.1)</td><td>When EV uses ISO 15118-20 AND M01.FR.06</td><td>CSMS SHALL return the next CertificateInstallationRes and decrease the value of remainingContracts in Get15118EVCertificateResponse by 1.</td><td></td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Certificate Update</td></tr><tr><td>2</td><td>ID</td><td>M02</td></tr><tr><td></td><td>Reference</td><td>ISO15118-1 C1</td></tr><tr><td>3</td><td>Objective(s)</td><td>See ISO15118-1, use case Objective C1, page 20.</td></tr><tr><td>4</td><td>Description</td><td>See ISO15118-1, use case Description C1, page 21 up to and including the third "NOTE".</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>15118:See ISO15118-1, use case Objective C1, Scenario Description, first 3 bullets, page 21.OCPP:- The Charging Station sends a Get15118EVCertificateRequest message with action = update to the CSMS.- The CSMS responds with Get15118EVCertificateResponse to the Charging Station.15118:See ISO15118-1, use case Description C1, Scenario Description, last 2 bullets, page 21.</td></tr><tr><td>5</td><td>Prerequisites</td><td>- Communication between EV and EVSE SHALL be established successfully.
+- Online connection between Charging Station and CSMS SHALL be possible.
+- CSMS should be able to communicate with a third party that can process the CertificateInstallationRequest, for example a contract certificate pool.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>See ISO15118-1, use case Objective C1 and C2, page 20/22.</td></tr><tr><td>7</td><td>Error handling</td><td>In case the CSMS is not able to respond within the specified time, the Charging Station SHALL indicate failure to the EV.</td></tr><tr><td>8</td><td>Remark(s)</td><td>See ISO15118-1, use case Requirements C1, trigger, page 21.
+The message timeout in ISO15118-2 for CertificateUpdateReq is 5 seconds.</td></tr></table>
+
+
+Figure 159. Certificate Update
+
+Source: ISO15118-1
+
+# M02 - Certificate Update - Requirements
+
+Table 128. M02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>M02.FR.01 (2.1)</td><td>Upon receiving an ISO 15118 CertificateUpdateReq AND EV uses ISO 15118-2</td><td>Charging Station SHALL forward the request to the CSMS using the Get15118EVCertificateRequest message with action = update.</td><td>The CSMS is responsible for forwarding it to the secondary actor which will process the CertificateUpdateRequest. This could be a contract certificate pool as outlined in application guide VDE-AR-E 2802-100-1.</td></tr><tr><td>M02.FR.02 (2.1)</td><td>Upon receiving an ISO 15118 CertificateUpdateReq AND EV uses ISO 15118-20</td><td>Charging Station SHALL act according to use case M01</td><td>ISO 15118-20 does not differentiate between Install and Update anymore.</td></tr></table>
+
+# M03 - Retrieve list of available certificates from a Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Retrieve list of available certificates from a Charging Station</td></tr><tr><td>2</td><td>ID</td><td>M03</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to retrieve a list of available certificates from a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>To facilitate the management of the Charging Station's installed certificates, a method of retrieving the installed certificates is provided. The CSMS requests the Charging Station to send a list of installed certificates</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS requests the Charging Station to send a list of installed certificates by sending a GetInstalledCertificatesRequest
+2. The Charging Station responds with a GetInstalledCertificatesResponse</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS received a list of installed certificates</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>For installing the (V2G) Charging Station Certificate, see use cases A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station. The V2G certificate chain SHOULD NOT include the V2GRootCertificate. This SHOULD be installed using Use case M05 - Install CA certificate in a Charging Station.</td></tr></table>
+
+
+Figure 160. Retrieve list of available certificates from a Charging Station
+
+# M03 - Retrieve list of available certificates from a Charging Station - Requirements
+
+Table 129. M03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>M03.FR.01</td><td>After receiving a GetInstalledCertificatesRequest</td><td>The Charging Station SHALL respond with a GetInstalledCertificatesResponse.</td></tr><tr><td>M03.FR.02</td><td>M03.FR.01 AND No certificate matching certificateType was found</td><td>The Charging Station SHALL indicate this by setting status in the GetInstalledCertificatesResponse to NotFound.</td></tr><tr><td>M03.FR.03</td><td>M03.FR.01 AND A certificate matching certificateType was found</td><td>The Charging Station SHALL indicate this by setting status in the GetInstalledCertificatesResponse to Accepted.</td></tr><tr><td>M03.FR.04</td><td>M03.FR.03</td><td>The Charging Station SHALL include the hash data for each matching installed certificate in the GetInstalledCertificatesResponse.</td></tr><tr><td>M03.FR.05</td><td>When the Charging Station receives a GetInstalledCertificatesRequest with certificateType V2GCertificateChain</td><td>The Charging Station SHALL include the hash data for each installed certificate belonging to a V2G certificate chain. Sub CA certificates SHALL be placed as a childCertificate under the V2G Charging Station certificate.</td></tr></table>
+
+# M04 - Delete a specific certificate from a Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Delete a specific certificate from a Charging Station</td></tr><tr><td>2</td><td>ID</td><td>M04</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to request the Charging Station to delete an installed certificate.</td></tr><tr><td>4</td><td>Description</td><td>To facilitate the management of the Charging Station's installed certificates, a method of deleting an installed certificate is provided. The CSMS requests the Charging Station to delete a specific certificate.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS requests the Charging Station to delete an installed certificate by sending a DeleteCertificateRequest.
+2. The Charging Station responds with a DeleteCertificateResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The requested certificate was deleted from the Charging Station.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>For installing the (V2G) Charging Station Certificate, see use cases A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station. The V2G certificate chain SHOULD NOT include the V2GRootCertificate. This SHOULD be installed using Use case M05 - Install CA certificate in a Charging Station.
+It is possible to delete the last (every) installed CSMSRootCertificates. When all CSMSRootCertificates are deleted, the Charging Station cannot validate CSMS Certificates, so it will not be able to connect to a CSMS. Before a CSMS would ever send a DeleteCertificateRequest that would delete the last/all CSMSRootCertificates the CSMS is ADVISED to make very sure that this is what is really wanted.
+It is possible to delete the last (every) installed ManufacturerRootCertificates, when all ManufacturerRootCertificates are deleted, no "Signed Firmware" can be installed in the Charging Station.</td></tr></table>
+
+
+Figure 161. Delete Installed Certificate
+
+# M04 - Delete a specific certificate from a Charging Station - Requirements
+
+Table 130. M04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>M04.FR.01</td><td>After receiving a DeleteCertificateRequest</td><td>The Charging Station SHALL respond with a DeleteCertificateResponse.</td><td></td></tr><tr><td>M04.FR.02</td><td>M04.FR.01 AND The requested certificate was found</td><td>The Charging Station SHALL attempt to delete it, and indicate success by setting status to Accepted in the DeleteCertificateResponse.</td><td></td></tr><tr><td>M04.FR.03</td><td>M04.FR.01 AND (The deletion fails OR the Charging Station rejects the request to delete the specified certificate.)</td><td>The Charging Station SHALL indicate failure by setting status to Failed in the DeleteCertificateResponse.</td><td>A Charging Station may reject the request to prevent the deletion of a certificate, if it is the last one from its certificate type.</td></tr><tr><td>M04.FR.04</td><td>M04.FR.01 AND The requested certificate was not found</td><td>The Charging Station SHALL indicate failure by setting status to NotFound in the DeleteCertificateResponse.</td><td></td></tr><tr><td>M04.FR.06</td><td>M04.FR.01 AND When certificateData refers to the Charging Station Certificate (see use case A)</td><td>Charging Station SHALL respond with DeleteCertificateReponse with status = Failed.</td><td>Deletion of the Charging Station Certificate is not allowed via DeleteCertificateRequest.</td></tr><tr><td>M04.FR.07</td><td>When deleting a certificate</td><td>The CSMS SHALL use the same hashAlgorithm as the Charging Station uses to report the certificateHashData for the certificate in the GetInstalledCertificatesResponse.</td><td>This ensures CSMS uses a hashAlgorithm that is supported by the Charging Station.</td></tr></table>
+
+M05 - Install CA certificate in a Charging Station
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>M04.FR.08</td><td>M04.FR.02 AND Certificate to delete is a sub-CA or root certificate</td><td>Charging Station MAY also delete all child certificates.</td><td>Else these child certificates remain as unusable orphan certificates that can no longer be deleted.</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Install CA certificate in a Charging Station</td></tr><tr><td>2</td><td>ID</td><td>M05</td></tr><tr><td>3</td><td>Objective(s)</td><td>To facilitate the management of the Charging Station's installed certificates, a method to install a new CA certificate.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS requests the Charging Station to install a new CSMS root certificate, an eMobility Operator root certificate, Manufacturer root certificate, or a V2G root certificate.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS requests the Charging Station to install a new certificate by sending an InstallCertificateRequest.
+2. The Charging Station responds with an InstallCertificateResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The new certificate was installed in the Charging Station trust store.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Even though the messages CertificateSignedRequest (see use cases A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station) and InstallCertificateRequest (use case M05) are both used to send certificates, their purposes are different. CertificateSignedRequest is used to return the the Charging Stations own public certificate and V2G certificate(s) signed by a Certificate Authority. InstallCertificateRequest is used to install Root certificates.
+For installing the (V2G) Charging Station Certificate, see use cases A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station. The V2G certificate chain SHOULD NOT include the V2GRootCertificate. This SHOULD be installed using this use case.
+It is allowed to have multiple certificates of the same type installed.</td></tr></table>
+
+
+Figure 162. Install CA certificate in a Charging Station
+
+# M05 - Install CA certificate in a Charging Station - Requirements
+
+Table 131. M05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>M05.FR.01</td><td>After receiving an InstallCertificateRequest</td><td>The Charging Station SHALL attempt to install the certificate and respond with an InstallCertificateResponse.</td></tr><tr><td>M05.FR.02</td><td>M05.FR.01 AND The installation was successful</td><td>The Charging Station SHALL indicate success by setting status to Accepted in the InstallCertificateResponse.</td></tr><tr><td>M05.FR.03</td><td>M05.FR.01 AND The installation failed</td><td>The Charging Station SHALL indicate failure by setting status to Failed in the InstallCertificateResponse.</td></tr><tr><td>M05.FR.06</td><td>When a new certificate gets installed AND the CertificateEntries.maxLimit is going to be exceeded</td><td>The Charging Station SHALL respond with status = Rejected.</td></tr><tr><td>M05.FR.07</td><td>M05.FR.01 AND The certificate is invalid.</td><td>The Charging Station SHALL indicate rejection by setting status to Rejected in the InstallCertificateResponse.</td></tr><tr><td>M05.FR.09</td><td>When AdditionalRootCertificateCheck is true</td><td>Only one certificate (plus a temporarily fallback certificate) of certificateType CSMSRootCertificate is allowed to be installed at a time.</td></tr><tr><td>M05.FR.10</td><td>When AdditionalRootCertificateCheck is true AND installing a new certificate of certificateType CSMSRootCertificate</td><td>The new CSMS Root certificate SHALL replace the old CSMS Root certificate AND the new Root Certificate MUST be signed by the old Root Certificate it is replacing</td></tr><tr><td>M05.FR.11</td><td>M05.FR.10 AND the new CSMS Root certificate is NOT signed by the old CSMS Root certificate</td><td>The Charging Station SHALL NOT install the new CSMS Root Certificate and respond with status = Rejected.</td></tr><tr><td>M05.FR.12</td><td>M05.FR.10 AND the new CSMS Root certificate is signed by the old CSMS Root certificate</td><td>The Charging Station SHALL install the new CSMS Root Certificate AND temporarily keep the old CSMS Root certificate as a fallback certificate AND respond with status = Accepted</td></tr><tr><td>M05.FR.13</td><td>M05.FR.12 AND the Charging Station successfully connected to the CSMS using the new CSMS Root certificate</td><td>The Charging Station SHALL remove the old CSMS Root (fallback) certificate.</td></tr><tr><td>M05.FR.14</td><td>M05.FR.12 AND The Charging Station is attempting to reconnect to the CSMS (NOT migrating to another CSMS with Use Case B10 - Migrate to new CSMS), but determines that the server certificate provided by the CSMS is invalid when using the new CSMS Root certificate to verify it</td><td>The Charging Station SHALL try to use the old CSMS Root (fallback) certificate to verify the server certificate.</td></tr><tr><td>M05.FR.15</td><td>M05.FR.12 AND When the Charging Station is migrating to another CSMS with Use Case B10 - Migrate to new CSMS, but determines that the server certificate provided by the CSMS is invalid when using the new CSMS Root certificate to verify it</td><td>The Charging Station SHALL use the NetworkProfileConnectionAttempts mechanism as described at Use Case B10 - Migrate to new CSMS.</td></tr><tr><td>M05.FR.16</td><td>M05.FR.15 AND If after the number of attempts the connection fails AND If it goes back to the old NetworkConnectionProfile (See B10.FR.03)</td><td>The Charging Station SHALL use the old CSMS Root (fallback) certificate to verify the server certificate.</td></tr><tr><td>M05.FR.17</td><td>NOT M05.FR.10 AND After receiving an InstallCertificateRequest for a certificate that is already present in the certificate trust store of the Charging Station</td><td>The Charging Station SHALL replace the certificate and respond with InstallCertificateResponse with status = Accepted.</td></tr></table>
+
+# M06 - Get V2G Charging Station Certificate status
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get V2G Charging Station Certificate status</td></tr><tr><td>2</td><td>ID</td><td>M06</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable a Charging Station to cache the OCSP certificate status needed for the TLS handshake between EV and Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>When the cable gets plugged in and an ISO 15118 supported EV gets connected to the Charging Station, the EV requests the Charging Station to prove the validity of the (SubCA) certificates by an OCSPResponse. A request needs to be sent per SubCA. Because the timeout constraint in ISO 15118 is too strict to make the call to an external server, OCPP requires to cache the OCSP certificate status of the certificates beforehand. The Charging Station needs to refresh the cached OCSP data once a week..</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station requests the CSMS to provide OCSP certificate status by sending a GetCertificateStatusRequest.
+2. The CSMS responds with a GetCertificateStatusResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+The Charging Station received the OCSP certificate status for the requested certificate
+Failure postcondition:
+The retrieval of the OCSP certificate status by the CSMS failed</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>The status indicator in the GetCertificateStatusResponse indicates whether or not the CSMS was successful in retrieving the certificate status. it does NOT indicate the validity of the certificate.
+For installing the (V2G) Charging Station Certificate, see use cases A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station. The V2G certificate chain SHOULD NOT include the V2GRootCertificate. This SHOULD be installed using Use case M05 - Install CA certificate in a Charging Station.
+OCPP allows for only one certificate per GetCertificateStatusRequest. Because when multiple answers on a GetCertificateStatusRequest are to be expected, it makes handling the request and status more complex. So a GetCertificateStatusRequest needs to be sent per SubCA.
+responderURL is required in OCPP, while it is optional in ISO 15118. Without a responderURL in a certificate it cannot work, so a responderURL is required for any certificate for which a GetCertificateStatusRequest can be expected.</td></tr></table>
+
+
+Figure 163. Get V2G Charging Station Certificate status
+
+# M06 - Get V2G Charging Station Certificate status - Requirements
+
+Table 132. M06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>M06.FR.01</td><td>After receiving a GetCertificateStatusRequest</td><td>The CSMS SHALL respond with a GetCertificateStatusResponse.</td></tr><tr><td>M06.FR.02</td><td>M06.FR.01ANDThe CSMS was successful in retrieving the OCSP certificate status</td><td>The CSMS SHALL indicate success by setting status to Accepted in the GetCertificateStatusResponse.</td></tr><tr><td>M06.FR.03</td><td>M06.FR.02</td><td>The CSMS SHALL include the OCSP response data in the OCSPResult field in the GetCertificateStatusResponse.</td></tr><tr><td>M06.FR.04</td><td>M06.FR.01ANDThe CSMS was not successful in retrieving the OCSP certificate status</td><td>The CSMS SHALL indicate it was not successful by setting status to Failed in the GetCertificateStatusResponse.</td></tr><tr><td>M06.FR.06</td><td></td><td>The Charging Station SHALL request and cache the OCSP status for its V2G certificates.</td></tr><tr><td>M06.FR.07</td><td></td><td>After the Charging Station Certificate has been updated, The Charging Station SHALL refresh the cached OCSP data by sending a GetCertificateStatusRequest for the new certificate, and also for the intermediate certificates.</td></tr><tr><td>M06.FR.08</td><td></td><td>The CSMS SHALL format the response data according to OCSPResponse as defined in IETF RFC 6960, formatted according to ASN.1 [X.680].</td></tr><tr><td>M06.FR.09</td><td></td><td>The OCSPResponse data SHALL be DER encoded.</td></tr><tr><td>M06.FR.10</td><td></td><td>The Charging Station SHALL refresh the cached OCSP data at least once a week.</td></tr></table>
+
+# M07 - Get Vehicle Certificate Chain Revocation Status
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Vehicle Certificate Chain Revocation Status</td></tr><tr><td>2</td><td>ID</td><td>M07</td></tr><tr><td>3</td><td>Objective(s)</td><td>To let Charging Station check validity of the vehicle certificate chain using OCSP and certificate revocation lists.</td></tr><tr><td>4</td><td>Description</td><td>Charging Station requests CSMS to check whether certificates are revoked. Depending on the information in the certificate, this requires checking via OCSP ("Authority Info Access" field in certificate) or CRL ("CRL Distribution Points" field).This check is required by ISO 15118-20 during the TLS handshake. The results are allowed to be cached at CSMS or Charging Station for at most one week by ISO 15118-20.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. Charging Station sends a GetCertificateChainStatusRequest with a list of certificates that need to be validated via an OCSP request and/or via their certificate revocation list.2 For each certificate, CSMS first checks the status in cached data from earlier OCSP or CRL checks, less than a week old.3 If the certificate is not present in the cached status information, CSMS will issue an OCSP request or download the CRL.4 CSMS responds with a GetCertificateChainStatusResponse with the result for each certificate.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>When the request is successful the response contains the status for each certificate.</td></tr><tr><td>7</td><td>Error handling</td><td>If (part of) the request is not successful, the status of the certificates for which no status could be retrieved is Failed.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Charging Stations that have unrestricted access to the internet might be able to fetch a CRL from a CRL distribution point themselves.</td></tr></table>
+
+
+Figure 164. Request Certificate Revocation List from CSMS
+
+Request for two certificates
+
+```txt
+GetCertificateChainStatusRequest { "certificateStatusRequests": [ }
+```
+
+Response
+
+```json
+"certificateHashData": { "hashAlgorithm": "SHA256" "issuerNameHash": "12345ABCDE", "issuerKeyHash": "ABCDE1234", "serialNumber": "00123456789" }, "source": "OCSP", "urls": [ "https://ocsp.responder.org/revoked.ocsp"] }, { "certificateHashData": { "hashAlgorithm": "SHA256" "issuerNameHash": "ABCDE12345", "issuerKeyHash": "1234ABCDE", "serialNumber": "987634294239" }, "source": "CRL", "urls": [ "https://crls.com/revoked.crl", "ftp://ftp.crls.com/revoked.crl"] } ] }
+```
+
+```jsonl
+GetCertificateChainStatusResponse
+{ "certificateStatus": [ { "certificateData": { "hashAlgorithm":"SHA256" "issuerNameHash":"12345ABCDE", "issuerKeyHash":"ABCDE1234", "serialNumber":"00123456789" }, "source":"OCSP", "status":"Good", "nextUpdate":"20250201T1200Z" }, { "certificateData": { "hashAlgorithm":"SHA256" "issuerNameHash":"ABCDE12345", "issuerKeyHash":"1234ABCDE", "serialNumber":"987634294239" }, "source":"CRL", "status":"Good", "nextUpdate":"20250201T1200Z" } ]
+}
+```
+
+# M07 - Get Vehicle Certificate Chain Revocation Status - Requirements
+
+Table 133. M07 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>M07.FR.01</td><td>When CSMS receives a GetCertificateChainStatusRequest with one or more entries in certificateStatusRequests which have source = OCSP</td><td>CSMS SHALL perform an OCSP request to one of URLs in urls for certificateHashData of each certificate.</td></tr><tr><td>M07.FR.02</td><td>M07.FR.01 AND the OCSP request to the selected URL from urls for certificateHashData fails</td><td>CSMS SHALL use status = Failed for this certificate with certificateHashData in the response.</td></tr><tr><td>M07.FR.03</td><td>M07.FR.01 AND NOT M07.FR.02</td><td>CSMS SHALL use the OCSP status (Good/Revoked/Unknown) for status of the certificate with certificateHashData in the response.</td></tr><tr><td>M07.FR.04</td><td>When CSMS receives a GetCertificateChainStatusRequest with one or more entries in certificateStatusRequests which have source = CRL</td><td>CSMS SHALL retrieve the CRL from one of the urls for certificateHashData of each certificate.</td></tr><tr><td>M07.FR.05</td><td>M07.FR.04 AND CSMS fails to download the CRL</td><td>CSMS SHALL use status = Failed for this certificate with certificateHashData in the response.</td></tr><tr><td>M07.FR.06</td><td>M07.FR.04 the serialNumber of a certificate is part of the downloaded CRL</td><td>CSMS SHALL use status = Revoked for this certificate in the response.</td></tr><tr><td>M07.FR.07</td><td>M07.FR.04 AND the serialNumber of a certificate is not part of the downloaded CRL</td><td>CSMS SHALL use status = Good for this certificate in the response.</td></tr><tr><td>M07.FR.08</td><td>When CSMS has checked all certificates in the GetCertificateChainStatusRequest</td><td>CSMS SHALL respond with a GetCertificateChainStatusResponse with a list of certificateStatus in which each entry has the certificateHashData of the certificate, the source (OCSP/CRL), status and nextUpdate of the checked certificates.</td></tr><tr><td>M07.FR.09</td><td>M07.FR.08</td><td>Charging Station SHOULD store the certificateStatus data from the GetCertificateChainStatusResponse in a local certificate status cache for at most one week.</td></tr><tr><td>M07.FR.10</td><td>When an entry for certificateHashData is present in the local certificate status cache AND the time in nextUpdate has not expired</td><td>Charging Station SHOULD NOT send a GetCertificateChainStatusRequest for the certificate.</td></tr><tr><td>M07.FR.11</td><td>When Charging Station wants to check the revocation status of a certificate chain AND the certificateHashData for one or more certificates of the chain is not present in the local certificate status cache</td><td>Charging Station SHALL send a GetCertificateChainStatusRequest to CSMS for the certificateHashData entries of the certificate chain that are not in the local certificate status cache.</td></tr></table>
+
+# N. Diagnostics
+
+# Chapter 1. Introduction
+
+This Functional Block describes the diagnostics functionality of OCPP. This functionality enables remote diagnostics of problems with a Charging Station. A Charging Station can be requested to upload a file with diagnostics information (optionally limited to a specified interval).
+
+# Chapter 2. Use cases & Requirements
+
+# 2.1. Logging
+
+# N01 - Retrieve Log Information
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Retrieve Log</td></tr><tr><td>2</td><td>ID</td><td>N01</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS retrieving of log information from a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers the functionality of getting log information from a Charging Station. The CSMS can request a Charging Station to upload a file with log information to a given location (URL). The format of this log file is not prescribed. The Charging Station uploads a log file and gives information about the status of the upload by sending status notifications to the CSMS.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a GetLogRequest to the Charging Station.
+2. The Charging Station responds with a GetLogResponse.
+3. The Charging Station sends a LogStatusNotificationRequest with the status Uploading
+4. The CSMS responds with a LogStatusNotificationResponse acknowledging the status update request.
+5. Uploading of the diagnostics files.
+6. The Charging Station sends LogStatusNotificationRequest with the status Uploaded.
+7. The CSMS responds with LogStatusNotificationResponse, acknowledging the status update request.</td></tr><tr><td></td><td>Alternative scenario</td><td>Requesting DataCollectorLog
+The DataCollector is an optional component that collects samples of measurands at a high frequency, typically with subsecond intervals. It is a component that is reported as part of an EVSE and when enabled it only applies to that EVSE. The samples are logged internally in the Charging Station and can be retrieved in bulk with the GetLogRequest by specifying LogEnumType (changed) DataCollectorLog. For small intervals and lots of data it is much more efficient to use the DataCollector than installing a sampling monitor.
+* The DataCollectorLog is configured via device model component DataCollector.
+* Data collecting is switched on/off via DataCollector.Enabled.
+* Data collecting starts from DataCollector DateTime["Start"] until DataCollector DateTime["End].
+* Measurands defined in DataCollector.SampledMeasurands are collected at rate defined in DataCollector.SamplingInterval.
+Retrieval of the data collector log is done via a GetLogRequest with logType = DataCollectorLog following the steps described in Scenario description above.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>- Diagnostics information is available for upload.
+- URL to upload file to is reachable and exists.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+Log file successfully uploaded.
+Failure postcondition:
+Log file not successfully uploaded and failed.</td></tr><tr><td>7</td><td>Error handling</td><td>When the upload fails and the transfer protocol supports "resume" the Charging Station is RECOMMENDED to try to resume before aborting the upload.</td></tr><tr><td>8</td><td>Remark(s)</td><td>As an example in this use case the requestId = 123, but this could be any value.When a Charging Station is requested to upload a log file, the CSMS supplies in the request an URL where the Charging Station SHALL upload the file. The URL also contains the protocol which must be used to upload the file.The FTP URL is of format: ftp://User:jpassword@host:port/path in which the parts User:jpassword@, :password or :port may be excluded.The Charging Station has a required Configuration Variable that reports which file transfer protocols it supports: FileTransferProtocolsThe format of the log file is not prescribed.FTP needs to be able to use Passive FTP, to be able to transverse over as much different typologies as possible.</td></tr></table>
+
+
+Figure 165. Sequence Diagram: Get Diagnostics
+
+# N01 - Retrieve Log Information - Requirements
+
+Table 134. N01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N01.FR.01</td><td>Upon receipt of a GetLogRequest AND if the requested log information is available</td><td>The Charging Station SHALL respond with a GetLogResponse stating the name of the file and status Accepted.</td><td></td></tr><tr><td>N01.FR.02</td><td>N01.FR.01</td><td>The Charging Station SHALL start uploading a single log file to the specified location</td><td></td></tr><tr><td>N01.FR.03</td><td>N01.FR.02 AND The GetLogRequest contained /logType SecurityLog</td><td>The Charging Station SHALL upload its security log</td><td></td></tr><tr><td>N01.FR.04</td><td>N01.FR.02 AND The GetLogRequest contained /logType DiagnosticsLog</td><td>The Charging Station SHALL upload its diagnostics.</td><td></td></tr><tr><td>N01.FR.05</td><td>Upon receipt of a GetLogRequest AND if the requested log information is NOT available</td><td>The Charging Station SHALL respond with a GetLogResponse WITH status Rejected.</td><td></td></tr><tr><td>N01.FR.07</td><td></td><td>Every LogStatusNotificationRequest sent for a log upload SHALL contain the same requestId as the GetLogRequest that started this log upload.</td><td></td></tr><tr><td>N01.FR.08</td><td>When uploading a log document is started</td><td>The Charging Station SHALL send a LogStatusNotificationRequest with status Uploading.</td><td></td></tr><tr><td>N01.FR.09</td><td>When a log document is uploaded successfully</td><td>The Charging Station SHALL send a LogStatusNotificationRequest with status Uploaded.</td><td></td></tr><tr><td>N01.FR.10</td><td>When uploading a log document failed</td><td>The Charging Station SHALL send a LogStatusNotificationRequest with status UpLoadFailure, BadMessage, PermissionDenied OR NotSupportedOperation.</td><td>It is RECOMMENDED to send the status only after all retry attempts have failed.A Charging Station MAY send a new Uploading status upon each retry attempt.</td></tr><tr><td>N01.FR.12</td><td>When a Charging Station is assembling or uploading the log file AND the Charging Station receives a new GetLogRequest</td><td>The Charging Station SHOULD cancel the ongoing log file upload AND respond with status AcceptedCanceled.</td><td></td></tr><tr><td>N01.FR.13</td><td></td><td>The field requestId in LogStatusNotificationRequest is mandatory, unless the message was triggered by a TriggerMessageRequest AND there is no log upload ongoing.</td><td></td></tr><tr><td>N01.FR.14</td><td></td><td>It is RECOMMENDED that Charging Station and CSMS support at least HTTP(s) as transport mechanism for the log file upload</td><td>HTTP transport is most likely to be supported, since it is also used for OCPP messaging.</td></tr><tr><td>N01.FR.15</td><td></td><td>Charging Station SHALL at least support the CSMS trust chain for secure transports</td><td></td></tr><tr><td>N01.FR.16</td><td></td><td>It is RECOMMENDED that Charging Station supports the usual CAs provided by the operating system</td><td>The log file storage of CSMS may be a cloud service operated separately from the CSMS itself and not part of the CSMS trustchain.</td></tr><tr><td>N01.FR.17</td><td>When CSMS requires basic authorization for the upload</td><td>CSMS is RECOMMENDED to require a different basic authorization password for the upload, then the one used for OCPP connectivity.</td><td>This is to avoid leaking the OCPP password to 3rd parties if the log file storage is a different system.Basic authorization can be added to the URL as follows:http://username passwords@csms.org/logs</td></tr><tr><td>N01.FR.18</td><td></td><td>Is is RECOMMENDED that CSMS accepts both PUT and POST requests for uploads from Charging Station.</td><td></td></tr><tr><td>N01.FR.19</td><td>When Charging Station uses a HTTP(s) POST request to upload the log file</td><td>Charging Station SHALL provide at least the following attributes: Content-Type: (e.g. application/ocet-stream) and Content- Disposition: with a specification of the filename.</td><td>For example:Content-Type:application/ocet-streamContent-Disposition:form-data:name="uploadfile";filename="logfile_20210420.zip"</td></tr><tr><td>N01.FR.20</td><td>N01.FR.12 AND Charging Station cancels the log file upload</td><td>The Charging Station SHALL send a LogStatusNotificationRequest with status = AcceptedCanceled.</td><td>N01.FR.12 is a "SHOULD" requirement. Only send status notification when requirement is executed.</td></tr><tr><td>N01.FR.21</td><td>N01.FR.18 AND the GetLogRequest logremoteLocation string ends with a slash character (/")</td><td>The Charging Station SHALL append the filename that it returned in the GetLogResponse filename field to this string.</td><td></td></tr><tr><td>N01.FR.22</td><td>N01.FR.18 AND the file to upload exceeds the threshold of 1MB (1024 * 1024 bytes)</td><td>The Charging Station MAY include the "Expect: 100-continue" header in the HTTP PUT request.</td><td>This gives the server a chance to deny the request before a lot of data is sent.</td></tr><tr><td>N01.FR.23</td><td>N01.FR.18</td><td>The Charging Station MAY implement a mechanism to resume HTTP uploads, if it can identify whether the upload server supports the same mechanism.</td><td>At the time of this writing, no official HTTP resume mechanism existed, only vendor-specific solutions and an IETF draft, which were not aligned.</td></tr><tr><td>N01.FR.24 (2.1)</td><td>N01.FR.02 AND The GetLogRequest contained/logType DataCollectorLog AND The Charging Station supports the DataCollector log functionality.</td><td>The Charging Station SHALL upload its data collector log.</td><td>See DataCollector component in device model.</td></tr><tr><td>N01.FR.25 (2.1)</td><td>N01.FR.17 AND the GetLogRequest logremoteLocation URL contains a userinfo component</td><td>The Charging Station SHALL use the given userinfo for HTTP Basic Authentication.</td><td></td></tr><tr><td>N01.FR.26 (2.1)</td><td>N01.FR.18</td><td>The CSMS SHALL NOT send a log upload URL that points to a server responding with a redirection.</td><td></td></tr><tr><td>N01.FR.27 (2.1)</td><td>N01.FR.18</td><td>The CSMS SHALL NOT send a log upload URL containing a fragment component.</td><td>The fragment component would not be part of the HTTP request, so it serves no purpose.</td></tr><tr><td>N01.FR.28 (2.1)</td><td>N01.FR.18 AND the CSMS includes a query component in the log upload URL</td><td>The CSMS SHALL NOT include a query component that ends with a slash character (/").</td><td>This is to simplify processing of the URL string in the Charging Station.</td></tr><tr><td>N01.FR.29 (2.1)</td><td>N01.FR.18 AND the GetLogRequest logremoteLocation string does not end with a slash character (/")</td><td>The Charging Station SHALL use it as received without modifications.</td><td></td></tr><tr><td>N01.FR.30 (2.1)</td><td>N01.FR.18</td><td>The Charging Station SHALL NOT follow redirects received in response to the request AND SHALL send a LogStatusNotificationRequest with status = UploadFailure and optionally add reasonCode = "RedirectAllowed".</td><td>Redirects bear the risk of changing the HTTP method and of redirection loops. This results in an upload failure as in N01.FR.10.</td></tr></table>
+
+# 2.2. Configure Monitoring
+
+NOTE
+
+For managing the monitoring of a Charging Station a basic understanding of Device Model concepts is essential. These concepts are explained in "OCPP 2.1: Part 1 - Architecture & Topology", chapter 4.
+
+# N02 - Get Monitoring report
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Monitoring Report</td></tr><tr><td>2</td><td>ID</td><td>N02</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to retrieve a report about configured monitoring settings per component and variable.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests the Charging Station to send a report about configured monitoring settings per component and variable. Optionally, this list can be filtered on monitoringCriteria and componentVariables.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request a monitoring report from a Charging Station.
+2. The CSMS sends a GetMonitoringReportRequest to the Charging Station.
+3. The Charging Station responds with a GetMonitoringReportResponse.
+4. The Charging Station sends a NotifyMonitoringReportRequest to the CSMS.
+5. The CSMS responds with a NotifyMonitoringReportResponse.
+6. Steps #4 and #5 are repeated until all data of the monitoring report has been sent.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Station supports Monitoring</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS received a report about the configured monitoring settings.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 166. Sequence Diagram: Get Monitoring Report
+
+# N02 - Get Monitoring Report - Requirements
+
+Table 135. N02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N02.FR.01</td><td>NOT N02.FR.10 AND When the Charging Station receives a GetMonitoringReportRequest for supported monitoringCriteria OR without monitoringCriteria</td><td>The Charging Station SHALL send a getMonitoringReportResponse with Accepted.</td></tr><tr><td>N02.FR.02</td><td>When the Charging Station receives a GetMonitoringReportRequest for not supported monitoringCriteria</td><td>The Charging Station SHALL send a getMonitoringReportResponse with NotSupported.</td></tr><tr><td>N02.FR.03</td><td>N02.FR.01</td><td>The Charging Station SHALL send the requested information via one or more notifyMonitoringReportRequest messages to the CSMS.</td></tr><tr><td>N02.FR.04</td><td>N02.FR.01 AND The GetMonitoringReportRequest contained a requestId</td><td>Every notifyMonitoringReportRequest sent for this GetMonitoringReportRequest SHALL contain the same requestId.</td></tr><tr><td>N02.FR.05</td><td>N02.FR.01 AND monitoringCriteria and componentVariables are NOT both empty.</td><td>The set of monitors reported in one or more notifyMonitoringReportRequest messages is limited to the set defined by monitoringCriteria and componentVariables.</td></tr><tr><td>N02.FR.06</td><td>N02.FR.01 AND monitoringCriteria is NOT empty AND componentVariables is empty.</td><td>The set of monitors reported in one or more notifyMonitoringReportRequest messages is limited to the set defined by monitoringCriteria.</td></tr><tr><td>N02.FR.07</td><td></td><td>The maximum number of componentVariables in one GetMonitoringReportRequest message is given by the ItemsPerMessageGetReport Configuration Variable</td></tr></table>
+
+N03 - Set Monitoring Base
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N02.FR.08</td><td>N02.FR.01 AND monitoringCriteria is absent AND componentVariables is NOT empty.</td><td>The set of monitors reported in one or more notifyMonitoringReportRequest messages is limited to the set defined by componentVariables.</td></tr><tr><td>N02.FR.09</td><td></td><td>The sequence number contained in the seqNo field of the NotifyMonitoringReportRequest is incremental per report. So the NotifyMonitoringReportRequest message which contains the first report part, SHALL have a seqNo with value 0.</td></tr><tr><td>N02.FR.10</td><td>When the Charging Station receives a GetMonitoringReportRequest with a combination of criteria which results in an empty result set.</td><td>The Charging Station SHALL respond with a GetMonitoringReportResponse(status=EmptyResultSet).</td></tr><tr><td>N02.FR.11</td><td>N02.FR.01 AND monitoringCriteria is empty AND componentVariables is empty.</td><td>The set of all existing monitors is reported in one or more notifyMonitoringReportRequest messages.</td></tr><tr><td>N02.FR.12</td><td>If monitoringCriteria contains ThresholdMonitoring</td><td>All monitors with type = UpperThreshold or type = LowerThreshold are reported.</td></tr><tr><td>N02.FR.13</td><td>If monitoringCriteria contains DeltaMonitoring</td><td>All monitors with type = Delta are reported.</td></tr><tr><td>N02.FR.14</td><td>If monitoringCriteria contains PeriodicMonitoring</td><td>All monitors with type = Periodic or type = PeriodicClockAligned are reported.</td></tr><tr><td>N02.FR.16</td><td>When Charging Station receives a GetMonitoringReportRequest with componentVariable elements in which variable is missing</td><td>The Charging Station SHALL report for every variable of the component in componentVariable.</td></tr><tr><td>N02.FR.17</td><td>When Charging Station receives a GetMonitoringReportRequest with componentVariable elements in which variable is present, but instance is missing</td><td>The Charging Station SHALL report for every instance of the variable of the component in componentVariable.</td></tr><tr><td>N02.FR.18</td><td>N02.FR.11 AND When Charging Station receives a GetMonitoringReportRequest with a component in a componentVariable element that has a component.evse.id, but component.evseconnector is missing</td><td>The Charging Station SHALL report the component(s) with this component.name, component.instance and component.evse.id for every component.evseconnector, whilst taking into account N02.FR.20.</td></tr><tr><td>N02.FR.19</td><td>N02.FR.11 AND When Charging Station receives a GetMonitoringReportRequest with a component in a componentVariable element that has no component.evse.id</td><td>The Charging Station SHALL report the component(s) with this component.name, component.instance and component.evse field (including top level component without component.evse), whilst taking into account N02.FR.20.</td></tr><tr><td>N02.FR.20</td><td>N02.FR.11 AND When Charging Station receives a GetMonitoringReportRequest with a component in a componentVariable element that has a value for component.instance</td><td>The Charging Station SHALL report the component(s) with this component.name for every component.instance field, whilst taking into account N02.FR.18, N02.FR.19.</td></tr><tr><td>N02.FR.21</td><td>N02.FR.11 AND When Charging Station receives a GetMonitoringReportRequest with a component in a componentVariable element that has no component.instance field</td><td>The Charging Station SHALL report the component(s) with this component.name for every component.instance field or the component(s) without component.instance field, whichever is the case, whilst taking into account N02.FR.18, N02.FR.19.</td></tr><tr><td>N02.FR.22(2.1)</td><td>N02.FR.03</td><td>Charging Station SHALL include the eventNotificationType of each monitor in monitoringData variableMonitoring.</td></tr><tr><td>N02.FR.23(2.1)</td><td>If monitoringCriteria contains TargetDeltaMonitoring</td><td>All monitors with type = TargetDelta and type = TargetDeltaRelative are reported.</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set Monitoring Base</td></tr><tr><td>2</td><td>ID</td><td>N03</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to request the Charging Station to activate a set of preconfigured monitoring settings, as denoted by the value of MonitoringBase.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests the Charging Station to activate a set of preconfigured monitoring settings, as denoted by the value of MonitoringBase. It is up to the manufacturer of the Charging Station to define which monitoring settings are activated by All, FactoryDefault and HardWiredOnly.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request a Charging Station to set a monitoring base.
+2. The CSMS sends a SetMonitoringBaseRequest to the Charging Station.
+3. The Charging Station responds with a SetMonitoringBaseResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Station supports Monitoring</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station activated the set of monitoring settings, as denoted by the value of MonitoringBase.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Upon receipt of a SetMonitoringBaseRequest for:
+· monitoringBase = HardWiredOnly: the Charging Station will deactivate all pre-configured monitors and remove any previously configured custom monitors. Only the HardWiredMonitor monitors remain.
+· monitoringBase = FactoryDefault: the Charging Station will (re)activate all PreconfiguredMonitor monitors and remove all custom monitors.
+· monitoringBase = All: the Charging Station will activate all pre-configured monitors and leave previously configured CustomMonitor monitors intact. This includes the custom monitors that were created when changing an existing pre-configured monitor.</td></tr></table>
+
+
+Figure 167. Sequence Diagram: Set Monitoring Base
+
+# N03 - Set Monitoring Base - Requirements
+
+Table 136. N03 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N03.FR.01</td><td>When the Charging Station accepts a setMonitoringBaseRequest</td><td>Then the Charging Station SHALL send a setMonitoringBaseResponse with Accepted.</td></tr><tr><td>N03.FR.02</td><td>When the Charging Station receives a setMonitoringBaseRequest for a not supported monitoringBase</td><td>Then the Charging Station SHALL send a setMonitoringBaseResponse with NotSupported.</td></tr><tr><td>N03.FR.03</td><td>N03.FR.01 AND When the Charging Station received a setMonitoringBaseRequest with monitoringBase All</td><td>Then the Charging Station SHALL activate all preconfigured monitoring whilst leaving all installed custom monitors (including changed preconfigured monitors) intact.</td></tr><tr><td>N03.FR.04</td><td>N03.FR.01 AND When the Charging Station received a setMonitoringBaseRequest with monitoringBase FactoryDefault</td><td>Then the Charging Station SHALL delete all custom monitors (including overruled pre-configured monitors) and activate the pre-configured monitors of the Charging Station.</td></tr></table>
+
+N04 - Set Variable Monitoring
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N03.FR.05</td><td>N03.FR.01 AND When the Charging Station received a setMonitoringBaseRequest with monitoringBase HardWiredOnly</td><td>Then the Charging Station SHALL clear all custom and disable all pre-configured monitors. Only hard-wired monitors remain active.</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set Variable Monitoring</td></tr><tr><td>2</td><td>ID</td><td>N04</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to request the Charging Station to set monitoring triggers on Variables.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests the Charging Station to set monitoring triggers on Variables. Multiple triggers can be set for upper or lower thresholds, delta changes or periodic reporting.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request a Charging Station to set a variable monitoring setting.
+2. The CSMS sends a SetVariableMonitoringRequest to the Charging Station.
+3. The Charging Station responds with a SetVariableMonitoringResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Station supports Monitoring
+The specific Variable supports Monitoring</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station activated the set of monitoring triggers on the Variables.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>All variableMonitoring settings are persistent across reboot.
+A variableMonitoring setting is persistent after a firmware update, if the monitored variable still exists and it is still monitor-able. Otherwise the variableMonitoring setting is removed.</td></tr></table>
+
+
+Figure 168. Sequence Diagram: Set Variable Monitoring
+
+N04 - Set Variable Monitoring - Requirements
+Table 137. N04 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N04.FR.01</td><td>When the Charging Station receives a SetVariableMonitoringRequest with an X number of SetMonitoringData elements</td><td>The Charging Station SHALL respond with an SetVariableMonitoringResponse with an equal (X) number of SetMonitoringResult elements, one for every SetMonitoringData element in the SetVariableMonitoringRequest.</td><td></td></tr><tr><td>N04.FR.02</td><td>N04.FR.01</td><td>Every SetMonitoringResult element in the SetVariableMonitoringResponse SHALL contain the same component and variable combination as one of the SetVariableMonitoringRequest elements in the SetVariableMonitoringRequest.</td><td></td></tr><tr><td>N04.FR.03</td><td>When the Charging Station receives a SetVariableMonitoringRequest with an unknown Component in SetMonitoringData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: UnknownComponent.</td><td></td></tr><tr><td>N04.FR.04</td><td>When the Charging Station receives a SetVariableMonitoringRequest with a Variable that is unknown for the given Component in SetMonitoringData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: UnknownVariable.</td><td></td></tr><tr><td>N04.FR.05</td><td>When the Charging Station receives a SetVariableMonitoringRequest with an MonitorType which is not supported by the specific Variable</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: UnsupportedMonitorType.</td><td></td></tr><tr><td>N04.FR.06</td><td>When the Charging Station receives a SetVariableMonitoringRequest with (monitor type = UpperThreshold AND value < minLimit OR value > maxLimit) OR (monitor type = LowerThreshold AND value < minLimit OR value > maxLimit)</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: Rejected.</td><td>minLimit and maxLimit refer to the VariableCharacteristicsType for the VariableType. Be aware that setting a UpperThreshold to the maxLimit or setting a LowerThreshold to the minLimit will result in a monitor that will never trigger. More information on the reason of rejection can be provided in the optional statusInfo element.</td></tr><tr><td>N04.FR.07</td><td>When the Charging Station receives a SetVariableMonitoringRequest for a monitor that conflicts with safety requirements.</td><td>The Charging Station MAY set the attributeStatus field in the corresponding SetMonitoringResult to: Rejected.</td><td>e.g. when the requested monitoring overrides factory set security monitoring.</td></tr><tr><td>N04.FR.08</td><td>When the Charging Station was able to set the given value in the SetMonitoringData</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: Accepted.</td><td>Please refer to use case N07 - Alert Event on how to handle the different monitor types.</td></tr><tr><td>N04.FR.09</td><td></td><td>The maximum size and number of items of monitoringData in one SetVariableMonitoringRequest message is determined by the ItemsPerMessageSetVariableMonitoring and BytesPerMessageSetVariableMonitoring Configuration Variables.</td><td></td></tr><tr><td>N04.FR.10</td><td>When the Charging Station receives a SetVariableMonitoringRequest for a component/variable combination for which a monitor with the same type and severity already exists with a different id.</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: Duplicate.</td><td>There cannot be two monitors of the same type with the same severity on the same variable. E.g. when a component/variable has a monitor with an UpperThreshold at value "67" and severity "4-Error", then there cannot be another UpperThreshold at value "78" with same severity "4-Error" defined.</td></tr><tr><td>N04.FR.11</td><td>When the Charging Station receives a SetVariableMonitoringRequest without an Id AND N04.FR.08</td><td>The Charging Station will generate an Id and return it in the SetVariableMonitoringResponse.</td><td></td></tr></table>
+
+N05 - Set Monitoring Level
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N04.FR.12</td><td>When the Charging Station receives a SetVariableMonitoringRequest with an Id AND A monitor exists matching the given Id AND The given Component/Variable combination corresponds with the existing VariableMonitor.</td><td>The Charging Station SHALL replace the monitor.</td><td></td></tr><tr><td>N04.FR.13</td><td>When the Charging Station receives a SetVariableMonitoringRequest with an Id AND No monitor exists matching the given Id.</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: Rejected.</td><td></td></tr><tr><td>N04.FR.14</td><td>When the Charging Station receives a SetVariableMonitoringRequest with type Delta and value contains a negative value.</td><td>The Charging Station SHALL set the attributeStatus field in the corresponding SetMonitoringResult to: Rejected.</td><td>More information can be provided in the optional statusInfo element.</td></tr><tr><td>N04.FR.15</td><td>N04.FR.12 AND The replaced VariableMonitor belonged to the 'PreconfiguredMonitors'.</td><td>The new VariableMonitor shall be classified as a 'CustomMonitor', until reset by a SetMonitoringBaseRequest.</td><td></td></tr><tr><td>N04.FR.16</td><td>When the Charging Station receives a SetVariableMonitoringRequest with an Id AND a monitor exists matching the given Id AND the given Component/Variable combination does NOT correspond with the existing VariableMonitor.</td><td>The Charging Station SHALL respond with Rejected AND NOT replace the VariableMonitor.</td><td>It is not allowed to change Variable or Component of a monitor.</td></tr><tr><td>N04.FR.17</td><td>When the CSMS sends a SetVariableMonitoringRequest with type Delta for a Variable that is NOT of a numeric type</td><td>It is RECOMMENDED to use a value of 1.</td><td>value is irrelevant for non-numeric types (e.g. any type except decimal or integer), since the monitor is triggered by every change of the Variable.</td></tr><tr><td>N04.FR.18</td><td>N04.FR.12 AND The id in the SetVariableMonitoringRequest refers to a HardWiredMonitor</td><td>The Charging Station SHALL respond with Rejected AND NOT replace the VariableMonitor.</td><td>It is not possible to change a hardwired monitor.</td></tr><tr><td>N04.FR.19</td><td>The Charging Station has rebooted</td><td>The CSMS IS RECOMMENDED to send a GetMonitoringReportRequest message to get a new list of monitors.</td><td>Custom monitors are persistent after reboot or firmware update, but IDs may have changed.</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set Monitoring Level</td></tr><tr><td>2</td><td>ID</td><td>N05</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to request the Charging Station to restrict the reporting of monitoring events by NotifyEventRequest to only those monitors with a severity number lower than or equal to a certain severity.</td></tr><tr><td>4</td><td>Description</td><td>It may be desirable to restrict the reporting of monitoring events, to only those monitors with a severity number lower than or equal to a certain severity. For example when the data-traffic between Charging Station and CSMS needs to limited for some reason. The CSMS can control which events it will to be notified of by the Charging Station with the SetMonitoringLevelRequest message.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request a Charging Station to restrict the reporting of monitoring events, by setting a severity level limit.
+2. The CSMS sends a SetMonitoringLevelRequest to the Charging Station.
+3. The Charging Station responds with a SetMonitoringLevelResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Station supports Monitoring</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station restricted the reporting of monitoring events by NotifyEventRequest to only those wanted by the user.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 169. Sequence Diagram: Set Monitoring Level
+
+# N05 - Set Monitoring Level - Requirements
+
+Table 138. N05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N05.FR.01</td><td>When the Charging Station accepts a setMonitoringLevelRequest</td><td>The Charging Station SHALL send a setMonitoringLevelResponse with Accepted.</td></tr><tr><td>N05.FR.02</td><td>When the Charging Station receives a setMonitoringLevelRequest for a severity that is out of range</td><td>The Charging Station SHALL send a setMonitoringLevelResponse with Rejected.</td></tr><tr><td>N05.FR.03</td><td>N05.FR.01</td><td>The Charging Station SHALL restrict the reporting of monitoring events by NotifyEventRequest to only those monitors with a severity number lower than or equal to the given severity.</td></tr></table>
+
+# N06 - Clear / Remove Monitoring
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Clear / Remove Monitoring</td></tr><tr><td>2</td><td>ID</td><td>N06</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to clear / remove monitoring settings.</td></tr><tr><td>4</td><td>Description</td><td>A monitoring setting can be cleared (removed) by sending a ClearVariableMonitoringRequest with the id of the monitoring setting.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO triggers the CSMS to request clearing/removing one or more variables in a Charging Station.
+2. The CSMS sends a ClearVariableMonitoringRequest to the Charging Station.
+3. The Charging Station responds with a ClearVariableMonitoringResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Station supports Monitoring</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station cleared / removed the requested monitoring settings.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 170. Sequence Diagram: Clear / Remove Monitoring
+
+# N06 - Clear / Remove Monitoring - Requirements
+
+Table 139. N06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N06.FR.01</td><td>When the Charging Station accepts a ClearVariableMonitoringRequest</td><td>The Charging Station SHALL send a ClearVariableMonitoringResponse with Accepted.</td></tr><tr><td>N06.FR.02</td><td>When the Charging Station receives a ClearVariableMonitoringRequest with a non existing id</td><td>The Charging Station SHALL send a ClearVariableMonitoringResponse with NotFound.</td></tr><tr><td>N06.FR.03</td><td>When the Charging Station receives a ClearVariableMonitoringRequest for an id referring to a monitor that cannot be cleared (for example because it is hardcoded).</td><td>The Charging Station SHALL send a ClearVariableMonitoringResponse with Rejected.</td></tr><tr><td>N06.FR.04</td><td></td><td>The CSMS SHALL NOT put more id elements in a ClearVariableMonitoringRequest than reported by the Charging Station via: ItemsPerMessageClearVariableMonitoring and BytesPerMessageClearVariableMonitoring.</td></tr><tr><td>N06.FR.05</td><td></td><td>For every id in a ClearVariableMonitoringRequest the Charging Station SHALL add a clearMonitoringResult element to the ClearVariableMonitoringResponse sent to the CSMS.</td></tr><tr><td>N06.FR.06</td><td>Charging Station receives a ClearVariableMonitoringRequest with more id elements than allowed by ItemsPerMessageClearVariableMonitoring</td><td>The Charging Station MAY respond with a CALLERROR(OccurrenceConstraintViolation)</td></tr><tr><td>N06.FR.07</td><td>Charging Station receives a ClearVariableMonitoringRequest with a length of more bytes than allowed by BytesPerMessageClearVariableMonitoring</td><td>The Charging Station MAY respond with a CALLERROR(FormatViolation)</td></tr></table>
+
+# 2.3. Monitoring Events
+
+# N07 - Alert Event
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Alert Event</td></tr><tr><td>2</td><td>ID</td><td>N07</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the Charging Station the ability to notify the CSMS about monitoring events.</td></tr><tr><td>4</td><td>Description</td><td>NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. If a threshold or a delta value has exceeded, the Charging Station sends a NotifyEventRequest to the CSMS.
+2. The CSMS responds with a NotifyEventResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station has active monitoring settings.
+The monitoring setting(s) might have been configured explicitly via a SetVariableMonitoring message or it might be "hard-wired" in the Charging Station's firmware.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station notified the CSMS about the monitoring events.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Requirement N07.FR.04 states that events with a severity equal or less than OfflineMonitoringEventQueuingSeverity shall be queued while the charging station is offline, and delivered once online. This implies that events with a severity greater than OfflineMonitoringEventQueuingSeverity will not be sent to CSMS. The result is, that the logical chain of events may be broken when the charging station is back online.
+For example, a monitoring event for a variable exceeding a threshold occurred while offline and was not sent. Once back online, at some point in time the monitoring event is reported with the variable cleared set to true, but CSMS did not even know that the threshold had been exceeded. CSMS will have to be able to deal with that.
+This problem can be prevented, while still adhering to the specification, by not simply discarding these monitoring events, but by delaying the evaluation of those monitors that exceed OfflineMonitoringEventQueuingSeverity, until the charging station comes back online. The result is, that when the charging station is back online, CSMS will get the monitoring events that apply to the current situation, and it is fully up-to-date regarding the monitors. Only those monitoring events that were triggered & cleared during the offline period will remain invisible to CSMS.</td></tr></table>
+
+
+Figure 171. Sequence Diagram: Alert Event
+
+# N07 - Alert Event - Requirements
+
+Table 140. N07 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N07.FR.02 (2.1)</td><td>When a monitored value returns to within the boundary of UpperThreshold, LowerThreshold, TargetDelta or TargetDeltaRelative</td><td>The Charging Station SHALL send a NotifyEventRequest with an eventData with the attribute cleared is true.</td><td></td></tr><tr><td>N07.FR.03</td><td>When the CSMS receives an NotifyEventRequest</td><td>The CSMS SHALL respond with an empty NotifyEventResponse.</td><td></td></tr><tr><td>N07.FR.04</td><td>When a monitor is triggered AND The severity number of the monitor is equal to or lower than the severity number set in the Configuration Variable OfflineMonitoringEventQueuingSeverity AND The Charging Station is offline</td><td>The Charging Station SHALL queue this NotifyEventRequest and deliver it when it is back online.</td><td></td></tr><tr><td>N07.FR.05</td><td>When a monitor is triggered AND another event caused this event</td><td>The Charging Station MAY include the eventId of the other event in the cause field of the eventData element in the NotifyEventRequest message.</td><td></td></tr><tr><td>N07.FR.06</td><td>When a monitor is triggered</td><td>An eventData element in a NotifyEventRequest SHALL contain the Component, Variable and variableMonitoringId that caused the event.</td><td></td></tr><tr><td>N07.FR.07</td><td>When a monitor is triggered</td><td>The Charging Station SHALL set the seqNo of the first NotifyEventRequest sent for this event to 0.</td><td></td></tr><tr><td>N07.FR.10</td><td>When a monitor is triggered AND A variableMonitoring setting has been set on a write-only variable.</td><td>The actualField of the NotifyEventRequest SHALL be empty.</td><td></td></tr><tr><td>N07.FR.11 (2.1)</td><td>When modifying a set UpperThreshold, LowerThreshold, TargetDelta or TargetDeltaRelative VariableMonitor AND (the new threshold clears the old threshold OR the new threshold is exceeded by the monitored value)</td><td>The Charging Station SHALL send a NotifyEventRequest message for this VariableMonitor with the appropriate value for cleared.</td><td>If monitored value is below new threshold, then cleared = true. If monitored value above threshold, then cleared = false or absent.</td></tr><tr><td>N07.FR.12 (2.1)</td><td>When removing a set UpperThreshold, LowerThreshold, TargetDelta or TargetDeltaRelative VariableMonitor AND the threshold was exceeded.</td><td>The Charging Station SHALL NOT send a NotifyEventRequest with an eventData with the attribute cleared is true.</td><td></td></tr><tr><td>N07.FR.13</td><td></td><td>A VariableMonitoring needs to be stored persistently across reboots.</td><td></td></tr><tr><td>N07.FR.14 (2.1)</td><td>When a variableMonitoring setting of type UpperThreshold, LowerThreshold, TargetDelta or TargetDeltaRelative has been triggered AND after a reboot occurred the monitored value returned within the configured threshold.</td><td>The Charging Station SHALL send a NotifyEventRequest with an eventData with the attribute cleared is true.</td><td></td></tr><tr><td>N07.FR.15</td><td>When a monitor is triggered AND The severity of the monitor is greater than the monitoring severity level set in a SetMonitoringLevelRequest by the CSMS (see use case N05 - Set Monitoring Level)</td><td>The Charging Station SHALL NOT send a NotifyEventRequest for the triggered monitor.</td><td></td></tr><tr><td>N07.FR.16</td><td>When there is a monitor with type UpperThreshold on a Component/Variable combination AND the Actual value (attributeType Actual) of the Variable exceeds value</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Alerting for the triggered monitor.</td><td>Notification is sent when exceeding the threshold, not on the threshold.</td></tr><tr><td>N07.FR.17</td><td>When there is a monitor with type LowerThreshold on a Component/Variable combination AND the Actual value (attributeType Actual) of the Variable drops below value</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Alerting for the triggered monitor.</td><td>Notification is sent when dropping below the threshold, not on the threshold.</td></tr><tr><td>N07.FR.18</td><td>When there is a monitor with type Delta on a Component/Variable combination AND the Variable is of a numeric type AND the Actual value (attributeType Actual) of the Variable has changed more than plus or minus value since the time that this monitor was set or since the last time this event notice was sent, whichever was last,</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Delta for the triggered monitor.</td><td></td></tr></table>
+
+N08 - Periodic Event
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N07.FR.19</td><td>When there is a monitor with type Delta on a Component/Variable combination AND the Variable is NOT of a numeric type AND the Actual value (attributeType'Actual') of the Variable has changed since the time that this monitor was set or since the last time this event notice was sent, whichever was last, (Note: For variables that are not numeric, like boolean, string or enumerations, a monitor of type Delta will trigger an event notice whenever the variable changes, regardless of the value of value)</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Delta for the triggered monitor.</td><td></td></tr><tr><td>N07.FR.20(2.1)</td><td>N07.FR.06</td><td>Charging Station SHOULD set the field eventData.severity of the NotifyEventRequest to the severity of the monitor referred to in variableMonitoringld.</td><td>A HardwiredNotification does not have an associated monitor, but can still provide a severity.The requirement is a "should", because the added field is optional for backwards compatibility, but it is recommended to provide a severity.</td></tr><tr><td>N07.FR.21(2.1)</td><td>When eventData.eventNotificationType = HardwiredNotification in NotifyEventRequest</td><td>Charging Station SHOULD set eventData.severity to an implementation-defined value.</td><td>Value of severity is up to implementation, since this notification is not related to a monitor.</td></tr><tr><td>N07.FR.22(2.1)</td><td>When there is a monitor with type TargetDelta on a Component/Variable combination AND the Actual value (attributeType Actual) of the Variable differs from the Target value (attributeType Target) more than plus or minus value</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Alerting for the triggered monitor.</td><td>Example: when target = 100, value = 10, then an event is triggered when actual < 90 or actual > 110.</td></tr><tr><td>N07.FR.23(2.1)</td><td>When there is a monitor with type TargetDeltaRelative on a Component/Variable combination AND the Actual value (attributeType Actual) of the Variable differs from the Target value (attributeType Target) more than plus or minus (value * Target value)</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Alerting for the triggered monitor.</td><td>Example: when target = 100, value = 0.1, then an event is triggered when actual < 90 or actual > 110.</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Periodic Event</td></tr><tr><td>2</td><td>ID</td><td>N08</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the Charging Station the ability to notify the CSMS periodically about monitoring events.</td></tr><tr><td>4</td><td>Description</td><td>NotifyEventRequest reports every Component/Variable for which a VariableMonitoring setting was triggered. Only the VariableMonitoring settings that are responsible for triggering an event are included.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. If a periodic value has exceeded, the Charging Station sends a NotifyEventRequest with trigger periodic to the CSMS.
+2. The CSMS responds with a NotifyEventResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>The Charging Station has active monitoring settings.
+The monitoring setting(s) might have been configured explicitly via a SetVariableMonitoring message or it might be "hard-wired" in the Charging Station's firmware.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station notified the CSMS about the monitoring events.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 172. Sequence Diagram: Periodic Event
+
+# N08 - Periodic Event - Requirements
+
+Table 141. N08 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N08.FR.02</td><td>When the CSMS receives an NotifyEventRequest</td><td>The CSMS SHALL respond with an empty NotifyEventResponse.</td></tr><tr><td>N08.FR.03</td><td>N08.FR.06 OR N08.FR.07 AND The severity number of the monitor is equal to or lower than the severity number set in the Configuration Variable OfflineMonitoringEventQueueingSeverity AND The Charging Station is offline</td><td>The Charging Station SHALL queue this NotifyEventRequest and deliver it when it is back online.</td></tr><tr><td>N08.FR.04</td><td>N08.FR.06 OR N08.FR.07 AND This NotifyEventRequest is the first or only report part.</td><td>The Charging Station SHALL set seqNo to 0.</td></tr><tr><td>N08.FR.05</td><td>N08.FR.06 OR N08.FR.07 AND When the variableMonitoring setting which triggered the event is either of type Periodic or PeriodicClockAligned</td><td>The Charging Station SHALL set trigger to Periodic.</td></tr><tr><td>N08.FR.06</td><td>When there is a monitor with type Periodic on a Component/Variable combination AND the number of seconds specified in value have passed (starting from the time that this monitor was set or triggered)</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Periodic for the triggered monitor.</td></tr><tr><td>N08.FR.07</td><td>When there is a monitor with type PeriodicClockAligned on a Component/Variable combination AND the number of seconds specified by value, starting from the nearest clock-aligned interval after this monitor was set, have passed (For example, a value of 900 will trigger event notices at 0, 15, 30 and 45 minutes after the hour, every hour)</td><td>The Charging Station SHALL send a NotifyEventRequest with trigger Periodic for the triggered monitor.</td></tr></table>
+
+# 2.4. Customer Information
+
+# N09 - Get Customer Information
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Customer Information</td></tr><tr><td>2</td><td>ID</td><td>N09</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to retrieve raw customer information from a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS sends a message to the Charging Station to retrieve raw customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a CustomerInformationRequest with the report flag set to true to the Charging Station with a reference to a customer (idToken, customerCertificate or customerIdentifier).2. The Charging Station responds with CustomerInformationResponse, indicating whether it will send it or not.3. The Charging Station sends one or more NotifyCustomerInformationRequest messages to the CSMS.4. The CSMS responds with one or more NotifyCustomerInformationResponse messages to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS has Successfully received a CustomerInformationResponse message with status Accepted AND has Successfully received the requested data.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 173. Sequence Diagram: Get Customer Information
+
+# N09 - Get Customer Information - Requirements
+
+Table 142. N09 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N09.FR.01</td><td>When the CSMS wants to retrieve CustomerInformation from the Charging Station.</td><td>The report flag in the CustomerInformationRequest SHALL be set to true.</td><td></td></tr><tr><td>N09.FR.02</td><td>When the Charging Station receives a CustomerInformationRequest AND it is in a state where it can process this request.</td><td>the Charging Station SHALL respond with a CustomerInformationResponse message with status Accepted .</td><td></td></tr><tr><td>N09.FR.03</td><td>When the Charging Station is in a state where it cannot process this request.</td><td>On receipt of the CustomerInformationRequest the Charging Station SHALL respond with a CustomerInformationResponse with status Rejected .</td><td></td></tr><tr><td>N09.FR.04</td><td></td><td>The CSMS SHALL include a reference to a customer by including either an idToken, customerCertificate or customerIdentifier in the CustomerInformationRequest.</td><td></td></tr><tr><td>N09.FR.05</td><td>N09.FR.02 AND the Charging Station has information stored about the customer referred to by the customer identifier</td><td>The Charging Station SHALL send the requested information via one or more NotifyCustomerInformationRequest messages to the CSMS.</td><td></td></tr><tr><td>N09.FR.06</td><td>N09.FR.02 AND the Charging Station has no information stored about the customer referred to by the customer identifier.</td><td>The Charging Station SHALL send one NotifyCustomerInformationRequest message to the CSMS indicating that no data was found.</td><td></td></tr><tr><td>N09.FR.07</td><td>When receiving a CustomerInformationRequest with both the report flag as well as the clear flag are set to false</td><td>It is RECOMMENDED to respond with status a CustomerInformationResponse message with status Rejected .</td><td></td></tr><tr><td>N09.FR.08</td><td>When requesting user information according to the customerCertificate</td><td>The CSMS SHALL use the hashAlgorithm, which was used to install the certificate.</td><td>When a new firmware is installed it is RECOMMENDED that the CSMS requests the certificate first using GetInstalledCertificates Request to be sure of the used hashAlgorithm.</td></tr><tr><td>N09.FR.09</td><td>When CustomerInformationRequest contains none of idToken, customerCertificate or customerIdentifier OR CustomerInformationRequest contains more than one of idToken, customerCertificate or customerIdentifier</td><td>Charging Station SHALL respond with status = Invalid</td><td>Only one value for either idToken, customerCertificate or customerIdentifier may be provided. Charging Station counterpart requirement of N09.FR.04.</td></tr></table>
+
+# N10 - Clear Customer Information
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Clear Customer Information</td></tr><tr><td>2</td><td>ID</td><td>N10</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable the CSMS to clear (and retrieve) raw customer information from a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS sends a message to the Charging Station to clear (and retrieve) raw customer information, for example to be compliant with local privacy laws. The Charging Station notifies the CSMS by sending one or more reports.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends CustomerInformationRequest with the clear flag set to true to the Charging Station with a reference to a customer (idToken, customerCertificate or customerIdentifier).2. The Charging Station responds with CustomerInformationResponse, indicating whether it will send it or not.3. If the report flag is set to true, the Charging Station sends one or more NotifyCustomerInformationRequest messages to the CSMS.4. The CSMS responds with one or more NotifyCustomerInformationResponse messages to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The CSMS has Successfully received a CustomerInformationResponse message with status Accepted, the Charging Station has removed the customer information as requested and (if report flag was set to true) the CSMS has Successfully received the removed data.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>n/a</td></tr></table>
+
+
+Figure 174. Sequence Diagram: Clear Customer Information
+
+# N10 - Clear Customer Information - Requirements
+
+Table 143. N10 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N10.FR.01</td><td>When the Charging Station receives a CustomerInformationRequest AND it is in a state where it can process this request.</td><td>the Charging Station SHALL respond with a CustomerInformationResponse message with status Accepted .</td><td></td></tr><tr><td>N10.FR.02</td><td>When the Customer referred to by the customer identifier is present in the Local Authorization List of a Charging Station</td><td>The CSMS SHALL update the Local Authorization List using the SendLocalListRequest (see D01 - Send Local Authorization List).</td><td>To prevent problems with Local Authorization List versions.</td></tr><tr><td>N10.FR.03</td><td>N10.FR.01 AND receiving a CustomerInformationRequest with the clear flag set to true and the report flag set to true AND the Charging Station has information stored about the customer referred to by the customer identifier.</td><td>The Charging Station SHALL remove all customer related data for the Customer referred to by the customer identifier from the Charging Station, except from the LocalList AND the Charging Station SHALL send the cleared information via one or more NotifyCustomerInformationRequest messages to the CSMS.</td><td>To prevent problems with LocalList versions only the CSMS can change the contents of the LocalList.</td></tr><tr><td>N10.FR.04</td><td>N10.FR.01 AND receiving a CustomerInformationRequest with the clear flag set to true and the report flag set to true AND the Charging Station has no information stored about the customer referred to by the customer identifier.</td><td>The Charging Station SHALL send one NotifyCustomerInformationRequest message to the CSMS indicating that no data was found.</td><td></td></tr><tr><td>N10.FR.05</td><td>When the Charging Station receives a CustomerInformationRequest and is in a state where it cannot process this request.</td><td>The Charging Station SHALL respond with a CustomerInformationResponse with status Rejected</td><td></td></tr><tr><td>N10.FR.06</td><td>N10.FR.01 AND receiving a CustomerInformationRequest with the clear flag set to true, the report flag set to false</td><td>The Charging Station SHALL remove all customer related data for the Customer referred to by the customer identifier from the Charging Station, except from the LocalList AND the Charging Station SHALL send one NotifyCustomerInformationRequest message to the CSMS indicating that the data was cleared.</td><td>To prevent problems with LocalList versions only the CSMS can change the contents of the LocalList.</td></tr><tr><td>N10.FR.07</td><td>When receiving a CustomerInformationRequest with both the report flag as well as the clear flag are set to false</td><td>It is RECOMMENDED to respond with a CustomerInformationResponse message with status Rejected .</td><td></td></tr><tr><td>N10.FR.08</td><td></td><td>The CSMS SHALL include a reference to a customer by including either an idToken, customerCertificate or customerIdentifier in the CustomerInformationRequest.</td><td></td></tr><tr><td>N10.FR.09</td><td>When clearing user information according to the customerCertificate</td><td>The CSMS SHALL use the hashAlgorithm, which was used to install the certificate.</td><td>When a new firmware is installed it is RECOMMENDED that the CSMS requests the certificate first using GetInstalledCertificates Request to be sure of the used hashAlgorithm.</td></tr></table>
+
+# 2.5. Frequent Periodic Variable Monitoring
+
+The following use cases describe a more efficient method of reporting values of periodic monitors that need to be reported frequently. A Charging Station opens a so-called "event stream" for a specific monitor. This can be at the request of CSMS in a SetVariableMonitoringRequest, or by Charging Station when it is reporting periodic values for a preconfigured or hardwired monitor.
+
+Charging Station may send these periodic values in chunks to safe overhead. For example, a periodic monitor of 1 second can be reported in one NotifyPeriodicEventStream message that is sent every minute with 60 values.
+
+The NotifyPeriodicEventStream message is of a special unconfirmed message type ("SEND") that requires no response. This allows for much faster sending of the data.
+
+# N11 - Set Frequent Periodic Variable Monitoring
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set Frequent Periodic Variable Monitoring</td></tr><tr><td>2</td><td>ID</td><td>N11</td></tr><tr><td>3</td><td>Objective(s)</td><td>To give the CSMS the ability to request efficient frequent periodic monitoring of variables.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how the CSMS requests the Charging Station to set monitoring triggers on Variables and use an event stream to report a set of measured values, for example, once every 60 seconds to reduce the communications overhead of individual NotifyEventRequests.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description #1</td><td>Variable monitor set by CSMS
+1. The CSMS sends a SetVariableMonitoringRequest for two variables of a component to the Charging Station with monitorEnumType = Periodic or PeriodicClockAligned and with eventStream.interval/values describing how often the stream must be flushed.
+2. Charging Station responds with a SetVariableMonitoringResponse with setMonitoringResult element for each variable and an Accepted status and an id for each monitor.
+3. Charging Station creates an event stream for each monitored variable by sending an OpenPeriodicEventStreamRequest to CSMS with the constant data for each variable for which an event stream is created.
+4. CSMS responds to each OpenPeriodicEventStreamRequest with OpenPeriodicEventStreamResponse with status = Accepted.
+5. Every interval seconds or when values values are available Charging Station will send all periodic values of a monitor as one message via the NotifyPeriodicEventStream message. This message is not acknowledged by CSMS.</td></tr><tr><td></td><td>Scenario description #2</td><td>Hardwired/PreconfiguredMonitor from Charging Station
+1. Charging Station creates an event stream for each periodic HardWiredMonitor or PreconfiguredMonitor by sending an OpenPeriodicEventStreamRequest to CSMS with the constant data for each variable for which an event stream is created and params.interval/values describing how often the stream will be flushed.
+2. CSMS responds to each OpenPeriodicEventStreamRequest with OpenPeriodicEventStreamResponse with status = Accepted.
+3. Every interval seconds or when values values are available Charging Station will send all periodic values of a monitor as one message via the NotifyPeriodicEventStream message. This message is not acknowledged by CSMS.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>Charging Station supports Monitoring
+The specific Variable supports Monitoring</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The Charging Station activated the set of monitoring triggers on the Variables.</td></tr><tr><td>7</td><td>Error handling</td><td>If Charging Station fails to open an event stream, e.g. because CSMS rejects it, then Charging Station will use regular NotifyEventRequest messages.</td></tr><tr><td>8</td><td>Remark(s)</td><td>This mechanism is meant for monitors that are expected to be triggered frequently, like periodic monitors, but it may also be used for delta monitors that are expected to trigger frequently.All variableMonitoring settings are persistent across reboot.A variableMonitoring setting is persistent after a firmware update, if the monitored variable still exists, and it is still monitor-able. Otherwise, the variableMonitoring setting is removed.A Charging Station can also open an event stream for hardwired or preconfigured monitors, for which no SetVariableMonitoringRequest was issued.</td></tr></table>
+
+
+
+# N11 - Set Frequent Periodic Variable Monitoring - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N11.FR.01</td><td>Upon receiving a SetVariableMonitoringRequest with one or more setMonitoringData elements that have a periodicEventStream element</td><td>Charging Station SHALL associate a periodic event stream with each of the monitors that have a periodicEventStream element.</td></tr><tr><td>N11.FR.02</td><td>N11.FR.01</td><td>Charging Station SHALL send a OpenPeriodicEventStreamRequest to CSMS with the id of event stream, and params set to the event stream flushing parameters from periodicEventStream in the SetVariableMonitoringRequest, and variableMonitoringId set to the id of the monitor.</td></tr><tr><td>N11.FR.03</td><td>When Charging Station wants to use a periodic event stream for a HardWired or Preconfigured monitor</td><td>Charging Station SHALL send a OpenPeriodicEventStreamRequest to CSMS with the id of event stream, and params set to the (preconfigured) event stream flushing parameters, and variableMonitoringId set to the id of the monitor.</td></tr><tr><td>N11.FR.04</td><td>N11.FR.02 OR N11.FR.03</td><td>CSMS SHALL prepare to receive data of the periodic event stream and SHALL associate the data related to the variableMonitoringId with the values read from the event stream.</td></tr><tr><td>N11.FR.05</td><td>When CSMS is not able to process the periodic event stream</td><td>CSMS SHALL respond with a OpenPeriodicEventStreamResponse with status = Rejected.</td></tr><tr><td>N11.FR.06</td><td>When CSMS accepts the periodic event stream</td><td>CSMS SHALL respond with a OpenPeriodicEventStreamResponse with status = Accepted.</td></tr><tr><td>N11.FR.07</td><td>N11.FR.05</td><td>Charging Station SHALL refrain from using the periodic event stream for this monitor and SHALL revert to using NotifyEventRequest message for this monitor.</td></tr><tr><td>N11.FR.08</td><td></td><td>CSMS SHALL associate the following data, that is normally present as required fields in a NotifyEventRequest, with the periodic event stream. (This data is available from the monitor):
+· variableMonitoringId,
+· trigger (= Periodic),
+· eventNotificationType,
+· severity,
+· component,
+· variable.</td></tr><tr><td>N11.FR.09</td><td>When providing a periodicEventStream element in a SetVariableMonitoringRequest</td><td>CSMS SHALL provide a value for interval or values or both.</td></tr></table>
+
+# N12 - Get Periodic Event Streams
+
+New in OCPP2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Periodic Event Streams</td></tr><tr><td>2</td><td>ID</td><td>N12</td></tr><tr><td>3</td><td>Objective(s)</td><td>To get a list of existing event streams</td></tr><tr><td>4</td><td>Description</td><td>CSMS requests a list of event streams and associated constant data.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends a GetPeriodicEventStreamRequest without parameters.
+2. CS responds with a GetPeriodicEventStreamResponse with a list of ConstantStreamDataType.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td></td></tr><tr><td>6</td><td>Postcondition(s)</td><td></td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>This is only needed in case CSMS has somehow lost its administration of event streams.</td></tr></table>
+
+# N12 - Get Periodic Event Streams - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N12.FR.01</td><td>Upon receiving a GetPeriodicEventStreamRequest</td><td>Charging Station SHALL respond with a GetPeriodicEventStreamResponse with a list of zero or more ConstantStreamDataType of all open event streams</td></tr></table>
+
+# N13 - Close Periodic Event Streams
+
+New in OCPP2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Close Periodic Event Streams</td></tr><tr><td>2</td><td>ID</td><td>N13</td></tr><tr><td>3</td><td>Objective(s)</td><td>To close a periodic event stream</td></tr><tr><td>4</td><td>Description</td><td>Charging Station closes/terminates a periodic event stream.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS, CSO</td></tr><tr><td></td><td>Scenario description #1</td><td>Charging Station closes a periodic event stream
+ 1. Charging Station flushes the periodic event stream, i.e. all buffered data is sent to CSMS.
+ 2. Charging Station reverts to using regular NotifyEventRequest messages for the variable that was associated with the periodic event stream.
+ 3. Charging Station sends a ClosePeriodicEventStreamRequest with id of the event stream to tell CSMS that event stream has been closed.
+ 4. CSMS responds with a ClosePeriodicEventStreamResponse.</td></tr><tr><td></td><td>Scenario description #2</td><td>CSMS clears a variable monitor
+ 1. CSMS sends a ClearVariableMonitoringRequest for a component/variable monitor that uses a periodic event stream to report the events.
+ 2. Charging Station processes the request as described in use case N06 Clear/Remove Monitoring.
+ 3. If monitor was successfully cleared, Charging Station continues with steps from Scenario description #1.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td></td></tr><tr><td>6</td><td>Postcondition(s)</td><td></td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>This can be initiated by Charging Station at any time, but is normally the result of CSMS removing a monitor.</td></tr></table>
+
+# N13 - Close Periodic Event Streams - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N13.FR.01</td><td>When Charging Station wants to close/terminate a periodic event stream</td><td>Charging Station SHALL notify CSMS about this by sending a ClosePeriodicEventStreamRequest message with the id of the event stream.</td><td></td></tr><tr><td>N13.FR.02</td><td>N13.FR.01</td><td>CSMS SHALL stop using the periodic event stream and respond with a ClosePeriodicEventStreamResponse.</td><td></td></tr><tr><td>N13.FR.03</td><td>N13.FR.01</td><td>Charging Station SHALL send all buffered values of a periodic event stream before sending the ClosePeriodicEventStreamRequest.</td><td></td></tr><tr><td>N13.FR.04</td><td>N13.FR.01</td><td>Charging Station SHALL revert to using NotifyEventRequest message to report the variable that was associated with the periodic event stream.</td><td></td></tr><tr><td>N13.FR.05</td><td>Upon receiving a ClearVariableMonitoringRequest for a monitor</td><td>Charging Station SHALL clear the monitor as described in use case N06 Clear/Remove Monitor, and Charging Station SHALL close an associated periodic event stream as per requirement N13.FR.01.</td><td>Removing the monitor automatically closes the periodic event stream.</td></tr><tr><td>N13.FR.06</td><td>Upon receiving a SetVariableMonitoringRequest for an existing monitor with same id and same component/variable and without a periodicEventStream element</td><td>Charging Station SHALL replace the monitor as described in N04.FR.12, and Charging Station SHALL close an associated periodic event stream as per requirement N13.FR.01.</td><td>This re-install the monitor without a periodic event stream</td></tr></table>
+
+# N14 - Adjust Periodic Event Streams
+
+New in OCPP2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Adjust Periodic Event Streams</td></tr></table>
+
+N14 - Adjust Periodic Event Streams - Requirements
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>2</td><td>ID</td><td>N14</td></tr><tr><td>3</td><td>Objective(s)</td><td>To adjust the transmission rate of a periodic event stream</td></tr><tr><td>4</td><td>Description</td><td>CSMS updates the interval/values parameters of an event stream.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description #1</td><td>1. CSMS sends a AdjustPeriodicEventStreamRequest to Charging Station with new values for params.interval and/or params.values to change how often data for the stream is sent.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A periodic event stream exists.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>How often Charging Station sends data for the periodic event stream is adjusted accordingly.</td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td></td></tr></table>
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>N14.FR.01</td><td>When CSMS wants to change the rate of sending data for a periodic event stream</td><td>CSMS SHALL send a AdjustPeriodicEventStreamRequest message with the id of the event stream and a params object with new interval and/or values fields</td><td></td></tr><tr><td>N14.FR.02</td><td>N14.FR.01 AND If Charging Station is unable to comply to the new parameters</td><td>Charging Station SHALL respond with AdjustPeriodicEventStreamResponse with status = Rejected.</td><td></td></tr><tr><td>N14.FR.03</td><td>N14.FR.01 AND If Charging Station is able to comply to the new parameters</td><td>Charging Station SHALL respond with AdjustPeriodicEventStreamResponse with status = Accepted and change the rate of sending NotifyPeriodicEventStream messages according to params.</td><td></td></tr></table>
+
+# N15 - Periodic Event Streams
+
+New in OCPP2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Periodic Event Streams</td></tr><tr><td>2</td><td>ID</td><td>N15</td></tr><tr><td>3</td><td>Objective(s)</td><td>To explain how a frequent periodic monitor is sent.</td></tr><tr><td>4</td><td>Description</td><td>Charging Station can open a periodic event stream to report frequent periodic monitor values, as described in use case N11. This reduces data overhead, since static data is not repeated every time, and reduces time, because a periodic event stream message is not acknowledged by CSMS. This use case describes the use of the NotifyPeriodicEventStream message to send the data.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description #1</td><td>Charging Station sends values over event stream
+1. When a monitor that is associated with a periodic event stream, produces a value, Charging Station places this value in the event stream buffer together with a timestamp.
+2. The field params of PeriodicEventStreamParamsType that was used in OpenPeriodicEventStreamRequest determines when to flush the buffer.
+3. After more than params.interval seconds have passed since the last flush, or after the number of values equals or exceeds params.values, then Charging Station writes ("flushes") the buffered values to CSMS as a list of streamData in a NotifyPeriodicEventStream message. This message is not confirmed by CSMS.</td></tr></table>
+
+N15 - Periodic Event Stream - Requirements
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td><td></td></tr><tr><td rowspan="4"></td><td rowspan="4">Scenario description #2</td><td>CSMS reads values from event stream</td><td></td></tr><tr><td>1. When CSMS receives a NotifyPeriodicEventStream message, it has a北京时间 and a list of StreamDataElementType with the value (v) and time (t), as an offset to北京时间, of the event.</td><td></td></tr><tr><td>2. CSMS combines the data with the information of the monitor of this periodic event stream such that it can recreate all required fields that would be present in a NotifyEventRequest. This allows a CSMS to use the same processing for events from a periodic event stream as for regular NotifyEventRequests.</td><td></td></tr><tr><td>NOTE</td><td>One required field of NotifyEventRequest is missing: eventId, because that is not present in the periodic event stream data. When needed CSMS can give it any value, because it is never communicated back to the Charging Station.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A periodic event stream for the monitor exists.</td><td></td></tr><tr><td>6</td><td>Postcondition(s)</td><td></td><td></td></tr><tr><td>7</td><td>Error handling</td><td>Since this message has no reply, there is no way for CSMS to report an error condition back to Charging Station. The only way for CSMS to stop with a periodic event stream is by clearing the associated monitor.</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>This message uses the RPC framework message type "SEND" to send an unconfirmed message. Unconfirmed messages do not require a response. They were introduced in OCPP 2.1. (See part 4 "JSON over Websockets Implementation Guide").A Charging Station can send a SEND message at any time, i.e. there is need to wait for the CALLRESULT of the previous CALL message before sending it.Because SEND messages still use the same websocket connection as CALL/CALLRESULT messages, the frequent sending of large SEND messages may cause a delay for other messages.</td><td></td></tr></table>
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>N15.FR.01</td><td></td><td>Charging Station SHALL send a NotifyPeriodicEventStream message as a message type "SEND" in the RPC Framework over the WebSocket.</td></tr><tr><td>N15.FR.02</td><td>When receiving a message of RPC message type "SEND"</td><td>CSMS SHALL NOT confirm the message upon receipt with "CALLRESULT" or "CALLERROR".</td></tr><tr><td>N15.FR.03</td><td>N15.FR.02</td><td>CSMS SHALL associate the following fixed data, that is normally present as required fields in a NotifyEventRequest, with the data elements of the periodic event stream of type StreamDataElementType. (This fixed data is available from the monitor in variableMonitoringId): · variableMonitoringId, · trigger (= Periodic), · eventNotificationType, · severity, · component, · variable.</td></tr><tr><td>N15.FR.04</td><td></td><td>Charging Station SHALL set pending in NotifyPeriodicEventStream to the number of data elements that is available, but not yet part of this NotifyPeriodicEventStream message.</td></tr><tr><td>N15.FR.05</td><td>When the value of pending in subsequent NotifyPeriodicEventStream messages that CSMS receives is growing</td><td>CSMS SHOULD consider adjusting the periodic event stream parameters to allow larger or more frequent messages.</td></tr><tr><td>N15.FR.06</td><td>If params.interval in a SetMonitoringDataType of a monitor is greater than 0</td><td>Charging Station SHALL send a NotifyPeriodicEventStream message for the associated monitor every params.interval seconds.</td></tr><tr><td>N15.FR.07</td><td>N15.FR.06 AND params.values is greater than 0</td><td>Charging Station SHALL send no more than params.values values at a time in a NotifyPeriodicEventStream message.</td></tr><tr><td>N15.FR.08</td><td>If params.values in a SetMonitoringDataType of a monitor is greater than 0</td><td>Charging Station SHALL send a NotifyPeriodicEventStream message for the associated monitor as soon as params.values values are available.</td></tr><tr><td>N15.FR.09</td><td></td><td>Charging Station SHALL set北京时间 in a NotifyPeriodicEventStream message to the timestamp of the first value in the data list of values. (This effectively makes that the offset t of the first value is always 0).</td></tr></table>
+
+# O. Display Message
+
+# Chapter 1. Introduction
+
+With the DisplayMessage feature, OCPP enables a CSO to display a message or a cycle of messages on a Charging Station, that is not part of the firmware of the Charging Station. The CSO gets control over these messages: the CSO can set, retrieve (get), replace and clear messages.
+
+Every message can be configured in different languages and different message formats. See DisplayMessageSupportedFormats. So the Charging Station can select the correct format/language when it needs to display a message to a user. Every message the CSO sends to the Charging Station has some parameters to control when and how a message is shown: priority, state, start/end time etc. See DisplayMessageSupportedPriorities.
+
+# NOTE
+
+It is not possible to retrieve/modify messages not configured via SetDisplayMessageRequest. (In other words: Message coded in the firmware of a Charging Station cannot be modified.)
+
+# Chapter 2. Use cases & Requirements
+
+# 001 - Set DisplayMessage
+
+Updated in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set DisplayMessage</td></tr><tr><td>2</td><td>ID</td><td>001</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable a CSO to display additional messages on a Charging Station that are not part of the firmware.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a CSO can set a message to be displayed on a Charging Station. Depending on the given parameters the message shall be displayed a certain way and at a certain moment on the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>CSO, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO configures the CSMS to send a request to set a new message.
+2. The CSMS sends a SetDisplayMessageRequest message to the Charging Station.
+3. The Charging Station accepts the request by sending a SetDisplayMessageResponse message to the CSMS.
+4. The Charging Station shows the new message on the display at the configured moment.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>002 - Set DisplayMessage for Transaction
+006 - Replace DisplayMessage</td></tr><tr><td>5</td><td>Prerequisites</td><td>No messages configured with the same IDs.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The new message will be displayed on the Charging Station (time, duration and position depending on configuration)</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The maximum number of messages that can be stored in a Charging Station can be read by the CSMS in the Configuration Variable:NumberOfDisplayMessages.maxLimit.
+The default language of the Charging Station and the list of supported languages are reported in the Configuration Variable: DisplayMessageLanguage.
+If DisplayMessageLanguage is not present, then additional language messages in messageExtra in a SetDisplayMessageRequest are not supported.</td></tr></table>
+
+
+Figure 175. Set DisplayMessage sequence diagram
+
+# 001 - Set DisplayMessage - Requirements
+
+Table 144.001 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>001.FR.01</td><td>When the Charging Station receives a DisplayInfo object via a SetDisplayMessageRequest and the priority of the message is not supported by the Charging Station</td><td>The Charging Station SHALL send a SetDisplayMessageResponse with status: NotSupportedPriority. (See configuration variable DisplayMessageSupportedPriorities for supported priorities).</td></tr><tr><td>001.FR.02</td><td>When the Charging Station receives a DisplayInfo object via a SetDisplayMessageRequest and the state of the message is not supported by the Charging Station</td><td>The Charging Station SHALL send a SetDisplayMessageResponse with status: NotSupportedState. (See configuration variable DisplayMessageSupportedStates for supported states).</td></tr><tr><td>001.FR.03</td><td>When the Charging Station receives a DisplayInfo object via a SetDisplayMessageRequest and the format of the message is not supported by the Charging Station</td><td>The Charging Station SHALL send a SetDisplayMessageResponse with status: NotSupportedMessageFormat. (See configuration variable DisplayMessageSupportedFormats for supported formats).</td></tr><tr><td>001.FR.04</td><td></td><td>When a CSMS sends a message to a Charging Station that does not belong to a transaction, the field: transactionId in the Message field SHALL be omitted.</td></tr><tr><td>001.FR.05</td><td></td><td>The CSMS MAY include astartTime andEndTime when setting a message.</td></tr><tr><td>001.FR.06</td><td>001.FR.05</td><td>The Charging Station SHALL NOT display the DisplayMessage message before thestartTime.</td></tr><tr><td>001.FR.07</td><td>001.FR.05</td><td>The Charging Station SHALL remove a DisplayMessage message after theEndTime.</td></tr><tr><td>001.FR.08</td><td>When the Charging Station knows the language preferences of the EV Driver</td><td>The Charging Station SHALL display the DisplayMessage message in the preferred language, if available.</td></tr><tr><td>001.FR.09</td><td>001.FR.08</td><td>When no matching language is available, it is RECOMMENDED to show a DisplayMessage message in English as fall-back, if available.</td></tr><tr><td>001.FR.10</td><td></td><td>The Charging Station SHALL store the messages in persistent storage, so they survive a power cycle/reboot of the Charging Station.</td></tr><tr><td>001.FR.11</td><td>When the Charging Station receives a SetDisplayMessageRequest and the total number of messages after having handled this request will exceed NumberOfDisplayMessages.maxLimit.</td><td>The Charging Station SHALL respond with status: Rejected.</td></tr><tr><td>001.FR.12</td><td>When the Charging Station receives a SetDisplayMessageRequest and the priority of the message is NormalCycle</td><td>The Charging Station SHALL show this message at the configured moment in the normal cycle of messages.</td></tr><tr><td>001.FR.13</td><td>When the Charging Station receives a SetDisplayMessageRequest and the priority of the message is InFront</td><td>The Charging Station SHALL show this message at the configured moment, regardless of the normal cycle of messages.</td></tr><tr><td>001.FR.14</td><td>When multiple messages with priority InFront are configured to be shown at the same time</td><td>The Charging Station SHALL cycle these messages.</td></tr><tr><td>001.FR.15</td><td>When the Charging Station receives a SetDisplayMessageRequest and the priority of the message is AlwaysFront</td><td>The Charging Station SHALL show this message at the configured moment, regardless of other installed messages. Hence, it shall not cycle it with other messages and the Charging Station's own messages shall not override this message.</td></tr><tr><td>001.FR.16</td><td>001.FR.15 AND Another message with priority AlwaysFront is already set</td><td>The Charging Station SHALL replace the old message with the newly set message.</td></tr><tr><td>001.FR.17</td><td></td><td>Language SHALL be specified as RFC-5646 tags, see: [RFC5646], example: US English is: "en-US"</td></tr><tr><td>001.FR.18(2.1)</td><td>If configuration variable DisplayMessageLanguage is present AND Charging Station receives a SetDisplayMessageRequest with a message or messageExtra element in its MessageInfoType that has a language that is not in the valuesList of DisplayMessageLanguage</td><td>Charging Station SHALL respond with a SetDisplayMessageResponse with status = LanguageNotSupported.</td></tr><tr><td>001.FR.19 (2.1)</td><td>If configuration variable DisplayMessageLanguage is not present AND Charging Station receives a SetDisplayMessageRequest with a messageExtra element in its MessagingInfoType</td><td>Charging Station SHALL respond with a SetDisplayMessageResponse with status = Rejected.</td></tr></table>
+
+002 - Set DisplayMessage for Transaction
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Set DisplayMessage for Transaction</td></tr><tr><td>2</td><td>ID</td><td>002</td></tr><tr><td></td><td>Parent use case</td><td>001 - Set DisplayMessage</td></tr><tr><td>3</td><td>Objective(s)</td><td>To enable a CSO to display messages during an ongoing transaction on a Charging Station that are not build in to the firmware.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a CSO can set a message to be displayed on a Charging Station for a specific transaction. Depending on the given parameters the message shall be displayed a certain way on the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>CSO, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO configures the CSMS to send a request to show a new message during a given transaction.
+2. The CSMS sends a SetDisplayMessageRequest message with the transactionId to the Charging Station.
+3. The Charging Station accepts the request by sending a SetDisplayMessageResponse message to the CSMS.
+4. The Charging Station shows the new message on the display while the transaction is ongoing.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>001 - Set MessageMessage
+006 - Replace MessageMessage</td></tr><tr><td>5</td><td>Prerequisites</td><td>No messages configured with the same IDs.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The new message will be displayed on the Charging Station while the transaction is ongoing (time, duration and position depend on configuration)</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>The maximum number of messages that can be stored in a Charging Station can be read by the CSMS in the Configuration Variable:NumberOfDisplayMessages.maxLimit.</td></tr></table>
+
+
+Figure 176. Set DisplayMessage for transaction sequence diagram
+
+# 002 - Set DisplayMessage for Transaction - Requirements
+
+Table 145.002 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>002.FR.01</td><td>When the Charging Station receives a Message object via a SetDisplayMessageRequest and the transactionId of the message is not known by the Charging Station</td><td>The Charging Station SHALL send a SetDisplayMessageResponse with status: UnknownTransaction.</td></tr><tr><td>002.FR.02</td><td>When the transaction with the given transactionId ends</td><td>The Charging Station SHALL remove the message from the list of messages.</td></tr><tr><td>002.FR.03</td><td>When the Charging Station receives a MessagingInfo object via a SetDisplayMessageRequest and the priority of the message is not supported by the Charging Station</td><td>The Charging Station SHALL send a SetDisplayMessageResponse with status: NotSupportedPriority.</td></tr><tr><td>002.FR.04</td><td>When the Charging Station receives a MessagingInfo object via a SetDisplayMessageRequest and the state of the message is not supported by the Charging Station</td><td>The Charging Station SHALL send a SetDisplayMessageResponse with status: NotSupportedState.</td></tr><tr><td>002.FR.05</td><td>When the Charging Station receives a MessagingInfo object via a SetDisplayMessageRequest and the format of the message is not supported by the Charging Station</td><td>The Charging Station SHALL send a SetDisplayMessageResponse with status: NotSupportedMessageFormat.</td></tr><tr><td>002.FR.06</td><td></td><td>The Charging Station SHALL NOT display the DisplayMessage message before the startTime.</td></tr><tr><td>002.FR.07</td><td></td><td>The Charging Station SHALL remove a DisplayMessage message after the endTime.</td></tr><tr><td>002.FR.08</td><td>When the Charging Station knows the language preferences of the EV Driver</td><td>The Charging Station SHALL display the DisplayMessage message in the preferred language, if available.</td></tr><tr><td>002.FR.09</td><td>002.FR.08</td><td>When no matching language is available, it is RECOMMENDED to show a DisplayMessage message in English as fall-back, if available.</td></tr><tr><td>002.FR.10</td><td></td><td>The Charging Station SHALL store the messages in persistent storage, so they survive a power cycle/reboot of the Charging Station.</td></tr><tr><td>002.FR.11</td><td>When the Charging Station receives a SetDisplayMessageRequest and the total number of messages after having handled this request will exceed NumberOfDisplayMessages.maxLimit.</td><td>The Charging Station SHALL respond with status: Rejected.</td></tr><tr><td>002.FR.12</td><td></td><td>Language SHALL be specified as RFC-5646 tags, see: [RFC5646], example: US English is: "en-US"</td></tr><tr><td>002.FR.14</td><td>When the Charging Station receives a SetDisplayMessageRequest and the priority of the message is NormalCycle</td><td>The Charging Station SHALL show this message in the normal cycle of messages.</td></tr><tr><td>002.FR.15</td><td>When the Charging Station receives a SetDisplayMessageRequest and the priority of the message is InFront</td><td>The Charging Station SHALL show this message at the configured moment, regardless of the normal cycle of messages.</td></tr><tr><td>002.FR.16</td><td>When multiple messages with priority InFront are configured to be shown at the same time</td><td>The Charging Station SHALL cycle these messages.</td></tr><tr><td>002.FR.17</td><td>When the Charging Station receives a SetDisplayMessageRequest and the priority of the message is AlwaysFront</td><td>The Charging Station SHALL show this message at the configured moment, regardless of other installed messages. Hence, it shall not cycle it with other messages and the Charging Station's own message shall not override this message.</td></tr><tr><td>002.FR.18</td><td>002.FR.17 AND Another message with priority AlwaysFront is already set</td><td>The Charging Station SHALL replace the old message with the newly set message.</td></tr></table>
+
+# 003 - Get All DisplayMessages
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get All DisplayMessages</td></tr><tr><td>2</td><td>ID</td><td>003</td></tr><tr><td>3</td><td>Objective(s)</td><td>Enable a CSO to retrieve all messages currently configured in a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a CSO can request all the installed DisplayMessages configured via OCPP in a Charging Station.
+The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able to view to current list of messages, so the CSO knows which messages are (still) configured.</td></tr><tr><td></td><td>Actors</td><td>CSO, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO asks the CSMS to retrieve all messages.
+2. The CSMS sends a GetDisplayMessagesRequest message to the Charging Station.
+3. The Charging Station responds with a GetDisplayMessagesResponse Accepted, indicating it has configured messages and will send them.
+4. The Charging Station sends one or more NotifyDisplayMessagesRequest messages to the CSMS (depending on the amount of messages to be sent).
+5. The CSMS responds to every notify with a NotifyDisplayMessagesResponse message.</td></tr><tr><td>5</td><td>Prerequisites</td><td>There is at least one message configured in the Charging Station</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>Only messages configured via OCPP can be retrieved via a GetDisplayMessagesRequest.</td></tr></table>
+
+
+Figure 177. Get All DisplayMessages sequence diagram
+
+# 003 - Get All DisplayMessages - Requirements
+
+Table 146.003 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>003.FR.01</td><td>When all fields except requestId in a GetDisplayMessagesRequest are omitted AND at least one display message is configured.</td><td>The Charging Station SHALL respond with Accepted.</td></tr><tr><td>003.FR.02</td><td>003.FR.01</td><td>The Charging Station SHALL send all configured DisplayMessages via NotifyDisplayMessagesRequest.</td></tr><tr><td>003.FR.03</td><td>003.FR.02 AND There are more DisplayMessages than the Charging Station can send in 1 NotifyDisplayMessagesRequest</td><td>The Charging Station SHALL split the DisplayMessages over multiple NotifyDisplayMessagesRequest messages.</td></tr><tr><td>003.FR.04</td><td>003.FR.03</td><td>The Charging Station SHALL set the tbc field is true in every NotifyDisplayMessagesRequest messages, except the last.</td></tr><tr><td>003.FR.05</td><td>003.FR.04</td><td>The Charging Station SHALL set the requestId field to the same value as the requestId in the GetDisplayMessagesRequest.</td></tr><tr><td>003.FR.06</td><td>When NO DisplayMessages are configured</td><td>The Charging Station SHALL respond with Unknown.</td></tr></table>
+
+# 004 - Get Specific DisplayMessages
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Get Specific DisplayMessages</td></tr><tr><td>2</td><td>ID</td><td>004</td></tr><tr><td>3</td><td>Objective(s)</td><td>Enable a CSO to retrieve one or more specific DisplayMessages, currently configured in a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a CSO can request/query for (specific) DisplayMessage, configured via OCPP in a Charging Station. The Charging Station can remove messages when they are out-dated, or transactions have ended. It can be very useful for a CSO to be able query the Charging Station for installed DisplayMessages, so the CSO known which messages are (still) configured.</td></tr><tr><td></td><td>Actors</td><td>CSO, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO asks the CSMS to query for DisplayMessages.
+2. The CSMS sends a GetDisplayMessagesRequest message with the query parameters to the Charging Station.
+3. When the Charging Station has DisplayMessages that match the requested parameters, it responds with GetDisplayMessagesResponse Accepted.
+4. The Charging Station sends one or more NotifyDisplayMessagesRequest message to the CSMS (depending on the amount of messages to be send).
+5. The CSMS response every notify with a NotifyDisplayMessagesResponse message.</td></tr><tr><td>5</td><td>Prerequisites</td><td>There is a message with the given id configured in the Charging Station</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>n/a</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>Only message configured via OCPP can be retrieved via GetDisplayMessagesRequest.</td></tr></table>
+
+
+Figure 178. Get a specific DisplayMessages sequence diagram
+
+# 004 - Get Specific DisplayMessage - Requirements
+
+Table 147.004 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>004.FR.01</td><td>When one or more of the fields in a GetDisplayMessagesRequest are used AND The Charging Station has DisplayMessages configured that match the parameters in the request</td><td>The Charging Station SHALL respond with Accepted.</td></tr><tr><td>004.FR.02</td><td>When one or more of the fields in a GetDisplayMessagesRequest are used AND The Charging Station has NO DisplayMessages configured that match the parameters in the request</td><td>The Charging Station SHALL respond with Unknown.</td></tr><tr><td>004.FR.03</td><td>004.FR.01</td><td>The Charging Station SHALL send all configured DisplayMessages via NotifyDisplayMessagesRequest.</td></tr><tr><td>004.FR.04</td><td>004.FR.03 AND There are more DisplayMessages than the Charging Station can send in 1 NotifyDisplayMessagesRequest</td><td>The Charging Station SHALL split the DisplayMessages over multiple NotifyDisplayMessagesRequest messages.</td></tr><tr><td>004.FR.05</td><td>004.FR.04</td><td>The Charging Station SHALL set the tbc field is true in every NotifyDisplayMessagesRequest messages, except the last.</td></tr><tr><td>004.FR.06</td><td>004.FR.05</td><td>The Charging Station SHALL set the requestId field to the same value as the requestId in the GetDisplayMessagesRequest.</td></tr><tr><td>004.FR.07</td><td>When NO DisplayMessages are configured</td><td>The Charging Station SHALL respond with Unknown.</td></tr></table>
+
+# 005 - Clear a DisplayMessage
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Clear a DisplayMessage</td></tr><tr><td>2</td><td>ID</td><td>005</td></tr><tr><td>3</td><td>Objective(s)</td><td>Enable a CSO to remove a specific message, currently configured in a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a CSO can remove a specific message, configured via OCPP in a Charging Station.</td></tr><tr><td></td><td>Actors</td><td>CSO, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO asks the CSMS to remove a specific message.
+2. The CSMS sends a ClearDisplayMessageRequest message with the id of the specific message to the Charging Station.
+3. The Charging Station removes the message.
+4. The Charging Station response by sending a ClearDisplayMessageResponse message to the CSMS.</td></tr><tr><td>5</td><td>Prerequisites</td><td>There is a message with the given id configured in the Charging Station</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The message with the given id is removed from the Charging Station</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>Only messages configured via OCPP can be cleared/removed via ClearDisplayMessageRequest</td></tr></table>
+
+
+Figure 179. Clear a DisplayMessage sequence diagram
+
+# 005 - Clear a DisplayMessage - Requirements
+
+Table 148.005 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>005.FR.01</td><td>When a Charging Station receives a ClearDisplayMessageRequest AND there is a message configured in the Charging Station with that id</td><td>The Charging Station SHALL respond with a ClearDisplayMessageResponse message with status: Accepted.</td></tr><tr><td>005.FR.02</td><td>When a Charging Station receives a ClearDisplayMessageRequest AND there is no message configured in the Charging Station with the given id</td><td>The Charging Station SHALL respond with a ClearDisplayMessageResponse message with status: Unknown.</td></tr><tr><td>005.FR.03 (2.1)</td><td>When a Charging Station receives a ClearDisplayMessageRequest AND Charging Station is not able to execute the request</td><td>The Charging Station SHALL respond with a ClearDisplayMessageResponse message with status: Rejected.</td></tr></table>
+
+006 - Replace DisplayMessage
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Replace DisplayMessage</td></tr><tr><td>2</td><td>ID</td><td>006</td></tr><tr><td>3</td><td>Objective(s)</td><td>Enable a CSO to replace DisplayMessages, already configured on a Charging Station.</td></tr><tr><td>4</td><td>Description</td><td>This use case describes how a CSO can replace a DisplayMessage that is previously configured in a Charging Station. Replace the message content, but also all the given parameters with the new one.</td></tr><tr><td></td><td>Actors</td><td>CSO, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSO asks the CSMS to replace an existing DisplayMessage.
+2. The CSMS sends a SetDisplayMessageRequest message to the Charging Station with the a DisplayMessage with the same ID as already configured in the Charging Station.
+3. The Charging Station accepts the request by sending a SetDisplayMessageResponse message to the CSMS.
+4. The Charging Station shows the updated/replaced message on the display at the configured moment.</td></tr><tr><td></td><td>Alternative scenario(s)</td><td>001 - Set DisplayMessage and 002 - Set DisplayMessage for Transaction</td></tr><tr><td>5</td><td>Prerequisites</td><td>There is a message with the same id configured in the Charging Station</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>The DisplayMessage is replaced by the one provided with the same ID.</td></tr><tr><td>7</td><td>Error Handling</td><td>n/a</td></tr><tr><td>8</td><td>Remarks</td><td>n/a</td></tr></table>
+
+
+Figure 180. Replace DisplayMessage sequence diagram
+
+# 006 - Replace DisplayMessage - Requirements
+
+Table 149.006 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>006.FR.01</td><td>When a Charging Station receives a SetDisplayMessageRequest AND there is a message configured in the Charging Station with the same id</td><td>The Charging Station SHALL replace the existing message with the new message (including all the new parameters) AND respond with a SetDisplayMessageResponse message with status: Accepted for this message.</td></tr></table>
+
+# P. DataTransfer
+
+# Chapter 1. Introduction
+
+This Functional Block describes the functionality that enables parties to extend existing commands with custom attributes or add new custom commands to OCPP
+
+OCPP offers two mechanisms to create vendor-specific custom extension.
+
+1. The DataTransferRequest message allows for the exchange of data or messages not standardized in OCPP. As such, it offers a framework within OCPP for experimental functionality that may find its way into future OCPP versions. Experimenting can be done without creating new (possibly incompatible) OCPP dialects. Secondly, it offers a possibility to implement additional functionality agreed upon between specific CSMS and Charging Station vendors.
+2. A CustomData element exists as an optional element in the JSON schemas of all types. CustomData is the only class in the JSON schema files that allows additional properties. It can thus be used to add additional custom attributes to any type. The CustomData has been deliberately left out of the specification document, because it would introduce a lot of clutter and it is not meant to be used in standard implementations. See also [OCPP2.1-PART4].
+
+The DataTransferRequest/Response contains a field without a length or type specification. It can be convenient to use this field as structured JSON content.
+
+Example of embedded JSON
+
+```txt
+[2,
+"unique msg id>","DataTransfer",
+{ "vendorId": "com.mycompany.ice", "messageId": "iceParkedAtCs" "data": { "start_time": "2020-04-01T11:01:02" }
+]
+```
+
+# IMPORTANT
+
+Please use with extreme caution and only for optional functionality, since it will impact your compatibility with other systems that do not make use of this option. We recommend mentioning the usage explicitly in your documentation and/or communication. Please consider consulting the Open Charge Alliance before turning to this option to add functionality.
+
+# Chapter 2. Use cases & Requirements
+
+P01 - Data Transfer to the Charging Station
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Data Transfer to the Charging Station</td></tr><tr><td>2</td><td>ID</td><td>P01</td></tr><tr><td>3</td><td>Objective(s)</td><td>To send information from the CSMS to the Charging Station for a function that is not supported by OCPP.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers the functionality of sending a DataTransfer message to the Charging Station from the CSMS.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS sends information to a Charging Station for a function not supported by OCPP with DataTransferRequest.
+2. The Charging Station responds to the CSMS with DataTransferResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+DataTransferRequest is received Successfully and Accepted
+Failure postcondition:
+Message has been Accepted but the contained request is Rejected.
+In all other cases the usage of status Accepted or Rejected and the data element is part of the vendor-specific agreement between the parties involved.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Data Transfer is used if information for a function is not supported by OCPP.
+The length of data in both the request and response message is undefined and it is RECOMMENDED that this is agreed upon by all parties involved.</td></tr></table>
+
+
+Figure 181. Sequence Diagram: Data Transfer to the Charging Station
+
+# P01 - Data Transfer to the Charging Station - Requirements
+
+Table 150. P01 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>P01.FR.01</td><td></td><td>The Charging Station SHALL only use DataTransferRequest for a function which is not supported by OCPP.</td></tr><tr><td>P01.FR.02</td><td></td><td>The vendorId SHOULD be a value from the reversed DNS namespace, where the top tiers of the name, when reversed, should correspond to the publicly registered primary DNS name of the Vendor organization.</td></tr><tr><td>P01.FR.03</td><td></td><td>The messageld in the request message MAY be used to indicate a specific message or implementation.</td></tr><tr><td>P01.FR.04</td><td></td><td>The length of data in both the request and response message is undefined and it is RECOMMENDED that this is agreed upon by all parties involved.</td></tr><tr><td>P01.FR.05</td><td>If the recipient of the request has no implementation for the specific vendorId.</td><td>The recipient SHALL return a status UnknownVendor.</td></tr><tr><td>P01.FR.06</td><td>Upon receipt of DataTransferRequest and in case of a msgageld mismatch (if used).</td><td>The recipient SHALL return status UnknownMessageId.</td></tr><tr><td>P01.FR.07</td><td></td><td>The usage of status Accepted or Rejected and the data element SHALL be part of the vendor-specific agreement between the parties involved.</td></tr></table>
+
+P02 - Data Transfer to the CSMS
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Data Transfer to the CSMS</td></tr><tr><td>2</td><td>ID</td><td>P02</td></tr><tr><td>3</td><td>Objective(s)</td><td>To send information from the Charging Station to the CSMS for a function which is not supported by OCPP.</td></tr><tr><td>4</td><td>Description</td><td>This use case covers the functionality of sending a DataTransfer message to the CSMS from the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends information to the CSMS for a function not supported by OCPP with DataTransferRequest.
+2. The CSMS responds to the Charging Station with DataTransferResponse.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>n/a</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Successful postcondition:
+DataTransferRequest is received Successfully and Accepted
+Failure postcondition:
+Message has been accepted but the contained request is Rejected.
+In all other cases the usage of status Accepted or Rejected and the data element is part of the vendor-specific agreement between the parties involved.</td></tr><tr><td>7</td><td>Error handling</td><td>n/a</td></tr><tr><td>8</td><td>Remark(s)</td><td>Data Transfer is used if information for a function is not supported by OCPP.
+The length of data in both the request and response message is undefined and should be agreed upon by all parties involved.</td></tr></table>
+
+
+Figure 182. Sequence Diagram: Data Transfer to the CSMS
+
+# P02 - Data Transfer to the CSMS - Requirements
+
+Table 151. P02 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td></tr><tr><td>P02.FR.01</td><td></td><td>The vendorId in the request message SHOULD be known to the Charging Station and uniquely identify the vendor-specific implementation.</td></tr><tr><td>P02.FR.02</td><td></td><td>The Charging Station SHALL only use DataTransferRequest for a function which is not supported by OCPP. (Same as P01.FR.01)</td></tr><tr><td>P02.FR.03</td><td></td><td>The VendorId SHOULD be a value from the reversed DNS namespace, where the top tiers of the name, when reversed, should correspond to the publicly registered primary DNS name of the Vendor organization. (Same as P01.FR.02)</td></tr><tr><td>P02.FR.04</td><td></td><td>The msgageld in the request message MAY be used to indicate a specific message or implementation. (Same as P01.FR.03)</td></tr><tr><td>P02.FR.05</td><td></td><td>The length of data in both the request and response message is undefined and it is RECOMMENDED that this is agreed upon by all parties involved. (Same as P01.FR.04)</td></tr><tr><td>P02.FR.06</td><td>If the recipient of the request has no implementation for the specific vendorId.</td><td>The recipient SHALL return a status UnknownVendor.</td></tr><tr><td>P02.FR.07</td><td>Upon receipt of DataTransferRequest and in case of a msgageld mismatch (if used).</td><td>The recipient SHALL return status UnknownMessageId.</td></tr><tr><td>P02.FR.08</td><td></td><td>The usage of status Accepted or Rejected and the data element SHALL be part of the vendor-specific agreement between the parties involved. (Same as P01.FR.07)</td></tr></table>
+
+# Q. Bidirectional Power Transfer
+
+# Chapter 1. Introduction
+
+This document describes the communication between charging station and CSMS to allow support for bidirectional charging when either CHAdeMO or ISO 15118-20 is used for the communication between the EV and charging station.
+
+This document uses the abbreviation V2X (vehicle-to-anything) for bidirectional power transfer between an EV and the grid (V2G), a home (V2H), a building (V2B) or an appliance (V2L). In the context of OCPP V2L can be ignored, because that does not involve any OCPP communication. V2H and V2B are specialized cases of V2G that are about using the EV battery to power a home or building, either to limit or prevent power consumption from the grid, or the provide power in case of a grid outage.
+
+The remainder of this document does not use the abbreviation V2G for vehicle-to-grid or bidirectional power transfer to avoid any confusion with the same term that is used in ISO 15118, where it refers to the vehicle to charging station communication.
+
+# Chapter 2. Smart Charging Extensions for V2X
+
+Support for bidirectional charging builds upon the smart charging functionality of OCPP, as described in Introduction. Charging schedules in a charging profile have been extended with additional attributes to control discharging operations.
+
+# 2.1. Setpoint and charge/discharge limits
+
+A schedule entry ChargingSchedulePeriodType has three fields to influence the charging or discharging. These settings are in Watts or Amperes, as defined by the chargingRateUnit of the ChargingScheduleType.
+
+1. setpoint: the target value for either charging or discharging depending on the sign. Positive values indicate charging, while negative values indicate discharging.
+2. limit: the maximum allowed charging limit. Positive values only.
+3. dischargeLimit: the maximum allowed discharging limit. Negative values only.
+
+
+Figure 183. Example of using setpoint and limit/dischargingLimit
+Usage example of limit/dischargeLimit and setpoint
+
+# 2.2. V2X operation modes
+
+The various V2X use cases support different kinds of operations. For example, the charging profile can define a setpoint to follow that defines the level of charging or discharging. In other situations there can be an external system, like an EMS, that defines the setpoint, or the charging profile can instruct the charging station to use local data, like a power-frequency table or load-balancing thresholds, to control the setpoint.
+
+This mode of operation is defined by the variable OperationMode that is part of a ChargingSchedulePeriodType
+
+The following operation modes exist, of which the first four are also used for regular smart charging, as described in Introduction.
+
+1. ChargingOnly
+2. ExternalSetpoint
+3. ExternalLimits
+4. CentralSetpoint
+5. CentralFrequency
+6. LocalFrequency
+
+7. LocalLoadBalancing
+8. Idle
+
+# ChargingOnly
+
+This operation mode allows charging only, therefore is not bidirectional at all. This is also the default operation mode when the field operationMode is missing. It is added especially for Charging Stations that intent to operate in V2X, but are unsure during energy service negotiation if the EV and EV user are allowed to operate in V2X at this time and location. The EV then starts in this operation mode, waiting for authorization of the V2X operation mode. When V2X is authorized, a service negotiation needs to be performed between EV and charging station to start using actual V2X operation modes.
+
+The field limit is used to specify the maximum allowed charging limit. The fields setpoint and dischargeLimit are not used.
+
+# ExternalSetpoint
+
+This control mode tells the charging station that the setpoint parameter is to be determined by some external actor, such as an EMS. A setpoint is a charging rate that the EV must try to follow as closely as possible.
+
+Behavior is identical to the description of ExternalSetpoint in Introduction, with the exception that setpoint can become negative to specify a discharging setpoint. Optionally the parameters limit and dischargeLimit can be set by CSMS to limit the range of the external setpoint.
+
+# ExternalLimits
+
+This control mode is similar to ExternalSetpoint with the difference that it is not the setpoint that is controlled, but it is the limit and dischargingLimit parameters that are determined by the external actor, such as an EMS.
+
+# CentralSetpoint
+
+In this case CSMS provides a value for setpoint in the charging schedule period. A setpoint is a charging rate that the EV must try to follow as closely as possible. Positive values for setpoint represent charging, negative values represent discharging.
+
+If the chargingProfileKind = Dynamic, then the value of setpoint can be changed by CSMS during the charging schedule period via an UpdateDynamicScheduleRequest without having to submit a new charging profile.
+
+The parameters limit and dischargeLimit are not used.
+
+# LocalFrequency
+
+LocalFrequency is the operation mode during which the EV takes part in frequency containment reserve (FCR) services or automatic Frequency Restoration Reserve (aFRR).
+
+# FCR
+
+FCR is a type of balancing service that is used to maintain the stability and reliability of the electricity grid. Also known as primary control reserve, it is activated when the frequency of the grid deviates from its normal operating range. When frequency deviations occur, for example, as a consequence of a power plant outage, FCR intervenes automatically within seconds in the entire synchronous area to restore the balance between supply and demand.
+
+The power setpoint for frequency support is determined from a power/frequency (Freq-Watt) curve, based on the locally measured frequency. This operation mode requires that the chargingRateUnit of the ChargingScheduleType is $\overline{\mathbb{W}}$ , so that setpoint refers to power. The power/frequency curve might be different for various locations and is therefore provided as a field in ChargingSchedulePeriodType: v2xFreqWattCurve, which contains a list of at least two V2XFreqWattPointType coordinates.
+
+Values for power in between the given frequency levels are to be determined locally by linear interpolation.
+
+The power setpoint is depending on the frequency reading in the charging station:
+
+$$
+\text {s e t p o i n t} = \text {g e t p o w e r f r o m P / F t a b l e (F r e q u e n c y)}
+$$
+
+Example P/F table:
+
+
+Figure 184. Example P/F table
+
+```txt
+# example FCR table
+"v2xFreqWattCurve": {{47, -10000}, {49.80, -10000}, {49.99, -500}, {49.991, 0}, {50, 0}, {50.009, 0}, {50.01, 500}, {50.20, 10000}, {53, 10000}]
+```
+
+# aFRR
+
+The second form of balancing energy is automatic Frequency Restoration Reserve (aFRR). As the secondary reserve, aFRR gradually replaces FCR after 30 seconds. Once activated by the grid operator, the power must be fully available within 15 minutes, with a certain minimum ramp rate (e.g. $20\%$ ) of the offered power/min, and be able to follow a new setpoint every few seconds. It is therefore the most demanding balancing reserve product. Operators with sufficiently large energy generation or consumption can offer both upward and downward aFRR.
+
+The aFRR capacity is activated by a signal from the TSO to the CSO. The signal is passed on to affected charging stations via the AFRRSignalRequest message. The amount of upward or downward aFRR for a charging station is set in the v2xSignalWattCurve element in the ChargingSchedulePeriodType.
+
+```txt
+example aFRR table "v2xSignalWattCurve": $\left[\{-1, - 2000\} ,\{0,0\} ,\{1,2000\}\right]$
+```
+
+# CentralFrequency
+
+CentralFrequency is similar to LocalFrequency, only in this case the setpoint for frequency support is determined by the CSMS. This is used, for instance, when costly calibrated frequency measurements are to be used that can not be installed in each charging station. This needs to be used in a charging profile with chargingProfileKind = Dynamic, such that CSMS can continually update the setpoint when the frequency changes via the UpdateDynamicScheduleRequest.
+
+When the charging station does not receive a new setpoint within time, then the charging profile terminates, allowing the charging station to fall back to a charging profile with a lower stack level with a different operation mode.
+
+# LocalLoadBalancing
+
+This operation mode allows an EV to be utilized for load balancing, for example for a building that both consumes energy and produces energy from solar panels.
+
+Because the charging station can read the smart energy meter of the building, the charging station and EV setup can influence the resulting load on the grid connection.
+
+
+Figure 185. Diagram of a local load-balancing setup
+
+For this operation mode there are four configurable keys:
+
+1. UpperThreshold, threshold level for the measured load at which the EV will start to compensate the power of the load in order to avoid exceeding the threshold (by discharging).
+2. LowerThreshold, threshold level for the measured load at which the EV will start to compensate the power of the load in order to avoid passing below the threshold (by charging).
+3. UpperOffset, the amount by which the load is compensated more (or less) than the upper threshold.
+4. LowerOffset, the amount by which the load is compensated more (or less) than the lower threshold.
+
+All these keys can have either positive or negative values, as long as UpperThreshold > LowerThreshold. The values of LowerOffset and UpperOffset are relative to LowerThreshold and UpperThreshold.
+
+To better understand what possible usages of this operation mode can be, here are some examples:
+
+1. When both LowerOffset and UpperOffset are set to zero, then the schedule will aim to keep the load exactly between LowerThreshold and UpperThreshold.
+2. When UpperThreshold = 10 kW with UpperOffset = +1 kW and LowerThreshold = -5 kW with LowerOffset = -1 kW, then the schedule will aim to keep the load between +11 kW and -6 kW.
+
+```python
+Load = get latest load power reading()
+If Load > UpperThreshold
+ DeltaSetpoint = UpperThreshold + UpperOffset - Load
+Else If Load < LowerThreshold
+ DeltaSetpoint = LowerThreshold + LowerOffset - Load
+Else
+ DeltaSetpoint = 0
+setpoint = setpoint + DeltaSetpoint
+```
+
+The determined setpoint in the V2X schedule entry is always to be limited by limit (when positive) or dischargeLimit (when negative).
+
+
+Figure 186. Graphs of measured load and compensating setpoint
+
+
+Figure 187. Graph of resulting power import/export
+
+Two configurable threshold values V2XLocalLoadBalancing[UpperThreshold] and V2XLocalLoadBalancing[LowerThreshold] are used so the capacity controller in the charging station can limit the power imported from the grid and/or exported to the grid.
+
+# Idle
+
+This operation mode is used when the EV is to be idle, in order to minimize the energy used by the EV for a period of time.
+
+The field preconditioningRequest is used to indicate if the EV can go to sleep completely, or should be on standby. The difference between sleeping and standby is that when sleeping, the EV is not expected to react quickly to a new schedule, while for standby it is expected that the EV can quickly start charging or discharging, when for example a new schedule is sent from the CSMS to the charging station.
+
+# Limits and setpoints per operation mode
+
+The following table lists the charging limits and setpoints that can be set for each charging mode.
+
+<table><tr><td>limits and setpoints per operation mode</td><td>limit</td><td>dischargeLimit</td><td>setpoint</td><td>setpoint-Reactive</td></tr><tr><td>ChargingOnly</td><td>required</td><td>-</td><td>-</td><td>-</td></tr><tr><td>CentralSetpoint</td><td>optional</td><td>optional</td><td>required</td><td>optional</td></tr><tr><td>CentralFrequency</td><td>optional</td><td>optional</td><td>required</td><td>-</td></tr><tr><td>LocalFrequency</td><td>-</td><td>-</td><td>calculated from freq/signal curves</td><td>-</td></tr><tr><td>ExternalSetpoint</td><td>optional</td><td>optional</td><td>set externally</td><td>-</td></tr><tr><td>ExternalLimits</td><td>set externally</td><td>set externally</td><td>-</td><td>-</td></tr><tr><td>LocalLoadBalancing</td><td>-</td><td>-</td><td>calculated from load and thresholds/offsets</td><td>-</td></tr></table>
+
+# 2.3. Switching V2X operation modes
+
+The V2X operation mode is defined per ChargingSchedulePeriodType. This means that you can have a different V2X operation mode per period in a charging profile. Although this is not a likely scenario, there may be situations where it is known in advance that certain hours of the day are "ChargingOnly" and other are "LocalLoadBalancing" or "CentralSetpoint".
+
+In many cases, though, a change of V2X operation mode is based on circumstances and cannot be planned. In that case the charging profile will have to be replaced with a new charging profile that contains a new charging schedule with the desired V2X operation mode.
+
+It is not uncommon that a charging schedule contains only one charging schedule period, because the setpoint or limits are determined dynamically during the period. This is the case, for example, with LocalFrequency, ExternalSetpoint, ExternalLimits and LocalLoadBalancing.
+
+# 2.4. Residual measurand
+
+With the new measurand Power.Active.Residual the CSMS can easily monitor if the measured power is within margin of the power setpoint. When the residual is positive it is charging or discharging at a higher power than the given power setpoint, when negative it is charging or discharging at a lower power than the given power setpoint.
+
+The power residuals are calculated by:
+
+```txt
+If Power.Active.Setpoint is None:
+ Power.Active.Residual = 0
+If Power.Active.Setpoint == 0:
+ Power.Active.Residual = Power.Active.Import + Power.Active.Import
+If Power.Active.Setpoint > 0:
+ Power.Active.Residual = Power.Active.Import - Power.Active.Setpoint
+If Power.Active.Setpoint < 0:
+ Power.Active.Residual = Power.Active.Import + Power.Active.Setpoint
+```
+
+2.5. Generic smart charging rules for V2X
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>V2X.01</td><td></td><td>All requirements from section Introduction also apply to V2X</td><td></td></tr><tr><td>V2X.02</td><td></td><td>A setpoint (or setpointReactive) in a charging profile is a value that EV is supposed to follow as closely as possible.</td><td>In contrast to a limit which only specifies the maximum power that is allowed.</td></tr><tr><td>V2X.03</td><td>If a ChargingSchedulePeriodType of the composite schedule contains a positive setpoint as well as a limit</td><td>Charging Station SHALL cap (i.e. not exceed) the setpoint for power towards EV to the value of limit.</td><td>E.g. if setpoint = 2000 W and limit = 1000 W, then the setpoint communicated to EV is 1000 W. When chargingRateUnit = A then limit is about current instead of power.</td></tr><tr><td>V2X.04</td><td>If a ChargingSchedulePeriodType of the composite schedule contains a negative setpoint as well as a dischargingLimit</td><td>Charging Station SHALL cap (i.e. not go below) the setpoint for discharging power towards EV to the value of dischargingLimit.</td><td>E.g. if setpoint = -2000 W and dischargingLimit = -1000 W, then the setpoint communicated to EV is -1000 W. This does not apply to setpointReactive. When chargingRateUnit = A then limit is about current instead of power.</td></tr><tr><td>V2X.05</td><td>Upon receiving a SetChargingProfileRequest with a ChargingSchedulePeriodType in which the value of setpoint lies outside the range from dischargingLimit to limit</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status = Rejected and reasonCode = InvalidSchedule</td><td>E.g. Reject if setpoint = -750 W when limit = 1000 W and dischargingLimit = -500 W.</td></tr></table>
+
+# Chapter 3. Use Cases & Requirements
+
+# Q01 - V2X Authorization
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>V2X Authorization</td></tr><tr><td>2</td><td>ID</td><td>Q01</td></tr><tr><td>3</td><td>Objective(s)</td><td>Authorization of an EV by the CSMS to start a V2X power transfer loop.</td></tr><tr><td>4</td><td>Description</td><td>Upon authorization the EV receives a list of allowed energy transfers from CSMS. The EV will select the desired energy transfer from that list and report it to CSMS.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS (possibly a secondary actor such as an aggregating party)</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends a AuthorizationRequest with EVCCID of EV in additionalInfo of idToken.
+a. The CSMS returns an AuthorizationResponse with idTokenInfo.status = Accepted and the list allowedEnergyTransfer for this EV.
+2. The Charging Station sends a TransactionEventRequest, with eventType set to Started
+a. The CSMS will respond with the TransactionEventResponse.
+3. The EV and Charging station agree on an energy transfer method.
+4. The Charging Station sends NotifyEVChargingNeedsRequest with the chosen requestedEnergyTransfer (and optionally the availableEnergyTransfer list), together with v2xcChargingParameters, departureTime and a ControlModeEnumType.
+a. The CSMS will respond with the NotifyEVChargingNeedsResponse message, with status set to Accepted.
+5. The CSMS will send the SetChargingProfileRequest message to the Charging Station with a charging schedule containing a V2X operationMode other than ChargingOnly.
+a. The Charging Station will respond with the SetChargingProfileResponse message.
+6. The Charging Station will send its parameters on charging and discharging to the EV.
+7. The EV will request to start V2X power transfer.
+a. The Charging station will accept to start V2X power transfer.</td></tr><tr><td></td><td>Scenario description #2</td><td>When CSMS decides to rely on a TxDefaultProfile with a charging schedule containing a V2X operationMode other than ChargingOnly:
+Steps 1 to 3 as above.
+4. The Charging Station sends NotifyEVChargingNeedsRequest with the chosen requestedEnergyTransfer (and optionally the availableEnergyTransfer list), together with v2xcChargingParameters, departureTime and a ControlModeEnumType.
+a. The CSMS will respond with the NotifyEVChargingNeedsResponse message, with status set to NoChargingProfile, to signal that no SetChargingProfileRequest is to be expected.
+5. The Charging Station uses the TxDefaultProfile.
+6. The Charging Station will send its parameters on charging and discharging to the EV.
+7. The EV will request to start V2X power transfer.
+a. The Charging station will accept to start V2X power transfer.</td></tr><tr><td>5</td><td>Prerequisites</td><td>ISO15118Ctrl.Enabled = true and V2XChargingCtrl.Enabled = true</td></tr><tr><td>6</td><td>Post conditions</td><td></td></tr><tr><td>7</td><td>Error Handling</td><td>When requestedEnergyTransfer is NOT accepted by the CSMS:1. The Charging Station uses the NotifyEVChargingNeedsRequest message to send the chosen requestedEnergyTransfer to the CSMS.2. The CSMS will respond with the NotifyEVChargingNeedsResponse message, with status set to Rejected.3. The Charging Station will stop the current transaction.</td></tr><tr><td>8</td><td>Remarks</td><td>A V2X energy transfer may likely require authorization from a third party (e.g. the eMSP). When Charging Station requests a V2X energy service, there is a possibility that the CSMS cannot allow that energy service within the timeout of the EV. It can then only Reject it and the transaction will stop. It is therefore advised to always start by requesting a ChargingOnly energy service, but indicate that the V2X service is available for this EV. Once the Charging Station receives the allowedEnergyTransfer including the V2X service from the CSMS, there can be a service renegotiation to change to the V2X service.The ISO 15118 EVCCID of the EV is available in the device model as the variable VehicleId from the component ConnectedEV, if that is needed by the operator to determine whether to allow V2X operations. In some cases the EVCCID may be used as an idToken for authorization, or it can be added to the additionalInfo field of the idToken that is used for authorization.</td></tr></table>
+
+# NOTE
+
+The ISO 15118-20 ScheduleExchangeReq has a timeout of 2s, but this can be prolonged up to 1 minute if the Charging Station returns a ScheduleExchangeRes(EVSEProcessing = Ongoing) response before the 2s timeout. This will trigger the EV to send another ScheduleExchangeReq() to which the Charging Station can eventually respond with ScheduleExchangeRes(EVSEProcessing = Finished) once the NotifyEVChargingNeedsRequest/Response and SetChargingProfileRequest/Response have been exchanged between Charging Station and CSMS.
+
+
+Figure 188. V2X Authorization
+
+# Q01 - V2X Authorization - Requirements
+
+Table 152. Q01 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td colspan="4">AllowedEnergyTransfer / RequestedEnergyTransfer</td></tr><tr><td>Q01.FR.01</td><td>When Charging Station's ISO15118Ctrlr.Enabled = true and V2XChargingCtrlr.Enabled = true AND CSMS receives an AuthorizationRequest AND CSMS is able to determine a list of allowedEnergyTransfer before sending the AuthorizationResponse</td><td>CSMS SHALL return a list of allowedEnergyTransfer in AuthorizationResponse.</td><td>No need to return allowedEnergyTransfer for non-15118 stations or non-V2X capable stations.</td></tr><tr><td>Q01.FR.02</td><td>When Charging Station starts an ISO 15118-20 transaction</td><td>Charging Station SHALL add EVCCID to idToken in TransactionRequest(eventType=Started) in idToken(additionalInfo.additionalIden and with idToken.additionalInfo.type set to "EVCCID".</td><td>This transaction may become bidirectional. This is needed in case CSMS uses the EVCCID of vehicle to decide whether to allow V2X.</td></tr><tr><td>Q01.FR.03</td><td>Q01.FR.02</td><td>Charging Station SHALL send a NotifyEVChargingNeedsRequest with evseld set to the EVSE used for this transaction AND the requestedEnergyTransfer set to the type that has been agreed between EV and Charging Station AND a list of availableEnergyTransfer that is supported by EV AND the fields controlMode, v2xChargingParameters and optionally departureTime, mobilityNeedsMode and evEnergyOffer.</td><td></td></tr><tr><td>Q01.FR.04</td><td>If CSMS does not accept the requestedEnergyTransfer</td><td>CSMS SHALL respond with a NotifyEVChargingNeedsResponse with status = Rejected.</td><td>Charging station will then stop the transaction.</td></tr><tr><td>Q01.FR.05</td><td>Q01.FR.04</td><td>Charging Station SHOULD start a service renegotiation with EV for a different energy transfer service</td><td>This situation should not occur when an energy transfer is selected from the allowedEnergyTransfer list in the AuthorizationResponse.</td></tr><tr><td>Q01.FR.06</td><td>Q01.FR.04 AND Charging Station did not start a service renegotiation</td><td>Charging Station SHALL terminate the transaction and send a TransactionRequest with eventType=Ended, triggerReason =AbnormalCondition, stoppedReason=ReqEnergyTransf erRejected.</td><td>This is an error situation, because energy service did not match allowedEnergyTransfer.</td></tr><tr><td>Q01.FR.07</td><td>If CSMS accepts the requestedEnergyTransfer</td><td>CSMS SHALL respond with a NotifyEVChargingNeedsResponse with status = Accepted or Processing.</td><td>Charging station can expect to receive a charging profile immediately or soon.</td></tr><tr><td>Q01.FR.08</td><td>Q01.FR.01 AND CSMS is not able to determine a list of allowedEnergyTranfer before sending the AuthorizationResponse</td><td>CSMS SHALL omit allowedEnergyTransfer from AuthorizationResponse.</td><td>This can happen if it could not be determined within the short time span before the response has to be returned, e.g. because a third party has to be requested for permission.</td></tr><tr><td>Q01.FR.09</td><td>Q01.FR.20</td><td>Charging Station SHALL send a NotifyEVChargingNeedsRequest with evseld set to the EVSE used for this transaction and requestedEnergyTransfer set to its default energy transfer (charging only AC/DC) and availableEnergyTransfer set to the supported energy transfers.</td><td>Depending on type of EVSE this will be AC_single_phase, AC_two_phase, AC_three_phase or DC, DC_ACDP</td></tr><tr><td colspan="4">Device model</td></tr><tr><td>Q01.FR.30</td><td></td><td>Charging Station SHALL report the operation modes that it supports in V2XChargingCtrl SupportedOperationModes</td><td></td></tr><tr><td>Q01.FR.31</td><td></td><td>Charging Station SHALL at least support the operation modes ChargingOnly, CentralSetpoint and CentralFrequency.</td><td>CentralFrequency is basically a CentralSetpoint for a specific use case.</td></tr><tr><td>Q01.FR.32</td><td></td><td>Charging Station SHALL report the energy transfer modes that it supports in V2XChargingCtrlrSupportedEnergyTransferModes</td><td></td></tr><tr><td>Q01.FR.33</td><td>When V2XChargingCtrlrTxStartedMeasurands is defined for the instance matching the operationMode of the current ChargingSchedulePeriodType</td><td>Charging Station SHALL include those measurands in meterValues of TransactionEventRequest in addition to measurands already defined in SampledDataCtrlrTxStartedMeasurands.</td><td></td></tr><tr><td>Q01.FR.34</td><td>When V2XChargingCtrlrTxEndedMeasurands is defined for the instance matching the operationMode of the current ChargingSchedulePeriodType</td><td>Charging Station SHALL include those measurands in meterValues of TransactionEventRequest in addition to measurands already defined in SampledDataCtrlrTxEndedMeasurands.</td><td></td></tr><tr><td>Q01.FR.35</td><td>When V2XChargingCtrlrTxUpdatedMeasurands is defined for the instance matching the operationMode of the current ChargingSchedulePeriodType</td><td>Charging Station SHALL include those measurands in meterValues of TransactionEventRequest in addition to measurands already defined in SampledDataCtrlrTxUpdatedMeasurands.</td><td></td></tr><tr><td>Q01.FR.36</td><td></td><td>Charging Station SHALL support the device model component Connected EV related with at least the variables "Available", "VehicleId", "VehicleCertificate", "ProtocolAgreed", "ProtocolSupportedByEV".</td><td></td></tr></table>
+
+# Q02 - Starting in operationMode ChargingOnly before enabling V2X
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Starting in operationMode ChargingOnly before enabling V2X</td></tr><tr><td>2</td><td>ID</td><td>Q02</td></tr><tr><td>3</td><td>Objective(s)</td><td>To start a transaction with operationMode ChargingOnly, such that it can become a bidirectional session at a later time.</td></tr><tr><td>4</td><td>Description</td><td>This operation mode is added especially for Charging Stations that intent to operate in V2X, but are unsure during energy service negotiation if the EV is allowed to operate in V2X at this time and location.
+Charging Station starts in this operation mode, waiting for authorization of the V2X operation mode. When V2X is authorized, a service negotiation should be performed between EV and Charging Station to start using actual V2X operation modes.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging Station sends a AuthorizationRequest with EVCCID of EV in additionInfo of idToken.
+a. The CSMS returns an AuthorizationResponse with idTokenInfo.status = Accepted and the list allowedEnergyTransfer without V2X.
+2. The Charging Station sends a NotifyEVChargingNeedsRequest with requestedEnergyTransfer set to normal AC or DC.
+3. The CSMS will respond with the NotifyEVChargingNeedsResponse message, with status set to Accepted
+4. The CSMS sends a SetChargingProfileRequest message, with a chargingSchedule with operationMode set to ChargingOnly.
+a. Charging Station and CSMS behave as described in Use cases & Requirements.
+5. The CSMS gets the EVCCID from EV from additionInfo which it had received in the InvalidateRequest or from the device model variable ConnectedEV.Vehiceld.
+6. Alternatively, CSMS gets the vehicle certificate from the device model variable ConnectedEV.Vehicld Certificate.
+7. When CSMS decides to allow V2X, for example based on idToken, EVCCID or vehicle certificate
+a. CSMS sends a NotifyAllowedEnergyTransferRequest to Charging Station with an updated allowedEnergyTransfer list that contains a bidirectional transfer, DC_BPT, AC_BPT or AC_BPTDER.
+b. Charging Station responds with NotifyAllowedEnergyTransferResponse with status = Accepted.
+8. The Charging Station will start a service renegotiation with the EV, allowing the EV to change its current energy service to one with potentially more value.</td></tr><tr><td>5</td><td>Prerequisites</td><td></td></tr><tr><td>6</td><td>Post conditions</td><td>Charging profile schedule ends</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>This use case may also be applied when the user authorizes using external identification means (EIM) before plugging-in a cable. In that case, the charging station does not know which EVSE will be selected by the user (in case multiple EVSEs are available). If the EVSEs have different capabilities (e.g. AC and DC), then the CSMS will not be able to provide the correct list of allowed energy transfer options in the AuthorizationResponse at time of authorization.
+When the user connects the cable to EV, then CSMS can send a NotifyAllowedEnergyTransferRequest to update the list of allowed energy transfers for this EVSE. This will trigger a service renegotiation, as described in this use case.</td></tr></table>
+
+NOTE
+
+The diagram below only shows ISO 15118-20 messages for as far as they are relevant for the data exchange between Charging Stations and CSMS.
+
+
+Figure 189. V2X Operation Mode ChargingOnly before enabling V2X
+
+# Q02 - Charging only (V2X control) before starting V2X - Requirements
+
+Table 153. Q02 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Q02.FR.01</td><td>When Charging Station does not request bidirectional power transfer in NotifyEVChargingNeedsRequest</td><td>CSMS SHALL send a SetChargingProfileRequest message, with chargingSchedulePeriod(s) with field operationMode set to ChargingOnly or omitted</td><td>When operationMode is omitted, this also defaults to ChargingOnly.</td></tr><tr><td>Q02.FR.02</td><td>Q02.FR.01</td><td>CSMS SHALL NOT include fields dischargeLimit, setpoint, setpointReactive in the ChargingProfileType.</td><td>This also includes the L2 and L3 variants of those fields.</td></tr><tr><td>Q02.FR.03</td><td>When CSMS is not able to determine a list of allowedEnergyTransfer before sending the AuthorizationResponse</td><td>CSMS SHALL omit allowedEnergyTransfer from AuthorizationResponse.</td><td>This can happen if it could not be determined within the short time span before the response has to be returned, e.g. because a third party has to be requested for permission. (Same as Q01.FR.08)</td></tr><tr><td>Q02.FR.04</td><td>Q02.FR.03</td><td>Charging Station SHALL send a NotifyEVChargingNeedsRequest with evsId set to the EVSE used for this transaction and requestedEnergyTransfer set to its default energy transfer (charging only AC/DC) and availableEnergyTransfer set to the supported energy transfers.</td><td>Depending on type of EVSE this will be AC_single_phase, AC_two_phase, AC_three_phase or DC, DC_ACDP</td></tr><tr><td>Q02.FR.05</td><td>When CSMS changes the list of allowed energy transfers for a transaction</td><td>CSMS SHALL send a NotifyAllowedEnergyTransferRequest with the allowedEnergyTransfer list and with transactionId set to the transaction for which this is intended.</td><td>For example, when permission for V2X is received some time after authorization.</td></tr><tr><td>Q02.FR.06</td><td>Q02.FR.05</td><td>Charging Station SHALL respond with a NotifyAllowedEnergyTransferResponse with status = Accepted and start an ISO 15118 service renegotiation with EV</td><td></td></tr><tr><td>Q02.FR.07</td><td>Q02.FR.06</td><td>Charging Station SHALL send a NotifyEVChargingNeedsRequest as in Q01.FR.03 with an updated list of requestedEnergyTransfer.</td><td></td></tr></table>
+
+# Q03 - Central V2X control with charging schedule
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Central V2X control with charging schedule</td></tr><tr><td>2</td><td>ID</td><td>Q03</td></tr><tr><td>3</td><td>Objective(s)</td><td>To allow the CSMS to control the charge and discharge behaviour of an EV with power profiles.</td></tr><tr><td>4</td><td>Description</td><td>The EV's charging and discharging behaviour is controlled by the Central System. The CSMS sends a power profile and can update it at any time. The power profile might be determined by some secondary actor that relays through the CSMS.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS, [secondary actor]</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS has sent a SetChargingProfileRequest message with a chargingProfilePurpose TxProfile or TxDefaultProfile and with a chargingSchedule that has one or more periods with operationMode set to CentralSetpoint and setpoint to the desired active power the EV should import or export.
+2. In ISO 15118 Scheduled mode the Charging Station will send the schedule to the EV to be executed. A change to the schedule will trigger a renegotiation in ISO 15118.
+3. In ISO 15118 Dynamic mode the Charging Station will set the charge or discharge rate of the EV to setpoint at start of each schedule period. No schedule is sent to EV and no renegotiation is triggered in ISO 15118.
+If the charging profile is of chargingProfileKind = Dynamic, then CSMS can update the setpoint via the UpdateDynamicScheduleRequest message.</td></tr><tr><td>5</td><td>Prerequisites</td><td>A charging profile from CSMS must have profile purpose TxProfile or TxDefaultProfile for V2X operations.</td></tr><tr><td>6</td><td>Post conditions</td><td>Charging profile ends</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>CSMS can control with the fields maxOfflineDuration and invalidAfterOfflineDuration of a ChargingProfileType how long it remains valid in an offline situation, and whether it can be resumed once online again.</td></tr></table>
+
+
+Figure 190. V2X Operation Mode Central Setpoint
+
+# Q03 - Central V2X control with charging schedule - Requirements
+
+Table 154. Q03 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td colspan="4">OperationMode CentralSetpoint</td></tr><tr><td>Q03.FR.01</td><td>When CSMS provides setpoints for charging/discharging</td><td>CSMS SHALL send a SetChargingProfileRequest message with one or more chargingSchedulePeriod(s) that have operationMode = CentralSetpoint.</td><td></td></tr><tr><td>Q03.FR.02</td><td>Q03.FR.01</td><td>CSMS SHALL NOT include fields limit and dischargeLimit in the ChargingSchedulePeriodType.</td><td>This also includes the L2 and L3 variants of those fields.</td></tr></table>
+
+# Q04 - Central V2X control with dynamic CSMS setpoint
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Central V2X control with dynamic CSMS setpoint</td></tr><tr><td>2</td><td>ID</td><td>Q04</td></tr><tr><td>3</td><td>Objective(s)</td><td>To allow the CSMS to control the charge and discharge behaviour of an EV by dynamically changing a setpoint (instead of providing a schedule).</td></tr><tr><td>4</td><td>Description</td><td>The EV's charging and discharging behaviour is controlled by the Central System. The CSMS sends a dynamic charging profile with a single period, which is updated frequently.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS, [secondary actor]</td></tr><tr><td></td><td>Scenario description</td><td>CSMS periodically updates the charging schedule:1. The CSMS has sent a SetChargingProfileRequest message with a chargingProfilePurpose TxProfile or TxDefaultProfile and a chargingProfileKind = Dynamic.The chargingProfile contains 1 chargingSchedule with 1 chargingSchedulePeriod which has operationMode set to CentralSetpoint and setpoint to the desired active power the EV should import or export.2. If chargingSchedule.duration has a value, then this specifies how long the chargingSchedule remains valid after the SetChargingProfileRequest or after the last update by UpdateDynamicScheduleRequest.3. The Charging Station will obey the values of the (one and only) chargingSchedulePeriod, e.g. it will set the charge or discharge rate of the EV to setpoint.4. CSMS updates the chargingSchedulePeriod periodically by sending a UpdateDynamicScheduleRequest.If chargingSchedule.duration is set and the chargingSchedulePeriod is not updated after duration seconds, then the chargingSchedule ends and Charging Station will fall back to the next valid charging profile.</td></tr><tr><td></td><td>Scenario description #2</td><td>Charging Stations pulls charging schedule updates from CSMS:1. The CSMS has sent a SetChargingProfileRequest message with a chargingProfilePurpose TxProfile or TxDefaultProfile and a chargingProfileKind = Dynamic and a dynUpdateInterval = 60.The chargingProfile contains 1 chargingSchedule with 1 chargingSchedulePeriod which has operationMode set to CentralSetpoint and setpoint to the desired active power the EV should import or export.2. If chargingSchedule.duration has a value, then this specifies how long the chargingSchedule remains valid after SetChargingProfileRequest or UpdateDynamicScheduleRequest.3. The Charging Station will obey the values of the (one and only) chargingSchedulePeriod, e.g. it will set the charge or discharge rate of the EV to setpoint.4. At dynUpdateInterval seconds after last update of the charging profile, Charging Station sends a PullDynamicScheduleUpdateRequest to CSMS.5. CSMS responds with PullDynamicScheduleUpdateResponse with new values to use in ChargingSchedulePeriodType.If chargingSchedule.duration is set and the chargingSchedulePeriod is not updated after duration seconds, then the chargingSchedule ends and Charging Station will fall back to the next valid charging profile.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Profile purpose must be TxProfile or TxDefaultProfile and profile kind must be Dynamic.</td></tr><tr><td>6</td><td>Post conditions</td><td>Charging profile ends, because no update is received after duration seconds or charging profile is no longer the active profile.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>A dynamic charging profile does not necessarily require the use of ISO 15118-20 dynamic control mode.Example of changing a dynamic setpoint to 2000"UpdateDynamicScheduleRequest":{ "chargingProfileId": 10, "setpoint": 2000}or"PullDynamicScheduleUpdateResponse":{ "setpoint": 2000}</td></tr></table>
+
+
+Figure 191. V2X Operation Mode with CentralSetpoint set dynamically
+
+NOTE
+
+This use case adheres to requirements related to CentralSetpoint from Q03 and Dynamic charging profiles from
+
+# Q05 - External V2X setpoint control with a charging profile from CSMS
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>External V2X setpoint control with a charging profile from CSMS</td></tr><tr><td>2</td><td>ID</td><td>Q05</td></tr><tr><td>3</td><td>Objective(s)</td><td>CSMS explicitly allows an External System to control the charge and discharge behaviour of an EV for a certain period of time.</td></tr><tr><td>4</td><td>Description</td><td>CSMS has disallowed that an external actor submits a ChargingStationExternalConstraints charging profile. Instead, CSMS defines a charging profile with a chargingSchedulePeriod that has operationMode = ExternalLimits or ExternalSetpoint. Only during this charging period CSMS lets the charging and discharging behaviour be controlled by an External System connected to the Charging Station, such as an EMS.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS, External System</td></tr><tr><td></td><td>Scenario description</td><td>External setpoint control granted by CSMS.
+1. CSMS has sent a SetChargingProfileRequest message with a chargingProfilePurpose TxProfile or TxDefaultProfile in which chargingProfileKind = Dynamic and with a chargingSchedulePeriod which has operationMode set to ExternalSetpoint (to allow controlling the setpoints) or ExternalLimits (to allow controlling charging/discharging limits).
+2. During this chargingSchedulePeriod the External System is allowed to control the desired active power the EV should import or export.
+3. If chargingSchedule.duration is set and the setpoint/limit/dischargingLimit is not updated by External System after duration seconds, then the chargingSchedule ends and Charging Station will fall back to the next valid charging profile.
+4. If chargingSchedule.duration has not been set, then the chargingSchedule is valid indefinitely, until the charging profile is cleared or replaced by CSMS.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Profile purpose must be TxProfile or TxDefaultProfile for V2X operations.
+Configuration variable ExternalControlSignalsEnabled = true.
+Configuration variable ExternalConstraintsProfileDisallowed = true.</td></tr><tr><td>6</td><td>Post conditions</td><td>If chargingSchedule.duration is set, then the use case ends when the setpoint is not updated after duration seconds, i.e. the schedule ceases to be valid when duration + lastDynamicUpdate > current time.
+If chargingSchedule.duration is not set, then the chargingSchedule remains valid until the charging profile is cleared or replaced by CSMS.</td></tr><tr><td>7</td><td>Error Handling</td><td>The value of chargingSchedule.duration acts as a timeout for updates from the external system. If no updates are received in time, the charging profile will fall back to the next valid charging profile.</td></tr><tr><td>8</td><td>Remarks</td><td>The communication method by which the External System communicates desired power levels to the Charging Station is out of scope of this document.
+Together with configuration variable ExternalConstraintsProfileDisallowed = false this use case controls when an external system is allowed to dictate setpoint and limits.
+The power setpoint communicated towards EV may never exceed limit or go below dischargingLimit of the composite (merged) charging schedules. (See V2X.03/04)</td></tr></table>
+
+# Q05 - External V2X setpoint control with a charging profile from CSMS - Requirements
+
+Table 155. Q05 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Q05.FR.01</td><td>When a ChargingSchedulePeriodType with operationMode = ExternalSetpoint in a TxProfile or TxDefaultProfile charging profile becomes active</td><td>Charging Station SHALL use the value from the External System for setpoint and setpointReactive.</td><td>During this period the values of setpoint and setpointReactive are given by External System. When applicable this also includes the L2 and L3 values of setpoint(Reactive).</td></tr><tr><td>Q05.FR.02</td><td>When a ChargingSchedulePeriodType with operationMode = ExternalLimits in a TxProfile or TxDefaultProfile charging profile becomes active</td><td>Charging Station SHALL use the value from the External System for limit and dischargingLimit.</td><td>During this period the values of limit and dischargingLimit are given by External System. When applicable this also includes the L2 and L3 values of (discharging)Limit.</td></tr><tr><td>Q05.FR.03</td><td>Q05.FR.01 AND chargingProfileKind = Dynamic</td><td>External System MAY dynamically change setpoint and setpointReactive during the ChargingSchedulePeriodType.</td><td>When applicable this also includes the L2 and L3 values of setpoint(Reactive).</td></tr><tr><td>Q05.FR.04</td><td>Q05.FR.02 AND chargingProfileKind = Dynamic</td><td>External System MAY dynamically change limit and dischargingLimit during the ChargingSchedulePeriodType.</td><td>When applicable this also includes the L2 and L3 values of (discharging)Limit.</td></tr><tr><td>Q05.FR.05</td><td>Q05.FR.03 AND External System updates setpoint or setpointReactive</td><td>Charging station SHALL update setpoint or setpointReactive in the charging profile and set dynUpdateTime to the current time.</td><td></td></tr><tr><td>Q05.FR.06</td><td>Q05.FR.04 AND External System updates limit or dischargingLimit</td><td>Charging station SHALL update limit or dischargingLimit in the charging profile and set dynUpdateTime to the current time.</td><td></td></tr><tr><td>Q05.FR.07</td><td>(Q05.FR.03 OR Q03.FR.04) AND chargingSchedule.duration is set AND current time > (chargingSchedule.duration + dynUpdateTime)</td><td>Charging Station SHALL consider the charging profile invalid and switch to using the next valid charging profile.</td><td>This is a fallback when External System is no longer responding within time set by duration.</td></tr></table>
+
+# Q06 - External V2X control with a charging profile from an External System
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>External V2X control with a charging profile from an External System</td></tr><tr><td>2</td><td>ID</td><td>Q06</td></tr><tr><td>3</td><td>Objective(s)</td><td>An External System controls the charge and discharge limits or setpoint of a charging station via a ChargingStationExternalConstraints charging profile.</td></tr><tr><td>4</td><td>Description</td><td>An External System is not aware of individual charging sessions on a charging station. It can therefore only control charging station or EVSE power. This use case defines three scenarios:1. Scheduled external limits control: a schedule of limits provided by external system.2. Dynamic external limits control: limits are dynamically updated by external system.3. Dynamic setpoint control: setpoint is dynamically updated by external system.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, External System</td></tr><tr><td></td><td>Scenario #1</td><td>Scheduled external limits control.1. External System sets a charging schedule with limits and/or dischargingLimits, which is represented in the charging station by a charging profile in which chargingProfilePurpose = ChargingStationExternalConstraints, chargingProfileKind = Absolute and with one or more chargingSchedulePeriods which have operationMode set to ExternalLimits and the externally received values for limit and dischargingLimit.2. With these chargingSchedulePeriods the External System controls the limits of the active power to import or export.3. When this external charging profile is set, charging station will send a NotifyChargingLimitRequest with chargingLimitSource = EMS and with the received schedule in chargingSchedule to CSMS.4. If the charging profile is set to EVSE #0 (i.e. the whole charging station), then it is up to the charging station to divide charging and discharging power among the EVSEs to keep the total charging station power within limit and dischargingLimit.</td></tr><tr><td></td><td>Scenario #2</td><td>Dynamic external limits control.1. External System sets a single (discharging)limit, which is represented in the charging station by a charging profile in which chargingProfilePurpose = ChargingStationExternalConstraints, chargingProfileKind = Dynamic and with 1 chargingSchedulePeriod which has operationMode set to ExternalLimits and the externally received value for limit and/or dischargingLimit.2. With this chargingSchedulePeriod the External System controls the limits of the active power to import or export.3. Since chargingProfileKind = Dynamic, the EMS can change the limit and dischargingLimit dynamically without having to update the charging profile.4. When this external charging profile is set and when the value of limit/dischargingLimit changes more than SmartChargingCtrl. LimitChangeSignificance, the charging station will send a NotifyChargingLimitRequest with chargingLimitSource = EMS, isDynamic = true, and the charging schedule in chargingSchedule to CSMS.5. If the charging profile is set to EVSE #0 (i.e. the whole charging station), then it is up to the charging station to divide charging and discharging power among the EVSEs to keep the total charging station power such that it remains within limit and dischargingLimit.</td></tr><tr><td></td><td>Scenario #3</td><td>Dynamic external setpoint control.1. External System sets a single setpoint and/or setpointReactive, which is represented in the charging station as a charging profile in which chargingProfilePurpose = ChargingStationExternalConstraints, chargingProfileKind = Dynamic and with 1 chargingSchedulePeriod which has operationMode set to ExternalSetpoint and a value for setpoint and/or setpointReactive.2. With this chargingSchedulePeriod the External System controls the setpoint of the active and reactive power to import or export.3. When this external charging profile is set and when the value of limit/dischargingLimit changes more than SmartChargingCtrl. LimitChangeSignificance, charging station will send a NotifyChargingLimitRequest with chargingLimitSource = EMS, isDynamic = true, and with the received schedule in chargingSchedule to CSMS.4. If the charging profile is set to EVSE #0 (i.e. the whole charging station), then it is up to the charging station to divide charging and discharging power among the EVSEs to ensure the total charging station power matches the setpoint.</td></tr><tr><td>5</td><td>Prerequisites</td><td>For discharging, at least one of the active charging sessions must have an active TxProfile or TxDefaultProfile for V2X operations.Configuration variable ExternalControlSignalsEnabled = true.Configuration variable ExternalConstraintsProfileDisallowed = false or absent.</td></tr><tr><td>6</td><td>Post conditions</td><td>Use case ends when the charging profile for ChargingStationExternalConstraints ends.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>The communication method by which the External System communicates the charging profile to the Charging Station is out of scope of this document.See section K. Smart Charging use cases K23 to K26 to see various topologies in which an external actor imposes charging limits.An external system (e.g. EMS) might not be aware (or does not have to be aware) of how many EVSEs the charging station has. In that case the ChargingStationExternalConstraints charging profile has to be assigned to EVSE #0.When a ChargingStationExternalConstraints charging profile is active with a chargingSchedulePeriod with operationMode = ExternalSetpoint and at the same time a Tx(Default)Profile charging profile is active with a chargingSchedulePeriod that also controls the setpoint (e.g. CentralSetpoint or Central/LocalFrequency) then the variable SmartChargingCtrlr.SetpointPriority determines which value of setpoint the charging station shall use.The power setpoint communicated towards EV may never exceed limit or go below dischargingLimit of the composite (merged) charging schedules. (See V2X.03/04)A scheduled external setpoint control, i.e. with chargingProfileKind = Absolute or Relative, is not mentioned as a scenario. It is possible, but less likely, since a setpoint is controlling the exact amount of power and an External System is unlikely to be able to predict a schedule for this.</td></tr></table>
+
+# Q06 - External V2X control with a charging profile from an External System - Requirements
+
+Table 156. Q06 - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Q06.FR.01</td><td>When External System sends a schedule of limits</td><td>Charging Station SHALL represent this by a ChargingProfileType with chargingProfilePurpose = ChargingStationExternalConstraints, chargingProfileKind = Absolute and a chargingSchedule with chargingSchedulePeriods with operationMode = ExternalLimits representing the received schedule of limit and dischargingLimit.</td><td>When applicable this also include the L2 and L3 values of (discharging)limit.</td></tr><tr><td>Q06.FR.02</td><td>When External System sends a single limit value</td><td>Charging Station SHALL represent this by a ChargingProfileType with chargingProfilePurpose = ChargingStationExternalConstraints, chargingProfileKind = Dynamic and a chargingSchedule with one chargingSchedulePeriod with operationMode = ExternalLimits representing the received value of limit and dischargingLimit.</td><td>When applicable this also include the L2 and L3 values of (discharging)limit.</td></tr><tr><td>Q06.FR.03</td><td>When External System sends a schedule of setpoints</td><td>Charging Station SHALL represent this by a ChargingProfileType with chargingProfilePurpose = ChargingStationExternalConstraints, chargingProfileKind = Absolute and a chargingSchedule with chargingSchedulePeriods with operationMode = ExternalSetpoint representing the received schedule of setpoint and setpointReactive.</td><td>When applicable this also include the L2 and L3 values of setpoint(Reactive).</td></tr><tr><td>Q06.FR.04</td><td>When External System sends a single setpoint value</td><td>Charging Station SHALL represent this by a ChargingProfileType with chargingProfilePurpose = ChargingStationExternalConstraints, chargingProfileKind = Dynamic and a chargingSchedule with one chargingSchedulePeriod with operationMode = ExternalSetpoint representing the received value of setpoint and setpointReactive.</td><td>When applicable this also include the L2 and L3 values of setpoint(Reactive).</td></tr><tr><td>Q06.FR.05</td><td>Q06.FR.02</td><td>Charging Station SHALL use the value of limit and dischargingLimit that External System may vary dynamically within the ChargingSchedulePeriodType.</td><td>Also applies to L2 and L3 values.</td></tr><tr><td>Q06.FR.06</td><td>Q06.FR.04</td><td>Charging Station SHALL use the value of setpoint and setpointReactive that External System may vary dynamically within the ChargingSchedulePeriodType.</td><td>Also applies to L2 and L3 values.</td></tr><tr><td>Q06.FR.07</td><td>When for a charging profile with chargingProfilePurpose = ChargingStationExternalConstraints and chargingProfileKind = Dynamic the External System updates values within ChargingSchedulePeriodType</td><td>Charging Station SHALL update the value of dynUpdateTime to the current time.</td><td></td></tr><tr><td>Q06.FR.08</td><td>When ExternalConstraintsProfileDi sallowed = true AND an External System sends charging limits or setpoints</td><td>Charging Station SHALL refuse the settings and not create a charging profile for this.</td><td>This overrules Q06.FR.01 to Q06.FR.04.</td></tr><tr><td colspan="4">NotifyChargingLimit</td></tr><tr><td>Q06.FR.10</td><td>Q06.FR.01 OR Q06.FR.03</td><td>Charging Station SHALL send a NotifyChargingLimitRequest with chargingLimitSource = EMS and with the received schedule in chargingSchedule to CSMS.</td><td></td></tr><tr><td>Q06.FR.11</td><td>Q06.FR.02 OR Q06.FR.04</td><td>Charging Station SHALL send a NotifyChargingLimitRequest with chargingLimitSource = EMS, isDynamic = true and with the received schedule in chargingSchedule to CSMS.</td><td>This chargingSchedule will only have a single period.</td></tr><tr><td>Q06.FR.12</td><td>Q06.FR.07 AND The value of limit, dischargingLimit, setpoint, setpointReactive changes more than SmartChargingCtrl.LimitChangeSignificance</td><td>Charging Station SHALL send a NotifyChargingLimitRequest with chargingLimitSource = EMS, isDynamic = true and a schedule with the new values in chargingSchedule to CSMS.</td><td>Also applies to L2 and L3 values.</td></tr><tr><td colspan="4">SetpointPriority</td></tr><tr><td>Q06.FR.20</td><td>When a chargingSchedulePeriod in a charging profile with chargingProfilePurpose = ChargingStationExternalConstraints has operationMode = ExternalSetpoint AND A charging profile of chargingProfilePurpose = TxProfile or TxDefaultProfile also defines a setpoint or setpointReactive</td><td>Configuration variable SmartChargingCtrl. SetpointPriority defines which charging profile the charging station shall apply.</td><td></td></tr><tr><td>Q06.FR.21</td><td>Q06.FR.20 AND SmartChargingCtrl. SetpointPriority = "ExternalControl" OR SmartChargingCtrl. SetpointPriority does not exist</td><td>Charging station shall use the setpoint and setpointReactive from the active ChargingStationExternalConstraints profile.</td><td>This is default behavior for operationMode ExternalSetpoint.</td></tr><tr><td>Q06.FR.22</td><td>Q06.FR.20 AND SmartChargingCtrl. SetpointPriority = "CSMS"</td><td>Charging station shall use the setpoint and setpointReactive from the TxProfile or TxDefaultProfile profile that is active, thus overruling the external setpoint.</td><td>Only TxProfile and TxDefaultProfile can contain a setpoint(Reactive).</td></tr><tr><td colspan="4">evseld = 0</td></tr><tr><td>Q06.FR.30</td><td>When chargingSchedulePeriod has operationMode = ExternalLimits AND evseld = 0</td><td>Charging station SHALL keep the total active power of the charging station within limit and dischargingLimit.</td><td></td></tr><tr><td>Q06.FR.31</td><td>When chargingSchedulePeriod has operationMode = ExternalSetpoint AND evsEd = 0</td><td>Charging station SHALL try to match the total active power of the charging station with the value of setpoint and reactive power with setpointReactive.</td><td>It may not be possible to achieve this, as this highly depends on the value of the setpoints and the active sessions on the EVSEs.</td></tr></table>
+
+# Q07 - Central V2X control for frequency support
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Central V2X control for frequency support</td></tr><tr><td>2</td><td>ID</td><td>Q07</td></tr><tr><td>3</td><td>Objective(s)</td><td>To allow an EV to be used for frequency support, with control at the CSMS.</td></tr><tr><td>4</td><td>Description</td><td>The EV's charging and discharging behaviour is controlled by the CSMS for frequency support. This use case is intended for when calibrated frequency readings are required, and it is not economically viable to do these measurements locally. The Central system will constantly update the power setpoint (probably of an aggregated group of EV's) depending on the centrally measured frequency.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS has sent a SetChargingProfileRequest message with a chargingProfilePurpose TxProfile or TxDefaultProfile and a chargingProfileKind = Dynamic. The chargingProfile contains 1 chargingSchedule with 1 chargingSchedulePeriod which has operationMode set to CentralFrequency and setpoint to the desired active power the EV should import or export.2. If chargingSchedule.duration is set on a Dynamic charging profile, then this specifies how long the chargingSchedule remains valid after SetChargingProfileRequest or UpdateDynamicScheduleRequest.3. The Charging Station will obey the values of the (one and only) chargingSchedulePeriod, e.g. it will set the charge or discharge rate of the EV to setpoint.4. CSMS updates the chargingSchedulePeriod periodically by sending a UpdateDynamicScheduleRequest.</td></tr><tr><td></td><td>Scenario description #2</td><td>When the Charging Station does not receive a UpdateDynamicScheduleRequest message with a new schedule before the configured duration expires, then Charging Station shall continue with the next valid charging profile.If the Charging Station supports local frequency control, then this can be a LocalFrequency charging profile at a lower stack level. So, if no update from CSMS is received on time, then the Charging Station will switch from CentralFrequency to use case Q08 for local frequency control until a new UpdateDynamicScheduleRequest is received for the CentralFrequency charging profile.</td></tr><tr><td>5</td><td>Prerequisites</td><td></td></tr><tr><td>6</td><td>Post conditions</td><td>Charging Profile ends or no more updates via UpdateDynamicScheduleRequest are received.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>This use case is a special case of Q04 - Central V2X control with dynamic CSMS setpoint. This use case should not be confused with frequency support mechanisms described in section R. DER Control. In Q07 - Central V2X control for frequency support and Q08 - Local V2X control for frequency support the frequency support is the primary goal of the charging profile, whereas in the case of section R. DER Control the frequency support provided by frequency droop parameters or a frequency-Watt curve exists to satisfy grid code requirements.</td></tr></table>
+
+
+Figure 192. V2X Operation Mode CentralFrequency
+
+NOTE
+
+This use case adheres to requirements related to CentralSetpoint from Q04 - Central V2X control with dynamic CSMS setpoint and Dynamic charging profiles from K01. There are no specific requirements for this use case.
+
+# Q08 - Local V2X control for frequency support
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Local V2X control for frequency support</td></tr><tr><td>2</td><td>ID</td><td>Q08</td></tr><tr><td>3</td><td>Objective(s)</td><td>To allow an EV to be used for frequency control, depending on local frequency readings.</td></tr><tr><td>4</td><td>Description</td><td>In this use case no setpoint is expected from the CSMS, and local frequency readings are always used to determine a setpoint by the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station</td></tr><tr><td></td><td>Scenario description #1</td><td>Frequency Containment Reserve (FCR) service
+1. The CSMS has sent a SetChargingProfileRequest message, with a chargingSchedule that has one or more periods with operationMode set to LocalFrequency and a value for v2xBaseline and a v2xFreqWattCurve with the curve of power to be delivered or consumed depending on the frequency.
+2. The Charging Station will continually get its latest frequency reading and calculate the new setpoint as v2xBaseline plus the interpolated power value from v2xFreqWattCurve.</td></tr><tr><td></td><td>Scenario description #2</td><td>Automatic Frequency Restoration Reserve (aFRR) service
+1. The CSMS has sent a SetChargingProfileRequest message, with a chargingSchedule that has one or more periods with operationMode set to LocalFrequency and a value for v2xBaseline and a v2xFreqWattCurve with the curve of power to be delivered or consumed depending on the frequency and a v2xFsignalWattCurve with the power to be delivered or consumed depending on the signal from TSO.
+2. The CSMS sends a AFRRSignalRequest message with a signal and timestamp as result of a signal received from TSO. The value of signal is applied when time is greater or equal to timestamp.
+3. The Charging Station will continually get its latest frequency reading and calculate the new setpoint as v2xBaseline plus the interpolated power value from v2xFreqWattCurve and v2xFsignalWattCurve.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The field limitAtSoC is absent in chargingSchedule, or SoC of EV is still below the value in limitAtSoC.</td></tr></table>
+
+
+Figure 193. V2X Operation Mode LocalFrequency
+
+# Q08 - Local V2X control for frequency support - Requirements
+
+Table 157. Q08 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td colspan="4">FCR</td></tr><tr><td>Q08.FR.01</td><td>When a ChargingSchedulePeriodType has operationMode = LocalFrequency</td><td>The ChargingSchedulePeriodType SHALL NOT contain the fields limit, dischargingLimit, setpoint, setpointReactive.</td><td>This also applies to the L2 and L3 variants of these fields. The power setpoint is calculated from v2xFreqWattCurve and v2xBaseline.</td></tr><tr><td>Q08.FR.02</td><td>Q08.FR.01</td><td>The ChargingSchedulePeriodType SHALL have a v2xFreqWattCurve with at least two V2xFreqWattPointType elements, and a value for v2xBaseline.</td><td></td></tr><tr><td>Q08.FR.03</td><td>When Charging Station receives a SetChargingProfile with a ChargingSchedulePeriodType that has operationMode = LocalFrequency AND The field v2xBaseline or v2xFreqWattCurve is missing or has less than two V2xFreqWattPointType elements</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status = Rejected and statusInforeasonCode = "NoFreqWattCurve".</td><td>It is advised to mention the chargingSchedule.id and chargingSchedulePeriod.startPeriod in statusInfo additionInfo to tell which part of the charging schedule is invalid.</td></tr><tr><td>Q08.FR.04</td><td>When Charging Station receives a SetChargingProfile with a ChargingSchedulePeriodType that has operationMode = LocalFrequency AND The ChargingSchedulePeriodType contains any of the fields limit, dischargingLimit, setpoint, setpointReactive.</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status = Rejected and statusInforeasonCode = "InvalidSchedule"</td><td>This also applies to the L2 and L3 variants of these fields. The power setpoint is calculated from v2xFreqWattCurve and v2xBaseline. It is advised to mention the chargingSchedule.id and chargingSchedulePeriod.startPeriod in statusInfo additionInfo to tell which part of the charging schedule is invalid.</td></tr><tr><td>Q08.FR.05</td><td>Q08.FR.01</td><td>The ChargingScheduleType that contains the ChargingSchedulePeriodType SHALL have chargingRateUnit = w.</td><td>A frequency-watt curve specifies power in Watts.</td></tr><tr><td>Q08.FR.06</td><td>When a ChargingSchedulePeriodType with operationMode = LocalFrequency starts</td><td>The Charging Station SHALL calculate the new setpoint as v2xBaseline plus the interpolated power value from v2xFreqWattCurve for the measured frequency.</td><td></td></tr><tr><td>Q08.FR.07</td><td>During a ChargingSchedulePeriodType with operationMode = LocalFrequency, When the net frequency change in mHz is equal or more than V2XChargingCtrl LocalFrequencyUpdateThreshold</td><td>The Charging Station SHALL calculate the new setpoint as v2xBaseline plus the interpolated power value from v2xFreqWattCurve for the measured frequency.</td><td></td></tr><tr><td colspan="4">aFRR</td></tr><tr><td>Q08.FR.10</td><td>When a ChargingSchedulePeriodType has operationMode = LocalFrequency and contains field v2xSignalWattCurve AND Charging Station receives a AFRRSignalRequest with a timestamp and signal</td><td>Charging Station SHALL calculate a delta to the power setpoint based on the value of signal that it receives from AFRRSignalRequest and add that to the existing value of the power setpoint at time timestamp.</td><td>aFRR is added on top of the setpoint value calculated in Q08.FR.06/07</td></tr><tr><td>Q08.FR.11</td><td>When Charging Station receives a AFRRSignalRequest and no ChargingSchedulePeriodType with operationMode = LocalFrequency and a field v2xSignalWattCurve is active</td><td>Charging Station SHALL respond with AFRRSignalResponse with status = Rejected and statusInforeasonCode = "NoSignalWattCurve"</td><td>It is advised to mention the chargingSchedule.id and chargingSchedulePeriod.startPeriod in statusInfo additionInfo to tell which part of the charging schedule is invalid.</td></tr></table>
+
+# Q09 - Local V2X control for load balancing
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Local V2X control for load balancing</td></tr><tr><td>2</td><td>ID</td><td>Q09</td></tr><tr><td>3</td><td>Objective(s)</td><td>To allow the EV to be utilized for locally controlled load balancing.</td></tr><tr><td>4</td><td>Description</td><td>This operation modes allows an EV to be utilized for load balancing controlled locally by the Charging Station. The Charging Station is able to read the grid meter of a building that consumes energy and possibly generates energy from, for example, solar panels.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The CSMS has sent a SetChargingProfileRequest message, with a chargingSchedule that has one or more periods with operationMode set to LocalLoadBalancing.2. The Charging Station will continually get the latest load power reading to calculate a new setpoint that will offset the measured power generation or consumption, such that it stays between the configured UpperThreshold and LowerThreshold. Optionally, there may be an UpperOffset and LowerOffset to control how much the power can exceed these thresholds.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station is able to read the upstream meter.</td></tr><tr><td>6</td><td>Post conditions</td><td>ChargingSchedulePeriod ends</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>See section LocalLoadBalancing in the introduction of this chapter for more detailed information on how local load-balancing works.This use case only works for one Charging Station, but can work for multiple EVSEs when Charging Station has the capability to combine setpoints from multiple EVSEs to compensate the measured load at the upstream meter.Local load-balancing by multiple Charging Stations would have to be coordinated by a CSMS or Local Controller using the Central Setpoint use case.</td></tr></table>
+
+
+Figure 194. V2X Operation Mode LocalLoadBalancing
+
+# Q09 - Local V2X control for load balancing - Requirements
+
+Table 158. Q09 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Q09.FR.01</td><td>When Charging Station receives a SetChargingProfileRequest with a ChargingSchedulePeriodType with operationMode = LocalLoadBalancing AND V2XSupportedOperationModes does not contain "LocalLoadBalancing"</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status = Rejected and statusInforeasonCode = "UnsupportedParam".</td><td></td></tr><tr><td>Q09.FR.02</td><td>When Charging Station receives a SetChargingProfileRequest with a ChargingSchedulePeriodType with operationMode = LocalLoadBalancing AND ((V2XLocalLoadBalancing[UpperThreshold] or V2XLocalLoadBalancing[LowerThreshold] are not set) OR (V2XLocalLoadBalancing[UpperO ffset] or V2XLocalLoadBalancing[LowerO ffset] are not set) OR (V2XLocalLoadBalancing[UpperT threshold] is not greater than V2XLocalLoadBalancing[LowerT threshold]))</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status = Rejected and statusInfo = "MissingDevModellinfo"</td><td></td></tr><tr><td>Q09.FR.03</td><td>During a ChargingSchedulePeriodType with operationMode = LocalLoadBalancing</td><td>Charging Station SHALL continuously read the power reported by the upstream grid meter</td><td></td></tr><tr><td rowspan="2">Q09.FR.04</td><td rowspan="2">Q09.FR.03</td><td>Charging Station SHALL calculate the power setpoint as follows:</td><td rowspan="2">"Load" is power from upstream meter. Positive values for consumption of energy.</td></tr><tr><td>If Load > UpperThreshold
+DeltaSetpoint =
+UpperThreshold + UpperOffset - Load
+Else If Load <
+LowerThreshold
+DeltaSetpoint =
+LowerThreshold + LowerOffset - Load
+Else
+DeltaSetpoint = 0
+setpoint = setpoint + DeltaSetpoint</td></tr><tr><td>Q09.FR.05</td><td>Q09.FR.03 AND limit and/or dischargingLimit are set</td><td>Charging Station SHALL cap the maximum (positive) value of setpoint to the value of limit and cap the minimum (negative) value of setpoint to the value of dischargingLimit.</td><td>This also applies to L2 and L3 values.</td></tr></table>
+
+# Q10 - Idle, minimizing energy consumption
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Idle, minimizing energy consumption</td></tr><tr><td>2</td><td>ID</td><td>Q10</td></tr><tr><td>3</td><td>Objective(s)</td><td>To request the EV to not perform any charging or discharging. Preconditioning of the vehicle is allowed.</td></tr><tr><td>4</td><td>Description</td><td>The CSMS requests EV to suspend any charging or discharging during one or more schedule intervals. CSMS requests EV to precondition itself in order to maintain the battery at an optimal temperature for charging or discharging.</td></tr><tr><td></td><td>Actors</td><td>EV, Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description #1</td><td>When preconditioning of the battery is needed:1. The CSMS sends a SetChargingProfileRequest message, with a chargingSchedule that has one or more periods with operationMode set to Idle and preconditioning set to True for this interval.2. The Charging Station will request the EV to refrain from charging or discharging the battery, and to turn on preconditioning of the battery, which may, of course, draw some power from the EVSE.</td></tr><tr><td></td><td>Scenario description #2</td><td>When preconditioning of the battery is not needed:1. The CSMS sends a SetChargingProfileRequest message, with a chargingSchedule with operationMode set to Idle and preconditioning set to False for this interval.2. The Charging Station will request the EV to refrain from charging or discharging and switch off preconditioning.</td></tr><tr><td></td><td>Scenario description #3</td><td>Requesting EVSE to sleep:1. The CSMS sends a SetChargingProfileRequest message, with a chargingSchedule that has one or more periods with operationMode set to Idle and evseSleep set to True for this interval.2. The Charging Station will turn off the power electronics/modules associated with the current transaction.3. When the EVSE is sleeping, any other charging command will "wake it up" (including limits/setpoints at 0 W).4. If a TransactionEventRequest is sent while the EVSE is sleeping, then the field evseSleep in TransactionEventRequest will be true.</td></tr><tr><td>5</td><td>Prerequisites</td><td></td></tr><tr><td>6</td><td>Post conditions</td><td>ChargingSchedulePeriod ends</td></tr><tr><td>7</td><td>Error Handling</td><td>When Charging Station does not support evseSleep = true, it will ignore it.</td></tr><tr><td>8</td><td>Remarks</td><td>This use case assumes a feature exists to request the EV to precondition the battery. It does not describe how CSMS or Charging Station do this.The configuration key SmartChargingCtrl.SupportsEvseSleep has the value true if the option to request the EVSE to sleep is supported.</td></tr></table>
+
+# Q10 - Idle, minimizing energy consumption - Requirements
+
+Table 159. Q10 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>Q10.FR.01</td><td>When a chargingSchedulePeriod has operationMode = Idle</td><td>The fields limit, dischargingLimit, setpoint and setpointReactive SHALL be absent</td><td>This also applies to the L2/L3 variants of these fields.</td></tr><tr><td>Q10.FR.02</td><td>When Charging Station receives a SetChargingProfileRequest with a chargingSchedulePeriod that has operationMode = Idle AND any of the fields limit, dischargingLimit, setpoint and setpointReactive is present</td><td>Charging Station SHALL respond with SetChargingProfileResponse with status = Rejected and statusInforeasonCode = "InvalidSchedule".</td><td>It is advised to mention the chargingSchedule.id and chargingSchedulePeriod.startPeriod in statusInfo additionInfo to tell which part of the charging schedule is invalid.</td></tr><tr><td>Q10.FR.03</td><td>When chargingSchedulePeriod has operationMode = Idle and evseSleep = true and SupportsEvseSleep is true</td><td>Charging Station SHALL turn off the electronics/modules associated with this transaction until an event happens that requires activation of these electronics/modules.</td><td>Events can be, for example, a change of operationMode in the next ChargingSchedulePeriod, receiving a new ChargingProfile (include one with limits of 0 W), stopping of the transaction.</td></tr><tr><td>Q10.FR.04</td><td>Q10.FR.03</td><td>Charging Station SHALL report the value of evseSleep as true when sending TransactionEventRequests as long as the EVSE is sleeping.</td><td></td></tr><tr><td>Q10.FR.05</td><td>When chargingSchedulePeriod has operationMode = Idle and evseSleep = true and SupportsEvseSleep is false or EVSE is not able to go into sleep mode</td><td>Charging Station SHALL report the value of evseSleep in TransactionEventRequests as false.</td><td>An absent field evseSleep is the same as having the value false.</td></tr></table>
+
+# Q11 - Going offline during V2X operation
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Going offline during V2X operation</td></tr><tr><td>2</td><td>ID</td><td>Q11</td></tr><tr><td>3</td><td>Objective(s)</td><td>To describe the amount of time that V2X operations may continue when the Charging Station is offline.</td></tr><tr><td>4</td><td>Description</td><td>If a Charging Station goes offline while a V2X operation is in progress, it is the field maxOfflineDuration in ChargingProfileType that determines how long the V2X operation may continue before the charging profile becomes invalid and Charging Station reverts to the next (lower) valid stack level.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. The Charging System is online and a V2X operation is active on the Charging System.
+2. The Charging Station looses connection to the CSMS.
+3. The Charging Station detects that it is offline. The maxOfflineDuration value counts from at this moment on.
+4. The Charging Station reverts back to the next valid charging profile after maxOfflineDuration seconds.
+5. The CSMS should assume that a V2X operation has reverted back to the next valid charging profile when it detects an offline situation.
+Note: since CS and CSMS may detect being offline at different moments, the CSMS should not try to guess the exact moment based on the maxOfflineDuration timeout value.</td></tr><tr><td>5</td><td>Prerequisites</td><td>The Charging Station must be able to detect an offline situation quickly. Typically, within 30 seconds.</td></tr><tr><td>6</td><td>Post conditions</td><td>V2X operation has reverted back to the next valid charging profile which has a longer or no maxOfflineDuration. (see K01.FR.101)</td></tr><tr><td>7</td><td>Error Handling</td><td>If there is no charging profile to fall back to after maxOfflineDuration seconds, charging continues without a charging profile, i.e. in "charging only" mode without limits.</td></tr><tr><td>8</td><td>Remarks</td><td>The next valid charging profile might also be a V2X profile if it has a value of maxOfflineDuration that has not yet elapsed.
+Charging profiles with invalidAfterOfflineDuration = true for which maxOfflineDuration has elapsed shall not be reactivated when the Charging Station is online again.</td></tr></table>
+
+NOTE The requirements for this use case are covered by K01 requirements about maxOfflineDuration.
+
+
+Figure 195. V2X Operation Going Offline
+
+# Q12 - Resuming a V2X operation after an offline period
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Resuming a V2X operation after an offline period</td></tr><tr><td>2</td><td>ID</td><td>Q12</td></tr><tr><td>3</td><td>Objective(s)</td><td>To describe how to resume V2X operations after an offline period.</td></tr><tr><td>4</td><td>Description</td><td>The Charging Station is offline and a V2X charging operation is active on the Charging Station via a TxProfile or TxDefaultProfile charging profile.
+Charging Station has a regular (ChargingOnly) charging profile with stack level #1 and a V2X (CentralSetpoint) charging profile with stack level #2. If the offline period lasted less than maxOfflineDuration seconds, then the V2X operation mode will still be what it was before going offline, else it will have reverted back while offline to the next valid charging profile with a lower stack level (i.e. #1).</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description #1</td><td>maxOfflineDuration has not elapsed
+1. The Charging Station restores connection to the CSMS.
+2. The offline period lasted less than the value of maxOfflineDuration of the (V2X) charging profile. The charging profile therefore remained active during the offline period, and nothing changes in this respect when the connection is restored.</td></tr><tr><td></td><td>Scenario description #2</td><td>maxOfflineDuration has elapsed, invalidAfterOfflineDuration = false
+1. The Charging Station restores connection to the CSMS.
+2. The offline period lasted longer than maxOfflineDuration of the (V2X) charging profile. This charging profile stopped being active after maxOfflineDuration seconds.
+3. While offline, Charging Station selected the next valid charging profile with stack level #1 and is now using a charging profile that only has operation mode ChargingOnly.
+4. When connection to CSMS is restored, Charging Station will re-evaluate its charging profiles and now select the charging profile with stack level #2 as the valid profile.
+5. Charging Station will continue with V2X operations according to the charging profile.</td></tr><tr><td></td><td>Scenario description #3</td><td>maxOfflineDuration has elapsed, invalidAfterOfflineDuration = true</td></tr><tr><td></td><td></td><td>1. The Charging Station restores connection to the CSMS.</td></tr><tr><td></td><td></td><td>2. The offline period lasted longer than maxOfflineDuration of the (V2X) charging profile. This charging profile stopped being active after maxOfflineDuration seconds.</td></tr><tr><td></td><td></td><td>3. While offline, Charging Station selected the next valid charging profile with stack level #1 and is now using a charging profile that only has operation mode ChargingOnly.</td></tr><tr><td></td><td></td><td>4. When connection to CSMS is restored, Charging Station will re-evaluate its charging profiles. The charging profile with stack level #2 has invalidAfterOfflineDuration = true and is therefore no longer eligible.</td></tr><tr><td></td><td></td><td>5. Charging Station continues the charging profile with stack level #1 as the valid profile.</td></tr><tr><td></td><td></td><td>6. Charging Station will continue with charging-only operations according to the charging profile.</td></tr><tr><td>5</td><td>Prerequisites</td><td>Charging Station is offline</td></tr><tr><td>6</td><td>Post conditions</td><td></td></tr><tr><td>7</td><td>Remarks</td><td>The requirements for this use case are covered by K01 - SetChargingProfile requirements about maxOfflineDuration.</td></tr></table>
+
+
+Figure 196. V2X Operation Resuming After Offline
+
+# R. DER Control
+
+# Chapter 1. Introduction
+
+Utilities consider a charging station (or group of charging stations) that is performing bidirectional charging/discharging as a Distributed Energy Resource (DER). A DER needs to adhere to the local grid codes that govern how it should react in case of grid anomalies. This is controlled by a range of settings and curves that determine how to respond to frequencies or voltages that are too high or too low.
+
+# NOTE
+
+A utility may also require grid code support for charging-only Charging Stations, for example to provide frequency support. This chapter uses the term "DER control" for both bidirectional as well as charging-only Charging Stations.
+
+Utilities usually require a DER to be registered and conform to certain regulations before it is permitted to provide energy to the grid. DC bidirectional (vehicle-to-grid) EVSEs could be registered in this way, because an EVSE is a stationary inverter for a battery pack (the EV). An AC bidirectional EV, however, uses its onboard inverter and is not stationary at all - it might charge and discharge at different locations. There is currently no regulation that covers the registration of AC bidirectional EVs.
+
+In the US an EV capable of AC vehicle-to-grid shall be certified to the automotive standard SAE J3072 (which also calls out certification to IEEE 1547). However, as system operators want to have additional assurance that the EV follows the grid code, the EVSE shall also be certified to UL 1741, which allows the EVSE to monitor grid code compliance and disconnect the EV if the grid code is not followed. The SAE J3072 standard requires its own interface that connects to the inverter in the EV. There are at the time of publication (2024) few EV OEMs that have implemented this interface.
+
+This specification assumes that the utility does not directly interface with charging stations or EVs for DER control, because the charging stations are only controlled by CSO, and the EVs have no interface with the utility. Instead, the CSO acts as an aggregator who controls (groups of) charging stations. The CSO, as aggregator, is assumed to take care of scheduling DER control messages towards charging stations when the utility sends (a schedule of) DER control messages.
+
+The interface from CSO to a charging station is the OCPP protocol. OCPP 2.1 supports sending DER control messages, as described in this chapter.
+
+# Chapter 2. DER Control using OCPP and ISO 15118-20
+
+# 2.1. CSO acting as aggregator
+
+OCPP does not prescribe the protocol that must be used to communicate DER settings towards a CSO. The OCPP message set aims to provide support for DER control features from IEEE 1547 shown in Table 1. This table references two common protocols: IEC 61850, mostly used in Europe and Asia, and IEEE 2030.5, mostly used in the USA. In addition, IEEE 1547 D.3 mentions IEEE 1815 DNP3 and SunSpec Modbus as standardized interfaces that can be used for this. The fact that these are not referenced any further in this specification does not preclude them being used as a communication interface between utility and CSO for DER control.
+
+Table 160. Comparing terminology across standards (based on Table C6 of [RefJ3072])
+
+<table><tr><td>IEEE 1547-2018</td><td>IEC 61850</td><td>IEEE 2030.5-2018</td><td>OCPP</td></tr><tr><td>Mode/Function</td><td>LN</td><td>DERControl</td><td>controlType</td></tr><tr><td>Constant Power Factor</td><td>DFPF</td><td>opModFixedPFInject: Excit</td><td>FixedPFInject</td></tr><tr><td>Voltage - Reactive Power</td><td>DVVR</td><td>opModVoltVar: Curve</td><td>VoltVar</td></tr><tr><td>Active Power - Reactive Power</td><td>DWVR</td><td>opModWattVar: Curve</td><td>WattVar</td></tr><tr><td>Constant Reactive Power</td><td>DVAR</td><td>opModFixedVar: FixedVar</td><td>FixedVar</td></tr><tr><td>Voltage - Active Power</td><td>DVWC</td><td>opModVoltWatt: Curve</td><td>VoltWatt</td></tr><tr><td>High Voltage Trip Curve</td><td>DHVT</td><td>opModHVRTMustTrip: Curve</td><td>HVMustTrip</td></tr><tr><td>Low Voltage Trip Curve</td><td>DLVT</td><td>opModLVRTMustTrip: Curve</td><td>LVMustTrip</td></tr><tr><td>High Frequency Trip Curve</td><td>DHFT</td><td>opModHFRTMustTrip: Curve</td><td>HFMustTrip</td></tr><tr><td>Low Frequency Trip Curve</td><td>DLFT</td><td>opModLFRTMustTrip: Curve</td><td>LFMustTrip</td></tr><tr><td>Frequency-Droop (HF)</td><td>DHFW</td><td>opModFreqDroop</td><td>FreqDroop</td></tr><tr><td>Frequency-Droop (LF)</td><td>DLFW</td><td>opModFreqDroop</td><td>FreqDroop</td></tr><tr><td>Enter Service</td><td>DCTE</td><td>DefaultDERControl: setES...</td><td>EnterService</td></tr><tr><td>Cease to Energize and Trip</td><td>DCTE</td><td>opModEnergize</td><td>ChargingProfile</td></tr><tr><td>Limit Active Power</td><td>DWMX</td><td>opModMaxLimW: PerCent</td><td>LimitMaxDischarge</td></tr><tr><td>NA</td><td>DTCD</td><td>opModFixedW: SignedPerCent</td><td>ChargingProfile</td></tr><tr><td>NA</td><td>DWGC</td><td>opModFixedW: SignedPerCent</td><td>ChargingProfile</td></tr></table>
+
+It is important to realize, that the OCPP messages do not provide one-to-one replacement of IEC 61850 or IEEE 2030.5 messages. It is assumed that the CSO performs an aggregator role towards the utility. The utility connects with the CSMS of the CSO, using an agreed protocol (e.g. one of IEC 61850, IEEE 2030.5, DNP3, Modbus). CSMS will then forward the appropriate information to the impacted charging stations. The burden of scheduling and prioritizing of messages lies mostly with CSMS.
+
+For example, a utility can schedule a series of events with a start time and duration for a DER. A DER can be part of multiple groups, and one group can have a higher priority than another group. CSMS will receive these events and construct a timeline of events in which higher priority events supersede events with lower priority. CSMS will then send the appropriate OCPP messages to the affected charging station. ISO 15118-20 Amendment 1 can be used to transfer the DER control parameters to the EV, guaranteeing the EV will comply with the grid code requirements during times when the EV is feeding back to the grid to satisfy a request coming from the CSMS or an EMS. This is illustrated in the figure below.
+
+
+Figure 197. Protocol chain for DER control
+
+# 2.2. DER Control for DC bidirectional power transfer
+
+In case of a DC charging station, the AC-DC inverter is part of the EVSE in the charging station. The bidirectional EVSE is therefore the device that is acting as the DER that needs to be configured such that it complies to the grid codes.
+
+In most cases the DER configuration will be static, since grid codes are not changed often, but it is possible for the CSO to dynamically update the DER settings of charging stations.
+
+# 2.3. DER Control for AC bidirectional power transfer
+
+In case of an AC charging station, the AC-DC inverter is part of the EV. As such it cannot be controlled directly via OCPP, because there is no OCPP connection with the EV. The charging station has its own communication protocol with the EV. This document assumes ISO 15118-20 as the communication protocol with the EV, but other protocols that support bidirectional charging, such as CHAdeMO, can also be used, although the number of parameters that can be exchanged may differ.
+
+The current version of ISO 15118-20 for AC (ProtocolNamespace = "urn:iso:std:iso:15118:-20:AC", VersionNumberMajor = 1) available in 2023 does not provide support to configure the EV inverter with specific grid code settings, such as fault ride-through and frequency droop curves, or reactive power capabilities. However, the ChargeLoop message of ISO 15118-20, that is exchanged between charging station and EV several times a second, provides a lot of control over the charging. A charging station can use this to dynamically control the charging and discharging such that it satisfies the grid code requirements.
+
+For example, a frequency droop curve can be implemented by the charging station. Based on the grid frequency this curve will tell how much discharging needs to be reduced or increased to help stabilize the grid frequency. The charging station adjusts the charging or discharging rate of the EV via the ChargeLoop messages. There is some latency involved, of course, and reaction speed highly depends on how frequent the EV sends its ChargeLoop messages. It will not suffice for settings that require a reaction time in the order of milliseconds.
+
+Amendment 1 of ISO 15118-20 provides a new service "AC_BPTDER" with capabilities to enforce grid code compliance. Two types of architectures are supported. An architecture in which the AC inverter in the EV is fully responsible for grid code compliance, and an architecture in which the responsibility is split between EV and Charging Station.
+
+# 2.4. ISO 15118 V2G-AC inverter architecture
+
+In the V2G-AC inverter architecture, the advanced smart inverter in the EV is fully responsible for grid code compliance. When the EV connects to the Charging Station, the latter will require a list of settings and supported DER controls that the EV must support when accepting the AC_BPTDER service. Charging Station will then send all grid code settings to the EV. The grid code settings will have been sent to the Charging Station by the CSMS at some earlier point in time.
+
+
+Figure 198. V2G-AC inverter architecture (ISO 15118-20)
+
+# 2.5. ISO 15118 V2G-Split inverter architecture
+
+In the V2G-Split architecture the responsibility for grid code compliance is split between EV and Charging Station.
+
+When the EV connects to the Charging Station, the latter will require a list of minimally required settings and DER controls that the EV must support. (This could even be an empty list.) Any DER controls that are required to comply to the grid code, but are not supported by the EV will be executed by the EVSE of the Charging Station. One of the possible configurations is the one represented in the diagram, where the EVSE ensures grid code compliance by measuring frequency and voltage deviations and calculating the appropriate active and/or reactive power target values. The EV will receive the targets requested by the EVSE and consume or inject active/reactive power. Both the EV and EVSE or just one shall also have interface protection means, which will be triggered according to the trip functions. The EV may perform reactive and active power functions independently, or receive target requests by the EVSE to consume or inject active/reactive power.
+
+
+Figure 199. V2G-Split inverter architecture (ISO 15118-20)
+
+# NOTE
+
+From an OCPP point of view the inverter architecture, V2G-AC or V2G-Split, is irrelevant. CSMS sends the DER controls to the Charging Station and does not need to know if the inverter is part of a DC Charging Station or AC Charging Station with V2G-AC or V2G-Split architecture.
+
+# 2.6. DER nameplate information
+
+The DER nameplate information is information about capabilities and make and model of the inverter. For a DC charging station this information can be provided by the CSO, who is aware of the station's inverter capabilities. A CSO will either have this information based on the make and model of the charging station, or the CSO is able to request the data from the charging station by retrieving data about the AcDcConverter component of the EVSE in the charging station.
+
+When the ISO 15118-20 communication is established using the AC_BPTDER service, the vehicle will send its inverter capabilities, including the manufacturer, model and version.
+
+The capabilities of the inverter of the EVSE do not have to match the capabilities of the vehicle. The combined capabilities of station and vehicle can only be given once the ISO 15118-20 ChargeParameterDiscovery process has completed. The results are sent to CSMS via the OCPP NotifyEVChargingNeedsRequest message.
+
+# 2.7. DER controls
+
+The behavior of a DER (i.e. charging station or EV inverter) can be controlled by so-called DER controls. These are settings with parameters to control active or reactive power, other settings, such as a specific power factor and ramp rates, and curves that control behavior.
+
+# NOTE
+
+ISO 15118-20 sends a complete set of DER controls to the EV each time it requests to use the AC_BPTDER service for AC bidirectional charging. This is because the EV is seen as a "new" DER resource that needs to be fully configured. Standards like IEEE 2030.5 and IEC 61850, however, allow a utility to submit or update individual controls. A utility might, for example, for the set of voltage trip curves that are installed on a DER, only update the overvoltage trip curve. This approach makes sense for static DER resources, such as solar panels and DC charging stations. OCPP messages are designed for controlling individual DER controls, because that is what utilities or aggregators are likely to provide. A charging station will group the set of active DER controls into a single message with voltage trip curves, frequency trip curves, reactive power support, etc. for sending to the EV.
+
+# Power settings
+
+If a utility wishes to state (reactive) power setpoints or limits, this can be achieved via the CSO. Setting of active or reactive power setpoints via CSMS is already supported by OCPP charging profiles. No new messages towards charging station are needed to support this. Instead, a power setpoint or limit will be translated to an OCPP charging profile towards the stations.
+
+# Parameter settings
+
+Other control settings, such as a fixed power factor, frequency droop, are transferred to the charging station via a SetDERControlRequest message. The settings can be scheduled with a start time and duration. The currently active settings can be retrieved with a GetDERControlRequest message.
+
+The following settings can be set via SetDERControlRequest:
+
+1. Voltage trip curves
+2. Frequency trip curves
+3. Enter service parameters
+4. Reactive power curves and parameters
+5. Active power curves and frequency droop
+
+Frequency droop is a parameterized form of the Freq-Watt curve that is determined by slope and a dead-band parameters.
+
+
+Figure 200. Example Frequency Droop curve from IEEE 1547-2018
+
+# Curves
+
+DER curves describe behavior that a charging station must perform autonomously in case of a grid anomaly. Such curves are configured on the charging station via the OCPP SetDERControlRequest messages.
+
+While only one curve per curve-type can be active at the same time, different curve-types can be active at the same time if they do not conflict. These curves are used to provide autonomous control in a predictable fashion. For example, assuming a volt-watt curve is active; if the inverter senses an over-voltage situation a volt-watt curve would direct the inverter to lower its power output during discharging. Likewise, in an under-voltage situation, the same curve would likely direct the DER to increase its output during discharging.
+
+# Trip and ride-through curves
+
+A ride-through curve describes how long a DER must stay connected when frequency of voltage deviates from nominal. A trip curve describes after how many seconds a DER must disconnect when frequency of voltage deviates from nominal. Both curves are called "trip curves" in this document, where a "may trip" curve defines the ride-through behavior and a "must trip" curve defines the trip behavior.
+
+Trip curves exist for high and low frequency or voltage anomalies:
+
+1. High Frequency Must/May Trip
+2. Low Frequency Must/May Trip
+3. High Voltage Must/May Trip and Momentary Cessation
+4. Low Voltage Must/May Trip and Momentary Cessation
+
+
+Figure 201. Example frequency trip curves from IEEE 2030.5
+
+
+Figure 202. Example voltage trip curves from IEEE 2030.5
+
+# Volt and Watt curves
+
+The following is a list of (reactive) power curves based on the measured frequency, voltage or power:
+
+1. Frequency-Power curve, P(F)
+2. Voltage-Reactive Power curve, Q(U)
+3. Voltage-Power curve, P(U)
+4. Power-Power Factor curve, Pf(P)
+5. Power-Reactive Power curve, Q(P)
+
+
+Figure 203. Example $Q(U)$ curve used in Germany (VDE-AR-N 4105)
+
+
+Figure 204. Example power factor curve, $\cos \phi i(P)$ , used in Germany (VDE-AR-N 4105)
+
+# 2.8. DER alarms
+
+When a charging station starts to deviate from normal behavior, because it is forced to follow a DER curve or setting, then this will be signalled to CSMS, such that the CSO is aware of this situation. Similarly, the charging station will send a signal when this event has ended.
+
+This is supported via the OCPP NotifyDERAlarmRequest message, which tells which DER control is taking over and what caused it. The message is sent again with an "ended" flag to signal when the event has ended.
+
+# 2.9. Prioritizing of controls
+
+There are two mechanisms that affect the priority of DER controls. Controls can be DER curves or parameter settings in this context. Firstly, there are default DER controls and scheduled ones. Secondly, there are different priorities as defined by the priority field of the setting. A priority $= 0$ is the highest priority.
+
+# Default controls
+
+Default DER controls are active when there is no scheduled DER control of the same type that is active at that point in time. "Type" in this context means a DER control parameter, such as FreqDroop or a DER curve, such as FreqWatt or HFMustTrip. There may be scheduled DER controls installed, but they will not become active until their specified startTime, and stop being active after duration seconds after startTime, after which the system falls back to the default DER control (if any).
+
+# Priority
+
+Only one control of a specific type can be active at any one time. If more than one control of the same type is installed, then the one with the highest priority (i.e. the lowest priority value!) will prevail. This applies to default and scheduled DER controls: the default control with the lowest priority value will be used as default control, and the scheduled control with the lowest priority value will be applied at its start time.
+
+The prioritization of a scheduled DER controls takes place at the moment when the message is received. When a DER control is received with a lower priority value than other controls of the same type, then these other controls become superseded immediately, as long as they have not yet started. This happens even when the new control has a much later start time than the existing ones. If a to-be-superseded control has already started (i.e. it is past startTime), then it will remain active and only become superseded at the startTime of the superseding control. A superseded control will no longer be used, but will remain to exist in the charging station until its duration expires.
+
+This method of scheduling has deliberately been made to match the process for prioritization that is described in [RefCSIP]. The following examples from [RefCSIP] illustrate the behavior by describing two very similar overlapping event scenarios that only differ in when the charging station receives the controls. In the first case, the charging station receives both DER controls prior to the start of either. In this case, the charging station does not execute the lower priority (superseded) control at all. It only executes the higher priority control as shown in the figure below.
+
+
+Time Relationship of Scheduled Overlapping Events
+
+
+Client (Inverter) Behavior
+Server
+Client
+
+In the second case, the charging station receives the higher priority control while executing the lower priority control. In this case, the charging station continues with the lower priority control until the start time of the higher priority control. It then supersedes the lower priority control and switches to executing the higher priority control as shown in the figure below.
+
+
+Figure 205. Control received before start of superseded control. From [RefCSIP]
+Client (Inverter) Behavior
+
+
+Server
+Figure 206. Control received after start of superseded event. From [RefCSIP]
+Client
+
+Superseded controls remain present in the charging station and are reported with a isSuperseded flag set to true. Controls that are past their scheduled time and duration will be automatically removed by the charging station.
+
+# Scheduling by CSMS
+
+Ideally, CSMS will take care of the prioritization and only send the highest priority DER control to the charging station. However, in some cases this must be handled by the charging station. An example of this is the situation where CSMS has already sent a DER control for "X" with priority = 1 to the charging station, and this control is now active. Then suddenly CSMS receives another DER control for "X" with priority = 0 that is overlapping, as shown in figure Control received after start of superseded event. From [RefCSIP]. If charging station would not be able to handle controls with different priority, then CSMS would have to send the new control with priority = 0 at the moment that it should start, thus replacing the older control. However, due to network and system latency, it would be impossible to guarantee that the new event starts exactly at its startTime. The charging station will thus have to deal with two or more controls for the same type with different priorities.
+
+# Chapter 3. Use Cases for DER control
+
+Following use cases describe how a power setting, a DER setting, a trip curve and a power curve can be configured and activated.
+
+# R01 - Starting a V2X session with DER control in EVSE
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Starting a V2X session with DER control in EVSE</td></tr><tr><td>2</td><td>ID</td><td>R01</td></tr><tr><td>3</td><td>Objective(s)</td><td>To start a bidirectional charging session with DER control performed by inverter in the EVSE. This is always the case for DC EVSEs, but can also be used in case of AC charging if the Charging Station is capable of controlling (dis)charging behavior of EV such that it meets DER control settings.</td></tr><tr><td>4</td><td>Description</td><td>This use case illustrates how DER control can be executed in three different scenarios: ISO 15118-20 DC_BPT, CHAdeMO and ISO 15118-20 AC_BPT.A utility has set specific grid parameters (DER controls) that are required to be applied to bidirectional charging sessions.CSMS configures the settings at the Charging Station.An EV starts a bidirectional charging session.No DER control settings need to be applied to the EV, since the EVSE of the Charging Station will handle these.For an ISO 15118-20 DC_BPT or CHAdeMO charging session, the inverter is part of (and controlled by) the Charging Station.For an ISO 15118-20 AC_BPT charging session, the inverter is in the EV and cannot be configured by the Charging Station. Instead, the Charging Station will control charging behavior via ChargeLoop message in a way that it adheres as much as possible to the DER control settings of the Charging Station.</td></tr><tr><td></td><td>Actors</td><td>Utility, CSMS, Charging Station, EV</td></tr><tr><td></td><td>Scenario description #1</td><td>A DC bidirectional session using ISO 15118-20 DC_BPT1. EV and Charging Station start an ISO 15118-20 session.2. Upon successful authorization the EV starts service negotiation and selects the DC_BPT service.3. EV and Charging Station exchange charge parameters4. Charging Station sends NotifyEVChargingNeedsRequest with departureTime and v2xChargingParameters.5. CSMS calculates a TxProfile for this session, which may contain periods of discharging, and sends it as a SetChargingProfileRequest.6. Charging Station responds with ScheduleExchangeRes to EV.a. If controlMode = Scheduled is used, then ScheduleExchangeRes will contain the TxProfile schedule.b. If controlMode = Dynamic is used, then Charging Station will update charging/discharging levels via the ChargeLoop messages with EV to match the TxProfile schedule.7. EV requests start of charging with a PowerDeliveryReq.8. EV starts charging.9. EV will start discharging according to schedule periods in TxProfile schedule.10. DER control is executed by Charging Station.a. Discharging power of EVSE inverter will be limited to 50% of its rated capacity.b. Power will be adjusted according to grid voltage as defined by the configured VoltWatt curve.</td></tr><tr><td></td><td>Scenario description #2</td><td>A DC bidirectional session using CHAdeMO
+1. EV is authorized and starts a charging session.
+2. EV and Charging Station exchange charge parameters.
+3. CSMS calculates a TxProfile for this session, which may contain periods of discharging, and sends it as a SetChargingProfileRequest.
+4. Charging Station will update charging/discharging levels via CHAdeMO messages with EV to match the TxProfile schedule.
+5. EV will start discharging according to schedule periods in TxProfile schedule.
+6. DER control is executed by Charging Station:
+ a. It will limit discharging power of EVSE inverter to 50% of its rated capacity.
+ b. It will adjust power of EVSE inverter according to grid voltage as defined by the configured VoltWatt curve.</td></tr><tr><td></td><td>Alternative description</td><td>An AC bidirectional session using ISO 15118-20 AC_BPT
+1. EV and Charging Station start an ISO 15118-20 session.
+2. Upon successful authorization the EV starts service negotiation and selects the AC_BPT service.
+The following steps 3 to 9 are identical to the DC_BPT scenario
+10. Inverter is in EV, but DER control is executed by Charging Station:
+ a. It will limit discharging power of EV to 50% of its rated capacity during ChargeParameterDiscovery by setting the EVSEMaximumDischargePower to 50% of reported EVMaximumDischargePower.
+ b. It will adjust power according to grid voltage as defined by the configured VoltWatt curve by controlling EVSETargetActivePower using ChargeLoop control.</td></tr><tr><td>5</td><td>Prerequisites</td><td>·In advance utility has sent DER control settings to the CSMS of CSO. In this example these are a VoltWatt curve and a limitation of discharging power to 50% of the rated power of the inverter.
+·CSMS has conveyed these settings as SetDERControlRequest messages to the Charging Station:
+ 1. SetDERControlRequest(isDefault = true,CONTROLType = VoltWatt, curve = {...})
+ 2. SetDERControlRequest(isDefault = true,CONTROLType = LimitDischargePower, limitMaxDischarge = {pctMaxDischargePower = 50.0})
+See use cases R04 - Configure DER control settings at Charging Station.</td></tr><tr><td>6</td><td>Post conditions</td><td>The charging session adheres to DER control settings from utility.</td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>The descriptions using ISO 15118 messages, such the use of ChargeParameterDiscovery and ChargeLoop for DER control, are only informative and not prescriptive.</td></tr></table>
+
+
+Figure 207. Sequence diagram of an ISO 15118-20 DC bidirectional session with DER control in EVSE
+
+# R01 - Starting a V2X session with DER control in EVSE - Requirements
+
+Table 161. R01 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>R01.FR.01</td><td>Charging Station supports DC bidirectional power transfer</td><td>Charging Station SHALL expose the DER capabilities of the DC inverter, also referred to as nameplate information, in variables of the component DCDERCtrlr for each EVSE.</td><td></td></tr><tr><td>R01.FR.02</td><td>When receiving a GetReportRequest for component DCDERCtrlr</td><td>A DC bidirectional Charging Station SHALL report all variables in DCDERCtrlr that are marked as mandatory.</td><td>This is to report the DER capabilities (or nameplate information) of each EVSE inverter.</td></tr><tr><td>R01.FR.03</td><td>Upon receiving DER controls as SetDERControlRequest messages from CSMS</td><td>Charging Station SHALL store all DER controls settings in the SetDERControlRequest persistently.</td><td>DER controls must persist after a power-cycle or reboot.</td></tr></table>
+
+# R02 - Starting a V2X session with DER control in EV
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Starting a V2X session with DER control in EV</td></tr><tr><td>2</td><td>ID</td><td>R02</td></tr><tr><td>3</td><td>Objective(s)</td><td>To start an AC bidirectional charging session with an EV that supports DER control of its inverter via ISO 15118-20.</td></tr><tr><td>4</td><td>Description</td><td>This use case illustrates how DER control can be executed in the scenarios where ISO 15118-20 AC_BPTDER is used.A utility has set specific grid parameters (DER controls) that are required to be applied to bidirectional charging sessions.CSMS configures the settings at the Charging Station.An EV starts a bidirectional charging session using ISO 15118-20 AC_BPTDER service.Charging Station configures DER control settings in EV, to be executed by the inverter in the EV.</td></tr><tr><td></td><td>Actors</td><td>Utility, CSMS, Charging Station, EV</td></tr><tr><td></td><td>Scenario description</td><td>An AC bidirectional session using AC_BPT DER</td></tr><tr><td></td><td></td><td>1. EV and Charging Station start an ISO 15118-20 session.</td></tr><tr><td></td><td></td><td>2. Upon successful authorization the EV starts service negotiation and requests service details to the AC_BPT DER service.</td></tr><tr><td></td><td></td><td>3. Charging Station presents service parameters that EV must comply with.</td></tr><tr><td></td><td></td><td>a. Parameter DERControlFunctions in the service negotiation specifies in this use case that EV must at least support high frequency ride-through Must Trip mode (bit 11) and limitation of maximum discharge power (bit 20).</td></tr><tr><td></td><td></td><td>4. EV selects the AC_BPT DER service.</td></tr><tr><td></td><td></td><td>5. EV and Charging Station exchange charge parameters.</td></tr><tr><td></td><td></td><td>a. Charging Station sends EV a field DERControl with a FrequencyTrip curve and an ActivePowerSupport field containing the LimitMaxDischargePower with a PercentageValue of 50%.</td></tr><tr><td></td><td></td><td>6. Charging Station sends NotifyEVChargingNeedsRequest with departureTime, v2xChargingParameters and derChargingParameters that contains (among others) nameplate information from EV inverter and a list of DER controls supported by EV.</td></tr><tr><td></td><td></td><td>7. CSMS calculates a TxProfile for this session, which may contain periods of discharging, and sends it as a SetChargingProfileRequest.</td></tr><tr><td></td><td></td><td>8. Charging Station responds with ScheduleExchangeRes to EV.</td></tr><tr><td></td><td></td><td>a. If controlMode = Scheduled is used, then ScheduleExchangeRes will contain the TxProfile schedule.</td></tr><tr><td></td><td></td><td>b. If controlMode = Dynamic is used, then Charging Station will update charging/discharging levels via the ChargeLoop messages with EV to match the TxProfile schedule.</td></tr><tr><td></td><td></td><td>9. EV requests start of charging with a PowerDeliveryReq.</td></tr><tr><td></td><td></td><td>10. EV starts charging.</td></tr><tr><td></td><td></td><td>11. EV will start discharging according to schedule periods in TxProfile schedule.</td></tr><tr><td></td><td></td><td>12. DER control is executed by inverter in EV:</td></tr><tr><td></td><td></td><td>a. It will stop discharging when the frequency deviates from nominal for a certain amount and time as defined in the high frequency trip curve.</td></tr><tr><td></td><td></td><td>b. It will limit discharging power to 50% of its rated capacity as defined by the ActivePowerSupport limitation.</td></tr><tr><td></td><td></td><td>c. When any of the above occurs EV will notify Charging Station about this via the DERAlarm element in the ChargeLoop message with derFunctionName set to HFTrip (a) or LimitMaxPower (b).</td></tr><tr><td></td><td></td><td>13. When a DER control influences the (dis)charging process, Charging Station will notify CSMS about this via the NotifyDERAlarmRequest with controlType set to HFMustTrip or LimitDischargingPower (depending on the event) and gridEventFault = OverFrequency in case of HFMustTrip and the timestamp.</td></tr><tr><td>5</td><td>Prerequisites</td><td>• In advance utility has sent DER control settings to the CSMS of CSO. In this example these are a VoltWatt curve and a limitation of discharging power to 50% of the rated power of the inverter.</td></tr><tr><td></td><td></td><td>• CSMS has conveyed these settings as SetDERControlRequest messages to the Charging Station:</td></tr><tr><td></td><td></td><td>1. SetDERControlRequest(isDefault = true,CONTROLType = HVMustTrip, curve = {...})</td></tr><tr><td></td><td></td><td>2. SetDERControlRequest(isDefault = true,CONTROLType = LimitDischargePower, limitMaxDischarge = { pctMaxDischargePower = 50.0})</td></tr><tr><td></td><td></td><td>See use cases R04 - Configure DER control settings at Charging Station.</td></tr><tr><td>6</td><td>Post conditions</td><td></td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>The descriptions using ISO 15118 messages, such as the use of ChargeParameterDiscovery and ChargeLoop for DER control, are only informative and not prescriptive.The DER controls HFMustTrip and PowerMonitoring are just an example in this use case. In reality more DER controls are likely to be required.</td></tr></table>
+
+
+Figure 208. Sequence diagram of an ISO 15118-20 AC bidirectional session with DER control in EV
+
+# R02 - Starting a V2X session with DER control in EV - Requirements
+
+Table 162. R02 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>R02.FR.01</td><td>Charging Station starts AC bidirectional power transfer session with EV via ISO 15118-20 AC_BPT DER service</td><td>Charging Station SHALL expose the DER capabilities of the DC inverter in EV, also referred to as nameplate information, in the field derChargeParameters of a NotifyEVChargingNeedsRequest.</td><td></td></tr><tr><td>R02.FR.02</td><td>Upon receiving DER controls as SetDERControlRequest messages from CSMS</td><td>Charging Station SHALL store all DER controls settings in the SetDERControlRequest persistently.</td><td>DER controls must persist after a power-cycle or reboot. (Same as R01.FR.03)</td></tr><tr><td>R02.FR.03</td><td>R02.FR.02</td><td>Charging Station SHALL send received DER controls to EV.</td><td>Using the ISO 15118-20 ChargeParameterDiscoveryRes message.</td></tr></table>
+
+# R03 - Starting a V2X session with hybrid DER control in both EV and EVSE
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Starting a V2X session with hybrid DER control in both EV and EVSE</td></tr><tr><td>2</td><td>ID</td><td>R03</td></tr><tr><td>3</td><td>Objective(s)</td><td>To start an AC bidirectional charging session with an EV that supports part of the DER control and an EVSE that supports another part.</td></tr><tr><td>4</td><td>Description</td><td>This use case illustrates how DER control can be executed in the scenario where ISO 15118-20 AC_BPTDER is used, but not all controls are executed by the inverter in the EV.A utility has set specific grid parameters (DER controls) that are required to be applied to bidirectional charging sessions.CSMS configures the settings at the Charging Station.An EV starts a bidirectional charging session using ISO 15118-20 AC_BPTDER service.Charging Station configures DER control settings in EV, to be executed by the inverter in the EV.DER controls that are not supported by EV are handled by EVSE.</td></tr><tr><td></td><td>Actors</td><td>Utility, CSMS, Charging Station, EV</td></tr><tr><td></td><td>Scenario description</td><td>A AC bidirectional session using AC_BPT_DER1. EV and Charging Station start an ISO 15118-20 session.2. Upon successful authorization the EV starts service negotiation and requests service details to the AC_BPT_DER service.3. Charging Station presents service parameters that EV must comply with.a. Parameter DERControlFunctions in the service negotiation specifies in this use case that EV must at least support high frequency ride-through Must Trip mode (bit 11).4. EV selects the AC_BPT_DER service.5. EV and Charging Station exchange charge parameters.a. EV does not report support for PowerMonitoring in evSupportedDERControl. This can be emulated by the Charging Station if it is listed in the variable ACDERCtrlmodesSupported.b. Charging Station sends a field DERControl with FrequencyTripCurve containing the FrequencyTrip curve.c. During charging the Charging Station will limit the maximum discharge power to 50% of the reported EVMaximumDischargePower in the ChargeLoopRes message with field EVSETTargetActivePower.Remaining steps 6 to 11 are identical to use case R0212. The following DER control is executed by inverter in EV:a. It will stop discharging when the frequency deviates from nominal for a certain amount and time as defined in the high frequency trip curve.b. When the above occurs EV will notify Charging Station about this via the DERAlarm element in the ChargeLoop message with derFunctionName set to HFTrip.13. The following DER control is executed by Charging Station:a. It will limit discharging power to 50% of EVMaximumDischargePower as defined by the ActivePowerSupport limitation.14. When a DER control influences the (dis)charging process, for example an overfrequency, Charging Station will notify CSMS about this via the NotifyDERAlarmRequest with controlType set to HFMustTrip and gridEventFault = OverFrequency and the timestamp.</td></tr><tr><td>5</td><td>Prerequisites</td><td>In advance utility has sent DER control settings to the CSMS of CSO. In this example these are a high frequency trip curve (HFMustTrip) and a limitation of discharging power (LimitMaxDischarge) to 50% of the rated power of the inverter.CSMS has conveyed the settings as SetDERControlRequest messages to Charging Station.</td></tr><tr><td>6</td><td>Post conditions</td><td></td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td>The descriptions using ISO 15118 messages, such as the use of ChargeParameterDiscovery and ChargeLoop for DER control, are only informative and not prescriptive.</td></tr></table>
+
+
+Figure 209. Sequence diagram of an ISO 15118-20 AC bidirectional session with DER control in EV
+
+# R03 - Starting a V2X session with hybrid DER control in both EV and EVSE - Requirements
+
+Table 163. R03 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>R03.FR.01</td><td>Charging Station start AC bidirectional power transfer session with EV via ISO 15118-20 AC_BPT DER service</td><td>Charging Station SHALL expose the DER capabilities of the DC inverter in EV, also referred to as nameplate information, in the field derChargeParameters of a NotifyEVChargingNeedsRequest.</td><td>(Same as R02.FR.01)</td></tr><tr><td>R03.FR.02</td><td>Upon receiving DER controls as SetDERControlRequest messages from CSMS</td><td>Charging Station SHALL store DER controls persistently.</td><td>DER controls must persist after a power-cycle or reboot. (Same as R01.FR.03)</td></tr><tr><td>R03.FR.03</td><td>If Charging Station is able to emulate certain DER controls locally</td><td>Charging Station SHALL list these DER controls in variable ACDERCtrlmodesSupported</td><td>These are DER controls that Charging Station can emulate using ChargeLoop message to control the EV inverter.</td></tr><tr><td>R03.FR.04</td><td>If Charging Station is able to locally emulate a certain DER control</td><td>Charging Station MAY omit this DER control from the list or required DER controls in the ISO 15118-20 service negotiation for AC_BPT DER.</td><td>This will allow an EV whose inverter does not support this DER control to participate in bidirectional power transfer, because this specific DER control is emulated by Charging Station.</td></tr><tr><td>R03.FR.05</td><td>If Charging Station is able to locally emulate a certain DER control, but this DER control is also supported by EV</td><td>Charging Station SHALL NOT emulate this DER control, but configure it in EV.</td><td>Capabilities of the inverter must be used much as possible.</td></tr><tr><td>R03.FR.06</td><td>R03.FR.02</td><td>Charging Station SHALL send received DER controls, that it does not emulate locally, to EV.</td><td>Using the ISO 15118-20 ChargeParameterDiscoveryRes message. (Same as R02.FR.02)</td></tr></table>
+
+# R04 - Configure DER control settings at Charging Station
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Configure DER control settings at Charging Station</td></tr><tr><td>2</td><td>ID</td><td>R04</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show how a number of different DER settings can be configured.</td></tr><tr><td>4</td><td>Description</td><td>This use case contains several scenarios that show how DER settings are configured at a Charging Station. Not all possible DER controls are shown in these scenarios, but all are set as default or scheduled in a similar way.</td></tr><tr><td></td><td>Actors</td><td>Utility, CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description #1</td><td>Frequency droop as default DER control1. CSMS receives new frequency droop parameters from utility.2. For each charging station in region of utilitya. CSMS issues SetDERControlRequest messages with isDefault = true,(controlType = FreqDroop and freqDroop field set to the frequency droop parameters: overFreq, underFreq, overDroop, underDroop, responseTime and without a startTime or duration.b. CS responds with SetDERControlResponse with status = Accepted.c. The default frequency droop will immediately become active.</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td><td></td></tr><tr><td></td><td>Scenario description #2</td><td>Frequency droop as a scheduled DER control1. CSMS receives new frequency droop parameters from utility.2. For each charging station in region of utilitya. CSMS issues SetDERControlRequest messages with isDefault = false,(controlType = FreqDroop and freqDroop field set to the frequency droop parameters: overFreq, underFreq, overDroop, underDroop, responseTime and with a startTime and duration.b. CS responds with SetDERControlResponse with controlType = FreqDroop and status = Accepted.c. At startTime CS will report with a NotifyDERStartStopRequest that the frequency droop has become active (thus overruling any default setting for frequency droop, if present).</td><td></td></tr><tr><td></td><td>Scenario description #3</td><td>Ride-through curve as a default DER control1. CSMS receives new default HFRT curve from utility2. For each charging station in region of utilitya. CSMS installs new DER curve, using SetDERControlRequest with controlType = HFMayTrip, isDefault = true, and an object DERCurveType with yUnit = Not_Aplicable and curveData containing the curve points.b. CS responds with SetDERControlResponse with status = Accepted.3. If the net frequency deviates from nominal, only when it exceeds curveData.x Herz for more than curveData.y seconds, shall Charging Station stop exporting power to or importing power from the grid.a. When that happens Charging Station notifies CSMS via a NotifyDERAlarmRequest with controlType = HFMayTrip and gridEventFault = OverFrequency.</td><td></td></tr><tr><td rowspan="2"></td><td rowspan="2">Scenario description #4</td><td>VoltVar Q(U) curve as a default DER control1. CSMS receives new scheduled VoltVar curve from utility2. For each charging station in region of utilitya. CSMS installs new DER curve, using SetDERControlRequest with controlType = VoltVar and a DERCurveType object with yUnit set to one of PctMaxW, PctMaxVar or PctVarAvail and curveData containing the curve points, and a startTime and duration.b. CS responds with SetDERControlResponse with status = Accepted.3. At startTime CS will send a NotifyDERStartStopRequest with controlled for this curve and started = true.4. From startTime onwards, for a period of duration seconds, Charging Station will continuously adjust the amount of reactive power according to the VoltVar curve by sending an EVSETargetReactivePower element without a corresponding EVSETargetActivePower element in the AC/DC_ChargeLoop messages.a. Since this does not affect the active power profile of the charging/discharging sessions, CS will not notify CSMS about it, unless the charging profile has a setting for setpointReactive, in which case CS sends a NotifyDERAlarmRequest with controlType = VoltVar.5. At startTime + duration (i.e. when control ends) CS will send a NotifyDERStartStopRequest with controlled for the curve and started = false.</td><td></td></tr><tr><td>NOTE</td><td>According to ISO 15118-20, when in scheduled control mode, and the grid code only demands a specific reactive power behavior (e.g. resulting from a Q(U) rule), the SECC (EVSE) shall only send an EVSETargetReactivePower element without a corresponding EVSETargetActivePower element. This allows to satisfy grid code requirements without interfering in the normal EVPowerProfile.</td></tr><tr><td>5</td><td>Prerequisites</td><td></td><td></td></tr><tr><td>6</td><td>Post conditions</td><td></td><td></td></tr><tr><td>7</td><td>Error Handling</td><td></td><td></td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td rowspan="4">8</td><td rowspan="4">Remarks</td><td>This use case is similar for other DER controls.</td></tr><tr><td>Charging station has to store these values persistently.</td></tr><tr><td>The HFMayTrip curve configures ride-through behavior.</td></tr><tr><td>The HFMustTrip curve configures the trip behavior.</td></tr></table>
+
+# R04 - Configure DER control settings at Charging Station - Requirements
+
+Table 164. R04 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td colspan="4">SetDERControl</td></tr><tr><td>R04.FR.01</td><td>Charging Station receives a SetDERControlRequest with a(controlType that it does not support</td><td>Charging Station SHALL respond with SetDERControlResponse with status = NotSupported.</td><td></td></tr><tr><td>R04.FR.02</td><td>Charging Station receives a SetDERControlRequest with isDefault = true and a(controlType that it supports AND no default DER control of(controlType exists</td><td>Charging Station SHALL configure this DER control as the new default DER control, and respond with SetDERControlResponse with status = Accepted.</td><td></td></tr><tr><td>R04.FR.03</td><td>Charging Station receives a SetDERControlRequest with isDefault = true and a(controlType that it supports AND an existing default DER control of(controlType has a higher value for priority</td><td>Charging Station SHALL set the isSuperseded attribute of the existing control to true and accept the new control as the new default DER control, and respond with SetDERControlResponse with status = Accepted and supersededId with Id of superseded control.</td><td>A lower priority value overrules a higher priority value.</td></tr><tr><td>R04.FR.04</td><td>(R04.FR.02 OR R04.FR.03) AND a scheduled DER control for(controlType is already active</td><td>Charging Station SHALL accept this default DER control and respond with SetDERControlResponse with status = Accepted and continue to execute the scheduled DER curve.</td><td>Replacing a default curve while a scheduled curve is active (between startTime and duration seconds) will not affect the scheduled curve.</td></tr><tr><td>R04.FR.05</td><td>Charging Station receives a SetDERControlRequest with isDefault = false and a(controlType that it supports AND no scheduled DER control of(controlType exists</td><td>Charging Station SHALL accept this DER control, and respond with SetDERControlResponse with status = Accepted.</td><td></td></tr><tr><td>R04.FR.06</td><td>Charging Station receives a SetDERControlRequest with isDefault = false and a(controlType that it supports AND an existing scheduled DER control of(controlType, that is not yet active, has a higher value for priority</td><td>Charging Station SHALL set the isSuperseded attribute of the existing control to true and accept the new control as the new scheduled DER control for(controlType, and respond with SetDERControlResponse with status = Accepted, and supersededId with Id of superseded control.</td><td>A lower priority value has preference. The existing scheduled DER control is immediately superseded, even when startTime of the new control is later than that of the existing control.</td></tr><tr><td>R04.FR.07</td><td>Charging Station receives a SetDERControlRequest with a(controlType that it supports AND an existing scheduled DER control of(controlType is already active and has a higher value for priority</td><td>Charging Station SHALL respond with SetDERControlResponse with status = Accepted and SHALL continue to execute the existing control untilstartTime of the new control, upon which the isSuperseded attribute of the existing control is set to true and the new control is executed for(controlType.</td><td>A lower priority value has preference. When the existing scheduled DER control is already active, it remains active until thestartTime of the new control.</td></tr><tr><td>R04.FR.08</td><td>Charging Station receives a SetDERControlRequest with a(controlType that it supports AND an existing scheduled DER control of(controlType is already active and has a lower value for priority</td><td>Charging Station SHALL respond with SetDERControlResponse with status = Accepted, and supersededId =CONTROLd, and SHALL set the isSuperseded attribute to true and continue to execute the existing setting forCONTROLd.</td><td>A lower priority value has preference. This new control is immediately superseded by the existing control which has lower priority value. CSMS should avoid sending a DER control that has a higher priority value than what is already configured.</td></tr><tr><td>R04.FR.09</td><td></td><td>Charging Station SHALL NOT execute a control which has isSuperseded = true</td><td></td></tr><tr><td>R04.FR.10</td><td></td><td>Charging Station SHALL delete a control afterstartTime + duration seconds has expired</td><td></td></tr><tr><td>R04.FR.11</td><td>When there is no control active for(controlType that has isDefault = false</td><td>Charging Station SHALL execute the control for(controlType that has isDefault = true and isSuperseded = false</td><td>When there is no scheduled control active (after itsstartTime), then revert to the default control.</td></tr><tr><td colspan="4">NotifyDERStartStop</td></tr><tr><td>R04.FR.20</td><td>When a DER control has isDefault = false, isSuperseded = false andstartTime equals current time</td><td>Charging Station SHALL send a NotifyDERStartStopRequest withCONTROLd for this control, started = true, and timestamp is current time.</td><td>Start of DER control atstartTime is reported.</td></tr><tr><td>R04.FR.21</td><td>(When a DER control A has isDefault = false, isSuperseded = false andstartTime is current time) AND (another DER control B has isDefault = false, isSuperseded = false and a higher value for priority and is currently active)</td><td>Charging Station SHALL send a NotifyDERStartStopRequest withCONTROLd = A, started = true, and supersededId = B and timestamp is current time.</td><td>Starting of A will supersede B.</td></tr><tr><td>R04.FR.22</td><td>When a DER control has isDefault = false, isSuperseded = false andstartTime + duration equals current time</td><td>Charging Station SHALL send a NotifyDERStartStopRequest withCONTROLd for this control, started = false, and timestamp is current time.</td><td>End of DER control after duration is reported.</td></tr><tr><td colspan="4">GetDERControl</td></tr><tr><td>R04.FR.30</td><td>Charging Station receives a GetDERControlRequest AND no DER controls are present on Charging Station for given isDefault,CONTROL type and controlId</td><td>Charging Station SHALL return a status = NotFound in GetDERControlResponse.</td><td>A missing isDefault,(controlType or controlId in the request matches any value of isDefault,controlType or controlId.</td></tr><tr><td>R04.FR.31</td><td>When Charging Station receives a GetDERControlRequest</td><td>The Charging Station SHALL set the requestId in every ReportDERControlRequest to the value of requestId in GetDERControlRequest.</td><td></td></tr><tr><td>R04.FR.32</td><td>When the DER controls are reported in more than one ReportDERControlRequest</td><td>Charging Station SHALL set the tbc flag to true for all ReportDERControlRequest messages except the last.</td><td></td></tr><tr><td>R04.FR.33</td><td>Charging Station receives a GetDERControlRequest without isDefault,CONTROL and DER controls are present on Charging Station</td><td>Charging Station SHALL return a status = Accepted and send one or more ReportDERControlRequest messages for all controls.</td><td>Returns all controls.</td></tr><tr><td>R04.FR.34</td><td>NOT R04.FR.30 AND Charging Station receives a GetDERControlRequest with no controlId and with a controlType that it supports</td><td>Charging Station SHALL return a status = Accepted and send one or more ReportDERControlRequest messages for all controls that match the value of controlType and isDefault (if present) in the GetDERControlRequest.</td><td>Returns controls for controlType (matching isDefault if present).</td></tr><tr><td>R04.FR.35</td><td>NOT R04.FR.30 AND Charging Station receives a GetDERControlRequest with no controlType and with a controlId</td><td>Charging Station SHALL return a status = Accepted and send one or more ReportDERControlRequest messages for all controls that match the value of controlId and isDefault (if present).</td><td>Returns the controls for controlId (matching isDefault if present).</td></tr><tr><td>R04.FR.36</td><td>Charging Station receives a GetDERControlRequest with a controlType that it does not support</td><td>Charging Station SHALL return a status = NotSupported in GetDERControlResponse.</td><td></td></tr><tr><td colspan="4">ClearDERControl</td></tr><tr><td>R04.FR.41</td><td>Charging Station receives a ClearDERControlRequest with no controlId and with a controlType that it supports, but that has not been set at the Charging Station for the specified value of isDefault</td><td>Charging Station returns a ClearDERControlResponse with status = NotFound.</td><td></td></tr><tr><td>R04.FR.42</td><td>Charging Station receives a ClearDERControlRequest with no controlType and with a controlId that has not been set for the given value of isDefault</td><td>Charging Station SHALL respond with ClearDERControlResponse with status = NotFound.</td><td></td></tr><tr><td>R04.FR.43</td><td>Charging Station receives a ClearDERControlRequest with no controlId and with a controlType that it does not support</td><td>Charging Station returns a ClearDERControlResponse with status = NotSupported.</td><td></td></tr><tr><td>R04.FR.44</td><td>Charging Station receives a ClearDERControlRequest without controlType and without controlId</td><td>Charging Station SHALL clear all controls that match the value of isDefault in the request, and return a ClearDERControlResponse with status = Accepted.</td><td>Clear all default or all scheduled messages based on value of isDefault.</td></tr><tr><td>R04.FR.45</td><td>Charging Station receives a ClearDERControlRequest with no controlId and with a(controlType that it supports and that is in use</td><td>Charging Station SHALL clear all controls that match the value of isDefault andCONTROLType in the request, and return a ClearDERControlResponse with status = Accepted.</td><td>Return default or scheduled messages forCONTROLType based on value of isDefault.</td></tr></table>
+
+# R05 - Charging station reporting a DER event
+
+New in OCPP 2.1
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Charging station reporting a DER event</td></tr><tr><td>2</td><td>ID</td><td>R05</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show how a charging station reports that it is acting upon a VoltWatt DER curve, because this affects the power profile of the charging session.</td></tr><tr><td>4</td><td>Description</td><td>A grid anomaly occurs that forces a charging station to adjust behavior according to a preconfigured VoltWatt DER curve</td></tr><tr><td></td><td>Actors</td><td>CSMS, Charging Station</td></tr><tr><td></td><td>Scenario description</td><td>1. Voltage at grid connection point exceeds a threshold value from the VoltWatt curve while EV is discharging.
+2. CS reports that it is adjusting discharging behavior according to VoltWatt curve via a NotifyDERAlarmRequest message with controlType = VoltWatt and gridEventFault = OverVoltage.
+3. If CS is a DC station: CS lowers discharging power according to VoltWatt curve.
+4. If CS is an AC station: CS instructs EV via ISO 15118-20 AC_ChargeLoop message to lower discharging power. CS repeats this every time the power value on the curve changes.
+5. When voltage returns back to normal, CS reports end of this situation, via a NotifyDERAlarmRequest with controlType = VoltWatt, gridEventFault = OverVoltage and alarmEnded = true.
+6. CS continues to follow the active charging profile.</td></tr><tr><td>5</td><td>Prerequisites</td><td>A VoltWatt curve has been configured at the charging station.
+In case of an AC station, the ISO 15118-20 AC_BPT service is used, or AC_BPTDER is used without installing a VoltWatt curve in the EV, thus requiring the Charging Station to control power via the AC_ChargeLoop message. This assumes a discharging transaction was active during the entire event.</td></tr><tr><td>6</td><td>Post conditions</td><td></td></tr><tr><td>7</td><td>Error Handling</td><td></td></tr><tr><td>8</td><td>Remarks</td><td></td></tr></table>
+
+Utility
+
+CSMS
+
+Utility sends 2 VoltWatt controls
+
+from different DER Programs
+
+and a scheduled power limit.
+
+(Pseudo IEEE 2030.5 messages)
+
+DERCurve(#1, "Volt-Watt 1", ...)
+
+DERCurve(#2, "Volt-Watt 2", ...)
+
+DefaultDERControl(opModVoltWatt, #1, primacy=1)
+
+DERControl(opModMaxLimW, 10000W,
+
+startTime=1675206000, duration=3600)
+
+DefaultDERControl(opModVoltWatt, #2, primacy=0)
+
+Charging Station
+
+AC EV
+
+CSMS only sends highest prio default to CS
+
+SetDERControlRequest(default=true,
+
+controlType=VoltWatt, curve=#2)
+
+SetDERControlResponse(Accepted)
+
+SetChargingProfile(ChargingStationMaxProfile, 10000W,
+
+startTime=1675206000, duration=3600)
+
+SetChargingProfileResponse(Accepted)
+
+EV starts charging
+
+ISO 15118-20 authorization
+
+AuthorizationRequest...
+
+AuthorizationResponse(Accepted)
+
+ServiceSelection(AC_BPT)
+
+ChargeParameterDiscovery(power, current, voltage)
+
+ScheduleExchangeReq(energyRequest, departureTime)
+
+NotifyEVChargingNeedsRequest(...)
+
+NotifyEVChargingNeedsResponse(Accepted)
+
+SetChargingProfileResponse(schedule max=10000W)
+
+SetChargingProfileResponse(Accepted)
+
+loop
+
+[while charging]
+
+AC_ChargeLoopReq()
+
+AC_ChargeLoopRes()
+
+Charging Station detects overvoltage situation
+
+triggering VoltWatt curve
+
+NotifyDERAlarmRequest(true, VoltWatt, timestamp)
+
+NotifyDERAlarmResponse()
+
+When overvoltage situation ends
+
+AC_ChargeLoop(Resume discharging power
+
+according to schedule)
+
+NotifyDERAlarmRequest(false, VoltWatt, timestamp)
+
+NotifyDERAlarmResponse()
+
+Figure 210. Sequence diagram showing VoltWatt curve and charging limit from utility
+
+# R05 - Charging station reporting a DER event - Requirements
+
+Table 165. R05 - Requirements
+
+<table><tr><td>ID.</td><td>Precondition</td><td>Requirements</td><td>Note</td></tr><tr><td>R05.FR.01</td><td>When Charging Station needs to deviate from charging profile or nominal charging rate in case of no charging profile, because of a DER control setting or curve</td><td>Charging Station SHALL report this once per occurrence by sending a NotifyDERAlarmRequest with timestamp with current time and(control)Type that matches the DER control that causes this andgridEventFault for the fault that caused this.</td><td></td></tr><tr><td>R05.FR.02</td><td>When Charging Station no longer needs to deviate from charging profile or nominal charging rate in case of no charging profile, because of a DER control setting or curve</td><td>Charging Station SHALL report the end of this situation by sending a NotifyDERAlarmRequest with alarmEnded = true, timestamp with current time and(controlType that matches the DER control that is no longer taking over andgridEventFault for the fault that caused this.</td><td></td></tr><tr><td>R05.FR.03</td><td>When a NotifyDERAlarmRequest with alarmEnded = false or absent has been reported for DER control A for(controlType X and Charging Station needs to deviate from this because of a DER control B that is now activated for(controlType Y</td><td>Charging Station SHALL report taking over by DER control B by sending a NotifyDERAlarmRequest with alarmEnded = false or absent, timestamp with current time and(controlType = B and gridEventFault = Y.</td><td></td></tr><tr><td>R05.FR.04</td><td>R05.FR.03</td><td>Charging Station SHALL NOT report the ending of the alarm by DER control A via NotifyDERAlarmRequest</td><td>There are no multiple levels of alarm. Alarm is still active. Only the(controlType andgridEventFault have changed.</td></tr></table>
+
+# S. Battery Swapping
+
+# Chapter 1. Introduction
+
+Battery swapping is the process whereby an EV driver exchanges the near empty EV battery for a charged EV battery. The returned battery is placed in a dock and then charged again. Once it reaches a certain level of state of charge it becomes eligible to be swapped again for an empty battery.
+
+For light EVs, such as e-scooters, the swapping is a manual process performed by the EV driver. For regular EVs the swapping is an automated process that is initiated by the EV driver, but performed by a machine.
+
+NOTE Depending on the type of EVs the battery swap can consist of a single battery or a set of batteries.
+
+Although this section assumes that an EV driver returns a battery (or set of batteries) before receiving a new battery (or set of batteries), the reverse order is also supported by the described mechanism.
+
+A battery swap action cannot be recorded by OCPP TransactionEvent messages. The action of swapping a battery is not considered a charging transaction; instead, it is a service for which the price can depend, for example, on the difference between the state of charge of the old and new batteries or be based on a monthly fee. OCPP 2.1 introduces a new message to record the swapping of batteries. The actual charging of batteries in the dock can still be tracked by CSMS via TransactionEvent messages.
+
+A battery swap station has multiple slots that to hold batteries. In OCPP, a battery swap station is treated as a charging station. Similar to charging stations, where one EVSE charges one EV, OCPP assumes that, in a battery swap station, conceptually one EVSE powers one battery slot. (In practice, it may be possible that a single power supply unit is used to charge batteries in multiple slots one after the other). Different types of battery slots can be represented by specifying a different connector type for an EVSE in the Device Model variable ConnectorType. (See Example representation of a battery swap station in device model).
+
+# Chapter 2. Availability states for a battery slot
+
+The OCPP availability states are about availability or occupancy of an EVSE/Connector. That means that:
+
+- "Available" means no battery is present in slot.
+- "Occupied" means a battery is present in slot.
+- "Unavailable" means slot cannot be used.
+
+It is important to understand that this differs from the "availability of the swapping service". An "Available" slot does not contain a battery for swapping, whereas an "Occupied" slot does have a battery that can be used for swapping (assuming it has a high enough state of charge).
+
+# Chapter 3. Use cases for Battery Swapping
+
+# S01 - Battery Swap Local Authorization
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Battery Swap Local Authorization</td></tr><tr><td>2</td><td>ID</td><td>S01</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show how a battery swap action is authorized locally at the swap station.</td></tr><tr><td>4</td><td>Description</td><td>EV Driver authorizes locally at the swap station by presenting an RFID card.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. EV Driver authorizes at swap station by presenting a valid RFID card.
+2. Charging Station (swap station) sends an Request with Token to CSMS.
+a. CSMS grants authorization to swap in the Response with TokenInfo.status = Accepted.
+3. Charging Station opens or indicates empty slot(s) where the set of empty batteries can be inserted.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>EV Driver has a valid contract for swapping.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>When successful, use case S03 - Battery Swap In/Out starts.</td></tr><tr><td>7</td><td>Error handling</td><td>When Charging Station has not enough batteries available for swapping, the swap action is refused and use case ends.</td></tr><tr><td>8</td><td>Remark(s)</td><td>Authorization of EV Driver using an RFID card follows the process of use case C01 - EV Driver Authorization using RFID.
+Since the authorization for battery swapping is not used to start a transaction, any requirements in C01 that are about behavior of authorization when a transaction for the idToken is in progress, are not relevant, because the situation does not occur.</td></tr></table>
+
+
+Figure 211. Sequence diagram for local authorization
+
+# S01 - Battery Swap Local Authorization - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>S01.FR.01</td><td>Upon successful authorization ofauthorizeRequest for an idToken AND when enough batteries are available for a swap</td><td>Charging Station (swap station) SHALL open or indicate an empty slot(s) where returned batteries can be inserted.</td><td></td></tr><tr><td>S01.FR.02</td><td>When an idToken has been authorized and the EV Driver does not insert a battery into a slot before the timeout set by the Configuration Variable: BatterySwapInTimeout</td><td>Charging Station SHALL end the authorization of idToken and abort the battery swap process.</td><td>At this point no BatterySwapRequest has been sent yet.</td></tr></table>
+
+# S02 - Battery Swap Remote Start
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Battery Swap Remote Start</td></tr><tr><td>2</td><td>ID</td><td>S02</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show how a battery swap action is requested remotely by CSMS.</td></tr><tr><td>4</td><td>Description</td><td>EV Driver requests CSMS to initiate a battery swap via a smartphone app, e.g. by scanning a QR code or selecting the appropriate station in the app.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. When CSMS authorizes the EV Driver's request to charge via a smartphone app, CSMS sends a RequestBatterySwapRequest with idToken set to the authorization token for the EV Driver and a requestId to be used in the following BatterySwapRequest.
+2. When Charging Station has at least as many batteries available for swapping as needed for the swap:
+a. Charging Station responds with RequestBatterySwapResponse with status = Accepted.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>idToken is authorized to swap.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>When successful, use case S03 - Battery Swap In/Out follows.</td></tr><tr><td>7</td><td>Error handling</td><td>If not enough batteries are available for swapping, the Charging Station responds with RequestBatterySwapResponse with status = Rejected and statusInfoReasonCode = "NoBatteryAvailable".</td></tr><tr><td>8</td><td>Remark(s)</td><td></td></tr></table>
+
+
+Figure 212. Sequence diagram for remote start
+
+# S02 - Battery Remote Start - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>S02.FR.01</td><td>When CSMS sends a RequestBatterySwapRequest for idToken with a requestId AND idToken is authorized by CSMS AND Charging Station has enough batteries available for swapping</td><td>Charging Station SHALL respond with RequestBatterySwapResponse with status = Accepted</td><td></td></tr><tr><td>S02.FR.02</td><td>S02.FR.01</td><td>Charging Station SHALL use the same requestId in the BatterySwapRequest that results from this RequestBatterySwapRequest</td><td>This allows CSMS to associate the BatterySwapRequest with the RequestBatterySwapRequest.</td></tr><tr><td>S02.FR.03</td><td></td><td>CSMS SHALL NOT send send a RequestBatterySwapRequest for an idToken that is not authorized</td><td></td></tr></table>
+
+S03 - Battery Swap In/Out
+
+<table><tr><td>S02.FR.04</td><td>When CSMS sends a RequestBatterySwapRequest for idToken AND idToken is authorized by CSMS AND Charging Station has not enough batteries available for swapping</td><td>Charging Station SHALL respond with RequestBatterySwapResponse with status = Rejected and statusInforeasonCode = "NoBatteryAvailable"</td><td>More information can be provided in field additionalInfo.</td></tr><tr><td>S02.FR.05</td><td>S02.FR.01 AND the EV Driver does not insert a battery into a slot before the timeout set by the Configuration Variable: BatterySwapInTimeout</td><td>Charging Station SHALL end the authorization of idToken and abort the battery swap process.</td><td>At this point no BatterySwapRequest has been sent yet.</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Battery Swap In/Out</td></tr><tr><td>2</td><td>ID</td><td>S03</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show how the action of returning the empty battery and accepting a charge battery is recorded.</td></tr><tr><td>4</td><td>Description</td><td>This use case refers to a "set of batteries", but the set can consist of only a single battery.
+An EV driver presents an empty battery or set of batteries to be swapped. The battery swap station accepts the set of empty batteries and returns set of charged batteries. The swap station records parameters, like serial number, state of charge and state of health of the swapped batteries.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. Charging Station opens or indicates the slot(s) where the set of empty batteries can be inserted.
+2. EV Driver (or swapping machinery) inserts set of empty batteries into empty slot(s) of swap station.
+3. Charging Station sends a BatterySwapRequest with eventType = BatteryIn and a requestId and with idToken set to the authorized idToken, and abatteryData field for each returned battery with evseld set to number of the slot where the battery was inserted, and the parameters serialNumber, SoC, SoH.
+4. If CSMS accepts this battery, then
+ a. CSMS responds with BatterySwapResponse with status = Accepted.
+ b. Charging Station sends a NotifyEventRequest for the EVSE(s) corresponding to the used slot(s) with variable "AvailabilityState" set to "Occupied".
+5. If CSMS does not accept this set of batteries, for example, because one is damaged, then
+ a. CSMS responds with BatterySwapResponse with status = Rejected and statusInfoReasonCode = "BatteryDamaged". (When desired, more specific information can be given in additionalInfo).</td></tr><tr><td></td><td></td><td>6. Charging Station returns a set of batteries to EV Driver to use.
+(The actual method or returning a battery is up to swap station implementation. A battery can be presented by station or user can select one.)
+7. If a battery was still charging
+ a. Charging Station ends the charging transaction and sends a TransactionEventRequest with eventType = Ended.
+8. EV Driver (or swapping machinery) accepts set of batteries and installs it in EV.
+9. Charging Station sends a BatterySwapRequest with eventType = BatteryOut and the requestId from the BatteryIn event and a batteryData field with evse set to number of the slot where each battery is taken from, and the parameters serialNumber, SoC, SoH.
+ a. CSMS responds with BatterySwapResponse with status = Accepted.
+ b. Charging Station sends a NotifyEventRequest for the EVSE corresponding to the slot with variable "AvailabilityState" set to "Available".
+10. EV Driver leaves.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td></td></tr><tr><td>6</td><td>Postcondition(s)</td><td>When successful, use case S04 - Battery Swap Charging follows.</td></tr><tr><td>7</td><td>Error handling</td><td>If CSMS does not accept the inserted battery, it will respond with a BatterySwapResponse with status = Rejected and statusInfo with a reasonCode. Predefined reason codes contain: BatterySoHLow, BatterySoC, BatteryDamaged, BatteryUnknown, BatteryType, NoBatteryAvailable. See Appendix 5 Reason Codes.</td></tr><tr><td>8</td><td>Remark(s)</td><td>A battery swap station is treated as a Charging Station in OCPP in which every battery slot represents a logical EVSE. The BatterySwapRequest message is related to the idToken of the EV Driver. The TransactionEvent messages are not associated with the EV Driver, hence the idToken in the TransactionEvent can be the predefined value in BatterySwapIdtoken or be absent. Battery swap stations usually operate as "old battery in first, new battery out second", as described in this use case. The described mechanism also works, however, when the order is reversed. The use of a StatusNotificationRequest instead of a NotifyEventRequest to report AvailabilityState, is allowed, but use of StatusNotificationRequest has been deprecated.</td></tr></table>
+
+
+Figure 213. Sequence diagram for swapping batteries
+
+# S03 - Battery Swap In/Out - Requirements
+
+S04 - Battery Swap Charging
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>S03.FR.01</td><td>When a set of batteries is inserted into a slot</td><td>Charging Station SHALL send a BatterySwapRequest with eventType = BatteryIn, a requestId, an idToken set to authorized idToken, and batteryData with parameters from each battery with evse set to number of the slot where battery is inserted</td><td>requestId is used to associate BatteryIn and BatteryOut events in CSMS. A set can also consist of a single battery.</td></tr><tr><td>S03.FR.02</td><td>S03.FR.01</td><td>Charging Station SHALL report it as a Connector that is Occupied by a NotifyEventRequest for variable "AvailabilityState" of the Connector.</td><td></td></tr><tr><td>S03.FR.03</td><td>When a set of batteries is removed from a slot</td><td>Charging Station SHALL send a BatterySwapRequest with eventType = BatteryOut, the same requestId as used during BatteryIn, an idToken set to authorized idToken, and batteryData with parameters from the battery with evse set to number of the slot where battery is taken from.</td><td></td></tr><tr><td>S03.FR.04</td><td>S03.FR.03</td><td>Charging Station SHALL report it as a Connector that is Available by a NotifyEventRequest for variable "AvailabilityState" of the Connector.</td><td></td></tr><tr><td>S03.FR.05</td><td>When EV Driver authorizes to perform a battery swap AND Charging has no (or not enough) batteries available for swapping</td><td>Charging Station SHALL refuse the battery swap operation.</td><td></td></tr><tr><td>S03.FR.06</td><td>When the set of batteries offered after insertion of the old batteries is not removed after the timeout specified in BatterySwapOutTimeout</td><td>Charging Station SHALL send a BatterySwapRequest with eventType = BatteryOutTimeout, the same requestId as used during BatteryIn and idToken set to the authorized idToken, and batteryData with parameters from the battery with evse set to the number of the slot from which the battery was offered to EV Driver.</td><td>Situation needs to be reported, because CSMS ends up with an orphan BatteryIn for which a BatteryOut is missing.</td></tr></table>
+
+<table><tr><td>No.</td><td>Type</td><td>Description</td></tr><tr><td>1</td><td>Name</td><td>Battery Swap Charging</td></tr><tr><td>2</td><td>ID</td><td>S04</td></tr><tr><td>3</td><td>Objective(s)</td><td>To show how the charging of swapped batteries is recorded.</td></tr><tr><td>4</td><td>Description</td><td>This use case refers to a "set of batteries", but the set can consist of only a single battery.
+An EV driver has swapped empty batteries for new ones, which the Charging Station will charge again up to a predefined state of charge.</td></tr><tr><td></td><td>Actors</td><td>Charging Station, CSMS</td></tr><tr><td></td><td>Scenario description</td><td>1. Charging Station charges the empty batteries in the swap station.
+a. Charging Station sends a TransactionRequest with eventType = Started and evse set to number of the slot where the battery is in, idToken set to a predefined value in BatterySwapIdtoken or left empty with type =
+NoAuthorization, and triggerReason = CablePluggedIn.
+(CablePluggedIn for a swap station means that the battery has been inserted.)
+b. This follows the regular charging process as described in use cases E02 or E03.
+2. While charging the battery
+a. Charging Station periodically sends a TransactionRequest with the current state of charge of the battery as a metervalued with measurand = "SoC"
+3. When a battery has been charged to the maximum allowed state of charge:
+a. Charging Station suspends the charging transaction and sends a TransactionRequest with eventType = Updated and chargingState =
+SuspendedEVSE and triggerReason = EnergyLimitReached.</td></tr><tr><td>5</td><td>Prerequisite(s)</td><td>A battery is present to be charged.</td></tr><tr><td>6</td><td>Postcondition(s)</td><td>Battery is charged until BatterySwapMaxSoc.</td></tr><tr><td>7</td><td>Error handling</td><td></td></tr><tr><td>8</td><td>Remark(s)</td><td>A battery swap station is treated as a Charging Station in OCPP in which every battery slot represents a logical EVSE.The BatterySwap message is related to the idToken of the EV Driver. The TransactionEvent messages are not associated with the EV Driver, hence the idToken in the TransactionEvent can be the predefined value in BatterySwapIdtoken or be absent.The battery swap station may suspend and resume the charging of batteries or change charging rate as needed, or CSMS can influence the charging rate. This is analogous to local load-balancing and smart charging in regular charging stations.</td></tr></table>
+
+
+Figure 214. Sequence diagram for charging swapped batteries
+
+# S04 - Battery Swap Charging - Requirements
+
+<table><tr><td>ID</td><td>Precondition</td><td>Requirement definition</td><td>Note</td></tr><tr><td>S04.FR.01</td><td>When a battery is inserted into a slot</td><td>Charging Station SHALL start charging the battery.</td><td></td></tr><tr><td>S04.FR.02</td><td>S04.FR.01 AND BatterySwapIdtoken is set</td><td>Charging Station SHALL send a TransactionRequest with eventType = Started and triggerReason = CablePluggedIn and chargingState = Charging and idToken.idToken = BatterySwapIdtoken and idToken.type = Central.</td><td></td></tr><tr><td>S04.FR.03</td><td>S04.FR.01 AND BatterySwapIdtoken is not set</td><td>Charging Station SHALL send a TransactionRequest with eventType = Started and triggerReason = CablePluggedIn and chargingState = Charging and idToken.idToken = "" and idToken.type = NoAuthorization.</td><td></td></tr><tr><td>S04.FR.04</td><td></td><td>Charging Station SHALL send TransactionRequest messages with eventType = Updated with periodic meter values for measurand = "SoC" to inform CSMS of the state of charge of the battery.</td><td>This is to inform CSMS about progress of charging. See SampledDataTxUpdat edMeasurands. The triggerReason will be MeterValuePeriodic if there is no other reason to send a TransactionEventReques t.</td></tr><tr><td>S04.FR.05</td><td>When a battery in a slot is charged to BatterySwapTargetSoc</td><td>Charging Station SHALL make the battery in this slot eligible for swapping.</td><td></td></tr><tr><td>S04.FR.06</td><td>When a battery in a slot is charged to BatterySwapMaxSoc</td><td>Charging Station SHALL suspend energy transfer and send a TransactionRequest with eventType = Updated and triggerReason = EnergyLimitReached and chargingState = SuspendedEVSE.</td><td>Transaction is kept alive to allow that energy transfer is started again (e.g. in case of V2X operations)</td></tr><tr><td>S04.FR.07</td><td>When a battery is removed from a slot</td><td>Charging Station SHALL send a TransactionRequest with eventType = Ended and triggerReason = EVCommunicationLost and chargingState = Idle and stoppedReason = EVDisconnected.</td><td></td></tr><tr><td>S04.FR.08</td><td></td><td>Configuration key TxStartPoint SHALL be "EVConnected"</td><td>The transaction is started when the battery is inserted.</td></tr><tr><td>S04.FR.09</td><td></td><td>Configuration key TxStopPoint SHALL be "EVConnected"</td><td>The transaction is ended when the battery is removed.</td></tr><tr><td>S04.FR.10</td><td></td><td>BatterySwapMaxSoc SHALL be greater than or equal to BatterySwapTargetSoc.</td><td></td></tr><tr><td>S04.FR.11</td><td>When Charging Station reboots</td><td>Charging Station SHALL start new transactions for all EVSEs that have a battery in their slot.</td><td>This includes the ones that have reached their maximum state of charge (BatterySwapMaxSoc). See also S04.FR.06.</td></tr></table>
+
+# Messages, Datatypes & Enumerations
+
+# Chapter 1. Messages
+
+# 1.1. AdjustPeriodicEventStream
+
+# 1.1.1. AdjustPeriodicEventStreamRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 <= val</td><td>1..1</td><td>Required.</td></tr><tr><td>params</td><td>PeriodicStreamParamsType</td><td>1..1</td><td>Required. Updated rate of sending data</td></tr></table>
+
+# 1.1.2. AdjustPeriodicEventStreamResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Status of operation.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information</td></tr></table>
+
+# 1.2. AFRRSignal
+
+# 1.2.1. AFRRSignalRequest
+
+(2.1) This message passes an aFRR signal on to the charging station. Charging station uses the value of signal to select a matching power value from the v2xSignalWattCurve in the ChargingSchedulePeriod.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. Time when signal becomes active.</td></tr><tr><td>signal</td><td>integer</td><td>1..1</td><td>Required. Value of signal in v2xSignalWattCurve.</td></tr></table>
+
+# 1.2.2. AFRRSignalResponse
+
+(2.1) Response stating whether signal was accepted. Response will be Accepted if a v2xSignalWattCurve_element exists in the ChargingSchedulePeriodType for that point in time.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Additional information on status.</td></tr></table>
+
+# 1.3. Authorization
+
+# 1.3.1.authorizeRequest
+
+This contains the field definition of theauthorizeRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificate</td><td>string[0..10000]</td><td>0..1</td><td>Optional. (2.1) 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.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>1..1</td><td>Required. This contains the identifier that needs to be authorized.</td></tr><tr><td>iso15118CertificateHashData</td><td>OCSPRequestDataType</td><td>0..4</td><td>Optional. Contains the information needed to verify the EV Contract Certificate via OCSP. Not needed if certificate is provided.</td></tr></table>
+
+# 1.3.2.authorizeResponse
+
+This contains the field definition of theauthorizeResponse PDU sent by the CSMS to the Charging Station in response to an AuthorizationRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateStatus</td><td>AuthorizationCertificateStatusEnumType</td><td>0..1</td><td>Optional. Certificate status information. - if all certificates are valid: return 'Accepted'. - if one of the certificates was revoked, return 'CertificateRevoked'.</td></tr><tr><td>allowedEnergyTransfer</td><td>EnergyTransferModeEnumType</td><td>0.*</td><td>Optional. (2.1) List of allowed energy transfer modes the EV can choose from. If omitted this defaults to charging only.</td></tr><tr><td>idTokenInfo</td><td>IdTokenInfoType</td><td>1..1</td><td>Required. This contains information about authorization status, expiry and group id.</td></tr><tr><td>tariff</td><td>TariffType</td><td>0..1</td><td>Optional. (2.1) Tariff for this idToken.</td></tr></table>
+
+# 1.4. BatterySwap
+
+# 1.4.1. BatterySwapRequest
+
+(2.1) Message sent by Charging Station when a battery is swapped in or out of a battery swap station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>eventType</td><td>BatterySwapEventEnumType</td><td>1..1</td><td>Required. Battery in/out</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. RequestId to correlate BatteryIn/Out events and optional RequestBatterySwapRequest.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>1..1</td><td>Required. Id token of EV Driver</td></tr><tr><td>batteryData</td><td>BatteryDataType</td><td>1..*</td><td>Required. Info on batteries inserted or taken out.</td></tr></table>
+
+# 1.4.2. BatterySwapResponse
+
+(2.1) Empty response by CSMS to confirm receipt of BatterySwapRequest.
+
+# 1.5. BootNotification
+
+# 1.5.1. BootNotificationRequest
+
+This contains the field definition of the BootNotificationRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>reason</td><td>BootReasonEnumType</td><td>1..1</td><td>Required. This contains the reason for sending this message to the CSMS.</td></tr><tr><td>chargingStation</td><td>ChargingStationType</td><td>1..1</td><td>Required. Identifies the Charging Station</td></tr></table>
+
+# 1.5.2. BootNotificationResponse
+
+This contains the field definition of the BootNotificationResponse PDU sent by the CSMS to the Charging Station in response to a BootNotificationRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>currentTime</td><td>dateTime</td><td>1..1</td><td>Required. This contains the CSMS's current time.</td></tr><tr><td>interval</td><td>integer</td><td>1..1</td><td>Required. When Status is Accepted, this contains the heartbeat interval in seconds. If the CSMS returns something other than Accepted, the value of the interval field indicates the minimum wait time before sending a next BootNotification request.</td></tr><tr><td>status</td><td>RegistrationStatusEnumType</td><td>1..1</td><td>Required. This contains whether the Charging Station has been registered within the CSMS.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.6. CancelReservation
+
+# 1.6.1. CancelReservationRequest
+
+This contains the field definition of the CancelReservationRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>reservationId</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. Id of the reservation to cancel.</td></tr></table>
+
+# 1.6.2. CancelReservationResponse
+
+This contains the field definition of the CancelReservationResponse PDU sent by the Charging Station to the CSMS in response to a CancelReservationRequest.
+
+Class
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>CancelReservationStatusEnumTyp e</td><td>1..1</td><td>Required. This indicates the success or failure of the canceling of a reservation by CSMS.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.7. CertificateSigned
+
+# 1.7.1. CertificateSignedRequest
+
+This contains the field definition of the CertificateSignedRequest PDU sent by the CSMS to the Charging Station.
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateChain</td><td>string[0..10000]</td><td>1..1</td><td>Required. The signed PEM encoded X.509 certificate. This SHALL also contain the necessary sub CA certificates, when applicable. The order of the bundle follows the certificate chain, starting from the leaf certificate.The Configuration Variable MaxCertificateChainSize can be used to limit the maximum size of this field.</td></tr><tr><td>certificateType</td><td>CertificateSigningUseEnumType</td><td>0..1</td><td>Optional. Indicates the type of the signed certificate that is returned. When omitted the certificate is used for both the 15118 connection (if implemented) and the Charging Station to CSMS connection. This field is required when a typeOfCertificate was included in the SignCertificateRequest that requested this certificate to be signed AND both the 15118 connection and the Charging Station connection are implemented.</td></tr><tr><td>requestId</td><td>integer</td><td>0..1</td><td>Optional. (2.1) RequestId to correlate this message with the SignCertificateRequest.</td></tr></table>
+
+# 1.7.2. CertificateSignedResponse
+
+This contains the field definition of the CertificateSignedResponse PDU sent by the Charging Station to the CSMS in response to a CertificateSignedRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>CertificateSignedStatusEnumType</td><td>1..1</td><td>Required. Returns whether certificate signing has been accepted, otherwise rejected.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.8. ChangeAvailability
+
+# 1.8.1. ChangeAvailabilityRequest
+
+This contains the field definition of the ChangeAvailabilityRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>operationalStatus</td><td>OperationalStatusEnumType</td><td>1..1</td><td>Required. This contains the type of availability change that the Charging Station should perform.</td></tr><tr><td>evse</td><td>EVSEType</td><td>0..1</td><td>Optional. Contains Id's to designate a specific EVSE/connector by index numbers. When omitted, the message refers to the Charging Station as a whole.</td></tr></table>
+
+# 1.8.2. ChangeAvailabilityResponse
+
+This contains the field definition of the ChangeAvailabilityResponse PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ChangeAvailabilityStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station is able to perform the availability change.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.9. ChangeTransactionTariff
+
+# 1.9.1. ChangeTransactionTariffRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. Transaction id for new tariff.</td></tr><tr><td>tariff</td><td>TariffType</td><td>1..1</td><td>Required. New tariff to use for transaction.</td></tr></table>
+
+# 1.9.2. ChangeTransactionTariffResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>TariffChangeStatusEnumType</td><td>1..1</td><td>Required. Status of the operation</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information</td></tr></table>
+
+# 1.10. ClearCache
+
+# 1.10.1. ClearCacheRequest
+
+This contains the field definition of the ClearCacheRequest PDU sent by the CSMS to the Charging Station. No fields are defined.
+
+# 1.10.2. ClearCacheResponse
+
+This contains the field definition of the ClearCacheResponse PDU sent by the Charging Station to the CSMS in response to a ClearCacheRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ClearCacheStatusEnumType</td><td>1..1</td><td>Required. Accepted if the Charging Station has executed the request, otherwise rejected.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.11. ClearChargingProfile
+
+# 1.11.1. ClearChargingProfileRequest
+
+This contains the field definition of the ClearChargingProfileRequest PDU sent by the CSMS to the Charging Station. The CSMS can use this message to clear (remove) either a specific charging profile (denoted by id) or a selection of charging profiles that match with the values of the optional evse, stackLevel and ChargingProfilePurpose fields.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>chargingProfileId</td><td>integer</td><td>0..1</td><td>Optional. The Id of the charging profile to clear.</td></tr><tr><td>chargingProfileCriteria</td><td>ClearChargingProfileType</td><td>0..1</td><td>Optional. Specifies the charging profile.</td></tr></table>
+
+# 1.11.2. ClearChargingProfileResponse
+
+This contains the field definition of the ClearChargingProfileResponse PDU sent by the Charging Station to the CSMS in response to a ClearChargingProfileRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ClearChargingProfileStatusEnumType</td><td>1..1</td><td>Required. Indicates if the Charging Station was able to execute the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.12. ClearDERControl
+
+# 1.12.1. ClearDERControlRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>isEmpty</td><td>boolean</td><td>1..1</td><td>Required. True: clearing default DER controls. False: clearing scheduled controls.</td></tr><tr><td>controlType</td><td>DERControlEnumType</td><td>0..1</td><td>Optional. Name of control settings to clear. Not used when controlled is provided.</td></tr><tr><td>controlled</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. Id of control setting to clear. When omitted all settings for(controlType are cleared.</td></tr></table>
+
+# 1.12.2. ClearDERControlResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>DERControlStatusEnumType</td><td>1..1</td><td>Required. Result of operation.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information</td></tr></table>
+
+# 1.13. ClearDisplayMessage
+
+# 1.13.1. ClearDisplayMessageRequest
+
+This contains the field definition of the ClearDisplayMessageRequest PDU sent by the CSMS to the Charging Station. The CSMS asks the Charging Station to clear a display message that has been configured in the Charging Station to be cleared/removed. See also 005 - Clear a Display Message.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. Id of the message that SHALL be removed from the Charging Station.</td></tr></table>
+
+# 1.13.2. ClearDisplayMessageResponse
+
+This contains the field definition of the ClearDisplayMessageResponse PDU sent by the Charging Station to the CSMS in a response to a ClearDisplayMessageRequest. See also O05 - Clear a Display Message.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ClearMessageStatusEnumType</td><td>1..1</td><td>Required. Returns whether the Charging Station has been able to remove the message.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.14. ClearedChargingLimit
+
+# 1.14.1. ClearedChargingLimitRequest
+
+This contains the field definition of the ClearedChargingLimitRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>chargingLimitSource</td><td>string[0..20]</td><td>1..1</td><td>Required. Source of the charging limit. Allowed values defined in Appendix as ChargingLimitSourceEnum不同类型.</td></tr><tr><td>evseld</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. EVSE Identifier.</td></tr></table>
+
+# 1.14.2. ClearedChargingLimitResponse
+
+This contains the field definition of the ClearedChargingLimitResponse PDU sent by the CSMS to the Charging Station. No fields are defined.
+
+# 1.15. ClearTariffs
+
+# 1.15.1. ClearTariffsRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>tarifflds</td><td>string[0..60]</td><td>0..*</td><td>Optional. List of tarifflds to clear. When absent clears all tariffs at evseld.</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>0..1</td><td>Optional. When present only clear tariffs matching tarifflds at EVSE evseld.</td></tr></table>
+
+# 1.15.2. ClearTariffsResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>clearTariffsResult</td><td>ClearTariffs ResultType</td><td>1..*</td><td>Required. Result per tariff.</td></tr></table>
+
+# 1.16. ClearVariableMonitoring
+
+# 1.16.1. ClearVariableMonitoringRequest
+
+This contains the field definition of the ClearVariableMonitoringRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 ⇔ val</td><td>1..*</td><td>Required. List of the monitors to be cleared, identified by there Id.</td></tr></table>
+
+# 1.16.2. ClearVariableMonitoringResponse
+
+This contains the field definition of the ClearVariableMonitoringResponse PDU sent by the Charging Station to the CSMS.
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>clearMonitoringResult</td><td>ClearMonitoringResultType</td><td>1..*</td><td>Required. List of status per monitor.</td></tr></table>
+
+# 1.17. ClosePeriodicEventStream
+
+# 1.17.1. ClosePeriodicEventStreamRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. Id of stream to close.</td></tr></table>
+
+# 1.17.2. ClosePeriodicEventStreamResponse
+
+# 1.18. CostUpdated
+
+# 1.18.1. CostUpdatedRequest
+
+This contains the field definition of the CostUpdatedRequest PDU sent by the CSMS to the Charging Station. With this request the CSMS can send the current cost of a transaction to a Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>totalCost</td><td>decimal</td><td>1..1</td><td>Required. Current total cost, based on the information known by the CSMS, of the transaction including taxes. In the currency configured with the configuration Variable: [Currency]</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. Transaction Id of the transaction the current cost are asked for.</td></tr></table>
+
+# 1.18.2. CostUpdatedResponse
+
+This contains the field definition of the CostUpdatedResponse PDU sent by the Charging Station to the CSMS in response to CostUpdatedRequest. No fields are defined.
+
+# 1.19. CustomerInformation
+
+This contains the field definition of the CustomerInformationRequest PDU sent by the CSMS to the Charging Station.
+
+# 1.19.1. CustomerInformationRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. The Id of the request.</td></tr><tr><td>report</td><td>boolean</td><td>1..1</td><td>Required. Flag indicating whether the Charging Station should return NotifyCustomerInformationRequest messages containing information about the customer referred to.</td></tr><tr><td>clear</td><td>boolean</td><td>1..1</td><td>Required. Flag indicating whether the Charging Station should clear all information about the customer referred to.</td></tr><tr><td>customerIdentifier</td><td>string[0..64]</td><td>0..1</td><td>Optional. A (e.g. vendor specific) identifier of the customer this request refers to. This field contains a custom identifier other than IdToken and Certificate. One of the possible identifiers (customerIdentifier, customerIdToken or customerCertificate) should be in the request message.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>0..1</td><td>Optional. The IdToken of the customer this request refers to. One of the possible identifiers (customerIdentifier, customerIdToken or customerCertificate) should be in the request message.</td></tr><tr><td>customerCertificate</td><td>CertificateDataType</td><td>0..1</td><td>Optional. The Certificate of the customer this request refers to. One of the possible identifiers (customerIdentifier, customerIdToken or customerCertificate) should be in the request message.</td></tr></table>
+
+# 1.19.2. CustomerInformationResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>CustomerInformationStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the request was accepted.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.20. DataTransfer
+
+# 1.20.1. DataTransferRequest
+
+This contains the field definition of the DataTransferRequest PDU sent either by the CSMS to the Charging Station or vice versa.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>messageId</td><td>string[0..50]</td><td>0..1</td><td>Optional. May be used to indicate a specific message or implementation.</td></tr><tr><td>data</td><td>anyType</td><td>0..1</td><td>Optional. Data without specified length or format. This needs to be decided by both parties (Open to implementation).</td></tr><tr><td>vendorId</td><td>string[0..255]</td><td>1..1</td><td>Required. This identifies the Vendor specific implementation</td></tr></table>
+
+# 1.20.2. DataTransferResponse
+
+This contains the field definition of the DataTransferResponse PDU sent by the Charging Station to the CSMS or vice versa in response to a DataTransferRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>DataTransferStatusEnumType</td><td>1..1</td><td>Required. This indicates the success or failure of the data transfer.</td></tr><tr><td>data</td><td>anyType</td><td>0..1</td><td>Optional. Data without specified length or format, in response to request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.21. DeleteCertificate
+
+# 1.21.1. DeleteCertificateRequest
+
+Used by the CSMS to request deletion of an installed certificate on a Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateHashData</td><td>CertificateHashDataType</td><td>1..1</td><td>Required. Indicates the certificate of which deletion is requested.</td></tr></table>
+
+# 1.21.2. DeleteCertificateResponse
+
+Response to a DeleteCertificateRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>DeleteCertificateStatusEnumType</td><td>1..1</td><td>Required. Charging Station indicates if it can process the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.22. FirmwareStatusNotification
+
+# 1.22.1. FirmwareStatusNotificationRequest
+
+This contains the field definition of the FirmwareStatusNotificationRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>FirmwareStatusEnumType</td><td>1..1</td><td>Required. This contains the progress status of the firmware installation.</td></tr><tr><td>requestId</td><td>integer</td><td>0..1</td><td>Optional. The request id that was provided in the UpdateFirmwareRequest that started this firmware update. This field is mandatory, unless the message was triggered by a TriggerMessageRequest AND there is no firmware update ongoing.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. (2.1) Detailed status info</td></tr></table>
+
+# 1.22.2. FirmwareStatusNotificationResponse
+
+This contains the field definition of the FirmwareStatusNotificationResponse PDU sent by the CSMS to the Charging Station in response to a FirmwareStatusNotificationRequest. No fields are defined.
+
+# 1.23. Get15118EVCertificate
+
+# 1.23.1. Get15118EVCertificateRequest
+
+This message is sent by the Charging Station to the CSMS if an ISO 15118 vehicle selects the service Certificate installation. NOTE: This message is based on CertificateInstallationReq Res from ISO 15118 2.
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>iso15118SchemaVersion</td><td>string[0..50]</td><td>1..1</td><td>Required. Schema version currently used for the 15118 session between EV and Charging Station. Needed for parsing of the EXI stream by the CSMS.</td></tr><tr><td>action</td><td>CertificateActionEnumType</td><td>1..1</td><td>Required. Defines whether certificate needs to be installed or updated.</td></tr><tr><td>exiRequest</td><td>string[0..11000]</td><td>1..1</td><td>Required. (2.1) Raw CertificateInstallationReq request from EV, Base64 encoded.
+Extended to support ISO 15118-20 certificates. The minimum supported length is 11000. If a longer exiRequest is supported, then the supported length must be communicated in variable OCPPCommCtrl.FieldLength["Get15118EVCertificateRequest.exiRequest"].</td></tr><tr><td>maximumContractCertificatesChains</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. (2.1) Absent during ISO 15118-2 session.
+Required during ISO 15118-20 session.
+Maximum number of contracts that EV wants to install.</td></tr><tr><td>prioritizedEMAIDs</td><td>identifierString[0..255]</td><td>0..8</td><td>Optional. (2.1) Absent during ISO 15118-2 session.
+Optional during ISO 15118-20 session. List of EMAIDs for which contract certificates must be requested first, in case there are more certificates than allowed by maximumContractCertificateChains.</td></tr></table>
+
+# 1.23.2. Get15118EVCertificateResponse
+
+Response message from CSMS to Charging Station containing the status and optionally new certificate. NOTE: This message is based on CertificateInstallationReq Res from ISO 15118-2.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>Iso15118EVCertificateStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the message was processed properly.</td></tr><tr><td>exiResponse</td><td>string[0..17000]</td><td>1..1</td><td>Required. (2/1) Raw CertificateInstallationRes response for the EV, Base64 encoded.
+Extended to support ISO 15118-20 certificates. The minimum supported length is 17000. If a longer exiResponse is supported, then the supported length must be communicated in variable OCPPCommCtrl.FieldLength["Get15118EVCertificateResponse.exiResponse"].</td></tr><tr><td>remainingContracts</td><td>integer, 0 ⇌ val</td><td>0..1</td><td>Optional. (2.1) Number of contracts that can be retrieved with additional requests.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.24. GetBaseReport
+
+# 1.24.1. GetBaseReportRequest
+
+This contains the field definition of the GetBaseReportRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of the request.</td></tr><tr><td>reportBase</td><td>ReportBaseEnumType</td><td>1..1</td><td>Required. This field specifies the report base.</td></tr></table>
+
+# 1.24.2. GetBaseReportResponse
+
+This contains the field definition of the GetBaseReportResponse PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericDeviceModelStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station is able to accept this request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.25. GetCertificateChainStatus
+
+# 1.25.1. GetCertificateChainStatusRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateStatusRequests</td><td>CertificateStatusRequestInfoType</td><td>1..4</td><td>Required. Certificate to check revocation status for.</td></tr></table>
+
+# 1.25.2. GetCertificateChainStatusResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateStatus</td><td>Certificate statusesType</td><td>1..4</td><td>Required. Status of the certificate revocation check.</td></tr></table>
+
+# 1.26. GetCertificateStatus
+
+# 1.26.1. GetCertificateStatusRequest
+
+This contains the field definition of the GetCertificateStatusRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>ocspRequestData</td><td>OCSPRequestDataType</td><td>1..1</td><td>Required. Indicates the certificate of which the status is requested.</td></tr></table>
+
+# 1.26.2. GetCertificateStatusResponse
+
+This contains the field definition of the GetCertificateStatusResponse PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GetCertificateStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the charging station was able to retrieve the OCSP certificate status.</td></tr><tr><td>ocspResult</td><td>string[0..18000]</td><td>0..1</td><td>Optional. (2.1) OCSPResponse class as defined in IETF RFC 6960. DER encoded (as defined in IETF RFC 6960), and then base64 encoded. MAY only be omitted when status is not Accepted.
+The minimum supported length is 18000. If a longer ocspResult is supported, then the supported length must be communicated in variable OCPPCommCtrlr.FieldLength["GetCertificateStatusResponse.ocspResult"].</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.27. GetChargingProfiles
+
+# 1.27.1. GetChargingProfilesRequest
+
+The message GetChargingProfilesRequest can be used by the CSMS to request installed charging profiles from the Charging Station. The charging profiles will then be reported by the Charging Station via ReportChargingProfilesRequest messages.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. Reference identification that is to be used by the Charging Station in the ReportChargingProfilesRequest when provided.</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>0..1</td><td>Optional. For which EVSE installed charging profiles SHALL be reported. If 0, only charging profiles installed on the Charging Station itself (the grid connection) SHALL be reported. If omitted, all installed charging profiles SHALL be reported.
+Reported charging profiles SHALL match the criteria in field chargingProfile.</td></tr><tr><td>chargingProfile</td><td>ChargingProfileCriterionType</td><td>1..1</td><td>Required. Specifies the charging profile.</td></tr></table>
+
+# 1.27.2. GetChargingProfilesResponse
+
+This contains the field definition of the GetChargingProfilesResponse PDU sent by the Charging Station to the CSMS in response to a GetChargingProfilesRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GetChargingProfileStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station is able to process this request and will send ReportChargingProfilesRequest messages.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.28. GetCompositeSchedule
+
+# 1.28.1. GetCompositeScheduleRequest
+
+This contains the field definition of the GetCompositeScheduleRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>duration</td><td>integer</td><td>1..1</td><td>Required. Length of the requested schedule in seconds.</td></tr><tr><td>chargingRateUnit</td><td>ChargingRateUnitEnumType</td><td>0..1</td><td>Optional. Can be used to force a power or current profile.</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. The ID of the EVSE for which the schedule is requested. When evseid=0, the Charging Station will calculate the expected consumption for the grid connection.</td></tr></table>
+
+# 1.28.2. GetCompositeScheduleResponse
+
+This contains the field definition of the GetCompositeScheduleResponse PDU sent by the Charging Station to the CSMS in response to a GetCompositeScheduleRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. The Charging Station will indicate if it was able to process the request</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr><tr><td>schedule</td><td>CompositeScheduleType</td><td>0..1</td><td>Optional. This field contains the calculated composite schedule. It may only be omitted when this message contains status Rejected.</td></tr></table>
+
+# 1.29. GetDERControl
+
+# 1.29.1. GetDERControlRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. RequestId to be used in ReportDERControlRequest.</td></tr><tr><td>isEmpty</td><td>boolean</td><td>0..1</td><td>Optional. True: get a default DER control. False: get a scheduled control.</td></tr><tr><td>controlType</td><td>DERControlEnumType</td><td>0..1</td><td>Optional. Type of control settings to retrieve. Not used when controlled is provided.</td></tr><tr><td>controlled</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. Id of setting to get. When omitted all settings for(controlType are retrieved.</td></tr></table>
+
+# 1.29.2. GetDERControlResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>DERControlStatusEnumType</td><td>1..1</td><td>Required. Result of operation.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status info.</td></tr></table>
+
+# 1.30. GetDisplayMessages
+
+# 1.30.1. GetDisplayMessagesRequest
+
+Class
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 <= val</td><td>0..*</td><td>Optional. If provided the Charging Station shall return Display Messages of the given ids. This field SHALL NOT contain more ids than set in NumberOfDisplayMessages.maxLimit</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of this request.</td></tr><tr><td>priority</td><td>MessagePriorityEnumType</td><td>0..1</td><td>Optional. If provided the Charging Station shall return Display Messages with the given priority only.</td></tr><tr><td>state</td><td>MessageStateEnumType</td><td>0..1</td><td>Optional. If provided the Charging Station shall return Display Messages with the given state only.</td></tr></table>
+
+# 1.30.2. GetDisplayMessagesResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GetDisplayMessagesStatusEnumType</td><td>1..1</td><td>Required. Indicates if the Charging Station has Display Messages that match the request criteria in the GetDisplayMessagesRequest</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.31. GetInstalledCertificates
+
+# 1.31.1. GetInstalledCertificatesRequest
+
+Used by the CSMS to request an overview of the installed certificates on a Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateType</td><td>GetCertificateIdUseEnumType</td><td>0..*</td><td>Optional. Indicates the type of certificates requested.
+When omitted, all certificate types are requested.</td></tr></table>
+
+# 1.31.2. GetInstalledCertificatesResponse
+
+Response to a GetInstalledCertificatesRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GetInstalledCertificateStatusEnum Type</td><td>1..1</td><td>Required. Charging Station indicates if it can process the request.</td></tr><tr><td>certificateDataChain</td><td>CertificateDataChainType</td><td>0..*</td><td>Optional. The Charging Station includes the Certificate information for each available certificate.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.32. GetLocalListVersion
+
+# 1.32.1. GetLocalListVersionRequest
+
+This contains the field definition of the GetLocalListVersionRequest PDU sent by the CSMS to the Charging Station. No fields are defined.
+
+# 1.32.2. GetLocalListVersionResponse
+
+This contains the field definition of the GetLocalListVersionResponse PDU sent by the Charging Station to CSMS in response to a GetLocalListVersionRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>versionNumber</td><td>integer</td><td>1..1</td><td>Required. This contains the current version number of the local authorization list in the Charging Station.</td></tr></table>
+
+# 1.33. GetLog
+
+# 1.33.1. GetLogRequest
+
+This contains the field definition of the GetLogRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>logType</td><td>LogEnumType</td><td>1..1</td><td>Required. This contains the type of log file that the Charging Station should send.</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of this request</td></tr><tr><td>retries</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. This specifies how many times the Charging Station must retry to upload the log before giving up. If this field is not present, it is left to Charging Station to decide how many times it wants to retry. If the value is 0, it means: no retries.</td></tr><tr><td>retryInterval</td><td>integer</td><td>0..1</td><td>Optional. The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charging Station to decide how long to wait between attempts.</td></tr><tr><td>log</td><td>LogParametersType</td><td>1..1</td><td>Required. This field specifies the requested log and the location to which the log should be sent.</td></tr></table>
+
+# 1.33.2. GetLogResponse
+
+This contains the field definition of the GetLogResponse PDU sent by the Charging Station to the CSMS in response to a GetLogRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>LogStatusEnumType</td><td>1..1</td><td>Required. This field indicates whether the Charging Station was able to accept the request.</td></tr><tr><td>filename</td><td>string[0..255]</td><td>0..1</td><td>Optional. This contains the name of the log file that will be uploaded. This field is not present when no logging information is available.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.34. GetMonitoringReport
+
+# 1.34.1. GetMonitoringReportRequest
+
+This contains the field definition of the GetMonitoringReportRequest PDU sent by the CSMS to the Charging Station
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of the request.</td></tr><tr><td>monitoringCriteria</td><td>MonitoringCriterionEnumType</td><td>0..3</td><td>Optional. This field contains criteria for components for which a monitoring report is requested</td></tr><tr><td>componentVariable</td><td>ComponentVariableType</td><td>0..*</td><td>Optional. This field specifies the components and variables for which a monitoring report is requested.</td></tr></table>
+
+# 1.34.2. GetMonitoringReportResponse
+
+This contains the field definition of the GetMonitoringReportResponse PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericDeviceModelStatusEnumType</td><td>1..1</td><td>Required. This field indicates whether the Charging Station was able to accept the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.35. GetPeriodicEventStream
+
+# 1.35.1. GetPeriodicEventStreamRequest
+
+# 1.35.2. GetPeriodicEventStreamResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>constantStreamData</td><td>ConstantStreamDataType</td><td>0..*</td><td>Optional. List of constant part of streams</td></tr></table>
+
+# 1.36. GetReport
+
+# 1.36.1. GetReportRequest
+
+This contains the field definition of the GetReportRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of the request.</td></tr><tr><td>componentCriteria</td><td>ComponentCriterionEnumType</td><td>0..4</td><td>Optional. This field contains criteria for components for which a report is requested</td></tr><tr><td>componentVariable</td><td>ComponentVariableType</td><td>0..*</td><td>Optional. This field specifies the components and variables for which a report is requested.</td></tr></table>
+
+# 1.36.2. GetReportResponse
+
+The response to a GetReportRequest, sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericDeviceModelStatusEnumType</td><td>1..1</td><td>Required. This field indicates whether the Charging Station was able to accept the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.37. GetTariffs
+
+# 1.37.1. GetTariffsRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. EVSE id to get tariff from. When evseld = 0, this gets tariffs from all EVSEs.</td></tr></table>
+
+# 1.37.2. GetTariffsResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>TariffGetStatusEnumType</td><td>1..1</td><td>Required. Status of operation</td></tr><tr><td>tariffAssignments</td><td>TariffAssignmentType</td><td>0..*</td><td>Optional. Installed default and user-specific tariffs per EVSE</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Details status information</td></tr></table>
+
+# 1.38. GetTransactionStatus
+
+# 1.38.1. GetTransactionStatusRequest
+
+With this message, the CSMS can ask the Charging Station whether it has transaction-related messages waiting to be delivered to the CSMS. When a transactionId is provided, only messages for a specific transaction are asked for.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. The Id of the transaction for which the status is requested.</td></tr></table>
+
+# 1.38.2. GetTransactionStatusResponse
+
+The response to a GetTransactionStatusRequest, sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>ongoingIndicator</td><td>boolean</td><td>0..1</td><td>Optional. Whether the transaction is still ongoing.</td></tr><tr><td>messagesInQueue</td><td>boolean</td><td>1..1</td><td>Required. Whether there are still message to be delivered.</td></tr></table>
+
+# 1.39. GetVariables
+
+# 1.39.1. GetVariablesRequest
+
+This contains the field definition of the GetVariablesRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>getVariableData</td><td>GetVariableDataType</td><td>1..*</td><td>Required. List of requested variables.</td></tr></table>
+
+# 1.39.2. GetVariablesResponse
+
+This contains the field definition of the GetVariablesResponse PDU sent by the CSMS to the Charging Station in response to GetVariablesRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>getVariableResult</td><td>GetVariableResultType</td><td>1..*</td><td>Required. List of requested variables and their values.</td></tr></table>
+
+# 1.40. Heartbeat
+
+# 1.40.1. HeartbeatRequest
+
+This contains the field definition of the HeartbeatRequest PDU sent by the Charging Station to the CSMS. No fields are defined.
+
+# 1.40.2. HeartbeatResponse
+
+This contains the field definition of the HeartbeatResponse PDU sent by the CSMS to the Charging Station in response to a HeartbeatRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>currentTime</td><td>dateTime</td><td>1..1</td><td>Required. Contains the current time of the CSMS.</td></tr></table>
+
+# 1.41.InstallCertificate
+
+# 1.41.1. InstallCertificateRequest
+
+Used by the CSMS to request installation of a certificate on a Charging Station.
+
+Note: This message is not for installing a TLS client certificate in a charging station. The CertificateSignedRequest mechanism is used for that.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateType</td><td>InstallCertificateUseEnumType</td><td>1..1</td><td>Required. Indicates the certificate type that is sent.</td></tr><tr><td>certificate</td><td>string[0..10000]</td><td>1..1</td><td>Required. A PEM encoded X.509 certificate.</td></tr></table>
+
+# 1.41.2. InstallCertificateResponse
+
+The response to a InstallCertificateRequest, sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>InstallCertificateStatusEnumType</td><td>1..1</td><td>Required. Charging Station indicates if installation was successful.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.42. LogStatusNotification
+
+# 1.42.1. LogStatusNotificationRequest
+
+This contains the field definition of the LogStatusNotificationRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>UploadLogStatusEnumType</td><td>1..1</td><td>Required. This contains the status of the log upload.</td></tr><tr><td>requestId</td><td>integer</td><td>0..1</td><td>Optional. The request id that was provided in GetLogRequest that started this log upload. This field is mandatory, unless the message was triggered by a TriggerMessageRequest AND there is no log upload ongoing.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. (2.1) Detailed status info</td></tr></table>
+
+# 1.42.2. LogStatusNotificationResponse
+
+This contains the field definition of the LogStatusNotificationResponse PDU sent by the CSMS to the Charging Station in response to LogStatusNotificationRequest. No fields are defined.
+
+# 1.43. MeterValues
+
+# 1.43.1. MeterValuesRequest
+
+This contains the field definition of the MeterValuesRequest PDU sent by the Charging Station to the CSMS. This message might be removed in a future version of OCPP. It will be replaced by Device Management Monitoring events.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. This contains a number (>0) designating an EVSE of the Charging Station. '0' (zero) is used to designate the main power meter.</td></tr><tr><td>meterValue</td><td>MeterValueType</td><td>1..*</td><td>Required. The sampled meter values with timestamps. The following Configuration Variables are used to configure which measurands are sent: -AlignedDataMeasurands -AlignedDataUpstreamMeasurands</td></tr></table>
+
+# 1.43.2. MeterValuesResponse
+
+This contains the field definition of the MeterValuesResponse PDU sent by the CSMS to the Charging Station in response to a MeterValuesRequest PDU. This message might be removed in a future version of OCPP. It will be replaced by Device Management Monitoring events.
+
+No fields are defined.
+
+# 1.44. NotifyAllowedEnergyTransfer
+
+# 1.44.1. NotifyAllowedEnergyTransferRequest
+
+(2.1) Message sent by CSMS to update the list of authorized energy services, e.g. to allow bidirectional charging for a charging session that is already in progress. One example is that the EV has already started a transaction in charging-only mode and meanwhile the CSMS has found that this EV is authorized by some secondary actor, such as an aggregating party, to use bidirectional charging. This message is then used to give the EV the opportunity to change energy service from charging-only to bidirectional charging.
+
+Another example is that the CSMS wishes to change the active energy service. This is done by updating the list of authorized energy services and omitting the currently active energy service.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. The transaction for which the allowed energy transfer is allowed.</td></tr><tr><td>allowedEnergyTransfer</td><td>EnergyTransferModeEnumType</td><td>1..*</td><td>Required. Modes of energy transfer that are accepted by CSMS.</td></tr></table>
+
+# 1.44.2. NotifyAllowedEnergyTransferResponse
+
+(2.1) Status of NotifyAllowedEnergyServicesRequest. Request should normally not be rejected, unless there are some technical problems.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>NotifyAllowedEnergyTransferStatusEnumType</td><td>1..1</td><td>Required.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional.</td></tr></table>
+
+# 1.45. NotifyChargingLimit
+
+# 1.45.1. NotifyChargingLimitRequest
+
+The message NotifyChargingLimitRequest can be used to communicate a charging limit, set by an external system on the Charging Station (Not installed by the CSO via SetChargingProfileRequest), to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>0..1</td><td>Optional. The EVSE to which the charging limit is set. If absent or when zero, it applies to the entire Charging Station.</td></tr><tr><td>chargingLimit</td><td>ChargingLimitType</td><td>1..1</td><td>Required. This contains the source of the charging limit and whether it is grid critical.</td></tr><tr><td>chargingSchedule</td><td>ChargingScheduleType</td><td>0..*</td><td>Optional. Contains limits for the available power or current over time, as set by the external source.</td></tr></table>
+
+# 1.45.2. NotifyChargingLimitResponse
+
+The NotifyChargingLimitResponse message is sent by the CSMS to the Charging Station in response to a NotifyChargingLimitsRequest. No fields are defined.
+
+# 1.46. NotifyCustomerInformation
+
+This contains the field definition of the NotifyCustomerInformationRequest PDU sent by the Charging Station to the CSMS.
+
+# 1.46.1. NotifyCustomerInformationRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>data</td><td>string[0..512]</td><td>1..1</td><td>Required. (Part of) the requested data. No format specified in which the data is returned. Should be human readable.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. “to be continued” indicator. Indicates whether another part of the monitoringData follows in an upcoming notifyMonitoringReportRequest message. Default value when omitted is false.</td></tr><tr><td>seqNo</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. Sequence number of this message. First message starts at 0.</td></tr><tr><td>generatedAt</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp of the moment this message was generated at the Charging Station.</td></tr><tr><td>requestId</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. The Id of the request.</td></tr></table>
+
+# 1.46.2. NotifyCustomerInformationResponse
+
+# 1.47. NotifyDERAlarm
+
+# 1.47.1. NotifyDERAlarmRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>controlType</td><td>DERControlEnumType</td><td>1..1</td><td>Required. Name of DER control, e.g. LFMustTrip</td></tr><tr><td>gridEventFault</td><td>GridEventFaultEnumType</td><td>0..1</td><td>Optional. Type of grid event that caused this</td></tr><tr><td>alarmEnded</td><td>boolean</td><td>0..1</td><td>Optional. True when error condition has ended. Absent or false when alarm has started.</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. Time of start or end of alarm.</td></tr><tr><td>extralinfo</td><td>string[0..200]</td><td>0..1</td><td>Optional. Optional info provided by EV.</td></tr></table>
+
+# 1.47.2. NotifyDERAlarmResponse
+
+This message has no fields.
+
+# 1.48. NotifyDERStartStop
+
+# 1.48.1. NotifyDERStartStopRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>controlled</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. Id of the started or stopped DER control.
+Corresponds to the controlled of the SetDERControlRequest.</td></tr><tr><td>started</td><td>boolean</td><td>1..1</td><td>Required. True if DER control has started. False if it has ended.</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. Time of start or end of event.</td></tr><tr><td>supersededIds</td><td>identifierString[0..36]</td><td>0..24</td><td>Optional. List of controlleds that are superseded as a result of this control starting.</td></tr></table>
+
+# 1.48.2. NotifyDERStartStopResponse
+
+This message has no fields.
+
+# 1.49. NotifyDisplayMessages
+
+# 1.49.1. NotifyDisplayMessagesRequest
+
+This contains the field definition of the NotifyDisplayMessagesRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The id of the GetDisplayMessagesRequest that requested this message.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. "to be continued" indicator. Indicates whether another part of the report follows in an upcoming NotifyDisplayMessagesRequest message. Default value when omitted is false.</td></tr><tr><td>messageInfo</td><td>MessageInfoType</td><td>0..*</td><td>Optional. The requested display message as configured in the Charging Station.</td></tr></table>
+
+# 1.49.2. NotifyDisplayMessagesResponse
+
+The NotifyDisplayMessagesResponse message is sent by the CSMS to the Charging Station in response to a NotifyDisplayMessagesRequest. No fields are defined.
+
+# 1.50. NotifyEVChargingNeeds
+
+# 1.50.1. NotifyEVChargingNeedsRequest
+
+The Charging Station uses this message to communicate the charging needs as calculated by the EV to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer, 1 ⇔ val</td><td>1..1</td><td>Required. Defines the EVSE and connector to which the EV is connected. Evseld may not be 0.</td></tr><tr><td>maxScheduleTuples</td><td>integer, 0 ⇔ val</td><td>0..1</td><td>Optional. Contains the maximum elements the EV supports for:
+- ISO 15118-2: schedule tuples in SASchedule (both Pmax and Tariff).
+- ISO 15118-20: PowerScheduleEntry, PriceRule and PriceLevelScheduleEntries.</td></tr><tr><td>timestamp</td><td>dateTime</td><td>0..1</td><td>Optional. (2.1) Time when EV charging needs were received.
+Field can be added when charging station was offline when charging needs were received.</td></tr><tr><td>chargingNeeds</td><td>ChargingNeedsType</td><td>1..1</td><td>Required. The characteristics of the energy delivery required.</td></tr></table>
+
+# 1.50.2. NotifyEVChargingNeedsResponse
+
+Response to a NotifyEVChargingNeedsRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>NotifyEVChargingNeedsStatusEnu mType</td><td>1..1</td><td>Required. Returns whether the CSMS has been able to process the message successfully. It does not imply that the evChargingNeeds can be met with the current charging profile.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional.</td></tr></table>
+
+# 1.51. NotifyEVChargingSchedule
+
+# 1.51.1. NotifyEVChargingScheduleRequest
+
+The Charging Station uses this message to communicate the charging schedule as calculated by the EV to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>timeBase</td><td>dateTime</td><td>1..1</td><td>Required. Periods contained in the charging profile are relative to this point in time.</td></tr><tr><td>evseld</td><td>integer, 1 ⇌ val</td><td>1..1</td><td>Required. The charging schedule contained in this notification applies to an EVSE. Evseld must be > 0.</td></tr><tr><td>selectedChargingScheduleId</td><td>integer, 0 ⇌ val</td><td>0..1</td><td>Optional. (2.1) Id of the chargingSchedule that EV selected from the provided ChargingProfile.</td></tr><tr><td>powerToleranceAcceptance</td><td>boolean</td><td>0..1</td><td>Optional. (2.1) True when power tolerance is accepted by EV. This value is taken from EVPowerProfile.PowerToleranceAcceptance in the ISO 15118-20 PowerDeliverReq message..</td></tr><tr><td>chargingSchedule</td><td>ChargingScheduleType</td><td>1..1</td><td>Required. Planned energy consumption of the EV over time. Always relative to timeBase.</td></tr></table>
+
+# 1.51.2. NotifyEVChargingScheduleResponse
+
+Response to a NotifyEVChargingScheduleRequest message.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Returns whether the CSMS has been able to process the message successfully. It does not imply any approval of the charging schedule.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.52. Notify
+
+# 1.52.1. NotifyRequest
+
+This contains the field definition of the NotifyEventRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>generatedAt</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp of the moment this message was generated at the Charging Station.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. “to be continued” indicator. Indicates whether another part of the report follows in an upcoming notifyEventRequest message. Default value when omitted is false.</td></tr><tr><td>seqNo</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. Sequence number of this message. First message starts at 0.</td></tr><tr><td>eventData</td><td>-eventDataType</td><td>1..*</td><td>Required. List of EventData. An EventData element contains only the Component, Variable and VariableMonitoring data that caused the event. The list of EventData will usually contain one eventData element, but the Charging Station may decide to group multiple events in one notification. For example, when multiple events triggered at the same time.</td></tr></table>
+
+# 1.52.2. NotifyResponse
+
+Response to NotifyRequest. No fields are defined.
+
+# 1.53. NotifyMonitoringReport
+
+# 1.53.1. NotifyMonitoringReportRequest
+
+This contains the field definition of the NotifyMonitoringRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The id of the GetMonitoringRequest that requested this report.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. “to be continued” indicator. Indicates whether another part of the monitoringData follows in an upcoming notifyMonitoringReportRequest message. Default value when omitted is false.</td></tr><tr><td>seqNo</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. Sequence number of this message. First message starts at 0.</td></tr><tr><td>generatedAt</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp of the moment this message was generated at the Charging Station.</td></tr><tr><td>monitor</td><td>MonitoringDataType</td><td>0..*</td><td>Optional. List of MonitoringData containing monitoring settings.</td></tr></table>
+
+# 1.53.2. NotifyMonitoringReportResponse
+
+Response to a NotifyMonitoringRequest message. No fields are defined.
+
+# 1.54. NotifyPeriodicEventStream
+
+This is a message of messageType SEND. It does not have a response.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. Id of stream.</td></tr><tr><td>pending</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. Number of data elements still pending to be sent.</td></tr><tr><td>baseline</td><td>dateTime</td><td>1..1</td><td>Required. Base timestamp to add to time offset of values.</td></tr><tr><td>data</td><td>StreamDataElementType</td><td>1..*</td><td>Required. Variable part of stream data</td></tr></table>
+
+# 1.55. NotifyPriorityCharging
+
+# 1.55.1. NotifyPriorityChargingRequest
+
+(2.1) Message sent by Charging Station to notify CSMS that it has switched to the priority charging profile, that allows for the maximum possible current or power under current circumstances. Message contains a transactionId, because it only applies to the transaction in progress.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. The transaction for which priority charging is requested.</td></tr><tr><td>activated</td><td>boolean</td><td>1..1</td><td>Required. True if priority charging was activated. False if it has stopped using the priority charging profile.</td></tr></table>
+
+# 1.55.2. NotifyPriorityChargingResponse
+
+(2.1) This response message has an empty body.
+
+# 1.56. NotifyReport
+
+# 1.56.1. NotifyReportRequest
+
+This contains the field definition of the NotifyReportRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The id of the GetReportRequest or GetBaseReportRequest that requested this report</td></tr><tr><td>generatedAt</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp of the moment this message was generated at the Charging Station.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. “to be continued” indicator. Indicates whether another part of the report follows in an upcoming notifyReportRequest message. Default value when omitted is false.</td></tr><tr><td>seqNo</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. Sequence number of this message. First message starts at 0.</td></tr><tr><td>reportData</td><td>报告显示，报告类型为：</td><td>0..*</td><td>Optional. List of Data type.</td></tr></table>
+
+# 1.56.2. NotifyReportResponse
+
+Response to a NotifyReportRequest message. No fields are defined.
+
+# 1.57. NotifySettlement
+
+# 1.57.1. NotifySettlementRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. The transactionId that the settlement belongs to. Can be empty if the payment transaction is canceled prior to the start of the OCPP transaction.</td></tr><tr><td>pspRef</td><td>identifierString[0..255]</td><td>1..1</td><td>Required. The payment reference received from the payment terminal and is used as the value for idToken.</td></tr><tr><td>status</td><td>PaymentStatusEnumType</td><td>1..1</td><td>Required. The status of the settlement attempt.</td></tr><tr><td>statusInfo</td><td>string[0..500]</td><td>0..1</td><td>Optional. Additional information from payment terminal/payment process.</td></tr><tr><td>settlementAmount</td><td>decimal</td><td>1..1</td><td>Required. The amount that was settled, or attempted to be settled (in case of failure).</td></tr><tr><td>settlementTime</td><td>dateTime</td><td>1..1</td><td>Required. The time when the settlement was done.</td></tr><tr><td>receiptId</td><td>string[0..50]</td><td>0..1</td><td>Optional.</td></tr><tr><td>receiptUrl</td><td>string[0..2000]</td><td>0..1</td><td>Optional. The receipt URL, to be used if the receipt is generated by the payment terminal or the CS.</td></tr><tr><td>vatNumber</td><td>string[0..20]</td><td>0..1</td><td>Optional. VAT number for a company receipt.</td></tr><tr><td>vatCompany</td><td>AddressType</td><td>0..1</td><td>Optional. Company address associated with VAT number.</td></tr></table>
+
+# 1.57.2. NotifySettlementResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>receiptUrl</td><td>string[0..2000]</td><td>0..1</td><td>Optional. The receipt URL if receipt generated by CSMS.
+The Charging Station can QR encode it and show it to the EV Driver.</td></tr><tr><td>receiptId</td><td>string[0..50]</td><td>0..1</td><td>Optional. The receipt id if the receipt is generated by CSMS.</td></tr></table>
+
+# 1.58. NotifyWebPaymentStarted
+
+# 1.58.1. NotifyWebPaymentStartedRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. EVSE id for which transaction is requested.</td></tr><tr><td>timeout</td><td>integer</td><td>1..1</td><td>Required. Timeout value in seconds after which no result of web payment process (e.g. QR code scanning) is to be expected anymore.</td></tr></table>
+
+# 1.58.2. NotifyWebPaymentStartedResponse
+
+# 1.59. OpenPeriodicEventStream
+
+# 1.59.1. OpenPeriodicEventStreamRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>constantStreamData</td><td>ConstantStreamDataType</td><td>1..1</td><td>Required. Constant part of stream data</td></tr></table>
+
+# 1.59.2. OpenPeriodicEventStreamResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Result of request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status info</td></tr></table>
+
+# 1.60. PublishFirmware
+
+# 1.60.1. PublishFirmwareRequest
+
+This contains the field definition of the PublishFirmwareRequest PDU sent by the CSMS to the Local Controller.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>location</td><td>string[0..2000]</td><td>1..1</td><td>Required. This contains a string containing a URI pointing to a location from which to retrieve the firmware.</td></tr><tr><td>retries</td><td>integer, 0 ⇔ val</td><td>0..1</td><td>Optional. This specifies how many times Charging Station must retry to download the firmware before giving up. If this field is not present, it is left to Charging Station to decide how many times it wants to retry. If the value is 0, it means: no retries.</td></tr><tr><td>checksum</td><td>identifierString[0..32]</td><td>1..1</td><td>Required. The MD5 checksum over the entire firmware file as a hexadecimal string of length 32.</td></tr><tr><td>requestId</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. The Id of the request.</td></tr><tr><td>retrypInterval</td><td>integer, 0 ⇔ val</td><td>0..1</td><td>Optional. The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charging Station to decide how long to wait between attempts.</td></tr></table>
+
+# 1.60.2. PublishFirmwareResponse
+
+This contains the field definition of the PublishFirmwareResponse PDU sent by the Local Controller to the CSMS in response to a PublishFirmwareRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the request was accepted.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.61. PublishFirmwareStatusNotification
+
+# 1.61.1. PublishFirmwareStatusNotificationRequest
+
+This contains the field definition of the PublishFirmwareStatusNotificationRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>PublishFirmwareStatusEnumType</td><td>1..1</td><td>Required. This contains the progress status of the publishfirmware installation.</td></tr><tr><td>location</td><td>string[0..2000]</td><td>0..*</td><td>Optional. Required if status is Published. Can be multiple URI's, if the Local Controller supports e.g. HTTP, HTTPS, and FTP.</td></tr><tr><td>requestId</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. The request id that was provided in the PublishFirmwareRequest which triggered this action.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. (2.1) Detailed status info</td></tr></table>
+
+# 1.61.2. PublishFirmwareStatusNotificationResponse
+
+This contains the field definition of the PublishFirmwareStatusNotificationResponse PDU sent by the CSMS to the Charging station in response to a PublishFirmwareStatusNotificationRequest.
+
+# 1.62. PullDynamicScheduleUpdate
+
+# 1.62.1. PullDynamicScheduleUpdateRequest
+
+(2.1) This message is sent by a Charging Station to request an update of setpoints and/or limits of the charging profile with given chargingProfileId.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>chargingProfileId</td><td>integer</td><td>1..1</td><td>Required. Id of charging profile to update.</td></tr></table>
+
+# 1.62.2.PullDynamicScheduleUpdateResponse
+
+(2.1) If no data can be provided by CSMS, then the response will only contain status.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ChargingProfileStatusEnumType</td><td>1..1</td><td>Required. Result of request.</td></tr><tr><td>scheduleUpdate</td><td>ChargingScheduleUpdateType</td><td>0..1</td><td>Optional. Updated charging schedule period values.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Additional info about status</td></tr></table>
+
+# 1.63. ReportChargingProfiles
+
+# 1.63.1. ReportChargingProfilesRequest
+
+Reports charging profiles installed in the Charging Station, as requested via a GetChargingProfilesRequest message. The charging profile report can be split over multiple ReportChargingProfilesRequest messages, this can be because charging profiles for different charging sources need to be reported, or because there is just to much data for one message.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. Id used to match the GetChargingProfilesRequest message with the resulting ReportChargingProfilesRequest messages. When the CSMS provided a requestId in the GetChargingProfilesRequest, this field SHALL contain the same value.</td></tr><tr><td>chargingLimitSource</td><td>string[0..20]</td><td>1..1</td><td>Required. Source that has installed this charging profile. Values defined in Appendix as ChargingLimitSourceEnumStringType.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. To Be Continued. Default value when omitted: false. false indicates that there are no further messages as part of this report.</td></tr><tr><td>evseld</td><td>integer, 0 ⇌ val</td><td>1..1</td><td>Required. The evse to which the charging profile applies. If evseld = 0, the message contains an overall limit for the Charging Station.</td></tr><tr><td>chargingProfile</td><td>ChargingProfileType</td><td>1..*</td><td>Required. The charging profile as configured in the Charging Station.</td></tr></table>
+
+# 1.63.2. ReportChargingProfilesResponse
+
+The ReportChargingProfilesResponse message is sent by the CSMS to the Charging Station in response to a ReportChargingProfilesRequest. No fields are defined.
+
+# 1.64. ReportDERControl
+
+# 1.64.1. ReportDERControlRequest
+
+Reports DER controls requested by a GetDERControlRequest message. The report may consist of more than one message.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. RequestId from GetDERControlRequest.</td></tr><tr><td>tbc</td><td>boolean</td><td>0..1</td><td>Optional. To Be Continued. Default value when omitted: false.
+False indicates that there are no further messages as part of this report.</td></tr><tr><td>fixedPFAbsorb</td><td>FixedPFGetType</td><td>0..24</td><td>Optional. Fixed power factor setpoint when absorbing active power</td></tr><tr><td>fixedPFInject</td><td>FixedPFGetType</td><td>0..24</td><td>Optional. Fixed power factor setpoint when injecting active power</td></tr><tr><td>fixedVar</td><td>FixedVarGetType</td><td>0..24</td><td>Optional. Fixed reactive power setting</td></tr><tr><td>limitMaxDischarge</td><td>LimitMaxDischargeGetType</td><td>0..24</td><td>Optional. Limit maximum discharge as percentage of rated capability</td></tr><tr><td>freqDroop</td><td>FreqDroopGetType</td><td>0..24</td><td>Optional. Frequency-Watt parameterized mode</td></tr><tr><td>enterService</td><td>EnterServiceGetType</td><td>0..24</td><td>Optional. Enter service after trip parameters</td></tr><tr><td>gradient</td><td>GradientGetType</td><td>0..24</td><td>Optional. Gradient settings</td></tr><tr><td>curve</td><td>DERCurveGetType</td><td>0..24</td><td>Optional. Voltage/Frequency/Active/Reactive curve</td></tr></table>
+
+# 1.64.2. ReportDERControlResponse
+
+This is an empty message sent by CSMS in response to a ReportDERControlRequest message.
+
+# 1.65. RequestBatterySwap
+
+# 1.65.1. RequestBatterySwapRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. Request id to match with BatterySwapRequest.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>1..1</td><td>Required. Id token of EV driver.</td></tr></table>
+
+# 1.65.2. RequestBatterySwapResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Accepted or rejected the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Additional info on status</td></tr></table>
+
+# 1.66. RequestStartTransaction
+
+# 1.66.1. RequestStartTransactionRequest
+
+This contains the field definitions of the RequestStartTransactionRequest PDU sent to Charging Station by CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer, 1 <= val</td><td>0..1</td><td>Optional. Number of the EVSE on which to start the transaction. Evseld SHALL be > 0</td></tr><tr><td>remoteStartId</td><td>integer</td><td>1..1</td><td>Required. Id given by the server to this start request. The Charging Station will return this in the TransactionEventRequest, letting the server know which transaction was started for this request. Use to start a transaction.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>1..1</td><td>Required. The identifier that the Charging Station must use to start a transaction.</td></tr><tr><td>chargingProfile</td><td>ChargingProfileType</td><td>0..1</td><td>Optional. Charging Profile to be used by the Charging Station for the requested transaction. ChargingProfilePurpose MUST be set to TxProfile</td></tr><tr><td>groupldToken</td><td>IdTokenType</td><td>0..1</td><td>Optional. The groupldToken is only relevant when the transaction is to be started on an EVSE for which a reservation for groupldToken is active, and the configuration variable AuthorizationRemoteStart = false (otherwise the AuthorizationResponse could return the groupldToken).</td></tr></table>
+
+# 1.66.2. RequestStartTransactionResponse
+
+This contains the field definitions of the RequestStartTransactionResponse PDU sent from Charging Station to CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>RequestStartStopStatusEnumType</td><td>1..1</td><td>Required. Status indicating whether the Charging Station accepts the request to start a transaction.</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. When the transaction was already started by the Charging Station before the RequestStartTransactionRequest was received, for example: cable plugged in first. This contains the transactionId of the already started transaction.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.67. RequestStopTransaction
+
+# 1.67.1. RequestStopTransactionRequest
+
+This contains the field definitions of the RequestStopTransactionRequest PDU sent to Charging Station by CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. The identifier of the transaction which the Charging Station is requested to stop.</td></tr></table>
+
+# 1.67.2. RequestStopTransactionResponse
+
+This contains the field definitions of the RequestStopTransactionResponse PDU sent from Charging Station to CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>RequestStartStopStatusEnumType</td><td>1..1</td><td>Required. Status indicating whether Charging Station accepts the request to stop a transaction.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.68. ReservationStatusUpdate
+
+# 1.68.1. ReservationStatusUpdateRequest
+
+This contains the field definition of the ReservationStatusUpdateRequest PDU sent by the Charging Station to the CSMS.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>reservationId</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. The ID of the reservation.</td></tr><tr><td>reservationUpdateStatus</td><td>ReservationUpdateStatusEnumTyp e</td><td>1..1</td><td>Required. The updated reservation status.</td></tr></table>
+
+# 1.68.2. ReservationStatusUpdateResponse
+
+This contains the field definition of the ReservationStatusUpdateResponse PDU sent by the CSMS to the Charging Station in response to a ReservationStatusUpdateRequest. No fields are defined.
+
+# 1.69. ReserveNow
+
+# 1.69.1. ReserveNowRequest
+
+This contains the field definition of the ReserveNowRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. Id of reservation.</td></tr><tr><td>expiryDateTime</td><td>dateTime</td><td>1..1</td><td>Required. Date and time at which the reservation expires.</td></tr><tr><td>connectorType</td><td>string[0..20]</td><td>0..1</td><td>Optional. This field specifies the connector type. Values defined in Appendix as ConnectorEnumStringType.</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>0..1</td><td>Optional. This contains ID of the evse to be reserved.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>1..1</td><td>Required. The identifier for which the reservation is made.</td></tr><tr><td>groupIdToken</td><td>IdTokenType</td><td>0..1</td><td>Optional. The group identifier for which the reservation is made.</td></tr></table>
+
+# 1.69.2. ReserveNowResponse
+
+This contains the field definition of the ReserveNowResponse PDU sent by the Charging Station to the CSMS in response to ReserveNowRequest PDU.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ReserveNowStatusEnumType</td><td>1..1</td><td>Required. This indicates the success or failure of the reservation.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.70. Reset
+
+# 1.70.1. ResetRequest
+
+This contains the field definition of the ResetRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>type</td><td>ResetEnumType</td><td>1..1</td><td>Required. This contains the type of reset that the Charging Station or EVSE should perform.</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>0..1</td><td>Optional. This contains the ID of a specific EVSE that needs to be reset, instead of the entire Charging Station.</td></tr></table>
+
+# 1.70.2. ResetResponse
+
+This contains the field definition of the ResetResponse PDU sent by the Charging Station to the CSMS in response to ResetRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ResetStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station is able to perform the reset.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.71. SecurityEventNotification
+
+# 1.71.1. SecurityEventNotificationRequest
+
+Sent by the Charging Station to the CSMS in case of a security event.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>type</td><td>string[0..50]</td><td>1..1</td><td>Required. Type of the security event. This value should be taken from the Security events list.</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. Date and time at which the event occurred.</td></tr><tr><td>techInfo</td><td>string[0..255]</td><td>0..1</td><td>Optional. Additional information about the occurred security event.</td></tr></table>
+
+# 1.71.2. SecurityEventNotificationResponse
+
+Sent by the CSMS to the Charging Station to confirm the receipt of a SecurityEventNotificationRequest message. No fields are defined.
+
+# 1.72.SendLocalList
+
+# 1.72.1. SendLocalListRequest
+
+This contains the field definition of the SendLocalListRequest PDU sent by the CSMS to the Charging Station. If no (empty) localAuthorizationList is given and the updateType is Full, all IdTokens are removed from the list. Requesting a Differential update without or with empty localAuthorizationList will have no effect on the list. All IdTokens in the localAuthorizationList MUST be unique, no duplicate values are allowed.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>versionNumber</td><td>integer</td><td>1..1</td><td>Required. In case of a full update this is the version number of the full list. In case of a differential update it is the version number of the list after the update has been applied.</td></tr><tr><td>updateType</td><td>UpdateEnumType</td><td>1..1</td><td>Required. This contains the type of update (full or differential) of this request.</td></tr><tr><td>localAuthorizationList</td><td>AuthorizationData</td><td>0..*</td><td>Optional. This contains the Local Authorization List entries.</td></tr></table>
+
+# 1.72.2. SendLocalListResponse
+
+This contains the field definition of the SendLocalListResponse PDU sent by the Charging Station to the CSMS in response to SendLocalListRequest PDU.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>SendLocalListStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station has successfully received and applied the update of the Local Authorization List.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.73. SetChargingProfile
+
+# 1.73.1. SetChargingProfileRequest
+
+This contains the field definition of the SetChargingProfileRequest PDU sent by the CSMS to the Charging Station. The CSMS uses this message to send charging profiles to a Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. For TxDefaultProfile an evseld=0 applies the profile to each individual evse. For ChargingStationMaxProfile and ChargingStationExternalConstraints an evseld=0 contains an overall limit for the whole Charging Station.</td></tr><tr><td>chargingProfile</td><td>ChargingProfileType</td><td>1..1</td><td>Required. The charging profile to be set at the Charging Station.</td></tr></table>
+
+# 1.73.2. SetChargingProfileResponse
+
+This contains the field definition of the SetChargingProfileResponse PDU sent by the Charging Station to the CSMS in response to SetChargingProfileRequest PDU.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ChargingProfileStatusEnumType</td><td>1..1</td><td>Required. Returns whether the Charging Station has been able to process the message successfully. This does not guarantee the schedule will be followed to the letter. There might be other constraints the Charging Station may need to take into account.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional.</td></tr></table>
+
+# 1.74. SetDefaultTariff
+
+# 1.74.1. SetDefaultTariffRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. EVSE that tariff applies to. When evseld = 0, then tarriff applies to all EVSEs.</td></tr><tr><td>tariff</td><td>TariffType</td><td>1..1</td><td>Required. Tariff structure.</td></tr></table>
+
+# 1.74.2. SetDefaultTariffResponse
+
+Class
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>TariffSetStatusEnumType</td><td>1..1</td><td>Required.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed info on status</td></tr></table>
+
+# 1.75. SetDERControl
+
+# 1.75.1. SetDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>isEmpty</td><td>boolean</td><td>1..1</td><td>Required. True if this is a default DER control</td></tr><tr><td>controlled</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. Unique id of this control, e.g. UUID</td></tr><tr><td>controlType</td><td>DERControlEnumType</td><td>1..1</td><td>Required. Type of control. Determines which setting field below is used.</td></tr><tr><td>curve</td><td>DERCurveType</td><td>0..1</td><td>Optional. Voltage/Frequency/Active/Reactive curve</td></tr><tr><td>fixedPFAbsorb</td><td>FixedPFType</td><td>0..1</td><td>Optional. Fixed power factor setpoint when absorbing active power</td></tr><tr><td>fixedPFInject</td><td>FixedPFType</td><td>0..1</td><td>Optional. Fixed power factor setpoint when injecting active power</td></tr><tr><td>fixedVar</td><td>FixedVarType</td><td>0..1</td><td>Optional. Fixed reactive power</td></tr><tr><td>limitMaxDischarge</td><td>LimitMaxDischargeType</td><td>0..1</td><td>Optional. Limit maximum discharge as percentage of rated capability</td></tr><tr><td>freqDroop</td><td>FreqDroopType</td><td>0..1</td><td>Optional. Frequency-Watt parameterized mode</td></tr><tr><td>enterService</td><td>EnterServiceType</td><td>0..1</td><td>Optional. Enter service after trip parameters (default control only)</td></tr><tr><td>gradient</td><td>GradientType</td><td>0..1</td><td>Optional. Gradient (default ramp rate) settings (default control only)</td></tr></table>
+
+# 1.75.2. SetDERControlResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>DERControlStatusEnumType</td><td>1..1</td><td>Required. Result of operation.</td></tr><tr><td>supersededlds</td><td>identifierString[0..36]</td><td>0..24</td><td>Optional. List of controllers that are superseded as a result of setting this control.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Additional details on status</td></tr></table>
+
+# 1.76. SetDisplayMessage
+
+# 1.76.1. SetDisplayMessageRequest
+
+This contains the field definition of the SetDisplayMessageRequest PDU sent by the CSMS to the Charging Station. The CSMS asks the Charging Station to configure a new display message that the Charging Station will display (in the future). See also 001 - Set Display Message, 002 - Set Display Message for Transaction and 006 - Replace Display Message
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>message</td><td>MessageInfoType</td><td>1..1</td><td>Required. Message to be configured in the Charging Station, to be displayed.</td></tr></table>
+
+# 1.76.2. SetDisplayMessageResponse
+
+This contains the field definition of the SetDisplayMessageResponse PDU sent by the Charging Station to the CSMS in a response to a SetDisplayMessageRequest. See also O01 - Set Display Message, O02 - Set Display Message for Transaction and O06 - Replace Display Message
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>DisplayMessageStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station is able to display the message.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.77. SetMonitoringBase
+
+# 1.77.1. SetMonitoringBaseRequest
+
+This contains the field definition of the SetMonitoringBaseRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>monitoringBase</td><td>MonitoringBaseEnumType</td><td>1..1</td><td>Required. Specify which monitoring base will be set</td></tr></table>
+
+# 1.77.2. SetMonitoringBaseResponse
+
+This contains the field definition of the SetMonitoringBaseResponse PDU sent by the Charging Station to the CSMS in response to a SetMonitoringBaseRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericDeviceModelStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the Charging Station was able to accept the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.78. SetMonitoringLevel
+
+# 1.78.1. SetMonitoringLevelRequest
+
+This contains the field definition of the SetMonitoringLevelRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>severity</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. The Charging Station SHALL only report events with a severity number lower than or equal to this severity. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.The severity levels have the following meaning:0-DangerIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately.1-Hardware FailureIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required.2-System FailureIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required.3-CriticalIndicates a critical error. Action is required.4-ErrorIndicates a non-urgent error. Action is required.5-A AlertIndicates an alert event. Default severity for any type of monitoring event.6-WarningIndicates a warning event. Action may be required.7-NoticeIndicates an unusual event. No immediate action is required.8-InformationalIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required.9-DebugIndicates information useful to developers for debugging, not useful during operations.</td></tr></table>
+
+# 1.78.2. SetMonitoringLevelResponse
+
+This contains the field definition of the SetMonitoringLevelResponse PDU sent by the Charging Station to the CSMS in response to a SetMonitoringLevelRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the Charging Station was able to accept the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.79. SetNetworkProfile
+
+# 1.79.1. SetNetworkProfileRequest
+
+With this message the CSMS gains the ability to configure the connection data (e.g. CSMS URL, OCPP version, APN, etc) on a Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>configurationSlot</td><td>integer</td><td>1..1</td><td>Required. Slot in which the configuration should be stored.</td></tr><tr><td>connectionData</td><td>NetworkConnectionProfileType</td><td>1..1</td><td>Required. Connection details.</td></tr></table>
+
+# 1.79.2. SetNetworkProfileResponse
+
+This contains the field definition of the SetNetworkProfileResponse PDU sent by the Charging Station to the CSMS in response to a SetNetworkProfileRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>SetNetworkProfileStatusEnumType</td><td>1..1</td><td>Required. Result of operation.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.80. SetVariableMonitoring
+
+# 1.80.1. SetVariableMonitoringRequest
+
+This contains the field definition of the SetVariableMonitoringRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>setMonitoringData</td><td>SetMonitoringDataType</td><td>1..*</td><td>Required. List of MonitoringData containing monitoring settings.</td></tr></table>
+
+# 1.80.2. SetVariableMonitoringResponse
+
+This contains the field definition of the SetVariableMonitoringResponse PDU sent by the Charging Station to the CSMS in response to a SetVariableMonitoringRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>setMonitoringResult</td><td>SetMonitoringResultType</td><td>1..*</td><td>Required. List of result statuses per monitor.</td></tr></table>
+
+# 1.81. SetVariables
+
+# 1.81.1. SetVariablesRequest
+
+This contains the field definition of the SetVariablesRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>setVariableData</td><td>SetVariableDataType</td><td>1..*</td><td>Required. List of Component-Variable pairs and attribute values to set.</td></tr></table>
+
+# 1.81.2. SetVariablesResponse
+
+This contains the field definition of the SetVariablesResponse PDU sent by the Charging Station to the CSMS in response to a SetVariablesRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>setVariableResult</td><td>SetVariableResultType</td><td>1..*</td><td>Required. List of result statuses per Component-Variable.</td></tr></table>
+
+# 1.82. SignCertificate
+
+# 1.82.1. SignCertificateRequest
+
+Sent by the Charging Station to the CSMS to request that the Certificate Authority signs the public key into a certificate.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>csr</td><td>string[0..5500]</td><td>1..1</td><td>Required. The Charging Station SHALL send the public key in form of a Certificate Signing Request (CSR) as described in RFC 2986 [22] and then PEM encoded, using the SignCertificateRequest message.</td></tr><tr><td>certificateType</td><td>CertificateSigningUseEnumType</td><td>0..1</td><td>Optional. Indicates the type of certificate that is to be signed. When omitted the certificate is to be used for both the 15118 connection (if implemented) and the Charging Station to CSMS connection.</td></tr><tr><td>requestId</td><td>integer</td><td>0..1</td><td>Optional. (2.1) RequestId to match this message with the CertificateSignedRequest.</td></tr><tr><td>hashRootCertificate</td><td>CertificateHashDataType</td><td>0..1</td><td>Optional. (2.1) The hash of the root certificate to identify the PKI to use.</td></tr></table>
+
+# 1.82.2. SignCertificateResponse
+
+Sent by the CSMS to the Charging Station in response to the SignCertificateRequest message.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Specifies whether the CSMS can process the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.83. StatusNotification
+
+# 1.83.1. StatusNotificationRequest
+
+This contains the field definition of the StatusNotificationRequest PDU sent by the Charging Station to the CSMS. This message might be removed in a future version of OCPP. It will be replaced by Device Management Monitoring events.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. The time for which the status is reported.</td></tr><tr><td>connectorStatus</td><td>Connector statusesEnumType</td><td>1..1</td><td>Required. This contains the current status of the Connector.</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. The id of the EVSE to which the connector belongs for which the status is reported.</td></tr><tr><td>connectorld</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. The id of the connector within the EVSE for which the status is reported.</td></tr></table>
+
+# 1.83.2. StatusNotificationResponse
+
+This contains the field definition of StatusNotificationResponse sent by the CSMS to the Charging Station in response to a StatusNotificationRequest. This message might be removed in a future version of OCPP. It will be replaced by Device Management Monitoring events.
+
+No fields are defined.
+
+# 1.84. TransactionEvent
+
+# 1.84.1. TransactionRequest
+
+This section contains the field definition of the TransactionEventRequest PDU sent by the Charging Station to the CSMS. For each of the eventTypes; Started, Updated and Ended, the corresponding cardinality is specified.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>eventType</td><td>TransactionEventEnumType</td><td>1..1</td><td>Required. This contains the type of this event. The first TransactionEvent of a transaction SHALL contain: "Started" The last TransactionEvent of a transaction SHALL contain: "Ended" All others SHALL contain: "Updated"</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. The date and time at which this transaction event occurred.</td></tr><tr><td>triggerReason</td><td>TriggerReasonEnumType</td><td>1..1</td><td>Required. Reason the Charging Station sends this message to the CSMS</td></tr><tr><td>seqNo</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. Incremental sequence number, helps with determining if all messages of a transaction have been received.</td></tr><tr><td>offline</td><td>boolean</td><td>0..1</td><td>Optional. Indication that this transaction event happened when the Charging Station was offline. Default = false, meaning: the event occurred when the Charging Station was online.</td></tr><tr><td>NumberOfPhasesUsed</td><td>integer, 0 <= val >= 3</td><td>0..1</td><td>Optional. If the Charging Station is able to report the number of phases used, then it SHALL provide it. When omitted the CSMS may be able to determine the number of phases used as follows:1: The numberPhases in the currently used ChargingSchedule.2: The number of phases provided via device management.</td></tr><tr><td>cableMaxCurrent</td><td>integer</td><td>0..1</td><td>Optional. The maximum current of the connected cable in Ampere (A).</td></tr><tr><td>reservationId</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. This contains the Id of the reservation that terminates as a result of this transaction.</td></tr><tr><td>preconditioningStatus</td><td>PreconditioningStatusEnumType</td><td>0..1</td><td>Optional. (2.1) The current preconditioning status of the BMS in the EV. Default value is Unknown.</td></tr><tr><td>evseSleep</td><td>boolean</td><td>0..1</td><td>Optional. (2.1) True when EVSE electronics are in sleep mode for this transaction. Default value (when absent) is false.</td></tr><tr><td>meterValue</td><td>MeterValueType</td><td>0..*</td><td>Optional. This contains the meter values relevant to the transaction. Depending on the eventType of this TransactionRequest the following Configuration Variable is used to configure which measurands are used:Started: SampledDataTxStartedMeasurandsUpdated: SampledDataTxUpdatedMeasurands and AlignedDataMeasurandsEnded: SampledDataTxEndedMeasurands and AlignedDataTxEndedMeasurands</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>0..1</td><td>Optional. This contains the identifier for which a transaction 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 TransactionRequest for every authorization (for starting or for stopping) done for this transaction, so that CSMS can return the idTokenInfo in the TransactionResponse. idToken should not be present in the TransactionRequest when a transaction is ended by a RequestStopTransactionRequest or a ResetRequest.</td></tr><tr><td>evse</td><td>EVSEType</td><td>0..1</td><td>Optional. This identifies which evse (and connector) of the Charging Station is used.</td></tr><tr><td>transactionInfo</td><td>TransactionType</td><td>1..1</td><td>Required. Contains transaction specific information.</td></tr><tr><td>costDetails</td><td>CostDetailsType</td><td>0..1</td><td>Optional. (2.1) Optional. Only required in TransactionRequest('Ended') and only if Charging Station calculated cost locally.</td></tr></table>
+
+# 1.84.2. TransactionResponse
+
+This contains the field definition of the TransactionEventResponse PDU sent by the CSMS to the Charging Station in response to a TransactionRequest.
+
+Class
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>totalCost</td><td>decimal</td><td>0..1</td><td>Optional. When eventType of TransactionRequest is Updated, then this value contains the running cost. When eventType of TransactionRequest is Ended, then this contains the final total cost of this transaction, including taxes, in the currency configured with the Configuration Variable: Currency. Absence of this value does not imply that the transaction was free. To indicate a free transaction, the CSMS SHALL send a value of 0.00.</td></tr><tr><td>chargingPriority</td><td>integer</td><td>0..1</td><td>Optional. Priority from a business point of view. Default priority is 0, The range is from -9 to 9. Higher values indicate a higher priority. The chargingPriority in TransactionResponse is temporarily, so it may not be set in the IdTokenInfoType afterwards. Also the chargingPriority in TransactionResponse has a higher priority than the one in IdTokenInfoType.</td></tr><tr><td>idTokenInfo</td><td>IdTokenInfoType</td><td>0..1</td><td>Optional. This contains information about authorization status, expiry and group id. Is required when the transactionRequest contained an idToken.</td></tr><tr><td>updatedPersonalMessage</td><td>MessageContentType</td><td>0..1</td><td>Optional. This can contain updated personal message that can be shown to the EV Driver. This can be used to provide updated tariff information .</td></tr><tr><td>updatedPersonalMessageExtra</td><td>MessageContentType</td><td>0..4</td><td>Optional. (2.1) Additional languages besides the default language in updatedPersonalMessage.</td></tr><tr><td>transactionLimit</td><td>TransactionLimitType</td><td>0..1</td><td>Optional. (2.1) Maximum cost/energy/time limit allowed for this transaction.</td></tr></table>
+
+# 1.85. TriggerMessage
+
+# 1.85.1. TriggerMessageRequest
+
+This contains the field definition of the TriggerMessageRequest PDU sent by the CSMS to the Charging Station.
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestedMessage</td><td>MessageTriggerEnumType</td><td>1..1</td><td>Required. Type of message to be triggered.</td></tr><tr><td>customTrigger</td><td>string[0..50]</td><td>0..1</td><td>Optional. (2.1) When requestedMessage = CustomTrigger this will trigger sending the corresponding message in field customTrigger, if supported by Charging Station.</td></tr><tr><td>evse</td><td>EVSEType</td><td>0..1</td><td>Optional. Can be used to specify the EVSE and Connector if required for the message which needs to be sent.</td></tr></table>
+
+# 1.85.2. TriggerMessageResponse
+
+This contains the field definition of the TriggerMessageResponse PDU sent by the Charging Station to the CSMS in response to TriggerMessageResponse.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>TriggerMessageStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the Charging Station will send the requested notification or not.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.86. UnlockConnector
+
+# 1.86.1. UnlockConnectorRequest
+
+This contains the field definition of the UnlockConnectorRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. This contains the identifier of the EVSE for which a connector needs to be unlocked.</td></tr><tr><td>connectorld</td><td>integer, 0 ⇔ val</td><td>1..1</td><td>Required. This contains the identifier of the connector that needs to be unlocked.</td></tr></table>
+
+# 1.86.2. UnlockConnectorResponse
+
+This contains the field definition of the UnlockConnectorResponse PDU sent by the Charging Station to the CSMS in response to an UnlockConnectorRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>UnlockStatusEnumType</td><td>1..1</td><td>Required. This indicates whether the Charging Station has unlocked the connector.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.87. UnpublishFirmware
+
+# 1.87.1. UnpublishFirmwareRequest
+
+This contains the field definition of the UnpublishFirmwareRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>checksum</td><td>identifierString[0..32]</td><td>1..1</td><td>Required. The MD5 checksum over the entire firmware file as a hexadecimal string of length 32.</td></tr></table>
+
+# 1.87.2. UnpublishFirmwareResponse
+
+This contains the field definition of the UnpublishFirmwareResponse PDU sent by the Charging Station to the CSMS in response to a UnpublishFirmwareRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>UnpublishFirmwareStatusEnumType</td><td>1..1</td><td>Required. Indicates whether the Local Controller succeeded in unpublishing the firmware.</td></tr></table>
+
+# 1.88. UpdateDynamicSchedule
+
+# 1.88.1. UpdateDynamicScheduleRequest
+
+(2.1) This message is used to update a setpoint or limit in a dynamic charging profile.
+
+Class
+
+Id of dynamic charging profile to update.
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>chargingProfileId</td><td>integer</td><td>1..1</td><td>Required. Id of charging profile to update.</td></tr><tr><td>scheduleUpdate</td><td>ChargingScheduleupdateType</td><td>1..1</td><td>Required. Updated values for charging schedule period.</td></tr></table>
+
+# 1.88.2. UpdateDynamicScheduleResponse
+
+(2.1) Returns whether the Charging Station has been able to process the message successfully.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ChargingProfileStatusEnumType</td><td>1..1</td><td>Required. Returns whether message was processed successfully.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status info.</td></tr></table>
+
+# 1.89. UpdateFirmware
+
+# 1.89.1. Update FirmwareRequest
+
+This contains the field definition of the UpdateFirmwareRequest PDU sent by the CSMS to the Charging Station.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>retries</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. This specifies how many times Charging Station must retry to download the firmware before giving up. If this field is not present, it is left to Charging Station to decide how many times it wants to retry. If the value is 0, it means: no retries.</td></tr><tr><td>retrypInterval</td><td>integer</td><td>0..1</td><td>Optional. The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charging Station to decide how long to wait between attempts.</td></tr><tr><td>requestId</td><td>integer</td><td>1..1</td><td>Required. The Id of this request</td></tr><tr><td>firmware</td><td>FirmwareType</td><td>1..1</td><td>Required. Specifies the firmware to be updated on the Charging Station.</td></tr></table>
+
+# 1.89.2. Update FirmwareResponse
+
+This contains the field definition of the UpdateFirmwareResponse PDU sent by the Charging Station to the CSMS in response to an UpdateFirmwareRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>UpdateFirmwareStatusEnumType</td><td>1..1</td><td>Required. This field indicates whether the Charging Station was able to accept the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 1.90. UsePriorityCharging
+
+# 1.90.1. UsePriorityChargingRequest
+
+(2.1) Message sent by CSMS to tell Charging Station to switch to the priority charging profile, that allows for the maximum possible current or power under current circumstances. Message contains a transactionId, because it only applies to the transaction in progress.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. The transaction for which priority charging is requested.</td></tr><tr><td>activate</td><td>boolean</td><td>1..1</td><td>Required. True to request priority charging. False to request stopping priority charging.</td></tr></table>
+
+# 1.90.2. UsePriorityChargingResponse
+
+(2.1) Status of the UsePriorityChargingRequest.
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>PriorityChargingStatusEnumType</td><td>1..1</td><td>Required. Result of the request.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional.</td></tr></table>
+
+# 1.91. VatNumberValidation
+
+# 1.91.1. VatNumberValidationRequest
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>vatNumber</td><td>string[0..20]</td><td>1..1</td><td>Required. VAT number to check.</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>0..1</td><td>Optional. EVSE id for which check is done</td></tr></table>
+
+# 1.91.2. VatNumberValidationResponse
+
+Class
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>vatNumber</td><td>string[0..20]</td><td>1..1</td><td>Required. VAT number that was requested.</td></tr><tr><td>evseld</td><td>integer, 0 ⇔ val</td><td>0..1</td><td>Optional. EVSE id for which check was requested.</td></tr><tr><td>status</td><td>GenericStatusEnumType</td><td>1..1</td><td>Required. Result of operation.</td></tr><tr><td>company</td><td>(AddressType</td><td>0..1</td><td>Optional. Company address associated with vatNumber.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Additional info on status</td></tr></table>
+
+# Chapter 2. Datatypes
+
+# 2.1. AbsolutePriceScheduleType
+
+Class
+
+The AbsolutePriceScheduleType is modeled after the same type that is defined in ISO 15118-20, such that if it is supplied by an EMSP as a signed EXI message, the conversion from EXI to JSON (in OCPP) and back to EXI (for ISO 15118-20) does not change the digest and therefore does not invalidate the signature.
+
+# class AbsolutePriceSchedule-Simple
+
+Structure is identical to that of ISO 15118-20.
+
+"BusinessComponent" AbsolutePriceScheduleType
+
++PriceRuleStacks
+
+1..1024
+
+"BusinessComponent" PriceRuleStackTrace
+
++PriceRule
+
+1..8
+
+BusinessComponent PriceRuleType
+
++TaxRules
+
+0..10
+
+BusinessComponent TaxRuleType
+
++OverstayRuleList
+
+0..1
+
+BusinessComponentOverstayRuleListType
+
+rule
+
+BusinessComponent OverstayRuleType
+
++Additional Selected Services
+
+0.5
+
+BusinessComponent
+FunctionalSelectedServicesType
+
+AbsolutePriceScheduleType is used by: Common:ChargingScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>timeAnchor</td><td>dateTime</td><td>1..1</td><td>Required. Starting point of price schedule.</td></tr><tr><td>priceScheduleID</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. Unique ID of price schedule</td></tr><tr><td>priceScheduleDescription</td><td>string[0..160]</td><td>0..1</td><td>Optional. Description of the price schedule.</td></tr><tr><td>currency</td><td>string[0..3]</td><td>1..1</td><td>Required. Currency according to ISO 4217.</td></tr><tr><td>language</td><td>string[0..8]</td><td>1..1</td><td>Required. String that indicates what language is used for the human readable strings in the price schedule. Based on ISO 639.</td></tr><tr><td>priceAlgorithm</td><td>string[0..2000]</td><td>1..1</td><td>Required. A string in URN notation which shall uniquely identify an algorithm that defines how to compute an energy fee sum for a specific power profile based on the EnergyFee information from the PriceRule elements.</td></tr><tr><td>priceRuleStacks</td><td>PriceRuleSTACKType</td><td>1..1024</td><td>Required. A set of pricing rules for parking and energy costs.</td></tr><tr><td>taxRules</td><td>Tax-ruleType</td><td>0..10</td><td>Optional. Optional. Describes the applicable tax rule(s) for this price schedule.</td></tr><tr><td>additionalSelectedServices</td><td>AdditionalSelectedServicesType</td><td>0..5</td><td>Optional. Optional. A set of prices for optional services (e.g. valet, carwash).</td></tr><tr><td>overstayRuleList</td><td>OverstayRuleelistType</td><td>0..1</td><td>Optional. Optional. A set of overstay rules that allows for escalation of charges after the overstay is triggered.</td></tr><tr><td>minimumCost</td><td>RationalNUMBERType</td><td>0..1</td><td>Optional. Optional. Minimum amount to be billed for the overall charging session (e.g. including energy, parking, and overstay).</td></tr><tr><td>maximumCost</td><td>RationalNUMBERType</td><td>0..1</td><td>Optional. Optional. Maximum amount to be billed for the overall charging session (e.g. including energy, parking, and overstay).</td></tr></table>
+
+# 2.2. ACChargingParametersType
+
+Class
+
+EV AC charging parameters for ISO 15118-2
+
+ACChargingParametersType is used by: Common:ChargingNeedsType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>energyAmount</td><td>decimal</td><td>1..1</td><td>Required. Amount of energy requested (in Wh). This includes energy required for preconditioning. Relates to: ISO 15118-2: AC_EVChargeParameterType: EAmountISO 15118-20:Dynamic/Scheduled_SEReqControlModeType:EVTargetEnergyRequest</td></tr><tr><td>evMinCurrent</td><td>decimal</td><td>1..1</td><td>Required. Minimum current (amps) supported by the electric vehicle (per phase). Relates to:ISO 15118-2: AC_EVChargeParameterType: EVMinCurrent</td></tr><tr><td>evMaxCurrent</td><td>decimal</td><td>1..1</td><td>Required. Maximum current (amps) supported by the electric vehicle (per phase). Includes cable capacity.Relates to:ISO 15118-2: AC_EVChargeParameterType: EVMaxCurrent</td></tr><tr><td>evMaxVoltage</td><td>decimal</td><td>1..1</td><td>Required. Maximum voltage supported by the electric vehicle. Relates to:ISO 15118-2: AC_EVChargeParameterType: EVMaxVoltage</td></tr></table>
+
+# 2.3. AdditionalInfoType
+
+Class
+
+Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.
+
+AdditionalInfoType is used by: Common.IdTokenType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>additionalIdToken</td><td>identifierString[0..255]</td><td>1..1</td><td>Required. (2.1) This field specifies the additional IdToken.</td></tr><tr><td>type</td><td>string[0..50]</td><td>1..1</td><td>Required. additionInfo can be used to send extra information to CSMS in addition to the regular authorization with IdToken. AdditionInfo contains one or more custom types, which need to be agreed upon by all parties involved. When the type is not supported, the CSMS/Charging Station MAY ignore the additionInfo.</td></tr></table>
+
+# 2.4. AdditionalSelectedServicesType
+
+Class
+
+Part of ISO 15118-20 price schedule.
+
+AdditionalSelectedServicesType is used by: Common:AbsolutePriceScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>serviceName</td><td>string[0..80]</td><td>1..1</td><td>Required. Human readable string to identify this service.</td></tr><tr><td>serviceFee</td><td>RationalNUMBERType</td><td>1..1</td><td>Required. Cost of the service.</td></tr></table>
+
+# 2.5. AddressType
+
+Class
+
+(2.1) A generic address format.
+
+AddressType is used by: NotifySettlementRequest, VatNumberValidationResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>name</td><td>string[0..50]</td><td>1..1</td><td>Required. Name of person/company</td></tr><tr><td>address1</td><td>string[0..100]</td><td>1..1</td><td>Required. Address line 1</td></tr><tr><td>address2</td><td>string[0..100]</td><td>0..1</td><td>Optional. Address line 2</td></tr><tr><td>city</td><td>string[0..100]</td><td>1..1</td><td>Required. City</td></tr><tr><td>postalCode</td><td>string[0..20]</td><td>0..1</td><td>Optional. Postal code</td></tr><tr><td>country</td><td>string[0..50]</td><td>1..1</td><td>Required. Country name</td></tr></table>
+
+# 2.6.APNType
+
+Class
+
+Collection of configuration data needed to make a data-connection over a cellular network.
+
+# NOTE
+
+When asking a GSM modem to dial in, it is possible to specify which mobile operator should be used. This can be done with the mobile country code (MCC) in combination with a mobile network code (MNC). Example: If your preferred network is Vodafone Netherlands, the MCC=204 and the MNC=04 which means the key PreferredNetwork = 20404 Some modems allows to specify a preferred network, which means, if this network is not available, a different network is used. If you specify UseOnlyPreferredNetwork and this network is not available, the modem will not dial in.
+
+APNType is used by: SetNetworkProfileRequest.NetworkConnectionProfileType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>apn</td><td>string[0..2000]</td><td>1..1</td><td>Required. The Access Point Name as an URL.</td></tr><tr><td>apnUserName</td><td>string[0..50]</td><td>0..1</td><td>Optional. APN username.</td></tr><tr><td>apnPassword</td><td>string[0..64]</td><td>0..1</td><td>Optional. (2.1) APN Password.</td></tr><tr><td>simPin</td><td>integer</td><td>0..1</td><td>Optional. SIM card pin code.</td></tr><tr><td>preferredNetwork</td><td>identifierString[0..6]</td><td>0..1</td><td>Optional. Preferred network, written as MCC and MNC concatenated. See note.</td></tr><tr><td>useOnlyPreferredNetwork</td><td>boolean</td><td>0..1</td><td>Optional. Default: false. Use only the preferred Network, do not dial in when not available. See Note.</td></tr><tr><td>apnAuthentication</td><td>APNAuthenticationEnumType</td><td>1..1</td><td>Required. Authentication method.</td></tr></table>
+
+# 2.7. AuthorizationData
+
+Class
+
+Contains the identifier to use for authorization.
+
+AuthorizationData is used by: SendLocalListRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>idTokenInfo</td><td>IdTokenInfoType</td><td>0..1</td><td>Optional. Required when UpdateType is Full. This contains information about authorization status, expiry and group id. For a Differential update the following applies: If this element is present, then this entry SHALL be added or updated in the Local Authorization List. If this element is absent, the entry for this IdToken in the Local Authorization List SHALL be deleted.</td></tr><tr><td>idToken</td><td>IdTokenType</td><td>1..1</td><td>Required. This contains the identifier which needs to be stored for authorization.</td></tr></table>
+
+# 2.8. BatteryDataType
+
+Class
+
+BatteryDataType is used by: BatterySwapRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Slot number where battery is inserted or removed.</td></tr><tr><td>serialNumber</td><td>string[0..50]</td><td>1..1</td><td>Required. Serial number of battery.</td></tr><tr><td>soC</td><td>decimal, 0 < = val < = 100</td><td>1..1</td><td>Required. State of charge</td></tr><tr><td>soH</td><td>decimal, 0 < = val < = 100</td><td>1..1</td><td>Required. State of health</td></tr><tr><td>productionDate</td><td>dateTime</td><td>0..1</td><td>Optional. Production date of battery.</td></tr><tr><td>vendorInfo</td><td>string[0..500]</td><td>0..1</td><td>Optional. Vendor-specific info from battery in undefined format.</td></tr></table>
+
+# 2.9. CertificateDataChainType
+
+Class
+
+CertificateDataChainType is used by: GetInstalledCertificatesResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>certificateType</td><td>GetCertificateldUseEnumType</td><td>1..1</td><td>Required. Indicates the type of the requested certificate(s).</td></tr><tr><td>certificateHashData</td><td>CertificateHashDataType</td><td>1..1</td><td>Required. Information to identify a certificate.</td></tr><tr><td>childCertificateHashData</td><td>CertificateHashDataType</td><td>0..4</td><td>Optional. Information to identify the child certificate(s).</td></tr></table>
+
+# 2.10. CertificateHashDataType
+
+Class
+
+CertificateDataType is used by: Common: CertificateChainType, Common: CertificateRequestInfoType, Common: CertificateStatusType, SignCertificateRequest, DeleteCertificateRequest, CustomerInformationRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>hashAlgorithm</td><td>HashAlgorithmEnumType</td><td>1..1</td><td>Required. Used algorithms for the hashes provided.</td></tr><tr><td>issuerNameHash</td><td>identifierString[0..128]</td><td>1..1</td><td>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.</td></tr><tr><td>issuerKeyHash</td><td>string[0..128]</td><td>1..1</td><td>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.</td></tr><tr><td>serialNumber</td><td>identifierString[0..40]</td><td>1..1</td><td>Required. The string representation of the hexadecimal value of the serial number without the prefix "0x" and without leading zeroes.</td></tr></table>
+
+# 2.11. CertificateStatusRequestInfoType
+
+Class
+
+Data necessary to request the revocation status of a certificate.
+
+CertificateStatusRequestInfoType is used by: GetCertificateChainStatusRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>source</td><td>CertificateStatusSourceEnumType</td><td>1..1</td><td>Required. Source of status: OCSP, CRL</td></tr><tr><td>urls</td><td>string[0..2000]</td><td>1..5</td><td>Required. URL(s) of source.</td></tr><tr><td>certificateHashData</td><td>CertificateHashDataType</td><td>1..1</td><td>Required. Hash data of certificate.</td></tr></table>
+
+# 2.12. CertificateStatusType
+
+Class
+
+Revocation status of certificate
+
+CertificateStatusType is used by: GetCertificateChainStatusResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>source</td><td>CertificateStatusSourceEnumType</td><td>1..1</td><td>Required. Source of status: OCSP, CRL</td></tr><tr><td>status</td><td>CertificateStatusEnumType</td><td>1..1</td><td>Required. Status of certificate: good, revoked or unknown.</td></tr><tr><td>nextUpdate</td><td>dateTime</td><td>1..1</td><td>Required.</td></tr><tr><td>certificateHashData</td><td>CertificateHashDataType</td><td>1..1</td><td>Required. Hash data of the certificate.</td></tr></table>
+
+# 2.13. ChargingLimitType
+
+Class
+
+ChargingLimitType is used by: NotifyChargingLimitRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>chargingLimitSource</td><td>string[0..20]</td><td>1..1</td><td>Required. Represents the source of the charging limit.Values defined in appendix asChargingLimitSourceEnum不同类型.</td></tr><tr><td>isLocalGeneration</td><td>boolean</td><td>0..1</td><td>Optional. (2.1) True when the reported limit concerns local generation that is providing extra capacity, instead of a limitation.</td></tr><tr><td>isGridCritical</td><td>boolean</td><td>0..1</td><td>Optional. Indicates whether the charging limit is critical for the grid.</td></tr></table>
+
+# 2.14. ChargingNeedsType
+
+Class
+
+ChargingNeedsType is used by: NotifyEVChargingNeedsRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>requestedEnergyTransfer</td><td>EnergyTransferModeEnumType</td><td>1..1</td><td>Required. Mode of energy transfer requested by the EV.</td></tr><tr><td>availableEnergyTransfer</td><td>EnergyTransferModeEnumType</td><td>0..*</td><td>Optional. (2.1) Modes of energy transfer that are marked as available by EV.</td></tr><tr><td>controlMode</td><td>ControlModeEnumType</td><td>0..1</td><td>Optional. (2.1) Indicates whether EV wants to operate in Dynamic or Scheduled mode. When absent, Scheduled mode is assumed for backwards compatibility.ISO 15118-20:ServiceSelectionReq(SelectedEnergyTransferService)</td></tr><tr><td>mobilityNeedsMode</td><td>MobilityNeedsModeEnumType</td><td>0..1</td><td>Optional. (2.1) Value of EVCC indicates that EV determines min/target SOC and departure time.A value of EVCC_SECC indicates that charging station or CSMS may also update min/target SOC and departure time.ISO 15118-20:ServiceSelectionReq(SelectedEnergyTransferService)</td></tr><tr><td>departureTime</td><td>dateTime</td><td>0..1</td><td>Optional. Estimated departure time of the EV.ISO 15118-2: AC/DC_EVChargeParameterType:DepartureTimeISO 15118-20:Dynamic/Scheduled_SEReqControlModeType:DepartureTime</td></tr><tr><td>v2xChargingParameters</td><td>V2XChargingParametersType</td><td>0..1</td><td>Optional. (2.1) The list of charging parameters that apply to an ISO 15118-20 session or any other session that supports bidirectional charging.</td></tr><tr><td>dcChargingParameters</td><td>DCChargingParametersType</td><td>0..1</td><td>Optional. EV DC charging parameters</td></tr><tr><td>acChargingParameters</td><td>ACChargingParametersType</td><td>0..1</td><td>Optional. EV AC charging parameters.</td></tr><tr><td>evEnergyOffer</td><td>EVEnergyOfferType</td><td>0..1</td><td>Optional. (2.1) Discharging and associated price offered by EV. Schedule periods during which EV is willing to discharge have a negative value for power.</td></tr><tr><td>derChargingParameters</td><td>DERChargingParametersType</td><td>0..1</td><td>Optional. (2.1) Additional charging parameters for ISO 15118-20 AC bidirectional sessions with DER control (AC_BPT_DER)</td></tr></table>
+
+# 2.15. ChargingPeriodType
+
+Class
+
+A ChargingPeriodType consists of a start time, and a list of possible values that influence this period, for example: amount of energy charged this period, maximum current during this period etc.
+
+ChargingPeriodType is used by: Common:CostDetailsType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>tariffld</td><td>string[0..60]</td><td>0..1</td><td>Optional. Unique identifier of the Tariff that was used to calculate cost. If not provided, then cost was calculated by some other means.</td></tr><tr><td>startPeriod</td><td>dateTime</td><td>1..1</td><td>Required. Start timestamp of charging period. A period ends when the next period starts. The last period ends when the session ends.</td></tr><tr><td>dimensions</td><td>CostDimensionType</td><td>0..*</td><td>Optional. List of volume per cost dimension for this charging period.</td></tr></table>
+
+# 2.16. ChargingProfileCriterionType
+
+Class
+
+A ChargingProfileCriterionType is a filter for charging profiles to be selected by a GetChargingProfilesRequest.
+
+ChargingProfileCriterionType is used by: GetChargingProfilesRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>chargingProfilePurpose</td><td>ChargingProfilePurposeEnumType</td><td>0..1</td><td>Optional. Defines the purpose of the schedule transferred by this profile</td></tr><tr><td>stackLevel</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. Value determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.</td></tr><tr><td>chargingProfileld</td><td>integer</td><td>0..*</td><td>Optional. List of all the chargingProfiles requested. Any ChargingProfile that matches one of these profiles will be reported. If omitted, the Charging Station SHALL not filter on chargingProfileld. This field SHALL NOT contain more ids than set in ChargingProfileEntries.maxLimit</td></tr><tr><td>chargingLimitSource</td><td>string[0..20]</td><td>0..4</td><td>Optional. For which charging limit sources, charging profiles SHALL be reported. If omitted, the Charging Station SHALL not filter on chargingLimitSource. Values defined in Appendix as ChargingLimitSourceEnumDDRType.</td></tr></table>
+
+# 2.17. ChargingProfileType
+
+Class
+
+A ChargingProfile consists of 1 to 3 ChargingSchedules with a list of ChargingSchedulePeriods, describing the amount of power or current that can be delivered per time interval.
+
+class ChargingProfile-Simple
+
+
+
+ChargingProfileType is used by: RequestStartTransactionRequest, SetChargingProfileRequest, ReportChargingProfilesRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>1..1</td><td>Required. Id of ChargingProfile. Unique within charging station. Id can have a negative value. This is useful to distinguish charging profiles from an external actor (external constraints) from charging profiles received from CSMS.</td></tr><tr><td>stkLevel</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. Value determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.</td></tr><tr><td>chargingProfilePurpose</td><td>ChargingProfilePurposeEnumType</td><td>1..1</td><td>Required. Defines the purpose of the schedule transferred by this profile</td></tr><tr><td>chargingProfileKind</td><td>ChargingProfileKindEnumType</td><td>1..1</td><td>Required. Indicates the kind of schedule.</td></tr><tr><td>recrencyKind</td><td>RecrencyKindEnumType</td><td>0..1</td><td>Optional. Indicates the start point of a recurrence.</td></tr><tr><td>validFrom</td><td>dateTime</td><td>0..1</td><td>Optional. Point in time at which the profile starts to be valid. If absent, the profile is valid as soon as it is received by the Charging Station.</td></tr><tr><td>validTo</td><td>dateTime</td><td>0..1</td><td>Optional. Point in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. SHALL only be included if ChargingProfilePurpose is set to TxProfile in a SetChargingProfileRequest. The transactionId is used to match the profile to a specific transaction.</td></tr><tr><td>maxOfflineDuration</td><td>integer</td><td>0..1</td><td>Optional. (2.1) Period in seconds that this charging profile remains valid after the Charging Station has gone offline. After this period the charging profile becomes invalid for as long as it is offline and the Charging Station reverts back to a valid profile with a lower stack level. If invalidAfterOfflineDuration is true, then this charging profile will become permanently invalid. A value of 0 means that the charging profile is immediately invalid while offline. When the field is absent, then no timeout applies and the charging profile remains valid when offline.</td></tr><tr><td>invalidAfterOfflineDuration</td><td>boolean</td><td>0..1</td><td>Optional. (2.1) When set to true this charging profile will not be valid anymore after being offline for more than maxOfflineDuration. When absent defaults to false.</td></tr><tr><td>dynUpdateInterval</td><td>integer</td><td>0..1</td><td>Optional. (2.1) Interval in seconds after receipt of last update, when to request a profile update by sending a PullDynamicScheduleUpdateRequest message. A value of 0 or no value means that no update interval applies. Only relevant in a dynamic charging profile.</td></tr><tr><td>dynUpdateTime</td><td>dateTime</td><td>0..1</td><td>Optional. (2.1) Time at which limits or setpoints in this charging profile were last updated by a PullDynamicScheduleUpdateRequest or UpdateDynamicScheduleRequest or by an external actor. Only relevant in a dynamic charging profile.</td></tr><tr><td>priceScheduleSignature</td><td>string[0..256]</td><td>0..1</td><td>Optional. (2.1) ISO 15118-20 signature for all price schedules in chargingSchedules.Note: for 256-bit elliptic curves (like secp256k1) the ECDSA signature is 512 bits (64 bytes) and for 521-bit curves (like secp521r1) the signature is 1042 bits. This equals 131 bytes, which can be encoded as base64 in 176 bytes.</td></tr><tr><td>chargingSchedule</td><td>ChargingScheduleType</td><td>1..3</td><td>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. For ISO 15118 Dynamic Control Mode only one chargingSchedule shall be provided.</td></tr></table>
+
+# 2.18. ChargingSchedulePeriodType
+
+Class
+
+Charging schedule period structure defines a time period in a charging schedule. It is used in: CompositeScheduleType and in ChargingScheduleType. When used in a NotifyEVChargingScheduleRequest only startPeriod, limit, limit_L2, limit_L3 are relevant.
+
+ChargingSchedulePeriodType is used by: Common:ChargingScheduleType, Common:CompositeScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>startPeriod</td><td>integer</td><td>1..1</td><td>Required. Start of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.</td></tr><tr><td>limit</td><td>decimal</td><td>0..1</td><td>Optional. Optional only when not required by the operationMode, as in CentralSetpoint, ExternalSetpoint, ExternalLimits, LocalFrequency, LocalLoadBalancing. Charging rate limit during the schedule period, in the applicable chargingRateUnit. This SHOULD be a non-negative value; a negative value is only supported for backwards compatibility with older systems that use a negative value to specify a discharging limit. When using chargingRateUnit = w, this field represents the sum of the power of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.</td></tr><tr><td>limit_L2</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Charging rate limit on phase L2 in the applicable chargingRateUnit.</td></tr><tr><td>limit_L3</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Charging rate limit on phase L3 in the applicable chargingRateUnit.</td></tr><tr><td>numberPhases</td><td>integer, 0 <= val <= 3</td><td>0..1</td><td>Optional. The number of phases that can be used for charging. For a DC EVSE this field should be omitted. For an AC EVSE a default value of numberPhases = 3 will be assumed if the field is absent.</td></tr><tr><td>phaseToUse</td><td>integer, 0 <= val <= 3</td><td>0..1</td><td>Optional. Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPPhaseSwitchingSupported is defined and true. It's not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.</td></tr><tr><td>dischargeLimit</td><td>decimal, val <= 0</td><td>0..1</td><td>Optional. (2.1) Limit in chargingRateUnit that the EV is allowed to discharge with. Note, these are negative values in order to be consistent with setpoint, which can be positive and negative. For AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.</td></tr><tr><td>dischargeLimit_L2</td><td>decimal, val <= 0</td><td>0..1</td><td>Optional. (2.1) Limit in chargingRateUnit on phase L2 that the EV is allowed to discharge with.</td></tr><tr><td>dischargeLimit_L3</td><td>decimal, val <= 0</td><td>0..1</td><td>Optional. (2.1) Limit in chargingRateUnit on phase L3 that the EV is allowed to discharge with.</td></tr><tr><td>setpoint</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Setpoint in chargingRateUnit that the EV should follow as close as possible. Use negative values for discharging. When a limit and/or dischargeLimit are given the overshoot when following setpoint must remain within these values. This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.</td></tr><tr><td>setpoint_L2</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Setpoint in chargingRateUnit that the EV should follow on phase L2 as close as possible.</td></tr><tr><td>setpoint_L3</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Setpoint in chargingRateUnit that the EV should follow on phase L3 as close as possible.</td></tr><tr><td>setpointReactive</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Setpoint for reactive power (or current) in chargingRateUnit that the EV should follow as closely as possible. Positive values for inductive, negative for capacitive reactive power or current. This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.</td></tr><tr><td>setpointReactive_L2</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Setpoint for reactive power (or current) in chargingRateUnit that the EV should follow on phase L2 as closely as possible.</td></tr><tr><td>setpointReactive_L3</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Setpoint for reactive power (or current) in chargingRateUnit that the EV should follow on phase L3 as closely as possible.</td></tr><tr><td>preconditioningRequest</td><td>boolean</td><td>0..1</td><td>Optional. (2.1) If true, the EV should attempt to keep the BMS preconditioned for this time interval.</td></tr><tr><td>evseSleep</td><td>boolean</td><td>0..1</td><td>Optional. (2.1) If true, the EVSE must turn off power electronics/modules associated with this transaction. Default value when absent is false.</td></tr><tr><td>v2xBaseline</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Power value that, when present, is used as a baseline on top of which values from v2xFreqWattCurve and v2xSignalWattCurve are added.</td></tr><tr><td>operationMode</td><td>OperationModeEnumType</td><td>0..1</td><td>Optional. (2.1) Charging operation mode to use during this time interval. When absent defaults to ChargingOnly.</td></tr><tr><td>v2xFreqWattCurve</td><td>V2XFreqWattPointType</td><td>0..20</td><td>Optional. (2.1) Only required when operationMode = LocalFrequency. When used it must contain at least two coordinates to specify a power-frequency table to use during this period. The table determines the value of setpoint power for a given frequency. chargingRateUnit must be W for LocalFrequency control.</td></tr><tr><td>v2xSignalWattCurve</td><td>V2XSignalWattPointType</td><td>0..20</td><td>Optional. (2.1) Only used, but not required, when operationMode = LocalFrequency. When used it must contain at least two coordinates to specify a signal-frequency curve to use during this period. The curve determines the value of setpoint power for a given signal. chargingRateUnit must be W for LocalFrequency control.</td></tr></table>
+
+# 2.19. ChargingScheduleType
+
+Class
+
+Charging schedule structure defines a list of charging periods, as used in: NotifyEVChargingScheduleRequest and ChargingProfileType. When used in a NotifyEVChargingScheduleRequest only duration and chargingSchedulePeriod are relevant and chargingRateUnit must be 'W'.
+
+An ISO 15118-20 session may provide either an absolutePriceSchedule or a priceLevelSchedule. An ISO 15118-2 session can only provide a_salesTariff_element. The field digestValue is used when price schedule or sales tariff are signed.
+
+classChargingSchedule-Simple
+
+
+
+ChargingScheduleType is used by: Common:ChargingProfileType, NotifyChargingLimitRequest, NotifyEVChargingScheduleRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer</td><td>1..1</td><td>Required.</td></tr><tr><td>startSchedule</td><td>dateTime</td><td>0..1</td><td>Optional. Starting point of an absolute schedule or recurring schedule.</td></tr><tr><td>duration</td><td>integer</td><td>0..1</td><td>Optional. Duration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction in case startSchedule is absent.</td></tr><tr><td>chargingRateUnit</td><td>ChargingRateUnitEnumType</td><td>1..1</td><td>Required. The unit of measure in which limits and setpoints are expressed.</td></tr><tr><td>minChargingRate</td><td>decimal</td><td>0..1</td><td>Optional. Minimum charging rate supported by the EV. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates.</td></tr><tr><td>powerTolerance</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Power tolerance when following EVPowerProfile.</td></tr><tr><td>signatureId</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. (2.1) Id of this element for referencing in a signature.</td></tr><tr><td>digestValue</td><td>string[0..88]</td><td>0..1</td><td>Optional. (2.1) Base64 encoded hash (SHA256 for ISO 15118-2, SHA512 for ISO 15118-20) of the EXI price schedule element. Used in signature.</td></tr><tr><td>useLocalTime</td><td>boolean</td><td>0..1</td><td>Optional. (2.1) Defaults to false. When true, disregard time zone offset in北京时间 fields of ChargingScheduleType and use unqualified local time at Charging Station instead. This allows the same Absolute or Recurring charging profile to be used in both summer and winter time.</td></tr><tr><td>randomizedDelay</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. (2.1) Defaults to 0. When randomizedDelay not equals zero, then the start of each ChargingSchedulePeriodType is delayed by a randomly chosen number of seconds between 0 and randomizedDelay. Only allowed for TxProfile and TxDefaultProfile.</td></tr><tr><td>salesTariff</td><td>SalesTariffType</td><td>0..1</td><td>Optional. Sales tariff for charging associated with this schedule.</td></tr><tr><td>chargingSchedulePeriod</td><td>ChargingSchedulePeriodType</td><td>1..1024</td><td>Required. List of ChargingSchedulePeriod elements defining maximum power or current usage over time. The maximum number of periods, that is supported by the Charging Station, if less than 1024, is set by device model variable SmartChargingCtrl.PeriodsPerSchedule.</td></tr><tr><td>absolutePriceSchedule</td><td>AbsolutePriceScheduleType</td><td>0..1</td><td>Optional. (2.1) The ISO 15118-20 absolute price schedule.</td></tr><tr><td>priceLevelSchedule</td><td>PriceLevelScheduleType</td><td>0..1</td><td>Optional. (2.1) The ISO 15118-20 price level schedule</td></tr><tr><td>limitAtSoC</td><td>LimitAtSoCType</td><td>0..1</td><td>Optional. (2.1) When present and SoC of EV is greater than or equal to soc, then charging limit or setpoint will be capped to the value of limit.</td></tr></table>
+
+# 2.20. ChargingScheduleUpdateType
+
+Class
+
+Updates to a ChargingSchedulePeriodType for dynamic charging profiles.
+
+ChargingScheduleUpdateType is used by: PullDynamicScheduleUpdateResponse, UpdateDynamicScheduleRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>limit</td><td>decimal</td><td>0..1</td><td>Optional. Optional only when not required by the operationMode, as in CentralSetpoint, ExternalSetpoint, ExternalLimits, LocalFrequency, LocalLoadBalancing. Charging rate limit during the schedule period, in the applicable chargingRateUnit. This SHOULD be a non-negative value; a negative value is only supported for backwards compatibility with older systems that use a negative value to specify a discharging limit. For AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.</td></tr><tr><td>limit_L2</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Charging rate limit on phase L2 in the applicable chargingRateUnit.</td></tr><tr><td>limit_L3</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Charging rate limit on phase L3 in the applicable chargingRateUnit.</td></tr><tr><td>dischargeLimit</td><td>decimal, val <= 0</td><td>0..1</td><td>Optional. (2.1) Limit in chargingRateUnit that the EV is allowed to discharge with. Note, these are negative values in order to be consistent with setpoint, which can be positive and negative. For AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.</td></tr><tr><td>dischargeLimit_L2</td><td>decimal, val <= 0</td><td>0..1</td><td>Optional. (2.1) Limit in chargingRateUnit on phase L2 that the EV is allowed to discharge with.</td></tr><tr><td>dischargeLimit_L3</td><td>decimal, val <= 0</td><td>0..1</td><td>Optional. (2.1) Limit in chargingRateUnit on phase L3 that the EV is allowed to discharge with.</td></tr><tr><td>setpoint</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Setpoint in chargingRateUnit that the EV should follow as close as possible. Use negative values for discharging.When a limit and/or dischargeLimit are given the overshoot when following setpoint must remain within these values. This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.</td></tr><tr><td>setpoint_L2</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Setpoint in chargingRateUnit that the EV should follow on phase L2 as close as possible.</td></tr><tr><td>setpoint_L3</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Setpoint in chargingRateUnit that the EV should follow on phase L3 as close as possible.</td></tr><tr><td>setpointReactive</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Setpoint for reactive power (or current) in chargingRateUnit that the EV should follow as closely as possible. Positive values for inductive, negative for capacitive reactive power or current. This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.</td></tr><tr><td>setpointReactive_L2</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Setpoint for reactive power (or current) in chargingRateUnit that the EV should follow on phase L2 as closely as possible.</td></tr><tr><td>setpointReactive_L3</td><td>decimal</td><td>0..1</td><td>Optional. (2.1) Setpoint for reactive power (or current) in chargingRateUnit that the EV should follow on phase L3 as closely as possible.</td></tr></table>
+
+# 2.21. ChargingStationType
+
+Class
+
+The physical system where an Electrical Vehicle (EV) can be charged.
+
+ChargingStationType is used by: BootNotificationRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>serialNumber</td><td>string[0..25]</td><td>0..1</td><td>Optional. Vendor-specific device identifier.</td></tr><tr><td>model</td><td>string[0..20]</td><td>1..1</td><td>Required. Defines the model of the device.</td></tr><tr><td>vendorName</td><td>string[0..50]</td><td>1..1</td><td>Required. Identifies the vendor (not necessarily in a unique manner).</td></tr><tr><td>firmwareVersion</td><td>string[0..50]</td><td>0..1</td><td>Optional. This contains the firmware version of the Charging Station.</td></tr><tr><td>modem</td><td>ModemType</td><td>0..1</td><td>Optional. Defines the functional parameters of a communication link.</td></tr></table>
+
+# 2.22. ClearChargingProfileType
+
+Class
+
+A ClearChargingProfileType is a filter for charging profiles to be cleared by ClearChargingProfileRequest.
+
+ClearChargingProfileType is used by: ClearChargingProfileRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer, 0 < = val</td><td>0..1</td><td>Optional. Specifies the id of the EVSE for which to clear charging profiles. An evseld of zero (0) specifies the charging profile for the overall Charging Station. Absence of this parameter means the clearing applies to all charging profiles that match the other criteria in the request.</td></tr><tr><td>chargingProfilePurpose</td><td>ChargingProfilePurposeEnumType</td><td>0..1</td><td>Optional. Specifies to purpose of the charging profiles that will be cleared, if they meet the other criteria in the request.</td></tr><tr><td>stackLevel</td><td>integer, 0 < = val</td><td>0..1</td><td>Optional. Specifies the stackLevel for which charging profiles will be cleared, if they meet the other criteria in the request.</td></tr></table>
+
+# 2.23. ClearMonitoringResultType
+
+Class
+
+ClearMonitoringResultType is used by: ClearVariableMonitoringResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>ClearMonitoringStatusEnumType</td><td>1..1</td><td>Required. Result of the clear request for this monitor, identified by its Id.</td></tr><tr><td>id</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Id of the monitor of which a clear was requested.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Element providing more information about the status.</td></tr></table>
+
+# 2.24. ClearTariffsResultType
+
+Class
+
+ClearTariffsResultType is used by: ClearTariffsResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>tariffld</td><td>string[0..60]</td><td>0..1</td><td>Optional. Id of tariff for which status is reported. If no tariffs were found, then this field is absent, and status will be NotTariff.</td></tr><tr><td>status</td><td>TariffClearStatusEnumType</td><td>1..1</td><td>Required.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Additional info on status</td></tr></table>
+
+# 2.25. ComponentType
+
+Class
+
+A physical or logical component
+
+ComponentType is used by: Common:ComponentVariableType, Common:MessageInfoType, GetVariablesRequest.GetVariableDataType, GetVariablesResponse.GetVariableResultType, NotifyMonitoringReportRequest.MonitoringDataType, NotifyReportRequest.ReportDataType, SetVariableMonitoringRequest.SetMonitoringDataType, SetVariableMonitoringResponse.SetMonitoringResultType, SetVariablesRequest.SetVariableDataType, SetVariablesResponse.SetVariableResultType, NotifyEventRequest.EventDataType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>name</td><td>identifierString[0..50]</td><td>1..1</td><td>Required. Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.</td></tr><tr><td>instance</td><td>identifierString[0..50]</td><td>0..1</td><td>Optional. Name of instance in case the component exists as multiple instances. CaseInsensitive. strongly advised to use Camel Case.</td></tr><tr><td>evse</td><td>EVSEType</td><td>0..1</td><td>Optional. Specifies the EVSE when component is located at EVSE level, also specifies the connector when component is located at Connector level.</td></tr></table>
+
+# 2.26. ComponentVariableType
+
+Class
+
+Class to report components, variables and variable attributes and characteristics.
+
+ComponentVariableType is used by: GetMonitoringReportRequest, GetReportRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which a report of Variable is requested.</td></tr><tr><td>variable</td><td>VariableType</td><td>0..1</td><td>Optional. Variable for which the report is requested.</td></tr></table>
+
+# 2.27. CompositeScheduleType
+
+Class
+
+CompositeScheduleType is used by: GetCompositeScheduleResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evseld</td><td>integer, 0 <= val</td><td>1..1</td><td>Required.</td></tr><tr><td>duration</td><td>integer</td><td>1..1</td><td>Required.</td></tr><tr><td>scheduleStart</td><td>dateTime</td><td>1..1</td><td>Required.</td></tr><tr><td>chargingRateUnit</td><td>ChargingRateUnitEnumType</td><td>1..1</td><td>Required.</td></tr><tr><td>chargingSchedulePeriod</td><td>ChargingSchedulePeriodType</td><td>1..*</td><td>Required. List of ChargingSchedulePeriod elements defining maximum power or current over time.</td></tr></table>
+
+# 2.28. ConstantStreamDataType
+
+Class
+
+ConstantStreamDataType is used by: OpenPeriodicEventStreamRequest, GetPeriodicEventStreamResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Uniquely identifies the stream</td></tr><tr><td>variableMonitoringId</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Id of monitor used to report his event. It can be a preconfigured or hardwired monitor.</td></tr><tr><td>params</td><td>PeriodicStreamParamsType</td><td>1..1</td><td>Required. Max time and items parameters</td></tr></table>
+
+# 2.29. ConsumptionCostType
+
+Class
+
+ConsumptionCostType is used by: Common:SalesTariffEntryType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>startValue</td><td>decimal</td><td>1..1</td><td>Required. The lowest level of consumption that defines the starting point of this consumption block. The block interval extends to the start of the next interval.</td></tr><tr><td>cost</td><td>CostType</td><td>1..3</td><td>Required. This field contains the cost details.</td></tr></table>
+
+# 2.30. CostDetailsType
+
+Class
+
+CostDetailsType contains the cost as calculated by Charging Station based on provided TariffType.
+
+NOTE Reservation is not shown as a chargingPeriod, because it took place outside of the transaction.
+
+CostDetailsType is used by: TransactionEventRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>failureToCalculate</td><td>boolean</td><td>0..1</td><td>Optional. If set to true, then Charging Station has failed to calculate the cost.</td></tr><tr><td>failureReason</td><td>string[0..500]</td><td>0..1</td><td>Optional. Optional human-readable reason text in case of failure to calculate.</td></tr><tr><td>chargingPeriods</td><td>ChargingPeriodType</td><td>0..*</td><td>Optional. List of Charging Periods that make up this charging session. A finished session has of 1 or more periods, where each period has a different list of dimensions that determined the price. When sent as a running cost update during a transaction chargingPeriods are omitted.</td></tr><tr><td>totalCost</td><td>TotalCostType</td><td>1..1</td><td>Required. Total sum of all the costs of this transaction in the specified currency.</td></tr><tr><td>totalUsage</td><td>TotalUsageType</td><td>1..1</td><td>Required. Total usage of energy and time</td></tr></table>
+
+# 2.31. CostDimensionType
+
+Class
+
+Volume consumed of cost dimension.
+
+CostDimensionType is used by: Common:ChargingPeriodType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>type</td><td>CostDimensionEnumType</td><td>1..1</td><td>Required. Type of cost dimension: energy, power, time, etc.</td></tr><tr><td>volume</td><td>decimal</td><td>1..1</td><td>Required. Volume of the dimension consumed, measured according to the dimension type.</td></tr></table>
+
+# 2.32. CostType
+
+Class
+
+CostType is used by: Common:ConsumptionCostType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>costKind</td><td>CostKindEnumType</td><td>1..1</td><td>Required. The kind of cost referred to in the message element amount</td></tr><tr><td>amount</td><td>integer</td><td>1..1</td><td>Required. The estimated or actual cost per kWh</td></tr><tr><td>amountMultiplier</td><td>integer</td><td>0..1</td><td>Optional. Values: -3..3, The amountMultiplier defines the exponent to base 10 (dec). The final value is determined by: amount * 10^ amountMultiplier</td></tr></table>
+
+# 2.33. DCChargingParametersType
+
+Class
+
+EV DC charging parameters for ISO 15118-2
+
+DCChargingParametersType is used by: Common:ChargingNeedsType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evMaxCurrent</td><td>decimal</td><td>1..1</td><td>Required. Maximum current (in A) supported by the electric vehicle. Includes cable capacity. Relates to: ISO 15118-2: DC_EVChargeParameterType:EVMaximumCurrentLimit</td></tr><tr><td>evMaxVoltage</td><td>decimal</td><td>1..1</td><td>Required. Maximum voltage supported by the electric vehicle. Relates to: ISO 15118-2: DC_EVChargeParameterType: EVMaximumVoltageLimit</td></tr><tr><td>evMaxPower</td><td>decimal</td><td>0..1</td><td>Optional. Maximum power (in W) supported by the electric vehicle. Required for DC charging. Relates to: ISO 15118-2: DC_EVChargeParameterType: EVMaximumPowerLimit</td></tr><tr><td>evEnergyCapacity</td><td>decimal</td><td>0..1</td><td>Optional. Capacity of the electric vehicle battery (in Wh). Relates to: ISO 15118-2: DC_EVChargeParameterType: EVEnergyCapacity</td></tr><tr><td>energyAmount</td><td>decimal</td><td>0..1</td><td>Optional. Amount of energy requested (in Wh). This includes energy required for preconditioning. Relates to: ISO 15118-2: DC_EVChargeParameterType: EVEnergyRequest</td></tr><tr><td>stateOfCharge</td><td>integer, 0 <= val <= = 100</td><td>0..1</td><td>Optional. Energy available in the battery (in percent of the battery capacity) Relates to: ISO 15118-2: DC_EVChargeParameterType: DC_AVStatus: EVRESSSOC</td></tr><tr><td>fullSoC</td><td>integer, 0 <= val <= = 100</td><td>0..1</td><td>Optional. Percentage of SoC at which the EV considers the battery fully charged. (possible values: 0 - 100) Relates to: ISO 15118-2: DC_EVChargeParameterType: FullSOC</td></tr><tr><td>bulkSoC</td><td>integer, 0 <= val <= = 100</td><td>0..1</td><td>Optional. Percentage of SoC at which the EV considers a fast charging process to end. (possible values: 0 - 100) Relates to: ISO 15118-2: DC_EVChargeParameterType: BulkSOC</td></tr></table>
+
+# 2.34. DERChargingParametersType
+
+Class
+
+(2.1) DERChargingParametersType is used in ChargingNeedsType during an ISO 15118-20 session for AC_BPTDER to report the inverter settings related to DER control that were agreed between EVSE and EV.
+
+Fields starting with "ev" contain values from the EV. Other fields contain a value that is supported by both EV and EVSE.
+
+DERChargingParametersType type is only relevant in case of an ISO 15118-20 AC_BPT DER/AC DER charging session.
+
+NOTE All these fields have values greater or equal to zero (i.e. are non-negative)
+
+DERChargingParametersType is used by: Common:ChargingNeedsType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evSupportedDERControl</td><td>DERControlEnumType</td><td>0..*</td><td>Optional. DER control functions supported by EV.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:DERContrlFunctions (bitmap)</td></tr><tr><td>evOverExcitedMaxDischargePower</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum injected active power by EV, at specified over-excited power factor(overExcitedPowerFactor).It can also be defined as the rated maximum discharge power at the rated minimum injected reactive power value. This means that if the EV is providing reactive power support, and it is requested to discharge at max power (e.g. to satisfy an EMS request), the EV may override the request and discharge up to overExcitedMaximumDischargePower to meet the minimum reactive power requirements. Corresponds to the WOnPF attribute in IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVOverExcitedMaximumDischargePower</td></tr><tr><td>evOverExcitedPowerFactor</td><td>decimal</td><td>0..1</td><td>Optional. EV power factor when injecting (over excited) the minimum reactive power.Corresponds to the OvPF attribute in IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVOverExcitedPowerFactor</td></tr><tr><td>evUnderExcitedMaxDischargePower</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum injected active power by EV supported at specified under-excited power factor(EVUnderExcitedPowerFactor).It can also be defined as the rated maximum dischargePower at the rated minimum absorbed reactive power value. This means that if the EV is providing reactive power support, and it is requested to discharge at max power (e.g. to satisfy an EMS request), the EV may override the request and discharge up to underExcitedMaximumDischargePower to meet the minimum reactive power requirements.This corresponds to the WUnPF attribute in the IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVOunderExcitedMaximumDischargePower</td></tr><tr><td>evUnderExcitedPowerFactor</td><td>decimal</td><td>0..1</td><td>Optional. EV power factor when injecting (under excited) the minimum reactive power.Corresponds to the OvPF attribute in IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVOunderExcitedPowerFactor</td></tr><tr><td>maxApparentPower</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum total apparent power, defined by min(EV, EVSE) in va. Corresponds to the VAMaxRtg in IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumApparentPower</td></tr><tr><td>maxChargeApparentPower</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum absorbed apparent power, defined by min(EV, EVSE) in va.This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.Corresponds to the ChaVAMaxRtg in IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumChargeApparentPower</td></tr><tr><td>maxChargeApparentPower_L2</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum absorbed apparent power on phase L2, defined by min(EV, EVSE) in va. Corresponds to the ChaVAMaxRtg in IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumChargeApparentPower_L2</td></tr><tr><td>maxChargeApparentPower_L3</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum absorbed apparent power on phase L3, defined by min(EV, EVSE) in va. Corresponds to the ChaVAMaxRtg in IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumChargeApparentPower_L3</td></tr><tr><td>maxDischargeApparentPow er</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum injected apparent power, defined by min(EV, EVSE) in va.This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.Corresponds to the DisVAMaxRtg in IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumDischargeApparentPower_L2</td></tr><tr><td>maxDischargeApparentPow er_L2</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum injected apparent power on phase L2, defined by min(EV, EVSE) in va.Corresponds to the DisVAMaxRtg in IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumDischargeApparentPower_L2</td></tr><tr><td>maxDischargeApparentPow er_L3</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum injected apparent power on phase L3, defined by min(EV, EVSE) in va.Corresponds to the DisVAMaxRtg in IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumDischargeApparentPower_L3</td></tr><tr><td>maxChargeReactivePower</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum absorbed reactive power, defined by min(EV, EVSE), in vars.This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.Corresponds to the AvarMax attribute in the IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumChargeReactivePower</td></tr><tr><td>maxChargeReactivePower_L2</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum absorbed reactive power, defined by min(EV, EVSE), in vars on phase L2.Corresponds to the AvarMax attribute in the IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumChargeReactivePower_L2</td></tr><tr><td>maxChargeReactivePower_L3</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum absorbed reactive power, defined by min(EV, EVSE), in vars on phase L3.Corresponds to the AvarMax attribute in the IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumChargeReactivePower_L3</td></tr><tr><td>minChargeReactivePower</td><td>decimal</td><td>0..1</td><td>Optional. Rated minimum absorbed reactive power, defined by max(EV, EVSE), in vars.This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMinimumChargeReactivePower</td></tr><tr><td>minChargeReactivePower_L2</td><td>decimal</td><td>0..1</td><td>Optional. Rated minimum absorbed reactive power, defined by max(EV, EVSE), in vars on phase L2.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMinimumChargeReactivePower_L2</td></tr><tr><td>minChargeReactivePower_L3</td><td>decimal</td><td>0..1</td><td>Optional. Rated minimum absorbed reactive power, defined by max(EV, EVSE), in vars on phase L3.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMinimumChargeReactivePower_L3</td></tr><tr><td>maxDischargeReactivePower</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum injected reactive power, defined by min(EV, EVSE), in vars.This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.Corresponds to the IvarMax attribute in the IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumDischargeReactivePower</td></tr><tr><td>maxDischargeReactivePower_L2</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum injected reactive power, defined by min(EV, EVSE), in vars on phase L2.Corresponds to the IvarMax attribute in the IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumDischargeReactivePower_L2</td></tr><tr><td>maxDischargeReactivePower_L3</td><td>decimal</td><td>0..1</td><td>Optional. Rated maximum injected reactive power, defined by min(EV, EVSE), in vars on phase L3.Corresponds to the IvarMax attribute in the IEC 61850.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMaximumDischargeReactivePower_L3</td></tr><tr><td>minDischargeReactivePower</td><td>decimal</td><td>0..1</td><td>Optional. Rated minimum injected reactive power, defined by max(EV, EVSE), in vars.This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMinimumDischargeReactivePower</td></tr><tr><td>minDischargeReactivePower_L2</td><td>decimal</td><td>0..1</td><td>Optional. Rated minimum injected reactive power, defined by max(EV, EVSE), in var on phase L2.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMinimumDischargeReactivePower_L2</td></tr><tr><td>minDischargeReactivePower_L3</td><td>decimal</td><td>0..1</td><td>Optional. Rated minimum injected reactive power, defined by max(EV, EVSE), in var on phase L3.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVMinimumDischargeReactivePower_L3</td></tr><tr><td>nominalVoltage</td><td>decimal</td><td>0..1</td><td>Optional. Line voltage supported by EVSE and EV.ISO 15118-20:DER_BPT_AC_CPDReqEnergyTransferModeType:EVNominalVoltage</td></tr><tr><td>nominalVoltageOffset</td><td>decimal</td><td>0..1</td><td>Optional. The nominal AC voltage (rms) offset between the Charging Station's electrical connection point and the utility's point of common coupling.ISO 15118-20: DER_BPT_AC_CPDReqEnergyTransferModeType: EVNominalVoltageOffset</td></tr><tr><td>maxNominalVoltage</td><td>decimal</td><td>0..1</td><td>Optional. Maximum AC rms voltage, as defined by min(EV, EVSE) to operate with.ISO 15118-20: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumNominalVoltage</td></tr><tr><td>minNominalVoltage</td><td>decimal</td><td>0..1</td><td>Optional. Minimum AC rms voltage, as defined by max(EV, EVSE) to operate with.ISO 15118-20: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMinimumNominalVoltage</td></tr><tr><td>evInverterManufacturer</td><td>string[0..50]</td><td>0..1</td><td>Optional. Manufacturer of the EV inverter.ISO 15118-20: DER_BPT_AC_CPDReqEnergyTransferModeType: EVInverterManufacturer</td></tr><tr><td>evInverterModel</td><td>string[0..50]</td><td>0..1</td><td>Optional. Model name of the EV inverter.ISO 15118-20: DER_BPT_AC_CPDReqEnergyTransferModeType: EVInverterModel</td></tr><tr><td>evInverterSerialNumber</td><td>string[0..50]</td><td>0..1</td><td>Optional. Serial number of the EV inverter.ISO 15118-20: DER_BPT_AC_CPDReqEnergyTransferModeType: EVInverterSerialNumber</td></tr><tr><td>evInverterSwVersion</td><td>string[0..50]</td><td>0..1</td><td>Optional. Software version of EV inverter.ISO 15118-20: DER_BPT_AC_CPDReqEnergyTransferModeType: EVInverterSwVersion</td></tr><tr><td>evInverterHwVersion</td><td>string[0..50]</td><td>0..1</td><td>Optional. Hardware version of EV inverter.ISO 15118-20: DER_BPT_AC_CPDReqEnergyTransferModeType: EVInverterHwVersion</td></tr><tr><td>evIslandingDetectionMethod d</td><td>IslandingDetectionEnumType</td><td>0..*</td><td>Optional. Type of islanding detection method. Only mandatory when islanding detection is required at the site, as set in the ISO 15118 Service Details configuration.ISO 15118-20: DER_BPT_AC_CPDReqEnergyTransferModeType: EVIslandingDetectionMethod</td></tr><tr><td>evIslandingTripTime</td><td>decimal</td><td>0..1</td><td>Optional. Time after which EV will trip if an island has been detected.ISO 15118-20: DER_BPT_AC_CPDReqEnergyTransferModeType: EVIslandingTripTime</td></tr><tr><td>evMaximumLevel1DCInjection</td><td>decimal</td><td>0..1</td><td>Optional. Maximum injected DC current allowed at level 1 charging.ISO 15118-20: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumLevel1DCInjection</td></tr><tr><td>evDurationLevel1DCInjection</td><td>decimal</td><td>0..1</td><td>Optional. Maximum allowed duration of DC injection at level 1 charging.ISO 15118-20: DER_BPT_AC_CPDReqEnergyTransferModeType: EVDurationLevel1DCInjection</td></tr><tr><td>evMaximumLevel2DInjecti
+on</td><td>decimal</td><td>0..1</td><td>Optional. Maximum injected DC current allowed at level 2 charging.
+ISO 15118-20:
+DER_BPT_AC_CPDReqEnergyTransferModeType:
+EVMaximumLevel2DInjection</td></tr><tr><td>evDurationLevel2DInjectio
+n</td><td>decimal</td><td>0..1</td><td>Optional. Maximum allowed duration of DC injection at level 2 charging.
+ISO 15118-20:
+DER_BPT_AC_CPDReqEnergyTransferModeType:
+EVDurationLevel2DInjection</td></tr><tr><td>evReactiveSusceptance</td><td>decimal</td><td>0..1</td><td>Optional. Measure of the susceptibility of the circuit to reactance, in Siemens (S).
+ISO 15118-20:
+DER_BPT_AC_CPDReqEnergyTransferModeType:
+EVReactiveSusceptance</td></tr><tr><td>evSessionTotalDischargeEn
+ergyAvailable</td><td>decimal</td><td>0..1</td><td>Optional. Total energy value, in Wh, that EV is allowed to provide during the entire V2G session. The value is independent of the V2X Cycling area. Once this value reaches the value of 0, the EV may block any attempt to discharge in order to protect the battery health. ISO 15118-20:
+DER_BPT_AC_CPDReqEnergyTransferModeType:
+EVSessionTotalDischargeEnergyAvailable</td></tr></table>
+
+# 2.35. DERCurve类型的
+
+Class
+
+DERCurveGetType is used by: ReportDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. Id of DER curve</td></tr><tr><td>curveType</td><td>DERControlEnumType</td><td>1..1</td><td>Required. Type of DER curve</td></tr><tr><td>isDefault</td><td>boolean</td><td>1..1</td><td>Required. True if this is a default curve</td></tr><tr><td>isSuperseded</td><td>boolean</td><td>1..1</td><td>Required. True if this setting is superseded by a higher priority setting (i.e. lower value of priority)</td></tr><tr><td>curve</td><td>DERCurveType</td><td>1..1</td><td>Required. Parameters defining the DER curve</td></tr></table>
+
+# 2.36. DERCurvePointsType
+
+Class
+
+DERCurvePointsType is used by: Common:DERCurveType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>x</td><td>decimal</td><td>1..1</td><td>Required. The data value of the X-axis (independent) variable, depending on the curve type.</td></tr><tr><td>y</td><td>decimal</td><td>1..1</td><td>Required. The data value of the Y-axis (dependent) variable, depending on the DERUnitEnumType of the curve. If y is power factor, then a positive value means DER is absorbing reactive power (under-excited), a negative value when DER is injecting reactive power (over-excited).</td></tr></table>
+
+# 2.37. DERCurveType
+
+Class
+
+DERCurveType is used by: Common:DERCurveGetType, Common:LimitMaxDischargeType, SetDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>priority</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Priority of curve (0=highest)</td></tr><tr><td>yUnit</td><td>DERUnitEnumType</td><td>1..1</td><td>Required. Unit of the Y-axis of DER curve</td></tr><tr><td>responseTime</td><td>decimal</td><td>0..1</td><td>Optional. Open loop response time, the time to ramp up to 90% of the new target in response to the change in voltage, in seconds. A value of 0 is used to mean no limit. When not present, the device should follow its default behavior.</td></tr><tr><td>startTime</td><td>dateTime</td><td>0..1</td><td>Optional. Point in time when this curve will become activated. Only absent when default is true.</td></tr><tr><td>duration</td><td>decimal</td><td>0..1</td><td>Optional. Duration in seconds that this curve will be active. Only absent when default is true.</td></tr><tr><td>hysteresis</td><td>HysteresisType</td><td>0..1</td><td>Optional. Hysteresis parameters for curve.</td></tr><tr><td>voltageParams</td><td>VoltageParamsType</td><td>0..1</td><td>Optional. Additional parameters for voltage curves.</td></tr><tr><td>reactivePowerParams</td><td>ReactivePowerParamsType</td><td>0..1</td><td>Optional. Additional parameters for VoltVar curve.</td></tr><tr><td>curveData</td><td>DERCurvePointsType</td><td>1..10</td><td>Required. Coordinates of the DER curve. X-axis is determined by curveType. Y-axis is determined by yUnit.</td></tr></table>
+
+# 2.38. EnterServiceGetType
+
+Class
+
+EnterServiceGetType is used by: ReportDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. Id of setting</td></tr><tr><td>enterService</td><td>EnterServiceType</td><td>1..1</td><td>Required. Enter Service settings</td></tr></table>
+
+# 2.39. EnterServiceType
+
+Class
+
+EnterServiceType is used by: Common:EnterServiceGetType, SetDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>priority</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Priority of setting (0=highest)</td></tr><tr><td>highVoltage</td><td>decimal</td><td>1..1</td><td>Required. Enter service voltage high</td></tr><tr><td>lowVoltage</td><td>decimal</td><td>1..1</td><td>Required. Enter service voltage low</td></tr><tr><td>highFreq</td><td>decimal</td><td>1..1</td><td>Required. Enter service frequency high</td></tr><tr><td>lowFreq</td><td>decimal</td><td>1..1</td><td>Required. Enter service frequency low</td></tr><tr><td>delay</td><td>decimal</td><td>0..1</td><td>Optional. Enter service delay</td></tr><tr><td>randomDelay</td><td>decimal</td><td>0..1</td><td>Optional. Enter service randomized delay</td></tr><tr><td>rampRate</td><td>decimal</td><td>0..1</td><td>Optional. Enter service ramp rate in seconds</td></tr></table>
+
+# 2.40. EVAbsolutePriceScheduleEntryType
+
+Class
+
+(2.1) An entry in price schedule over time for which EV is willing to discharge.
+
+EVAbsolutePriceScheduleEntryType is used by: Common:EVAbsolutePriceScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>duration</td><td>integer</td><td>1..1</td><td>Required. The amount of seconds of this entry.</td></tr><tr><td>evPriceRule</td><td>EVPpriceRuleType</td><td>1..8</td><td>Required. A set of pricing rules for energy costs.</td></tr></table>
+
+# 2.41. EVAbsolutePriceScheduleType
+
+Class
+
+# (2.1) Price schedule of EV energy offer.
+
+EVAbsolutePriceScheduleType is used by: Common:EVEnergyOfferType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>timeAnchor</td><td>dateTime</td><td>1..1</td><td>Required. Starting point in time of the EVEnergyOffer.</td></tr><tr><td>currency</td><td>string[0..3]</td><td>1..1</td><td>Required. Currency code according to ISO 4217.</td></tr><tr><td>priceAlgorithm</td><td>string[0..2000]</td><td>1..1</td><td>Required. ISO 15118-20 URN of price algorithm: Power, PeakPower, StackedEnergy.</td></tr><tr><td>evAbsolutePriceScheduleE ntries</td><td>EVAbsolutePriceScheduleEntryTyp e</td><td>1..102 4</td><td>Required. Schedule of prices for which EV is willing to discharge.</td></tr></table>
+
+# 2.42. EVEnergyOfferType
+
+Class
+
+(2.1) A schedule of the energy amount over time that EV is willing to discharge. A negative value indicates the willingness to discharge under specific conditions, a positive value indicates that the EV currently is not able to offer energy to discharge.
+
+EVEnergyOfferType is used by: Common:ChargingNeedsType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>evPowerSchedule</td><td>EVPowerScheduleType</td><td>1..1</td><td>Required. Power schedule offered for discharging.</td></tr><tr><td>evAbsolutePriceSchedule</td><td>EVAbsolutePriceScheduleType</td><td>0..1</td><td>Optional. Price schedule for which EV is willing to discharge.</td></tr></table>
+
+# 2.43.EventDataType
+
+Class
+
+Class to report an event notification for a component-variable.
+
+EventDataType is used by: NotifyRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>eventId</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Identifies the event. This field can be referred to as a cause by other events.</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp of the moment the report was generated.</td></tr><tr><td>trigger</td><td>EventTriggerEnumType</td><td>1..1</td><td>Required. Type of trigger for this event, e.g. exceeding a threshold value.</td></tr><tr><td>cause</td><td>integer, 0 < = val</td><td>0..1</td><td>Optional. Refers to the Id of an event that is considered to be the cause for this event.</td></tr><tr><td>actualValue</td><td>string[0..2500]</td><td>1..1</td><td>Required. Actual value (attributeType Actual) of the variable.The Configuration Variable Reporting研究成果 can be used to limit GetVariableResult(attributeValue,VariableAttribute.value and DataActualValue. The max size of these values will always remain equal.</td></tr><tr><td>techCode</td><td>string[0..50]</td><td>0..1</td><td>Optional. Technical (error) code as reported by component.</td></tr><tr><td>techInfo</td><td>string[0..500]</td><td>0..1</td><td>Optional. Technical detail information as reported by component.</td></tr><tr><td>cleared</td><td>boolean</td><td>0..1</td><td>Optional. Cleared is set to true to report the clearing of a monitored situation, i.e. a 'return to normal'.</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. If an event notification is linked to a specific transaction, this field can be used to specify its transactionId.</td></tr><tr><td>variableMonitoringId</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. Identifies the VariableMonitoring which triggered the event.</td></tr><tr><td>eventNotificationType</td><td>EventNotificationEnumType</td><td>1..1</td><td>Required. Specifies the event notification type of the message.</td></tr><tr><td>severity</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. (2.1) Severity associated with the monitor in variableMonitoringId or with the hardwired notification.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which event is notified.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which event is notified.</td></tr></table>
+
+# 2.44. EVPowerScheduleEntryType
+
+Class
+
+(2.1) An entry in schedule of the energy amount over time that EV is willing to discharge. A negative value indicates the willingness to discharge under specific conditions, a positive value indicates that the EV currently is not able to offer energy to discharge.
+
+EVPowerScheduleEntryType is used by: Common:EVPowerScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>duration</td><td>integer</td><td>1..1</td><td>Required. The duration of this entry.</td></tr><tr><td>power</td><td>decimal</td><td>1..1</td><td>Required. Defines maximum amount of power for the duration of this EVPowerScheduleEntry to be discharged from the EV battery through EVSE power outlet. Negative values are used for discharging.</td></tr></table>
+
+# 2.45. EVPowerScheduleType
+
+Class
+
+(2.1) Schedule of EV energy offer.
+
+EVPowerScheduleType is used by: Common:EVEnergyOfferType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>timeAnchor</td><td>dateTime</td><td>1..1</td><td>Required. The time that defines the starting point for the EVEnergyOffer.</td></tr><tr><td>evPowerScheduleEntries</td><td>EVPowerScheduleEntryType</td><td>1..1024</td><td>Required. List of EVEpowerScheduleEntries.</td></tr></table>
+
+# 2.46. EVPriceRuleType
+
+Class
+
+(2.1) An entry in price schedule over time for which EV is willing to discharge.
+
+EVPPriceRuleType is used by: Common:EVAbsolutePriceScheduleEntryType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>energyFee</td><td>decimal</td><td>1..1</td><td>Required. Cost per kWh.</td></tr><tr><td>powerRangeStart</td><td>decimal</td><td>1..1</td><td>Required. The EnergyFee applies between this value and the value of the PowerRangeStart of the subsequent EVPriceRule. If the power is below this value, the EnergyFee of the previous EVPriceRule applies. Negative values are used for discharging.</td></tr></table>
+
+# 2.47. EVSEType
+
+Class
+
+Electric Vehicle Supply Equipment
+
+EVSEType is used by: Common:ComponentType, TriggerMessageRequest, ChangeAvailabilityRequest, TransactionEventRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. EVSE Identifier. This contains a number (>0) designating an EVSE of the Charging Station.</td></tr><tr><td>connectorId</td><td>integer, 0 < = val</td><td>0..1</td><td>Optional. An id to designate a specific connector (on an EVSE) by connector index number.</td></tr></table>
+
+# 2.48. FirmwareType
+
+Class
+
+Represents a copy of the firmware that can be loaded/updated on the Charging Station.
+
+FirmwareType is used by: UpdateFirmwareRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>location</td><td>string[0..2000]</td><td>1..1</td><td>Required. URI defining the origin of the firmware.</td></tr><tr><td>retrieveDateTime</td><td>dateTime</td><td>1..1</td><td>Required. Date and time at which the firmware shall be retrieved.</td></tr><tr><td>installDateTime</td><td>dateTime</td><td>0..1</td><td>Optional. Date and time at which the firmware shall be installed.</td></tr><tr><td>signingCertificate</td><td>string[0..5500]</td><td>0..1</td><td>Optional. Certificate with which the firmware was signed. PEM encoded X.509 certificate.</td></tr><tr><td>signature</td><td>string[0..800]</td><td>0..1</td><td>Optional. Base64 encoded firmware signature.</td></tr></table>
+
+# 2.49. FixedPFGetType
+
+Class
+
+FixedPFG族自治州 is used by: ReportDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. Id of setting.</td></tr><tr><td>isDefault</td><td>boolean</td><td>1..1</td><td>Required. True if setting is a default control.</td></tr><tr><td>isSuperseded</td><td>boolean</td><td>1..1</td><td>Required. True if this setting is superseded by a lower priority setting.</td></tr><tr><td>fixedPF</td><td>FixedPFType</td><td>1..1</td><td>Required. FixedPF for AbsorbW or InjectW</td></tr></table>
+
+# 2.50. FixedPFType
+
+Class
+
+FixedPFType is used by: Common:FixedPFGetType, SetDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>priority</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Priority of setting (0=highest)</td></tr><tr><td>displacement</td><td>decimal</td><td>1..1</td><td>Required. Power factor, cos phi), as value between 0..1.</td></tr><tr><td>excitation</td><td>boolean</td><td>1..1</td><td>Required. True when absorbing reactive power (under-excited), false when injecting reactive power (over-excited).</td></tr><tr><td>startTime</td><td>dateTime</td><td>0..1</td><td>Optional. Time when this setting becomes active</td></tr><tr><td>duration</td><td>decimal</td><td>0..1</td><td>Optional. Duration in seconds that this setting is active.</td></tr></table>
+
+# 2.51. FixedVar类型的
+
+Class
+
+FixedVarGetType is used by: ReportDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. Id of setting</td></tr><tr><td>isDefault</td><td>boolean</td><td>1..1</td><td>Required. True if setting is a default control.</td></tr><tr><td>isSuperseded</td><td>boolean</td><td>1..1</td><td>Required. True if this setting is superseded by a lower priority setting</td></tr><tr><td>fixedVar</td><td>FixedVarType</td><td>1..1</td><td>Required. Fixed Var setpoint</td></tr></table>
+
+# 2.52. FixedVarType
+
+Class
+
+FixedVarType is used by: Common:FixedVarGetType, SetDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>priority</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Priority of setting (0=highest)</td></tr><tr><td>setpoint</td><td>decimal</td><td>1..1</td><td>Required. The value specifies a target var output interpreted as a signed percentage (-100 to 100). A negative value refers to charging, whereas a positive one refers to discharging. The value type is determined by the unit field.</td></tr><tr><td>unit</td><td>DERUnitEnumType</td><td>1..1</td><td>Required. Unit of the setpoint.</td></tr><tr><td>startTime</td><td>dateTime</td><td>0..1</td><td>Optional. Time when this setting becomes active.</td></tr><tr><td>duration</td><td>decimal</td><td>0..1</td><td>Optional. Duration in seconds that this setting is active.</td></tr></table>
+
+# 2.53. FreqDroop类型的
+
+Class
+
+FreqDroopGetType is used by: ReportDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. Id of setting</td></tr><tr><td>isDefault</td><td>boolean</td><td>1..1</td><td>Required. True if setting is a default control.</td></tr><tr><td>isSuperseded</td><td>boolean</td><td>1..1</td><td>Required. True if this setting is superseded by a higher priority setting (i.e. lower value of priority)</td></tr><tr><td>freqDroop</td><td>FreqDroopType</td><td>1..1</td><td>Required. FreqDroop parameters</td></tr></table>
+
+# 2.54. FreqDroopType
+
+Class
+
+FreqDroopType is used by: Common:FreqDroopGetType, SetDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>priority</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Priority of setting (0=highest)</td></tr><tr><td>overFreq</td><td>decimal</td><td>1..1</td><td>Required. Over-frequency start of droop</td></tr><tr><td>underFreq</td><td>decimal</td><td>1..1</td><td>Required. Under-frequency start of droop</td></tr><tr><td>overDroop</td><td>decimal</td><td>1..1</td><td>Required. Over-frequency droop per unit, oFDroop</td></tr><tr><td>underDroop</td><td>decimal</td><td>1..1</td><td>Required. Under-frequency droop per unit, uFDroop</td></tr><tr><td>responseTime</td><td>decimal</td><td>1..1</td><td>Required. Open loop response time in seconds</td></tr><tr><td>startTime</td><td>dateTime</td><td>0..1</td><td>Optional. Time when this setting becomes active</td></tr><tr><td>duration</td><td>decimal</td><td>0..1</td><td>Optional. Duration in seconds that this setting is active</td></tr></table>
+
+# 2.55. GetVariableDataType
+
+Class
+
+Class to hold parameters for GetVariables request.
+
+GetVariableDataType is used by: GetVariablesRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>attributeType</td><td>AttributeEnumType</td><td>0..1</td><td>Optional. Attribute type for which value is requested. When absent, default Actual is assumed.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which the Variable is requested.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which the attribute value is requested.</td></tr></table>
+
+# 2.56. GetVariableResultType
+
+Class
+
+Class to hold results of GetVariables request.
+
+GetVariableResultType is used by: GetVariablesResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>attributeStatus</td><td>GetVariableStatusEnumType</td><td>1..1</td><td>Required.</td></tr><tr><td>attributeType</td><td>AttributeEnumType</td><td>0..1</td><td>Optional.</td></tr><tr><td>attributeValue</td><td>string[0..2500]</td><td>0..1</td><td>Optional. Value of requested attribute type of component-variable. This field can only be empty when the given status is NOT accepted.The Configuration Variable ReportingValueSize can be used to limit GetVariableResult(attributeValue,VariableAttribute.value and EventDataactualValue. The max size of these values will always remain equal.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which the Variable is requested.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which the attribute value is requested.</td></tr><tr><td>attributeStatusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed attribute status information.</td></tr></table>
+
+# 2.57. Gradient类型的
+
+Class
+
+Gradient类型的is used by: ReportDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. Id of setting</td></tr><tr><td>gradient</td><td>GradientType</td><td>1..1</td><td>Required. Gradient setting</td></tr></table>
+
+# 2.58. GradientType
+
+Class
+
+GradientType is used by: Common:GradientGetType, SetDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>priority</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Id of setting</td></tr><tr><td>gradient</td><td>decimal</td><td>1..1</td><td>Required. Default ramp rate in seconds (0 if not applicable)</td></tr><tr><td>softGradient</td><td>decimal</td><td>1..1</td><td>Required. Soft-start ramp rate in seconds (0 if not applicable)</td></tr></table>
+
+# 2.59. HysteresisType
+
+Class
+
+HysteresisType is used by: Common:DERCurveType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>hysteresisHigh</td><td>decimal</td><td>0..1</td><td>Optional. High value for return to normal operation after a grid event, in absolute value. This value adopts the same unit as defined by yUnit</td></tr><tr><td>hysteresisLow</td><td>decimal</td><td>0..1</td><td>Optional. Low value for return to normal operation after a grid event, in absolute value. This value adopts the same unit as defined by yUnit</td></tr><tr><td>hysteresisDelay</td><td>decimal</td><td>0..1</td><td>Optional. Delay in seconds, once grid parameter within HysteresisLow and HysteresisHigh, for the EV to return to normal operation after a grid event.</td></tr><tr><td>hysteresisGradient</td><td>decimal</td><td>0..1</td><td>Optional. Set default rate of change (ramp rate %/s) for the EV to return to normal operation after a grid event</td></tr></table>
+
+# 2.60. IdTokenInfoType
+
+Class
+
+Contains status information about an identifier. It is advised to not stop charging for a token that expires during charging, as ExpiryDate is only used for caching purposes. If ExpiryDate is not given, the status has no end date.
+
+IdTokenInfoType is used by: Common:AuthorizationData,authorizeResponse,TransactionEventResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>status</td><td>AuthorizationStatusEnumType</td><td>1..1</td><td>Required. Current status of the ID Token.</td></tr><tr><td>cacheExpiryDateTime</td><td>dateTime</td><td>0..1</td><td>Optional. Date and Time after which the token must be considered invalid.</td></tr><tr><td>chargingPriority</td><td>integer</td><td>0..1</td><td>Optional. Priority from a business point of view. Default priority is 0, The range is from -9 to 9. Higher values indicate a higher priority. The chargingPriority in TransactionResponse overrules this one.</td></tr><tr><td>language1</td><td>string[0..8]</td><td>0..1</td><td>Optional. Preferred user interface language of identifier user. Contains a language code as defined in [RFC5646].</td></tr><tr><td>language2</td><td>string[0..8]</td><td>0..1</td><td>Optional. Second preferred user interface language of identifier user. Don't use when language1 is omitted, has to be different from language1. Contains a language code as defined in [RFC5646].</td></tr><tr><td>evseld</td><td>integer, 0 < = val</td><td>0..*</td><td>Optional. Only used when the IdToken is only valid for one or more specific EVSEs, not for the entire Charging Station.</td></tr><tr><td>groupldToken</td><td>IdTokenType</td><td>0..1</td><td>Optional. This contains the group identifier.</td></tr><tr><td>personalMessage</td><td>MessageContentType</td><td>0..1</td><td>Optional. Personal message that can be shown to the EV Driver and can be used for tariff information, user greetings etc.</td></tr></table>
+
+# 2.61. IdTokenType
+
+Class
+
+Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.
+
+IdTokenType is used by: Common:AuthorizationData, Common:IdTokenInfoType, RequestStartTransactionRequest,authorizeRequest, TransactionEventRequest, ReserveNowRequest, CustomerInformationRequest, BatterySwapRequest, RequestBatterySwapRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>idToken</td><td>identifierString[0..255]</td><td>1..1</td><td>Required. (2.1) IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.</td></tr><tr><td>type</td><td>string[0..20]</td><td>1..1</td><td>Required. (2.1) Enumeration of possible idToken types.Values defined in Appendix as IdTokenEnumStringType.</td></tr><tr><td>additionalInfo</td><td>AdditionalInfoType</td><td>0..*</td><td>Optional. AdditionalInfo can be used to send extra information which can be validated by the CSMS in addition to the regular authorization with IdToken.AdditionalInfo contains one or more custom types, which need to be agreed upon by all parties involved. When AdditionalInfo is NOT implemented or a not supported AdditionalInfo.type is used, the CSMS/Charging Station MAY ignore the AdditionalInfo.</td></tr></table>
+
+# 2.62. LimitAtSoType
+
+Class
+
+LimitAtSoType is used by: Common:ChargingScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>soc</td><td>integer, 0 <= val <= 100</td><td>1..1</td><td>Required. The SoC value beyond which the charging rate limit should be applied.</td></tr><tr><td>limit</td><td>decimal</td><td>1..1</td><td>Required. Charging rate limit beyond the SoC value. The unit is defined by chargingSchedule.chargingRateUnit.</td></tr></table>
+
+# 2.63. LimitMaxDischarge类型的
+
+Class
+
+LimitMaxDischargeGetType is used by: ReportDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. Id of setting</td></tr><tr><td>isDefault</td><td>boolean</td><td>1..1</td><td>Required. True if setting is a default control.</td></tr><tr><td>isSuperseded</td><td>boolean</td><td>1..1</td><td>Required. True if this setting is superseded by a higher priority setting (i.e. lower value of priority)</td></tr><tr><td>limitMaxDischarge</td><td>LimitMaxDischargeType</td><td>1..1</td><td>Required. Maximum discharge power as percentage or rated capability</td></tr></table>
+
+# 2.64. LimitMaxDischargeType
+
+Class
+
+LimitMaxDischargeType is used by: Common:LimitMaxDischargeGetType, SetDERControlRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>priority</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Priority of setting (0=highest)</td></tr><tr><td>pctMaxDischargePower</td><td>decimal</td><td>0..1</td><td>Optional. Only for PowerMonitoring.
+The value specifies a percentage (0 to 100) of the rated maximum discharge power of EV. The PowerMonitoring curve becomes active when power exceeds this percentage.</td></tr><tr><td>startTime</td><td>dateTime</td><td>0..1</td><td>Optional. Time when this setting becomes active</td></tr><tr><td>duration</td><td>decimal</td><td>0..1</td><td>Optional. Duration in seconds that this setting is active</td></tr><tr><td>powerMonitoringMustTrip</td><td>DERCurveType</td><td>0..1</td><td>Optional. The curve is an interpolation of data points where the x-axis values are time in seconds and the y-axis values refer to the percentage value of the rated EVMaximumDischargePower, reported in the ChargeParameterDiscoveryRequest message. The value lies between 0 and 100. The curve is activated when the power value measured via the ExternalMeter value reported in the ChargeLoopRes is higher than the pctMaxDischargePower defined above. If the power does not stay within the defined curve for the respective time period, the EV must trip.</td></tr></table>
+
+# 2.65. LogParametersType
+
+Class
+
+Generic class for the configuration of logging entries.
+
+LogParametersType is used by: GetLogRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>remoteLocation</td><td>string[0..2000]</td><td>1..1</td><td>Required. The URL of the location at the remote system where the log should be stored.</td></tr><tr><td>oldestTimestamp</td><td>dateTime</td><td>0..1</td><td>Optional. This contains the date and time of the oldest logging information to include in the diagnostics.</td></tr><tr><td>latestTimestamp</td><td>dateTime</td><td>0..1</td><td>Optional. This contains the date and time of the latest logging information to include in the diagnostics.</td></tr></table>
+
+# 2.66. MessageContentType
+
+Class
+
+Contains message details, for a message to be displayed on a Charging Station.
+
+MessageContentType is used by: Common:IdTokenInfoType, Common:MessageInfoType, Common:TariffType, TransactionEventResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>format</td><td>MessageFormatEnumType</td><td>1..1</td><td>Required. Format of the message.</td></tr><tr><td>language</td><td>string[0..8]</td><td>0..1</td><td>Optional. Message language identifier. Contains a language code as defined in [RFC5646].</td></tr><tr><td>content</td><td>string[0..1024]</td><td>1..1</td><td>Required. (2.1) Required. Message contents. Maximum length supported by Charging Station is given in OCPPCommCtrl.FieldLength["MessageContentType.cont ent"]. Maximum length defaults to 1024.</td></tr></table>
+
+# 2.67. MessagingInfoType
+
+Class
+
+Contains message details, for a message to be displayed on a Charging Station.
+
+MessageInfoType is used by: SetDisplayMessageRequest, NotifyDisplayMessagesRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Unique id within an exchange context. It is defined within the OCPP context as a positive Integer value (greater or equal to zero).</td></tr><tr><td>priority</td><td>MessagePriorityEnumType</td><td>1..1</td><td>Required. With what priority should this message be shown</td></tr><tr><td>state</td><td>MessageStateEnumType</td><td>0..1</td><td>Optional. During what state should this message be shown. When omitted this message should be shown in any state of the Charging Station.</td></tr><tr><td>startTime</td><td>dateTime</td><td>0..1</td><td>Optional. From what date-time should this message be shown. If omitted: directly.</td></tr><tr><td>endTime</td><td>dateTime</td><td>0..1</td><td>Optional. Until what date-time should this message be shown, after this date/time this message SHALL be removed.</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>0..1</td><td>Optional. During which transaction shall this message be shown. Message SHALL be removed by the Charging Station after transaction has ended.</td></tr><tr><td>message</td><td>MessageContentType</td><td>1..1</td><td>Required. Contains message details for the message to be displayed on a Charging Station.</td></tr><tr><td>display</td><td>ComponentType</td><td>0..1</td><td>Optional. When a Charging Station has multiple Displays, this field can be used to define to which Display this message belongs.</td></tr><tr><td>messageExtra</td><td>MessageContentType</td><td>0..4</td><td>Optional. (2.1) Contains message details for extra languages to be displayed on a Charging Station.</td></tr></table>
+
+# 2.68. MeterValueType
+
+Class
+
+Collection of one or more sampled values in MeterValuesRequest and TransactionEvent. All sampled values in a MeterValue are sampled at the same point in time.
+
+MeterValueType is used by: MeterValuesRequest, TransactionEventRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>timestamp</td><td>dateTime</td><td>1..1</td><td>Required. Timestamp for measured value(s).</td></tr><tr><td>sampledValue</td><td>SampledValueType</td><td>1.*</td><td>Required. One or more measured values</td></tr></table>
+
+# 2.69. ModemType
+
+Class
+
+Defines parameters required for initiating and maintaining wireless communication with other devices.
+
+ModemType is used by: BootNotificationRequest.CchargingStationType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>iccid</td><td>identifierString[0..20]</td><td>0..1</td><td>Optional. This contains the ICCID of the modem's SIM card.</td></tr><tr><td>imsi</td><td>identifierString[0..20]</td><td>0..1</td><td>Optional. This contains the IMSI of the modem's SIM card.</td></tr></table>
+
+# 2.70. MonitoringDataType
+
+Class
+
+Class to hold parameters of SetVariableMonitoring request.
+
+MonitoringDataType is used by: NotifyMonitoringRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which monitoring report was requested.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which monitoring report was requested.</td></tr><tr><td>variableMonitoring</td><td>VariableMonitoringType</td><td>1..*</td><td>Required. List of monitors for this Component-Variable pair.</td></tr></table>
+
+# 2.71. NetworkConnectionProfileType
+
+Class
+
+The NetworkConnectionProfile defines the functional and technical parameters of a communication link.
+
+NetworkConnectionProfileType is used by: SetNetworkProfileRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>ocppVersion</td><td>OCPPVersionEnumType</td><td>0..1</td><td>Optional. (2.1) This field is ignored, since the OCPP version to use is determined during the websocket handshake. The field is only kept for backwards compatibility with the OCPP 2.0.1 JSON schema.</td></tr><tr><td>ocppInterface</td><td>OCPPInterfaceEnumType</td><td>1..1</td><td>Required. Applicable Network Interface. Charging Station is allowed to use a different network interface to connect if the given one does not work.</td></tr><tr><td>ocppTransport</td><td>OCPPTransportEnumType</td><td>1..1</td><td>Required. Defines the transport protocol (e.g. SOAP or JSON). Note: SOAP is not supported in OCPP 2.x, but is supported by earlier versions of OCPP.</td></tr><tr><td>messageTimeout</td><td>integer</td><td>1..1</td><td>Required. Duration in seconds before a message send by the Charging Station via this network connection times-out. The best setting depends on the underlying network and response times of the CSMS. If you are looking for a some guideline: use 30 seconds as a starting point.</td></tr><tr><td>ocppCsmsUrl</td><td>string[0..2000]</td><td>1..1</td><td>Required. URL of the CSMS(s) that this Charging Station communicates with, without the Charging Station identity part. The SecurityCtrl.Identity field is appended to ocppCsmsUrl to provide the full websocket URL.</td></tr><tr><td>securityProfile</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. This field specifies the security profile used when connecting to the CSMS with this NetworkConnectionProfile.</td></tr><tr><td>identity</td><td>string[0..48]</td><td>0..1</td><td>Optional. (2.1) Charging Station identity to be used as the basic authentication username.</td></tr><tr><td>basicAuthPassword</td><td>string[0..64]</td><td>0..1</td><td>Optional. (2.1) BasicAuthPassword to use for security profile 1 or 2.</td></tr><tr><td>vpn</td><td>VPNType</td><td>0..1</td><td>Optional. Settings to be used to set up the VPN connection</td></tr><tr><td>apn</td><td>APNType</td><td>0..1</td><td>Optional. Collection of configuration data needed to make a data-connection over a cellular network.</td></tr></table>
+
+# 2.72. OCSPRequestDataType
+
+Class
+
+Information about a certificate for an OCSP check.
+
+OCSPRequestDataType is used by: InvalidateRequest, GetCertificateStatusRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>hashAlgorithm</td><td>HashAlgorithmEnumType</td><td>1..1</td><td>Required. Used algorithms for the hashes provided.</td></tr><tr><td>issuerNameHash</td><td>identifierString[0..128]</td><td>1..1</td><td>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.</td></tr><tr><td>issuerKeyHash</td><td>string[0..128]</td><td>1..1</td><td>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.</td></tr><tr><td>serialNumber</td><td>identifierString[0..40]</td><td>1..1</td><td>Required. The string representation of the hexadecimal value of the serial number without the prefix "0x" and without leading zeroes.</td></tr><tr><td>responderURL</td><td>string[0..2000]</td><td>1..1</td><td>Required. This contains the responder URL (Case insensitive).</td></tr></table>
+
+# 2.73. OverstayRuleelistType
+
+Class
+
+Part of ISO 15118-20 price schedule.
+
+OverstayRuleelistType is used by: Common:AbsolutePriceScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>overstayTimeThreshold</td><td>integer</td><td>0..1</td><td>Optional. Time till overstay is applied in seconds.</td></tr><tr><td>overstayPowerThreshold</td><td>RationalNUMBERType</td><td>0..1</td><td>Optional. Power threshold in W at which the overstay applies.</td></tr><tr><td>overstayRule</td><td>OverstayRuleType</td><td>1..5</td><td>Required. Overstay rules that will be applied.</td></tr></table>
+
+# 2.74. OverstayRuleType
+
+Class
+
+Part of ISO 15118-20 price schedule.
+
+OverstayRuleType is used by: Common:OverstayRuleelistType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>overstayRuleDescription</td><td>string[0..32]</td><td>0..1</td><td>Optional. Human readable string to identify the overstay rule.</td></tr><tr><td>startTime</td><td>integer</td><td>1..1</td><td>Required. Time in seconds after trigger of the parent Overstay Rules for this particular fee to apply.</td></tr><tr><td>overstayFeePeriod</td><td>integer</td><td>1..1</td><td>Required. Time till overstay will be reapplied</td></tr><tr><td>overstayFee</td><td>RationalNUMBERType</td><td>1..1</td><td>Required. Fee that applies to this overstay.</td></tr></table>
+
+# 2.75. PeriodicEventStreamParamsType
+
+Class
+
+PeriodicEventStreamParamsType is used by: Common:ConstantStreamDataType, AdjustPeriodicEventStreamRequest, SetVariableMonitoringRequest.SetMonitoringDataType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>interval</td><td>integer, 0 < = val</td><td>0..1</td><td>Optional. Time in seconds after which stream data is sent.</td></tr><tr><td>values</td><td>integer, 0 < = val</td><td>0..1</td><td>Optional. Number of items to be sent together in stream.</td></tr></table>
+
+# 2.76. PriceLevelScheduleEntryType
+
+Class
+
+Part of ISO 15118-20 price schedule.
+
+PriceLevelScheduleEntryType is used by: Common:PriceLevelScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>duration</td><td>integer</td><td>1..1</td><td>Required. The amount of seconds that define the duration of this given PriceLevelScheduleEntry.</td></tr><tr><td>priceLevel</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Defines the price level of this PriceLevelScheduleEntry (referring to NumberOfPriceLevels). Small values for the PriceLevel represent a cheaper PriceLevelScheduleEntry. Large values for the PriceLevel represent a more expensive PriceLevelScheduleEntry.</td></tr></table>
+
+# 2.77. PriceLevelScheduleType
+
+Class
+
+The PriceLevelScheduleType is modeled after the same type that is defined in ISO 15118-20, such that if it is supplied by an EMSP as a signed EXI message, the conversion from EXI to JSON (in OCPP) and back to EXI (for ISO 15118-20) does not change the digest and therefore does not invalidate the signature.
+
+PriceLevelScheduleType is used by: Common:ChargingScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>timeAnchor</td><td>dateTime</td><td>1..1</td><td>Required. Starting point of this price schedule.</td></tr><tr><td>priceScheduleId</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. Unique ID of this price schedule.</td></tr><tr><td>priceScheduleDescription</td><td>string[0..32]</td><td>0..1</td><td>Optional. Description of the price schedule.</td></tr><tr><td>(numberOfPriceLevels</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. Defines the overall number of distinct price level elements used across all PriceLevelSchedules.</td></tr><tr><td>priceLevelScheduleEntries</td><td>PriceLevelScheduleEntryType</td><td>1..100</td><td>Required. List of entries of the schedule.</td></tr></table>
+
+# 2.78. PriceRuleStackType
+
+Class
+
+Part of ISO 15118-20 price schedule.
+
+PriceRuleStackType is used by: Common:AbsolutePriceScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>duration</td><td>integer</td><td>1..1</td><td>Required. Duration of the stack of price rules. he amount of seconds that define the duration of the given PriceRule(s).</td></tr><tr><td>priceRule</td><td>PriceRuleType</td><td>1..8</td><td>Required. Contains the price rules.</td></tr></table>
+
+# 2.79. PriceRuleType
+
+Class
+
+Part of ISO 15118-20 price schedule.
+
+PriceRuleType is used by: Common:PriceRuleSTACKType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>parkingFeePeriod</td><td>integer</td><td>0..1</td><td>Optional. The duration of the parking fee period (in seconds). When the time enters into a ParkingFeePeriod, the ParkingFee will apply to the session..</td></tr><tr><td>carbonDioxideEmission</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. Number of grams of CO2 per kWh.</td></tr><tr><td>renewableGenerationPercentage</td><td>integer, 0 <= val <= 100</td><td>0..1</td><td>Optional. Percentage of the power that is created by renewable resources.</td></tr><tr><td>energyFee</td><td>RationalNumberType</td><td>1..1</td><td>Required. Cost per kWh. Use zero for free energy.</td></tr><tr><td>parkingFee</td><td>RationalNumberType</td><td>0..1</td><td>Optional. Optional. Cost of parking. Mandatory whenever a parking fee applies.</td></tr><tr><td>powerRangeStart</td><td>RationalNumberType</td><td>1..1</td><td>Required. For values 0 and above, this is the power level above which this price rule applies. If there is another PriceRule with a higher value, and the current power is above that value, then that other PriceRule applies. For negative values, this is the power level below which this price rule applies. If there is another PriceRule with a lower value, and the current power is below that value, then that other PriceRule applies.</td></tr></table>
+
+# 2.80. PriceType
+
+Class
+
+Price with and without tax. At least one of exclTax, incITax must be present.
+
+PriceType is used by: Common:TariffType, Common:TotalCostType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>exclTax</td><td>decimal</td><td>0..1</td><td>Optional. Price/cost excluding tax. Can be absent if exclTax is present.</td></tr><tr><td>inclTax</td><td>decimal</td><td>0..1</td><td>Optional. Price/cost including tax. Can be absent if exclTax is present.</td></tr><tr><td>taxRates</td><td>TaxRateType</td><td>0..5</td><td>Optional. Tax percentages that were used to calculate inclTax from exclTax (for displaying/printing on invoices).</td></tr></table>
+
+# 2.81. RationalNumberType
+
+Class
+
+Part of ISO 15118-20 price schedule.
+
+RationalNumberOfTypeisusedby:Common:AbsolutePriceScheduleType,Common:AdditionalSelectedServicesType, Common:OverstayRuleListType,Common:OverstayRuleType,Common:PriceRuleType,Common:TaxRuleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>exponent</td><td>integer</td><td>1..1</td><td>Required. The exponent to base 10 (dec)</td></tr><tr><td>value</td><td>integer</td><td>1..1</td><td>Required. Value which shall be multiplied.</td></tr></table>
+
+# 2.82. ReactivePowerParamsType
+
+Class
+
+ReactivePowerParamsType is used by: Common:DERCurveType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>vRef</td><td>decimal</td><td>0..1</td><td>Optional. Only for VoltVar curve: The nominal ac voltage (rms) adjustment to the voltage curve points for Volt-Var curves (percentage).</td></tr><tr><td>autonomousVRefEnable</td><td>boolean</td><td>0..1</td><td>Optional. Only for VoltVar: Enable/disable autonomous VRef adjustment</td></tr><tr><td>autonomousVRefTimeConstant</td><td>decimal</td><td>0..1</td><td>Optional. Only for VoltVar: Adjustment range for VRef time constant</td></tr></table>
+
+# 2.83. RelativeTimeIntervalType
+
+Class
+
+RelativeTimeIntervalType is used by: Common:SalesTariffEntryType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>start</td><td>integer</td><td>1..1</td><td>Required. Start of the interval, in seconds from NOW.</td></tr><tr><td>duration</td><td>integer</td><td>0..1</td><td>Optional. Duration of the interval, in seconds.</td></tr></table>
+
+# 2.84. ReportDataType
+
+Class
+
+Class to report components, variables and variable attributes and characteristics.
+
+ReportDataType is used by: NotifyRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which a report of Variable is requested.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which report is requested.</td></tr><tr><td>attribute</td><td>VariableAttributeType</td><td>1..4</td><td>Required. Attribute data of a variable.</td></tr><tr><td>characteristics</td><td>VariableCharacteristicsType</td><td>0..1</td><td>Optional. Fixed read-only parameters of a variable.</td></tr></table>
+
+# 2.85. SalesTariffEntryType
+
+Class
+
+SalesTariffEntryType is used by: Common:SalesTariffType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>ePriceLevel</td><td>integer, 0 < = val</td><td>0..1</td><td>Optional. Defines the price level of this SalesTariffEntry (referring to NumEPriceLevels). Small values for the EPriceLevel represent a cheaper TariffEntry. Large values for the EPriceLevel represent a more expensive TariffEntry.</td></tr><tr><td>relativeTimeInterval</td><td>RelativeTimeIntervalType</td><td>1..1</td><td>Required. Defines the time interval the SalesTariffEntry is valid for, based upon relative times.</td></tr><tr><td>consumptionCost</td><td>ConsumptionCostType</td><td>0..3</td><td>Optional. Defines additional means for further relative price information and/or alternative costs.</td></tr></table>
+
+# 2.86. SalesTariffType
+
+Class
+
+A SalesTariff provided by a Mobility Operator (EMSP). NOTE: This dataType is based on dataTypes from ISO 15118-2.
+
+SalesTariffType is used by: Common:ChargingScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. SalesTariff identifier used to identify one sales tariff. An SAID remains a unique identifier for one schedule throughout a charging session.</td></tr><tr><td>salesTariffDescription</td><td>string[0..32]</td><td>0..1</td><td>Optional. A human readable title/short description of the sales tariff e.g. for HMI display purposes.</td></tr><tr><td>numEPriceLevels</td><td>integer, 0 < = val</td><td>0..1</td><td>Optional. Defines the overall number of distinct price levels used across all provided SalesTariff elements.</td></tr><tr><td>salesTariffEntry</td><td>SalesTariffEntryType</td><td>1..1024</td><td>Required. Encapsulating element describing all relevant details for one time interval of the SalesTariff. The number of SalesTariffEntry elements is limited by the parameter maxScheduleTuples.</td></tr></table>
+
+# 2.87. SampledValueType
+
+Class
+
+Single sampled value in MeterValues. Each value can be accompanied by optional fields.
+
+To save on mobile data usage, default values of all of the optional fields are such that. The value without any additional fields will be interpreted, as a register reading of active import energy in Wh (Watt-hour) units.
+
+SampledValueType is used by: Common:MeterValueType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>value</td><td>decimal</td><td>1..1</td><td>Required. Indicates the measured value.</td></tr><tr><td>measurand</td><td>MeasurandEnumType</td><td>0..1</td><td>Optional. Type of measurement. Default = "Energy.Active.Import.Register"</td></tr><tr><td>context</td><td>ReadingContextEnumType</td><td>0..1</td><td>Optional. Type of detail value: start, end or sample. Default = "Sample.Periodic"</td></tr><tr><td>phase</td><td>PhaseEnumType</td><td>0..1</td><td>Optional. Indicates how the measured value is to be interpreted. For instance between L1 and neutral (L1-N) Please note that not all values of phase are applicable to all Measurands. When phase is absent, the measured value is interpreted as an overall value.</td></tr><tr><td>location</td><td>LocationEnumType</td><td>0..1</td><td>Optional. Indicates where the measured value has been sampled. Default = "Outlet"</td></tr><tr><td>signedMeterValue</td><td>SignedMeterValueType</td><td>0..1</td><td>Optional. Contains the MeterValueSignature with sign/encoding method information.</td></tr><tr><td>unitOfMeasure</td><td>UnitOfMeasureType</td><td>0..1</td><td>Optional. Represents a UnitOfMeasure including a multiplier</td></tr></table>
+
+# 2.88. SetMonitoringDataType
+
+Class
+
+Class to hold parameters of SetVariableMonitoring request.
+
+SetMonitoringDataType is used by: SetVariableMonitoringRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. An id SHALL only be given to replace an existing monitor. The Charging Station handles the generation of id's for new monitors.</td></tr><tr><td>transaction</td><td>boolean</td><td>0..1</td><td>Optional. Monitor only active when a transaction is ongoing on a component relevant to this transaction. Default = false.</td></tr><tr><td>value</td><td>decimal</td><td>1..1</td><td>Required. Value for threshold or delta monitoring. For Periodic or PeriodicClockAligned this is the interval in seconds.</td></tr><tr><td>type</td><td>MonitorEnumType</td><td>1..1</td><td>Required. The type of this monitor, e.g. a threshold, delta or periodic monitor.</td></tr><tr><td rowspan="2">severity</td><td rowspan="2">integer, 0 <= val</td><td rowspan="2">1..1</td><td>Required. The severity that will be assigned to an event that is triggered by this monitor. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.</td></tr><tr><td>The severity levels have the following meaning:0-DangerIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately.1-Hardware FailureIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required.2-System FailureIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required.3-CriticalIndicates a critical error. Action is required.4-ErrorIndicates a non-urgent error. Action is required.5-A AlertIndicates an alert event. Default severity for any type of monitoring event.6-WarningIndicates a warning event. Action may be required.7-NoticeIndicates an unusual event. No immediate action is required.8-InformationalIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required.9-DebugIndicates information useful to developers for debugging, not useful during operations.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which monitor is set.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which monitor is set.</td></tr><tr><td>periodicEventStream</td><td>PeriodicEventStreamParamsType</td><td>0..1</td><td>Optional. (2.1) Optional. When present, events from a monitor will be sent via a periodic event stream. Used for monitors of type Periodic, PeriodicClockAligned or Delta.</td></tr></table>
+
+# 2.89. SetMonitoringResultType
+
+Class
+
+Class to hold result of SetVariableMonitoring request.
+
+SetMonitoringResultType is used by: SetVariableMonitoringResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. Id given to the VariableMonitor by the Charging Station. The Id is only returned when status is accepted. Installed VariableMonitors should have unique id's but the id's of removed Installed monitors should have unique id's but the id's of removed monitors MAY be reused.</td></tr><tr><td>status</td><td>SetMonitoringStatusEnumType</td><td>1..1</td><td>Required. Status is OK if a value could be returned. Otherwise this will indicate the reason why a value could not be returned.</td></tr><tr><td>type</td><td>MonitorEnumType</td><td>1..1</td><td>Required. The type of this monitor, e.g. a threshold, delta or periodic monitor.</td></tr><tr><td>severity</td><td>integer, 0 <= val</td><td>1..1</td><td>Required. The severity that will be assigned to an event that is triggered by this monitor. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level. The severity levels have the following meaning:0-DangerIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately.1-Hardware FailureIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required.2-System FailureIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required.3-CriticalIndicates a critical error. Action is required.4-ErrorIndicates a non-urgent error. Action is required.5-A AlertIndicates an alert event. Default severity for any type of monitoring event.6-WarningIndicates a warning event. Action may be required.7-NoticeIndicates an unusual event. No immediate action is required.8-InformationalIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required.9-DebugIndicates information useful to developers for debugging, not useful during operations.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. Component for which status is returned.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Variable for which status is returned.</td></tr><tr><td>statusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed status information.</td></tr></table>
+
+# 2.90. SetVariableDataType
+
+Class
+
+SetVariableDataType is used by: SetVariablesRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>attributeType</td><td>AttributeEnumType</td><td>0..1</td><td>Optional. Type of attribute: Actual, Target, MinSet, MaxSet. Default is Actual when omitted.</td></tr><tr><td>attributeValue</td><td>string[0..2500]</td><td>1..1</td><td>Required. Value to be assigned to attribute of variable. This value is allowed to be an empty string ("").The Configuration Variable ConfigurationValueSize can be used to limit SetVariableData(attributeValue and VariableCharacteristics.valuesList. The max size of these values will always remain equal.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. The component for which the variable data is set.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. Specifies the that needs to be set.</td></tr></table>
+
+# 2.91. SetVariableResultSetType
+
+Class
+
+SetVariableResultType is used by: SetVariablesResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>attributeType</td><td>AttributeEnumType</td><td>0..1</td><td>Optional. Type of attribute: Actual, Target, MinSet, MaxSet. Default is Actual when omitted.</td></tr><tr><td>attributeStatus</td><td>SetVariableStatusEnumType</td><td>1..1</td><td>Required. Result status of setting the variable.</td></tr><tr><td>component</td><td>ComponentType</td><td>1..1</td><td>Required. The component for which result is returned.</td></tr><tr><td>variable</td><td>VariableType</td><td>1..1</td><td>Required. The variable for which the result is returned.</td></tr><tr><td>attributeStatusInfo</td><td>StatusInfoType</td><td>0..1</td><td>Optional. Detailed attribute status information.</td></tr></table>
+
+# 2.92. SignedMeterValueType
+
+Class
+
+Represent a signed version of the meter value.
+
+SignedMeterValueType is used by: Common:SampledValueType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>signedMeterData</td><td>string[0..32768]</td><td>1..1</td><td>Required. Base64 encoded, contains the signed data from the meter in the format specified in encodingMethod, which might contain more then just the meter value. It can contain information like timestamps, reference to a customer etc.</td></tr><tr><td>signingMethod</td><td>string[0..50]</td><td>0..1</td><td>Optional. (2.1) Method used to create the digital signature. Optional, if already included in signedMeterData. Standard values for this are defined in Appendix as SigningMethodEnum性和Type.</td></tr><tr><td>encodingMethod</td><td>string[0..50]</td><td>1..1</td><td>Required. Format used by the energy meter to encode the meter data. For example: OCMF or EDL.</td></tr><tr><td>publicKey</td><td>string[0..2500]</td><td>0..1</td><td>Optional. (2.1) Base64 encoded, sending depends on configuration variable PublicKeyWithSignedMeterValue.</td></tr></table>
+
+# 2.93. StatusBarType
+
+Class
+
+Element providing more information about the status.
+
+StatusInfoType is used by: Common:ClearTariffsResultType, BootNotificationResponse, CancelReservationResponse, TriggerMessageResponse, ChangeTransactionTariffResponse, GetTariffsResponse, OpenPeriodicEventStreamResponse, AdjustPeriodicEventStreamResponse, SetDERControlResponse, GetDERControlResponse, UnlockConnectorResponse, ClearDERControlResponse, UpdateFirmwareResponse, ClearDisplayMessageResponse, LogStatusNotificationRequest, Get15118EVCertificateResponse, GetCompositeScheduleResponse, ChangeAvailabilityResponse, GetLogResponse, ClearChargingProfileResponse, NotifyEVChargingNeedsResponse, ClearCacheResponse, NotifyEVChargingScheduleResponse, RequestStartTransactionResponse, RequestStopTransactionResponse, SetChargingProfileResponse, SetDisplayMessageResponse, SetNetworkProfileResponse, SignCertificateResponse, DataTransferResponse, FirmwareStatusNotificationRequest, CertificateSignedResponse, DeleteCertificateResponse, GetChargingProfilesResponse, GetInstalledCertificatesResponse, InstallCertificateResponse, ClearVariableMonitoringResponse.ClearMonitoringResultType, GetBaseReportResponse, GetMonitoringReportResponse, GetReportResponse, GetVariablesResponse.GetVariableResultType, ReserveNowResponse, SetMonitoringBaseResponse, SetMonitoringLevelResponse, SetVariableMonitoringResponse.SetMonitoringResultType, SetVariablesResponse.SetVariableResultType, PublishFirmwareResponse, PublishFirmwareStatusNotificationRequest, GetCertificateStatusResult response, ResetResponse, GetDisplayMessagesResponse, CustomerInformationResponse, NotifyAllowedEnergyTransferResponse, UsePriorityChargingResponse, PullDynamicScheduleUpdateResponse, UpdateDynamicScheduleResponse, SendLocalListResponse, AFRRSignalResponse, RequestBatterySwapResponse, VatNumberValidationResponse, SetDefaultTariffResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>reasonCode</td><td>string[0..20]</td><td>1..1</td><td>Required. A predefined code for the reason why the status is returned in this response. The string is case-insensitive.</td></tr><tr><td>additionalInfo</td><td>string[0..1024]</td><td>0..1</td><td>Optional. Additional text to provide detailed information.</td></tr></table>
+
+# 2.94. StreamData ElementType
+
+Class
+
+StreamDataElementType is used by: NotifyPeriodicEventStream
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>t</td><td>decimal</td><td>1..1</td><td>Required. Offset relative to北京时间 of this message.北京时间 + t is timestamp of recorded value.</td></tr><tr><td>v</td><td>string[0..2500]</td><td>1..1</td><td>Required.</td></tr></table>
+
+# 2.95. TariffAssignmentType
+
+Class
+
+Shows assignment of tariffs to EVSE or IdToken.
+
+TariffAssignmentType is used by: GetTariffsResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>tariffld</td><td>string[0..60]</td><td>1..1</td><td>Required. Tariff id.</td></tr><tr><td>tariffKind</td><td>TariffKindEnumType</td><td>1..1</td><td>Required. Kind of tariff (driver/default)</td></tr><tr><td>validFrom</td><td>dateTime</td><td>0..1</td><td>Optional. Date/time when this tariff become active.</td></tr><tr><td>evselds</td><td>integer, 0 <= val</td><td>0..*</td><td>Optional.</td></tr><tr><td>idTokens</td><td>identifierString[0..255]</td><td>0..*</td><td>Optional. IdTokens related to tariff</td></tr></table>
+
+# 2.96. TariffConditionsFixedType
+
+Class
+
+These conditions describe if a FixedPrice applies at start of the transaction.
+
+When more than one restriction is set, they are to be treated as a logical AND. All need to be valid before this price is active.
+
+# NOTE
+
+startTimeOfDay and endTimeOfDay are in local time, because it is the time in the tariff as it is shown to the EV driver at the Charging Station. A Charging Station will convert this to the internal time zone that it uses (which is recommended to be UTC, see section Generic chapter 3.1) when performing cost calculation.
+
+TariffConditionsFixedType is used by: Common:TariffFixedPriceType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>startTimeOfDay</td><td>string</td><td>0..1</td><td>Optional. Start time of day in local time.
+Format as per RFC 3339: time-hour "." time-minute
+Must be in 24h format with leading zeros. Hour/Minute
+separator: "." Regex: ([0-1][0-9][2[0-3]):[0-5][0-9]</td></tr><tr><td>endTimeOfDay</td><td>string</td><td>0..1</td><td>Optional. End time of day in local time. Same syntax asstartTimeOfDay.
+If end time < start time then the period wraps around to the next day.
+To stop at end of the day use: 00:00.</td></tr><tr><td>dayOfWeek</td><td>DayOfDayEnumType</td><td>0..7</td><td>Optional. Day(s) of the week this is tariff applies.</td></tr><tr><td>validFromDate</td><td>string</td><td>0..1</td><td>Optional. Start date in local time, for example: 2015-12-24. Valid from this day (inclusive).
+Format as per RFC 3339: full-date
+Regex: ([12][0-9]{3})-(0[1-9][1[0-2])-(0[1-9][12][0-9][3[01])</td></tr><tr><td>validToDate</td><td>string</td><td>0..1</td><td>Optional. End date in local time, for example: 2015-12-27.
+Valid until this day (exclusive). Same syntax as validFromDate.</td></tr><tr><td>evseKind</td><td>EvseKindEnumType</td><td>0..1</td><td>Optional. Type of EVSE (AC, DC) this tariff applies to.</td></tr><tr><td>paymentBrand</td><td>string[0..20]</td><td>0..1</td><td>Optional. For which payment brand this (adhoc) tariff applies. Can be used to add a surcharge for certain payment brands. Based on value of additionalIdToken from idToken(additionalInfo.type = "PaymentBrand".</td></tr><tr><td>paymentRecognition</td><td>string[0..20]</td><td>0..1</td><td>Optional. Type of adhoc payment, e.g. CC, Debit. Based on value of additionalIdToken from idToken/additionalInfo.type = "PaymentRecognition".</td></tr></table>
+
+# 2.97. TariffConditionsType
+
+Class
+
+These conditions describe if and when a TariffEnergyType or TariffTimeType applies during a transaction.
+
+When more than one restriction is set, they are to be treated as a logical AND. All need to be valid before this price is active.
+
+For reverse energy flow (discharging) negative values of energy, power and current are used.
+
+# NOTE
+
+minXXX (where XXX = Kwh/A/Kw) must be read as "closest to zero", and maxXXX as "furthest from zero". For example, a charging power range from 10 kW to 50 kWh is given by minPower = 10000 and maxPower = 50000, and a discharging power range from -10 kW to -50 kW is given by minPower = -10 and maxPower = -50.
+
+# NOTE
+
+startTimeOfDay and endTimeOfDay are in local time, because it is the time in the tariff as it is shown to the EV driver at the Charging Station. A Charging Station will convert this to the internal time zone that it uses (which is recommended to be UTC, see section Generic chapter 3.1) when performing cost calculation.
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>startTimeOfDay</td><td>string</td><td>0..1</td><td>Optional. Start time of day in local timeFORMAT as per RFC 3339: time-hour "." time-minuteMust be in 24h format with leading zeros. Hour/Minutes separator: "." Regex: ([0-1][0-9]2[0-3]):[0-5][0-9]</td></tr><tr><td>endTimeOfDay</td><td>string</td><td>0..1</td><td>Optional. End time of day in local time. Same syntax asstartTimeOfDay.If end time < start time then the period wraps around tothe next day.To stop at end of the day use: 00:00.</td></tr><tr><td>dayOfWeek</td><td>DayOfDayEnumType</td><td>0..7</td><td>Optional. Day(s) of the week this is tariff applies.</td></tr><tr><td>validFromDate</td><td>string</td><td>0..1</td><td>Optional. Start date in local time, for example: 2015-12-24. Valid from this day (inclusive).Format as per RFC 3339: full-dateRegex: ([12][0-9](3)-(0[1-9]1[0-2)-(0[1-9][12][0-9]3[01])</td></tr><tr><td>validToDate</td><td>string</td><td>0..1</td><td>Optional. End date in local time, for example: 2015-12-27.Valid until this day (exclusive). Same syntax asvalidFromDate.</td></tr><tr><td>evseKind</td><td>EvseKindEnumType</td><td>0..1</td><td>Optional. Type of EVSE (AC, DC) this tariff applies to.</td></tr><tr><td>minEnergy</td><td>decimal</td><td>0..1</td><td>Optional. Minimum consumed energy in Wh, for example20000 Wh. Valid from this amount of energy (inclusive)being used.</td></tr><tr><td>maxEnergy</td><td>decimal</td><td>0..1</td><td>Optional. Maximum consumed energy in Wh, for example50000 Wh. Valid until this amount of energy (exclusive)being used.</td></tr><tr><td>minCurrent</td><td>decimal</td><td>0..1</td><td>Optional. Sum of the minimum current (in Amperes) overall phases, for example 5 A. When the EV is charging withmore than, or equal to, the defined amount of current,this price is/becomes active. If the charging current is orbecomes lower, this price is not or no longer valid andbecomes inactive.This is NOT about the minimum current over theentire transaction.</td></tr><tr><td>maxCurrent</td><td>decimal</td><td>0..1</td><td>Optional. Sum of the maximum current (in Amperes) overall phases, for example 20 A. When the EV is chargingwith less than the defined amount of current, this pricebecomes/is active. If the charging current is or becomeshigher, this price is not or no longer valid and becomesinactive. This is NOT about the maximum current over theentire transaction.</td></tr><tr><td>minPower</td><td>decimal</td><td>0..1</td><td>Optional. Minimum power in W, for example 5000 W.When the EV is charging with more than, or equal to, thedefined amount of power, this price is/becomes active. Ifthe charging power is or becomes lower, this price is notor no longer valid and becomes inactive. This is NOTabout the minimum power over the entire transaction.</td></tr><tr><td>maxPower</td><td>decimal</td><td>0..1</td><td>Optional. Maximum power in W, for example 20000 W.When the EV is charging with less than thedefinedamount of power, this price becomes/is active. If thecharging power is or becomes higher, this price isnot or no longer valid and becomes inactive. This is NOTabout the maximum power over the entire transaction.</td></tr><tr><td>minTime</td><td>integer</td><td>0..1</td><td>Optional. Minimum duration in seconds the transaction(charging & idle) MUST last (inclusive). When the durationof a transaction is longer than the defined value, thisprice is or becomes active. Before that moment, thisprice is not yet active.</td></tr><tr><td>maxTime</td><td>integer</td><td>0..1</td><td>Optional. Maximum duration in seconds the transaction (charging & idle) MUST last (exclusive). When the duration of a transaction is shorter than the defined value, this price is or becomes active. After that moment, this price is no longer active.</td></tr><tr><td>minChargingTime</td><td>integer</td><td>0..1</td><td>Optional. Minimum duration in seconds the charging MUST last (inclusive). When the duration of a charging is longer than the defined value, this price is or becomes active. Before that moment, this price is not yet active.</td></tr><tr><td>maxChargingTime</td><td>integer</td><td>0..1</td><td>Optional. Maximum duration in seconds the charging MUST last (exclusive). When the duration of a charging is shorter than the defined value, this price is or becomes active. After that moment, this price is no longer active.</td></tr><tr><td>minIdleTime</td><td>integer</td><td>0..1</td><td>Optional. Minimum duration in seconds the idle period (i.e. not charging) MUST last (inclusive). When the duration of the idle time is longer than the defined value, this price is or becomes active. Before that moment, this price is not yet active.</td></tr><tr><td>maxIdleTime</td><td>integer</td><td>0..1</td><td>Optional. Maximum duration in seconds the idle period (i.e. not charging) MUST last (exclusive). When the duration of idle time is shorter than the defined value, this price is or becomes active. After that moment, this price is no longer active.</td></tr></table>
+
+# 2.98. TariffEnergyPriceType
+
+Class
+
+Tariff with optional conditions for an energy price.
+
+TariffEnergyPriceType is used by: Common: TariffEnergyType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>priceKwh</td><td>decimal</td><td>1..1</td><td>Required. Price per kWh (excl. tax) for this element.</td></tr><tr><td>conditions</td><td>TariffConditionsType</td><td>0..1</td><td>Optional. Conditions when this tariff element price is applicable. When absent always applicable,</td></tr></table>
+
+# 2.99. TariffEnergyType
+
+Class
+
+Price elements and tax for energy
+
+TariffEnergyType is used by: Common: TariffType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>taxRates</td><td>TaxRateType</td><td>0..5</td><td>Optional. Applicable tax percentages for this tariff dimension. If omitted, no tax is applicable. Not providing a tax is different from 0% tax, which would be a value of 0.0 here.</td></tr><tr><td>prices</td><td>TariffEnergyPriceType</td><td>1..*</td><td>Required. Element tariff price and conditions</td></tr></table>
+
+# 2.100. TariffFixedPriceType
+
+Class
+
+Tariff with optional conditions for a fixed price.
+
+TariffFixedPriceType is used by: Common:TariffFixedType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>priceFixed</td><td>decimal</td><td>1..1</td><td>Required. Fixed price for this element e.g. a start fee.</td></tr><tr><td>conditions</td><td>TariffConditionsFixedType</td><td>0..1</td><td>Optional. Conditions when this tariff element price is applicable. When absent always applicable,</td></tr></table>
+
+# 2.101. TariffFixedType
+
+Class
+
+TariffFixedType is used by: Common:TariffType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>prices</td><td>TariffFixedPriceType</td><td>1..*</td><td>Required.</td></tr><tr><td>taxRates</td><td>TaxRateType</td><td>0..5</td><td>Optional. Applicable tax percentages for this tariff dimension. If omitted, no tax is applicable. Not providing a tax is different from 0% tax, which would be a value of 0.0 here.</td></tr></table>
+
+# 2.102. TariffTimePriceType
+
+Class
+
+Tariff with optional conditions for a time duration price.
+
+TariffTimePriceType is used by: Common:TariffTimeType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>priceMinute</td><td>decimal</td><td>1..1</td><td>Required. Price per minute (excl. tax) for this element.</td></tr><tr><td>conditions</td><td>TariffConditionsType</td><td>0..1</td><td>Optional. Conditions when this tariff element price is applicable. When absent always applicable,</td></tr></table>
+
+# 2.103. TariffTimeType
+
+Class
+
+Price elements and tax for time
+
+TariffTimeType is used by: Common:TariffType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>prices</td><td>TariffTimePriceType</td><td>1..*</td><td>Required. Element tariff price and conditions</td></tr><tr><td>taxRates</td><td>TaxRateType</td><td>0..5</td><td>Optional. Applicable tax percentages for this tariff dimension. If omitted, no tax is applicable. Not providing a tax is different from 0% tax, which would be a value of 0.0 here.</td></tr></table>
+
+# 2.104. TariffType
+
+Class
+
+A tariff is described by fields with prices for: energy, charging time, idle time, fixed fee, reservation time, reservation fixed fee.
+
+Each of these fields may have (optional) conditions that specify when a price is applicable.
+
+The description contains a human-readable explanation of the tariff to be shown to the user.
+
+The other fields are parameters that define the tariff. These are used by the charging station to calculate the price.
+
+TariffType is used by: ChangeTransactionTariffRequest,authorizeResponse,SetDefaultTariffRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>tariffId</td><td>string[0..60]</td><td>1..1</td><td>Required. Unique id of tariff</td></tr><tr><td>currency</td><td>string[0..3]</td><td>1..1</td><td>Required. Currency code according to ISO 4217</td></tr><tr><td>validFrom</td><td>dateTime</td><td>0..1</td><td>Optional. Time when this tariff becomes active. When absent, it is immediately active.</td></tr><tr><td>description</td><td>MessageContentType</td><td>0..10</td><td>Optional. List of multi-language tariff information texts to be shown to the user.</td></tr><tr><td>energy</td><td>TariffEnergyType</td><td>0..1</td><td>Optional. Energy tariff</td></tr><tr><td>chargingTime</td><td>TariffTimeType</td><td>0..1</td><td>Optional. Charging time tariff</td></tr><tr><td>idleTime</td><td>TariffTimeType</td><td>0..1</td><td>Optional. Idle time tariff</td></tr><tr><td>fixedFee</td><td>TariffFixedType</td><td>0..1</td><td>Optional. Fixed fee tariff</td></tr><tr><td>minCost</td><td>PriceType</td><td>0..1</td><td>Optional. The minimal cost for a transaction with this tariff including and excluding taxes. Minimum can be including tax or excluding tax, or both.</td></tr><tr><td>maxCost</td><td>PriceType</td><td>0..1</td><td>Optional. The maximum cost for a transaction with this tariff. Maximum can be including tax or excluding tax, or both.</td></tr><tr><td>reservationTime</td><td>TariffTimeType</td><td>0..1</td><td>Optional. Reservation time tariff</td></tr><tr><td>reservationFixed</td><td>TariffFixedType</td><td>0..1</td><td>Optional. Fixed fee for a reservation</td></tr></table>
+
+# 2.105. TaxRateType
+
+Class
+
+Tax percentage
+
+TaxRateType is used by: Common:PriceType, Common:TariffEnergyType, Common:TariffFixedType, Common:TariffTimeType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>type</td><td>string[0..20]</td><td>1..1</td><td>Required. Type of this tax, e.g. "Federal", "State", for information on receipt.</td></tr><tr><td>tax</td><td>decimal</td><td>1..1</td><td>Required. Tax percentage</td></tr><tr><td>stack</td><td>integer, 0 <= val</td><td>0..1</td><td>Optional. Stack level for this type of tax. Default value, when absent, is 0.
+stack = 0: tax on net price;
+stack = 1: tax added on top of stack 0;
+stack = 2: tax added on top of stack 1, etc.</td></tr></table>
+
+# 2.106. TaxRuleType
+
+Class
+
+Part of ISO 15118-20 price schedule.
+
+TaxRuleType is used by: Common:AbsolutePriceScheduleType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>taxRuleID</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Id for the tax rule.</td></tr><tr><td>taxRuleName</td><td>string[0..100]</td><td>0..1</td><td>Optional. Human readable string to identify the tax rule.</td></tr><tr><td>taxIncludedInPrice</td><td>boolean</td><td>0..1</td><td>Optional. Indicates whether the tax is included in any price or not.</td></tr><tr><td>appliesstoEnergyFee</td><td>boolean</td><td>1..1</td><td>Required. Indicates whether this tax applies to Energy Fees.</td></tr><tr><td>appliesstoParkingFee</td><td>boolean</td><td>1..1</td><td>Required. Indicates whether this tax applies to Parking Fees.</td></tr><tr><td>appliesstoOverstayFee</td><td>boolean</td><td>1..1</td><td>Required. Indicates whether this tax applies to Overstay Fees.</td></tr><tr><td>appliesToMinimumMaximu
+mCost</td><td>boolean</td><td>1..1</td><td>Required. Indicates whether this tax applies to Minimum/Maximum Cost.</td></tr><tr><td>taxRate</td><td>RationalNumberType</td><td>1..1</td><td>Required. Percentage of the total amount of applying fee (energy, parking, overstay, MinimumCost and/or MaximumCost).</td></tr></table>
+
+# 2.107. TotalCostType
+
+Class
+
+This contains the cost calculated during a transaction. It is used both for running cost and final cost of the transaction.
+
+TotalCostType is used by: Common:CostDetailsType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>currency</td><td>string[0..3]</td><td>1..1</td><td>Required. Currency of the costs in ISO 4217 Code.</td></tr><tr><td>typeofCost</td><td>TariffCostEnumType</td><td>1..1</td><td>Required. Type of cost: normal or the minimum or maximum cost.</td></tr><tr><td>fixed</td><td>PriceType</td><td>0..1</td><td>Optional. Total sum of all flat fees in the specified currency, except for TariffFixedPrices with conditions.isReservation = true (counted in reservation).</td></tr><tr><td>energy</td><td>PriceType</td><td>0..1</td><td>Optional. Total sum of all the cost of all the energy used, in the specified currency.</td></tr><tr><td>chargingTime</td><td>PriceType</td><td>0..1</td><td>Optional. Total sum of all the cost related to duration of charging during this transaction, in the specified currency.</td></tr><tr><td>idleTime</td><td>PriceType</td><td>0..1</td><td>Optional. Total sum of all the cost related to idle time of this transaction, including fixed price components, in the specified currency.</td></tr><tr><td>reservationTime</td><td>PriceType</td><td>0..1</td><td>Optional. Sum of all time-based cost related to reservation, i.e. TariffType.reservationTime, in the specified currency.</td></tr><tr><td>total</td><td>TotalPriceType</td><td>1..1</td><td>Required. Total of associated cost elements for fixed, energy, chargingTime, idleTime and reservation.</td></tr><tr><td>reservationFixed</td><td>PriceType</td><td>0..1</td><td>Optional. Sum of fixed cost related to reservation, i.e. TariffType.reservationFixed, in the specified currency.</td></tr></table>
+
+# 2.108. TotalPriceType
+
+Class
+
+Total cost with and without tax. Contains the total of energy, charging time, idle time, fixed and reservation costs including and/or excluding tax.
+
+TotalPriceType is used by: Common: TotalCostType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>exclTax</td><td>decimal</td><td>0..1</td><td>Optional. Price/cost excluding tax. Can be absent if exclTax is present.</td></tr><tr><td>inclTax</td><td>decimal</td><td>0..1</td><td>Optional. Price/cost including tax. Can be absent if exclTax is present.</td></tr></table>
+
+# 2.109. TotalUsageType
+
+Class
+
+This contains the calculated usage of energy, charging time and idle time during a transaction.
+
+TotalUsageType is used by: Common:CostDetailsType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>energy</td><td>decimal</td><td>1..1</td><td>Required.</td></tr><tr><td>chargingTime</td><td>integer</td><td>1..1</td><td>Required. Total duration of the charging session (including the duration of charging and not charging), in seconds.</td></tr><tr><td>idleTime</td><td>integer</td><td>1..1</td><td>Required. Total duration of the charging session where the EV was not charging (no energy was transferred between EVSE and EV), in seconds.</td></tr><tr><td>reservationTime</td><td>integer</td><td>0..1</td><td>Optional. Total time of reservation in seconds.</td></tr></table>
+
+# 2.110. TransactionLimitType
+
+Class
+
+Cost, energy, time or SoC limit for a transaction.
+
+TransactionLimitType is used by: Common:TransactionType, TransactionEventResponse
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>maxCost</td><td>decimal</td><td>0..1</td><td>Optional. Maximum allowed cost of transaction in currency of tariff.</td></tr><tr><td>maxEnergy</td><td>decimal</td><td>0..1</td><td>Optional. Maximum allowed energy in Wh to charge in transaction.</td></tr><tr><td>maxTime</td><td>integer</td><td>0..1</td><td>Optional. Maximum duration of transaction in seconds from start to end.</td></tr><tr><td>maxSoC</td><td>integer, 0 <= val <= 100</td><td>0..1</td><td>Optional. Maximum State of Charge of EV in percentage.</td></tr></table>
+
+# 2.111. TransactionType
+
+Class
+
+TransactionType is used by: TransactionRequest
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>transactionId</td><td>identifierString[0..36]</td><td>1..1</td><td>Required. This contains the Id of the transaction.</td></tr><tr><td>chargingState</td><td>ChargingStateEnumType</td><td>0..1</td><td>Optional. Current charging state, is required when state has changed. Omitted when there is no communication between EVSE and EV, because no cable is plugged in.</td></tr><tr><td>timeSpentCharging</td><td>integer</td><td>0..1</td><td>Optional. Contains the total time that energy flowed from EVSE to EV during the transaction (in seconds). Note that timeSpentCharging is smaller or equal to the duration of the transaction.</td></tr><tr><td>stoppedReason</td><td>ReasonEnumType</td><td>0..1</td><td>Optional. The stoppedReason is the reason/event that 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"</td></tr><tr><td>remoteStartId</td><td>integer</td><td>0..1</td><td>Optional. The ID given to remote start request (RequestStartTransactionRequest. This enables to CSMS to match the started transaction to the given start request.</td></tr><tr><td>operationMode</td><td>OperationModeEnumType</td><td>0..1</td><td>Optional. (2.1) The operationMode that is currently in effect for the transaction.</td></tr><tr><td>tariffId</td><td>string[0..60]</td><td>0..1</td><td>Optional. (2.1) Id of tariff in use for transaction</td></tr><tr><td>transactionLimit</td><td>TransactionLimitType</td><td>0..1</td><td>Optional. (2.1) Maximum cost/energy/time allowed for this transaction.</td></tr></table>
+
+# 2.112. UnitOfMeasureType
+
+Class
+
+Represents a UnitOfMeasure with a multiplier
+
+UnitOfMeasureType is used by: Common:SampledValueType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>unit</td><td>string[0..20]</td><td>0..1</td><td>Optional. Unit of the value. Default = "Wh" if the (default) measurand is an "Energy" type. This field SHALL use a value from the list Standardized Units of Measurements in Part 2 Appendices. If an applicable unit is available in that list, otherwise a "custom" unit might be used.</td></tr><tr><td>multiplier</td><td>integer</td><td>0..1</td><td>Optional. Multiplier, this value represents the exponent to base 10. I.e. multiplier 3 means 10 raised to the 3rd power. Default is 0. The multiplier only multiplies the value of the measurand. It does not specify a conversion between units, for example, kW and W.</td></tr></table>
+
+# 2.113. V2XChargingParametersType
+
+Class
+
+Charg parameters for ISO 15118-20, also supporting V2X charging/discharging.+ All values are greater or equal to zero, with the exception of EVMinEnergyRequest, EVMaxEnergyRequest, EVTargetEnergyRequest, EVMinV2XEnergyRequest and EVMaxV2XEnergyRequest.
+
+V2XChargingParametersType is used by: Common:ChargingNeedsType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>minChargePower</td><td>decimal</td><td>0..1</td><td>Optional. Minimum charge power in W, defined by max(EV, EVSE). This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1. Relates to: ISO 15118-20:BPT_AC/DC_CPDReqEnergyTransferModeType:EVMinimumChargePower</td></tr><tr><td>minChargePower_L2</td><td>decimal</td><td>0..1</td><td>Optional. Minimum charge power on phase L2 in W, defined by max(EV, EVSE). Relates to: ISO 15118-20:BPT_AC/DC_CPDReqEnergyTransferModeType:EVMinimumChargePower_L2</td></tr><tr><td>minChargePower_L3</td><td>decimal</td><td>0..1</td><td>Optional. Minimum charge power on phase L3 in W, defined by max(EV, EVSE). Relates to: ISO 15118-20:BPT_AC/DC_CPDReqEnergyTransferModeType:EVMinimumChargePower_L3</td></tr><tr><td>maxChargePower</td><td>decimal</td><td>0..1</td><td>Optional. Maximum charge (absorbed) power in W, defined by min(EV, EVSE) at unity power factor. This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1. It corresponds to the ChaWMax attribute in the IEC 61850. It is usually equivalent to the rated apparent power of the EV when discharging (ChaVAMax) in IEC 61850.Relates to: ISO 15118-20:BPT_AC/DC_CPDReqEnergyTransferModeType:EVMaximumChargePower</td></tr><tr><td>maxChargePower_L2</td><td>decimal</td><td>0..1</td><td>Optional. Maximum charge power on phase L2 in W, defined by min(EV, EVSE) Relates to: ISO 15118-20:BPT_AC/DC_CPDReqEnergyTransferModeType:EVMaximumChargePower_L2</td></tr><tr><td>maxChargePower_L3</td><td>decimal</td><td>0..1</td><td>Optional. Maximum charge power on phase L3 in W, defined by min(EV, EVSE) Relates to: ISO 15118-20:BPT_AC/DC_CPDReqEnergyTransferModeType:EVMaximumChargePower_L3</td></tr><tr><td>minDischargePower</td><td>decimal</td><td>0..1</td><td>Optional. Minimum discharge (injected) power in W, defined by max(EV, EVSE) at unity power factor. Value >= 0.This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.It corresponds to the WMax attribute in the IEC 61850. It is usually equivalent to the rated apparent power of the EV when discharging (VAMax attribute in the IEC 61850).Relates to: ISO 15118-20:BPT_AC/DC_CPDReqEnergyTransferModeType:EVMinimumDischargePower</td></tr><tr><td>minDischargePower_L2</td><td>decimal</td><td>0..1</td><td>Optional. Minimum discharge power on phase L2 in W, defined by max(EV, EVSE). Value >= 0. Relates to: ISO 15118-20:BPT_AC/DC_CPDReqEnergyTransferModeType:EVMinimumDischargePower_L2</td></tr><tr><td>minDischargePower_L3</td><td>decimal</td><td>0..1</td><td>Optional. Minimum discharge power on phase L3 in W, defined by max(EV, EVSE). Value >= 0. Relates to: ISO 15118-20:BPT_AC/DC_CPDReqEnergyTransferModeType:EVMinimumDischargePower_L3</td></tr><tr><td>maxDischargePower</td><td>decimal</td><td>0..1</td><td>Optional. Maximum discharge (injected) power in W, defined by min(EV, EVSE) at unity power factor. Value >= 0. This field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1. Relates to: ISO 15118-20:BPT_AC/DC_CPDReqEnergyTransferModeType:EVMaximumDischargePower</td></tr><tr><td>maxDischargePower_L2</td><td>decimal</td><td>0..1</td><td>Optional. Maximum discharge power on phase L2 in W, defined by min(EV, EVSE). Value >= 0. Relates to: ISO 15118-20:BPT_AC/DC_CPDReqEnergyTransferModeType:EVMaximumDischargePowe_L2</td></tr><tr><td>maxDischargePower_L3</td><td>decimal</td><td>0..1</td><td>Optional. Maximum discharge power on phase L3 in W, defined by min(EV, EVSE). Value >= 0. Relates to: ISO 15118-20:BPT_AC/DC_CPDReqEnergyTransferModeType:EVMaximumDischargePower_L3</td></tr><tr><td>minChargeCurrent</td><td>decimal</td><td>0..1</td><td>Optional. Minimum charge current in A, defined by max(EV, EVSE) Relates to: ISO 15118-20:BPT_DC_CPDReqEnergyTransferModeType:EVMinimumChargeCurrent</td></tr><tr><td>maxChargeCurrent</td><td>decimal</td><td>0..1</td><td>Optional. Maximum charge current in A, defined by min(EV, EVSE) Relates to: ISO 15118-20:BPT_DC_CPDReqEnergyTransferModeType:EVMaximumChargeCurrent</td></tr><tr><td>minDischargeCurrent</td><td>decimal</td><td>0..1</td><td>Optional. Minimum discharge current in A, defined by max(EV, EVSE). Value >= 0. Relates to: ISO 15118-20:BPT_DC_CPDReqEnergyTransferModeType:EVMinimumDischargeCurrent</td></tr><tr><td>maxDischargeCurrent</td><td>decimal</td><td>0..1</td><td>Optional. Maximum discharge current in A, defined by min(EV, EVSE). Value >= 0. Relates to: ISO 15118-20:BPT_DC_CPDReqEnergyTransferModeType:EVMaximumDischargeCurrent</td></tr><tr><td>minVoltage</td><td>decimal</td><td>0..1</td><td>Optional. Minimum voltage in V, defined by max(EV, EVSE) Relates to: ISO 15118-20:BPT_DC_CPDReqEnergyTransferModeType:EVMinimumVoltage</td></tr><tr><td>maxVoltage</td><td>decimal</td><td>0..1</td><td>Optional. Maximum voltage in V, defined by min(EV, EVSE) Relates to: ISO 15118-20:BPT_DC_CPDReqEnergyTransferModeType:EVMaximumVoltage</td></tr><tr><td>evTargetEnergyRequest</td><td>decimal</td><td>0..1</td><td>Optional. Energy to requested state of charge in Wh Relates to: ISO 15118-20:Dynamic/Scheduled_SEReqControlModeType:EVTargetEnergyRequest</td></tr><tr><td>evMinEnergyRequest</td><td>decimal</td><td>0..1</td><td>Optional. Energy to minimum allowed state of charge in Wh Relates to: ISO 15118-20:Dynamic/Scheduled_SEReqControlModeType:EVMinimumEnergyRequest</td></tr><tr><td>evMaxEnergyRequest</td><td>decimal</td><td>0..1</td><td>Optional. Energy to maximum state of charge in Wh Relates to: ISO 15118-20:Dynamic/Scheduled_SEReqControlModeType:EVMaximumEnergyRequest</td></tr><tr><td>evMinV2XEnergyRequest</td><td>decimal</td><td>0..1</td><td>Optional. Energy (in Wh) to minimum state of charge for cycling (V2X) activity. Positive value means that current state of charge is below V2X range. Relates to: ISO 15118-20:Dynamic_SEReqControlModeType:EVMinimumV2XEnergyRequest</td></tr><tr><td>evMaxV2XEnergyRequest</td><td>decimal</td><td>0..1</td><td>Optional. Energy (in Wh) to maximum state of charge for cycling (V2X) activity. Negative value indicates that current state of charge is above V2X range. Relates to: ISO 15118-20:Dynamic_SEReqControlModeType:EVMaximumV2XEnergyRequest</td></tr><tr><td>targetSoC</td><td>integer, 0 <= val <= 100</td><td>0..1</td><td>Optional. Target state of charge at departure as percentage. Relates to: ISO 15118-20:BPT_DC_CPDReqEnergyTransferModeType: TargetSOC</td></tr></table>
+
+# 2.114. V2XFreqWattPointType
+
+Class
+
+(2.1) A point of a frequency-watt curve.
+
+V2XFreqWattPointType is used by: Common:ChargingSchedulePeriodType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>frequency</td><td>decimal</td><td>1..1</td><td>Required. Net frequency in Hz.</td></tr><tr><td>power</td><td>decimal</td><td>1..1</td><td>Required. Power in W to charge (positive) or discharge (negative) at specified frequency.</td></tr></table>
+
+# 2.115. V2XSignalWattPointType
+
+Class
+
+# (2.1) A point of a signal-watt curve.
+
+V2XSignalWattPointType is used by: Common:ChargingSchedulePeriodType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>signal</td><td>integer</td><td>1..1</td><td>Required. Signal value from an AFRRSignalRequest.</td></tr><tr><td>power</td><td>decimal</td><td>1..1</td><td>Required. Power in W to charge (positive) or discharge (negative) at specified frequency.</td></tr></table>
+
+# 2.116. VariableAttributeType
+
+Class
+
+Attribute data of a variable.
+
+VariableAttributeType is used by: NotifyReportRequest.ReportDataType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>type</td><td>AttributeEnumType</td><td>0..1</td><td>Optional. Attribute: Actual, MinSet, MaxSet, etc. Defaults to Actual if absent.</td></tr><tr><td>value</td><td>string[0..2500]</td><td>0..1</td><td>Optional. Value of the attribute. May only be omitted when mutability is set to 'WriteOnly'.The Configuration Variable ReportingValueSize can be used to limit GetVariableResult(attributeValue,VariableAttribute.value and EventDataactualValue. The max size of these values will always remain equal.</td></tr><tr><td>mutability</td><td>MutabilityEnumType</td><td>0..1</td><td>Optional. Defines the mutability of this attribute. Default is ReadWrite when omitted.</td></tr><tr><td>persistent</td><td>boolean</td><td>0..1</td><td>Optional. If true, value will be persistent across system reboots or power down. Default when omitted is false.</td></tr><tr><td>constant</td><td>boolean</td><td>0..1</td><td>Optional. If true, value that will never be changed by the Charging Station at runtime. Default when omitted is false.</td></tr></table>
+
+# 2.117. VariableCharacteristicsType
+
+Class
+
+Fixed read-only parameters of a variable.
+
+VariableCharacteristicsType is used by: NotifyReportRequest.ReportDataType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>unit</td><td>string[0..16]</td><td>0..1</td><td>Optional. Unit of the variable. When the transmitted value has a unit, this field SHALL be included.</td></tr><tr><td>dataType</td><td>DataEnumType</td><td>1..1</td><td>Required. Data type of this variable.</td></tr><tr><td>minLimit</td><td>decimal</td><td>0..1</td><td>Optional. Minimum possible value of this variable.</td></tr><tr><td>maxLimit</td><td>decimal</td><td>0..1</td><td>Optional. Maximum possible value of this variable. When the datatype of this Variable is String, OptionList, SequenceList or MemberList, this field defines the maximum length of the (CSV) string.</td></tr><tr><td>maxElements</td><td>integer, 1 <= val</td><td>0..1</td><td>Optional. (2.1) Maximum number of elements from valuesList that are supported as attributeValue.</td></tr><tr><td>valuesList</td><td>string[0..1000]</td><td>0..1</td><td>Optional. Mandatory when dataType = OptionList, MemberList or SequenceList. In that case valuesList specifies the allowed values for the type.The length of this field can be limited by DeviceDataCtrlr.ConfigurationValueSize.* 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.valuesList. The max size of these values will always remain equal.</td></tr><tr><td>supportsMonitoring</td><td>boolean</td><td>1..1</td><td>Required. Flag indicating if this variable supports monitoring.</td></tr></table>
+
+# 2.118. VariableMonitoringType
+
+Class
+
+A monitoring setting for a variable.
+
+VariableMonitoringType is used by: NotifyMonitoringReportRequest.MonitoringDataType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>id</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. Identifies the monitor.</td></tr><tr><td>transaction</td><td>boolean</td><td>1..1</td><td>Required. Monitor only active when a transaction is ongoing on a component relevant to this transaction.</td></tr><tr><td>value</td><td>decimal</td><td>1..1</td><td>Required. Value for threshold or delta monitoring. For Periodic or PeriodicClockAligned this is the interval in seconds.</td></tr><tr><td>type</td><td>MonitorEnumType</td><td>1..1</td><td>Required. The type of this monitor, e.g. a threshold, delta or periodic monitor.</td></tr><tr><td>severity</td><td>integer, 0 < = val</td><td>1..1</td><td>Required. The severity that will be assigned to an event that is triggered by this monitor. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.The severity levels have the following meaning:0-DangerIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately.1-Hardware FailureIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required.2-System FailureIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required.3-CriticalIndicates a critical error. Action is required.4-ErrorIndicates a non-urgent error. Action is required.5-A AlertIndicates an alert event. Default severity for any type of monitoring event.6-WarningIndicates a warning event. Action may be required.7-NoticeIndicates an unusual event. No immediate action is required.8-InformationalIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required.9-DebugIndicates information useful to developers for debugging, not useful during operations.</td></tr><tr><td>eventNotificationType</td><td>EventNotificationEnumType</td><td>1..1</td><td>Required. (2.1) Type of monitor.</td></tr></table>
+
+# 2.119.类型的
+
+Class
+
+Reference key to a component-variable.
+
+VariableType is used by: Common:ComponentVariableType, GetVariablesRequest.GetVariableDataType, GetVariablesResponse.GetVariableResultType, NotifyMonitoringReportRequest.MonitoringDataType, NotifyReportRequest.ReportDataType, SetVariableMonitoringRequest.SetMonitoringDataType, SetVariableMonitoringResponse.SetMonitoringResultType, SetVariablesRequest.SetVariableDataType, SetVariablesResponse.SetVariableResultType, NotifyEventRequest.EventDataType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>name</td><td>identifierString[0..50]</td><td>1..1</td><td>Required. Name of the variable. Name should be taken from the list of standardized variable names whenever possible. CaseInsensitive. strongly advised to use Camel Case.</td></tr><tr><td>instance</td><td>identifierString[0..50]</td><td>0..1</td><td>Optional. Name of instance in case the variable exists as multiple instances. CaseInsensitive. strongly advised to use Camel Case.</td></tr></table>
+
+# 2.120. VoltageParamsType
+
+Class
+
+VoltageParamsType is used by: Common:DERCurveType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>hv10MinMeanValue</td><td>decimal</td><td>0..1</td><td>Optional. EN 50549-1 chapter 4.9.3.4 Voltage threshold for the 10 min time window mean value monitoring. The 10 min mean is recalculated up to every 3 s. If the present voltage is above this threshold for more than the time defined by hv10MinMeanValue, the EV must trip. This value is mandatory if hv10MinMeanTripDelay is set.</td></tr><tr><td>hv10MinMeanTripDelay</td><td>decimal</td><td>0..1</td><td>Optional. Time for which the voltage is allowed to stay above the 10 min mean value. After this time, the EV must trip. This value is mandatory if OverVoltageMeanValue10min is set.</td></tr><tr><td>powerDuringCessation</td><td>PowerDuringCessationEnumType</td><td>0..1</td><td>Optional. Parameter is only sent, if the EV has to feed-in power or reactive power during fault-ride through (FRT) as defined by HVMomCess curve and LVMomCess curve.</td></tr></table>
+
+# 2.121. VPNType
+
+Class
+
+VPN Configuration settings
+
+VPNType is used by: SetNetworkProfileRequest.NetworkConnectionProfileType
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>server</td><td>string[0..2000]</td><td>1..1</td><td>Required. VPN Server Address</td></tr><tr><td>user</td><td>string[0..50]</td><td>1..1</td><td>Required. VPN User</td></tr><tr><td>group</td><td>string[0..50]</td><td>0..1</td><td>Optional. VPN group.</td></tr><tr><td>password</td><td>string[0..64]</td><td>1..1</td><td>Required. (2.1) VPN Password.</td></tr><tr><td>key</td><td>string[0..255]</td><td>1..1</td><td>Required. VPN shared secret.</td></tr><tr><td>type</td><td>VPNEnumType</td><td>1..1</td><td>Required. Type of VPN</td></tr></table>
+
+# Chapter 3. Enumerations
+
+# 3.1. APNAAuthenticationEnumType
+
+Enumeration
+
+APNAuthenticationEnumType is used by: setNetworkProfile:SetNetworkProfileRequest.APNType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>PAP</td><td>Use PAP authentication</td></tr><tr><td>CHAP</td><td>Use CHAP authentication</td></tr><tr><td>NONE</td><td>Use no authentication</td></tr><tr><td>AUTO</td><td>Sequentially try CHAP, PAP, NONE.</td></tr></table>
+
+# 3.2. AttributeEnumType
+
+Enumeration
+
+AttributeEnumType is used by: Common:VariableAttributeType, getVariables:GetVariablesRequest.GetVariableDataType, getVariables:GetVariablesResponse.GetVariableResultType, setVariables:SetVariablesRequest.SetVariableDataType, setVariables:SetVariablesResponse.SetVariableResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Actual</td><td>The actual value of the variable.</td></tr><tr><td>Target</td><td>The target value for this variable.</td></tr><tr><td>MinSet</td><td>The minimal allowed value for this variable</td></tr><tr><td>MaxSet</td><td>The maximum allowed value for this variable</td></tr></table>
+
+# 3.3. AuthorizationStatusEnumType
+
+Enumeration
+
+Status of an authorization response.
+
+AuthorizationStatusEnumType is used by: Common:IdTokenInfoType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Identifier is allowed for charging.</td></tr><tr><td>Blocked</td><td>Identifier has been blocked. Not allowed for charging.</td></tr><tr><td>ConcurrentTx</td><td>Identifier is already involved in another transaction and multiple transactions are not allowed. (Only relevant for the response to a TransactionRequest(eventType=Started).)</td></tr><tr><td>Expired</td><td>Identifier has expired. Not allowed for charging.</td></tr><tr><td>Invalid</td><td>Identifier is invalid. Not allowed for charging.</td></tr><tr><td>NoCredit</td><td>Identifier is valid, but EV Driver doesn’t have enough credit to start charging. Not allowed for charging.</td></tr><tr><td>NotAllowedTypeEVE</td><td>Identifier is valid, but not allowed to charge at this type of EVSE.</td></tr><tr><td>NotAtThisLocation</td><td>Identifier is valid, but not allowed to charge at this location.</td></tr><tr><td>NotAtThisTime</td><td>Identifier is valid, but not allowed to charge at this location at this time.</td></tr><tr><td>Unknown</td><td>Identifier is unknown. Not allowed for charging.</td></tr></table>
+
+# 3.4.authorizeCertificateStatusEnumType
+
+Enumeration
+
+Status of the EV Contract certificate.
+
+AuthorizationCertificateStatusEnumType is used by: authorizeAuthorizationResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Positive response</td></tr><tr><td>SignatureError</td><td></td></tr><tr><td>CertificateExpired</td><td>If the contract certificate in the AuthorizationRequest is expired.</td></tr><tr><td>CertificateRevoked</td><td>If the Charging Station or CSMS determine (via a CRL or OCSP response) that the contract certificate in the AuthorizationRequest is marked as revoked.</td></tr><tr><td>NoCertificateAvailable</td><td></td></tr><tr><td>CertChainError</td><td>If the contract certificate contained in the AuthorizationRequest message is not valid.</td></tr><tr><td>ContractCancelled</td><td>If the EMAID provided by EVCC is invalid, unknown, expired or blocked.</td></tr></table>
+
+# 3.5. BatterySwapEventEnumType
+
+Enumeration
+
+(2.1) Battery in/out event at a swap station.
+
+BatterySwapEventEnumType is used by: batterySwap:BatterySwapRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>BatteryIn</td><td>Battery (or set of batteries) is inserted.</td></tr><tr><td>BatteryOut</td><td>Battery (or set of batteries) is removed.</td></tr><tr><td>BatteryOutTimeout</td><td>The offered batteries have not been removed within timeout.</td></tr></table>
+
+# 3.6. BootReasonEnumType
+
+Enumeration
+
+BootReasonEnumType is used by: bootNotification:BootNotificationRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ApplicationReset</td><td>The Charging Station rebooted due to an application error.</td></tr><tr><td>FirmwareUpdate</td><td>The Charging Station rebooted due to a firmware update.</td></tr><tr><td>LocalReset</td><td>The Charging Station rebooted due to a local reset command.</td></tr><tr><td>PowerUp</td><td>The Charging Station powered up and registers itself with the CSMS.</td></tr><tr><td>RemoteReset</td><td>The Charging Station rebooted due to a remote reset command.</td></tr><tr><td>ScheduledReset</td><td>The Charging Station rebooted due to a scheduled reset command.</td></tr><tr><td>Triggered</td><td>Requested by the CSMS via a TriggerMessage</td></tr><tr><td>Unknown</td><td>The boot reason is unknown.</td></tr><tr><td>Watchdog</td><td>The Charging Station rebooted due to an elapsed watchdog timer.</td></tr></table>
+
+# 3.7. CancelReservationStatusEnumType
+
+Enumeration
+
+Status in CancelReservationResponse.
+
+CancelReservationStatusEnumType is used by: cancelReservation:CancelReservationResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Reservation for the identifier has been canceled.</td></tr><tr><td>Rejected</td><td>Reservation could not be canceled, because there is no reservation active for the identifier.</td></tr></table>
+
+# 3.8. CertificateActionEnumType
+
+Enumeration
+
+CertificateActionEnumType is used by: get15118EVCertificate:Get15118EVCertificateRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Install</td><td>Install the provided certificate.</td></tr><tr><td>Update</td><td>Update the provided certificate.</td></tr></table>
+
+# 3.9. CertificateSignedStatusEnumType
+
+Enumeration
+
+CertificateSignedStatusEnumType is used by: certificateSigned:CertificateSignedResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Signed certificate is valid.</td></tr><tr><td>Rejected</td><td>Signed certificate is invalid or requestId is unknown.</td></tr></table>
+
+# 3.10. CertificateSigningUseEnumType
+
+Enumeration
+
+CertificateSigningUseEnumType is used by: signCertificate:SignCertificateRequest, certificateSigned:CertificateSignedRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ChargingStationCertificate</td><td>Client side certificate used by the Charging Station to connect the CSMS.</td></tr><tr><td>V2GCertificate</td><td>Use for certificate for ISO 15118-2 connections. This means that the certificate should be derived from the V2G root.</td></tr><tr><td>V2G20Certificate</td><td>(2.1) Use for certificate for ISO 15118-20 connections. This means that the certificate should be derived from the V2G root.</td></tr></table>
+
+# 3.11. CertificateStatusEnumType
+
+Enumeration
+
+OCSP or CRL status of certificate.
+
+CertificateStatusEnumType is used by: Common: CertificateStatusType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Good</td><td>Certificate has not been revoked.</td></tr><tr><td>Revoked</td><td>Certificate has been revoked.</td></tr><tr><td>Unknown</td><td>Certificate is unknown.</td></tr><tr><td>Failed</td><td>The request to OCSP responder or CRL distribution point failed.</td></tr></table>
+
+# 3.12. CertificateStatusSourceEnumType
+
+Enumeration
+
+Source of certificate status, OCSP or CRL.
+
+CertificateStatusSourceEnumType is used by: Common:CertificateStatusRequestInfoType, Common:CertificateStatusType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>CRL</td><td>Checked in a certificate revocation list.</td></tr><tr><td>OCSP</td><td>Checked via OCSP request.</td></tr></table>
+
+# 3.13. ChangeAvailabilityStatusEnumType
+
+Enumeration
+
+Status returned in response to ChangeAvailabilityRequest.
+
+ChangeAvailabilityStatusEnumType is used by: changeAvailability:ChangeAvailabilityResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Rejected</td><td>Request has not been accepted and will not be executed.</td></tr><tr><td>Scheduled</td><td>Request has been accepted and will be executed when transaction(s) in progress have finished.</td></tr></table>
+
+# 3.14. ChargingProfileKindEnumType
+
+Enumeration
+
+Kind of charging profile.
+
+ChargingProfileKindEnumType is used by: Common:ChargingProfileType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Absolute</td><td>Schedule periods are relative to a fixed point in time defined in the schedule. This requires that startSchedule is set to a starting point in time.</td></tr><tr><td>Recurring</td><td>The schedule restarts periodically at the first schedule period. To be most useful, this requires that startSchedule is set to a starting point in time.</td></tr><tr><td>Relative</td><td>Charging schedule periods 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 remain relative to the PowerPathClosed moment. No value for startSchedule must be supplied.</td></tr><tr><td>Dynamic</td><td>(2.1) The schedule consists of only one charging schedule period, which is updated dynamically by CSMS.</td></tr></table>
+
+# 3.15. ChargingProfilePurposeItemType
+
+Enumeration
+
+Purpose of the charging profile.
+
+ChargingProfilePurposeEnumType is used by: Common:ChargingProfileType, clearChargingProfile:ClearChargingProfileRequest.ClearChargingProfileType, getChargingProfiles:GetChargingProfilesRequest.ChargingProfileCriterionType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ChargingStationExte- rnalConstraints</td><td>Additional constraints from an external source (e.g. an EMS) that will be incorporated into a local power schedule. When applied to evse.Id = 0 it sets a limit to the entire Charging Station. Note: In OCPP 2.0.1 this purpose was only allowed on evse.Id = 0. In OCPP 2.1 it can be set to an individual EVSE.</td></tr><tr><td>ChargingStationMax Profile</td><td>Configuration for the maximum power or current available for an entire Charging Station.</td></tr><tr><td>TxDefaultProfile</td><td>Default profile that can be configured in the Charging Station. When a new transaction is started, this profile SHALL be used, unless it was a transaction that was started by a RequestStartTransactionRequest with a ChargingProfile that is accepted by the Charging Station.</td></tr><tr><td>TxProfile</td><td>Profile with constraints to be imposed by the Charging Station on the current transaction, or on a new transaction when this is started via a RequestStartTransactionRequest with a ChargingProfile. A profile with this purpose SHALL cease to be valid when the transaction terminates.</td></tr><tr><td>PriorityCharging</td><td>(2.1) This profile is used in place of a Tx(Default)Profile, when priority charging is requested, either locally on Charging Station or via a request from CSMS.</td></tr><tr><td>LocalGeneration</td><td>(2.1) This profile adds capacity from local generation. Its capacity is added on top of other charging profiles.</td></tr></table>
+
+# 3.16. ChargingProfileStatusEnumType
+
+Enumeration
+
+Status returned in response to SetChargingProfileRequest.
+
+ChargingProfileStatusEnumType is used by: setChargingProfile:SetChargingProfileResponse, pullDynamicScheduleUpdate:PullDynamicScheduleUpdateResponse, updateDynamicSchedule:updateDynamicScheduleResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Rejected</td><td>Request has not been accepted and will not be executed.</td></tr></table>
+
+# 3.17. ChargingRateUnitEnumType
+
+Enumeration
+
+Unit in which a charging schedule is defined.
+
+ChargingRateUnitEnumType is used by: Common:ChargingScheduleType, Common:CompositeScheduleType, getCompositeSchedule:GetCompositeScheduleRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>W</td><td>Watts (power). This is the TOTAL allowed charging power. If used for AC Charging, the phase current should be calculated via: Current per phase = Power / (Line Voltage * Number of Phases). The "Line Voltage" used in the calculation is not the measured voltage, but the set voltage for the area (hence, 230 of 110 volt). The "Number of Phases" is the numberPhases from the ChargingSchedulePeriod. It is usually more convenient to use this for DC charging. Note that if numberPhases in a ChargingSchedulePeriod is absent, 3 SHALL be assumed.</td></tr><tr><td>A</td><td>Amperes (current). The amount of Ampere per phase, not the sum of all phases. It is usually more convenient to use this for AC charging.</td></tr></table>
+
+# 3.18. ChargingStateEnumType
+
+Enumeration
+
+The state of the charging process.
+
+ChargingStateEnumType is used by: Common:TransactionType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>EVConnected</td><td>There is a connection between EV and EVSE, in case the protocol used between EV and the Charging Station can detect a connection, the protocol needs to detect this for the state to become active. The connection can either be wired or wireless.
+Authorization is required to proceed to state Charging.</td></tr><tr><td>Charging</td><td>The contactor of the Connector is closed and energy is flowing to between EVSE and EV.</td></tr><tr><td>SuspendedEV</td><td>When the EV is connected to the EVSE and the EVSE is offering energy but the EV is not taking any energy.</td></tr><tr><td>SuspendedEVSE</td><td>When the EV is connected to the EVSE but the EVSE is not offering energy to the EV, e.g. due to a smart charging restrictions or local supply power constraints.</td></tr><tr><td>Idle</td><td>There is no connection between EV and EVSE.</td></tr></table>
+
+# 3.19. ClearCacheStatusEnumType
+
+Enumeration
+
+Status returned in response to ClearCacheRequest.
+
+ClearCacheStatusEnumType is used by: clearCache:ClearCacheResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Command has been executed.</td></tr><tr><td>Rejected</td><td>Command has not been executed.</td></tr></table>
+
+# 3.20. ClearChargingProfileStatusEnumType
+
+Enumeration
+
+Status returned in response to ClearChargingProfileRequest.
+
+ClearChargingProfileStatusEnumType is used by: clearChargingProfile:ClearChargingProfileResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request has been accepted.</td></tr><tr><td>Unknown</td><td>No Charging Profile(s) were found matching the request.</td></tr></table>
+
+# 3.21. ClearMessageStatusEnumType
+
+Enumeration
+
+Result for a ClearDisplayMessageRequest as used in a ClearDisplayMessageResponse.
+
+ClearMessageStatusEnumType is used by: clearDisplayMessage:ClearDisplayMessageResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request successfully executed: message cleared.</td></tr><tr><td>Unknown</td><td>Given message (based on the id) not known.</td></tr><tr><td>Rejected</td><td>(2.1) Request could not be executed.</td></tr></table>
+
+# 3.22. ClearMonitoringStatusEnumType
+
+Enumeration
+
+ClearMonitoringStatusEnumType is used by: clearVariableMonitoring: ClearVariableMonitoringResponse.ClearMonitoringResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Monitor successfully cleared.</td></tr><tr><td>Rejected</td><td>Clearing of monitor rejected.</td></tr><tr><td>NotFound</td><td>Monitor Id is not found.</td></tr></table>
+
+# 3.23. ComponentCriterionEnumType
+
+Enumeration
+
+ComponentCriterionEnumType is used by: getReport:GetReportRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Active</td><td>Components that are active, i.e. having Active = 1</td></tr><tr><td>Available</td><td>Components that are available, i.e. having Available = 1</td></tr><tr><td>Enabled</td><td>Components that are enabled, i.e. having Enabled = 1</td></tr><tr><td>Problem</td><td>Components that reported a problem, i.e. having Problem = 1</td></tr></table>
+
+# 3.24. ConnectorStatusEnumType
+
+Enumeration
+
+A status can be reported for the Connector of an EVSE of a Charging Station. States considered Operative are: Available, Reserved and Occupied. States considered Inoperative are: Unavailable, Faulted.
+
+ConnectorStatusEnumType is used by: statusNotification:StatusNotificationRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Available</td><td>When a Connector becomes available for a new User (Operative)</td></tr><tr><td>Occupied</td><td>When a Connector becomes occupied, so it is not available for a new EV driver. (Operative)</td></tr><tr><td>Reserved</td><td>When a Connector becomes reserved as a result of ReserveNow command (Operative)</td></tr><tr><td>Unavailable</td><td>When a Connector becomes unavailable as the result of a Change Availability command or an event upon which the Charging Station transitions to unavailable at its discretion. Upon receipt of ChangeAvailability message command, the status MAY change immediately or the change MAY be scheduled. When scheduled, StatusNotification SHALL be send when the availability change becomes effective (Inoperative)</td></tr><tr><td>Faulted</td><td>When a Connector (or the EVSE or the entire Charging Station it belongs to) has reported an error and is not available for energy delivery. (Inoperative).</td></tr></table>
+
+# 3.25. ControlModeEnumType
+
+Enumeration
+
+(2.1) ISO 15118-20 service parameter for control mode
+
+ControlModeEnumType is used by: Common:ChargingNeedsType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ScheduledControl</td><td>Scheduled control mode, EVSE provides up to three schedules for EV to choose from. EV follows the selected schedule.</td></tr><tr><td>DynamicControl</td><td>Dynamic control mode, EVSE executes a single schedule by sending setpoints to EV at every interval.</td></tr></table>
+
+# 3.26. CostDimensionEnumType
+
+Enumeration
+
+Usage dimension for cost in charging period.
+
+CostDimensionEnumType is used by: Common:CostDimensionType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Energy</td><td>Total amount of energy (dis-)charged during this charging period, defined in Wh (kiloWatt-hours). When negative, more energy was feed into the grid then charged into the EV.</td></tr><tr><td>MaxCurrent</td><td>Sum of the maximum current over all phases, reached during this charging period, defined in A (Ampere).</td></tr><tr><td>MinCurrent</td><td>Sum of the minimum current over all phases, reached during this charging period, when negative, current has flowed from the EV to the grid. Defined in A (Ampere).</td></tr><tr><td>MaxPower</td><td>Maximum power reached during this charging period: defined in W (Watt).</td></tr><tr><td>MinPower</td><td>Minimum power reached during this charging period: defined in W (Watt), when negative, the power has flowed from the EV to the grid.</td></tr><tr><td>IdleTlme</td><td>Time not charging during this charging period: defined in seconds.</td></tr><tr><td>ChargingTime</td><td>Time charging during this charging period: defined in seconds.</td></tr></table>
+
+# 3.27. CostKindEnumType
+
+Enumeration
+
+CostKindEnumType is used by: Common:CostType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>CarbonDioxideEmission</td><td>Absolute value. Carbon Dioxide emissions, in grams per kWh</td></tr><tr><td>RelativePricePercentage</td><td>Relative value. Percentage of renewable generation within total generation.</td></tr><tr><td>RenewableGenerationPercentage</td><td>Relative value. Price per kWh, as percentage relative to the maximum price stated in any of all tariffs indicated to the EV.</td></tr></table>
+
+# 3.28. CustomerInformationStatusTypeDef
+
+Enumeration
+
+Status in CancelReservationResponse.
+
+CustomerInformationStatusEnumType is used by: customerInformation:CustomerInformationResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>The Charging Station accepted the message.</td></tr><tr><td>Rejected</td><td>When the Charging Station is in a state where it cannot process this request.</td></tr><tr><td>Invalid</td><td>In a request to the Charging Station no reference to a customer is included.</td></tr></table>
+
+# 3.29. DataEnumType
+
+Enumeration
+
+DataEnumType is used by: Common:VariableCharacteristicsType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>string</td><td>This variable is of the type string.</td></tr><tr><td>decimal</td><td>This variable is of the type decimal.</td></tr><tr><td>integer</td><td>This variable is of the type integer.</td></tr><tr><td>dateTime</td><td>DateTime following the [RFC3339] specification.</td></tr><tr><td>boolean</td><td>This variable is of the type boolean.</td></tr><tr><td>OptionList</td><td>Supported/allowed values for a single choice, enumerated, text variable.</td></tr><tr><td>SequenceList</td><td>Supported/allowed values for an ordered sequence variable.</td></tr><tr><td>MemberList</td><td>Supported/allowed values for a mathematical set variable.</td></tr></table>
+
+# 3.30. DataTransferStatusEnumType
+
+Enumeration
+
+Status in DataTransferResponse.
+
+DataTransferStatusEnumType is used by: dataTransfer:DataTransferResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Message has been accepted and the contained request is accepted.</td></tr><tr><td>Rejected</td><td>Message has been accepted but the contained request is rejected.</td></tr><tr><td>UnknownMessageld</td><td>Message could not be interpreted due to unknown messageld string.</td></tr><tr><td>UnknownVendorId</td><td>Message could not be interpreted due to unknown vendorId string.</td></tr></table>
+
+# 3.31. DayOfWeekEnumType
+
+Enumeration
+
+DayOfWeekEnumType is used by: Common:TariffConditionsFixedType, Common:TariffConditionsType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Monday</td><td></td></tr><tr><td>Tuesday</td><td></td></tr><tr><td>Wednesday</td><td></td></tr><tr><td>Thursday</td><td></td></tr><tr><td>Friday</td><td></td></tr><tr><td>Saturday</td><td></td></tr><tr><td>Sunday</td><td></td></tr></table>
+
+# 3.32. DeleteCertificateStatusEnumType
+
+Enumeration
+
+DeleteCertificateStatusEnumType is used by: deleteCertificate:DeleteCertificateResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Normal successful completion (no errors).</td></tr><tr><td>Failed</td><td>The Charging Station either failed to remove the certificate or rejected the request. A Charging Station may reject the request to prevent the deletion of a certificate, if it is the last one of its certificate type.</td></tr><tr><td>NotFound</td><td>Requested resource not found.</td></tr></table>
+
+# 3.33. DERControlEnumType
+
+Enumeration
+
+Enumeration of DER controls
+
+DERControlEnumType is used by: Common:DERChargingParametersType, Common:DERCurveGetType, setDERControl:SetDERControlRequest, getDERControl:GetDERControlRequest, clearDERControl:ClearDERControlRequest, notifyDERAlarm:NotifyDERAlarmRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>EnterService</td><td>Enter Service parameters setting</td></tr><tr><td>FreqDroop</td><td>Frequency droop settings</td></tr><tr><td>FreqWatt</td><td>Frequency-Watt curve</td></tr><tr><td>FixedPFAbsorb</td><td>Fixed power factor when absorbing power setting</td></tr><tr><td>FixedPFInject</td><td>Fixed power factor when injecting power setting</td></tr><tr><td>FixedVar</td><td>Fixed reactive power setpoint</td></tr><tr><td>Gradients</td><td>Gradient settings</td></tr><tr><td>HFMustTrip</td><td>High Frequency Must Trip curve</td></tr><tr><td>HFMayTrip</td><td>High Frequency May Trip curve (ride-through)</td></tr><tr><td>HVMustTrip</td><td>High Voltage Must Trip curve</td></tr><tr><td>HVMomCess</td><td>High Voltage Momentary Cessation curve</td></tr><tr><td>HVMayTrip</td><td>High Voltage May Trip curve (ride-through)</td></tr><tr><td>LimitMaxDischarge</td><td>Limit discharge power to percentage of rated discharge power</td></tr><tr><td>LFMustTrip</td><td>Low Frequency Must Trip curve</td></tr><tr><td>LVMustTrip</td><td>Low Voltage Must Trip curve</td></tr><tr><td>LVMomCess</td><td>Low Voltage Momentary Cessation curve</td></tr><tr><td>LVMayTrip</td><td>Low Voltage May Trip curve (ride-through)</td></tr><tr><td>PowerMonitoringMustTrip</td><td>Power Monitoring curve according to VDE-AR-N 4105 section 5.5.2</td></tr><tr><td>VoltVar</td><td>Volt-Var curve</td></tr><tr><td>VoltWatt</td><td>Volt-Watt curve</td></tr><tr><td>WattPF</td><td>Watt-PowerFactor curve</td></tr><tr><td>WattVar</td><td>Watt-Var curve</td></tr></table>
+
+# 3.34. DERControlStatusEnumType
+
+Enumeration
+
+DERControlStatusEnumType is used by: setDERControl:SetDERControlResponse, getDERControl:GetDERControlResponse, clearDERControl:ClearDERControlResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Operation successful</td></tr><tr><td>Rejected</td><td>Operation failed</td></tr><tr><td>NotSupported</td><td>Type of DER setting or curve is not supported</td></tr><tr><td>NotFound</td><td>Type or Id in clear/get request was not found</td></tr></table>
+
+# 3.35. DERUnitEnumType
+
+Enumeration
+
+DERUnitEnumType is used by: Common:DERCurveType, Common:FixedVarType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Not_Aplicable</td><td>No unit applicable (e.g. for ride-through curves)</td></tr><tr><td>PctMaxW</td><td>Percentage of configured active power</td></tr><tr><td>PctMaxVar</td><td>Percentage of configured reactive power</td></tr><tr><td>PctWAvail</td><td>Percentage of available reserve active power</td></tr><tr><td>PctVarAvail</td><td>Percentage of available reserve reactive power</td></tr><tr><td>PctEffectiveV</td><td>Percentage of effective voltage</td></tr></table>
+
+# 3.36. DisplayMessageStatusEnumType
+
+Enumeration
+
+Result for a SetDisplayMessageRequest as used in a SetDisplayMessageResponse.
+
+DisplayMessageStatusEnumType is used by: setDisplayMessage:SetDisplayMessageResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request to display message accepted.</td></tr><tr><td>NotSupportedMessageFormat</td><td>None of the formats in the given message are supported.</td></tr><tr><td>Rejected</td><td>Request cannot be handled.</td></tr><tr><td>NotSupportedPriority</td><td>The given MessagePriority not supported for displaying messages by Charging Station.</td></tr><tr><td>NotSupportedState</td><td>The given MessageState not supported for displaying messages by Charging Station.</td></tr><tr><td>UnknownTransaction</td><td>Given Transaction not known/ongoing.</td></tr><tr><td>LanguageNotSupported</td><td>(2.1) Message contains one or more languages that are not supported by Charging Station.</td></tr></table>
+
+# 3.37. EnergyTransferModeEnumType
+
+Enumeration
+
+Enumeration of energy transfer modes.
+
+EnergyTransferModeEnumType is used by: Common:ChargingNeedsType, authorize:ActivateResponse, notifyAllowedEnergyTransfer:NotifyAllowedEnergyTransferRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>AC_single_phase</td><td>AC single phase charging according to IEC 62196.</td></tr><tr><td>AC_two_phase</td><td>AC two phase charging according to IEC 62196.</td></tr><tr><td>AC_three_phase</td><td>AC three phase charging according to IEC 62196.</td></tr><tr><td>DC</td><td>DC charging.</td></tr><tr><td>AC_BPT</td><td>(2.1) AC bidirectional (no DER control), ISO 15118-20</td></tr><tr><td>AC_BPTDER</td><td>(2.1) AC bidirectional with DER control, ISO 15118-20 (amendment to -20)</td></tr><tr><td>AC DER</td><td>(2.1) AC charging-only with DER control, ISO 15118-20 (amendment to -20)
+Note: at time of writing (July 2024) not yet defined for ISO 15118-20.</td></tr><tr><td>DC_BPT</td><td>(2.1) DC bidirectional power transfer, ISO 15118-20</td></tr><tr><td>DC_ACDP</td><td>(2.1) DC via ACDP connector (pantograph), ISO 15118-20</td></tr><tr><td>DC_ACDP_BPT</td><td>(2.1) DC bidirectional via ACDP connector (pantograph), ISO 15118-20</td></tr><tr><td>WPT</td><td>(2.1) Wireless power transfer, ISO 15118-20</td></tr></table>
+
+# 3.38.EventNotificationEnumType
+
+Enumeration
+
+Specifies the event notification type of the message.
+
+EventNotificationEnumType is used by: Common:VariableMonitoringType, notifyEvent:NotifyRequest.EventDataType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>HardWiredNotification</td><td>The software implemented by the manufacturer triggered a hardwired notification.</td></tr><tr><td>HardWiredMonitor</td><td>Triggered by a monitor, which is hardwired by the manufacturer.</td></tr><tr><td>PreconfiguredMonitor</td><td>Triggered by a monitor, which is preconfigured by the manufacturer.</td></tr><tr><td>CustomMonitor</td><td>Triggered by a monitor, which is set with the setvariablemonitoringrequest message by the Charging Station Operator.</td></tr></table>
+
+# 3.39.EventTriggerEnumType
+
+Enumeration
+
+EventTriggerEnumType is used by: notifyEvent:NotifyRequest.EventDataType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Alerting</td><td>Monitored variable has passed a Lower or Upper Threshold. Also used as trigger type for a HardwiredNotification.</td></tr><tr><td>Delta</td><td>Delta Monitored Variable value has changed by more than specified amount</td></tr><tr><td>Periodic</td><td>Periodic Monitored Variable has been sampled for reporting at the specified interval</td></tr></table>
+
+# 3.40. EvseKindEnumType
+
+Enumeration
+
+EvseKindEnumType is used by: Common:TariffConditionsFixedType, Common:TariffConditionsType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>AC</td><td>AC current EVSE</td></tr><tr><td>DC</td><td>DC current EVSE</td></tr></table>
+
+# 3.41. FirmwareStatusEnumType
+
+Enumeration
+
+Status of a firmware download.
+
+A value with "Intermediate state" in the description, is an intermediate state, update process is not finished.
+
+A value with "Failure end state" in the description, is an end state, update process has stopped, update failed.
+
+A value with "Successful end state" in the description, is an end state, update process has stopped, update successful.
+
+FirmwareStatusEnumType is used by: firmwareStatusNotification:FirmwareStatusNotificationRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Downloaded</td><td>Intermediate state. New firmware has been downloaded by Charging Station.</td></tr><tr><td>DownloadFailed</td><td>Failure end state. Charging Station failed to download firmware.</td></tr><tr><td>Downloading</td><td>Intermediate state. Firmware is being downloaded.</td></tr><tr><td>DownloadScheduled</td><td>Intermediate state. Downloading of new firmware has been scheduled.</td></tr><tr><td>DownloadPaused</td><td>Intermediate state. Downloading has been paused.</td></tr><tr><td>Idle</td><td>Charging Station is not performing firmware update related tasks. Status Idle SHALL only be used as in a FirmwareStatusNotificationRequest that was triggered by TriggerMessageRequest.</td></tr><tr><td>InstallationFailed</td><td>Failure end state. Installation of new firmware has failed.</td></tr><tr><td>Installing</td><td>Intermediate state. Firmware is being installed.</td></tr><tr><td>Installed</td><td>Successful end state. New firmware has successfully been installed in Charging Station.</td></tr><tr><td>InstallRebooting</td><td>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.</td></tr><tr><td>InstallScheduled</td><td>Intermediate state. Installation of the downloaded firmware is scheduled to take place on installDateTime given in UpdateFirmware request.</td></tr><tr><td>InstallVerificationFailed</td><td>Failure end state. Verification of the new firmware (e.g. using a checksum or some other means) has failed and installation will not proceed. (Final failure state)</td></tr><tr><td>InvalidSignature</td><td>Failure end state. The firmware signature is not valid.</td></tr><tr><td>SignatureVerified</td><td>Intermediate state. Provide signature successfully verified.</td></tr></table>
+
+# 3.42. GenericDeviceModel狀態EnumType
+
+Enumeration
+
+GenericDeviceModelStatusEnumType is used by: getBaseReport:GetBaseReportResponse, getMonitoringReport:GetMonitoringReportResponse, getReport:GetReportResponse, setMonitoringBase:SetMonitoringBaseResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Rejected</td><td>Request has not been accepted and will not be executed.</td></tr><tr><td>NotSupported</td><td>The content of the request message is not supported.</td></tr><tr><td>EmptyResultSet</td><td>If the combination of received criteria result in an empty result set.</td></tr></table>
+
+# 3.43.Generic statusesTypeDef
+
+Enumeration
+
+Generic message response status
+
+GenericStatusEnumType is used by: openPeriodicEventStream:OpenPeriodicEventStreamResponse,
+adjustPeriodicEventStream:AdjustPeriodicEventStreamResponse, getCompositeSchedule:GetCompositeScheduleResponse,
+notifyEVChargingSchedule:NotifyEVChargingScheduleResponse, signCertificate:SignCertificateResponse,
+setMonitoringLevel:SetMonitoringLevelResponse, publishFirmware:PublishFirmwareResponse, aFRRSignal:AFRRSignalResponse,
+requestBatterySwap:RequestBatterySwapResponse, vatNumberValidation:VatNumberValidationResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request has been accepted and will be executed.</td></tr><tr><td>Rejected</td><td>Request has not been accepted and will not be executed.</td></tr></table>
+
+# 3.44. GetCertificateIdUseEnumType
+
+Enumeration
+
+GetCertificateldUseEnumType is used by: Common: CertificateHashDataChainType, getInstalledCertificates:GetInstalledCertificatesRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>V2GRootCertificate</td><td>Use for certificate of the ISO 15118 V2G Root.</td></tr><tr><td>M0RootCertificate</td><td>Use for certificate from an eMobility Service provider. To support PnC charging with contracts from service providers that not derived their certificates from the V2G root.</td></tr><tr><td>CSMSRootCertificate</td><td>Root certificate for verification of the CSMS certificate.</td></tr><tr><td>V2GCertificateChain</td><td>ISO 15118 V2G certificate chain (excluding the V2GRootCertificate).</td></tr><tr><td>ManufacturerRootCertificate</td><td>Root certificate for verification of the Manufacturer certificate.</td></tr><tr><td>OEMRootCertificate</td><td>(2.1) OEM root certificate for 2-way TLS with EV.</td></tr></table>
+
+# 3.45. GetCertificateStatusEnumType
+
+Enumeration
+
+GetCertificateStatusEnumType is used by: getCertificateStatus:GetCertificateStatusResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Successfully retrieved the OCSP certificate status.</td></tr><tr><td>Failed</td><td>Failed to retrieve the OCSP certificate status.</td></tr></table>
+
+# 3.46. GetChargingProfileStatusEnumType
+
+Enumeration
+
+GetChargingProfileStatusEnumType is used by: getChargingProfiles:GetChargingProfilesResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Normal successful completion (no errors).</td></tr><tr><td>NoProfiles</td><td>No ChargingProfiles found that match the information in the GetChargingProfilesRequest.</td></tr></table>
+
+# 3.47. GetDisplayMessagesStatusEnumType
+
+Enumeration
+
+GetDisplayMessagesStatusEnumType is used by: getDisplayMessages:GetDisplayMessagesResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request accepted, there are Display Messages found that match all the requested criteria. The Charging Station will send NotifyDisplayMessagesRequest messages to report the requested Display Messages.</td></tr><tr><td>Unknown</td><td>No messages found that match the given criteria.</td></tr></table>
+
+# 3.48. GetInstalledCertificateStatusEnumType
+
+Enumeration
+
+GetInstalledCertificateStatusEnumType is used by: getInstalledCertificatesGetInstalledCertificatesResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Normal successful completion (no errors).</td></tr><tr><td>NotFound</td><td>Requested resource not found.</td></tr></table>
+
+# 3.49. GetVariable statusesEnumType
+
+Enumeration
+
+GetVariableStatusEnumType is used by: getVariables:GetVariablesResponse.GetVariableResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Variable successfully retrieved.</td></tr><tr><td>Rejected</td><td>Request is rejected.</td></tr><tr><td>UnknownComponent</td><td>Component is not known.</td></tr><tr><td>UnknownVariable</td><td>Variable is not known.</td></tr><tr><td>NotSupportedAttributeType</td><td>The AttributeType is not supported.</td></tr></table>
+
+# 3.50. GridEventFaultEnumType
+
+Enumeration
+
+GridEventFaultEnumType is used by: notifyDERAlarm:NotifyDERAlarmRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>CurrentImbalance</td><td>Current imbalance detected</td></tr><tr><td>LocalEmergency</td><td>A local emergency detected</td></tr><tr><td>LowInputPower</td><td>Low input power detected</td></tr><tr><td>OverCurrent</td><td>Overcurrent detected</td></tr><tr><td>OverFrequency</td><td>Over frequency detected</td></tr><tr><td>OverVoltage</td><td>Over voltage detected</td></tr><tr><td>PhaseRotation</td><td>Phase rotation detected</td></tr><tr><td>RemoteEmergency</td><td>A remote emergency detected</td></tr><tr><td>UnderFrequency</td><td>Under frequency detected</td></tr><tr><td>UnderVoltage</td><td>Under voltage detected</td></tr><tr><td>VoltageImbalance</td><td>Voltage imbalance detected</td></tr></table>
+
+# 3.51. HashAlgorithmEnumType
+
+Enumeration
+
+HashAlgorithmEnumType is used by: Common:CertificateHashDataType , Common:OCSPRequestDataType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>SHA256</td><td>SHA-256 hash algorithm.</td></tr><tr><td>SHA384</td><td>SHA-384 hash algorithm.</td></tr><tr><td>SHA512</td><td>SHA-512 hash algorithm.</td></tr></table>
+
+# 3.52. InstallCertificateStatusEnumType
+
+Enumeration
+
+InstallCertificateStatusEnumType is used by: installCertificate:InstallCertificateResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>The installation of the certificate succeeded.</td></tr><tr><td>Rejected</td><td>The certificate is invalid and/or incorrect OR the CSO tries to install more certificates than allowed.</td></tr><tr><td>Failed</td><td>The certificate is valid and correct, but there is another reason the installation did not succeed.</td></tr></table>
+
+# 3.53. InstallCertificateUseEnumType
+
+Enumeration
+
+InstallCertificateUseEnumType is used by: installCertificate:InstallCertificateRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>V2GRootCertificate</td><td>Use for certificate of the ISO 15118 V2G Root. A V2G Charging Station Certificate MUST be derived from one of the installed V2GRootCertificate certificates.</td></tr><tr><td>MORootCertificate</td><td>Use for certificate from an eMobility Service provider. To support PnC charging with contracts from service providers that not derived their certificates from the V2G root.</td></tr><tr><td>ManufacturerRootCertificate</td><td>Root certificate for verification of the Manufacturer certificate.</td></tr><tr><td>CSMSRootCertificate</td><td>Root certificate, used by the CA to sign the CSMS and Charging Station certificate.</td></tr><tr><td>OEMRootCertificate</td><td>(2.1) OEM root certificate for 2-way TLS with EV.</td></tr></table>
+
+# 3.54. IslandingDetectionEnumType
+
+Enumeration
+
+Methods of islanding detection
+
+IslandingDetectionEnumType is used by: Common:DERChargingParametersType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>NoAntiltsandingSup port</td><td>No anti-island detection supported</td></tr><tr><td>RoCoF</td><td>RoCoF - Rate of Change of Frequency</td></tr><tr><td>UVP_OVP</td><td>Under/over voltage (UVP/OVP)</td></tr><tr><td>UFP_OFp</td><td>Under/over frequency (UFP/OFP)</td></tr><tr><td>VoltageVectorShift</td><td>Voltage Vector Shift</td></tr><tr><td>ZeroCrossingDetecti on</td><td>Zero Crossing Detection</td></tr><tr><td>OtherPassive</td><td>Other passive anti-island detection method supported</td></tr><tr><td>ImpedanceMeasure ment</td><td>Impedance measurement</td></tr><tr><td>ImpedanceAtFreque ncy</td><td>Impedance detection at a specific frequency</td></tr><tr><td>SlipModeFrequency Shift</td><td>Slip-mode frequency shift</td></tr><tr><td>SandiaFrequencyShi ft</td><td>Frequency bias/Sandia frequency shift</td></tr><tr><td>SandiaVoltageShift</td><td>Sandia voltage shift</td></tr><tr><td>FrequencyJump</td><td>Frequency jump</td></tr><tr><td>RCLQFactor</td><td>RCL Q factor</td></tr><tr><td>OtherActive</td><td>Other active anti-island detection method supported</td></tr></table>
+
+# 3.55. Iso15118EVCertificateStatusEnumType
+
+Enumeration
+
+Iso15118EVCertificateStatusEnumType is used by: get15118EVCertificate:Get15118EVCertificateResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>exiResponse included. This is no indication whether the update was successful, just that the message was processed properly.</td></tr><tr><td>Failed</td><td>Processing of the message was not successful, no exiResponse included.</td></tr></table>
+
+# 3.56. LocationEnumType
+
+Enumeration
+
+Allowable values of the optional "location" field of a value element.
+
+LocationEnumType is used by: Common:SampledValueType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Body</td><td>Measurement inside body of Charging Station (e.g. Temperature).</td></tr><tr><td>Cable</td><td>Measurement taken from cable between EV and Charging Station.</td></tr><tr><td>EV</td><td>Measurement taken by EV.</td></tr><tr><td>Inlet</td><td>For the Charging Station (evseld = 0): measurement at network ("grid") inlet connection of the station. For measurements with evseld > 0, these are measurements taken at the EVSE inlet (This can be useful for a DC charger).</td></tr><tr><td>Outlet</td><td>Measurement at a Connector. Default value.</td></tr><tr><td>Upstream</td><td>(2.1) Measurement taken from an upstream local grid meter of the premise. This can be useful for charging stations that are connected "behind the meter" of a building, and that are able to read the building energy meter.</td></tr></table>
+
+# 3.57. LogEnumType
+
+Enumeration
+
+LogEnumType is used by: getLogGetLogRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>DiagnosticsLog</td><td>This contains the field definition of a diagnostics log file</td></tr><tr><td>SecurityLog</td><td>Sent by the CSMS to the Charging Station to request that the Charging Station uploads the security log.</td></tr><tr><td>DataCollectorLog</td><td>(2.1) The log of sampled measurements from the DataCollector component.</td></tr></table>
+
+# 3.58. logStatusEnumType
+
+Enumeration
+
+Generic message response status
+
+LogStatusEnumType is used by: getLogGetLogResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Accepted this log upload. This does not mean the log file is uploaded is successfully, the Charging Station will now start the log file upload.</td></tr><tr><td>Rejected</td><td>Log update request rejected.</td></tr><tr><td>AcceptedCanceled</td><td>Accepted this log upload, but in doing this has canceled an ongoing log file upload.</td></tr></table>
+
+# 3.59. MeasurandEnumType
+
+Enumeration
+
+Allowable values of the optional "measurand" field of a Value element, as used in MeterValuesRequest and TransactionEventRequest with eventTypes Started, Ended and Updated. Default value of "measurand" is always "Energy.Active.Import.Register".
+
+Note 1: Two measurands (Current.Offered and Power.Offered) are available that are strictly speaking no measured values. They indicate the maximum amount of current/power that is being offered to the EV and are intended for use in smart charging applications. The measurands with .Setpoint are not measured values, but are a value that should be followed as closely as possible.
+
+Note 2: Import is energy flow from the Grid to the Charging Station, EV or other load. Export is energy flow from the EV to the Charging Station and/or from the Charging Station to the Grid. Except in the case of a meter replacement, all "Register" values relating to a single charging transaction, or a non-transactional consumer (e.g. Charging Station internal power supply, overall supply) MUST be monotonically increasing in time.
+
+Note 3: The actual quantity of energy corresponding to a reported ".Register" value is computed as the register value in question minus the register value recorded/reported at the start of the transaction or other relevant starting reference point in time. For improved auditability, ".Register" values SHOULD be reported exactly as they are directly read from a non-volatile register in the electrical metering hardware, and SHOULD NOT be re-based to zero at the start of transactions. This allows any "missing energy" between sequential transactions, due to hardware fault, meter replacement, mis-wiring, fraud, etc. to be identified, by allowing the CSMS to confirm that the starting register value of any transaction is identical to the finishing register value of the preceding transaction on the same connector.
+
+Note 4: Measurands that have a direction as part of the name (.Import or .Export) have non-negative values. Measurands with .Setpoint, .Net or .Residual in the name can have negative values.
+
+Note 5: Measurands starting with Display represent the optional ISO 15118-20 DisplayParameters.
+
+MeasurandEnumType is used by: Common:SampledValueType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Current.Export</td><td>Instantaneous current flow from EV</td></tr><tr><td>Current.Export.Offered</td><td>(2.1) Maximum current EV is offered to export. Min(EV, EVSE)</td></tr><tr><td>Current.Export.Mini mum</td><td>(2.1) Minimum current EV can discharge with. Max(EV, EVSE)</td></tr><tr><td>Current.Import</td><td>Instantaneous current flow to EV</td></tr><tr><td>Current.Import.Offered</td><td>(2.1) Maximum current offered to EV.</td></tr><tr><td>Current.Import.Mini mum</td><td>(2.1) Minimum current EV can be charged with. Max(EV, EVSE).</td></tr><tr><td>Current.Offered</td><td>Maximum current offered to EV. Synonymous to Current.Import.Offered.</td></tr><tr><td>Display.PresentSOC</td><td>(2.1) Current state of charge of the EV battery.</td></tr><tr><td>Display.MinimumSOC</td><td>(2.1) Minimum State of Charge EV needs after charging of the EV battery the EV to keep throughout the charging session.</td></tr><tr><td>Display.TargetSOC</td><td>(2.1) Target State of Charge of the EV battery EV needs after charging.</td></tr><tr><td>Display.MaximumSOC</td><td>(2.1) The SOC at which the EV will prohibit any further charging.</td></tr><tr><td>Display.RemainingTimeToMinimumSOC</td><td>(2.1) The remaining time it takes to reach the minimum SOC. It is communicated as the offset in seconds from the point in time this value was received from EV.</td></tr><tr><td>Display.RemainingTimeToTargetSOC</td><td>(2.1) The remaining time it takes to reach the TargetSOC. It is communicated as the offset in seconds from the point in time this value was received from EV.</td></tr><tr><td>Display.RemainingTimeToMaximumSOC</td><td>(2.1) The remaining time it takes to reach the maximum SOC. It is communicated as the offset in seconds from the point in time this value was received from EV.</td></tr><tr><td>Display.ChargingComplete</td><td>(2.1) Indication if the charging is complete from EV point of view (value = 1).</td></tr><tr><td>Display.BatteryEnergyCapacity</td><td>(2.1) The calculated amount of electrical Energy in Wh stored in the battery when the displayed SOC equals 100%.</td></tr><tr><td>Display.InletHot</td><td>(2.1) Inlet temperature too high to accept specific operating condition.</td></tr><tr><td>Energy.Active.Expor tInterval</td><td>Absolute amount of "active electrical energy" (Wh or kWh) exported (to the grid) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for ClockAlignedDataInterval and TxnMeterValueSampleInterval.</td></tr><tr><td>Energy.Active.Expor t.Register</td><td>Numerical value read from the "active electrical energy" (Wh or kWh) register of the (most authoritative) electrical meter measuring energy exported (to the grid).</td></tr><tr><td>Energy.Active.Import tInterval</td><td>Absolute amount of "active electrical energy" (Wh or kWh) imported (from the grid supply) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for ClockAlignedDataInterval and TxnMeterValueSampleInterval.</td></tr><tr><td>Energy.Active.Import t.Register</td><td>Numerical value read from the "active electrical energy" (Wh or kWh) register of the (most authoritative) electrical meter measuring energy imported (from the grid supply).</td></tr><tr><td>Energy.Active.Import t.CableLoss</td><td>(2.1) Calculated energy loss after energy meter. Will be reset to 0 at start of transaction. Unit is Wh.</td></tr><tr><td>Energy.Active.Import t.LocalGeneration.R register</td><td>(2.1) Cumulative amount of imported energy that was from local generation. Value will be cumulative during a transaction, but is allowed to be reset to 0 at start of a transaction.</td></tr><tr><td>Energy.Active.Net</td><td>Numerical value read from the "net active electrical energy" (Wh or kWh) register.</td></tr><tr><td>Energy.Active.Setpoint Interval</td><td>(2.1) Energy during interval when Setpoint would be followed exactly, as calculated by Charging Station. Relevant when Setpoint changes frequently during an interval as result of LocalLoadBalancing or LocalFrequencyControl. Can be negative if energy was exported.</td></tr><tr><td>Energy.Apparent.Export</td><td>Numerical value read from the "apparent electrical export energy" (VAh or kVAh) register.</td></tr><tr><td>Energy.Apparent.Im port</td><td>Numerical value read from the "apparent electrical import energy" (VAh or kVAh) register.</td></tr><tr><td>Energy.Apparent.Net t</td><td>Numerical value read from the "apparent electrical energy" (VAh or kVAh) register.</td></tr><tr><td>Energy.Reactive.Export.Interval</td><td>Absolute amount of "reactive electrical energy" (varh or kvarh) exported (to the grid) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for ClockAlignedDataInterval and TxnMeterValueSampleInterval.</td></tr><tr><td>Energy.Reactive.ExportRegister</td><td>Numerical value read from the "reactive electrical energy" (varh or kvarh) register of the (most authoritative) electrical meter measuring energy exported (to the grid).</td></tr><tr><td>Energy.Reactive.Imp
+ortInterval</td><td>Absolute amount of "reactive electrical energy" (varh or kvarh) imported (from the grid supply) during an associated time "interval", specified by a Metervalues ReadingContext, and applicable interval duration configuration values (in seconds) for ClockAlignedDataInterval and TxnMeterValueSampleInterval.</td></tr><tr><td>Energy.Reactive.Imp
+ortRegister</td><td>Numerical value read from the "reactive electrical energy" (varh or kvarh) register of the (most authoritative) electrical meter measuring energy imported (from the grid supply).</td></tr><tr><td>Energy.Reactive.Net</td><td>Numerical value read from the "net reactive electrical energy" (varh or kvarh) register.</td></tr><tr><td>EnergyRequest.Targ
+et</td><td>(2.1) Energy to requested state of charge. (Wh)</td></tr><tr><td>EnergyRequest.Mini
+ mum</td><td>(2.1) Energy to minimum allowed state of charge. (Wh)</td></tr><tr><td>EnergyRequest.Maxi
+ mum</td><td>(2.1) Energy to maximum allowed state of charge. (Wh)</td></tr><tr><td>EnergyRequest.Mini
+ mum.V2X</td><td>(2.1) Energy to minimum state of charge for cycling (V2X) activity. Positive value means that current state of charge is below V2X range. (Wh)</td></tr><tr><td>EnergyRequest.Maxi
+ mum.V2X</td><td>(2.1) Energy to maximum state of charge for cycling (V2X) activity. Negative value means that current state of charge is above V2X range. (Wh)</td></tr><tr><td>EnergyRequest.Bulk</td><td>(2.1) Energy to end of bulk charging. (Wh)</td></tr><tr><td>Frequency</td><td>Instantaneous reading of powerline frequency.</td></tr><tr><td>Power.Active.Export</td><td>Instantaneous active power exported by EV. (W or kW)</td></tr><tr><td>Power.Active.Import</td><td>Instantaneous active power imported by EV. (W or kW)</td></tr><tr><td>Power.Active.Setpoint</td><td>(2.1) Power setpoint for charging or discharging (negative for discharging), that should be followed as close as possible.</td></tr><tr><td>Power.Active.Residu
+al</td><td>(2.1) Difference between the given charging setpoint and the actual power measured. Can be negative.</td></tr><tr><td>Power.Output.Minim
+ um</td><td>(2.1) Minimum power the EV can be discharged with. Max(EV, EVSE)</td></tr><tr><td>Power.Output.Offere
+ d</td><td>(2.1) Power offered to EV for discharging. Min(EV, EVSE)</td></tr><tr><td>Power.Factor</td><td>Instantaneous power factor of total energy flow</td></tr><tr><td>Power.Import.Offere
+ d</td><td>(2.1) Power offered to EV for charging. Min(EV, EVSE)</td></tr><tr><td>Power.Import.Minim
+ um</td><td>(2.1) Minimum power the EV can be charged with. Max(EV, EVSE)</td></tr><tr><td>Power.Offered</td><td>Maximum power offered to EV. Synonymous to Power.Import.Offered.</td></tr><tr><td>Power.Reactive.Exp
+ ort</td><td>Instantaneous reactive power exported by EV. (var or kvar)</td></tr><tr><td>Power.Reactive.Olf
+ ort</td><td>Instantaneous reactive power imported by EV. (var or kvar)</td></tr><tr><td>SoC</td><td>State of charge of charging vehicle in percentage</td></tr><tr><td>Voltage</td><td>Instantaneous DC or AC RMS supply voltage. For location = Inlet and evseld = 0: voltage at charging station grid connection. For_location_ = Outlet and evseld > 0: voltage at EVSE outlet towards the EV.</td></tr><tr><td>Voltage.Minimum</td><td>(2.1) Minimum voltage the EV can be charged or discharged with. Max(EV, EVSE)</td></tr><tr><td>Voltage.Maximum</td><td>(2.1) Maximum voltage the EV can be charged or discharged with. Min(EV, EVSE)</td></tr></table>
+
+# 3.60. MessageFormatEnumType
+
+Enumeration
+
+Format of a message to be displayed on the display of the Charging Station.
+
+MessageFormatEnumType is used by: Common:MessageContentType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ASCII</td><td>Message content is ASCII formatted, only 7-bit printable ASCII allowed.</td></tr><tr><td>HTML</td><td>Message content is HTML formatted.</td></tr><tr><td>URI</td><td>Message content is URI that Charging Station should download and use to display. for example a HTML page to be shown in a web-browser.</td></tr><tr><td>UTF8</td><td>Message content is UTF-8 formatted.</td></tr><tr><td>QRCODE</td><td>Message content is a text (usually a URL) that Charging Station will display as a QR code on the display. Note: this is not a dynamic QR code and should not be used for payments.</td></tr></table>
+
+# 3.61. MessagePriorityEnumType
+
+Enumeration
+
+Priority with which a message should be displayed on a Charging Station.
+
+MessagePriorityEnumType is used by: Common:MessageInfoType, getDisplayMessages:GetDisplayMessagesRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>AlwaysFront</td><td>Show this message always in front. Highest priority, don’t cycle with other messages. When a newer message with this MessagePriority is received, this message is replaced. No Charging Station own message may override this message.</td></tr><tr><td>InFront</td><td>Show this message in front of the normal cycle of messages. When more messages with this priority are to be shown, they SHALL be cycled.</td></tr><tr><td>NormalCycle</td><td>Show this message in the cycle of messages.</td></tr></table>
+
+# 3.62. MessageStateEnumType
+
+Enumeration
+
+State of the Charging Station during which a message SHALL be displayed.
+
+MessageStateEnumType is used by: Common:MessageInfoType, getDisplayMessages:GetDisplayMessagesRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Charging</td><td>Message only to be shown while the Charging Station is charging.</td></tr><tr><td>Faulted</td><td>Message only to be shown while the Charging Station is in faulted state.</td></tr><tr><td>Idle</td><td>Message only to be shown while the Charging Station is idle (no transaction active).</td></tr><tr><td>Unavailable</td><td>Message only to be shown while the Charging Station is in unavailable state.</td></tr><tr><td>Suspended</td><td>(2.1) Message only to be shown when Charging Station (or EV) has suspending the charging during a transaction.</td></tr><tr><td>Discharging</td><td>(2.1) Message only to be shown while the EV is discharging.</td></tr></table>
+
+# 3.63. MessageTriggerEnumType
+
+Enumeration
+
+Type of request to be triggered by trigger messages.
+
+MessageTriggerEnumType is used by: triggerMessage:TriggerMessageRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>BootNotification</td><td>To trigger BootNotification.</td></tr><tr><td>LogStatusNotification</td><td>To trigger LogStatusNotification.</td></tr><tr><td>FirmwareStatusNotification</td><td>To trigger FirmwareStatusNotification.</td></tr><tr><td>Heartbeat</td><td>To trigger Heartbeat.</td></tr><tr><td>MeterValues</td><td>To trigger MeterValues.</td></tr><tr><td>SignChargingStation Certificate</td><td>To trigger a SignCertificate with typeOfCertificate: ChargingStationCertificate.</td></tr><tr><td>SignV2GCertificate</td><td>To trigger a SignCertificate with typeOfCertificate: V2GCertificate</td></tr><tr><td>SignV2G20Certificate</td><td>(2.1) Same as SignV2GCertificate, but this triggers Charging Station explicitly to only sign V2G certificate for ISO 15118-20.</td></tr><tr><td>StatusNotification</td><td>To trigger StatusNotification.</td></tr><tr><td>TransactionEvent</td><td>To trigger TransactionEvent.</td></tr><tr><td>SignCombinedCertificate</td><td>To trigger a SignCertificate with typeOfCertificate: ChargingStationCertificate AND V2GCertificate</td></tr><tr><td>PublishFirmwareStatusNotification</td><td>To trigger PublishFirmwareStatusNotification.</td></tr><tr><td>CustomTrigger</td><td>(2.1) To trigger the message referred to in customTrigger field.</td></tr></table>
+
+# 3.64. MobilityNeedsModeEnumType
+
+Enumeration
+
+(2.1) ISO 15118-20 service parameter for mobility needs mode.
+
+MobilityNeedsModeEnumType is used by: Common:ChargingNeedsType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>EVCC</td><td>Only EV determines min/target SOC and departure time.</td></tr><tr><td>EVCC_SECC</td><td>Charging station or CSMS may also update min/target SOC and departure time.</td></tr></table>
+
+# 3.65. MonitorEnumType
+
+Enumeration
+
+MonitorEnumType is used by: Common:VariableMonitoringType,
+setVariableMonitoring:SetVariableMonitoringRequest.SetMonitoringDataType,
+setVariableMonitoring:setVariableMonitoringResponse.SetMonitoringResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>UpperThreshold</td><td>Triggers an event notice when the actual value of the Variable rises above value.</td></tr><tr><td>LowerThreshold</td><td>Triggers an event notice when the actual value of the Variable drops below value.</td></tr><tr><td>Delta</td><td>Triggers an event notice when the actual value has changed more than plus or minus value since the time that this monitor was set or since the last time this event notice was sent, whichever was last. For variables that are not numeric, like boolean, string or enumerations, a monitor of type Delta will trigger an event notice whenever the variable changes, regardless of the value of value.</td></tr><tr><td>Periodic</td><td>Triggers an event notice every value seconds interval, starting from the time that this monitor was set.</td></tr><tr><td>PeriodicClockAligne-d</td><td>Triggers an event notice every value seconds interval, starting from the nearest clock-aligned interval after this monitor was set. For example, a value of 900 will trigger event notices at 0, 15, 30 and 45 minutes after the hour, every hour.</td></tr><tr><td>TargetDelta</td><td>(2.1) Triggers an event notice when the actual value differs from the target value more than plus or minus value since the time that this monitor was set or since the last time this event notice was sent, whichever was last. Behavior of this type of monitor for a variable that is not numeric, is not defined. Example: when target = 100, value = 10, then an event is triggered when actual < 90 or actual > 110.</td></tr><tr><td>TargetDeltaRelative</td><td>(2.1) Triggers an event notice when the actual value differs from the target value more than plus or minus (value * target value) since the time that this monitor was set or since the last time this event notice was sent, whichever was last. Behavior of this type of monitor for a variable that is not numeric, is not defined. Example: when target = 100, value = 0.1, then an event is triggered when actual < 90 or actual > 110.</td></tr></table>
+
+# 3.66. MonitoringBaseEnumType
+
+Enumeration
+
+MonitoringBaseEnumType is used by: setMonitoringBase:SetMonitoringBaseRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>All</td><td>Activate all pre-configured monitors while leaving custom monitors intact, including those that overrule a pre-configured monitor.</td></tr><tr><td>FactoryDefault</td><td>(Re)activate the default monitors of the charging station and remove all custom monitors.</td></tr><tr><td>HardWiredOnly</td><td>Removes all custom monitors and disables all pre-configured monitors.</td></tr></table>
+
+# 3.67. MonitoringCriterionEnumType
+
+Enumeration
+
+MonitoringCriterionEnumType is used by: getMonitoringReport:GetMonitoringRequestRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ThresholdMonitorin g</td><td>Report variables and components with a monitor of type UpperThreshold or LowerThreshold.</td></tr><tr><td>DeltaMonitoring</td><td>Report variables and components with a monitor of type Delta.</td></tr><tr><td>PeriodicMonitoring</td><td>Report variables and components with a monitor of type Periodic or PeriodicClockAligned.</td></tr></table>
+
+# 3.68. MutabilityEnumType
+
+Enumeration
+
+MutabilityEnumType is used by: Common:VariableAttributeType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ReadOnly</td><td>This variable is read-only.</td></tr><tr><td>WriteOnly</td><td>This variable is write-only.</td></tr><tr><td>ReadWrite</td><td>This variable is read-write.</td></tr></table>
+
+# 3.69. NotifyAllowedEnergyTransferStatusEnumType
+
+Enumeration
+
+(2.1) Status result of a NotifyAllowedEnergyTransferRequest
+
+NotifyAllowedEnergyTransferStatusEnumType is used by: notifyAllowedEnergyTransfer:NotifyAllowedEnergyTransferResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request has been accepted.</td></tr><tr><td>Rejected</td><td>Request has been rejected. Should not occur, unless there are some technical problems.</td></tr></table>
+
+# 3.70. NotifyEVChargingNeedsStatusEnumType
+
+Enumeration
+
+NotifyEVChargingNeedsStatusEnumType is used by: notifyEVChargingNeeds:NotifyEVChargingNeedsResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>A schedule will be provided momentarily.</td></tr><tr><td>Rejected</td><td>(2.1) Service not available. No charging profile can be provided. For an ISO 15118-20 session this is used to convey that the requested energy transfer type is not possible.</td></tr><tr><td>Processing</td><td>The CSMS is gathering information to provide a schedule.</td></tr><tr><td>NoChargingProfile</td><td>(2.1) CSMS will not provide a charging profile at this time. CS should not wait for it. For an ISO 15118-20 session this value is used instead of Rejected to differentiate between the situation where no charging profile is available (NoChargingProfile) and requested energy transfer type is not available (Rejected).</td></tr></table>
+
+# 3.71. OCPPInterfaceEnumType
+
+Enumeration
+
+Enumeration of network interfaces.
+
+OCPPInterfaceEnumType is used by: setNetworkProfile:SetNetworkProfileRequest.NetworkConnectionProfileType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Wired0</td><td>Use wired connection 0</td></tr><tr><td>Wired1</td><td>Use wired connection 1</td></tr><tr><td>Wired2</td><td>Use wired connection 2</td></tr><tr><td>Wired3</td><td>Use wired connection 3</td></tr><tr><td>Wireless0</td><td>Use wireless connection 0</td></tr><tr><td>Wireless1</td><td>Use wireless connection 1</td></tr><tr><td>Wireless2</td><td>Use wireless connection 2</td></tr><tr><td>Wireless3</td><td>Use wireless connection 3</td></tr><tr><td>Any</td><td>(2.1) Use any interface.</td></tr></table>
+
+# 3.72. OCPPTransportEnumType
+
+Enumeration
+
+Enumeration of OCPP transport mechanisms. SOAP is currently not a valid value for OCPP 2.0.
+
+OCPPTransportEnumType is used by: setNetworkProfile:SetNetworkProfileRequest.NetworkConnectionProfileType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>SOAP</td><td>Use SOAP for transport of OCPP PDU's</td></tr><tr><td>JSON</td><td>Use JSON over WebSockets for transport of OCPP PDU's</td></tr></table>
+
+# 3.73. OCPPVersionEnumType
+
+Enumeration
+
+Enumeration of OCPP versions.
+
+OCPPVersionEnumType is used by: setNetworkProfile:SetNetworkProfileRequest.NetworkConnectionProfileType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>OCPP12</td><td>OCPP version 1.2</td></tr><tr><td>OCPP15</td><td>OCPP version 1.5</td></tr><tr><td>OCPP16</td><td>OCPP version 1.6, websocket subprotocol: ocpp1 . 6</td></tr><tr><td>OCPP20</td><td>No longer in use. The OCPP 2.0 release of OCPP has been withdrawn. The value OCPP20 is treated as OCPP2.0.1.</td></tr><tr><td>OCPP201</td><td>OCPP version 2.0.1, websocket subprotocol: ocpp2 . 0 . 1</td></tr><tr><td>OCPP21</td><td>(2.1) OCPP version 2.1, websocket subprotocol: ocpp2 . 1</td></tr></table>
+
+# 3.74. OperationalStatusEnumType
+
+Enumeration
+
+Requested availability change.
+
+OperationalStatusEnumType is used by: changeAvailability:ChangeAvailabilityRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Inoperative</td><td>Charging Station is not available for charging.</td></tr><tr><td>Operative</td><td>Charging Station is available for charging.</td></tr></table>
+
+# 3.75. OperationModeEnumType
+
+Enumeration
+
+(2.1) Operation mode for (bi-)directional charging during a charging schedule period.
+
+OperationModeEnumType is used by: Common:ChargingSchedulePeriodType, Common:TransactionType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Idle</td><td>Minimize energy consumption by having the EV either on standby or in sleep.</td></tr><tr><td>ChargingOnly</td><td>Classic charging or smart charging mode. (default)</td></tr><tr><td>CentralSetpoint</td><td>Control of setpoint by CSMS or some secondary actor that relays through the CSMS.</td></tr><tr><td>ExternalSetpoint</td><td>Control of setpoint by an external actor directly on the Charging Station.</td></tr><tr><td>ExternalLimits</td><td>Control of (dis)charging limits by an external actor on the Charging Station.</td></tr><tr><td>CentralFrequency</td><td>Frequency support with control by CSMS or some secondary actor that relays through the CSMS.</td></tr><tr><td>LocalFrequency</td><td>Frequency support with control in the Charging Station.</td></tr><tr><td>LocalLoadBalancing</td><td>Load-balancing performed by the Charging Station.</td></tr></table>
+
+# 3.76. PaymentStatusEnumType
+
+Enumeration
+
+(2.1) Status of the settlement of an ad hoc payment.
+
+PaymentStatusEnumType is used by: notifySettlement:NotifySettlementRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Settled</td><td>Settled successfully by the PSP.</td></tr><tr><td>Canceled</td><td>No billable part of the OCPP transaction, cancelation sent to the PSP.</td></tr><tr><td>Rejected</td><td>Rejected by the PSP.</td></tr><tr><td>Failed</td><td>Sent after the final attempt that fails due to communication problems.</td></tr></table>
+
+# 3.77. PhaseEnumType
+
+Enumeration
+
+Phase specifies how a measured value is to be interpreted. Please note that not all values of Phase are applicable to all Measurands.
+
+PhaseEnumType is used by: Common:SampledValueType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>L1</td><td>Measured on L1</td></tr><tr><td>L2</td><td>Measured on L2</td></tr><tr><td>L3</td><td>Measured on L3</td></tr><tr><td>N</td><td>Measured on Neutral</td></tr><tr><td>L1-N</td><td>Measured on L1 with respect to Neutral conductor</td></tr><tr><td>L2-N</td><td>Measured on L2 with respect to Neutral conductor</td></tr><tr><td>L3-N</td><td>Measured on L3 with respect to Neutral conductor</td></tr><tr><td>L1-L2</td><td>Measured between L1 and L2</td></tr><tr><td>L2-L3</td><td>Measured between L2 and L3</td></tr><tr><td>L3-L1</td><td>Measured between L3 and L1</td></tr></table>
+
+# 3.78. PowerDuringCessationEnumType
+
+Enumeration
+
+PowerDuringCessationEnumType is used by: Common:VoltageParamsType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Active</td><td>Active power</td></tr><tr><td>Reactive</td><td>Reactive power</td></tr></table>
+
+# 3.79. Preconditioning statusesylumType
+
+Enumeration
+
+(2.1) Preconditioning status of the battery
+
+PreconditioningStatusEnumType is used by: transactionEvent:TransactionRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Unknown</td><td>No information available on the status of preconditioning</td></tr><tr><td>Ready</td><td>The battery is preconditioned and ready to react directly on a given setpoint for charging (and discharging when available).</td></tr><tr><td>NotReady</td><td>Busy with preconditioning the BMS. When done will move to status Ready.</td></tr><tr><td>Preconditioning</td><td>The battery is not preconditioned and not able to directly react to given setpoint.</td></tr></table>
+
+# 3.80. PriorityChargingStatusEnumType
+
+Enumeration
+
+(2.1) Status of a UsePriorityChargingRequest
+
+PriorityChargingStatusEnumType is used by: usePriorityCharging:UsePriorityChargingResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Request has been accepted.</td></tr><tr><td>Rejected</td><td>Request has been rejected.</td></tr><tr><td>NoProfile</td><td>No priority charging profile present.</td></tr></table>
+
+# 3.81. PublishFirmwareStatusEnumType
+
+Enumeration
+
+Status for when publishing a Firmware.
+
+PublishFirmwareStatusEnumType is used by: publishFirmwareStatusNotification:PublishFirmwareStatusNotificationRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Idle</td><td></td></tr><tr><td>DownloadScheduled</td><td>Intermediate state. Downloading of new firmware has been scheduled.</td></tr><tr><td>Downloading</td><td>Intermediate state. Firmware is being downloaded.</td></tr><tr><td>Downloaded</td><td>Intermediate state. New firmware has been downloaded by Charging Station.</td></tr><tr><td>Published</td><td>The firmware has been successfully published.</td></tr><tr><td>DownloadFailed</td><td>Failure end state. Charging Station failed to download firmware.</td></tr><tr><td>DownloadPaused</td><td>Intermediate state. Downloading has been paused.</td></tr><tr><td>InvalidChecksum</td><td>Failure end state. The firmware checksum is not matching.</td></tr><tr><td>ChecksumVerified</td><td>Intermediate state. The Firmware checksum is successfully verified.</td></tr><tr><td>PublishFailed</td><td>Publishing the new firmware has failed.</td></tr></table>
+
+# 3.82. ReadingContextEnumType
+
+Enumeration
+
+Values of the context field.
+
+ReadingContextEnumType is used by: Common:SampledValueType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Interruption.Begin</td><td>Value taken at start of interruption.</td></tr><tr><td>Interruption.End</td><td>Value taken when resuming after interruption.</td></tr><tr><td>Other</td><td>Value for any other situations.</td></tr><tr><td>Sample.Clock</td><td>Value taken at clock aligned interval.</td></tr><tr><td>Sample.Periodic</td><td>Value taken as periodic sample relative to start time of transaction.</td></tr><tr><td>Transaction.Begin</td><td>Value taken at start of transaction.</td></tr><tr><td>Transaction.End</td><td>Value taken at end of transaction.</td></tr><tr><td>Trigger</td><td>Value taken in response to TriggerMessageRequest.</td></tr></table>
+
+# 3.83. ReasonEnumType
+
+Enumeration
+
+Reason for stopping a transaction.
+
+Each reason has a (Failed) or (Successful) label, that indicates whether this situation refers to a failed or successful charging session according to Charging Station. There may be situations, though, where a transaction is ended normally (e.g. stoppedReason = Local), but no energy was delivered because of a failure in EVSE or EV.
+
+ReasonEnumType is used by: Common:TransactionType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>DeAuthorized</td><td>The transaction was stopped because of the authorization status in the response to a TransactionRequest. (Failed)</td></tr><tr><td>EmergencyStop</td><td>Emergency stop button was used. (Failed)</td></tr><tr><td>EnergyLimitReached</td><td>(2.1) Deprecated, because it stops energy transfer, not the transaction.
+EV charging session reached a locally enforced maximum energy transfer limit. (Successful)</td></tr><tr><td>EVDisconnected</td><td>Disconnecting of cable, vehicle moved away from inductive charge unit. (Successful)</td></tr><tr><td>GroundFault</td><td>A GroundFault has occurred. (Failed)</td></tr><tr><td>ImmediateReset</td><td>A Reset(Immediate) command was received. (Failed)</td></tr><tr><td>MasterPass</td><td>The transaction was stopped using a token that belongs to the MasterPassGroupld. (Successful)</td></tr><tr><td>Local</td><td>Stopped locally on request of the EV Driver at the Charge Point. This is a regular termination of a transaction.
+Examples: presenting an IdToken tag, pressing a button to stop. (Successful)</td></tr><tr><td>LocalOutOfCredit</td><td>(2.1) Deprecated, because it stops energy transfer, not the transaction.A local credit limit enforced through the Charging Station has been exceeded. (Successful)</td></tr><tr><td>Other</td><td>Any other reason. (Failed)</td></tr><tr><td>OvercurrentFault</td><td>A larger than intended electric current has occurred. (Failed)</td></tr><tr><td>PowerLoss</td><td>Complete loss of power. (Failed)</td></tr><tr><td>PowerQuality</td><td>Quality of power too low, e.g. voltage too low/high, phase imbalance, etc. (Failed)</td></tr><tr><td>Reboot</td><td>A locally initiated reset/reboot occurred. (for instance watchdog kicked in). (Failed)</td></tr><tr><td>Remote</td><td>Stopped remotely on request of the CSMS. This is a regular termination of a transaction. Examples:termination using a smartphone app, exceeding a (non local) prepaid credit. (Successful)</td></tr><tr><td>SOCLimitReached</td><td>(2.1) Deprecated, because it stops energy transfer, not the transaction.Electric vehicle has reported reaching a locally enforced maximum battery State of Charge (SOC).(Successful)</td></tr><tr><td>StoppedByEV</td><td>The transaction was stopped by the EV. (Successful)</td></tr><tr><td>TimeLimitReached</td><td>(2.1) Deprecated, because it stops energy transfer, not the transaction.EV charging session reached a locally enforced time limit. (Successful)</td></tr><tr><td>Timeout</td><td>EV not connected within timeout. (Failed)</td></tr><tr><td>ReqEnergyTransferR ejected</td><td>(2.1) CSMS cannot accept the requested energy transfer type. (Failed)</td></tr></table>
+
+# 3.84. RecurrencyKindEnumType
+
+Enumeration
+
+ConcurrencyKindEnumType is used by: Common:ChargingProfileType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Daily</td><td>The schedule restarts every 24 hours, at the same time as in the startSchedule.</td></tr><tr><td>Weekly</td><td>The schedule restarts every 7 days, at the same time and day-of-the-week as in the startSchedule.</td></tr></table>
+
+# 3.85. RegistrationStatusEnumType
+
+Enumeration
+
+Result of registration in response to BootNotificationRequest.
+
+RegistrationStatusEnumType is used by: bootNotification:BootNotificationResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Charging Station is accepted by the CSMS.</td></tr><tr><td>Pending</td><td>CSMS is not yet ready to accept the Charging Station. CSMS may send messages to retrieve information or prepare the Charging Station.</td></tr><tr><td>Rejected</td><td>Charging Station is not accepted by CSMS. This may happen when the Charging Station id is not known by CSMS.</td></tr></table>
+
+# 3.86.ReportBaseEnumType
+
+Enumeration
+
+ReportBaseEnumType is used by: getBaseReport:GetBaseRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ConfigurationInvent-ory</td><td>Required. A (configuration) report that lists all Components/Variables that can be set by the operator.</td></tr><tr><td>FullInventory</td><td>Required. A (full) report that lists everything except monitoring settings.</td></tr><tr><td>SummaryInventory</td><td>Optional. A (summary) report that lists Components/Variables relating to the Charging Station's current charging availability, and to any existing problem conditions.For the Charging Station Component:- AvailabilityState.For each EVSE Component:- AvailabilityState.For each Connector Component:- AvailabilityState (if known and different from EVSE).For all Components in an abnormal State:- Active (Problem, Tripped, Overload, Failback) variables.- Any other diagnostically relevant Variables of the Components.- Include TechCode and TechInfo where available.All monitored Component.Variablesin Critical or Alert state shall also be included.- Charging Stations that do not have Monitoring implemented are NOT REQUIRED to include Connector Availability, monitoring alerts, and MAY limit problem reporting detail to just the active Problem boolean Variable.</td></tr></table>
+
+# 3.87. RequestStartStopStatusEnumType
+
+Enumeration
+
+The result of a RequestStartTransactionRequest or RequestStopTransactionRequest.
+
+RequestStartStopStatusEnumType is used by: requestStartTransaction:RequestStartTransactionResponse, requestStopTransaction:RequestStopTransactionResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Command will be executed.</td></tr><tr><td>Rejected</td><td>Command will not be executed.</td></tr></table>
+
+# 3.88. ReservationUpdateStatusEnumType
+
+Enumeration
+
+ReservationUpdateStatusEnumType is used by: reservationStatusUpdate:ReservationStatusUpdateRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Expired</td><td>The reservation is expired.</td></tr><tr><td>Removed</td><td>The reservation is removed.</td></tr><tr><td>NoTransaction</td><td>(2.1) The reservation was used, but no transaction was started.</td></tr></table>
+
+# 3.89. ReserveNowStatusEnumType
+
+Enumeration
+
+Status in ReserveNowResponse.
+
+ReserveNowStatusEnumType is used by: reserveNow:ReserveNowResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Reservation has been made.</td></tr><tr><td>Faulted</td><td>Reservation has not been made, because evse, connectors or specified connector are in a faulted state.</td></tr><tr><td>Occupied</td><td>Reservation has not been made. The evse or the specified connector is occupied.</td></tr><tr><td>Rejected</td><td>Reservation has not been made. Charging Station is not configured to accept reservations.</td></tr><tr><td>Unavailable</td><td>Reservation has not been made, because evse, connectors or specified connector are in an unavailable state.</td></tr></table>
+
+# 3.90. ResetEnumType
+
+Enumeration
+
+Type of reset requested.
+
+ResetEnumType is used by: reset:ResetRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Immediate</td><td>Immediate reset of the Charging Station or EVSE.</td></tr><tr><td>OnIdle</td><td>Delay reset until no more transactions are active.</td></tr><tr><td>ImmediateAndResume</td><td>(2.1) Immediate reset and resume transaction(s) afterwards</td></tr></table>
+
+# 3.91. ResetStatusEnumType
+
+Enumeration
+
+Result of ResetRequest.
+
+ResetStatusEnumType is used by: reset:ResetResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Command will be executed.</td></tr><tr><td>Rejected</td><td>Command will not be executed.</td></tr><tr><td>Scheduled</td><td>Reset command is scheduled, Charging Station is busy with a process that cannot be interrupted at the moment. Reset will be executed when process is finished.</td></tr></table>
+
+# 3.92. SendLocalListStatusEnumType
+
+Enumeration
+
+Type of update for SendLocalListRequest.
+
+SendLocalListStatusEnumType is used by: sendLocalList:SendLocalListResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Local Authorization List successfully updated.</td></tr><tr><td>Failed</td><td>Failed to update the Local Authorization List.</td></tr><tr><td>VersionMismatch</td><td>Version number in the request for a differential update is less or equal then version number of current list.</td></tr></table>
+
+# 3.93. SetMonitoringStatusEnumType
+
+Enumeration
+
+SetMonitoringStatusEnumType is used by: setVariableMonitoring:SetVariableMonitoringResponse.SetMonitoringResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Monitor successfully set.</td></tr><tr><td>UnknownComponent</td><td>Component is not known.</td></tr><tr><td>UnknownVariable</td><td>Variable is not known.</td></tr><tr><td>UnsupportedMonitor Type</td><td>Requested monitor type is not supported.</td></tr><tr><td>Rejected</td><td>Request is rejected.</td></tr><tr><td>Duplicate</td><td>A monitor already exists for the given type/severity combination.</td></tr></table>
+
+# 3.94. SetNetworkProfileStatusEnumType
+
+Enumeration
+
+Possible values of SetNetworkProfileStatus as used in SetNetworkProfileResponse.
+
+SetNetworkProfileStatusEnumType is used by: setNetworkProfile:SetNetworkProfileResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Setting new data successful</td></tr><tr><td>Rejected</td><td>Setting new data rejected</td></tr><tr><td>Failed</td><td>Setting new data failed</td></tr></table>
+
+# 3.95. SetVariable statusesEnumType
+
+Enumeration
+
+SetVariableStatusEnumType is used by: setVariables:SetVariablesResponse.SetVariableResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Variable successfully set.</td></tr><tr><td>Rejected</td><td>Request is rejected.</td></tr><tr><td>UnknownComponent</td><td>Component is not known.</td></tr><tr><td>UnknownVariable</td><td>Variable is not known.</td></tr><tr><td>NotSupportedAttributeType</td><td>The AttributeType is not supported.</td></tr><tr><td>RebootRequired</td><td>A reboot is required.</td></tr></table>
+
+# 3.96. TariffChangeStatusEnumType
+
+Enumeration
+
+TariffChangeStatusEnumType is used by: changeTransactionTariff:ChangeTransactionTariffResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Tariff has been accepted.</td></tr><tr><td>Rejected</td><td>Tariff has been rejected. More info in statusInfo.</td></tr><tr><td>TooManyElements</td><td>Tariff has too many elements and cannot be processed.</td></tr><tr><td>ConditionNotSupported</td><td>A condition is not supported, or conditions are not supported at all.</td></tr><tr><td>TxNotFound</td><td>Transaction does not exist or has already ended</td></tr><tr><td>NoCurrencyChange</td><td>Cannot change currency during a transaction</td></tr></table>
+
+# 3.97. TariffClearStatusEnumType
+
+Enumeration
+
+TariffClearStatusEnumType is used by: Common:ClearTariffsResultType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Clearing tariff has been accepted.</td></tr><tr><td>Rejected</td><td>Clearing tariff has been rejected. More info in statusInfo.</td></tr><tr><td>NoTariff</td><td>No tariff for EVSE of IdToken</td></tr></table>
+
+# 3.98. TariffCostEnumType
+
+Enumeration
+
+Type of cost: normal cost calculation, or limited to a min or max value.
+
+TariffCostEnumType is used by: Common:TotalCostType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>NormalCost</td><td>Cost is result of normal cost calculation.</td></tr><tr><td>MinCost</td><td>Cost is the minimum cost for this tariff.</td></tr><tr><td>MaxCost</td><td>Cost is the maximum cost for this tariff.</td></tr></table>
+
+# 3.99. TariffGetStatusEnumType
+
+Enumeration
+
+TariffGetStatusEnumType is used by: getTariffs:GetTariffsResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Tariff has been accepted.</td></tr><tr><td>Rejected</td><td>Tariff has been rejected. More info in statusInfo.</td></tr><tr><td>NoTariff</td><td>No tariff present on Charging Station or EVSE.</td></tr></table>
+
+# 3.100. TariffKindEnumType
+
+Enumeration
+
+TariffKindEnumType is used by: Common:TariffAssignmentType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>DefaultTariff</td><td>Default tariff</td></tr><tr><td>DriverTariff</td><td>Driver-specific tariff</td></tr></table>
+
+# 3.101. TariffSet statusesEnumType
+
+Enumeration
+
+TariffSetStatusEnumType is used by: setDefaultTariff:SetDefaultTariffResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Tariff has been accepted.</td></tr><tr><td>Rejected</td><td>Tariff has been rejected. More info in statusInfo.</td></tr><tr><td>TooManyElements</td><td>Tariff has too many elements and cannot be processed.</td></tr><tr><td>ConditionNotSupported</td><td>A condition is not supported, or conditions are not supported at all.</td></tr><tr><td>DuplicateTariffId</td><td>TariffId already exists in Charging Station.</td></tr></table>
+
+# 3.102. TransactionEventEnumType
+
+Enumeration
+
+TransactionEventEnumType is used by: transactionEvent:TransactionRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Ended</td><td>Last event of a transaction</td></tr><tr><td>Started</td><td>First event of a transaction.</td></tr><tr><td>Updated</td><td>Transaction event in between 'Started' and 'Ended'.</td></tr></table>
+
+# 3.103. TriggerMessageStatusEnumType
+
+Enumeration
+
+Status in TriggerMessageResponse.
+
+TriggerMessageStatusEnumType is used by: triggerMessage:TriggerMessageResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Requested message will be sent.</td></tr><tr><td>Rejected</td><td>Requested message will not be sent.</td></tr><tr><td>NotImplemented</td><td>Requested message cannot be sent because it is either not implemented or unknown.</td></tr></table>
+
+# 3.104. TriggerReasonEnumType
+
+Enumeration
+
+Reason that triggered a transactionEventRequest.
+
+TriggerReasonEnumType is used by: transactionEvent:TransactionRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>AbnormalCondition</td><td>An Abnormal Error or Fault Condition has occurred.</td></tr><tr><td>Authorized</td><td>Charging is authorized, by any means. Might be an RFID, or other authorization means.</td></tr><tr><td>CablePluggedIn</td><td>Cable is plugged in and EVDetected.</td></tr><tr><td>ChargingRateChanged</td><td>Rate of charging changed by more than LimitChangeSignificance by an external actor (e.g. an EMS).</td></tr><tr><td>ChargingStateChanged</td><td>Charging State changed.</td></tr><tr><td>CostLimitReached</td><td>(2.1) Maximum cost has been reached, as defined by transactionLimit.maxCost.</td></tr><tr><td>Deauthorized</td><td>The transaction was stopped because of the authorization status in the response to a transactionEventRequest.</td></tr><tr><td>EnergyLimitReached</td><td>Maximum energy of charging reached as defined by transactionLimit.maxEnergy.</td></tr><tr><td>EVCommunicationLost</td><td>Communication with EV lost, for example: cable disconnected.</td></tr><tr><td>EVConnectTimeout</td><td>EV not connected before the connection is timed out.</td></tr><tr><td>EVDeparted</td><td>EV departed. For example: When a departing EV triggers a parking bay detector.</td></tr><tr><td>EVDetected</td><td>EV detected. For example: When an arriving EV triggers a parking bay detector.</td></tr><tr><td>LimitSet</td><td>(2.1) Limit of cost/time/energy/SoC for transaction has set or changed.</td></tr><tr><td>MeterValueClock</td><td>Needed to send a clock aligned meter value</td></tr><tr><td>MeterValuePeriodic</td><td>Needed to send a periodic meter value</td></tr><tr><td>OperationModeChanged</td><td>(2.1) V2X operation mode has changed (at start of a new charging schedule period).</td></tr><tr><td>RemoteStart</td><td>A RequestStartTransactionRequest has been sent.</td></tr><tr><td>RemoteStop</td><td>A RequestStopTransactionRequest has been sent.</td></tr><tr><td>ResetCommand</td><td>CSMS sent a Reset Charging Station command.</td></tr><tr><td>RunningCost</td><td>(2.1) Trigger used when TransactionEvent is sent (only) to report a running cost update.</td></tr><tr><td>SignedDataReceived</td><td>Signed data is received from the energy meter.</td></tr><tr><td>SoCLimitReached</td><td>(2.1) State of charge limit has been reached, as defined by transactionLimit.maxSoC.</td></tr><tr><td>StopAuthorized</td><td>An EV Driver has been authorized to stop charging. For example: By swiping an RFID card.</td></tr><tr><td>TariffChanged</td><td>(2.1) Tariff for transaction has changed.</td></tr><tr><td>TariffNotAccepted</td><td>(2.1) Trigger to notify that EV Driver has not accepted the tariff for transaction. idToken becomes deauthorized.</td></tr><tr><td>TimeLimitReached</td><td>(2.1) Maximum time of charging reached, as defined by transactionLimit.maxTime.</td></tr><tr><td>Trigger</td><td>Requested by the CSMS via a TriggerMessageRequest.</td></tr><tr><td>TxResumed</td><td>(2.1) Transaction has resumed after reset or power outage.</td></tr><tr><td>UnlockCommand</td><td>CSMS sent an Unlock Connector command.</td></tr></table>
+
+# 3.105. UnlockStatusEnumType
+
+Enumeration
+
+Status in response to UnlockConnectorRequest.
+
+UnlockStatusEnumType is used by: unlockConnector:UnlockConnectorResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Unlocked</td><td>Connector has successfully been unlocked.</td></tr><tr><td>UnlockFailed</td><td>Failed to unlock the connector.</td></tr><tr><td>OngoingAuthorizedTransaction</td><td>The connector is not unlocked, because there is still an authorized transaction ongoing.</td></tr><tr><td>UnknownConnector</td><td>The specified connector is not known by the Charging Station.</td></tr></table>
+
+# 3.106. UnpublishFirmwareStatusEnumType
+
+Enumeration
+
+Status for when publishing a Firmware.
+
+UnpublishFirmwareStatusEnumType is used by: unpublishedFirmware:UnpublishFirmwareResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>DownloadOngoing</td><td>Intermediate state. Firmware is being downloaded.</td></tr><tr><td>NoFirmware</td><td>There is no published file.</td></tr><tr><td>Unpublished</td><td>Successful end state. Firmware file no longer being published.</td></tr></table>
+
+# 3.107. UpdateEnumType
+
+Enumeration
+
+UpdateEnumType is used by: sendLocalList:SendLocalListRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Differential</td><td>Indicates that the current Local Authorization List must be updated with the values in this message.</td></tr><tr><td>Full</td><td>Indicates that the current Local Authorization List must be replaced by the values in this message.</td></tr></table>
+
+# 3.108. Update Firmware Status EnumType
+
+Enumeration
+
+Generic message response status
+
+Update FirmwareStatusEnumType is used by: updateFirmware:UpdateFirmwareResponse
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Accepted</td><td>Accepted this firmware update request. This does not mean the firmware update is successful, the Charging Station will now start the firmware update process.</td></tr><tr><td>Rejected</td><td>Firmware update request rejected.</td></tr><tr><td>AcceptedCanceled</td><td>Accepted this firmware update request, but in doing this has canceled an ongoing firmware update.</td></tr><tr><td>InvalidCertificate</td><td>The certificate is invalid.</td></tr><tr><td>RevokedCertificate</td><td>Failure end state. The Firmware Signing certificate has been revoked.</td></tr></table>
+
+# 3.109. UploadLogStatusEnumType
+
+Enumeration
+
+UploadLogStatusEnumType is used by: logStatusNotification:LogStatusNotificationRequest
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>BadMessage</td><td>A badly formatted packet or other protocol incompatibility was detected.</td></tr><tr><td>Idle</td><td>The Charging Station is not uploading a log file. Idle SHALL only be used when the message was triggered by a TriggerMessageRequest.</td></tr><tr><td>NotSupportedOperation</td><td>The server does not support the operation</td></tr><tr><td>PermissionDenied</td><td>Insufficient permissions to perform the operation.</td></tr><tr><td>Uploaded</td><td>File has been uploaded successfully.</td></tr><tr><td>UploadFailure</td><td>Failed to upload the requested file.</td></tr><tr><td>Uploading</td><td>File is being uploaded.</td></tr><tr><td>AcceptedCanceled</td><td>On-going log upload is canceled and new request to upload log has been accepted.</td></tr></table>
+
+# 3.110. VPNUMType
+
+Enumeration
+
+Enumeration of VPN Types.
+
+VPNEnumType is used by: setNetworkProfile:SetNetworkProfileRequest. VPNType
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>IKEv2</td><td>IKEv2 VPN</td></tr><tr><td>IPSec</td><td>IPSec VPN</td></tr><tr><td>L2TP</td><td>L2TP VPN</td></tr><tr><td>PPTP</td><td>PPTP VPN</td></tr></table>
+
+# Referenced Components and Variables
+
+# Chapter 1. Controller Components
+
+This section gives an overview of the 'Controller' components, which are introduced in OCPP 2.0. A controller component can be recognized by the 'Ctrl' suffix and is responsible for the configuration of a certain functionality. Most of the 'Referenced' components that are described in this document, are 'Controller' components.
+
+The table below contains a summary of all Controller components, for more details, please refer to Part 2 - Appendices.
+
+<table><tr><td>Controller Component</td><td>Description</td></tr><tr><td>AlignedDataCtrlr</td><td>Responsible for configuration relating to the reporting of clock-aligned meter data.</td></tr><tr><td>AuthCacheCtrlr</td><td>Responsible for configuration relating to the use of a local cache for authorization for Charging Station use.</td></tr><tr><td>AuthCtrlr</td><td>Responsible for configuration relating to the use of authorization for Charging Station use.</td></tr><tr><td>CHAdeMOCtrlr</td><td>Responsible for configuration relating to the CHAdeMO controller</td></tr><tr><td>ClockCtrlr</td><td>Provides a means to configure management of time tracking by Charging Station.</td></tr><tr><td>CustomizationCtrlr</td><td>Responsible for configuration relating to custom vendor-specific implementations, like the DataTransfer message and CustomData extensions or CustomTriggers.</td></tr><tr><td>DeviceDataCtrlr</td><td>Responsible for configuration relating to the exchange and storage of Charging Station device model data.</td></tr><tr><td>DisplayMessageCtrlr</td><td>Responsible for configuration relating to the display of messages to Charging Station users.</td></tr><tr><td>ISO15118Ctrlr</td><td>Responsible for configuration relating to the ISO 15118 controller</td></tr><tr><td>LocalAuthListCtrlr</td><td>Responsible for configuration relating to the use of local authorization lists for Charging Station use.</td></tr><tr><td>MonitoringCtrlr</td><td>Responsible for configuration relating to the exchange of monitoring event data.</td></tr><tr><td>OCPPCommCtrlr</td><td>Responsible for configuration relating to information exchange between Charging Station and CSMS.</td></tr><tr><td>ReservationCtrlr</td><td>Responsible for configuration relating to reservations.</td></tr><tr><td>SampledDataCtrlr</td><td>Responsible for configuration relating to the reporting of sampled meter data.</td></tr><tr><td>SecurityCtrlr</td><td>Responsible for configuration relating to security of communications between Charging Station and CSMS.</td></tr><tr><td>SmartChargingCtrlr</td><td>Responsible for configuration relating to Smart Charging.</td></tr><tr><td>TariffCostCtrlr</td><td>Responsible for configuration relating to tariff and cost display.</td></tr><tr><td>TxCtrlr</td><td>Responsible for configuration relating to transaction characteristics and behaviour.</td></tr><tr><td>V2XChargingCtrlr (2.1)</td><td>Responsible for configuration relating to V2X charging/discharging. This component exists on the EVSE tier hierarchy.</td></tr><tr><td>DCDERCtrlr (2.1)</td><td>Responsible for configuration relating to DER capabilities of the DC inverter of the EVSE in the Charging Station. The component is located at the EVSE level, since it represents the DER capabilities, also referred to as nameplate information, of the EVSE.</td></tr><tr><td>ACDERCtrlr (2.1)</td><td>Responsible for configuration relating to DER capabilities that the EVSE of the Charging Station can emulate by using ISO 15118-20 ChargeLoop messages to control the inverter in the EV. The component is located at the EVSE level, since it represents the DER capabilities of the EVSE.</td></tr><tr><td>BatterySwapCtrlr (2.1)</td><td>Responsible for configuration relating to Battery swapping.</td></tr><tr><td>WebPaymentsCtrlr (2.1)</td><td>Responsible for configuration of a dynamic QR code for ad hoc payments.</td></tr></table>
+
+Every Controller component has an 'Enabled' variable. This variable can be used to enable/disable a certain functionality. Any data in the charging station is not part of the controller component, so when disabling a functionality, any relating data stored in the Charging Station will not be changed or removed.
+
+For example: if ReservationCtrl is disabled when there is an active reservation, the EVSE will become available, but the reservation
+
+entries will still be there – they are just not used. If afterwards ReservationCtrlr is enabled again, the reservation entries will become active again as long as they have not expired and no transaction is in progress. If a transaction has started in the mean time, that transaction remains active. The reservation is then considered expired.
+
+# Chapter 2. Referenced Components and Variables
+
+Below follows a list of all Component Variable combinations with a role standardized in this specification.
+
+These Configuration Variables replace the Configuration Keys from OCPP 1.x
+
+The list is split by functionality; General, Security, Authorization, Local Authorization List Management, Authorization Cache, Transaction, Metering, Reservation, Smart Charging, Tariff & Cost, Diagnostics, Display Message, Battery Swapping, Charging Infrastructure, ISO 15118, Bidirectional Charging related, and some additional components / variables that received a dedicated section; ConnectedEV, FrequencySimulator, DataCollector, Device Model hierarchy variables, DCDERCtrlr, ACDERCtrlr.
+
+A required Configuration Variable mentioned under a particular function block only has to be supported by the Charging Station if it supports that functional block.
+
+Please see chapter 4 in "Part 1 - Architecture & Topology" about the addressing of Components and Variables in the Device Model.
+
+# General requirements
+
+Requirements for all the Configuration Variables in this document:
+
+- All variables that are writable SHALL have the VariableAttribute field: persistence = true, and SHALL thus be stored in a persistent way.
+- Any fields not defined SHALL be left empty.
+- Any field marked with a \* (Asterisk) can be of any possible value.
+- When the AttributeType is NOT given, the CSMS and Charging Station SHALL assume the AttributeType to be Actual.
+
+# Shortcut notation for variables
+
+A Configuration Variable is a device model variable. Such a variable is identified by:
+
+1. its variable name, and optional variable instance
+2. the component it is a part of, and optional component instance
+3. the EVSE and optional connector to which component belongs.
+
+Configuration Variables can be referenced by their simplified name, which is the section header in this chapter in which the variable is described, or by their full definition which is described in the following shortcut notation:
+
+- componentName[instance].variableName[instance]
+
+As an example, the Configuration Variable TariffAvailable, which is the "Tariff" instance of the variable "Available" as part of component "TariffCostCtrlr", can also be referred to as:
+
+TariffCostCtrlr.Available[Tariff].
+
+The EVSE and Connector are not part of the shortcut notation. If a Configuration Variable has a value that is specific for an EVSE or Connector, then this explicitly mentioned in the text.
+
+# 2.1. General
+
+NOTE WebSocket-related variables are described in "OCPP-2.1 Part 4 JSON over WebSockets".
+
+# 2.1.1.ActiveNetworkProfile
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ActiveNetworkProfile</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">This variable indicates the NetworkConnectionProfile configuration slot the Charging Station currently uses for its connection with the CSMS.</td></tr></table>
+
+# 2.1.2. AllowNewSessionsPendingFirmwareUpdate
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ChargingStation</td></tr><tr><td rowspan="3">Variable</td><td>名字</td><td colspan="2">AllowNewSessionsPendingFirmwareUpdate</td></tr><tr><td>variables</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variables</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Indicates whether new sessions can be started on EVSEs, while Charging Station is waiting for all EVSEs to become Available in order to start a pending firmware update.
+When a firmware update is waiting to be installed and this variable exists and has the value true, then, the Charging Station will not set free EVSEs to Unavailable, pending the update. This means that it may take longer until there is a point in time when all EVSEs of the Charging Station are free and it can perform the firmware update.</td></tr></table>
+
+# 2.1.3. DefaultMessageTimeout
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">MessageTimeout</td></tr><tr><td>variableInstance</td><td colspan="2">Default</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">The purpose of the message timeout is to be able to consider a request message as not sent and continue with other tasks when the message did not arrive due to communication errors or software failure. The message timeout setting in a Charging Station can be configured in the messageTimeout field in the NetworkConnectionProfile.</td></tr></table>
+
+# 2.1.4. FileTransferProtocols
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">FileTransferProtocols</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>FTP, FTPS, HTTP, HTTPS, SFTP</td></tr><tr><td>Description</td><td colspan="3">List of supported file transfer protocols.</td></tr></table>
+
+# 2.1.5. HeartbeatInterval
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">HeartbeatInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>minLimit</td><td>1</td></tr><tr><td>Description</td><td colspan="3">Interval of inactivity (no OCPP exchanges) with CSMS after which the Charging Station should send HeartbeatRequest.</td></tr></table>
+
+# 2.1.6. NetworkConfigurationPriority
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">NetworkConfigurationPriority</td></tr><tr><td rowspan="2">variableAttributes</td><td>attributeType</td><td>Actual</td></tr><tr><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>SequenceList</td></tr><tr><td>valuesList</td><td>List of possible values</td></tr><tr><td>Description</td><td colspan="3">A comma separated ordered list of the priority of the possible Network Connection Profiles. The list of possible available profile slots for the network configuration profiles SHALL be reported, via the valuesList characteristic of this Variable.</td></tr></table>
+
+# 2.1.7. NetworkProfileConnectionAttempts
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">NetworkProfileConnectionAttempts</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Specifies the number of connection attempts the Charging Station executes before switching to a different profile.</td></tr></table>
+
+# 2.1.8. NetworkConfiguration
+
+New in OCPP 2.1
+
+# NOTE
+
+For improved readability the variables below are listed in a concise format.
+
+The component NetworkConfiguration is located at the top tier, i.e. not assigned to a specific EVSE.
+
+For the variables in NetworkConfiguration that are identical to parameters of SetNetworkProfileRequest, the same types and limits are used.
+
+If Charging Station only supports setting the network configuration via the SetNetworkProfileRequest, then all variables are reported as ReadOnly.
+
+<table><tr><td>Req'd</td><td>Component</td><td>Instance</td><td>Variable</td><td>Comments</td></tr><tr><td>yes</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>OcppCsmsUrl</td><td>URL of the CSMS (without the Charging Station Identity)</td></tr><tr><td>yes</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>OcppInterface</td><td>OptionList of values of OcppInterfaceEnumType.</td></tr><tr><td>yes</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>OcppTransport</td><td>OptionList of values of OCPPTransportEnumType. Is always "JSON".</td></tr><tr><td>yes</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>OcppVersion</td><td>OptionList of values of OcppVersionEnumType. This field is ignored, but only present here because it is in SetNetworkProfileRequest.</td></tr><tr><td>yes</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>MessageTimeout</td><td>Duration in seconds before a message send by the Charging Station via this network connection times out.</td></tr><tr><td colspan="5"></td></tr><tr><td>yes</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>SecurityProfile</td><td>Security profile level</td></tr><tr><td>yes / no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>Identity</td><td>Required if SecurityCtrl/Identity is ReadWrite</td></tr><tr><td>yes</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>BasicAuthPassword</td><td>Writing to this variable only sets the password for the "instance" configurationSlot</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>CsmsRootCertificate HashAlgorithm</td><td>References a specific CSMS Root Certificate which has to be contained in the chain. Same variable as CertificateHashDataType hashAlgorithm.</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>CsmsRootCertificate IssuerKeyHash</td><td>References a specific CSMS Root Certificate which has to be contained in the chain. Same variable as CertificateHashDataType issuerKeyHash.</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>CsmsRootCertificate IssuerNameHash</td><td>References a specific CSMS Root Certificate which has to be contained in the chain. Same variable as CertificateHashDataType issuerNameHas h.</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>CsmsRootCertificate SerialNumber</td><td>References a specific CSMS Root Certificate which has to be contained in the chain. Same variable as CertificateHashDataType serialNumber.</td></tr><tr><td colspan="5"></td></tr><tr><td>yes</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>VpnEnabled</td><td>True: VPN is configured. False: VPN is not configured. If variable is ReadOnly and set to False: VPN is not supported. When False the values of variables "Vpn*" have no meaning.</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>VpnType</td><td>Value from VPENumType</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>VpnServer</td><td>VPN server address</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>VpnUser</td><td>VPN user name</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>VpnGroup</td><td>VPN group name</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>VpnPassword</td><td>VPN password</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>VpnKey</td><td>VPN shared secret</td></tr><tr><td colspan="5"></td></tr><tr><td>yes</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>ApnEnabled</td><td>True: APN is configured. False: APN is not configured. If variable is ReadOnly and set to False: APN is not supported. When False the values of variables "Apn", SimPin, PreferredNetwork and UseOnlyPreferredNetwork have no meaning.</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>Apn</td><td>Access Point Name as URL</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>ApnUserName</td><td>APN user name</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>ApnPassword</td><td>APN password</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>SimPin</td><td>SIM card PIN code</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>PreferredNetwork</td><td>Preferred network as concatenation of MCC and MNC</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>UseOnlyPreferredNetwork</td><td>When true use only the preferred network</td></tr><tr><td>no</td><td>NetworkConfiguration</td><td>[configurationSlot]</td><td>ApnAuthentication</td><td>Value from APNAuthenticationEnumType</td></tr></table>
+
+Note: The variables CsmsRootCertificateXXX are printed on two lines for readability, but are a single word: e.g. CsmsRootCertificateHashAlgorithm.
+
+2.1.9.OfflineThreshold
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">OfflineThreshold</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When the offline period of a Charging Station exceeds the OfflineThreshold it is recommended to send a StatusNotificationRequest for all its Connectors when the Charging Station is back online.</td></tr></table>
+
+2.1.10. QueueAllMessages
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>ijklname</td><td colspan="2">QueueAllMessages</td></tr><tr><td>ijklattributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>ijklharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When this variable is set to true, the Charging Station will queue all message until they are delivered to the CSMS. When set to false the Charging Station will only queue Transaction related messages as required in: E04.FR.01. and other requirementsWhen this variable is the to true, and the Charging Station is running low on memory, the Charging Station SHALL drop TransactionEvent messages last, and when dropping measurements/meter data, the Charging Station SHALL drop intermediate values first (1st value, 3th value, 5th etc), not start dropping values from the beginning or end of the measurements/meter data.Default = false</td></tr></table>
+
+2.1.11.MessageAttemptsTransactionEvent
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>OCPPCommCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">MessageAttempts</td></tr><tr><td>variableInstance</td><td colspan="2">TransactionEvent</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">How often the Charging Station should try to submit a TransactionRequest message when the CSMS fails to process it.</td></tr></table>
+
+# 2.1.12. MessageAttemptIntervalTransactionEvent
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="6">Variable</td><td>variableName</td><td colspan="2">MessageAttemptInterval</td></tr><tr><td>variableInstance</td><td colspan="2">TransactionEvent</td></tr><tr><td rowspan="2">variableAttributes</td><td>attributeT ype</td><td>Actual</td></tr><tr><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">How long the Charging Station should wait before resubmitting a TransactionRequest message that the CSMS failed to process.</td></tr></table>
+
+# 2.1.13.UnlockOnEVSideDisconnect
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">UnlockOnEVSideDisconnect</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite/ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When set to true, the Charging Station SHALL unlock the cable on the Charging Station side when the cable is unplugged at the EV. For an EVSE with only fixed cables, the mutability SHALL be ReadOnly and the actual value SHALL be false. For a charging station with fixed cables and sockets, the variable is only applicable to the sockets.</td></tr></table>
+
+# 2.1.14. WebSocketPingInterval
+
+This configuration variable is described in "OCPP-2.1 Part 4 JSON over WebSockets".
+
+# 2.1.15. ResetRetries
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ResetRetries</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr></table>
+
+<table><tr><td>Description</td><td>Number of times to retry a reset of the Charging Station when a reset was unsuccessful.</td></tr></table>
+
+# 2.1.16.MessageFieldLength
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">FieldLength</td></tr><tr><td>variableInstancee</td><td colspan="2"><message>.<field></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">This variable is used to report the length of <field> in <message> when it is larger than the length that is defined in the standard OCPP message schema.</td></tr></table>
+
+# 2.1.17. ItemsPerMessageGetReport
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ItemsPerMessage</td></tr><tr><td>variableInstancee</td><td colspan="2">GetReport</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of ComponentVariable entries that can be sent in one GetReportRequest or GetMonitoringReportRequest message.</td></tr></table>
+
+# 2.1.18. ItemsPerMessageGetVariables
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ItemsPerMessage</td></tr><tr><td>variableInstancee</td><td colspan="2">GetVariables</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of GetVariableData objects in GetVariablesRequest.</td></tr></table>
+
+# 2.1.19. BytesPerMessageGetReport
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>DeviceDataCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BytesPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">GetReport</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Message Size (in bytes) - puts constraint on GetReportRequest or GetMonitoringReportRequest message size.</td></tr></table>
+
+# 2.1.20. BytesPerMessageGetVariables
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BytesPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">GetVariables</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Message Size (in bytes) - puts constraint on GetVariablesRequest message size.</td></tr></table>
+
+# 2.1.21. ConfigurationValueSize
+
+Updated in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ConfigurationValueSize</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>2500</td></tr><tr><td>Description</td><td colspan="3">This Configuration Variable can be used to limit the following fields: SetVariableData(attributeValue and VariableCharacteristics.valuesList. The max size of these values will always remain equal.</td></tr></table>
+
+# 2.1.22. ReportingValueSize
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ReportingValueSize</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>2500</td></tr><tr><td>Description</td><td colspan="3">This Configuration Variable can be used to limit the following fields:GetVariableResult.value, VariableAttribute.value and EventData的实际Value. The max size of these values will always remain equal.</td></tr></table>
+
+# 2.1.23. ItemsPerMessageSetVariables
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ItemsPerMessage</td></tr><tr><td>variableInstancee</td><td colspan="2">SetVariables</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of SetVariableData objects in SetVariablesRequest.</td></tr></table>
+
+# 2.1.24. BytesPerMessageSetVariables
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DeviceDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BytesPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">SetVariables</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Message Size (in bytes) - puts constraint on SetVariablesRequest message size.</td></tr></table>
+
+# 2.1.25. DateTime
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">DateTime</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>DateTime</td></tr><tr><td>Description</td><td colspan="3">Contains the current date and time.</td></tr></table>
+
+# 2.1.26. NtpSource
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">NtpSource</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>valuesList</td><td>DHCP, manual</td></tr><tr><td>Description</td><td colspan="3">When an NTP client is implemented, this variable can be used to configure the client: Use the NTP server provided via DHCP, or use the manually configured NTP server.</td></tr></table>
+
+# 2.1.27. NtpServerUri
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">NtpServerUri</td></tr><tr><td>variableInstance</td><td colspan="2">Single digit, multiple servers allowed, primary NtpServer has instance '1', the secondary has instance '2'. etc</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td rowspan="2">Description</td><td colspan="3">When an NTP client is implemented, this variable can be used to configure the client: This contains the address of the NTP server.</td></tr><tr><td colspan="3">Multiple NTP servers can be configured. These can be back-up NTP servers. If the NTP client supports it, it can also connect to multiple NTP servers simultaneous to get a more reliable time source.</td></tr></table>
+
+# 2.1.28.TimeOffset
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">TimeOffset</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td rowspan="3">Description</td><td colspan="3">Configured current local time offset in the format: "+01:00", "-02:00" etc.</td></tr><tr><td colspan="3">When a TimeOffset is used, it is advised not to implement: TimeZone. If a Charging Station has implemented both TimeOffset and TimeZone it is RECOMMENDED to not use both at the same time.</td></tr><tr><td colspan="3">The time offset is for display purposes to show local time and is also used for charging profiles that have useLocalTime = true.</td></tr></table>
+
+# 2.1.29. NextTimeOffsetTransitionDateTime
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">NextTimeOffsetTransitionDateTime</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>DateTime</td></tr><tr><td>Description</td><td colspan="3">Date time of the next time offset transition. On this date time, the clock displayed to the EV driver will be given the new offset as configured via TimeOffsetNextTransition.
+This can be used to manually configure the next start or end of a daylight saving time period.</td></tr></table>
+
+# 2.1.30.TimeOffsetNextTransition
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TimeOffset</td></tr><tr><td>variableInstance</td><td colspan="2">NextTransition</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">Next local time offset in the format: "+01:00", "-02:00" etc.
+New offset that will be set on the next time offset transition as configured via
+'NextTimeOffsetTransitionDateTime'.
+This can be used to manually configure the offset for the start or end of the daylight saving time period.</td></tr></table>
+
+# 2.1.31.TimeSource
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TimeSource</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>SequenceList</td></tr><tr><td>valuesList</td><td>List of all implemented time sources. Possible values: Heartbeat, NTP, GPS, RealTimeClock, MobileNetwork, RadioTimeTransmitter</td></tr><tr><td>Description</td><td colspan="3">Via this variable, the Charging Station provides the CSMS with the option to configure a clock source, if more than 1 are implemented.
+By providing a list of possible sources, the CSO can configure fallback sources.
+Example:
+"NTP,Heartbeat" means, use NTP, but when none of the NTP servers responses, use time synchronization via Heartbeat.
+NOTE: RadioTimeTransmitter: At various locations around the globe, low-frequency radio transmitters provide accurate local time information e.g. DCF77 in Germany, MSF in the United Kingdom, JJY in Japan etc. Such a radio time clock can be used as a time source for a Charging Station. The Charging Station shall convert the broadcasted time to UTC. For this TimeZone, TimeOffset, 'NextTimeOffsetTransitionDateTime' and 'TimeOffsetNextTransition' can be used.</td></tr></table>
+
+# 2.1.32.TimeZone
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">TimeZone</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr></table>
+
+<table><tr><td>Description</td><td>Configured current local time zone in the format: "Europe/Oslo", "Asia/Singapore" etc.</td></tr><tr><td></td><td>When a time zone is used, it is advised not to implement: TimeOffset. If a Charging Station has implemented both TimeOffset and TimeZone it is RECOMMENDED to not use both at the same time.</td></tr><tr><td></td><td>The time zone is for display purposes to show local time and is also used for charging profiles that have useLocalTime = true.</td></tr></table>
+
+# 2.1.33. TimeAdjustmentReportingThreshold
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ClockCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TimeAdjustmentReportingThreshold</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When the clock time is adjusted forwards or backwards for more then TimeAdjustmentReportingThreshold number of seconds, a SecurityEventNotification( "SettingSystemTime" ) is sent by the charging station. A reasonable value is 20 seconds.</td></tr></table>
+
+# 2.1.34.CustomImplementationEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">CustomizationCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">CustomImplementationEnabled</td></tr><tr><td>variableInstancee</td><td colspan="2"><VendorId></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">This standard configuration variable is used to enable/disable custom implementations that the Charging Station supports.It is recommended to first check if the custom behavior can be implemented using device model components/variables before resorting to DataTransfer message(s) and/or CustomData fields.</td></tr></table>
+
+# 2.1.35.CustomTriggers
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">CustomizationCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>(variableName</td><td colspan="2">CustomTriggers</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr></table>
+
+<table><tr><td>Description</td><td>This variable defines the names of custom triggers that Charging Station supports in a customTrigger field of TriggerMessageRequest. The names are as comma-separated list in the Actual value of CustomTriggers.</td></tr></table>
+
+# 2.1.36. ExternalConfigChangeDate
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ExternalConfigChangeDate</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>DateTime</td></tr><tr><td>Description</td><td colspan="3">Date/time when the configuration was changed externally, i.e. outside of CSMS, for example by a local service action. This can be monitored by CSMS to decide whether to issue a new GetBaseReportRequest to get the updated configuration.</td></tr></table>
+
+# 2.2. Security related
+
+# 2.2.1.BasicAuthPassword
+
+Updated in OCPP 2.1
+
+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.
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BasicAuthPassword</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>WriteOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>At least 40, at most 64.</td></tr><tr><td>Description</td><td colspan="3">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 a maximum as defined by the maxLimit of BasicAuthPassword, which must be at least 40 characters and at most 64. 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.(2.1) This variable has remained for backwards compatibility. As of OCPP 2.1 the variable BasicAuthPassword of component NetworkConfiguration must be used. If SecurityCtrlr.BasicAuthPassword is set directly, Charging Station SHALL also set the variable of the same name in all NetworkConfiguration component instances to the same value (if valid), including component instances which are contained in the currently configured NetworkConfigurationPriority.</td></tr></table>
+
+# 2.2.2. Identity
+
+Updated in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Identity</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly orReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>48 (Charging Station Identity)</td></tr><tr><td>Description</td><td colspan="3">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[ISO15118-2].(2.1) This variable has remained for backwards compatibility. As of OCPP 2.1 the variable Identity of component NetworkConfiguration must be used. IfSecurityCtrlr.Identity is set directly, Charging Station SHALL also set the variable of the same name in all NetworkConfiguration component instances to the same value (if valid), including component instances which are contained in the currently configured NetworkConfigurationPriority.</td></tr></table>
+
+# 2.2.3. OrganizationName
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrl</td></tr><tr><td rowspan="3">Variable</td><td>ijklname</td><td colspan="2">OrganizationName</td></tr><tr><td>ijklattributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>ijklcharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">This configuration variable is used to set the organization name of the CSO or an organization trusted by the CSO. It is used to set the O (organizationName) RDN in the subject field of the client certificate. See also A00.FR.509.</td></tr></table>
+
+# 2.2.4. CertificateEntries
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">CertificateEntries</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>Maximum number of Certificates installed at any time.</td></tr><tr><td>Description</td><td colspan="3">Amount of Certificates currently installed on the Charging Station.</td></tr></table>
+
+# 2.2.5. SecurityProfile
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>SecurityCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SecurityProfile</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">This configuration variable is used to report the security profile used by the Charging Station.</td></tr></table>
+
+# 2.2.6. Additional Root Certificate Check
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">AdditionalRootCertificateCheck</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When installing a new CSMS Root certificate, the new certificate SHALL replace the old one AND the new CSMS Root Certificate MUST be signed by the old CSMS Root Certificate it is replacing. This configuration variable is required unless only "security profile 1 - Unsecured Transport with Basic Authentication" is implemented. Please note that security profile 1 SHOULD only be used in trusted networks.
+Note: When using this additional security mechanism please be aware that the Charging Station needs to perform a full certificate chain verification when the new CSMS Root certificate is being installed. However, once the old CSMS Root certificate is set as the fallback certificate, the Charging Station needs to perform a partial certificate chain verification when verifying the server certificate during the TLS handshake. Otherwise the verification will fail once the old CSMS Root ( fallback) certificate is either expired or removed.
+Note 2: The statement that the variable is required, means that the configuration variable must be present, but does NOT indicate that the feature must be implemented. This is an optional feature. By setting the value to false, the Charging Station indicates that it does not support this feature, whereas true means that it does support the feature.</td></tr></table>
+
+# 2.2.7.MaxCertificateChainSize
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">MaxCertificateChainSize</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>10000</td></tr><tr><td>Description</td><td colspan="3">This configuration variable can be used to limit the size of the 'certificateChain' field from the CertificateSignedRequest PDU. This value SHOULD NOT be set too small. The smaller this value, the less security architectures the Charging Station will support. It is RECOMMENDED to set at least a size of 5600. This will allow the Charging Station to support most security architectures.</td></tr></table>
+
+# 2.2.8. CertSigningWaitMinimum
+
+<table><tr><td>Required</td><td>no</td></tr></table>
+
+<table><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">CertSigningWaitMinimum</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">This configuration variable defines how long the Charging Station has to wait before generating another CSR, in the case the CSMS accepts the SignCertificateRequest, but never returns the signed certificate back. This value will be doubled after every attempt. The amount of attempts is configured at CertSigningRepeatTimes If the certificate signing process is slow, this setting allows the CSMS to tell the Charging Station to allow more time.</td></tr></table>
+
+# 2.2.9. CertSigningRepeatTimes
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">CertSigningRepeatTimes</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">This variable can be used to configure the amount of times the Charging Station SHALL double the previous back-off time, starting with the number of seconds configured at CertSigningWaitMinimum, every time the back-off time expires without having received the CertificateSignedRequest containing the from the CSR generated signed certificate. When the maximum number of increments is reached, the Charging Station SHALL stop resending the SignCertificateRequest, until it is requested by the CSMS using a TriggerMessageRequest.</td></tr></table>
+
+# 2.2.10. AllowSecurityProfileDowngrade
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SecurityCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>ijklname</td><td colspan="2">AllowSecurityProfileDowngrade</td></tr><tr><td>ijklattributes</td><td>mutability</td><td>ReadWrite/ReadOnly</td></tr><tr><td>ijklcharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td rowspan="2">Description</td><td colspan="3">If this variable is implemented and set to true, then the Charging Station allows downgrading the security profile from 3 to 2.</td></tr><tr><td colspan="3">For security reasons it is not allowed to revert from profile 2 or profile 3 to security profile 1 using OCPP.</td></tr></table>
+
+# 2.3. Authorization related
+
+# 2.3.1. Enabled
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>AuthCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If set to false, then no authorization is done before starting a transaction or when reading an idToken. If an idToken was provided, then it will be put in the idToken field of the TransactionRequest. If no idToken was provided, then idToken in TransactionRequest will be left empty and type is set to NoAuthorization.</td></tr></table>
+
+# 2.3.2. AdditionalInfoItemsPerMessage
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">AdditionallyInfolItemsPerMessage</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of additionInfo items that can be sent in one message. This configuration variable only has to be implemented when Charging Station is able to receive additionalInfo fields from CSMS. It is not required when only the Charging Station can send additionInfo fields, because CSMS is expected to be able to handle an arbitrary amount of additionInfo fields from Charging Station.</td></tr></table>
+
+# 2.3.3. OfflineTxForUnknownIdEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">OfflineTxForUnknownIdEnabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this key exists, the Charging Station supports Unknown Offline Authorization. If this key reports a value of true, Unknown Offline Authorization is enabled.</td></tr></table>
+
+# 2.3.4.authorizeRemoteStart
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">AuthorizeRemoteStart</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly orReadWrite. Choice is up to Charging Station implementation.</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether a remote request to start a transaction in the form ofRequestStartTransactionRequest message should be authorized beforehand like a local action to start a transaction.</td></tr></table>
+
+# 2.3.5. LocalauthorizeOffline
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">LocalauthorizeOffline</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether the Charging Station, when Offline, will start a transaction for locally-authorized identifiers.</td></tr></table>
+
+# 2.3.6. LocalPreauthorize
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">LocalPreauthorize</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether the Charging Station, when online, will start a transaction for locally-authorized identifiers without waiting for or requesting an AuthorizationResponse from the CSMS.</td></tr></table>
+
+# 2.3.7. MasterPassgroupId
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">MasterPassGroupId</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>36 (The maximum string length of MasterPassGroupId)</td></tr><tr><td>Description</td><td colspan="3">IdTokens that have this id as groupId belong to the Master Pass Group. Meaning they can stop any ongoing transaction, but cannot start transactions. This can, for example, be used by law enforcement personal to stop any ongoing transaction when an EV has to be towed away.</td></tr></table>
+
+# 2.3.8. DisableRemoteAuthorization
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">DisableRemoteAuthorization</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr></table>
+
+<table><tr><td>Description</td><td>When set to true this instructs the Charging Station to not issue any AuthorizationRequests, but only use Authorization Cache and Local Authorization List to determine validity of idTokens.
+Note: The difference between AuthCtrl.DisableRemoteAuthorization and AuthCacheCtrl.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 AuthCtrl.DisableRemoteAuthorization disables all authorization with CSMS.</td></tr></table>
+
+# 2.3.9. SupportedIdTokentypes
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportedIdTokenTypes</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>List of IdTokenEnumstringType in Appendix.</td></tr><tr><td>Description</td><td colspan="3">The subset of the list of supported IdTokenTypes as defined in Appendix 7. "Standardized values for enumerations as string: IdTokenEnumstringType", that is supported by the Charging Station.</td></tr></table>
+
+# 2.4. Adhoc payment related
+
+New in OCPP 2.1
+
+# 2.4.1. PaymentCtrl
+
+Below is an overview of variables for component PaymentCtrl. See use case C18 - Authorization using locally connected payment terminal.
+
+<table><tr><td>Variable</td><td>Type</td><td>M/O</td><td>R/W</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>M</td><td>RW</td><td>Payment terminal support is enabled.</td></tr><tr><td>Problem</td><td>boolean</td><td>M</td><td>RO</td><td>There's a problem with the payment terminal.</td></tr><tr><td colspan="5">Authorization and settlement</td></tr><tr><td>AuthorizationDirectPayment</td><td>boolean</td><td>M</td><td>RW</td><td>If true, an AuthorizationRequest must be sent to CSMS to approve the direct payment.</td></tr><tr><td>AuthorizationAmount</td><td>decimal</td><td>M</td><td>RW</td><td>Amount used for the pre-authorization.</td></tr><tr><td>IncrementalAuthorizationAmount</td><td>decimal</td><td>O</td><td>RW</td><td>If value is 0, then incremental authorization is not allowed. Variable will be absent if Charging Station or payment terminal do not support incremental authorization.</td></tr><tr><td>IncrementalAuthorizationThreshold</td><td>decimal</td><td>O</td><td>RW</td><td>If costs exceed current authorization amount minus IncrementalAuthorizationThreshold then the authorization needs to be increased. When this variable is absent this threshold is defined by the implementation.</td></tr><tr><td>PaymentDetails</td><td>MemberList</td><td>M</td><td>RW</td><td>The valuesList of PaymentDetails contains the information that the payment terminal is able to provide. The Actual value of PaymentDetails determines which of these details shall be provided in the idToken.additionInfo field.valuesList: "PspRef", "SessionRef", "MerchantRef", "PaymentBrand", "ReadingMethod", "PaymentRecognition", "CardBin", "CardLast4Digits", "CardExpiryDate", "HashedCardNr", "WalletUserID".See also chapter Standardized additionInfo types in Appendix.</td></tr><tr><td>SettlementByCSMS</td><td>boolean</td><td>M</td><td>RW</td><td>When true, CSMS will take care of settlement.</td></tr><tr><td colspan="5">Receipts</td></tr><tr><td>ReceiptServerUrl</td><td>string</td><td>M</td><td>RW</td><td>URL to the receipt server, where an EV driver can find the receipt afterwards.</td></tr><tr><td>ReceiptByCSMS</td><td>boolean</td><td>M</td><td>RW</td><td>When true, CSMS will provide a URL to receipt, else it is provided by payment terminal.</td></tr><tr><td>Merchant[Id]</td><td>string</td><td>M</td><td>RW</td><td>Merchant ID to be added to a PSP/locally generated receipt.</td></tr><tr><td>Merchant[TaxId]</td><td>string</td><td>M</td><td>RW</td><td>Tax ID of the merchant to be added to a PSP/locally generated receipt.</td></tr><tr><td>Merchant[Name]</td><td>string</td><td>M</td><td>RW</td><td>Name of the merchant to be added to a PSP/locally generated receipt.</td></tr><tr><td>Merchant[Address]</td><td>string</td><td>M</td><td>RW</td><td>Address of the merchant to be added to a PSP/locally generated receipt.</td></tr><tr><td>Merchant[City]</td><td>string</td><td>M</td><td>RW</td><td>City of the merchant to be added to a PSP/locally generated receipt.</td></tr><tr><td colspan="5">Terminal data</td></tr><tr><td>TerminalID</td><td>string</td><td>M</td><td>RO</td><td>Terminal ID of the payment terminal.</td></tr><tr><td>PaymentServiceProvider</td><td>string</td><td>M</td><td>RO</td><td>The payment service provider that the terminal is using. Typically read-only.</td></tr><tr><td>VendorName</td><td>string</td><td>M</td><td>RO</td><td>Manufacturer of the payment terminal.</td></tr><tr><td>Model</td><td>string</td><td>M</td><td>RO</td><td>Model of the payment terminal.</td></tr><tr><td>SerialNumber</td><td>string</td><td>M</td><td>RO</td><td>Payment terminal serial number.</td></tr><tr><td>FirmwareVersion</td><td>string</td><td>M</td><td>RO</td><td>Payment terminal firmware version.</td></tr><tr><td>IMSI</td><td>string</td><td>M</td><td>RO</td><td>IMSI of the payment terminals SIM card.</td></tr><tr><td>ICCID</td><td>string</td><td>M</td><td>RO</td><td>ICCID of the payment terminals SIM card.</td></tr><tr><td>Connected</td><td>boolean</td><td>M</td><td>RO</td><td>Boolean to indicate whether the payment terminal is connected to its payment service provider.</td></tr></table>
+
+$M =$ mandatory, $O =$ optional
+$RO =$ read-only, $RW =$ read-write
+Note: notation "Merchant[xxx]" refers to instance "xxx" of variable "Merchant"
+
+# 2.4.2. WebPaymentsCtrl
+
+This logical component is used to configure the creation of dynamic QR codes for payment. See use case C25 - Ad hoc payment via static or dynamic QR code
+
+<table><tr><td>Variable</td><td>Type</td><td>RW</td><td>M/O</td><td>Description</td></tr><tr><td>URLTemplate</td><td>string</td><td>RW</td><td>M</td><td>URL template</td></tr><tr><td>URLParameters</td><td>MemberList</td><td>RO</td><td>O</td><td>List of supported URL query parameters "maxtime", "maxenergy" and "maxcost". valuesList: "maxtime", "maxenergy", "maxcost". When absent, none of these are supported.</td></tr><tr><td>TOTPVersion</td><td>OptionList</td><td>RW</td><td>M</td><td>Version of the TOTP algorithm to use.valuesList: "v1"The "TOTP algorithm, version 1" from C25 - Ad hoc payment via a QR code is referenced as "v1".When a Charging Station supports multiple versions, they are listed in valuesList.</td></tr><tr><td>RoamingEvseld</td><td>string</td><td>RW</td><td>O</td><td>Roaming EVSE Id to be used when URL is pointing to an external party.</td></tr><tr><td>ValidityTime</td><td>integer</td><td>RW</td><td>M</td><td>Validity of a one-time password in seconds.Acceptable range between 6 seconds up to 3600 seconds.</td></tr><tr><td>SharedSecret</td><td>string</td><td>WO</td><td>M</td><td></td></tr><tr><td>Length</td><td>integer</td><td>RW</td><td>M</td><td>Length of TOTP, e.g. 8 characters.Must be at least 6 characters.</td></tr><tr><td>QRCodeQuality</td><td>OptionList</td><td>RO/RW</td><td>O</td><td>The error correction level, defined as: Low, Medium, Quartile, High</td></tr></table>
+
+$M =$ mandatory, $O =$ optional
+$RO =$ read-only, $RW =$ read-write, $WO =$ write-only
+
+# 2.5. Authorization Cache related
+
+# 2.5.1. AuthCacheEnabled
+
+NOTE When the value of this variable is changed, the content of the authorization cache should not be altered.
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCacheCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable exists and reports a value of true, Authorization Cache is enabled.</td></tr></table>
+
+# 2.5.2. AuthCacheAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCacheCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable exists and reports a value of true, Authorization Cache is supported, but not necessarily enabled.</td></tr></table>
+
+# 2.5.3. AuthCacheLifeTime
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>AuthCacheCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">LifeTime</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Indicates how long it takes until a token expires in the authorization cache since it is last used.</td></tr></table>
+
+# 2.5.4. AuthCacheStorage
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCacheCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>ijklname</td><td colspan="2">Storage</td></tr><tr><td>ijklattributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">ijklcharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>The maximum number of bytes</td></tr><tr><td>Description</td><td colspan="3">Indicates the number of bytes currently used by the Authorization Cache.
+MaxLimit indicates the maximum number of bytes that can be used by the Authorization Cache.</td></tr></table>
+
+# 2.5.5. AuthCachePolicy
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCacheCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Policy</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>valuesList</td><td>LRU, LFU, FIFO, CUSTOM</td></tr><tr><td>Description</td><td colspan="3">Cache Entry Replacement Policy: least recently used, least frequently used, first in first out, other custom mechanism.</td></tr></table>
+
+# 2.5.6. AuthCacheDisablePostAuthorization
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AuthCacheCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">DisablePostauthorize</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When set to true this variable disables the behavior to request authorization for an idToken that is stored in the cache with a status other than Accepted, as stated in C10.FR.03 and C12.FR.05.</td></tr></table>
+
+# 2.6. Local Authorization List Management related
+
+# 2.6.1. LocalAuthListEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable exists and reports a value of true, Local Authorization List is enabled.</td></tr></table>
+
+# 2.6.2. LocalAuthListEntries
+
+<table><tr><td>Required</td><td colspan="3">when LocalAuthListAvailable is true</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Entries</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>The maximum number of IdTokens that can be stored in the Local Authorization List.</td></tr><tr><td>Description</td><td colspan="3">Amount of IdTokens currently in the Local Authorization List.
+The maxLimit of this variable SHALL be provided to report the maximum number of IdTokens that can be stored in the Local Authorization List.</td></tr></table>
+
+# 2.6.3. LocalAuthListAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable exists and reports a value of true, Local Authorization List is supported.</td></tr></table>
+
+# 2.6.4. ItemsPerMessageSendLocalList
+
+<table><tr><td>Required</td><td colspan="3">when LocalAuthListAvailable is true</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variablerName</td><td colspan="2">ItemsPerMessage</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of identifications that can be sent in a single SendLocalListRequest.</td></tr></table>
+
+# 2.6.5. BytesPerMessageSendLocalList
+
+<table><tr><td>Required</td><td colspan="3">when LocalAuthListAvailable is true</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">BytesPerMessage</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Message Size (in bytes) - puts a constraint on SendLocalListRequest message size.</td></tr></table>
+
+# 2.6.6. LocalAuthListStorage
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrl</td></tr><tr><td rowspan="4">Variable</td><td>ijklname</td><td colspan="2">Storage</td></tr><tr><td>ijklvariables</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">ijklcharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>The maximum number of bytes</td></tr><tr><td>Description</td><td colspan="3">Indicates the number of bytes currently used by the Local Authorization List. MaxLimit indicates the maximum number of bytes that can be used by the Local Authorization List.</td></tr></table>
+
+# 2.6.7. LocalAuthListDisablePostauthorize
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">DisablePostauthorize</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When set to true this variable disables the behavior to request authorization for an idToken that is stored in the local authorization list with a status other than Accepted, as stated in C14.FR.03.</td></tr></table>
+
+# 2.6.8. LocalAuthListSupportsExpiryDateTime
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">LocalAuthListCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SupportsExpiryDateTime</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">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.</td></tr></table>
+
+# 2.7. Transaction related
+
+# 2.7.1. EVConnectionTimeOut
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">EVConnectionTimeOut</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Interval from between "starting" of a transaction until incipient transaction is automatically canceled, due to failure of EV driver to (correctly) insert the charging cable connector(s) into the appropriate socket(s). The Charging Station SHALL go back to the original state, probably: 'Available'. "Starting" might be the swiping of the RFID, pressing a start button, a RequestStartTransactionRequest being received etc.</td></tr></table>
+
+# 2.7.2. StopTxOnEVSideDisconnect
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">StopTxOnEVSideDisconnect</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite or ReadOnly, depending on Charging Station implementation.</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When set to true, the Charging Station SHALL deauthorize the transaction when the cable is unplugged from the EV.</td></tr></table>
+
+# 2.7.3. TxBeforeAcceptedEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">TxBeforeAcceptedEnabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">With this configuration variable the Charging Station can be configured to allow charging before having received a BootNotificationResponse with RegistrationStatus: Accepted. See: Transactions before being accepted by a CSMS.</td></tr></table>
+
+# 2.7.4. TxStartPoint
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>TxCtrl</td></tr></table>
+
+2.7.5. TxStopPoint
+
+<table><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxStartPoint</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly orReadWrite. Choice is up to Charging Station implementation.</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>See TxStartStopPoint values for allowed values. It is not required to implement all possible values.</td></tr><tr><td>Description</td><td colspan="3">Defines when the Charging Station starts a new transaction: first transactioneventRequest: eventType = Started. When any event in the given list occurs, the Charging Station SHALL start a transaction. The Charging Station SHALL only send the Started event once for every transaction. It is advised to put all events that should be part of a transaction in the list, in case the start event never occurs. Because the possible events don't always have to come in the same order it is possible to provide a list of events. Which ever comes first will then cause a transaction to be started. For example: EVConnected, Authorized would mean that a transaction is started when an EV is detected (Cable is connected), or when an EV Driver swipes his RFID card on the CSMS successfully authorizes the ID for charging.</td></tr></table>
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxStopPoint</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly orReadWrite. Choice is up to Charging Station implementation.</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>See TxStartStopPoint values for allowed values. It is not required to implement all possible values.</td></tr><tr><td>Description</td><td colspan="3">Defines when the Charging Station ends a transaction: last transactioneventRequest: eventType = Ended. When any event in the given list is no longer valid, the Charging Station SHALL end the transaction. The Charging Station SHALL only send the Ended event once for every transaction.</td></tr></table>
+
+# 2.7.6. TxStartStopPoint values
+
+# 2.7.6.1. TxStartPoint values
+
+The following table lists the values allowed for the TxStartPoint variable. These values represent logical steps or events that (may) occur during a charging session. When such an event occurs, and it is listed in in the TxStartPoint variable, then this marks the start of a transaction.
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ParkingBayOccupancy</td><td>An object (probably an EV) is detected in the parking/charging bay.</td></tr><tr><td>EVConnected</td><td>Both ends of the Charging Cable have been connected (if this can be detected, else detection of a cable being plugged into the socket), or for wireless charging: initial communication between EVSE and EV is established.</td></tr><tr><td>Authorized</td><td>Driver or EV has been authorized, this can also be some form of anonymous authorization like a start button.</td></tr><tr><td>PowerPathClosed</td><td>All preconditions for charging have been met, power can flow. This event is the logical AND of EVConnected and Authorized and should be used if a transaction is supposed to start when EV is connected and authorized. Despite its name, this event is not related to the state of the power relay.Note: There may be situations where PowerPathClosed does not imply that charging starts at that moment, e.g. because of delayed charging or a battery that is too hot.</td></tr><tr><td>EnergyTransfer</td><td>Energy is being transferred between EV and EVSE.Note: Since energy needs to start flowing first to cause the transaction to be started, there is a small time gap (order of milliseconds) between the start of energy transfer and start of transaction. Depending on the implementation this may potentially skew the value of the energy meter reading associated with start of the transaction. Use PowerPathClosed as TxStartPoint to avoid this situation.</td></tr><tr><td>DataSigned</td><td>The moment when the signed meter value is received from the fiscal meter, that is used in the TransactionRequest with context = Transaction.Begin and triggerReason = SignedDataReceived. This TxStartPoint might be applicable when legislation exists that only allows a billable transaction to start when the first signed meter value has been received.</td></tr></table>
+
+# 2.7.6.2. TxStopPoint values
+
+The following table lists the values allowed for the TxStopPoint variable. These values represent logical steps or events that (may) occur during a charging session. When such an event occurs, and it is listed in in the TxStopPoint variable, then this marks the end of a transaction.
+
+The values are the same as for TxStartPoint, but in this case the meaning is different, since it refers to the ending of the event, rather than the start. For use with TxStopPoint each value should be interpreted as if it had "Not" prefixed to it. See the following table:
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>ParkingBayOccupancy</td><td>An object (probably an EV) is no longer detected in the parking/charging bay.</td></tr><tr><td>EVConnected</td><td>One or both ends of the Charging Cable have been disconnected (if this can be detected, else detection of a cable being unplugged from the socket), or for wireless charging: communication between EVSE and EV is lost.</td></tr><tr><td>Authorized</td><td>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 TransactionRequest with eventType = Ended will be transmitted.</td></tr><tr><td>PowerPathClosed</td><td>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 TransactionRequest 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.</td></tr><tr><td>EnergyTransfer</td><td>Energy is not being transferred between EV and EVSE. This is not recommended to use as a TxStopPoint, because it will stop the transaction as soon as EV or EVSE (temporarily) suspend the charging.</td></tr><tr><td>DataSigned</td><td>This condition has no meaning as a TxStopPoint and should not be used as such.</td></tr></table>
+
+# 2.7.7. MaxEnergyOnInvalidId
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>TxCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">MaxEnergyOnInvalidId</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>Wh</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum amount of energy in Wh delivered when an identifier is deauthorized by the CSMS after start of a transaction.</td></tr></table>
+
+# 2.7.8. StopTxOnInvalidId
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">StopTxOnInvalidId</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether the Charging Station will deauthorize an ongoing transaction when it receives a non-Accepted authorization status in TransactionEventResponse for this transaction.</td></tr></table>
+
+# 2.7.9. TxResumptionTimeout
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">ResumptionTimeout</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite / ReadOnly</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>unit</td><td>s</td></tr><tr><td>minLimit</td><td>0</td></tr><tr><td>Description</td><td colspan="3">This variable defines the maximum number of seconds that a transaction may be interrupted by a power outage and still be resumed afterwards. When absent default to 0.</td></tr></table>
+
+# 2.7.10. TxAllowEnergyTransferResumption
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>ijklname</td><td colspan="2">AllowEnergyTransferResumption</td></tr><tr><td>ijklattributes</td><td>mutability</td><td>ReadWrite / ReadOnly</td></tr><tr><td>ijklcharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">This variable defines whether energy transfer is allowed to be resumed when the transaction is resumed after a reset or power outage. Energy transfer will return to the state it had before the reset or power outage. When absent this variable defaults to false.</td></tr></table>
+
+# 2.8. EnergyTransferResumptionRandomRange
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">EnergyTransferResumptionRandomRange</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When the Charging Station gets shut down unexpectedly, e.g. due to a software fault, watchdog event, maintenance mode activation or power loss and the interruption was not longer than TxResumptionTimeout seconds and TxAllowEnergyTransferResumption = true and before interruption the charging state was Charging and the EV and EVSE are not disconnected, then the Charging Station shall delay resuming energy transfer for a random amount of seconds, with a maximum of the value configured at EnergyTransferResumptionRandomRange.</td></tr></table>
+
+# 2.8.1.TxSupportedLimits
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TxCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportedLimits</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>List of "maxCost, maxEnergy, maxLength, maxSoC"</td></tr><tr><td>Description</td><td colspan="3">This variable defines which transaction limits in TransactionLimitType are supported by the Charging Station. If the list is empty or this variable does not exist, then Charging Station supports no transaction limits.</td></tr></table>
+
+# 2.9. Metering related
+
+# 2.9.1. SampleDataEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable reports a value of true, Sampled Data is enabled.</td></tr></table>
+
+# 2.9.2. SampledDataAvailable
+
+<table><tr><td>Required</td><td>no</td></tr></table>
+
+<table><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable reports a value of true, Sampled Data is supported.</td></tr></table>
+
+# 2.9.3. SampledDataRegisterValuesWithoutPhases
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">RegisterValuesWithoutPhases</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable reports a value of true, then meter values of measurand Energy.Active.Importantly.Register will only report the total energy over all phases without reporting the individual phase values. If this variable is absent or false, then the value for each phase is reported, possibly also with a total value (depending on the meter).</td></tr></table>
+
+# 2.9.4. SampledDataSignReadings
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrl</td></tr><tr><td rowspan="3">Variable</td><td>ijklname</td><td colspan="2">SignReadings</td></tr><tr><td>ijklvariables</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>ijklvariables</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If set to true, the Charging Station SHALL include signed meter values in the TransactionEventRequest(Ended) as defined in SampledDataTxEndesauses. Some Charging Stations might only be able to sign Transaction.Begin and Transaction.End meter values. When a Charging Station does not support signed meter values, it SHALL NOT report this variable.</td></tr></table>
+
+# 2.9.5. SampledDataSignStartedReadings
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SignStartedReadings</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr></table>
+
+2.9.6. SampledDataSignUpdatedReadings
+
+<table><tr><td>Description</td><td>If set to true, the Charging Station SHALL include signed meter values for context = Transaction.Begin in the metervalues field in the TransactionEventRequest(Started or Updated) as defined in SampleledDataTxStartedMeasurands.
+This setting only has an effect if SampleledDataSignReadings is set to true.
+When a Charging Station does not support signing meter values, it SHALL NOT report this variable.</td></tr></table>
+
+2.9.7. SampledDataTxEndedMeasurands
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SignUpdatedReadings</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If set to true, the Charging Station SHALL include signed meter values in the metervalues field in the TransactionEventRequest(Updated) as defined in SampledDataTxUpdatedMeasurands.
+This setting only has an effect if SampledDataSignReadings is set to true.
+When a Charging Station does not support signing meter values, it SHALL NOT report this variable.</td></tr></table>
+
+2.9.8. SampledDataTxEndInterval
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrl</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">TxEndedMeasurands</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>maxLimit</td><td>The maximum length of the CSV formatted string, to be defined by the implementer.</td></tr><tr><td>valuesList</td><td>values from Measurands</td></tr><tr><td>Description</td><td colspan="3">Sampled measurands to be included in the meterValues element of TransactionEventRequest (eventType = Ended), every SampledDataTxEndInterval 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).</td></tr></table>
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>SampleDataCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxEndInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Interval between sampling of metering (or other) data, intended to be transmitted in the TransactionEventRequest (eventType = Ended) message. For transaction data (evseld>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 TxEndInterval = 0 is recommended, since other values may result in a lot of data to be transmitted in the TransactionEventRequest (eventType = Ended) message.</td></tr></table>
+
+# 2.9.9. SampledDataTxStartedMeasurands
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">TxStartedMeasurands</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from Measurands</td></tr><tr><td>maxLimit</td><td>The maximum length of the CSV formatted string, to be defined by the implementer.</td></tr><tr><td>Description</td><td colspan="3">Sampled measurand(s) to be taken at the start of any transaction to be included in the meterValues field of the first TransactionEventRequest message send at the start of a transaction (eventType = Started). 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 SampledDataTxStartedMeasurands.If the Charging Station has a meter, recommended to use as default: "Energy.Active.Importantly Register"</td></tr></table>
+
+# 2.9.10. SampledDataTxUpdatedMeasurands
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrl</td></tr><tr><td rowspan="5">Variable</td><td>ijklname</td><td colspan="2">TxUpdatedMeasurands</td></tr><tr><td>ijklattributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="3">ijklcharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from Measurands</td></tr><tr><td>maxLimit</td><td>The maximum length of the CSV formatted string, to be defined by the implementer.</td></tr><tr><td>Description</td><td>Sampled measurands to be included in the meterValues element of every TransactionEventRequest (eventType = Updated), every SampledDataTxUpdatedInterval seconds from the start 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 SampledDataTxUpdatedMeasurands.
+If the Charging Station has a meter, recommended to use as default: "Energy.Active.ImportantlyRegister"</td></tr></table>
+
+# 2.9.11. SampledDataTxUpdatedInterval
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>component Name</td><td colspan="2">SampledDataCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxUpdatedInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Interval between sampling of metering (or other) data, intended to be transmitted via TransactionEventRequest (eventType = Updated) messages. For transaction data (evseld>0), samples are acquired and transmitted periodically at this interval from the start of the charging transaction.A value of "0" (numeric zero), by convention, is to be interpreted to mean that no sampled data should be transmitted during the transaction.</td></tr></table>
+
+# 2.9.12. SampledDataUpstreamMeasurands
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SampledDataCtrl</td></tr><tr><td rowspan="6">Variable</td><td>variableName</td><td colspan="2">UpstreamMeasurands</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="4">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from Measurands</td></tr><tr><td>maxLimit</td><td>The maximum length of the CSV formatted string, to be defined by the implementer.</td></tr><tr><td>maxElem ents</td><td>Maximum number of values supported in variable.</td></tr><tr><td>Description</td><td colspan="3">Sampled measurands to be included in the meterValues element of every TransactionRequest (eventType = Updated), every SampledDataUpstreamInterval seconds from the start of the transaction for location = Upstream only. 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 SampledDataTxUpdatedMeasurands. If the Charging Station has a meter, recommended to use as default: "Energy.Active.Import.Register"</td></tr></table>
+
+# 2.9.13. SampledDataUpstreamInterval
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>component Name</td><td colspan="2">SampledDataCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">UpstreamInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Interval between sampling of metering (or other) data, intended to be transmitted via TransactionRequest(eventType=Updated) messages for location = Upstream only. For transaction data (evseld>0), samples are acquired and transmitted periodically at this interval from the start of the charging transaction.A value of "0" (numeric zero), by convention, is to be interpreted to mean that no sampled data should be transmitted during the transaction.</td></tr></table>
+
+# 2.9.14.AlignedDataEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable reports a value of true, Aligned Data is enabled.</td></tr></table>
+
+# 2.9.15.AlignedDataAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable reports a value of true, Aligned Data is supported.</td></tr></table>
+
+# 2.9.16.AlignedDataMeasurands
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>AlignedDataCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">Measurands</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from Measurands</td></tr><tr><td>maxLimit</td><td>The maximum length of the CSV formatted string, to be defined by the implementer.</td></tr><tr><td>Description</td><td colspan="3">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.</td></tr></table>
+
+# 2.9.17.AlignedDataInterval
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Interval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">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. A value of "0" (numeric zero), by convention, is to be interpreted to mean that no clock-aligned data should be transmitted.</td></tr></table>
+
+# 2.9.18.AlignedDataSendDuringIdle
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SendDuringIdle</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If set to true, the Charging Station SHALL NOT send clock aligned meter values when a transaction is ongoing. When an EVSE is specified, it SHALL stop sending the clock aligned meter values for this EVSE when it has an ongoing transaction. When no EVSE is specified, it SHALL stop sending the clock aligned meter values when any transaction is ongoing on this Charging Station.</td></tr></table>
+
+# 2.9.19.AlignedDataSignReadings
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>AlignedDataCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SignReadings</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If set to true, the Charging Station SHALL include signed meter values in the SampledValueType in the TransactionRequest(Ended) for those measurands defined in AlIGNEDDataTxEndesa Measurands and optionally in TransactionRequest(Updated) as controlled by AlIGNEDDataSignUpdatedReadings. When a Charging Station does not support signed meter values, it SHALL NOT report this variable.</td></tr></table>
+
+# 2.9.20.AlignedDataSignUpdatedReadings
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SignUpdatedReadings</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If set to true, the Charging Station SHALL include signed meter values in the SampledValueType in the TransactionEventRequest(Updated) for those measurands configured in AlIGNEDDataMeasurands. This variable only has an effect if AlIGNEDDataSignReadings is set to true. When a Charging Station does not support signed meter values, it SHALL NOT report this variable.</td></tr></table>
+
+# 2.9.21.AlignedDataTxEndedMeasurands
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">TxEndedMeasurands</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from Measurands</td></tr><tr><td>maxLimit</td><td>The maximum length of the CSV formatted string, to be defined by the implementer.</td></tr><tr><td>Description</td><td colspan="3">Clock-aligned periodic measurand(s) to be included in the meterValues element of TransactionEventRequest (eventType = Ended) for every
+AlignedDataTxEndPeriodInterval 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 TxEndedAlignedData.
+When left empty, no Clock-aligned measurands SHALL be put into the
+TransactionEventRequest (eventType = Ended).</td></tr></table>
+
+# 2.9.22.AlignedDataTxEndedInterval
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>AlignedDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">TxEndInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">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 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.</td></tr></table>
+
+# 2.9.23.AlignedDataUpstreamMeasurands
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="6">Variable</td><td>variableName</td><td colspan="2">UpstreamMeasurands</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="4">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from Measurands</td></tr><tr><td>maxLimit</td><td>The maximum length of the CSV formatted string, to be defined by the implementer.</td></tr><tr><td>maxElem ents</td><td>Maximum number of values supported in variable.</td></tr><tr><td>Description</td><td colspan="3">Clock-aligned measurand(s) to be included in MeterValuesRequest, every AlignedDataUpstreamInterval seconds for location Upstream only. 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 AlignedDataUpstreamMeasurands.</td></tr></table>
+
+# 2.9.24.AlignedDataUpstreamInterval
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">AlignedDataCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">UpstreamInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td>Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the MeterValuesRequest message for location Upstream only. 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, 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.</td></tr></table>
+
+# 2.9.25.PublicKeyWithSignedMeterValue
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">PublicKeyWithSignedMeterValue</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>valuesList</td><td>Never,OncePerTransaction,EveryMeterValue</td></tr><tr><td>Description</td><td colspan="3">This Configuration Variable can be used to configure whether a public key needs to be sent with a signed meter value. Note, that instead of omitting the field when the public key is not sent, it is also allowed to send it as an empty string (as was the case in OCPP 2.0.1).</td></tr></table>
+
+# 2.9.26.FiscalMeterPublicKey
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">FiscalMetering</td></tr><tr><td>evse</td><td colspan="2"><any></td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">PublicKey</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">Configuration variable that can be used to retrieve the public key for a meter connected to a specific EVSE. The FiscalMetering component will typically be on the EVSE-tier level. There may be one at the Charging Station tier level for the overall input of the Charging Station, or for a Charging Station with a single EVSE.</td></tr></table>
+
+# 2.10. Reservation related
+
+# 2.10.1. ReservationEnabled
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>ReservationCtrl</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Reservation is enabled.</td></tr></table>
+
+# 2.10.2. ReservationAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ReservationCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Reservation is supported.</td></tr></table>
+
+# 2.10.3. ReservationNonEvseSpecific
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ReservationCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">NonEvseSpecific</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this configuration variable is present and set to true: Charging Station supports Reservation where EVSE id is not specified.</td></tr></table>
+
+# 2.11. Smart Charging related
+
+# 2.11.1. SmartChargingEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Smart Charging is enabled.</td></tr></table>
+
+# 2.11.2. SmartChargingAvailable
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Smart Charging is supported.</td></tr></table>
+
+# 2.11.3. ACPhaseSwitchingSupported
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ACPhaseSwitchingSupported</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">This variable can be used to indicate an on-load/in-transaction capability. If defined and true, this EVSE supports the selection of which phase to use for 1 phase AC charging.</td></tr></table>
+
+# 2.11.4. ChargingProfileMaxStackLevel
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ProfileStackLevel</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum acceptable value for stackLevel in a ChargingProfile. Since the lowest stackLevel is 0, this means that if SmartChargingCtrlr.ProfileStackLevel = 1, there can be at most 2 valid charging profiles per Charging Profile Purpose per EVSE.</td></tr></table>
+
+# 2.11.5. ChargingScheduleChargingRateUnit
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">RateUnit</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>A,W</td></tr><tr><td>Description</td><td colspan="3">A list of supported quantities for use in a ChargingSchedule.</td></tr></table>
+
+# 2.11.6.PeriodsPerSchedule
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">PeriodsPerSchedule</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of periods that may be defined per ChargingSchedule.</td></tr></table>
+
+# 2.11.7. ExternalControlSignalsEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>ijklname</td><td colspan="2">ExternalControlSignalsEnabled</td></tr><tr><td>ijklattributes</td><td>mutability</td><td>ReadOnly orReadWrite. Choice is up to Charging Station implementation.</td></tr><tr><td>ijklcharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Indicates whether a Charging Station is able to respond to external control signals that influence charging.
+If the variable is true, but CSMS has set ExternalConstraintsProfileDisallowed = true, then external control signals are only allowed during a charging profile from CSMS with a chargingProfilePeriod = ExternalLimits or ExternalSetpoint.</td></tr></table>
+
+# 2.11.8. ExternalConstraintsProfileDisallowed
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ExternalConstraintsProfileDisallowed</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Indicates whether a Charging Station allows an external system to submit limits to be represented as a ChargingStationExternalConstraints charging profile.When false or absent this configuration variable allows that ChargingStationExternalConstraints charging profiles are created. When true this forbids the creation of a ChargingStationExternalConstraints charging profile. In that case the only way for an external system to influence charging is when CSMS explicitly allows this during a charging profile with a schedule that contains an ExternalLimits or ExternalSetpoint period.</td></tr></table>
+
+# 2.11.9. NotifyChargingLimitWithSchedules
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">NotifyChargingLimitWithSchedules</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr></table>
+
+<table><tr><td>Description</td><td>Indicates if the Charging Station should include the externally set charging limit/schedule in the message when it sends a NotifyChargingLimitRequest message. This might increase the data usage significantly, especially when an external system sends new profiles/limits with a short interval. Default is false when omitted.</td></tr></table>
+
+# 2.11.10. Phases3to1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Phases3to1</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If defined and true, this Charging Station supports switching from 3 to 1 phase during a transaction.</td></tr></table>
+
+# 2.11.11. ChargingProfileEntries
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">Entries</td></tr><tr><td>variableInstance</td><td colspan="2">ChargingProfiles</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>Maximum number of Charging profiles installed at any time.</td></tr><tr><td>Description</td><td colspan="3">Amount of Charging profiles currently installed on the Charging Station.</td></tr></table>
+
+# 2.11.12. LimitChangeSignificance
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">LimitChangeSignificance</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>decimal</td></tr><tr><td>Description</td><td colspan="3">If at the Charging Station side a change in the limit in a ChargingProfile is lower than this percentage, the Charging Station MAY skip sending a NotifyChargingLimitRequest or a TransactionEventRequest message to the CSMS. It is RECOMMENDED to set this key to a low value. See Smart Charging signals to a Charging Station from multiple actors.</td></tr></table>
+
+# 2.11.13. ChargingProfilePersistence
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>SmartChargingCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ChargingProfilePersistence</td></tr><tr><td>variableInstancee</td><td colspan="2">"TxProfile", "LocalGeneration", "ChargingStationExternalConstraints"</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If an instance of this variable is true, then charging profiles with the chargingProfilePurpose mentioned in the variableInstance are persistent, i.e. they are stored persistently and will still exist after a reboot. When these variables are not present or false, then these profiles are not stored in persistent memory.
+Note: ChargingStationMaxProfile, TxDefaultProfile and PriorityCharging are always persistent (as per K01.FR.27)</td></tr></table>
+
+# 2.11.14. ChargingProfileUpdateRateLimit
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">UpdateRateLimit</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">This configuration key limits how often a persistent charging profile can be updated. It is the minimum duration in seconds between updates of charging profiles of the same chargingProfilePurpose. A Charging Station may reject SetChargingProfileRequests that occur too frequently.
+ChargingStationMaxProfile, TxDefaultProfile and PriorityCharging are always persistent (as per K01.FR.27). Other chargingProfilePurpose profiles may be persistent when reported as such in ChargingProfilePersistence.</td></tr></table>
+
+# 2.11.15. SetpointPriority
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SetpointPriority</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>valuesList</td><td>ExternalSystem,CSMS</td></tr><tr><td>Description</td><td colspan="3">Defines which setpoint shall be used when a ChargingStationExternalConstraints profile with a operationMode = ExternalSetpoint is active, but at the same time a Tx(Default)Profile charging profile is also active with a setpoint. By default, (when variable is absent) the setpoint from ChargingStationExternalConstraints takes precedence.</td></tr></table>
+
+# 2.11.16. MaxExternalConstraintsId
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">MaxExternalConstraintsId</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Defines the highest value that a charging profile id of a ChargingStationExternalConstraints profile in the Charging Station can have. CSMS will use charging profile id's above this value to avoid conflicts with ChargingStationExternalConstraints profiles created by the Charging Station.</td></tr></table>
+
+# 2.11.17. SupportedAdditionalPurposes
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportedAdditionalPurposes</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>PriorityCharging, LocalGeneration</td></tr><tr><td>Description</td><td colspan="3">This configuration variable lists the additional ChargingProfilePurposeEnumType, that have been introduced in OCPP 2.1, that are supported by the Charging Station. When this variable is absent or an empty list, then the purposes PriorityCharging and LocalGeneration are not supported.</td></tr></table>
+
+# 2.11.18. SupportsDynamicProfiles
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportsFeature</td></tr><tr><td>instanceName</td><td colspan="2">DynamicProfiles</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>hvariableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When this variable has value True, then the Charging Station supports charging profiles of ChargingProfileKindEnumType Dynamic. This implies that the fields dynUpdateInterval and dynUpdateTime in ChargingProfileType are supported. When this variable is absent or false, dynamic charging profiles are not supported.</td></tr></table>
+
+# 2.11.19. SupportsMaxOfflineDuration
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportsFeature</td></tr><tr><td>instanceName</td><td colspan="2">MaxOfflineDuration</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When this variable has value True, then the Charging Station supports the fields maxOfflineDuration and invalidAfterOfflineDuration in ChargingProfileType. When this variable is absent or false then these fields are not supported.</td></tr></table>
+
+# 2.11.20. SupportsLocalTime
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportsFeature</td></tr><tr><td>instanceName</td><td colspan="2">UseLocalTime</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When this variable has value True, then the Charging Station supports the field useLocalTime in ChargingScheduleType. If useLocalTime = true in a charging schedule, then the startSchedule is treated as unqualified local time of the Charging Station. When this variable is absent or false, the useLocalTime is not supported.</td></tr></table>
+
+# 2.11.21. SupportsRandomizedDelay
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportsFeature</td></tr><tr><td>instanceName</td><td colspan="2">RandomizedDelay</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When this variable has value True, then the Charging Station supports the field randomizedDelay in ChargingScheduleType, which will delay the start of each charging schedule period by a random number between 0 and randomizedDelay. When this variable is absent or false, then randomizedDelay is not supported.</td></tr></table>
+
+# 2.11.22. SupportsLimitAtSoC
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportsFeature</td></tr><tr><td>instanceName</td><td colspan="2">LimitAtSoC</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When this variable has value True, then the Charging Station supports the field limitAtSoC in ChargingScheduleType, which will cap the limit or setpoint in the ChargingSchedulePeriodType by the value of limitAtSoClimit. When this variable is absent or false, then limitAtSoC is not supported.</td></tr></table>
+
+# 2.11.23. supportsEvseSleep
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">SmartChargingCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportsFeature</td></tr><tr><td>instanceName</td><td colspan="2">EvseSleep</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When reported as true the Charging Station supports the evseSleep flag in a ChargingSchedulePeriodType, which requests the EVSE electronics to go to sleep during operationMode = 'Idle'. When absent or false this option is not supported.</td></tr></table>
+
+# 2.12. Tariff & Cost related
+
+# 2.12.1. TariffAvailable
+
+Updated in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableInstance</td><td colspan="2">Tariff</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If true then the Charging Station supports the TariffType structure, that describes the tariff in a machine-readable format.
+Note 1: The capability will not be active until TariffEnabled is set to true.
+Note 2: Local cost calculation based on this tariff requires that CostEnabled is true.</td></tr></table>
+
+# 2.12.2. TariffEnabled
+
+Updated in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableInstance</td><td colspan="2">Tariff</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If true then the Charging Station has enabled support for the TariffType structure, that describes the tariff in a machine-readable format. Note: Local cost calculation based on this tariff requires that CostEnabled is true.</td></tr></table>
+
+# 2.12.3. TariffFallbackMessage
+
+Updated in OCPP 2.1
+
+Required for Charging Stations supporting tariff information.
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">TariffFallbackMessage</td></tr><tr><td>variableInstance</td><td colspan="2">< RFC5646 language code></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>512</td></tr><tr><td>Description</td><td colspan="3">Message (and/or tariff information) to be shown to an EV Driver when there is no driver specific tariff information available.</td></tr></table>
+
+# 2.12.4. CostAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableInstance</td><td colspan="2">Cost</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If true, then Charging Station supports local cost calculation.
+Note: The capability will not be active until CostEnabled is set to true.</td></tr></table>
+
+# 2.12.5. Enabled
+
+Updated in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableInstancee</td><td colspan="2">Cost</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If true, then local cost calculation is enabled on Charging Station.
+If false, then CSMS is responsible for cost calculation.
+If TariffEnabled is true, then the local cost calculation is performed based on the provided TariffType, else the local cost calculation is based on other non-specified (e.g. proprietary) information.</td></tr></table>
+
+# 2.12.6. TotalCostFallbackMessage
+
+Updated in OCPP 2.1
+
+Required for Charging Stations supporting Tariff Information.
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">TotalCostFallbackMessage</td></tr><tr><td>variableInstance</td><td colspan="2">< RFC5646 language code></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>512</td></tr><tr><td>Description</td><td colspan="3">Message to be shown to an EV Driver when the Charging Station cannot retrieve the cost for a transaction at the end of the transaction.</td></tr></table>
+
+# 2.12.7. Currency
+
+Updated in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, only when TariffEnabled = false</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Currency</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>3</td></tr><tr><td>Description</td><td colspan="3">Currency used by this Charging Station in a ISO 4217 [ISO4217] formatted currency code. Charging Station will omit or ignore this value when TariffEnabled = true, because TariffType already contains a currency.</td></tr></table>
+
+# 2.12.8.OfflineTariffFallbackMessage
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">OfflineTariffFallbackMessage</td></tr><tr><td>variableInstancee</td><td colspan="2"><RFC5646 language code></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>maxLimit</td><td>512</td></tr><tr><td>Description</td><td colspan="3">Message (and/or tariff information) to be shown to an EV Driver when Charging Station is offline. Language codes shall be specified as RFC5646. The short form is allowed if no regional variant is needed. For example: "en" (English), "es" (Spanish), "fr" (French).As instances aren't dynamic in the device model, the station will need to expose all languages that it supports.A Charging Station that has no language support and does not support multiple languages should report a single variable without an instance.</td></tr></table>
+
+# 2.12.9. RunningCostEnabled
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, if CostAvailable = true</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableInstancee</td><td colspan="2">RunningCost</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If true then Charging Station will provide periodic running cost updates in costDetails in TransactionEventRequest messages.</td></tr></table>
+
+# 2.12.10. CostInterval
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, if CostAvailable = true</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="6">Variable</td><td>variableName</td><td colspan="2">Interval</td></tr><tr><td>variableInstance</td><td colspan="2">Cost</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>minLimit</td><td>>0</td></tr><tr><td>Description</td><td colspan="3">Specifies the interval in seconds to use to provide periodic running cost updates during a transaction. The value of minLimit given by Charging Station specifies the minimal interval that Charging Station will accept.</td></tr></table>
+
+# 2.12.11. TariffInterval
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, if TariffAvailable = true and CostAvailable = true</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="6">Variable</td><td>variableName</td><td colspan="2">Interval</td></tr><tr><td>variableInstance</td><td colspan="2">Tariff</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>minLimit</td><td>>=0</td></tr><tr><td>Description</td><td colspan="3">Interval specifies the maximum interval in seconds to use when evaluating the conditions regarding current, power and energy of a tariff element during a transaction. The value of minLimit given by Charging Station specifies the minimal interval that Charging Station will accept. A value of Interval[Tariff] of 0 means Charging Station will evaluate current, power and energy values using the shortest interval possible for this Charging Station.</td></tr></table>
+
+# 2.12.12. TariffMaxElements
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, if TariffAvailable = true</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">MaxElements</td></tr><tr><td>variableInstance</td><td colspan="2">Tariff</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>minLimit</td><td>>=0</td></tr><tr><td>Description</td><td colspan="3">Specifies the maximum number of prices elements that the Charging Station supports in each TariffEnergyType (energy), TariffTimeType (chargingTime, idleTime) and TariffFixedType (fixedFee) of a TariffType.</td></tr></table>
+
+# 2.12.13. TariffConditionsSupported
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, if TariffAvailable = true</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ConditionsSupported</td></tr><tr><td>variableInstance</td><td colspan="2">Tariff</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr></table>
+
+<table><tr><td>Description</td><td>If set to true the Charging Station supports tariffs with conditions (TariffConditionsType and TariffConditionsFixedType). If set to false, the Charging Station does not support conditions in tariffs.</td></tr></table>
+
+# 2.12.14. HandleFailedTariff
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, if TariffAvailable = true</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">TariffCostCtrlr</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">HandleFailedTariff .</td></tr><tr><td>variableInstance</td><td colspan="2">Tariff</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>memberList</td><td>"Deauthorize", "UseDefaultTariff", "CentralCost"</td></tr><tr><td>Description</td><td colspan="3">This configuration determines how to act when a driver-specific tariff is received, which cannot be processed.
+· Deauthorize: deauthorize the idToken, such that no energy will be delivered.
+· UseDefaultTariff: fallback to the default tariff.
+· CentralCost: let CSMS perform the cost calculation.</td></tr></table>
+
+# 2.13. Diagnostics related
+
+# 2.13.1. MonitoringEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Monitoring is enabled.</td></tr></table>
+
+# 2.13.2. MonitoringAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Monitoring is supported.</td></tr></table>
+
+# 2.13.3. ItemsPerMessageClearVariableMonitoring
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ItemsPerMessage</td></tr><tr><td>variableInstancee</td><td colspan="2">ClearVariableMonitoring</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of IDs in a ClearVariableMonitoringRequest.</td></tr></table>
+
+# 2.13.4. ItemsPerMessageSetVariableMonitoring
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ItemsPerMessage</td></tr><tr><td>variableInstancee</td><td colspan="2">SetVariableMonitoring</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Maximum number of setMonitoringData elements that can be sent in one setVariableMonitoringRequest message.</td></tr></table>
+
+# 2.13.5. BytesPerMessageClearVariableMonitoring
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BytesPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">ClearVariableMonitoring</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Message Size (in bytes) - puts constraint on ClearVariableMonitoringRequest message size.</td></tr></table>
+
+# 2.13.6. BytesPerMessageSetVariableMonitoring
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">BytesPerMessage</td></tr><tr><td>variableInstance</td><td colspan="2">SetVariableMonitoring</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr></table>
+
+<table><tr><td>Description</td><td>Message Size (in bytes) - puts constraint on setVariableMonitoringRequest message size.</td></tr></table>
+
+# 2.13.7.OfflineMonitoringEventQueuingSeverity
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">OfflineQueuingSeverity</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When set and the Charging Station is offline, the Charging Station shall queue any NotifyEventRequest messages triggered by a monitor with a severity number equal to or lower than the severity configured here. Value ranging from 0 (Emergency) to 9 (Debug).</td></tr></table>
+
+# 2.13.8.ActiveMonitoringBase
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ActiveMonitoringBase</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>valuesList</td><td>values from MonitoringBaseEnumType</td></tr><tr><td>Description</td><td colspan="3">Shows the last set MonitoringBase. Valid values according
+MonitoringBaseEnumType: All, FactoryDefault, HardwiredOnly.</td></tr></table>
+
+# 2.13.9.ActiveMonitoringLevel
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ActiveMonitoringLevel</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Shows the currently used MonitoringLevel. Valid values are severity levels of SetMonitoringLevelRequest: 0-9.</td></tr></table>
+
+# 2.13.10. MonitoringMaxPeriodicEventStreams
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">MonitoringCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">MaxPeriodicEventStreams</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr></table>
+
+<table><tr><td>Description</td><td>The maximum number of open periodic event streams that Charging Station supports. A periodic event stream is opened by a Charging Station in reaction to a SetVariableMonitoringRequest with a periodicEventStream field, or can be opened at its own initiative.
+This variable is required, when event streams are supported.</td></tr></table>
+
+# 2.14. Display Message related
+
+# 2.14.1.DisplayMessageEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DisplayMessageCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Display Message is enabled.</td></tr></table>
+
+# 2.14.2. DisplayMessageAvailable
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DisplayMessageCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Whether Display Message is supported.</td></tr></table>
+
+# 2.14.3.NumberOfDisplayMessages
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DisplayMessageCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variablerName</td><td colspan="2">DisplayMessages</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>Maximum number of different messages that can configured in this Charging Station simultaneous, via SetDisplayMessageRequest.</td></tr><tr><td>Description</td><td colspan="3">Amount of different messages that are currently configured in this Charging Station, via SetDisplayMessageRequest</td></tr></table>
+
+# 2.14.4.DisplayMessageSupportedFormats
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>DisplayMessageCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportedFormats</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from MessageFormatEnumType</td></tr><tr><td>Description</td><td colspan="3">List of message formats supported by this Charging Station.</td></tr></table>
+
+# 2.14.5. DisplayMessageSupportedPriorities
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DisplayMessageCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportedPriorities</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from MessagePriorityEnumType</td></tr><tr><td>Description</td><td colspan="3">List of the priorities supported by this Charging Station.</td></tr></table>
+
+# 2.14.6.DisplayMessageSupportedStates
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DisplayMessageCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SupportedStates</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from MessageStateEnumType</td></tr><tr><td>Description</td><td colspan="3">List of the states during which to display a message, supported by this Charging Station.</td></tr></table>
+
+# 2.14.7.DisplayMessageLanguage
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">DisplayMessageCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Language</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>valuesList</td><td>values from RFC 5646</td></tr><tr><td>Description</td><td colspan="3">Default language code, per RFC 5646, of this Charging Station. Languages that are supported are listed in the valuesList.</td></tr></table>
+
+# 2.15. Charging Infrastructure related
+
+# 2.15.1.Available
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td rowspan="4">Components</td><td rowspan="3">componentName</td><td colspan="2">ChargingStation</td></tr><tr><td colspan="2">EVSE</td></tr><tr><td colspan="2">Connector</td></tr><tr><td>evse</td><td colspan="2">* (for EVSE and Connector)</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Available</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">When true the Component exists and is locally configured/wired for use, but may not be (remotely) Enabled. This variable is required on any Component that can be reported by the Charging Station. As a minimum it shall exist on ChargingStation, EVSE and Connector.</td></tr><tr><td>Note</td><td colspan="3">If any other variables are reported for a Component, then reporting Available does not add much value and may be omitted. However, the variable needs to exist, because it can be queried for by a GetCustomReport request for all Components that are 'available'.
+EVSE and Connector components are addressed on their respective tier. So, EVSE #1 is addressed as component EVSE on tier "evse = 1" and connector #1 on this EVSE is addressed as component Connector on tier "evse = 1, connector = 1.</td></tr></table>
+
+# 2.15.2. AvailabilityState
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td rowspan="4">Components</td><td rowspan="3">componentName</td><td colspan="2">ChargingStation</td></tr><tr><td colspan="2">EVSE</td></tr><tr><td colspan="2">Connector</td></tr><tr><td>evse</td><td colspan="2">*(for EVSE and Connector)</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">AvailabilityState</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>optionList</td></tr><tr><td>valuesList</td><td>Available, Occupied, Reserved, Unavailable, Faulted</td></tr><tr><td>Description</td><td colspan="3">This variable reports current availability state for the ChargingStation, EVSE and Connector. When this variable reports the Connector AvailabilityState, it replicates the connectorStatus values as would be reported by the StatusNotification messages.
+An EVSE or Connector component is addressed on its own tier. So, EVSE #1 is addressed as component EVSE on tier evse.id = 1, and EVSE #1, Connector #1 is addressed as component Connector on tier evse.id = 1, evseconnectorId = 1.</td></tr></table>
+
+# 2.15.3. AllowReset
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td>EVSE</td></tr><tr><td>evse</td><td>*</td></tr></table>
+
+<table><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">AllowReset</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Component can be reset. Can be used to announce that an EVSE can be reset individually.</td></tr></table>
+
+# 2.15.4. ConnectorType
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">Connector</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ConnectorType</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">Value of the type of connector as defined by ConnectorEnumType in "Part 2 - Specification" plus additionally: cGBT, cChaoJi, OppCharge.</td></tr></table>
+
+# 2.15.5. PhaseRotation
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">*</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">PhaseRotation</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly orReadWrite.</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>String</td></tr></table>
+
+<table><tr><td>Description</td><td>This variable describes the phase rotation of a Component relative to its parent Component, using a three letter string consisting of the letters: R, S, T and x.</td></tr><tr><td></td><td>The letter 'R' can be identified as phase 1 (L1), 'S' as phase 2 (L2), 'T' as phase 3 (L3).</td></tr><tr><td></td><td>The lower case 'x' is used to designate a phase that is not connected. An empty string means that phase rotation is not applicable or not known.</td></tr><tr><td></td><td>Certain measurands, like voltage and current, are reported with a phase relative to the grid connection. In order to support this, all components in the chain from Connector to ElectricalFeed need to have a value for PhaseRotation.</td></tr><tr><td></td><td>Some examples:
+"'' (unknown)
+"RST" (Standard Reference Phasing)
+"RTS" (Reversed Reference Phasing)
+"SRT" (Reversed 240 degree rotation)
+"STR" (Standard 120 degree rotation)
+"TRS" (Standard 240 degree rotation)
+"TSR" (Reversed 120 degree rotation)
+"RSx" (Two phases connected)
+"Rxx" (One phase connected)</td></tr></table>
+
+# 2.15.6. SupplyPhases
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td rowspan="4">Components</td><td rowspan="3">componentName</td><td colspan="2">ChargingStation</td></tr><tr><td colspan="2">EVSE</td></tr><tr><td colspan="2">Connector</td></tr><tr><td>evse</td><td colspan="2">* (for EVSE and Connector)</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SupplyPhases</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Number of alternating current phases connected/available. 1 or 3 for AC, 0 means DC (no alternating phases). Null value indicates that the number of phases (e.g. in use) is unknown.</td></tr></table>
+
+# 2.15.7. DCInputPhaseControl
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">EVSE</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">DCInputPhaseControl</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr></table>
+
+<table><tr><td>Description</td><td>When DCInputPhaseControl is true, then the values of numberPhases and PhaseToUse in a ChargingSchedulePeriodType will select the input phases from the grid to be used by the DC EVSE.</td></tr></table>
+
+# 2.15.8. Power
+
+<table><tr><td>Required</td><td colspan="3">yes (maxLimit only)</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">EVSE</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Power</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>decimal</td></tr><tr><td>maxLimit</td><td>decimal</td></tr><tr><td>Description</td><td colspan="3">The variableCharacteristic maxLimit, that holds the maximum power that this EVSE can provide, is required. The Actual value of the instantaneous (real) power is desired, but not required.</td></tr></table>
+
+# 2.15.9. DischargePower
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">EVSE</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">DischargePower</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>dataType</td><td>decimal</td></tr><tr><td>maxLimit</td><td>decimal</td></tr><tr><td>maxSet</td><td>decimal</td></tr><tr><td>Description</td><td colspan="3">This variable is required when V2X is supported.The variableCharacteristic maxLimit holds the maximum rated discharge power that this EVSE can provide.The variableCharacteristic maxSet holds the maximum configured discharge power that this EVSE can provide.The Actual value of the instantaneous (real) discharge power is recommended to be supported, but not required.Discharge power is represented by a positive value.</td></tr></table>
+
+# 2.15.10. EvseChargingState
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">EVSE</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ChargingState</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>valuesList</td><td>"EVConnected", "Charging", "SuspendedEV", "SuspendedEVSE", "Idle"</td></tr><tr><td>Description</td><td>This variable reports the current transaction charging state for an EVSE.</td></tr></table>
+
+# 2.15.11. EvseActiveTransactionId
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">EVSE</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ActiveTransactionId</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">This variable contains the transaction ID of the running transaction at the EVSE. If no transaction is active, it is an empty string.</td></tr></table>
+
+# 2.15.12. ChargingStationActiveTransactionId
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ChargingStation</td></tr><tr><td rowspan="3">Variable</td><td>ijklname</td><td colspan="2">ActiveTransactionId</td></tr><tr><td>ijklattributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>ijklcharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">This variable for the ChargingStation component contains a comma-separated list of transaction IDs actively running on the Charging Station. This list may contain transaction IDs that are not part of EvseActiveTransactionId when the transaction has not yet been assigned to an EVSE.</td></tr></table>
+
+# 2.15.13. Example Reporting of EVSEs and Connectors via device model
+
+The following example illustrates how the device model reports EVSEs and Connectors for an example charging station that has two EVSEs, of which EVSE #1 has one Type2 connector and EVSE #2 has two connectors: CCS and CHAdeMO.
+
+<table><tr><td colspan="4">Component</td><td colspan="2">Variable</td><td colspan="2">VariableAttribute</td><td colspan="3">VariableCharacteristics</td></tr><tr><td>name</td><td>evse id</td><td>evse conne-ctorld</td><td>instance</td><td>name</td><td>instance</td><td>type</td><td>value</td><td>dataType</td><td>maxLimit</td><td>supports Monitorin g</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>AvailabilityState</td><td></td><td>Actual</td><td>Available</td><td>boolean</td><td></td><td>false</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>SupplyPhases</td><td></td><td>Actual</td><td>3</td><td>integer</td><td></td><td>false</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>ACCurrent</td><td>"L1"</td><td>Actual</td><td>45.0</td><td>decimal</td><td></td><td>true</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>ACCurrent</td><td>"L2"</td><td>Actual</td><td>44.9</td><td>decimal</td><td></td><td>true</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>ACCurrent</td><td>"L3"</td><td>Actual</td><td>44.9</td><td>decimal</td><td></td><td>true</td></tr><tr><td>EVSE</td><td>1</td><td></td><td>"left"</td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>1</td><td></td><td>"left"</td><td>AvailabilityState</td><td></td><td>Actual</td><td>Available</td><td>optionList</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>1</td><td></td><td>"left"</td><td>SupplyPhases</td><td></td><td>Actual</td><td>3</td><td>integer</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>1</td><td></td><td>"left"</td><td>Power</td><td></td><td>Actual</td><td>0.0</td><td>decimal</td><td>22000.0</td><td>true</td></tr><tr><td>Connector</td><td>1</td><td>1</td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>Connector</td><td>1</td><td>1</td><td></td><td>ConnectorType</td><td></td><td>Actual</td><td>sType2</td><td>string</td><td></td><td>false</td></tr><tr><td>Connector</td><td>1</td><td>1</td><td></td><td>SupplyPhases</td><td></td><td>Actual</td><td>3</td><td>integer</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>2</td><td></td><td>"right"</td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>2</td><td></td><td>"right"</td><td>AvailabilityState</td><td></td><td>Actual</td><td>Occupied</td><td>optionList</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>2</td><td></td><td>"right"</td><td>SupplyPhases</td><td></td><td>Actual</td><td>0</td><td>integer</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>2</td><td></td><td>"right"</td><td>Power</td><td></td><td>Actual</td><td>41000.0</td><td>decimal</td><td>50000.0</td><td>true</td></tr><tr><td>Connector</td><td>2</td><td>1</td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>1</td><td></td><td>AvailabilityState</td><td></td><td>Actual</td><td>Occupied</td><td>optionList</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>1</td><td></td><td>ConnectorType</td><td></td><td>Actual</td><td>cCCS2</td><td>string</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>1</td><td></td><td>SupplyPhases</td><td></td><td>Actual</td><td>0</td><td>integer</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>2</td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>2</td><td></td><td>AvailabilityState</td><td></td><td>Actual</td><td>Unavailable</td><td>optionList</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>2</td><td></td><td>ConnectorType</td><td></td><td>Actual</td><td>cG105</td><td>string</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>2</td><td></td><td>SupplyPhases</td><td></td><td>Actual</td><td>0</td><td>integer</td><td></td><td>false</td></tr></table>
+
+# 2.16. ISO 15118 related
+
+# 2.16.1. CentralContractValidationAllowed
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">CentralContractValidationAllowed</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable exists and has the value true, then Charging Station can provide a contract certificate that it cannot validate, to the CSMS for validation as part of theauthorizeRequest.</td></tr></table>
+
+# 2.16.2. ContractValidationOffline
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ContractValidationOffline</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable is true, then Charging Station will try to validate a contract certificate when it is offline.</td></tr></table>
+
+# 2.16.3. ISO15118PnCEnabled
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>ISO15118Ctrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">PnCEnabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable is true, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is enabled.
+If this variable is false, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is disabled.</td></tr></table>
+
+# 2.16.4. ISO15118V2G Certificate InstallationEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">V2GCertificateInstallationEnabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable is true, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station is enabled. If this variable is false, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station is disabled.</td></tr></table>
+
+# 2.16.5. ISO15118ContractCertificateInstallationEnabled
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ContractCertificateInstallationEnabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If this variable is true, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is enabled. If this variable is false, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is disabled.</td></tr></table>
+
+# 2.16.6. ISO15118RequestMeteringReceipt
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">RequestMeteringReceipt</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr></table>
+
+<table><tr><td>Description</td><td>If this variable is true, then Charging Station shall request a metering receipt from EV before sending a fiscal meter value to CSMS.</td></tr></table>
+
+# 2.16.7. ISO15118SeccId
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td>evse</td><td colspan="2">* (optional)</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Seccld</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">The name of the SECC in the string format as required by ISO 15118.
+It is used as the commonName (CN) of the SECC leaf certificate.
+Maximum length of a commonName is 64 characters.
+Example: "DE-ICE-S-0003C4D5578786756453309675436-2"</td></tr></table>
+
+# 2.16.8. ISO15118CountryName
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td>evse</td><td colspan="2">* (optional)</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">CountryName</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">The countryName of the SECC in the ISO 3166-1 format.
+It is used as the countryName (C) of the SECC leaf certificate.
+Example: "DE"</td></tr></table>
+
+# 2.16.9.ISO15118OrganizationName
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td>evse</td><td colspan="2">* (optional)</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">OrganizationName</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">The organizationName of the CSO operating the charging station.
+It is used as the organizationName (O) of the SECC leaf certificate.
+Example: "John Doe Charging Services Ltd"
+Note: This value will usually be identical to SecurityCtrlr.OrganizationName, but it does not have to be.</td></tr></table>
+
+# 2.16.10. ISO15118EvseId
+
+<table><tr><td>Required</td><td>no</td></tr></table>
+
+<table><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">EVSE</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ISO15118Evseld</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">The name of the EVSE in the string format as required by ISO 15118 and IEC 63119-2.
+Example: "DE*ICE*E*1234567890*1"</td></tr></table>
+
+# 2.16.11.ISO15118NotificationMaxDelay
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">NotificationMaxDelay</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly, ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">The SECC (EVSE) uses the NotificationMaxDelay element in the EVSEStatus to indicate the time in seconds until it expects the EVCC (EV) to react on the action request indicated in EVSENotification.</td></tr></table>
+
+# 2.16.12. ISO15118ServiceRenegotiationSupport
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">ServiceRenegotiationSupport</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">If set to 'True' the SECC (EVSE) is capable of ServiceRenegotiation. When absent defaults to 'False'.</td></tr></table>
+
+# 2.16.13. ISO15118SupportedProviders
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td>ISO15118Ctrlr</td></tr><tr><td>evse</td><td>*</td></tr></table>
+
+<table><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">SupportedProviders</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">A comma-separated list of all providers (eMSPs) that are supported on this Charging Station. The providers are listed using country and provider ID from the EMAID, as defined in ISO 15118-20. When receiving an ISO 15118-20 AuthorizationSetupReq from EV, charging station may use this string to return a list of supported providers.</td></tr></table>
+
+# 2.16.14.ISO15118MaxPriceElements
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">MaxPriceElements</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>maxLimit</td><td>1024</td></tr><tr><td>minLimit</td><td>12</td></tr><tr><td>Description</td><td colspan="3">The maximum number of priceRuleStacks and priceLevelScheduleEntries that Charging Station is able to accept in a ChargingScheduleType. ISO 15118 requires support for a minimum of 12 entries.</td></tr></table>
+
+# 2.16.15. ISO15118ProtocolSupported
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">ISO15118Ctrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ProtocolSupported</td></tr><tr><td>variableInstance</td><td colspan="2"><for number of protocols supported></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">A string with the following comma-separated items:
+" <uri>, <major>, <minor>".
+<uri> is in the format as used in the SupportedAppProtocolReq message from ISO 15118-2 and ISO 15118-20.
+This variable has at most 20 instances; one for each supported protocol version.
+Instances are numbered from 1 to 20 (at most) as a string, i.e. "1", "2", etc, but unlike the variable ProcotolSupportedByEV from ConnectedEV for ISO 15118 this does not specify a priority, since priority is given by EV.
+Example:
+- ISO15118CtrlrpoonsProtocolSupported["1"] = "urn:iso:15118:2:2013:MsgDef,2,0"
+- ISO15118CtrlrpoonsProtocolSupported["2"] = "urn:iso:std:iso:15118:-20:DC,1,0"</td></tr></table>
+
+# 2.17. Connected EV related
+
+New in OCPP 2.1
+
+This section is new, but the ConnectedEV component already existed in OCPP 2.0.1. The full list of variables of the ConnectedEV component has been moved from part 2 - Appendices, to part 2 Specification - Referenced Components and Variables.
+
+# 2.17.1. ConnectedEV for ISO 15118
+
+Updated in OCPP 2.1
+
+Required variables
+
+<table><tr><td>Required</td><td colspan="2">When supporting V2X</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td>ConnectedEV</td></tr><tr><td>evse</td><td>* (EVSE to which EV is connected)</td></tr><tr><td colspan="3">Description</td></tr><tr><td colspan="3">ConnectedEV is a component that represents a connected vehicle for which data is received via an ISO 15118 or CHAdeMO interface. The information that is received, is represented as variables of ConnectedEV.</td></tr></table>
+
+<table><tr><td>Variable</td><td>Unit</td><td>ISO 15118-2 value</td><td>ISO 15118-20 value</td></tr><tr><td>Available</td><td>boolean</td><td colspan="2">When true this means an EV is connected.
+When false, all other fields are meaningless and should be empty strings.</td></tr><tr><td colspan="4">Protocol and static vehicle information</td></tr><tr><td>VehicleId</td><td>string</td><td>EVCCID (from SessionSetupReq)
+Six bytes, represented as hexadecimal encoded string, e.g. "010203040A0B", containing the EVCC MAC address.</td><td>EVCCID (from SessionSetupReq)
+Max 255 bytes with the first 3 bytes containing the WMI as defined in ISO 3780:2009.</td></tr><tr><td>VehicleCertificate["Leaf"]</td><td>string</td><td>n/a</td><td>The PEM encoded X.509 Leaf certificate of the vehicle certificate chain</td></tr><tr><td>VehicleCertificate["SubCA1"]</td><td>string</td><td>n/a</td><td>The PEM encoded X.509 intermediate SubCA1 certificate when present in the vehicle certificate chain</td></tr><tr><td>VehicleCertificate["SubCA2"]</td><td>string</td><td>n/a</td><td>The PEM encoded X.509 intermediate SubCA2 certificate, when present in the vehicle certificate chain</td></tr><tr><td>VehicleCertificate["Root"]</td><td>string</td><td>n/a</td><td>Optional. The PEM encoded X.509 Root certificate of the vehicle certificate chain</td></tr><tr><td>ProtocolAgreed</td><td>string</td><td>A string with the following comma-separated items:
+"<uri>,<major>,<minor>".
+This is the protocol URI and version information agreed upon between EV and EVSE in the supportedAppProtocolReq handshake from ISO 15118.
+Example for ISO 15118-2:
+"urn:iso:15118:2:2013:MsgDef,1,0"
+(1,0 = version 1.0)
+For DIN SPEC 70121:
+"urn:din:70121:2012:MsgDef"</td><td>Same definition.
+Example for ISO 15118-20:
+"urn:iso:std:iso:15118:-20:DC,1,0"
+(or AC, ACDP, WPT, etc.)</td></tr></table>
+
+Optional variables
+
+<table><tr><td>Variable</td><td>Unit</td><td>ISO 15118-2 value</td><td>ISO 15118-20 value</td></tr><tr><td>ProtocolSupportedBy EV["1"] to ProtocolSupportedBy EV["20"]</td><td>multi-instance string</td><td>A string with the following comma-separated items:
+"<uri>,<major>,<minor)". This is information from the SupportedAppProtocolReq message from ISO 15118
+This variable has 20 instances; one for each priority number. Priority is a number from 1 to 20 as a string, i.e. "1", "2", etc.
+Example:
+- ConnectedEV.ProTOCOLSupportedByEV["1"] = "urn:iso:15118:2:2013:MsgDef,2,0"
+- ConnectedEV.ProTOCOLSupportedByEV["2"] = "urn:iso:15118:2:2010:MsgDef,1,0"</td><td>Same definition.
+Example for ISO 15118-20:
+"urn:iso:std:iso:15118:-20:DC,1,0"
+(or AC, ACDP, WPT, etc.)</td></tr></table>
+
+<table><tr><td>Variable</td><td>Unit</td><td>ISO 15118-2 value</td><td>ISO 15118-20 value</td></tr><tr><td colspan="4">Voltage and current values: (from ChargeParameterDiscoveryReq unless stated otherwise)</td></tr><tr><td>ACCurrent.minSet</td><td>A</td><td>EVMinCurrent</td><td>-</td></tr><tr><td>ACCurrent.maxSet</td><td>A</td><td>EVMaxCurrent</td><td>-</td></tr><tr><td>ACVoltage.maxSet</td><td>V</td><td>EVMaxVoltage</td><td>-</td></tr><tr><td>DCCurrent.minSet</td><td>A</td><td>-</td><td>EVMiniumChargeCurrent</td></tr><tr><td>DCCurrent.maxSet</td><td>A</td><td>EVMaximumCurrentLimit</td><td>EVMiniumChargeCurrent</td></tr><tr><td>DCCurrent.target</td><td>A</td><td>EVTargetCurrent (CurrentDemandReq)</td><td>EVTTargetCurrent (DC_ChargeLoopReq)</td></tr><tr><td>DCVoltage.minSet</td><td>V</td><td>-</td><td>EVMiniumVoltage</td></tr><tr><td>DCVoltage.maxSet</td><td>V</td><td>EVMaximumVoltageLimit</td><td>EVMiniumVoltage</td></tr><tr><td>DCVoltage.target</td><td>V</td><td>EVTTargetVoltage (CurrentDemandReq)</td><td>EVTTargetVoltage (DC_ChargeLoopReq)</td></tr><tr><td colspan="4">Power, energy and time values:</td></tr><tr><td>Power.maxSet</td><td>W</td><td>EVMaximumPowerLimit (DC)</td><td>EVMaximumChargePower (AC/DC)All phases combined.</td></tr><tr><td>DischargePower.maxSet</td><td>W</td><td>-</td><td>EVMaximumDischargePower (AC/DC)Rated maximum, all phases combined (Actual discharging power is reported via EVSE)</td></tr><tr><td>DischargePower.actuaIal</td><td>W</td><td>-</td><td>EVMaximumDischargePower (AC/DC) (BPT ChargeLoopReq)Actual maximum, all phases combined</td></tr><tr><td>Energylimport.maxSet</td><td>Wh</td><td>EVEnergyCapacity (DC)</td><td>EVMaximumEnergyRequest(ScheduleExchangeReq,AC/DC_ChargeLoopReq)</td></tr><tr><td>Energylimport.minSet</td><td>Wh</td><td>-</td><td>EVMiniumEnergyRequest(ScheduleExchangeReq,AC/DC_ChargeLoopReq)</td></tr><tr><td>Energylimport.target</td><td>Wh</td><td>EVEnergyRequest (DC)EAmount (AC)</td><td>EVTTargetEnergyRequest(ScheduleExchangeReq,AC/DC_ChargeLoopReq)</td></tr><tr><td>BatteryCapacity</td><td>Wh</td><td>EVEnergyCapacity (DC)</td><td>BatteryCapacity(AC/DC_ChargeLoopReq.DisplayParameters)</td></tr><tr><td>DepartureTime</td><td>time</td><td>DepartureTimeProvided as seconds since message receipt.Converted to absolute time.</td><td>DepartureTime (ScheduleExchangeReq,AC/DC_ChargeLoopReq)Provided as seconds since message receipt.Converted to absolute time.</td></tr><tr><td>RemainingTimeBulk</td><td>s</td><td>RemainingTimeToBulkSoC(CurrentDemandReq)</td><td>-</td></tr><tr><td>RemainingTimeFull.maxSet</td><td>s</td><td>-</td><td>-</td></tr><tr><td>RemainingTimeFull.actual</td><td>s</td><td>RemainingTimeToFullSoc(CurrentDemandReq)</td><td>RemainingTimeToMaximumSOC(AC/DC_ChargeLoopReq.DisplayParameters)</td></tr><tr><td>StateOfChargeBulk</td><td>%</td><td>BulkSoC</td><td>-</td></tr><tr><td>StateOfCharge.maxSett</td><td>%</td><td>FullSoC</td><td>MaximumSOC(AC/DC_ChargeLoopReq.DisplayParameters)</td></tr><tr><td>StateOfChargeactual</td><td>%</td><td>DC_EVStatus.EVRESSSOC</td><td>PresentSOC(AC/DC_ChargeLoopReq.DisplayParameters)</td></tr><tr><td>ChargingCompleteBulk</td><td>boolean</td><td>BulkChargingComplete</td><td>-</td></tr><tr><td>ChargingCompleteFull</td><td>boolean</td><td>ChargingComplete</td><td>ChargingComplete(AC/DC_ChargeLoopReq.DisplayParameters)</td></tr><tr><td colspan="4">Error status values:</td></tr><tr><td colspan="4">ChargingStatewith a memberlist consisting of the following values:</td></tr><tr><td colspan="2">* BatteryOvervoltage</td><td>-</td><td><EVTerminationCode></td></tr><tr><td colspan="2">* BatteryUndervoltage</td><td>-</td><td>...</td></tr><tr><td colspan="2">* ChargingCurrentDeviation</td><td>FAILED_ChargingCurrentDifferential</td><td>...</td></tr><tr><td colspan="2">* BatteryTemperature</td><td>FAILED_RESSTemperatureInhibit</td><td>...</td></tr><tr><td colspan="2">* VoltageDeviation</td><td>FAILED_ChargingVoltageOutOfRange</td><td>...</td></tr><tr><td colspan="2">* ChargingSystemError</td><td>FAILED_EVRESSMalfunction</td><td>...</td></tr><tr><td colspan="2">* VehicleShiftPosition</td><td>FAILED EVShiftPosition</td><td>...</td></tr><tr><td colspan="2">* VehicleChargingEnabled</td><td>-</td><td>...</td></tr><tr><td colspan="2">* ChargingSystemIncompatibility</td><td>FAILED_ChargingSystemIncompatibility</td><td>...</td></tr><tr><td colspan="2">* ChargerConnectorLockFault</td><td>FAILED ChargerConnectorLockFault</td><td>...</td></tr><tr><td colspan="4">NOTE 1: ChargingState variable reports an error status and is not related to the chargingState in a TransactionEventRequest.
+NOTE 2: ISO 15118-20 uses the EVTerminationCode from the SessionStopReq message to signal what has caused the session to end.
+Future revisions of ISO 15118-20 will introduce concrete EVTerminationCode values (e.g. urn:iso:std:iso:15118:-20:EVTerminationCode:ChargerConnectorLockFault).</td></tr></table>
+
+# 2.17.2. ConnectedEV for CHAdeMO
+
+Required variables
+
+<table><tr><td>Variable</td><td>Unit</td><td>CHAdeMO value</td></tr><tr><td>Available</td><td>boolean</td><td>When true this means an EV is connected.
+When false, all other fields are meaningless and should be empty strings.</td></tr><tr><td colspan="3">Vehicle ID:</td></tr><tr><td>VehicleId</td><td>string</td><td>Vehicle ID (H'710 + H'711 + H'712)
+Three times 8 bytes, represented as hexbinary encoded string, e.g.
+"010203040A0B0C0D111213141A1B1C1D212223242A2B2C2D". A concatenation of H'710 + H'711 + H'712.</td></tr><tr><td>ProtocolAgreed</td><td>string</td><td>Lowest of Chademo protocol number from EV (H'102.0) and charger (H'109.0)
+Example for CHAdeMO 2.0.1: "CHAdeMO,3"
+(3 = version reported by CHAdeMO for v2.0.1)</td></tr></table>
+
+Optional variables
+
+<table><tr><td>Variable</td><td>Unit</td><td>CHAdeMO value</td></tr><tr><td>ProtocolSupportedByEV["1"] to ProtocolSupportedByEV["20"]</td><td>multi-instance string</td><td>Chademo protocol number (H'102.0) supported by EV.
+For Chademo only the first instance ProtocolSupportedByEV["1"] is used. The other instances have an empty string as value.
+Reported as a string with the following comma-separated items:
+"CHAdeMO,<version>";
+Example for CHAdeMO 2.0.1:
+- ConnectedEVprotocolsSupportedByEV["1"] = "CHAdeMO,3"</td></tr></table>
+
+<table><tr><td>Variable</td><td>Unit</td><td>CHAdeMO value</td></tr><tr><td colspan="3">Voltage and current values:</td></tr><tr><td>ACCurrent.minSet</td><td>A</td><td>-</td></tr><tr><td>ACCurrent.maxSet</td><td>A</td><td>-</td></tr><tr><td>ACVoltage.maxSet</td><td>V</td><td>-</td></tr><tr><td>DCCurrent.minSet</td><td>A</td><td>Minimum charge current (H'100.0)</td></tr><tr><td>DCCurrent.maxSet</td><td>A</td><td>-</td></tr><tr><td>DCCurrent.target</td><td>A</td><td>Charging current request (H'102.3)If HighCurrentControl is true, use the value from Charging currentrequest (extended) (H'110.1,2).</td></tr><tr><td>DCVoltage.minSet</td><td>V</td><td>Minimum battery voltage (H'100.2,3)</td></tr><tr><td>DCVoltage.maxSet</td><td>V</td><td>Maximum battery voltage (H'100.4,5)</td></tr><tr><td>DCVoltage.target</td><td>V</td><td>Target battery voltage (H'102.1,2)</td></tr><tr><td colspan="3">Power, energy and time values:</td></tr><tr><td>Power.maxSet</td><td>W</td><td>-</td></tr><tr><td>EnergyImport.maxSet</td><td>Wh</td><td>Total capacity of traction battery * 100 (H'101.5,6)</td></tr><tr><td>EnergyImport.target</td><td>Wh</td><td>-</td></tr><tr><td>DepartureTime</td><td>dateTime</td><td>-</td></tr><tr><td>RemainingTimeBulk</td><td>s</td><td>-</td></tr><tr><td>RemainingTimeFull.maxSet</td><td>s</td><td>Maximum charging time * 60 (H'101.2)</td></tr><tr><td>RemainingTimeFullactual</td><td>s</td><td>Estimated charging time * 60 (H'101.3)</td></tr><tr><td>StateOfChargeBulk</td><td>%</td><td>-</td></tr><tr><td>StateOfCharge.maxSet</td><td>%</td><td>Charged rate reference constant (H'100.6)</td></tr><tr><td>StateOfCharge的实际</td><td>%</td><td>State of charge (H'102.6)</td></tr><tr><td>ChargingCompleteBulk</td><td>boolean</td><td>-</td></tr><tr><td>ChargingCompleteFull</td><td>boolean</td><td>-</td></tr><tr><td colspan="3">Error status values:</td></tr><tr><td colspan="3">ChargingStatewith a memberlist consisting of the following values:</td></tr><tr><td colspan="2">* BatteryOvervoltage</td><td>Battery overvoltage (H'102.4.0)</td></tr><tr><td colspan="2">* BatteryUndervoltage</td><td>Battery undervoltage (H'102.4.1)</td></tr><tr><td colspan="2">* ChargingCurrentDeviation</td><td>Battery current deviation (H'102.4.2)</td></tr><tr><td colspan="2">* BatteryTemperature</td><td>High battery temperature (H'102.4.3)</td></tr><tr><td colspan="2">* VoltageDeviation</td><td>Battery voltage deviation (H'102.4.4)</td></tr><tr><td colspan="2">* ChargingSystemError</td><td>Charging system error (H'102.5.2)</td></tr><tr><td colspan="2">* VehicleShiftPosition</td><td>Vehicle shift position (H'102.5.1)</td></tr><tr><td colspan="2">* VehicleChargingEnabled</td><td>Vehicle charging enabled (H'102.5.0)</td></tr><tr><td colspan="2">* ChargingSystemIncompatibility</td><td>-</td></tr><tr><td colspan="2">* ChargerConnectorLockFault</td><td>-</td></tr><tr><td colspan="3">NOTE: ChargingState variable reports an error status and is not related to the chargingState in a TransactionEventRequest.</td></tr></table>
+
+# 2.17.3. ConnectedEV for WPT
+
+New in OCPP 2.1
+
+The following parameters coming from the WPT_ChargeLoopReq messages can be represented in the ConnectedEV component. This information might be useful for troubleshooting, but is not required for normal operation.
+
+Optional variables
+
+<table><tr><td>Variable</td><td>Unit</td><td>ISO 15118-20 value</td></tr><tr><td>WPT_EVPCPowerRequest</td><td>decimal</td><td>Power the EVPC would like to have as output in Watt.</td></tr><tr><td>WPT_EVPCPowerOutput</td><td>decimal</td><td>Power measured at the output of the EVPC electronics in Watt.</td></tr><tr><td>WPT_EVPCChargeDiagnostics</td><td>OptionList</td><td>Values are:"EVPCNoIssue","EVPCTempOverheatDetected","EVPCPowerTransferAnomalyDetected","EVPCAnomalyDetected"</td></tr><tr><td>WPT_EVPCOperatingFrequency</td><td>decimal</td><td>EVPC measured MF-WPT operating frequency.</td></tr><tr><td>WPT_EVPCCoilCurrentRequest</td><td>decimal</td><td>EVPC wants the primary device to set a specific (preferred) coil current value.</td></tr><tr><td>WPT_EVPCCoilCurrentInformation</td><td>decimal</td><td>Secondary device coil current (AC).</td></tr><tr><td>WPT_EVPCCurrentOutputInformation</td><td>decimal</td><td>DC current supplied to the EV.</td></tr><tr><td>WPT_EVPCVoltageOutputInformation</td><td>decimal</td><td>DC bus or battery voltage.</td></tr></table>
+
+# 2.17.4. ConnectedEV for ACDP
+
+New in OCPP 2.1
+
+The following parameters from ACDP_VehiclePositioningReq, ACPD_ConnectReq, ACDP_DisconnectReq and ACDP_SystemStatusReq can be represented in the ConnectedEV component. This information might be useful for troubleshooting, but is not required for normal operation.
+
+Optional variables
+
+<table><tr><td>Variable</td><td>Unit</td><td>ISO 15118-20 value</td></tr><tr><td>ACDP_EVMobilityStatus</td><td>boolean</td><td>Is true when an EV is immobilized</td></tr><tr><td>ACDP_EVPositioningSupport</td><td>boolean</td><td>Is true when EV has positioning support</td></tr><tr><td>ACDP_EVElectricalChargingDevice Status</td><td>OptionList</td><td>Values are:
+"State_A" (disconnected),
+"State_B", "State_C", "State_D" (connected)</td></tr><tr><td>ACDP_EVReadyToCharge</td><td>boolean</td><td>Element signalizes if the EV is READY or NOT READY to charge.</td></tr><tr><td>ACDP_EVIImmobilizationRequest</td><td>boolean</td><td>Represents the request of immobilization of the EV. This may be related to the hand brake status.</td></tr><tr><td>ACDP_EVIImmobilized</td><td>boolean</td><td>The immobilization of the EV is a mandatory precondition to activate the pantograph.</td></tr><tr><td>ACDP_WLANStrength</td><td>decimal</td><td>Element signalizes EV WiFi reception signal strength (-dBm)</td></tr><tr><td>ACDP_EVCPStatus</td><td>OptionList</td><td>Values are:
+"State_A", "State_B", "State_C", "State_D", "State_E". Refer to IEC 61851-23-1.</td></tr><tr><td>ACDP_EVSOC</td><td>decimal</td><td>For operation usable SOC status in %. This value may differ from physical SOC of the battery.
+This parameter can be same as PresentSOC in DisplayParameter.</td></tr><tr><td>ACDP_EVEErrorCode</td><td>OptionList</td><td>One of: "OK_NoEVError", "FAILED", "FAILED_EmergencyEvent", "FAILED_Breaker", "FAILED_RESSTemperatureInhibit", "FAILED_RESS", "FAILED_ChargingCurrentDifferential", "FAILED_ChargingVoltageOutOfRange", "FAILED_Reserved1", "FAILED_Reserved2"</td></tr><tr><td>ACDP_EVTtimeout</td><td>boolean</td><td>Indicates the occurrence of a timeout in the EVCC.</td></tr></table>
+
+# 2.18. Bidirectional Charging related
+
+# 2.18.1. v2XEEnabled
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, when supporting V2X</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">V2XChargingCtrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">Way for the CSMS to either activate or deactivate V2X functionality on a Charging Station.</td></tr></table>
+
+# 2.18.2. v2xSupportedEnergyTransferMode
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, when supporting V2X</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">V2XChargingCtrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">SupportedEnergyTransferModes</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>dataType</td><td>Memberlist</td></tr><tr><td>valuesList</td><td>values from EnergyTransferModeEnumType</td></tr><tr><td>maxLimit</td><td>The maximum length of the values list, to be defined by the implementer.</td></tr><tr><td>Description</td><td colspan="3">Lists the energy transfer services that are supported by the Charging Station.</td></tr></table>
+
+# 2.18.3. v2xSupportedOperationModes
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="2">yes, when supporting V2X</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td>V2XChargingCtrlr</td></tr><tr><td>evse</td><td>*</td></tr></table>
+
+<table><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">SupportedOperationModes</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="3">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from OperationModeEnumType</td></tr><tr><td>maxLimit</td><td>The maximum length of the values list, to be defined by the implementer.</td></tr><tr><td>Description</td><td colspan="3">Lists the operation modes that are supported by the Charging Station.</td></tr></table>
+
+# 2.18.4. v2xLocalFrequencyUpdateThreshold
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, when supporting V2X operationMode LocalFrequency</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">V2XChargingCtrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">LocalFrequencyUpdateThreshold</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">The amount of change in net frequency in mHz is needed to trigger a recalculation of the setpoint. Typical values range from 1 to 100.</td></tr></table>
+
+# 2.18.5. V2X Additional Sampled Data Measurands
+
+The following configuration variables define parameters that the Charging Station shall report via TransactionEventRequest messages in addition to those measurands that have been defined in the standard SampledDataCtrlr. The sampling interval for these additional measurands is configured in V2XChargingCtrlr.TxUpdatedInterval. When absent, the interval value from SampledDataCtrlr.TxUpdatedInterval is used.
+
+# 2.18.5.1. V2XSampledDataTxStartedMeasurands[OperationMode]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">V2XChargingCtrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">TxStartedMeasurands</td></tr><tr><td>variableInstance</td><td colspan="2"><OperationMode></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from MeasurandEnumType</td></tr><tr><td>Description</td><td colspan="3">List of sampled measurands to send in addition to those configured in SampledDataCtrlr.TxStartedMeasurands, when the Charging Station is in V2X operation mode <OperationMode>. Measurands that occur in TxStartedMeasurands of both SampledDataCtrlr and in V2XChargingCtrlr are reported as one measurand.</td></tr></table>
+
+# 2.18.5.2. v2xSampledDataTxEndedMeasurands[OperationMode]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">V2XChargingCtrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">TxEndedMeasurands</td></tr><tr><td>variableInstance</td><td colspan="2"><OperationMode></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from MeasurandEnumType</td></tr><tr><td>Description</td><td colspan="3">List of sampled measurands to send in addition to SampledDataCtrlr.TxEndedMeasurands, when the Charging Station is in V2X operation mode <OperationMode>. Measurands that occur in TxEndedMeasurands of both SampledDataCtrlr and in V2XChargingCtrlr are reported as one measurand.</td></tr></table>
+
+# 2.18.5.3. V2XSampledDataTxEndedInterval[OperationMode]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">V2XChargingCtrl</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">TxEndInterval</td></tr><tr><td>variableInstance</td><td colspan="2"><OperationMode></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">The interval used to sample the list of measurands in V2XChargingCtrl.TxEndedMeasurands, while the Charging Station is in V2X operation mode <OperationMode>. When absent the interval defaults to that in SampleDataCtrl.TxEndInterval. Measurands that occur in TxEndedMeasurands of both SampleDataCtrl and in V2XChargingCtrl are reported as with the sampling interval of V2XChargingCtrl.TxEndInterval.</td></tr></table>
+
+# 2.18.5.4. V2XSampledDataTxUpdatedMeasurands[OperationMode]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td>V2XChargingCtrlr</td></tr><tr><td>evse</td><td>*</td></tr></table>
+
+<table><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">TxUpdatedMeasurands</td></tr><tr><td>variableInstance</td><td colspan="2"><OperationMode></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from MeasurandEnumType</td></tr><tr><td>Description</td><td colspan="3">List of sampled measurands to send in addition to SampledDataCtrl.TxUpdatedMeasurands, when the Charging Station is in V2X operation mode <OperationMode>. Measurands that occur in TxUpdatedMeasurands of both SampledDataCtrl and in V2XChargingCtrl are reported as one measurand.</td></tr></table>
+
+# 2.18.5.5. v2xSampledDataTxUpdatedInterval[OperationMode]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">V2XChargingCtrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="5">Variable</td><td>variableName</td><td colspan="2">TxUpdatedInterval</td></tr><tr><td>variableInstance</td><td colspan="2"><OperationMode></td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">The interval used to sample the list of measurands in V2XChargingCtrlr.TxUpdatedMeasurands, while the Charging Station is in V2X operation mode <OperationMode>. When absent the interval defaults to that in SampleDataCtrlr.TxUpdatedInterval. Measurands that occur in TxUpdatedMeasurands of both SampleDataCtrlr and in V2XChargingCtrlr are reported as with the sampling interval of V2XChargingCtrlr.TxUpdatedInterval.</td></tr></table>
+
+# 2.18.6. V2X Local Load Balancing
+
+The following variables control upper and lower threshold and offsets for local load balancing.
+
+# 2.18.6.1. v2xLocalLoadBalancing[UpperThreshold]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, when supporting V2X operationMode LocalLoadBalancing</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">V2XChargingCtrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">LocalLoadBalancing</td></tr><tr><td>variableInstance</td><td colspan="2">UpperThreshold</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>decimal</td></tr><tr><td>Description</td><td colspan="3">When power (in Watts) exceeds this limit, the local load balancing mechanism will try limit the power to a maximum of UpperThreshold + UpperOffset.</td></tr></table>
+
+# 2.18.6.2. V2XLocalLoadBalancing[LowerThreshold]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, when supporting V2X operationMode LocalLoadBalancing</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">V2XChargingCtrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">LocalLoadBalancing</td></tr><tr><td>variableInstance</td><td colspan="2">LowerThreshold</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>decimal</td></tr><tr><td>Description</td><td colspan="3">When power (in Watts) drops below this limit, the local load balancing mechanism will try to keep the power to a minimum of LowerThreshold + LowerOffset.</td></tr></table>
+
+# 2.18.6.3. V2XLocalLoadBalancing[UpperOffset]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, when supporting V2X operationMode LocalLoadBalancing</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">V2XChargingCtrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">LocalLoadBalancing</td></tr><tr><td>variableInstance</td><td colspan="2">UpperOffset</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>decimal</td></tr><tr><td>Description</td><td colspan="3">An offset value (in Watts) to add to the UpperThreshold. This allows for some tuning of the upper limit without changing the threshold value.</td></tr></table>
+
+# 2.18.6.4. V2XLocalLoadBalancing[LowerOffset]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">yes, when supporting V2X operationMode LocalLoadBalancing</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">V2XChargingCtrlr</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">LocalLoadBalancing</td></tr><tr><td>variableInstance</td><td colspan="2">LowerOffset</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>decimal</td></tr><tr><td>Description</td><td colspan="3">An offset value (in Watts) to add to the LowerThreshold. This allows for some tuning of the lower limit without changing the threshold value.</td></tr></table>
+
+# 2.18.7. FrequencySimulator Component
+
+The FrequencySimulator is an optional component that can simulate net frequencies during a certification process. It is a component that is reported as part of an EVSE and when enabled it only applies to that EVSE.
+
+# 2.18.7.1. FrequencySimulatorEnabled
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">FrequencySimulator</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">This variable must be set to true in order to activate the FrequencySimulator and gather data with the DataCollector. Sampling of data will occur between DateTime["Start"] and DateTime["End"].</td></tr></table>
+
+# 2.18.7.2. FrequencySimulatorDateTime[Start]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">FrequencySimulator</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">DateTime</td></tr><tr><td>variableInstance</td><td colspan="2">Start</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>dateTime</td></tr><tr><td>Description</td><td colspan="3">If Enabled the FrequencySimulator will simulate a net frequency as long as time >= DateTime["Start"] and time < DateTime["End"].</td></tr></table>
+
+# 2.18.7.3. FrequencySimulatorDateTime[End]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">FrequencySimulator</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">DateTime</td></tr><tr><td>variableInstance</td><td colspan="2">End</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>dateTime</td></tr><tr><td>Description</td><td colspan="3">If Enabled the FrequencySimulator will simulate a net frequency as long as time >= DateTime["Start"] and time < DateTime["End"].</td></tr></table>
+
+# 2.18.7.4. FrequencySimulatorSchedule
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">FrequencySimulator</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">FrequencySchedule</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">A JSON-formatted string with an array of { time, freq} pairs, in which time is time in seconds (as integer) relative to the beginning of the schedule at DateTime("Start") and freq is the frequency to be simulated during that period in Hz (as decimal). Behaviour is similar to that of a ChargingSchedulePeriodType, i.e. the start of a new period marks the end of the previous period and the final period lasts until DateTime["End"].Example: ["time": 0, "freq": 50.0], {"time": 60, "freq": 49.2}, {"time": 300, "freq": 47.8}]".</td></tr></table>
+
+# 2.18.8. DataCollector Component
+
+The DataCollector is an optional component that collects samples of measurands at a high frequency, typically with subsecond intervals. It is a component that is reported as part of an EVSE and when enabled it only applies to that EVSE. The samples are logged internally in the Charging Station and can be retrieved in bulk with the GetLogRequest by specifying LogEnumType DataCollectorLog. For small intervals and lots of data it is much more efficient to use the DataCollector than installing a sampling monitor.
+
+Its purpose is to collect high frequency samples (less than 100 ms intervals) that are needed during the certification process of a Charging Station that is doing local frequency control. The DataCollector component is, however, not specific to V2X operations and can be used for any sampling.
+
+# 2.18.8.1.DataCollectorEnabled
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">DataCollector</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">Enabled</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>boolean</td></tr><tr><td>Description</td><td colspan="3">This variable must be set to True in order to activate the DataCollector. Sampling of data will occur between DateTime["Start"] and DateTime["End"].</td></tr></table>
+
+# 2.18.8.2.DataCollectorDateTime[Start]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td>DataCollector</td></tr><tr><td>evse</td><td>*</td></tr></table>
+
+<table><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">DateTime</td></tr><tr><td>variableInstance</td><td colspan="2">Start</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>dateTime</td></tr><tr><td>Description</td><td colspan="3">If Enabled the DataCollector will start sampling measurands from SampledMeasurands as long as time >= DateTime["Start"] and time < DateTime["End"].</td></tr></table>
+
+# 2.18.8.3.DataCollectorDateTime[End]
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">DataCollector</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">DateTime</td></tr><tr><td>variableInstance</td><td colspan="2">End</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>dateTime</td></tr><tr><td>Description</td><td colspan="3">If Enabled the DataCollector will start sampling measurands from SampledMeasurands as long as time >= DateTime["Start"] and time < DateTime["End"].</td></tr></table>
+
+# 2.18.8.4.DataCollectorSampledMeasurands
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">DataCollector</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="5">Variable</td><td>ijklname</td><td colspan="2">SampledMeasurands</td></tr><tr><td>ijklattributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="3">ijklcharacteristics</td><td>dataType</td><td>MemberList</td></tr><tr><td>valuesList</td><td>values from MeasurandEnumType</td></tr><tr><td>maxLimit</td><td>Maximum length of the memberlist as a CSV formatted string.</td></tr><tr><td>Description</td><td colspan="3">The set of measurands to be sampled by the DataCollector. Samples are always appended to the DataCollectorLog until it is retrieved by a GetLogRequest(DataCollectorLog), after which it is cleared.</td></tr></table>
+
+# 2.18.8.5. DataCollectorSamplingInterval
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td>no</td></tr></table>
+
+<table><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">DataCollector</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SamplingInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>decimal</td></tr><tr><td>Description</td><td colspan="3">The sampling interval in seconds.</td></tr></table>
+
+# 2.19. DER Control related
+
+# 2.19.1. DCDERCtrl
+
+New in OCPP 2.1
+
+The DCDERCtrl component holds DER capabilities of the DC inverter of the EVSE in the Charging Station. The component is located at the EVSE level, since it represents the DER capabilities, also referred to as nameplate information, of the EVSE.
+
+<table><tr><td>Variable</td><td>Data Type</td><td>M/O</td><td>Description</td></tr><tr><td>MaxW</td><td>decimal</td><td>M</td><td>Active power rating in watts at unity power factor</td></tr><tr><td>OverExcitedW</td><td>decimal</td><td>M</td><td>Active power rating in watts at specified over-excited power factor</td></tr><tr><td>OverExcitedPF</td><td>decimal</td><td>M</td><td>Over-excited power factor</td></tr><tr><td>UnderExcitedW</td><td>decimal</td><td>M</td><td>Active power rating in watts at specified under-excited power factor</td></tr><tr><td>UnderExcitedPF</td><td>decimal</td><td>M</td><td>Under-excited power factor</td></tr><tr><td>MaxVA</td><td>decimal</td><td>M</td><td>Maximum apparent power rating in voltamperes</td></tr><tr><td>MaxVar</td><td>decimal</td><td>M</td><td>Maximum injected reactive power rating in vars</td></tr><tr><td>MaxVarNeg</td><td>decimal</td><td>M</td><td>Maximum absorbed reactive power rating in vars</td></tr><tr><td>MaxChargeRateW</td><td>decimal</td><td>M</td><td>Maximum active power charge rating in watts</td></tr><tr><td>MaxChargeRateVA</td><td>decimal</td><td>M</td><td>Maximum apparent power charge rating in voltamperes; may differ from the apparent power maximum rating</td></tr><tr><td>VNom</td><td>decimal</td><td>O</td><td>Nominal ac voltage rating in rms volts</td></tr><tr><td>MaxV</td><td>decimal</td><td>O</td><td>Maximum ac voltage rating in rms volts</td></tr><tr><td>MinV</td><td>decimal</td><td>O</td><td>Minimum ac voltage rating in rms volts</td></tr><tr><td>ModesSupported</td><td>MemberList of DERControlEnumType</td><td>M</td><td>Indication of support for each control mode function</td></tr><tr><td>InverterManufacturer</td><td>string</td><td>M</td><td>Manufacturer of inverter</td></tr><tr><td>InverterModel</td><td>string</td><td>M</td><td>Model of inverter</td></tr><tr><td>InverterSerialNumber</td><td>string</td><td>O</td><td>Serial number of inverter</td></tr><tr><td>InverterSwVersion</td><td>string</td><td>M</td><td>Software version of inverter</td></tr><tr><td>InverterHwVersion</td><td>string</td><td>M</td><td>Hardware version of inverter</td></tr><tr><td>IslandingDetectionMethod</td><td>OptionList of IslandingDete cctionEnumTyp e</td><td>O</td><td>Type of islanding detection method</td></tr><tr><td>IslandingDetectionTripTime</td><td>decimal</td><td>O</td><td>Time until tripping after island detection</td></tr><tr><td>ReactiveSusceptance</td><td>decimal</td><td>M</td><td>Reactive susceptance that remains connected to the electrical power system in the cease to energize and trip state</td></tr></table>
+
+$M / O =$ "mandatory when DER control supported" or "optional"
+
+# 2.19.2. ACDERCtrl
+
+New in OCPP 2.1
+
+The ACDERCtrlrc component holds DER capabilities that the EVSE of the Charging Station can emulate by using ISO 15118-20 ChargeLoop messages to control the inverter in the EV. The component is located at the EVSE level, since it represents the DER capabilities of the EVSE.
+
+If the modesSupported variable is an empty list, then all DER capabilities must be provided by the EV.
+
+<table><tr><td>Variable</td><td>Data Type</td><td>M/O</td><td>Description</td></tr><tr><td>ModesSupported</td><td>MemberList of DERControlEnumType</td><td>M</td><td>Indication of support for each control mode function</td></tr></table>
+
+$M / O =$ "mandatory when DER control supported" or "optional"
+
+# 2.20. Battery Swapping related
+
+# 2.20.1. BatterySwapTargetSoc
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">BatterySwapCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">TargetSoc</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">The state of charge that a battery must have in order to be eligible for swapping. Batteries below TargetSoc are reported as "Occupied", at or above TargetSoc they are reported as "Available". TargetSoc must be smaller or equal to MaxSoc. A battery will continue to be charged until MaxSoc.</td></tr></table>
+
+# 2.20.2. BatterySwapMaxSoc
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">BatterySwapCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">MaxSoc</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">The maximum state of charge that a battery will be charged to.</td></tr></table>
+
+# 2.20.3. BatterySwapIdtoken
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td>BatterySwapCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">IdToken</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">The idToken that is used for charging transactions of swap batteries. If absent or empty string, then tokenType = "NoAuthorization" is used, else the given value is used as idToken with tokenType = Central.</td></tr></table>
+
+# 2.20.4. BatterySwapInTimeout
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">BatterySwapCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Timeout</td></tr><tr><td>variableInstance</td><td colspan="2">In</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Timeout in seconds in which a set of batteries must be inserted after successful authorization.</td></tr></table>
+
+# 2.20.5. BatterySwapOutTimeout
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">BatterySwapCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Timeout</td></tr><tr><td>variableInstance</td><td colspan="2">Out</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">Timeout in seconds in which the set of batteries that is offered by Charging Station to take out in exchange for the inserted set of batteries must be removed.</td></tr></table>
+
+# 2.20.6. BatteryCartridgeSoC
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">BatteryCartridge</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>名字</td><td colspan="2">SoC</td></tr><tr><td>variables</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variables</td><td>dataType</td><td>integer</td></tr></table>
+
+<table><tr><td>Description</td><td>The component BatteryCartridge refers to the battery that is inserted at the EVSE. The variable SoC represents current state of charge as a percentage from 0..100.</td></tr></table>
+
+# 2.20.7. BatteryCartridgeSoH
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">BatteryCartridge</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="3">Variable</td><td>名字</td><td colspan="2">SoH</td></tr><tr><td>variables</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variablesCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">The component BatteryCartridge refers to the battery that is inserted at the EVSE. The variable SoH represents current state of health as a value from 0..100.</td></tr></table>
+
+# 2.20.8. BatteryCartridgeWorkingMode
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">BatteryCartridge</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">WorkingMode</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>valuesList</td><td>"CC, CV, Full, Ready, Standby"</td></tr><tr><td>Description</td><td colspan="3">This variable represents the current working mode of the battery.CC: Continuous Current,CV: Continuous Voltage,Full: Fully Charged,Ready: Ready to be charged,Standby: Battery slot is emptyThis optional variable can be sent to or monitored by CSMS for information.</td></tr></table>
+
+# 2.20.9. BatterySlotStatus
+
+New in OCPP 2.1
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td colspan="2">Connector</td></tr><tr><td>evse</td><td colspan="2">*</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">SlotStatus</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>dataType</td><td>OptionList</td></tr><tr><td>valuesList</td><td>"Open, Locked, Faulted"</td></tr><tr><td rowspan="2">Description</td><td>This variable represents the status of the door of the battery slot.</td></tr><tr><td>This optional variable can be sent to or monitored by CSMS for information.</td></tr></table>
+
+# 2.20.9.1. Example representation of a battery swap station in device model
+
+A battery swap station can be mapped onto the standard 3-tier model of a charging station. A battery slot is mapped onto an EVSE. The battery slot type is represented by the connector type. Variables associated with the inserted battery cartridge are represented by a BatteryCartridge component, which is only Available when a cartridge is inserted. The table below represents a battery swap station with two battery slots in which only slot #2 contains a battery cartridge.
+
+<table><tr><td colspan="4">Component</td><td colspan="2">Variable</td><td colspan="2">VariableAttribute</td><td colspan="3">VariableCharacteristics</td></tr><tr><td>name</td><td>evse id</td><td>evse conne-ctorld</td><td>instance</td><td>name</td><td>instance</td><td>type</td><td>value</td><td>dataType</td><td>maxLimit</td><td>supports Monitorin g</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>ChargingStation</td><td></td><td></td><td></td><td>AvailabilityState</td><td></td><td>Actual</td><td>Available</td><td>boolean</td><td></td><td>true</td></tr><tr><td>BatterySwapCtrlr</td><td></td><td></td><td></td><td>TargetSoC</td><td></td><td>Actual</td><td>70</td><td>integer</td><td>100</td><td>false</td></tr><tr><td>BatterySwapCtrlr</td><td></td><td></td><td></td><td>MaxSoC</td><td></td><td>Actual</td><td>80</td><td>integer</td><td>100</td><td>false</td></tr><tr><td>BatterySwapCtrlr</td><td></td><td></td><td></td><td>IdToken</td><td></td><td>Actual</td><td>BSS-001</td><td>string</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>1</td><td></td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>1</td><td></td><td></td><td>AvailabilityState</td><td></td><td>Actual</td><td>Available</td><td>OptionList</td><td></td><td>true</td></tr><tr><td>EVSE</td><td>1</td><td></td><td></td><td>Power</td><td></td><td>Actual</td><td>0.0</td><td>decimal</td><td>22000.0</td><td>true</td></tr><tr><td>Connector</td><td>1</td><td>1</td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>Connector</td><td>1</td><td>1</td><td></td><td>ConnectorType</td><td></td><td>Actual</td><td>BatterySlot</td><td>string</td><td></td><td>false</td></tr><tr><td>Connector</td><td>1</td><td>1</td><td></td><td>SlotStatus</td><td></td><td>Actual</td><td>Open</td><td>OptionList</td><td></td><td>true</td></tr><tr><td>BatteryCartridge</td><td>1</td><td>1</td><td></td><td>Available</td><td></td><td>Actual</td><td>false</td><td>boolean</td><td></td><td>true</td></tr><tr><td>BatteryCartridge</td><td>1</td><td>1</td><td></td><td>Temperature</td><td></td><td>Actual</td><td>0</td><td>decimal</td><td></td><td>true</td></tr><tr><td>BatteryCartridge</td><td>1</td><td>1</td><td></td><td>SoC</td><td></td><td>Actual</td><td>0</td><td>integer</td><td></td><td>true</td></tr><tr><td>BatteryCartridge</td><td>1</td><td>1</td><td></td><td>WorkingMode</td><td></td><td>Actual</td><td>CC</td><td>OptionList</td><td></td><td>true</td></tr><tr><td>BatteryCartridge</td><td>1</td><td>1</td><td></td><td>SlotStatus</td><td></td><td>Actual</td><td>Locked</td><td>OptionList</td><td></td><td>true</td></tr><tr><td>EVSE</td><td>2</td><td></td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>EVSE</td><td>2</td><td></td><td></td><td>AvailabilityState</td><td></td><td>Actual</td><td>Occupied</td><td>optionList</td><td></td><td>true</td></tr><tr><td>EVSE</td><td>2</td><td></td><td></td><td>Power</td><td></td><td>Actual</td><td>4100.0</td><td>decimal</td><td>5000.0</td><td>true</td></tr><tr><td>Connector</td><td>2</td><td>1</td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>false</td></tr><tr><td>Connector</td><td>2</td><td>1</td><td></td><td>AvailabilityState</td><td></td><td>Actual</td><td>Occupied</td><td>optionList</td><td></td><td>true</td></tr><tr><td>Connector</td><td>2</td><td>1</td><td></td><td>ConnectorType</td><td></td><td>Actual</td><td>BatterySlot</td><td>string</td><td></td><td>false</td></tr><tr><td>Connector</td><td>1</td><td>1</td><td></td><td>SlotStatus</td><td></td><td>Actual</td><td>Locked</td><td>OptionList</td><td></td><td>true</td></tr><tr><td>BatteryCartridge</td><td>2</td><td>1</td><td></td><td>Available</td><td></td><td>Actual</td><td>true</td><td>boolean</td><td></td><td>true</td></tr><tr><td>BatteryCartridge</td><td>2</td><td>1</td><td></td><td>Temperature</td><td></td><td>Actual</td><td>35</td><td>decimal</td><td></td><td>true</td></tr><tr><td>BatteryCartridge</td><td>2</td><td>1</td><td></td><td>SoC</td><td></td><td>Actual</td><td>51</td><td>integer</td><td></td><td>true</td></tr><tr><td>BatteryCartridge</td><td>2</td><td>1</td><td></td><td>WorkingMode</td><td></td><td>Actual</td><td>CC</td><td>OptionList</td><td></td><td>true</td></tr><tr><td>BatteryCartridge</td><td>2</td><td>1</td><td></td><td>SlotStatus</td><td></td><td>Actual</td><td>Locked</td><td>OptionList</td><td></td><td>true</td></tr></table>
+
+# NOTE
+
+The BatteryCartridge component a EVSE #1 is absent. As a result the Available variable is false. The other variables (like Temperature, SoC) still exist in the device model, but have no meaning when the battery cartridge is not present.
+
+# 2.21. Device Model hierarchy variables
+
+New in OCPP 2.1
+
+See Part 1 "Device Model Hierarchy" for the purpose of these variables.
+
+The value of a XxxParent variable (Communication/Electrical/Logical/PhysicalParent) is a shorthand notation that points to the parent component, as follows:
+
+"[EvseId[#ConnectorId]//Component[#Instance]".
+
+in which parts between square brackets "[]" are optional.
+
+For example:
+
+To reference the Charging Station tier component "PowerBank" with instance "1", the variable value is "PowerBank#1"
+To reference the EVSE tier component on evseld #2 named "Meter" with instance "1" the variable value is "2/Meter#1"
+
+- To reference the Connector tier component on evseld #2 and connectorld #1 named "Shutter" with no instance, the variable value is "2#1/Shutter"
+
+# 2.21.1. CommunicationParent
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2"><any></td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">CommunicationParent</td></tr><tr><td>variableInstance</td><td colspan="2"><any> or none</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">Points to a communication parent component (data flow source), to allow rendering the communication hierarchy in a UI.
+Value format: [Evseld[#ConnectorId]/]Component[#Instance]</td></tr></table>
+
+# 2.21.2. ElectricalParent
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2"><any>></td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">ElectricalParent</td></tr><tr><td>variableInstance</td><td colspan="2"><any> or none</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">Points to a electrical parent component (energy flow source), to allow rendering the electrical hierarchy in a UI. Value format: [Evseld[#ConnectorId]/]Component[#Instance]</td></tr></table>
+
+# 2.21.3. LogicalParent
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td>Component</td><td>componentName</td><td><any=""></td></tr></table>
+
+2.21.4. PhysicalParent
+
+<table><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">LogicalParent</td></tr><tr><td>variableInstancee</td><td colspan="2"><any> or none</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">Points to a logical parent component, to allow rendering a comprehensive overview of the Charging Station components in a UI. Value format: [Evseld[#ConnectorId]/]Component[#Instance]</td></tr></table>
+
+2.21.5.Label
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2"><any>></td></tr><tr><td rowspan="4">Variable</td><td>ijklname</td><td colspan="2">PhysicalParent</td></tr><tr><td>ijklparent</td><td colspan="2"><any> or none</td></tr><tr><td>ijklparenttype</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>ijklparentcolor</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">Points to a physical parent component (container), to allow rendering an overview of the Charging Station component locations in a UI. Value format: [Evseld[#Connectorld]/]Component[#Instance]</td></tr></table>
+
+<table><tr><td>Required</td><td colspan="3">no</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2"><any>></td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">Label</td></tr><tr><td>variableInstance</td><td colspan="2"><any> or none</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadOnly</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>string</td></tr><tr><td>Description</td><td colspan="3">Specifies a non-unique label to be used in a hierarchy UI rendering, in place of the unique component name and instance, in case a duplicate label is needed (e.g. when a component physically contained in a parent component has the same label as a component contained in another parent component).</td></tr></table>
--- /dev/null
+# OCPP
+
+# Table of Contents
+
+Disclaimer 1
+
+Version History 2
+
+1. Introduction. 3
+
+1.1. Purpose of this document 3
+1.2. Intended audience 3
+1.3. OCPP-S and OCPP-J. 3
+1.4. Conventions 3
+1.5. Definitions & Abbreviations 3
+1.6. References 4
+
+2. Benefits & Issues 5
+
+3. WebSockets 6
+
+3.1. Client request 6
+3.2. Maintaining support for OCPP 2.0.1. 7
+3.3. Server response 7
+3.4. WebSocket Compression 8
+
+4. RPC framework. 9
+
+4.1. Introduction 9
+4.2. Message structures for different message types 11
+4.3. RPC Framework Error Codes 16
+4.4. Extension fallback mechanism 16
+
+5. Connection 17
+
+5.1. Data integrity. 17
+5.2. TLS fragment length 17
+5.3. WebSocket Ping in relation to OCPP Heartbeat 17
+5.4. Reconnecting 19
+5.5. Network node hierarchy 19
+
+6. OCPP Routing 20
+
+6.1. Local Controller 20
+6.2. Connections 20
+6.3. Connection loss 21
+6.4. Local Controller initiated messages 21
+6.5. Local Controller Security 21
+
+7. Signed Messages 23
+
+7.1. Signed Message Format 23
+7.2. Handling Signed Messages 23
+7.3. Allowed Algorithms 23
+7.4. Key Management 24
+
+8. Configuration 25
+
+8.1. RetryBackOffRepeatTimes 25
+8.2. RetryBackOffRandomRange 25
+8.3. RetryBackOffWaitMinimum 25
+8.4. WebSocketPingInterval 25
+
+9. CustomData Extension 27
+
+# Disclaimer
+
+Copyright © 2010 - 2025 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
+
+<table><tr><td>Version</td><td>Date</td><td>Description</td></tr><tr><td>2.1 Edition 1</td><td>2025-01-23</td><td>OCPP 2.1 Edition 1</td></tr></table>
+
+# Chapter 1. Introduction
+
+# 1.1. Purpose of this document
+
+The purpose of this document is to give the reader the information required to create a correct interoperable OCPP JSON implementation (OCPP-J). We will try to explain what is mandatory, what is considered good practice and what one should not do, based on our own experience. Undoubtedly misunderstandings or ambiguities will remain but by means of this document we aim to prevent them as much as possible.
+
+# 1.2. Intended audience
+
+This document is intended for developers looking to understand and/or implement OCPP JSON in a correct and interoperable way. Rudimentary knowledge of implementing web services on a server or embedded device is assumed.
+
+# 1.3. OCPP-S and OCPP-J
+
+With the introduction of OCPP 1.6, there were two different flavors of OCPP; SOAP and JSON. To avoid confusion in communication on the type of implementation we recommend using the distinct suffixes -J and -S to indicate JSON or SOAP. In generic terms this would be OCPP-J for JSON and OCPP-S for SOAP. Version specific terminology would be OCPP1.6J or OCPP1.2S. If no suffix is specified for
+
+OCPP 1.2 or 1.5 then a SOAP implementation must be assumed. For release 1.6 this is no longer implicit and should always be made clear. If a system supports both the JSON and SOAP variant it is considered good practice to label this OCPP1.6JS instead of just OCPP1.6.
+
+As of OCPP 2.0.1 the SOAP transport is no longer supported.
+
+# 1.4. Conventions
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
+
+# 1.5. Definitions & Abbreviations
+
+<table><tr><td>Abbreviation</td><td>Description</td></tr><tr><td>IANA</td><td>Internet Assigned Numbers Authority (www.iana.org).</td></tr><tr><td>OCPP-J</td><td>OCPP communication over WebSocket using JSON. Specific OCPP versions should be indicated with the J extension. OCPP1.6J means we are talking about a JSON/WebSocket implementation of 1.6.</td></tr><tr><td>OCPP-S</td><td>OCPP communication over SOAP and HTTP(S). As of version 1.6 this should explicitly mentioned. Older versions are assumed to be S unless clearly specified otherwise, e.g. OCPP1.5 is the same as OCPP1.5S</td></tr><tr><td>RPC</td><td>Remote procedure call</td></tr><tr><td>WAMP</td><td>WAMP is an open WebSocket subprotocol that provides messaging patterns to handle asynchronous data.</td></tr></table>
+
+# 1.6. References
+
+<table><tr><td>Reference</td><td>Description</td></tr><tr><td>[ISO15118-2]</td><td>Road vehicles - Vehicle to grid communication interface - Part 2: Technical protocol description and Open Systems Interconnection (OSI) layer requirements, Document Identifier: 69/216/CDV. https://webstore.iec.ch/publication/9273</td></tr><tr><td>[OCPP2.0-PART2]</td><td>"OCPP 2.0.1: Part 2 - Specification". http://www.openchargealliance.org/downloads/</td></tr><tr><td>[OCPP2.1-PART2]</td><td>"OCPP 2.1: Part 2 - Specification". http://www.openchargealliance.org/downloads/</td></tr><tr><td>[RFC1951]</td><td>"DEFLATE Compressed Data Format Specification version 1.3". https://www.ietf.org/rfc/rfc1951</td></tr><tr><td>[RFC2119]</td><td>"Key words for use in RFCs to Indicate Requirement Levels". S. Bradner. March 1997. http://www.ietf.org/rfc/rfc2119.txt</td></tr><tr><td>[RFC2616]</td><td>"Hypertext Transfer Protocol - HTTP/1.1". http://tools.ietf.org/html/rfc2616</td></tr><tr><td>[RFC2617]</td><td>"HTTP Authentication: Basic and Digest Access Authentication". http://tools.ietf.org/html/rfc2617</td></tr><tr><td>[RFC3629]</td><td>"UTF-8, a transformation format of ISO 10646". http://tools.ietf.org/html/rfc3629</td></tr><tr><td>[RFC3986]</td><td>"Uniform Resource Identifier (URI): Generic Syntax". http://tools.ietf.org/html/rfc3986</td></tr><tr><td>[RFC5246]</td><td>"The Transport Layer Security (TLS) Protocol; Version 1.2". http://tools.ietf.org/html/rfc5246</td></tr><tr><td>[RFC6455]</td><td>"The WebSocket Protocol". http://tools.ietf.org/html/rfc6455</td></tr><tr><td>[RFC7515]</td><td>"JSON Web Signatures (JWS)". https://tools.ietf.org/html/rfc7515</td></tr><tr><td>[RFC7518]</td><td>"JSON Web Algorithms (JWA)". https://tools.ietf.org/html/rfc7518</td></tr><tr><td>[RFC7692]</td><td>"Compression Extensions for WebSocket". https://tools.ietf.org/html/rfc7692</td></tr><tr><td>[RFC8259]</td><td>"The JavaScript Object Notation (JSON) Data Interchange Format". T. Bray. December 2017. https://tools.ietf.org/html/rfc8259</td></tr><tr><td>[WAMP]</td><td>http://wamp-proto.org/</td></tr></table>
+
+# Chapter 2. Benefits & Issues
+
+The WebSocket protocol is defined in [RFC6455]. Working implementations of earlier draft WebSocket specifications exist, but OCPP-J implementations SHOULD use the protocol described in [RFC6455].
+
+Be aware that WebSocket defines its own message structure on top of TCP. Data sent over a WebSocket, on a TCP level, is wrapped in a WebSocket frame with a header. When using a framework this is completely transparent. When working for an embedded system however, WebSocket libraries may not be available and then one has to frame messages correctly according to [RFC6455] him/herself.
+
+# Chapter 3. WebSockets
+
+For the connection between a Charging Station and a Charging Station Management System (CSMS) using OCPP-J, the CSMS acts as a WebSocket server and the Charging Station acts as a WebSocket client.
+
+# 3.1. Client request
+
+To set up a connection, the Charging Station initiates a WebSocket connection as described in [RFC6455] section 4, "Opening Handshake".
+
+OCPP-J imposes extra constraints on the URL and the WebSocket subprotocol, detailed in the following two sections 3.1.1 and 3.1.2.
+
+The Client (Charging Station) SHALL keep this WebSocket connection open all the time.
+
+# 3.1.1. The connection URL
+
+To initiate a WebSocket connection, the Charging Station needs a URL ([RFC3986]) to connect to. This URL is henceforth called the "connection URL". This connection URL is specific to a Charging Station. The Charging Station's connection URL contains the Charging Station identity so that the CSMS knows which Charging Station a WebSocket connection belongs to. However it is RECOMMENDED to let the CSMS NOT solely rely on the connection URL to identify a Charging Station, but to double-check the Charging Station's identity against their authentication credentials.
+
+A CSMS supporting OCPP-J MUST provide at least one OCPP-J endpoint URL, from which the Charging Station SHOULD derive its connection URL. This OCPP-J endpoint URL can be any URL with a "ws" or "wss" scheme. How the Charging Station obtains an OCPP-J endpoint URL is outside of the scope of this document.
+
+To derive its connection URL, the Charging Station modifies the OCPP-J endpoint URL by appending to the path first a '/' (U+002F SOLIDUS) and then a string uniquely identifying the Charging Station. This uniquely identifying string has to be percent-encoded / URL encoded as necessary as described in [RFC3986].
+
+Example 1: for a Charging Station with identity "CS001" connecting to a CSMS with OCPP-J endpoint URL "ws://csms.example.com/ocpp" this would give the following connection URL:
+
+ws://csms.example.com/ocpp/CS001
+
+Example 2: for a Charging Station with identity "RDAM|123" connecting to a CSMS with OCPP-J endpoint URL "wss://csms.example.com/ocppj" this would give the following URL:
+
+wss://csms.example.com/ocppj/RDAM%7C123
+
+The Charging Station identity datatype is identifierString (For definition see [OCPP2.1-PART2]. In addition, the colon": character SHALL NOT be used, because the unique identifier is also used for the basic authentication username. The colon": character is used to separate the basic authentication username and the password. The maximum length of the Charging Station identity is: 48 characters. (Note: Maximum length was chosen to ensure compatibility with EVSE ID from [ISO15118-2]."
+
+# 3.1.2. OCPP version negotiation
+
+(Updated in OCPP 2.1)
+
+The OCPP version(s) MUST be specified in the Sec-WebSocket-Protocol field. The client lists the OCPP version(s) it supports in order of preference. They SHOULD be one or more of the following values:
+
+Table 1. OCPP Versions
+
+<table><tr><td>OCPP version</td><td>WebSocket subprotocol name</td></tr><tr><td>1.2</td><td>ocpp1.2</td></tr><tr><td>1.5</td><td>ocpp1.5</td></tr><tr><td>1.6</td><td>ocpp1.6</td></tr><tr><td>2.0</td><td>ocpp2.0</td></tr><tr><td>2.0.1</td><td>ocpp2.0.1</td></tr><tr><td>2.1</td><td>ocpp2.1</td></tr></table>
+
+The ones for OCPP 1.2, 1.5, 1.6, 2.0, 2.0.1 and 2.1 are official WebSocket subprotocol name values. They are registered as such with IANA. These are official WebSocket subprotocol name values, that 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.
+
+If the OCPP version is part of the OCPP-J endpoint URL it SHALL NOT determine the OCPP version to use, because the OCPP version is selected via the websocket protocol negotiation mechanism, as explained in section 3.3 Server response.
+
+# 3.1.3. Example of an opening HTTP request
+
+(Updated in OCPP 2.1)
+
+The following is an example of an opening HTTP request of an OCPP-J connection handshake:
+
+GET /webServices/ocpp/CS3211 HTTP/1.1
+
+Host: some.server.com:33033
+
+Upgrade: websocket
+
+Connection: Upgrade
+
+Sec-WebSocket-Key: x3JJHMdbDL1EzLkh9GBhXDw==
+
+Sec-WebSocket-Protocol: ocpp2.1, ocpp2.0.1, ocpp1.6
+
+Sec-WebSocket-Version: 13
+
+The bold parts are found as such in every WebSocket handshake request, the other parts are specific to this example.
+
+In this example, the CSMS's OCPP-J endpoint URL is "ws://some.server.com:33033/webServices/ocpp". The Charging Station's unique identifier is "CS3211", so the path to request becomes "webServices/ocpp/CS3211".
+
+With the Sec-WebSocket-Protocol header, the Charging Station indicates here that it can use OCPP 2.1, OCPP 2.0.1 and OCPP 1.6J, with a preference for the first in the list, in this example OCPP 2.1.
+
+The other headers in this example are part of the HTTP and WebSocket protocols and are not relevant to those implementing OCPP-J on top of third-party WebSocket libraries. The roles of these headers are explained in [RFC2616] and [RFC6455].
+
+# 3.2. Maintaining support for OCPP 2.0.1
+
+A CSMS that supports OCPP 2.1 IS RECOMMENDED to also support OCPP 2.0.1, such that Charging Stations in the network that use OCPP 2.0.1 can still connect.
+
+A Charging Station that supports OCPP 2.1 IS RECOMMENDED to also support OCPP 2.0.1, such that it can still connect to CSMSs that use OCPP 2.0.1.
+
+# 3.3. Server response
+
+Upon receiving the Charging Station's handshake request, the CSMS has to finish the handshake with a response as described in [RFC6455].
+
+The following OCPP-J-specific conditions apply:
+
+- If the CSMS does not recognize the Charging Station identifier in the URL path, it SHOULD send an HTTP response with status 404 and abort the WebSocket connection as described in [RFC6455].
+- If the CSMS does not agree to using one of the subprotocols offered by the client, it MUST complete the WebSocket handshake with a response without a Sec-WebSocket-Protocol header and then immediately close the WebSocket connection.
+
+If the CSMS accepts the above example request and agrees to using OCPP 2.1 with the Charging Station, the CSMS's response will look as follows:
+
+# HTTP/1.1 101 Switching Protocols
+
+Upgrade: websocket
+
+Connection: Upgrade
+
+Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
+
+Sec-WebSocket-Protocol: ocpp2.1
+
+The bold parts are found as such in every WebSocket handshake response, the other parts are specific to this example.
+
+The role of the Sec-WebSocket-Accept header is explained in [RFC6455].
+
+The Sec-WebSocket-Protocol header indicates that the server will be using OCPP2.1 on this connection.
+
+For a definition on how a server SHALL report a 'failure to process the message', see: CALLERROR
+
+# 3.4. WebSocket Compression
+
+OCPP 2.1 supports RFC 7692: Compression Extensions for WebSocket see: [RFC6455]
+
+Table 2. WebSocket compression support requirement for devices
+
+<table><tr><td>Device</td><td>WebSocket Compression Support</td></tr><tr><td>Charging Station</td><td>Optional</td></tr><tr><td>CSMS</td><td>Required</td></tr><tr><td>Local Controller</td><td>Required</td></tr></table>
+
+The CSMS (and Local Controller) SHALL support RFC 7692, WebSocket compression, which is a relative simple way to reduce mobile data usage. For a Charging Station this is not a hard requirement, as this might be more complex to implement on an embedded platform. It is RECOMMENDED to be implemented on a Charging Station, because it is an efficient solution to reduce mobile data usage.
+
+RFC 7692 allows the Charging Station and the CSMS to do a negotiation during the connection setup. When both parties support the Compression Extension they will then use DEFLATE compression ([RFC1951]) when sending data over the line. When one of the parties doesn't support it, the JSON will be sent uncompressed (like in OCPP 1.6J).
+
+When the Charging Station detects that compression is not used, it is RECOMMENDED not to close the connection, as turning of compression can be very useful during development, testing and debugging.
+
+For more detailed information read the RFC 7692.
+
+# Chapter 4. RPC framework
+
+# 4.1. Introduction
+
+A WebSocket is a full-duplex connection, simply put a pipe where data goes in and data can come out and without a clear relation between in and out. The WebSocket protocol by itself provides no way to relate messages as requests and responses. To encode these request/response relations we need a small protocol on top of WebSocket. This problem occurs in more use cases of WebSocket so there are existing schemes to solve it. The most widely-used is WAMP (see [WAMP]) but with the current version of that framework handling RPCs symmetrically is not WAMP compliant. Since the required framework is very simple we decided to define our own framework, inspired by WAMP, leaving out what we do not need and adding what we find missing.
+
+Basically what we need is very simple: we need to send a message (CALL) and receive a reply (CALLRESULT) or an explanation why the message could not be handled properly (CALLERROR). Many CALLRESULT message have a simple content with a status describing whether the CALL was accepted or not, but for those cases where a CALLRESULT contains complex data elements that the receiver might not be able to process, a receiver can respond to the CALLRESULT with a CALLRESULTTERROR message to notify the sender that its response could not be processed.
+
+Besides the request-response pair of CALL-CALLRESULT the framework also offers a SEND message, which only sends a message and does not expect a response.
+
+Our actual OCPP message will be put into a wrapper that at least contains the type of message, a unique message ID and the payload, the OCPP message itself.
+
+# 4.1.1. Synchronicity
+
+A Charging Station or CSMS SHALL NOT send a CALL message to the other party unless the CALL message it sent before has been responded to or has timed out. This does not mean that the CSMS cannot send a message to another Charging Station, while waiting for a response of a first Charging Station, this rule is per OCPP-J connection. A CALL message has been responded to when a CALLERROR or CALLRESULT message has been received with the message ID of the CALL message.
+
+A CALL message has timed out when:
+
+- it has not been responded to, and
+- an implementation-dependent timeout interval has elapsed since the message was sent.
+
+Implementations are free to choose this timeout interval. It is RECOMMENDED that they take into account the kind of network used to communicate with the other party. Mobile networks typically have much longer worst-case round-trip times than fixed lines.
+
+# NOTE
+
+The above requirements do not rule out that a Charging Station or CSMS will receive a CALL message from the other party while it is waiting for a CALLERROR or CALLRESULT. Such a situation is difficult to prevent because CALL messages from both sides can always cross each other.
+
+# NOTE
+
+A Charging Station or CSMS is allowed to send a SEND message to the other party before the CALL message it has sent has been responded to or has timed out.
+
+# 4.1.2. Message validity and Character encoding
+
+The whole message consisting of wrapper and payload MUST be valid JSON encoded with the UTF-8 (see [RFC3629]) character encoding. Furthermore, the Charging Station and CSMS have the right to reject messages which are not conform the JSON schemas.
+
+Note that all valid US-ASCII text is also valid UTF-8, so if a system sends only US-ASCII text, all messages it sends comply with the UTF-8 requirement. Non US-ASCII characters SHOULD only be used for sending natural-language text. An example of such natural-language text is the MessageType which contains the text of a DisplayMessage in OCPP 2.1
+
+# 4.1.3. The message type
+
+(Updated in OCPP 2.1)
+
+To identify the type of message one of the following Message Type Numbers MUST be used.
+
+Table 3. Message types
+
+<table><tr><td>MessageType</td><td>Message Type Number</td><td>Description</td></tr><tr><td>CALL</td><td>2</td><td>Request message, i.e. messages ending in "Request"</td></tr><tr><td>CALLRESULT</td><td>3</td><td>Response message, i.e. message ending in "Response"</td></tr><tr><td>CALLERROR</td><td>4</td><td>Error response to a request message</td></tr><tr><td>CALLRESULTERROR</td><td>5</td><td>(2.1) Error response to a response message</td></tr><tr><td>SEND</td><td>6</td><td>(2.1) Unconfirmed message without response, i.e. messages not ending in "Request" or "Response"</td></tr></table>
+
+When a system receives a message with a Message Type Number not in this list, it SHALL ignore the message payload. Each message type may have additional required fields.
+
+# 4.1.4. Message ID
+
+The message ID serves to identify a request. A message ID for any CALL or SEND message MUST be different from all message IDs previously used by the same sender for any other CALL or SEND message on any WebSocket connection using the same unique Charging Station identifier. The message ID for a retried message (e.g. when no response was received within timeout) MAY be identical to the message ID of the original message.
+
+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.
+
+A message ID for a CALLRESULTTERROR message MUST be equal to that of the CALLRESULT message that caused the CALLRESULTTERROR message to be sent.
+
+Table 4. Unique Message ID
+
+<table><tr><td>Name</td><td>Datatype</td><td>Restrictions</td></tr><tr><td>messageId</td><td>string[36]</td><td>Unique message ID, maximum length of 36 characters, to allow for UUIDs/GUIDs</td></tr></table>
+
+# 4.1.5. JSON Payload
+
+The Payload of a message is a JSON object containing the arguments relevant to the Action.
+
+If there is no payload JSON allows for two different notations: null or and empty object $\emptyset$ . Although it seems trivial, we consider it good practice to only use the empty object statement. Null usually represents something undefined, which is not the same as empty, and also $\emptyset$ is shorter.
+
+When a field is optional in the OCPP action (0..1 or 0..\*) and is left empty for a specific request/response, JSON allows for a couple of different ways to put this in a JSON string. But because OCPP is designed for wireless links, OCPP only allows 1 option: Do no put the field in the payload (so null, $\{\}$ or [] are not allowed for an empty field).
+
+When a field has a cardinality of zero/one to many (0.._ or 1.._) and it has been given one entity, than it will still remain a list, but of size 1.
+
+# 4.1.6. Action
+
+The Action field in the CALL message MUST be the OCPP message name without the "Request" suffix.
+
+For example: For a "BootNotificationRequest" the action field will be set to "BootNotification".
+
+BTW: The CALLRESULT does not contain the action field. A client can match the Response (CALLRESULT) with the Request (CALL) via the Messaging field.
+
+# 4.1.7. Message Validity
+
+An message is only valid when:
+
+- Action is a known Action.
+- The JSON payload is valid JSON
+- All the required field for the Action are present
+- All data is of the correct data type.
+
+When a message is not valid, the server SHALL respond with a CALLERROR
+
+# 4.2. Message structures for different message types
+
+# NOTE
+
+You may find the Charging Station identity missing in the following paragraphs. The identity is exchanged during the WebSocket connection handshake and is a property of the connection. Every message is sent by or directed at this identity. There is therefore no need to repeat it in each message.
+
+# 4.2.1. CALL
+
+A CALL always consists of 4 elements: The standard elements MessageTyped and Messaging, a specific Action that is required on the other side and a payload, the arguments to the Action. The syntax of a CALL looks like this:
+
+[ \left[ <\text{MessageTypeId} >, \left[ <\text{MessageId} > \right], \left[ <\text{Action} > \right], \{\langle\text{Payload} \rangle \} \right] ]
+
+Table 5. CALL Fields
+
+<table><tr><td>Field</td><td>Datatype</td><td>Meaning</td></tr><tr><td>MessageTypel d</td><td>integer</td><td>This is a Message Type Number which is used to identify the type of the message.</td></tr><tr><td>Messageld</td><td>string[36]</td><td>This is a unique identifier that will be used to match request and result.</td></tr><tr><td>Action</td><td>string</td><td>The name of the remote procedure or action. This field SHALL contain a case-sensitive string. The field SHALL contain the OCPP Message name without the "Request" suffix. For example: For a "BootNotificationRequest", this field shall be set to "BootNotification".</td></tr><tr><td>Payload</td><td>JSON</td><td>JSON Payload of the action, see: JSON Payload for more information.</td></tr></table>
+
+For example, a BootNotificationRequest could look like this:
+
+```json
+[
+ 2,
+ "19223201",
+ "BootNotification",
+ {
+ "reason": "PowerUp",
+ "chargingStation": { "model": "SingleSocketCharger", "vendorName": "VendorX" }
+ }
+]
+```
+
+# 4.2.2. CALLRESULT
+
+If the call can be handled correctly the result will be a regular CALLRESULT. Error situations that are covered by the definition of the OCPP response definition are not considered errors in this context. They are regular results and as such will be treated as a normal CALLRESULT, even if the result is undesirable for the recipient.
+
+A CALLRESULT always consists of 3 elements: The standard elements MessageTyped and Messaging and a payload, containing the response to the Action in the original Call.
+
+The syntax of a CALLRESULT looks like this:
+
+[ \langle MessageTypeId \rangle, \langle MessageId \rangle, \{ \langle Payload \rangle \} ]
+
+Table 6. CALLRESULT Fields
+
+<table><tr><td>Field</td><td>Datatype</td><td>Meaning</td></tr><tr><td>MessageTypeld</td><td>integer</td><td>This is a Message Type Number which is used to identify the type of the message.</td></tr><tr><td>Messageld</td><td>string[36]</td><td>This MUST be the exact same ID that is in the call request so that the recipient can match request and result.</td></tr><tr><td>Payload</td><td>JSON</td><td>JSON Payload of the action, see: JSON Payload for more information.</td></tr></table>
+
+For example, a BootNotification response could look like this:
+
+```json
+[
+ 3,
+ "19223201",
+ { "currentTime": "2013-02-01T20:53:32.486Z", "interval": 300, "status": "Accepted" }
+]
+```
+
+# 4.2.3. CALLERROR and CALLRESULTTERROR
+
+(Updated in OCPP 2.1)
+
+CALLERROR and CALLRESULTTERROR are basically the same. A CALLERROR, rather than a CALLRESULT, is sent in response to a CALL message type, when it contains errors. A CALLRESULTTERROR is sent back on receipt of a CALLRESULT that contains errors to notify the sender that the response could not be processed.
+
+We only use CALLERROR or CALLRESULTTERROR in two situations:
+
+1. An error occurred during the transport of the message. This can be a network issue, an availability of service issue, etc.
+2. The CALL or CALLRESULT is received but the content of the message does not meet the requirements for a proper message. This could be missing mandatory fields, an existing message with the same unique identifier is being handled already, unique identifier too long, invalid JSON or OCPP syntax etc.
+
+When a server needs to report a 'failure to process the message', the server SHALL use a Message Type: CALLERROR (MessageTypeNumber = 4).
+
+When a server receives a corrupt message, the CALLERROR SHALL NOT directly include syntactically invalid JSON (For example, without encoding it first). When also the MessagingId cannot be read, the CALLERROR SHALL contain "-1" as MessagingId.
+
+When a message contains any invalid OCPP and/or it is not conform the JSON schema, the system is allowed to drop the message.
+
+A CALLERROR and CALLRESULTERROR always consist of 5 elements: The standard elements MessageId and Messaging, an errorCode string, an errorDescription string and an errorDetails object.
+
+The syntax of a CALLERROR looks like this:
+
+[ \left[ \langle MessageTypeId \rangle, \langle MessageId \rangle, \langle ErrorCode \rangle, \langle ErrorDescription \rangle, \langle ErrorDetails \rangle \right] ]
+
+Table 7. CALLERROR/CALLRESULT TERROR Fields
+
+<table><tr><td>Field</td><td>Datatype</td><td>Meaning</td></tr><tr><td>MessageTypeId</td><td>integer</td><td>This is a Message Type Number which is used to identify the type of the message.</td></tr><tr><td>MessageId</td><td>string[36]</td><td>This MUST be the exact same id that is in the call request so that the recipient can match request and result.</td></tr><tr><td>ErrorCode</td><td>string</td><td>This field MUST contain a string from the RPC Framework Error Codes table.</td></tr><tr><td>ErrorDescription</td><td>string[255]</td><td>Should be filled in if possible, otherwise a clear empty string ""</td></tr><tr><td>ErrorDetails</td><td>JSON</td><td>This JSON object describes error details in an undefined way. If there are no error details you MUST fill in an empty object {}.</td></tr></table>
+
+For example, a CALLERROR could look like this:
+
+```json
+[4, "162376037", "NotSupported", "SetDisplayMessageRequest not supported", {}]
+```
+
+# 4.2.4. SEND
+
+(New in OCPP 2.1)
+
+A SEND message type is sent as an unconfirmed message: it does not expect a response. It is used, for example, for frequent periodic monitor values that can be processed faster if no response has to be returned. Since SEND messages use the same WebSocket connection as CALL/CALLRESULT messages, the frequent sending of large SEND messages may cause a delay for other messages.
+
+The receiver SHALL NOT respond to a SEND message with a CALLRESULT or CALLERROR message.
+
+The sender MAY send a SEND message at any time, i.e. there is no need to wait for the CALLRESULT of the previous CALL
+
+message before sending it.
+
+A SEND always consists of the same 4 elements as a CALL message: The standard elements MessageTyped and Messagingeld, a specific Action that is required on the other side and a payload, the arguments to the Action. The syntax of a SEND looks like this:
+
+[ \langle MessageTypeId \rangle, \langle MessageId \rangle, \langle Action \rangle, \{ \langle Payload \rangle \} ]
+
+Table 8. SEND Fields
+
+<table><tr><td>Field</td><td>Datatype</td><td>Meaning</td></tr><tr><td>MessageTypeId</td><td>integer</td><td>This is a Message Type Number which is used to identify the type of the message.</td></tr><tr><td>Messageld</td><td>string[36]</td><td>This is a unique identifier that will be used to match request and result.</td></tr><tr><td>Action</td><td>string</td><td>The name of the remote procedure or action. This field SHALL contain a case-sensitive string. The field SHALL contain the OCPP Message name. For example: For a "NotifyPeriodicStream", this field shall be set to "NotifyPeriodicStream".</td></tr><tr><td>Payload</td><td>JSON</td><td>JSON Payload of the action, see: JSON Payload for more information.</td></tr></table>
+
+For example, a NotifyPeriodicEventStream could look like this:
+
+```json
+[
+ 6,
+ "19223201",
+ "NotifyPeriodicEventStream",
+ {
+ "id": 123,
+ "pending": 0,
+ "data": [
+ { "t": "2024-08-27T12:30:40Z", "v": "230.4" },
+ { "t": "2024-08-27T12:30:45Z", "v": "230.2" }
+ ]
+ }
+]
+```
+
+# 4.2.5. Diagram showing message types
+
+(Updated in OCPP 2.1)
+
+The following sequence diagram is an illustration of the use of the message type described above.
+
+
+Figure 1. Sequence diagram showing message types
+
+# 4.3. RPC Framework Error Codes
+
+The following table contains all the allowed error codes for the OCPP RPC Framework.
+
+Table 9. Valid Error Codes
+
+<table><tr><td>ErrorCode</td><td>Description</td></tr><tr><td>FormatViolation</td><td>Payload for Action is syntactically incorrect</td></tr><tr><td>GenericError</td><td>Any other error not covered by the more specific error codes in this table</td></tr><tr><td>InternalError</td><td>An internal error occurred and the receiver was not able to process the requested Action successfully</td></tr><tr><td>MessageTypeNotSupported</td><td>A message with an Message Type Number received that is not supported by this implementation.</td></tr><tr><td>NotImplemented</td><td>Requested Action is not known by receiver</td></tr><tr><td>NotSupported</td><td>Requested Action is recognized but not supported by the receiver</td></tr><tr><td>OccurrenceConstraintViolation</td><td>Payload for Action is syntactically correct but at least one of the fields violates occurrence constraints</td></tr><tr><td>PropertyConstraintViolation</td><td>Payload is syntactically correct but at least one field contains an invalid value</td></tr><tr><td>ProtocolError</td><td>Payload for Action is not conform the PDU structure</td></tr><tr><td>RpcFrameworkError</td><td>Content of the call is not a valid RPC Request, for example: Messaging could not be read.</td></tr><tr><td>SecurityError</td><td>During the processing of Action a security issue occurred preventing receiver from completing the Action successfully</td></tr><tr><td>TypeConstraintViolation</td><td>Payload for Action is syntactically correct but at least one of the fields violates data type constraints (e.g. "somestring": 12)</td></tr></table>
+
+# 4.4. Extension fallback mechanism
+
+(Updated in OCPP 2.1)
+
+Future versions of OCPP might add extra Message Types (other than CALL, CALLRESULT, CALLERROR, CALLRESULTTERROR and SEND.)
+
+When a system receives a message with a Message Type Number not in this list, it SHALL ignore the message payload. (See also paragraph The message type).
+
+# Chapter 5. Connection
+
+# 5.1. Data integrity
+
+For data integrity we rely on the underlying TCP/IP transport layer mechanisms.
+
+# 5.2. TLS fragment length
+
+TLS involves sending "Records" between peers. Records can be of type "Handshake", "Alert", "ChangeCipherSpec", "Heartbeat" or "Application". OCPP messages are sent in Application records. The payload contains a "fragment" of the application data. The record layer fragments information blocks into TLS plaintext records carrying data in chunks of 2^14 bytes (16kB) or less.
+
+TLS peers need to maintain an input and an output buffer to store an entire fragment of $16\mathrm{~kB}$ . For a low resource device it is a large cost to allocate $32\mathrm{~kB}$ for the TLS connection.
+
+
+Figure 2. Peers allocating standard $16\mathrm{kB}$ TLS buffers
+
+A TLS extension is defined in TLS Extensions RFC6066 Section 4, that allows the client to ask for a different maximum fragment length than the default $16\mathrm{kB}$ . A client can ask for a maximum fragment length of $0.5\mathrm{kB}$ , $1\mathrm{kB}$ , $2\mathrm{kB}$ or $4\mathrm{kB}$ . This TLS extension is, however, not widely supported and native managed cloud TLS termination services typically don't support this.
+
+A resource-constrained Charging Station SHOULD try to negotiate a smaller TLS maximum fragment size, and if that is not accepted by the peer, then Charging Station MAY unilaterally decide to allocate less memory to its TLS output buffer. A TLS maximum fragment length of $2\mathrm{kB}$ is suggested based on data collection during certification tests, which shows that $99\%$ of the messages fit in a $2\mathrm{kB}$ buffer.
+
+
+Figure 3. Charging Station allocating a $2\mathrm{kB}$ TLS output buffer
+
+# 5.3. WebSocket Ping in relation to OCPP Heartbeat
+
+The WebSocket specification defines Ping and Pong frames that are used to check if the remote endpoint is still responsive. In practice this mechanism is also used to prevent the network operator from quietly closing the underlying network connection after a certain period of inactivity. ThisWebSocket feature can be used as a substitute for most of the OCPP Heartbeat messages, but cannot replace all of its functionality. A Heartbeat message checks connectivity end-to-end, whereas a WebSocket ping/pong only
+
+Edition 1, 2025-01-23
+
+checks from point-to-point. This makes a difference in an extended network topology with a Local Controller between Charging Station and CSMS.
+
+Another important aspect of the Heartbeat response is time synchronisation. The Ping and Pong frames cannot be used for this so at least one original Heartbeat message a day is recommended to ensure a correct clock setting on the Charging Station.
+
+# 5.4. Reconnecting
+
+When the connection is lost, the Charging Station SHALL try to reconnect. When reconnecting, the Charging Station SHALL use an increasing back-off time with some randomization until it has successfully reconnected. This prevents an overload of the CSMS when all Charging Stations reconnect after a restart of the CSMS.
+
+The first reconnection attempts SHALL be after a back-off time of: RetryBackOffWaitMinimum seconds, plus a random value with a maximum of RetryBackOffRandomRange seconds. After every failed reconnection attempt the Charging Station SHALL double the previous back-off time, with a maximum of RetryBackOffRepeatTimes, adding a new random value with a maximum of RetryBackOffRandomRange seconds to every reconnection attempt. After RetryBackOffRepeatTimes reconnection attempts, the Charging Station SHALL keep reconnecting with the last back-off time, not increasing it any further.
+
+When reconnecting, a Charging Station SHOULD NOT send a BootNotification unless one or more of the elements in the BootNotification have changed since the last connection. For the previous SOAP based solutions this was considered good practice but when using WebSocket the server can already make the match between the identity and a communication channel at the moment the connection is established. There is no need for an additional message.
+
+# 5.5. Network node hierarchy
+
+The physical network topology is not influenced by a choice for JSON or SOAP. In case of JSON however the issues with Network Address Translation (NAT) have been resolved by letting the Charging Station open a TCP connection to the CSMS and keeping this connection open for communication initiated by the CSMS. It is therefore no longer necessary to have a smart device capable of interpreting and redirecting SOAP calls in between the CSMS and the Charging Station.
+
+# Chapter 6. OCPP Routing
+
+For some topologies it is required to route OCPP-J messages. For example when implementing a Local Controller.
+
+This section contains a solution for OCPP message routing that will work with any Charging Station and CSMS.
+
+# 6.1. Local Controller
+
+A Local controller is a device that sits between the CSMS and any number of Charging Stations, creating a local group. It is located near to the Charging Station (maybe even connected wired to the Charging Stations), so it does not have problem of losing the connection to the Charging Stations. This is practically useful for doing Local Smart Charging: load balancing between the Charging Stations on the same location. The Local Controller can see all the messages, ongoing transactions etc. It can send charging profiles to the Charging Station to influence the energy used by the Charging Stations, this way preventing the group to use more energy than available at the location at that time.
+
+The Local Controller SHALL work so the Charging Station doesn't have to behave different when connected to the Local Controller, compared to a direct connection to a CSMS. A Local Controller SHALL work so that a Charging Station can work out of the box with the Local Controller, requiring only the parameters that are needed to connect to the Local Controller to be set. The Local Controller SHALL work so that the CSMS can not notice if the Charging Station is connecting to it directly, or via the Local Controller.
+
+
+Figure 4. Local Controller Topology
+
+# 6.2. Connections
+
+For each Charging Station that connects to the Local Controller, two connections will be established:
+
+1. A WebSocket connection from the Charging Station to the Local Controller (configured in the Charging Station)
+2. A WebSocket connection from the Local Controller to the CSMS (configured in the Local Controller)
+
+Both connections SHOULD use a similar connection URI with the same Charging Station identifier. To the CSMS, the connection from the Local Controller appears to be a regular Charging Station connection.
+
+The Local Controller may open a separate WebSocket connection to the CSMS that allows the CSMS to address the Local Controller directly, which may be useful for changing settings or setting overall Charging Profiles.
+
+When a Charging Station connects to the Local Controller, it SHALL connect to it like it would to a CSMS, using the same URI Path in the connection URL as it would use to connect to the CSMS. When the connection between Charging Station and the CSMS is successfully set up, the Local Controller SHALL set up a WebSocket connection to the CSMS with the same URI Path in the connection URL that was used by the Charging Station to setup the connection. The Local Controller SHALL open a WebSocket connection for every Charging Station that connects to it.
+
+
+Figure 5. Local Controller WebSocket Connections
+
+# 6.3. Connection loss
+
+Whenever one or more WebSocket connections between CSMS and the Local Controller are lost, the Local Controller SHALL close all corresponding WebSocket to the Charging Stations that are connected to it. This is needed to force the Charging Station to queue messages as it would have done if it would have been connected to the CSMS directly and would have lost the connection to that CSMS.
+
+Whenever the connection between a Charging Station and the Local Controller is lost, the Local Controller SHALL close the WebSocket connection it has for the Charging Station to the CSMS. This is needed to let the CSMS know the Charging Station is offline and no CSMS initiated messages can be sent to it.
+
+# 6.4. Local Controller initiated messages
+
+The Local Controller SHALL relay any Charging Station initiated message to the CSMS (and vice versa).
+
+Since the Local Controller can also initiate its own messages to the Charging Station(s), a Local Controller SHALL take care of the following:
+
+1. If a Local Controller sends its own messages to a Charging Station, it SHALL guarantee that its messages have IDs that do not collide with IDs used by the CSMS, now and in the future. This can be done by either assigning a range of numbers to the Local Controller to use (and the CSMS to skip), or by using UUIDs/GUIDs.
+2. Replies to messages from the Charging Station to messages initiated by the Local Controller SHALL NOT be sent to the CSMS.
+
+# 6.5. Local Controller Security
+
+For the local controller, the normal OCPP security mechanisms will be used, as described in [OCPP2.1-PART2], part A. Security. All security profiles described there MAY be used when a Local Controller is deployed. The security section (part A) only describes the roles of the CSMS, and Charging Station. When a local controller is used, the security specification SHALL be interpreted as follows:
+
+- In the connection from the Charging Station to the Local Controller, the Charging Station SHALL act as the Charging Station, and the Local Controller SHALL act as the CSMS. When TLS is used, the Local Controller SHALL be the TLS server, and the Charging Station SHALL be the TLS client.
+- In the connection from the Local Controller to the CSMS, the Local Controller SHALL act as the Charging Station, and the CSMS SHALL acts as the CSMS. When TLS is used, the CSMS SHALL be the TLS server, and the Local Controller SHALL be the TLS client.
+
+When TLS with Client Side Certificates is used, the Local Controller SHALL have both a CSMS Certificate, and a Charging Station certificate (see [OCPP2.1-PART2] Part A - Keys used in OCPP), as it can function in both roles. These certificates SHALL be unique to the Local Controller. The Local Controller SHALL NOT store the Charging Station certificates of the attached Charging Stations. It SHALL also NOT store the CSMS Certificate of the CSMS. These certificates SHALL be kept private on their respective owners. The Local Controller SHALL only use its own certificates for setting up the TLS connections.
+
+It SHALL be possible to distinguish the Local Controller from the CSMS based on the URL in the CSMS Certificate. Because the Local Controller is placed in the field, there is a risk that its certificates get stolen from it, e.g. by an attack on the hardware. In that case, it SHALL only be possible to use the CSMS Certificate on the Local Controller to communicate with the attached Charging Stations, not with any other Charging Stations in the infrastructure.
+
+The TLS connections terminate on the Local Controller. So, the Local Controller can both read and manipulate data sent between the CSMSs and Charging Stations. If the security of the Local Controller is compromised, it will affect all attached Charging
+
+Stations. It is therefore RECOMMENDED to take sufficient security measures to protect the Local Controller. It is also RECOMMENDED to sign critical commands or replies with the mechanism described in Signed Messages. In this way, it can be detected if the Local Controller tries to manipulate data.
+
+# Chapter 7. Signed Messages
+
+For certain architectures it can be useful to use signed OCPP messages. This gives the Charging Station and the CSMS the ability to guarantee that messages are sent by the other party. For example when a Local Controller is involved, the Charging Station can know that a message received from the Local Controller is created and signed by the CSMS.
+
+Message signing can also be used when forwarding data from the Charging Station or the CSMS to 3th parties such as a DSO (Distribution System Operator).
+
+Because message signing is not needed in all architectures and scenarios, it is not required for all OCPP implementations. It will depend on the security requirements if this is required.
+
+This section defines a method to digitally sign any OCPP-J message. For each normal OCPP message an equivalent signed message is defined that encapsulates the normal message, and adds a digital signature.
+
+# 7.1. Signed Message Format
+
+For Signed OCPP Messages, JWS is used. For more information see: [RFC7515].
+
+Suppose we have an OPC calls encoded in the OCPP-J message:
+
+[ \langle MessageTypeId \rangle, \langle MessageId \rangle, \{ \langle Extension \rangle \}, \{ \langle Payload \rangle \} ]
+
+Then we define the equivalent signed message as follows.
+
+[ \left[ <\text{MessageTypeId}>, "<\text{MessageId}>", \{\langle\text{Extension}\rangle\}, "<\text{SignedAction}>", \{\langle\text{SignedPayload}\rangle\} \right] ]
+
+The MessageTyped and Messagingd SHALL stay the same. The <SignedAction> field SHALL be the action name (<Action>) with the string "-Signed" appended. For instance, if "<Action>" is "BootNotification", then "<SignedAction>" is "BootNotification-Signed". The <SignedPayload> SHALL be the JWS encoding of the payload, computed according to the following settings:
+
+- The JWS Payload SHALL be the <Payload> from the original message.
+- The JWS Protected Header SHALL contain a field called "OCPPAction" containing the name (<Action>) of the OCPP action, and a field called "OCPPMessageTypedId" containing the message ID (<MessageTyped>).
+- The JWS Protected Header SHOULD contain the x5t#S256 field to identify the key used for signing, as specified in Section 7.4.
+- The <SignedPayload> SHALL be encoded using the Flattened JWS JSON Serialization syntax.
+
+# 7.2. Handling Signed Messages
+
+When a Charging Station or CSMS receives a signed message, it SHALL extract the encapsulated normal message. It SHALL process it normally, following the OCPP 2.1 standard. It MAY perform additional actions that use the digital signature. This is optional, because a secure connection between the CSMS and the Charging Station is expected, hence a second process to validate a signature on message level is redundant. When a Charging Station receives a signed request, and it supports digital signing, it SHALL send a signed reply.
+
+# 7.3. Allowed Algorithms
+
+The algorithms allowed for use with JSON Web Signatures are defined in the JSON Web Algorithms standard [RFC7518]. To limit the cryptographic algorithms that a Charging Station has to implement, for OCPP the same algorithms SHALL be used as for the TLS connection used to secure communications. This means that for generating the digital signatures, the Charging Station and CSMS SHALL use the following algorithms from the JSON Web Algorithms standard [RFC7518], section 3.1:
+
+- ES256: ECDSA using P-256 and SHA-256
+- RS256: RSASSA-PKCS1-v1_5 using SHA-256
+- RS384: RSASSA-PKCS1-v1_5 using SHA-384
+
+Note that RS256 and ES256 are the algorithms recommended by [RFC7518].
+
+# 7.4. Key Management
+
+This section does not prescribe specific keys to be used for digital signatures. The CSMS Certificate and Charging Station Certificate, used for setting up a secure TLS connection, MAY be used for signing. For many use cases, these will however not be the correct keys. For instance, if the use case is to provide non-repudiation of meter readings, the messages should be signed with a certificate stored in the calibrated measuring chip.
+
+To be able to verify the digital signature, one needs to know which key was used to sign it. JSON Web Signatures supports several ways to store a key identifier with the signed message. As the certificates that can be used for signing are not specified, hash values will be used to identify them. Within the OCPP, the Charging Station and CSMS SHOULD include the field x5t#S256 in the JWS Protected Header to identify the certificate. Following the JSON Web Signatures standard [RFC7515] the value of this field SHOULD be set to the SHA-256 hash of the DER encoding of the signing certificate. How stakeholders can look up the certificate based on the hash value is out of scope for this document.
+
+# NOTE
+
+In the set up with a Local Controller, described in Local Controller, the TLS client key that would be signing messages to the CSMS will, in fact, not be the TLS client key that the TLS connection is using, since the key in the Local Controller is different from that in the Charging Station. Similarly, the TLS server key signing messages will be that of the CSMS, not that of the local controller. Therefore, implementation of the protocol MUST NOT regard this mismatch as invalidating the signatures; in fact, it is an expected and desired property to provide end-to-end authenticity.
+
+# Chapter 8. Configuration
+
+The following Configuration Variables are added to control JSON/WebSockets behaviour:
+
+# 8.1. RetryBackOffRepeatTimes
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="3">Variable</td><td>variableName</td><td colspan="2">RetryBackOffRepeatTimes</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td>variableCharacteristics</td><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When the Charging Station is reconnecting, after a connection loss, it will use this variable for the amount of times it will double the previous back-off time. When the maximum number of increments is reached, the Charging Station keeps connecting with the same back-off time.</td></tr></table>
+
+# 8.2. RetryBackOffRandomRange
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">RetryBackOffRandomRange</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When the Charging Station is reconnecting, after a connection loss, it will use this variable as the maximum value for the random part of the back-off time. It will add a new random value to every increasing back-off time, including the first connection attempt (with this maximum), for the amount of times it will double the previous back-off time. When the maximum number of increments is reached, the Charging Station will keep connecting with the same back-off time.</td></tr></table>
+
+# 8.3. RetryBackOffWaitMinimum
+
+<table><tr><td>Required</td><td colspan="3">yes</td></tr><tr><td>Component</td><td>componentName</td><td colspan="2">OCPPCommCtrlr</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">RetryBackOffWaitMinimum</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">When the Charging Station is reconnecting, after a connection loss, it will use this variable as the minimum back-off time, the first time it tries to reconnect.</td></tr></table>
+
+# 8.4. WebSocketPingInterval
+
+<table><tr><td>Required</td><td colspan="2">yes</td></tr><tr><td>Component</td><td>componentName</td><td>OCPPCommCtrl</td></tr><tr><td rowspan="4">Variable</td><td>variableName</td><td colspan="2">WebSocketPingInterval</td></tr><tr><td>variableAttributes</td><td>mutability</td><td>ReadWrite</td></tr><tr><td rowspan="2">variableCharacteristics</td><td>unit</td><td>s</td></tr><tr><td>dataType</td><td>integer</td></tr><tr><td>Description</td><td colspan="3">A value of 0 disables client sideWebSocket Ping / Pong. In this case there is either no ping / pong or the server initiates the ping and client responds with Pong.
+Positive values are interpreted as number of seconds between pings.
+Negative values are not allowed, SetConfiguration is then expected to return a Rejected result.
+It is recommended to configure WebSocketPingInterval smaller then:
+MessageAttemptsTransactionEvent * MessageAttemptIntervalTransactionEvent.
+This will limit the chance of the resend mechanism for transaction-related messages being triggered by connectivity issues.</td></tr></table>
+
+# Chapter 9. CustomData Extension
+
+In the JSON schema files all classes have the attribute additionalProperties set to false, such that a JSON parser will not accept any other properties in the message. In order to allow for some flexibility to create non-standard extensions for experimentation purposes, every JSON class has been extended with a "customData" property. This property is of type "CustomDataType", which has only one required property: "vendorld", which is used to identify the kind of customization. However, since it does not have additionalProperties set to false it can be freely extended with new properties.
+
+In the same way as is defined for the DataTransfer message, the "vendorld" SHOULD be a value from the reversed DNS namespace, where the top tiers of the name, when reversed, corresponds to the publicly registered primary DNS name of the Vendor organization.
+
+The following example shows the "CustomDataType" definition and the (optional) "customData" property in the schema definition of HeartbeatRequest:
+
+```jsonl
+{
+"\$"schema": "http://json-schema.org/draft-06-schema#"，
+"\$"id": "HeartbeatRequest"，
+"definitions": {
+"CustomDataType": {
+"description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+"javaType": "CustomDataType",
+"type": "object",
+"properties": {
+"vendorId": {
+"type": "string",
+"maxLength": 255 } }，
+"required": [ "vendorId" ] } }，
+"type": "object",
+"additionalProperties": false,
+"properties": {
+"customData": {
+"\$"ref": "#/definitions/CustomDataType" } } }
+}
+```
+
+Whereas the standard HeartbeatRequest has an empty body, a customized version, that provides the value of the main meter and a count of all sessions to date, could look like this:
+
+```json
+{
+ "customData": {
+ "vendorId": "com.mycompany.customheartbeat",
+ "mainMeterValue": 12345,
+ "sessionsToDate": 342
+ }
+}
+```
+
+A CSMS that has implemented this extension, identified by its "vendorId", will be able to process the data. Other CSMS
+
+Edition 1, 2025-01-23
+
+implementations will simply ignore these custom properties.
+
+A CSMS can request a report of the CustomizationCtrlr component to get a list of all customizations that are supported by the Charging Station.
--- /dev/null
+# OCPP
+
+# Table of Contents
+
+Disclaimer 1
+Version History 2
+
+1. Security Events 3
+2. Standardized Units of Measure 4
+3. Standardized Components 5
+
+3.1. Controller Components 5
+3.2. Physical Components 13
+3.3. Summary List of Standardized Components 31
+
+4. Standardized Variables 35
+5. Reason Codes 45
+6. Standardized additionalInfo types 48
+
+6.1. Generic. 48
+6.2. Ad hoc payment 48
+
+7. Standardized values for enumerations as string 50
+
+7.1. IdTokenEnumstringType 50
+7.2. ChargingLimitSourceEnumStringType 50
+7.3. ConnectorEnumstringType 50
+7.4. SigningMethodEnumstringType 51
+
+# Disclaimer
+
+Copyright © 2010 - 2025 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
+
+NOTE
+
+The appendix can be updated independently of the OCPP release. As a result the version numbering of the Appendix is not the same as the OCPP release.
+
+<table><tr><td>Appendix version</td><td>Date</td><td>OCPP Version</td><td>Description</td></tr><tr><td>2.0</td><td>2025-01-22</td><td>OCPP 2.1 Edition 1</td><td>Appendix version for OCPP 2.1 Updated parts are marked with " (Updated in v2.0)"</td></tr><tr><td>1.4</td><td>2024-04-30</td><td>OCPP 2.0.1 Edition 3</td><td>Appendix version for Edition 3 Updated parts are marked with " (Updated in v1.4)"</td></tr><tr><td>1.3</td><td>2022-12-15</td><td>OCPP 2.0.1</td><td>Appendix version for Errata 2 (2022)
+Updated parts are marked with " (Updated in v1.3)".</td></tr><tr><td>1.2</td><td>2021-10-01</td><td>OCPP 2.0.1</td><td>Appendix version for Errata 1 (2021)
+Appendix 3: Updated components are marked with " (Updated in v1.2)".
+Appendix 3: Added ConnectedEV component for info from ISO15118 and CHAdeMO.
+Appendix 5: Added reason MissingDeviceModellinfo</td></tr><tr><td>1.1</td><td>2020-03-23</td><td>OCPP 2.0.1</td><td>Update for OCPP 2.0.1</td></tr><tr><td>1.0</td><td>2018-04-11</td><td>OCPP 2.0</td><td>First release of this Appendix for OCPP 2.0</td></tr></table>
+
+# Chapter 1. Security Events
+
+The table below provides a list of security events. Security events that are implemented SHALL be stored at the security log and security events that are implemented and marked as critical SHALL also be pushed to the CSMS.
+
+This is a non-exhaustive list of security events, when a security event matches the description of one of the Security Events in this section, for interoperability reasons, the Security Event from this section SHALL be used, instead of adding a new (proprietary) Security Event. Some security events like; InvalidCsmsCertificate, InvalidChargingStationCertificate, etc. are mandatory to be implemented. Please refer to Part 2 - Specification for which security events are mandatory to be implemented.
+
+(Updated in v2.0)
+
+<table><tr><td>Security Event</td><td>Description</td><td>Critical</td></tr><tr><td>FirmwareUpdated</td><td>The Charging Station firmware is updated</td><td>Yes</td></tr><tr><td>FailedToAuthenticationAtCsms</td><td>The authentication credentials provided by the Charging Station were rejected by the CSMS</td><td>No</td></tr><tr><td>CsmsFailedToAuthentication</td><td>The authentication credentials provided by the CSMS were rejected by the Charging Station</td><td>No</td></tr><tr><td>SettingSystemTime</td><td>The system time on the Charging Station was changed more than ClockCtrlr.TimeAdjustmentReportingThreshold seconds</td><td>Yes</td></tr><tr><td>StartupOfTheDevice</td><td>The Charging Station has booted</td><td>Yes</td></tr><tr><td>ResetOrReboot</td><td>The Charging Station was rebooted or reset</td><td>Yes</td></tr><tr><td>SecurityLogWasCleared</td><td>The security log was cleared</td><td>Yes</td></tr><tr><td>ReconfigurationOfSecurityParameters</td><td>Security parameters, such as keys or the security profile used, were changed</td><td>No</td></tr><tr><td>MemoryExhaustion</td><td>The Flash or RAM memory of the Charging Station is getting full</td><td>Yes</td></tr><tr><td>InvalidMessages</td><td>The Charging Station has received messages that are not valid OCPP messages, if signed messages, signage invalid/incorrect</td><td>No</td></tr><tr><td>AttemptedReplayAttacks</td><td>The Charging Station has received a replayed message (other than the CSMS trying to resend a message because it there was for example a network problem)</td><td>No</td></tr><tr><td>TamperDetectionActivated</td><td>The physical tamper detection sensor was triggered</td><td>Yes</td></tr><tr><td>InvalidFirmwareSignature</td><td>The firmware signature is not valid</td><td>Yes</td></tr><tr><td>InvalidFirmwareSigningCertificate</td><td>The certificate used to verify the firmware signature is not valid</td><td>Yes</td></tr><tr><td>InvalidCsmsCertificate</td><td>The certificate that the CSMS uses was not valid or could not be verified</td><td>Yes</td></tr><tr><td>InvalidChargingStationCertificate</td><td>The certificate sent to the Charging Station using the CertificateSignedRequest message is not a valid certificate</td><td>Yes</td></tr><tr><td>DiscardedRenewedClientCertificate</td><td>The Charging Station discarded the renewed client certificate, because it was unable to successfully establish a connection using it.</td><td>Yes</td></tr><tr><td>InvalidTLSVersion</td><td>The TLS version used by the CSMS is lower than 1.2 and is not allowed by the security specification</td><td>Yes</td></tr><tr><td>InvalidTLSCipherSuite</td><td>The CSMS did only allow connections using TLS cipher suites that are not allowed by the security specification</td><td>Yes</td></tr><tr><td>MaintenanceLoginAccepted</td><td>Successful login to the local maintenance interface. It is recommended to include information like the user identification and the origin of the login attempt, which can be an ip-address or a touch screen for example, to the techInfo field. For this the following format is strongly recommended: '{\user': '\...', '\origin': '\...'}'</td><td>Yes</td></tr><tr><td>MaintenanceLoginFailed</td><td>Failed login attempt to the local maintenance interface. It is recommended to include information like the user identification and the origin of the login attempt, which can be an ip-address or a touch screen for example, to the techInfo field. For this the following format is strongly recommended: '{\user': '\...', '\origin': '\...'}'</td><td>Yes</td></tr></table>
+
+# Chapter 2. Standardized Units of Measure
+
+The standardized values for Unit of Measure. Default value of "unit" is always "Wh".
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>A</td><td>Amperes (current)</td></tr><tr><td>ASU</td><td>Arbitrary Strength Unit (Signal Strength)</td></tr><tr><td>B</td><td>Bytes</td></tr><tr><td>Celsius</td><td>Degrees (temperature)</td></tr><tr><td>dB</td><td>Decibel (for example Signal Strength)</td></tr><tr><td>dBm</td><td>Power relative to 1mW (10log(P/1mW))</td></tr><tr><td>Deg</td><td>Degrees (angle/rotation)</td></tr><tr><td>Fahrenheit</td><td>Degrees (temperature)</td></tr><tr><td>Hz</td><td>Hertz (frequency)</td></tr><tr><td>mHz</td><td>milliHertz (frequency)</td></tr><tr><td>K</td><td>Degrees Kelvin (temperature)</td></tr><tr><td>lx</td><td>Lux (Light Intensity)</td></tr><tr><td>m</td><td>Meter (length)</td></tr><tr><td>ms2</td><td>m/s2(Acceleration)</td></tr><tr><td>N</td><td>Newtons (Force)</td></tr><tr><td>Ohm</td><td>Ohm (Impedance)</td></tr><tr><td>kPa</td><td>kiloPascal (Pressure)</td></tr><tr><td>Percent</td><td>Percentage</td></tr><tr><td>RH</td><td>Relative Humidity%</td></tr><tr><td>RPM</td><td>Revolutions per Minute</td></tr><tr><td>s</td><td>Seconds (Time)</td></tr><tr><td>V</td><td>Voltage (DC or r.m.s. AC)</td></tr><tr><td>VA</td><td>Volt-Ampere (apparent power)</td></tr><tr><td>kVA</td><td>kiloVolt-Ampere (apparent power)</td></tr><tr><td>VAh</td><td>Volt-Ampere-hours (apparent energy)</td></tr><tr><td>kVAh</td><td>kiloVolt-Ampere-hours (apparent energy)</td></tr><tr><td>var</td><td>vars (reactive power)</td></tr><tr><td>kvar</td><td>kilovars (reactive power)</td></tr><tr><td>varh</td><td>var-hours (reactive energy)</td></tr><tr><td>kvarh</td><td>kilovar-hours (reactive energy)</td></tr><tr><td>W</td><td>Watts (power)</td></tr><tr><td>kW</td><td>kilowatts (power)</td></tr><tr><td>Wh</td><td>Watt-hours (energy). Default</td></tr><tr><td>kWh</td><td>kilowatt-hours (energy)</td></tr></table>
+
+# Chapter 3. Standardized Components
+
+This appendix provides a list of all standardized component names for OCPP 2.1 for controller components and for physical components. A summary table listing just all components without variables is provided at the end of this appendix in Summary List of Standardized Components.
+
+# 3.1. Controller Components
+
+This is the list of Standardized Controller Components for OCPP 2.1. and typical Variables that might be associated with them.
+
+# IMPORTANT
+
+This list does not imply that these Components are required, nor does it imply that the listed Variables are required for a Component or no other Variables are allowed to be associated with a Component.
+
+# 3.1.1.AlignedDataCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the reporting of clock-aligned meter data.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>If this variable reports a value of true, Aligned Data is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>If this variable reports a value of true, Aligned Data is supported.</td></tr><tr><td>Interval</td><td>integer</td><td>Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the MeterValuesRequest message.</td></tr><tr><td>Measurands</td><td>MemberList</td><td>Clock-aligned measurand(s) to be included in MeterValuesRequest, every AlignedDataInterval seconds.</td></tr><tr><td>SendDuringIdle</td><td>boolean</td><td>If set to true, the Charging Station SHALL NOT send clock aligned meter values when a transaction is ongoing.</td></tr><tr><td>SignReadings</td><td>boolean</td><td>If set to true, the Charging Station SHALL include signed meter values in the TransactionEventRequest to the CSMS.</td></tr><tr><td>TxEndedInterval</td><td>integer</td><td>Size (in seconds) of the clock-aligned data interval, intended to be transmitted in the TransactionEventRequest (eventType = Ended) message.</td></tr><tr><td>TxEndedMeasurands</td><td>MemberList</td><td>Clock-aligned periodic measurand(s) to be included in the meterValues element of TransactionEventRequest (eventType = Ended) for every TxEndedAlignedDataInterval of the transaction.</td></tr></table>
+
+# 3.1.2. AuthCtrl (Updated in v1.2)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the use of authorization for Charging Station use.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>If set to false, then no authorization is done before starting a transaction or when reading an idToken. If an idToken was provided, then it will be put in the idToken field of the TransactionRequest. If no idToken was provided, then idToken in TransactionRequest will be left empty and type is set to NoAuthorization.</td></tr><tr><td>AdditionaInfoItemsPerMessage</td><td>integer</td><td>Maximum number of AdditionaInfo items that can be sent in one message.</td></tr><tr><td>AuthorizationRemoteStart</td><td>boolean</td><td>Whether a remote request to start a transaction in the form of RequestStartTransactionRequest message should be authorized beforehand like a local action to start a transaction.</td></tr><tr><td>DisableRemoteAuthorization</td><td>boolean</td><td>When set to true this instructs the Charging Station to not issue any AuthorizationRequests, but only use Authorization Cache and Local Authorization List to determine validity of idTokens.</td></tr><tr><td>LocalAuthorizationOffline</td><td>boolean</td><td>Whether the Charging Station, when Offline, will start a transaction for locally-authorized identifiers.</td></tr><tr><td>LocalPreAuthorization</td><td>boolean</td><td>Whether the Charging Station, when online, will start a transaction for locally-authorized identifiers without waiting for or requesting an AuthorizationResponse from the CSMS.</td></tr><tr><td>MasterPassGroupId</td><td>string</td><td>IdTokens that have this id as groupId belong to the Master Pass Group.</td></tr><tr><td>OfflineTxForUnknownIdEnabled</td><td>boolean</td><td>If this key exists, the Charging Station supports Unknown Offline Authorization.</td></tr></table>
+
+# 3.1.3. AuthCacheCtrlr (Updated in v1.2)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the use of a local cache for authorization for Charging Station use.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>If this variable exists, the Charging Station supports an Authorization Cache.</td></tr><tr><td>Available</td><td>boolean</td><td>If this variable reports a value of true, Authorization Cache is supported.</td></tr><tr><td>LifeTime</td><td>integer</td><td>Indicates in seconds how long it takes until a token expires in the authorization cache since it is last used.</td></tr><tr><td>Policy</td><td>OptionList</td><td>Cache Entry Replacement Policy: (LRU,LFU) LeastRecentlyUsed or LeastFrequentlyUsed. Allowed values: LRU, LFU.</td></tr><tr><td>DisablePostAuthorize</td><td>boolean</td><td>When set to true this variable disables the behavior to request authorization for an idToken that is stored in the cache with a status other than Accepted, as stated in C10.FR.03 and C12.FR.05.</td></tr></table>
+
+# 3.1.4. CHAdeMOCtrl (Updated in v1.2)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">A CHAdeMO Controller component communicates with an EV using the wired CANbus protocol to exchange information and control charging using the CHAdeMO protocol</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>CHAdeMO controller enabled</td></tr><tr><td>Active</td><td>boolean</td><td>Connected</td></tr><tr><td>Complete</td><td>boolean</td><td>Protocol session ended normally</td></tr><tr><td>Tripped</td><td>boolean</td><td>CHAdeMO protocol terminated abnormally</td></tr><tr><td>Problem</td><td>boolean</td><td>CHAdeMO controller fault</td></tr><tr><td>SelftestActive(Set)</td><td>boolean</td><td>Start self-test by setting to true</td></tr><tr><td>SelftestActive</td><td>boolean</td><td>Self-test running when reported as true</td></tr><tr><td colspan="3">Specific CHAdeMO interface data from vehicle:</td></tr><tr><td>CHAdeMOProtocolNumber</td><td>integer</td><td>CHAdeMO protocol number (H'102.0)</td></tr><tr><td>VehicleStatus</td><td>boolean</td><td>Vehicle status (H'102.5.3)</td></tr><tr><td>DynamicControl</td><td>boolean</td><td>Vehicle is compatible with dynamic control (H'110.0.0)</td></tr><tr><td>HighCurrentControl</td><td>boolean</td><td>Vehicle is compatible with high current control (H'110.0.1)</td></tr><tr><td>HighVoltageControl</td><td>boolean</td><td>Vehicle is compatible with high voltage control (H'110.1.2)</td></tr><tr><td>AutoManufacturerCode</td><td>integer</td><td>Auto manufacturer code (H'700.0)A single byte manufacturer code assigned by CHAdeMO association</td></tr></table>
+
+# 3.1.5. ClockCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Provides a means to configure management of time tracking by Charging Station.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>DateTime</td><td>dateTime</td><td>Contains the current date and time.</td></tr><tr><td>NtpServerUri</td><td>string</td><td>This contains the address of the NTP server. Multiple NTP servers can be configured as backups, etc. If the NTP client supports it, it can also connect to multiple NTP servers simultaneous to get a more reliable time source. Variable instance value is single digit NTP priority (1=highest).</td></tr><tr><td>NtpSource</td><td>string</td><td>When an NTP client is implemented, this variable can be used to configure the client: Use the NTP server provided via DHCP, or use the manually configured NTP server.</td></tr><tr><td>TimeOffset</td><td>string</td><td>Configured local time offset in the format: "+01:00", "-02:00" etc.</td></tr><tr><td>NextTimeOffsetTransitionDateTime</td><td>dateTime</td><td>Date time of the next time offset transition.</td></tr><tr><td>TimeSource</td><td>string</td><td>Via this variable, the Charging Station provides the CSMS with the option to configure a clock source, if more than 1 are implemented.</td></tr><tr><td>TimeZone</td><td>string</td><td>Configured current local time zone in the format: "Europe/Oslo", "Asia/Singapore" etc.</td></tr><tr><td>TimeAdjustmentReportingThreshold</td><td>integer</td><td>If set, then time adjustments with an absolute value in seconds larger than this need to be reported as a security event SettingSystemTime.</td></tr></table>
+
+# 3.1.6.CustomizationCtrlr (New in v1.2)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to custom vendor-specific implementations, using the DataTransfer message and CustomData extensions.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>CustomImplementationEnabled</td><td>boolean</td><td>This standard configuration variable can be used to enable/disable custom implementations that the Charging Station supports. The instance name of the variable matches the vendorId of the customization in CustomData or DataTransfer messages.</td></tr><tr><td>CustomTriggers</td><td>MemberList</td><td>This variable defines the names of custom triggers that Charging Station supports in a customTrigger field of Triggermessagerequest.</td></tr></table>
+
+# 3.1.7. DeviceDataCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the exchange and storage of Charging Station Device Model data.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>BytesPerMessage</td><td>integer</td><td>Message Size (in bytes) - maxLimit used to report constraint on message size. Which message is specified in the instance.</td></tr><tr><td>ItemsPerMessage</td><td>integer</td><td>Maximum number of entries that can be sent in one message. Which entries in which message is specified in the instance.</td></tr><tr><td>ValueSize</td><td>integer</td><td>Can be used to limit the following fields: SetVariableData attributeValue, GetVariableResult attributeValue, VariableAttribute.value, VariableCharacteristics.valuesList and EventData的实际Value.</td></tr></table>
+
+# 3.1.8. DisplayMessageCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the display of messages to Charging Station users.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>Whether Display Message is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>Whether Display Message is supported.</td></tr><tr><td>DisplayMessages</td><td>integer</td><td>Amount of different messages that are currently configured in this Charging Station, via SetDisplayMessageRequest.</td></tr><tr><td>PersonalMessageSize</td><td>integer</td><td>Max size (in characters) of the personal message element of the IdTokenInfo data (0 specifies no personal data may be stored).</td></tr><tr><td>SupportedFormats</td><td>MemberList</td><td>List of message formats supported by this Charging Station. Possible values: See MessageFormatEnumType.</td></tr><tr><td>SupportedPriorities</td><td>MemberList</td><td>List of the priorities supported by this Charging Station. Possible values: See MessagePriorityEnumType.</td></tr></table>
+
+3.1.9. ISO15118Ctrl (Updated in v1.3)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td>SupportedStates</td><td>MemberList</td><td>List of the states during which to display a message supported by this Charging Station. Possible values: See MessageStateEnumType.</td></tr><tr><td>Language</td><td>OptionList</td><td>The default language of this Charging Station (per RFC 5646 language code). Supported languages are reported in the valuesList.</td></tr></table>
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Communicates with an EV to exchange information and control charging using the ISO 15118 protocol.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>ISO15118 controller enabled</td></tr><tr><td>Active</td><td>boolean</td><td>Connected</td></tr><tr><td>Tripped</td><td>boolean</td><td>ISO15118 communication session aborted</td></tr><tr><td>Complete</td><td>boolean</td><td>ISO15118 communication session ended</td></tr><tr><td>Problem</td><td>boolean</td><td>ISO15118 controller fault</td></tr><tr><td>Seccd</td><td>string</td><td>The name of the SECC in the string format as required by ISO 15118.</td></tr><tr><td>SelftestActive(Set)</td><td>boolean</td><td>Start self-test by setting to true</td></tr><tr><td>SelftestActive</td><td>boolean</td><td>Self-test running when reported as true</td></tr><tr><td>ContractValidationOffline</td><td>boolean</td><td>Supports validation of a contract certificate when offline</td></tr><tr><td>CentralContractValidationAllow ed</td><td>boolean</td><td>Contract certificates can be validated by the CSMS</td></tr><tr><td>PnCEnabled</td><td>boolean</td><td>If this variable is true, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is enabled. If this variable is false, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is disabled.</td></tr><tr><td>V2GCertificateInstallationEnabl ed</td><td>boolean</td><td>If this variable is true, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station is enabled. If this variable is false, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS and A03 - Update Charging Station Certificate initiated by the Charging Station is disabled.</td></tr><tr><td>ContractCertificateInstallationE nabled</td><td>boolean</td><td>If this variable is true, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is enabled. If this variable is false, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV and M02 - Certificate Update EV is disabled.</td></tr><tr><td>RequestMeteringReceipt</td><td>boolean</td><td>If this variable is true, then Charging Station shall request a metering receipt from EV before sending a fiscal meter value to CSMS.</td></tr><tr><td>OrganizationName</td><td>string</td><td>The organizationName of the CSO operating the charging station. It is used as the organizationName (O) of the SECC leaf certificate. Example: "John Doe Charging Services Ltd" Note: This value will usually be identical to SecurityCtrlr.OrganizationName, but it does not have to be.</td></tr><tr><td>CountryName</td><td>string</td><td>The countryName of the SECC in the ISO 3166-1 format. It is used as the countryName (C) of the SECC leaf certificate. Example: "DE"</td></tr><tr><td colspan="3">Specific ISO15118 interface data from vehicle:</td></tr><tr><td>MaxScheduleEntries</td><td>integer</td><td>MaxEntriesSAScheduleType (15118-2) or MaximumSupportingPoints (15118-20) Number of allowed schedule periods</td></tr><tr><td>RequestedEnergyTransferMode</td><td>OptionList</td><td>RequestedEnergyTransferMode "AC_single_phase_core", "AC_three_phase_core", "DC_core", "DCextended", "DC combo_core", "DC_uniquer"</td></tr></table>
+
+# 3.1.10. LocalAuthListCtrlr (Updated in v1.2)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the use of Local Authorization Lists for Charging Station use.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>Whether Local Authorization List is enabled.</td></tr><tr><td>Entries</td><td>integer</td><td>Amount of IdTokens currently in the Local Authorization List. The maxLimit of this variable SHALL be provided to report the maximum number of IdTokens that can be stored in the Local Authorization List.</td></tr><tr><td>Available</td><td>boolean</td><td>Whether Local Authorization List is supported.</td></tr><tr><td>ItemsPerMessage</td><td>integer</td><td>Maximum number of identifications that can be sent in a single SendLocalListRequest.</td></tr><tr><td>BytesPerMessage</td><td>integer</td><td>Message Size (in bytes) - puts a constraint on SendLocalListRequest message size.</td></tr><tr><td>Storage</td><td>integer</td><td>Indicates the number of bytes currently used by the Local Authorization List. MaxLimit indicates the maximum number of bytes that can be used by the Local Authorization List.</td></tr><tr><td>DisablePostAuthorize</td><td>boolean</td><td>When set to true this variable disables the behavior to request authorization for an idToken that is stored in the local authorization list with a status other than Accepted, as stated in C14.FR.03.</td></tr><tr><td>SupportsExpiryDateTime</td><td>boolean</td><td>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.</td></tr></table>
+
+# 3.1.11. MonitoringCtrlr (Updated in v1.3)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the exchange of monitoring event data.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>Whether Monitoring is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>Whether Monitoring is supported.</td></tr><tr><td>ItemsPerMessage</td><td>integer</td><td>Maximum number of items.</td></tr><tr><td>BytesPerMessage</td><td>integer</td><td>Message Size (in bytes) - puts constraint on message size.</td></tr><tr><td>MonitoringBase</td><td>optionList</td><td>Currently used MonitoringBase. (readonly)</td></tr><tr><td>MonitoringLevel</td><td>integer</td><td>Currently use MonitoringLevel (readonly)</td></tr><tr><td>OfflineQueuingSeverity</td><td>integer</td><td>When set and the Charging Station is offline, the Charging Station shall queue any notifyEventRequest messages triggered by a monitor with a severity number equal to or lower than the severity configured here. Value ranging from 0 (Emergency) to 9 (Debug).</td></tr><tr><td>ActiveMonitoringBase</td><td>OptionList</td><td>Shows the currently used MonitoringBase. Valid values according MonitoringBaseEnumType: All, FactoryDefault, HardwiredOnly. (readonly)</td></tr><tr><td>ActiveMonitoringLevel</td><td>integer</td><td>Shows the currently used MonitoringLevel. Valid values are severity levels of SetMonitoringLevelRequest: 0-9. (readonly)</td></tr></table>
+
+# 3.1.12. OCPPCommCtrl (Updated in v1.4)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to information exchange between Charging Station and CSMS.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>ActiveNetworkProfile</td><td>integer</td><td>Indicates the configuration profile the station uses at that moment to connect to the network.</td></tr><tr><td>FileTransferProtocols</td><td>MemberList</td><td>List of supported file transfer protocols.</td></tr><tr><td>HeartbeatInterval</td><td>integer</td><td>Interval in seconds of inactivity (no OCPP exchanges) with CSMS after which the Charging Station should send HeartbeatRequest.</td></tr><tr><td>MessageAttempts</td><td>integer</td><td>How often the Charging Station should try to submit a TransactionEventRequest message when the CSMS fails to process it.</td></tr><tr><td>MessageAttemptInterval</td><td>integer</td><td>How long in seconds the Charging Station should wait before resubmitting a TransactionRequest message that the CSMS failed to process.</td></tr><tr><td>MessageTimeout</td><td>integer</td><td>Message timeout in seconds. The message timeout setting in a Charging Station can be configured in the messageTimeout field in the NetworkConnectionProfile.</td></tr><tr><td>MinimumStatusDuration</td><td>integer</td><td>Minimum duration that a Charging Station or EVSE status is stable before StatusNotificationRequest is sent to the CSMS.</td></tr><tr><td>NetworkConfigurationPriority</td><td>string</td><td>A comma separated ordered list of the priority of the possible Network Connection Profiles.</td></tr><tr><td>NetworkProfileConnectionAttempts</td><td>integer</td><td>Specifies the number of connection attempts the Charging Station executes before switching to a different profile.</td></tr><tr><td>OfflineThreshold</td><td>integer</td><td>When the offline period in seconds of a Charging Station exceeds the OfflineThreshold it is recommended to send a StatusNotificationRequest for all its Connectors when the Charging Station is back online.</td></tr><tr><td>PublicKeyWithSignedMeterValue</td><td>boolean</td><td>This Configuration Variable can be used to configure whether a public key needs to be sent with a signed meter value.</td></tr><tr><td>QueueAllMessages</td><td>boolean</td><td>When this variable is set to true, the Charging Station will queue all message until they are delivered to the CSMS.</td></tr><tr><td>RetryBackOffRepeatTimes</td><td>integer</td><td>When the Charging Station is reconnecting, after a connection loss, it will use this variable for the amount of times it will double the previous back-off time.</td></tr><tr><td>RetryBackOffRandomRange</td><td>integer</td><td>When the Charging Station is reconnecting, after a connection loss, it will use this variable as the maximum value for the random part of the back-off time.</td></tr><tr><td>RetryBackOffWaitMinimum</td><td>integer</td><td>When the Charging Station is reconnecting, after a connection loss, it will use this variable as the minimum back-off time, the first time it tries to reconnect.</td></tr><tr><td>UnlockOnEVSideDisconnect</td><td>boolean</td><td>When set to true, the Charging Station SHALL unlock the cable on the Charging Station side when the cable is unplugged at the EV. For an EVSE with only fixed cables, the mutability SHALL be ReadOnly and the actual value SHALL be false. For a charging station with fixed cables and sockets, the variable is only applicable to the sockets.</td></tr><tr><td>WebSocketPingInterval</td><td>integer</td><td>Number of seconds between pings.</td></tr><tr><td>FieldLength</td><td>integer</td><td>This variable is used to report the length of <field> in <message> when it is larger than the length that is defined in the standard OCPP message schema.</td></tr></table>
+
+# 3.1.13. WebPaymentsCtrl (New in v2.0)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component to configure the creation of URLs for web payment, e.g. via dynamic QR codes.</td></tr><tr><td>Variable</td><td>Type</td><td>Description</td></tr><tr><td>URLTemplate</td><td>string</td><td>URL template</td></tr><tr><td>URLParameters</td><td>MemberList</td><td>List of supported URL parameters valuesList: "maxtime", "maxenergy", "maxcost"</td></tr><tr><td>TOTPVersion</td><td>string</td><td>Version of TOTP algorithm. valuesList: list of supported TOTP versions, e.g. "v1"</td></tr><tr><td>ChargingStationId</td><td>string</td><td>(Optional) Charging station Id to use in URL. When absent will default to Charging Station identity, as defined in SecurityCtrl.Identity.</td></tr><tr><td>ValidityTime</td><td>integer</td><td>Time in seconds to show QR, e.g. 30</td></tr><tr><td>SharedSecret</td><td>string</td><td><random text> set to a random value on first boot</td></tr><tr><td>Length</td><td>integer</td><td>Length of TOTP, e.g. 8</td></tr><tr><td>QRCodeQuality</td><td>OptionList</td><td>Low, Medium, Quartile, High</td></tr></table>
+
+# 3.1.14. ReservationCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to reservations.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>Whether Reservation is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>Whether Reservation is supported.</td></tr><tr><td>NonEvseSpecific</td><td>boolean</td><td>If this configuration variable is present and set to true: Charging Station supports Reservation without specifying an EVSE.</td></tr></table>
+
+# 3.1.15. SampledDataCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to the reporting of sampled meter data.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>If this variable reports a value of true, Sampled Data is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>If this variable reports a value of true, Sampled Data is supported.</td></tr><tr><td>SignReadings</td><td>boolean</td><td>If set to true, the Charging Station includes signed meter values in the MeterValuesRequest to the CSMS.</td></tr><tr><td>TxEndedMeasurands</td><td>MemberList</td><td>Sampled measurands to be included in the meterValues element of TransactionEventRequest (eventType = Ended), every TxEndedSampleInterval seconds from the start of the transaction.</td></tr><tr><td>TxEndedInterval</td><td>integer</td><td>Interval in seconds between sampling of metering (or other) data, intended to be transmitted in the TransactionEventRequest (eventType = Ended) message.</td></tr><tr><td>TxStartedMeasurands</td><td>MemberList</td><td>Sampled measurand(s) to be taken at the start of any transaction to be included in the meterValues field of the first TransactionEventRequest message send at the start of a transaction (eventType = Started).</td></tr><tr><td>TxUpdatedMeasurands</td><td>MemberList</td><td>Sampled measurands to be included in the meterValues element of every TransactionEventRequest (eventType = Updated), every SampledDataTxUpdatedInterval seconds from the start of the transaction.</td></tr><tr><td>TxUpdatedInterval</td><td>integer</td><td>Interval in seconds between sampling of metering (or other) data, intended to be transmitted via TransactionEventRequest (eventType = Updated) messages.</td></tr><tr><td>RegisterValuesWithoutPhases</td><td>boolean</td><td>If this variable reports a value of true, then meter values of measurand Energy.Active.Import.Register will only report the total energy over all phases without reporting the individual phase values. If this variable is absent or false, then the value for each phase is reported, possibly also with a total value (depending on the meter).</td></tr></table>
+
+# 3.1.16. SecurityCtrlr (Updated in v2.0)
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to security of communications between Charging Station and CSMS.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>BasicAuthPassword</td><td>string</td><td>The basic authentication password that is used for HTTP Basic Authentication. The string is a passwordString (see Part 2: 2.1.4) consisting of minimum 16 and a maximum as defined by the maxLimit of BasicAuthPassword, which must be at least 40 characters. 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.</td></tr><tr><td>Identity</td><td>string</td><td>The Charging Station identity. The string is an identifierString string (see Part 2: 2.1.4), so it SHALL only contain characters that are allowed for identifierString. Maximum length was chosen to ensure compatibility with EVSE ID from [EMI3] "Part 2: business objects".</td></tr><tr><td>OrganizationName</td><td>string</td><td>This configuration variable is used to set the organization name of the CSO or an organization trusted by the CSO. It is used to set the O (organizationName) RDN in the subject field of the client certificate.</td></tr><tr><td>CertSigningWaitMinimum</td><td>integer</td><td>Seconds to wait before generating another CSR in case CSMS does not return a signed certificate.</td></tr><tr><td>CertSigningRepeatTimes</td><td>integer</td><td>Number of times to rernd a SignCertificateRequest when CSMS does nor return a signed certificate.</td></tr><tr><td>AllowSecurityProfileDowngrade</td><td>boolean</td><td>If this variable is implemented and set to true, then the Charging Station allows downgrading the security profile from 3 to 2. For security reasons it is not allowed to revert from profile 2 or profile 3 to security profile 1 using OCPP.</td></tr></table>
+
+# 3.1.17. SmartChargingCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to smart charging.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>Whether Smart Charging is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>Whether Smart Charging is supported.</td></tr><tr><td>ACPhaseSwitchingSupported</td><td>boolean</td><td>If defined and true, this EVSE supports the selection of which phase to use for 1 phase AC charging.</td></tr><tr><td>ProfileStackLevel</td><td>integer</td><td>Maximum acceptable value for stackLevel in a ChargingProfile. Since the lowest stackLevel is 0, this means that if SmartChargingCtrlt ProfileStackLevel = 1, there can be at most 2 valid charging profiles per Charging Profile Purpose per EVSE.</td></tr><tr><td>RateUnit</td><td>MemberList</td><td>A list of supported quantities for use in a ChargingSchedule. Allowed values: 'A' and 'W'.</td></tr><tr><td>PeriodsPerSchedule</td><td>integer</td><td>Maximum number of periods that may be defined per ChargingSchedule.</td></tr><tr><td>ExternalControlSignalsEnabled</td><td>boolean</td><td>Indicates whether a Charging Station should respond to external control signals that influence charging.</td></tr><tr><td>NotifyChargingLimitWithSched ules</td><td>boolean</td><td>Indicates if the Charging Station should include the externally set charging limit/schedule in the message when it sends a NotifyChargingLimitRequest message. This might increase the data usage significantly, especially when an external system sends new profiles/limits with a short interval. Default is false when omitted.</td></tr><tr><td>Phases3to1</td><td>boolean</td><td>If defined and true, this Charging Station supports switching from 3 to 1 phase during a transaction.</td></tr><tr><td>Entries</td><td>integer</td><td>Amount of Charging profiles currently installed on the Charging Station. MaxLimit used to limit number of Charging profiles installed at any time.</td></tr><tr><td>LimitChangeSignificance</td><td>integer</td><td>If at the Charging Station side a change in the limit in a ChargingProfile is lower than this percentage, the Charging Station MAY skip sending a NotifyChargingLimitRequest or a TransactionEventRequest message to the CSMS. It is RECOMMENDED to set this key to a low value. See Smart Charging signals to a Charging Station from multiple actors.</td></tr></table>
+
+# 3.1.18. TariffCostCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to tariff and cost display.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>Enabled</td><td>boolean</td><td>Whether Tariff/cost is enabled.</td></tr><tr><td>Available</td><td>boolean</td><td>Whether Tariff/cost is supported.</td></tr><tr><td>TariffFallbackMessage</td><td>string</td><td>Message (and/or tariff information) to be shown to an EV Driver when there is no driver specific tariff information available.</td></tr><tr><td>TotalCostFallbackMessage</td><td>string</td><td>Message to be shown to an EV Driver when the Charging Station cannot retrieve the cost for a transaction at the end of the transaction.</td></tr><tr><td>Currency</td><td>string</td><td>Currency used by this Charging Station in a ISO 4217 formatted currency code.</td></tr></table>
+
+# 3.1.19. TxCtrl
+
+<table><tr><td colspan="3">Description</td></tr><tr><td colspan="3">Logical Component responsible for configuration relating to transaction characteristics and behaviour.</td></tr><tr><td>Variables</td><td>Type</td><td>Description</td></tr><tr><td>EVConnectionTimeOut</td><td>integer</td><td>Interval in seconds from between "starting" of a transaction until incipient transaction is automatically canceled, due to failure of EV driver to (correctly) insert the charging cable connector(s) into the appropriate socket(s). The Charging Station SHALL go back to the original state, probably: 'Available'. "Starting" might be the swiping of the RFID, pressing a start button, a RequestStartTransactionRequest being received etc.</td></tr><tr><td>TxBeforeAcceptedEnabled</td><td>boolean</td><td>With this configuration variable the Charging Station can be configured to allow charging before having received a BootNotificationResponse with RegistrationStatus: Accepted. See: Transactions before being accepted by a CSMS.</td></tr><tr><td>TxStartPoint</td><td>MemberList</td><td>Defines when the Charging Station starts a new transaction: first transactioneventRequest: eventType = Started. When any event in the given list occurs, the Charging Station SHALL start a transaction The Charging Station SHALL only send the Started event once for every transaction. It is advised to put all events that should be part of a transaction in the list, in case the start event never occurs. Because the possible events don't always have to come in the same order it is possible to provide a list of events. Which ever comes first will then cause a transaction to be started. For example: EVConnected, Authorized would mean that a transaction is started when an EV is detected (Cable is connected), or when an EV Driver swipes his RFID card en the CSMS successfully authorizes the ID for charging.</td></tr><tr><td>TxStopPoint</td><td>MemberList</td><td>Defines when the Charging Station ends a transaction: last transactioneventRequest: eventType = Ended. When any event in the given list is no longer valid, the Charging Station SHALL end the transaction. The Charging Station SHALL only send the Ended event once for every transaction.</td></tr><tr><td>MaxEnergyOnInvalidId</td><td>integer</td><td>Maximum amount of energy in Wh delivered when an identifier is deauthorized by the CSMS after start of a transaction.</td></tr><tr><td>StopTxOnInvalidId</td><td>boolean</td><td>whether the Charging Station will stop an ongoing transaction when it receives a non- Accepted authorization status in TransactionEventResponse for this transaction.</td></tr><tr><td>StopTxOnEVSideDisconnect</td><td>boolean</td><td>When set to true, the Charging Station SHALL administratively stop the transaction when the cable is unplugged from the EV.</td></tr></table>
+
+# 3.2. Physical Components
+
+This is a non-exhaustive list of Standardized Physical Components that SHALL be used when mapping a real Charging Station to the Device Model (for monitoring purposes).
+
+When the physical component that is to be mapped, matches the description of one of the Standardized Components in this section, for interoperability reasons, the Standardized Component from this section SHALL be used, instead of adding a new (proprietary) component.
+
+The list of typically used variables that is given for each Component is also non-exhaustive and all variables are optional. See also Part 1, paragraph 4.5. If a description of a variable is empty, please refer to the description in Standardized Variables.
+
+# 3.2.1. AccessBarrier
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Allows physical access of vehicles to a charging site to be controlled.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Open</td></tr><tr><td>Problem</td><td></td></tr></table>
+
+# 3.2.2. AcDcConverter
+
+<table><tr><td>Description</td></tr><tr><td>Provides a variable DC current source to force energy directly into an EV battery stack, under tight control of the EV's battery management system.</td></tr><tr><td colspan="2">Description</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>(not commanded Out of Service)</td></tr><tr><td>Problem</td><td>some problem/fault exists</td></tr><tr><td>Tripped</td><td>A problem requiring intervention has occurred</td></tr><tr><td>Overload</td><td>Excessive current/power consumption</td></tr><tr><td>DCVoltage</td><td>measured DC voltage</td></tr><tr><td>DCCurrent</td><td>measured DC current</td></tr><tr><td>Power</td><td>measured power</td></tr><tr><td>Temperature</td><td>temperature of converter</td></tr><tr><td>FanSpeed</td><td>Speed of cooling fan(s)</td></tr></table>
+
+# 3.2.3. AcPhaseSelector
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Allows a specific AC phase to be selected (typically at EVSE tier) for single phase vehicle charging in order to lower overall (e.g. site) phase imbalance.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Changing</td></tr><tr><td>Problem</td><td></td></tr><tr><td>PhaseRotation</td><td></td></tr></table>
+
+# 3.2.4. Actuator
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A general purpose electro-mechanical output system, with optional completion tracking sensing. Each output should use a Variable instance key indicating the nature of the output.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Non-Default</td></tr><tr><td>Problem</td><td></td></tr><tr><td>State</td><td></td></tr></table>
+
+# 3.2.5. AirCoolingSystem
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Fans (or equivalent devices) used to provide cooling.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Cooling system enabled to run</td></tr><tr><td>Active</td><td>Cooling</td></tr><tr><td>Problem</td><td>fault: e.g. fan stalled/slow</td></tr><tr><td>FanSpeed</td><td>Speed of cooling fan(s)</td></tr></table>
+
+# 3.2.6. AreaVentilation
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Fans (or equivalent devices) used to ensure that EVs that require ventilation during charging</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Area ventilation enabled</td></tr><tr><td>Active</td><td>Ventilating</td></tr><tr><td>Problem</td><td>fault: e.g. fan stalled/slow</td></tr><tr><td>FanSpeed</td><td>Speed of cooling fan(s)</td></tr></table>
+
+# 3.2.7. BayOccupancySensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Sensor (optical, ground loop, ultrasonic, etc.) to detect whether the associated parking/charging bay is physically vacant, or is occupied by a vehicle or other obstruction</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Sensor is sensing for occupancy</td></tr><tr><td>Active</td><td>Occupied</td></tr><tr><td>Percent</td><td>percentage obstruction (for analogue sensors).</td></tr></table>
+
+# 3.2.8. BeaconLighting
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Beacon Lighting to help EV drivers to locate nearby charging places, and/or to determine charging availability state, usually by color variation.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Beacon Lighting operational</td></tr><tr><td>Enabled(Set)=0</td><td>Disable beacon lighting</td></tr><tr><td>Active</td><td>On</td></tr><tr><td>Problem</td><td>Beacon lighting fault</td></tr><tr><td>Percent</td><td>Lighting Level (% of maximum)</td></tr><tr><td>Percent(Set)=x%</td><td>Lighting Level (% of maximum)</td></tr><tr><td>Power</td><td>Lighting Wattage</td></tr><tr><td>Color</td><td>Displayed color/intensity</td></tr></table>
+
+# 3.2.9. CableBreakawaySensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A sensor that detects when a charging cable (captive or removable) has been forcibly pulled from the Charging Station.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Breakaway sensor operational</td></tr><tr><td>Active</td><td>Tripped</td></tr><tr><td>Tripped</td><td>Breakaway detected: manual check/fix required</td></tr></table>
+
+# 3.2.10. CaseAccessSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Reports when an access door/panel is open</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Access sensor is enabled to detect/report opening/closing of access door/panel</td></tr><tr><td>Enabled(Set)=0</td><td>Disable reporting of access</td></tr><tr><td>Active</td><td>Open</td></tr><tr><td>Tripped</td><td>An access door/panel that needs manual reset action has been activated</td></tr><tr><td>Problem</td><td>A fault exists in the Sensor mechanism itself</td></tr></table>
+
+# 3.2.11. ChargingStation
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">The entire Charging Station as a logical entity</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Available for use (not commanded Out of Service)</td></tr><tr><td>Problem</td><td>Some problem/fault exists</td></tr><tr><td>Tripped</td><td>A problem requiring local/manual intervention has occurred.</td></tr><tr><td>Overload</td><td>Excessive current/power consumption</td></tr><tr><td>SupplyPhases</td><td>Number of AC supply phases connected</td></tr><tr><td>SupplyPhases(MaxLimit)</td><td>Number of AC supply phases supported</td></tr><tr><td>PhaseRotation</td><td>AC wiring phase rotation</td></tr><tr><td>ACVoltage</td><td>Measured incoming AC voltage [per phase]</td></tr><tr><td>ACVoltage(MaxLimit)</td><td>Designed maximum operating AC voltage</td></tr><tr><td>ACCurrent</td><td>Measured total AC current [per phase]</td></tr><tr><td>Power</td><td>Measured/calculated total power being consumed, including standby/ancillary loads</td></tr><tr><td>Power(MaxLimit)</td><td>Designed total operating load power, including standby/ancillary loads</td></tr><tr><td>VoltageImbalance</td><td>voltage imbalance in three phase supply</td></tr><tr><td>CurrentImbalance</td><td>current imbalance in three phase supply</td></tr><tr><td>VendorName</td><td>Charging Station vendor name (as reported in BootNotification)</td></tr><tr><td>Model</td><td>Charging Station model (as reported in BootNotification)</td></tr><tr><td>ECVariant</td><td>Engineering Change Variant</td></tr><tr><td>SerialNumber</td><td>Charging Station serial number</td></tr><tr><td>OperatingTimes</td><td>recurring operating times</td></tr><tr><td>ChargeProtocol</td><td>Charging Control Protocol applicable to the Charging Station</td></tr><tr><td>AvailabilityState</td><td>Indicates if the Charging Station is available or not (replaces the Charging Station Status values reported by the StatusNotification)</td></tr><tr><td>AllowNewSessionsPendingFirmware Update</td><td>Indicates whether new sessions can be started on EVSEs, while Charging Station is waiting for all EVSEs to become Available in order to start a pending firmware update.</td></tr></table>
+
+# 3.2.12. ChargingStatusIndicator
+
+Description
+
+<table><tr><td colspan="2">The Charging Status Indicator, provides visible feedback to the user about the connection and charging status of an EVSE/Connector. This is commonly in the form of multi-colored lighting.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>Lighted</td></tr><tr><td>Color</td><td>Displayed color</td></tr></table>
+
+# 3.2.13. ConnectedEV (updated in v2.0)
+
+<table><tr><td>Required</td><td colspan="2">no</td></tr><tr><td rowspan="2">Component</td><td>componentName</td><td>ConnectedEV</td></tr><tr><td>evse</td><td>* (EVSE to which EV is connected)</td></tr><tr><td colspan="3">Description</td></tr><tr><td colspan="3">ConnectedEV is a component that represents a connected vehicle for which data is received via an ISO 15118 or CHAdeMO interface. The information that is received, is represented as variables of ConnectedEV.</td></tr></table>
+
+ConnectedEV for ISO 15118
+
+<table><tr><td>Variable</td><td>Unit</td><td>ISO 15118-2 value</td><td>ISO 15118-20 value</td></tr><tr><td>Available</td><td>boolean</td><td colspan="2">When true this means an EV is connected.
+When false, all other fields are meaningless and should be empty strings.</td></tr><tr><td colspan="4">Protocol and static vehicle information</td></tr><tr><td>VehicleId</td><td>string</td><td>EVCCID (from SessionSetupReq)
+Six bytes, represented as hexbinary encoded string, e.g. "010203040A0B", containing the EVCC MAC address.</td><td>EVCCID (from SessionSetupReq)
+Max 255 bytes with the first 3 bytes containing the WMI as defined in ISO 3780:2009.</td></tr><tr><td>VehicleCertificate["Leaf"]</td><td>string</td><td>n/a</td><td>The PEM encoded X.509 Leaf certificate of the vehicle certificate chain</td></tr><tr><td>VehicleCertificate["SubCA1"]</td><td>string</td><td>n/a</td><td>The PEM encoded X.509 intermediate SubCA1 certificate when present in the vehicle certificate chain</td></tr><tr><td>VehicleCertificate["SubCA2"]</td><td>string</td><td>n/a</td><td>The PEM encoded X.509 intermediate SubCA2 certificate, when present in the vehicle certificate chain</td></tr><tr><td>VehicleCertificate["Root"]</td><td>string</td><td>n/a</td><td>Optional. The PEM encoded X.509 Root certificate of the vehicle certificate chain</td></tr><tr><td>ProtocolAgreed</td><td>multi-instance string</td><td>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 for ISO 15118-2:
+"urn:iso:15118:2:2013:MsgDef,1,0"
+(1,0 = version 1.0)
+For DIN SPEC 70121:
+"urn:din:70121:2012:MsgDef"</td><td>Same definition.
+Example for ISO 15118-20:
+"urn:iso:std:iso:15118:-20:DC,1,0"
+(or AC, ACDP, WPT, etc.)</td></tr><tr><td>ProtocolSupportedBy EV["1"]
+to
+ProtocolSupportedBy EV["20"]</td><td>string</td><td>A string with the following comma-separated items:
+"<uri>,<major>,<minor)".
+This is information from the SupportedAppProtocolReq message from ISO 15118
+This variable has 20 instances; one for each priority number. Priority is a number from 1 to 20 as a string, i.e. "1", "2", etc.
+Example:
+- ConnectedEV.ProTOCOLSupportedByEV["1"] = "urn:iso:15118:2:2013:MsgDef,2,0"
+- ConnectedEV.ProTOCOLSupportedByEV["2"] = "urn:iso:15118:2:2010:MsgDef,1,0"</td><td>Same definition.
+Example for ISO 15118-20:
+"urn:iso:std:iso:15118:-20:DC,1,0"
+(or AC, ACDP, WPT, etc.)</td></tr><tr><td colspan="4">Voltage and current values: (from ChargeParameterDiscoveryReq unless stated otherwise)</td></tr><tr><td>ACurrent.minSet</td><td>A</td><td>EVMinCurrent</td><td>-</td></tr><tr><td>ACurrent.maxSet</td><td>A</td><td>EVMaxCurrent</td><td>-</td></tr><tr><td>ACVoltage.maxSet</td><td>V</td><td>EVMaxVoltage</td><td>-</td></tr><tr><td>DCCurrent.minSet</td><td>A</td><td>-</td><td>EVMinimumChargeCurrent</td></tr><tr><td>DCCurrent.maxSet</td><td>A</td><td>EVMaximumCurrentLimit</td><td>EVMaximumChargeCurrent</td></tr><tr><td>DCCurrent.target</td><td>A</td><td>EVTTargetCurrent(CurrentDemandReq)</td><td>EVTTargetCurrent(DC_ChargeLoopReq)</td></tr><tr><td>DCVoltage.minSet</td><td>V</td><td>-</td><td>EVMinimumVoltage</td></tr><tr><td>DCVoltage.maxSet</td><td>V</td><td>EVMaximumVoltageLimit</td><td>EVMaximumVoltage</td></tr><tr><td>DCVoltage.target</td><td>V</td><td>EVTTargetVoltage(CurrentDemandReq)</td><td>EVTTargetVoltage(DC_ChargeLoopReq)</td></tr><tr><td colspan="4">Power, energy and time values:</td></tr><tr><td>Power.maxSet</td><td>W</td><td>EVMaximumPowerLimit(DC)</td><td>EVMaximumChargePower (AC/DC)
+All phases combined.</td></tr></table>
+
+ConnectedEV for CHAdeMO
+
+<table><tr><td>Variable</td><td>Unit</td><td>ISO 15118-2 value</td><td>ISO 15118-20 value</td></tr><tr><td>DischargePower.max Set</td><td>W</td><td>-</td><td>EVMaximumDischargePower (AC/DC) Rated maximum, all phases combined (Actual discharging power is reported via EVSE)</td></tr><tr><td>DischargePower.actu al</td><td>W</td><td>-</td><td>EVMaximumDischargePower (AC/DC) (BPT ChargeLoopReq) Actual maximum, all phases combined</td></tr><tr><td>EnergyImport.maxSet</td><td>Wh</td><td>EVEnergyCapacity (DC)</td><td>EVMaximumEnergyRequest (ScheduleExchangeReq, AC/DC_ChargeLoopReq)</td></tr><tr><td>EnergyImport.minSet</td><td>Wh</td><td>-</td><td>EVMinimumEnergyRequest (ScheduleExchangeReq, AC/DC_ChargeLoopReq)</td></tr><tr><td>EnergyImport.target</td><td>Wh</td><td>EVEnergyRequest (DC) EAmount (AC)</td><td>EVTargetEnergyRequest (ScheduleExchangeReq, AC/DC_ChargeLoopReq)</td></tr><tr><td>BatteryCapacity</td><td>Wh</td><td>EVEnergyCapacity (DC)</td><td>BatteryCapacity (AC/DC_ChargeLoopReq.DisplayParameters)</td></tr><tr><td>DepartureTime</td><td>dateTime</td><td>DepartureTime Provided as seconds since message receipt. Converted to absolute time.</td><td>DepartureTime (ScheduleExchangeReq, AC/DC_ChargeLoopReq) Provided as seconds since message receipt. Converted to absolute time.</td></tr><tr><td>RemainingTimeBulk</td><td>s</td><td>RemainingTimeToBulkSoC (CurrentDemandReq)</td><td>-</td></tr><tr><td>RemainingTimeFull.m axSet</td><td>s</td><td>-</td><td>-</td></tr><tr><td>RemainingTimeFull.ac tual</td><td>s</td><td>RemainingTimeToFullSoc (CurrentDemandReq)</td><td>RemainingTimeToMaximumSOC (AC/DC_ChargeLoopReq.DisplayParameters)</td></tr><tr><td>StateOfChargeBulk</td><td>%</td><td>BulkSoC</td><td>-</td></tr><tr><td>StateOfCharge.maxSe t</td><td>%</td><td>FullSoC</td><td>MaximumSOC (AC/DC_ChargeLoopReq.DisplayParameters)</td></tr><tr><td>StateOfChargeactual</td><td>%</td><td>DC_EVStatus.EVRESSSOC</td><td>PresentSOC (AC/DC_ChargeLoopReq.DisplayParameters)</td></tr><tr><td>ChargingCompleteBul k</td><td>boolean</td><td>BulkChargingComplete</td><td>-</td></tr><tr><td>ChargingCompleteFull</td><td>boolean</td><td>ChargingComplete</td><td>ChargingComplete (AC/DC_ChargeLoopReq.DisplayParameters)</td></tr><tr><td colspan="4">Error status values:</td></tr><tr><td colspan="4">ChargingState with a memberlist consisting of the following values:</td></tr><tr><td colspan="2">* BatteryOvervoltage</td><td>-</td><td><EVTerminationCode></td></tr><tr><td colspan="2">* BatteryUndervoltage</td><td>-</td><td>...</td></tr><tr><td colspan="2">* ChargingCurrentDeviation</td><td>FAILED ChargingCurrentDifferential</td><td>...</td></tr><tr><td colspan="2">* BatteryTemperature</td><td>FAILED RESSTemperatureInhibit</td><td>...</td></tr><tr><td colspan="2">* VoltageDeviation</td><td>FAILED ChargingVoltageOutOfRange</td><td>...</td></tr><tr><td colspan="2">* ChargingSystemError</td><td>FAILED EVRESSMalfunction</td><td>...</td></tr><tr><td colspan="2">* VehicleShiftPosition</td><td>FAILED EVShiftPosition</td><td>...</td></tr><tr><td colspan="2">* VehicleChargingEnabled</td><td>-</td><td>...</td></tr><tr><td colspan="2">* ChargingSystemIncompatibility</td><td>FAILED ChargingSystemIncompatibility</td><td>...</td></tr><tr><td colspan="2">* ChargerConnectorLockFault</td><td>FAILED ChargerConnectorLockFault</td><td>...</td></tr></table>
+
+<table><tr><td>Variable</td><td>Unit</td><td>CHAdeMO value</td></tr><tr><td>Available</td><td>boolean</td><td>Is true when an EV is connected</td></tr><tr><td colspan="3">Protocol and static vehicle information</td></tr><tr><td>VehicleId</td><td>string</td><td>Vehicle ID (H'710 + H'711 + H'712)Three times 8 bytes, represented as hexbinary encoded string, e.g."010203040A0B0C0D111213141A1B1C1D212223242A2B2C2D". A concatenation of H'710 + H'711 + H'712.</td></tr><tr><td>ProtocolAgreed</td><td>string</td><td>Lowest of Chademo protocol number from EV (H'102.0) and charger (H'109.0)Example for CHAdeMO 2.0.1: "CHAdeMO,3"(3 = version reported by CHAdeMO for v2.0.1)</td></tr><tr><td>ProtocolSupportedByEV["1"]</td><td>string</td><td>Chademo protocol number (H'102.0) supported by EVA string with the following comma-separated items:"CHAdeMO,<version>".Example for CHAdeMO 2.0.1:- ConnectedEV. ProtocolSupportedByEV = "CHAdeMO,3"</td></tr><tr><td colspan="3">Voltage and current values:</td></tr><tr><td>ACCurrent.minSet</td><td>A</td><td>-</td></tr><tr><td>ACCurrent.maxSet</td><td>A</td><td>-</td></tr><tr><td>ACVoltage.maxSet</td><td>V</td><td>-</td></tr><tr><td>DCCurrent.minSet</td><td>A</td><td>Minimum charge current (H'100.0)</td></tr><tr><td>DCCurrent.maxSet</td><td>A</td><td>-</td></tr><tr><td>DCCurrent.target</td><td>A</td><td>Charging current request (H'102.3)If HighCurrentControl is true, use the value from Charging currentrequest (extended) (H'110.1,2).</td></tr><tr><td>DCVoltage.minSet</td><td>V</td><td>Minimum battery voltage (H'100.2,3)</td></tr><tr><td>DCVoltage.maxSet</td><td>V</td><td>Maximum battery voltage (H'100.4,5)</td></tr><tr><td>DCVoltage.target</td><td>V</td><td>Target battery voltage (H'102.1,2)</td></tr><tr><td colspan="3">Power, energy and time values:</td></tr><tr><td>Power.maxSet</td><td>W</td><td>-</td></tr><tr><td>EnergyImport.maxSet</td><td>Wh</td><td>Total capacity of traction battery * 100 (H'101.5,6)</td></tr><tr><td>EnergyImport.target</td><td>Wh</td><td>-</td></tr><tr><td>DepartureTime</td><td>dateTime</td><td>-</td></tr><tr><td>RemainingTimeBulk</td><td>s</td><td>-</td></tr><tr><td>RemainingTimeFull.maxSet</td><td>s</td><td>Maximum charging time * 60 (H'101.2)</td></tr><tr><td>RemainingTimeFullactual</td><td>s</td><td>Estimated charging time * 60 (H'101.3)</td></tr><tr><td>StateOfChargeBulk</td><td>%</td><td>-</td></tr><tr><td>StateOfCharge.maxSet</td><td>%</td><td>Charged rate reference constant (H'100.6)</td></tr><tr><td>StateOfCharge的实际</td><td>%</td><td>State of charge (H'102.6)</td></tr><tr><td>ChargingCompleteBulk</td><td>boolean</td><td>-</td></tr><tr><td>ChargingCompleteFull</td><td>boolean</td><td>-</td></tr><tr><td colspan="3">Error status values:</td></tr><tr><td colspan="3">ChargingStatewith a memberlist consisting of the following values:</td></tr><tr><td colspan="2">* BatteryOvervoltage</td><td>Battery overvoltage (H'102.4.0)</td></tr><tr><td colspan="2">* BatteryUndervoltage</td><td>Battery undervoltage (H'102.4.1)</td></tr><tr><td colspan="2">* ChargingCurrentDeviation</td><td>Battery current deviation (H'102.4.2)</td></tr><tr><td colspan="2">* BatteryTemperature</td><td>High battery temperature (H'102.4.3)</td></tr><tr><td colspan="2">* VoltageDeviation</td><td>Battery voltage deviation (H'102.4.4)</td></tr><tr><td colspan="2">* ChargingSystemError</td><td>Charging system error (H'102.5.2)</td></tr><tr><td colspan="2">* VehicleShiftPosition</td><td>Vehicle shift position (H'102.5.1)</td></tr><tr><td colspan="2">* VehicleChargingEnabled</td><td>Vehicle charging enabled (H'102.5.0)</td></tr><tr><td colspan="2">* ChargingSystemIncompatibility</td><td>-</td></tr><tr><td colspan="2">* ChargerConnectorLockFault</td><td>-</td></tr></table>
+
+The following parameters coming from the WPT_ChargeLoopReq messages can be represented in the ConnectedEV component. This information might be useful for troubleshooting, but is not required for normal operation.
+
+ConnectedEV for WPT
+ConnectedEV for ACDP
+
+<table><tr><td>Variable</td><td>Unit</td><td>ISO 15118-20 value</td></tr><tr><td>WPT_EVPCPowerRequest</td><td>decimal</td><td>Power the EVPC would like to have as output in Watt.</td></tr><tr><td>WPT_EVPCPowerOutput</td><td>decimal</td><td>Power measured at the output of the EVPC electronics in Watt.</td></tr><tr><td>WPT_EVPCChargeDiagnostics</td><td>OptionList</td><td>Values are:"EVPCNoIssue","EVPCTempOverheatDetected","EVPCPowerTransferAnomalyDetected","EVPCAnomalyDetected"</td></tr><tr><td>WPT_EVPCOperatingFrequency</td><td>decimal</td><td>EVPC measured MF-WPT operating frequency.</td></tr><tr><td>WPT_EVPCCoilCurrentRequest</td><td>decimal</td><td>EVPC wants the primary device to set a specific (preferred) coil current value.</td></tr><tr><td>WPT_EVPCCoilCurrentInformation</td><td>decimal</td><td>Secondary device coil current (AC).</td></tr><tr><td>WPT_EVPCCurrentOutputInformation</td><td>decimal</td><td>DC current supplied to the EV.</td></tr><tr><td>WPT_EVPCVoltageOutputInformation</td><td>decimal</td><td>DC bus or battery voltage.</td></tr></table>
+
+The following parameters from ACDP_VehiclePositioningReq, ACPD_ConnectReq, ACDP_DisconnectReq and ACDP_SystemStatusReq can be represented in the ConnectedEV component. This information might be useful for troubleshooting, but is not required for normal operation.
+
+<table><tr><td>Variable</td><td>Unit</td><td>ISO 15118-20 value</td></tr><tr><td>ACDP_EVMobilityStatus</td><td>boolean</td><td>Is true when an EV is immobilized</td></tr><tr><td>ACDP_EVPositioningSupport</td><td>boolean</td><td>Is true when EV has positioning support</td></tr><tr><td>ACDP_EVElectricalChargingDevice Status</td><td>OptionList</td><td>Values are:"State_A"(disconnected),"State_B","State_C","State_D"(connected)</td></tr><tr><td>ACDP_EVReadyToCharge</td><td>boolean</td><td>Element signalizes if the EV is READY or NOT READY to charge.</td></tr><tr><td>ACDP_EVIImmobilizationRequest</td><td>boolean</td><td>Represents the request of immobilization of the EV. This may be related to the hand brake status.</td></tr><tr><td>ACDP_EVIImmobilized</td><td>boolean</td><td>The immobilization of the EV is a mandatory precondition to activate the pantograph.</td></tr><tr><td>ACDP_WLANStrength</td><td>decimal</td><td>Element signalizes EV WiFi reception signal strength (-dBm)</td></tr><tr><td>ACDP_EVCPStatus</td><td>OptionList</td><td>Values are:"State_A","State_B","State_C","State_D","State_E".Refer to IEC 61851-23-1.</td></tr><tr><td>ACDP_EVSOC</td><td>decimal</td><td>For operation usable SOC status in %. This value may differ from physical SOC of the battery.This parameter can be same as PresentSOC in DisplayParameter.</td></tr><tr><td>ACDP_EVErrorCode</td><td>OptionList</td><td>One of:"OK_NoEError", "FAILED", "FAILED_EmergencyEvent", "FAILED_Breaker", "FAILED_RESSTemperatureInhibit", "FAILED_RESS", "FAILED_ChargingCurrentDifferential", "FAILED_ChargingVoltageOutOfRange", "FAILED_Reserved1", "FAILED_Reserved2"</td></tr><tr><td>ACDP_EVTtimeout</td><td>boolean</td><td>Indicates the occurrence of a timeout in the EVCC.</td></tr></table>
+
+3.2.14. Connector
+
+<table><tr><td>Description</td></tr><tr><td>A means to connect an EV to a Charging Station with either a socket, an attached cable & inline connector, or any wireless power transfer device.</td></tr><tr><td colspan="2">Description</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Connector available for use (not commanded Out of Service)</td></tr><tr><td>Problem</td><td>problem/fault exists (e.g. over-temperature)</td></tr><tr><td>Tripped</td><td>A problem requiring intervention has occurred.</td></tr><tr><td>ConnectorType</td><td>A value of ConnectorStringEnumType (See Appendix 7). Specific type of connector, including sub-variant information. Note: Distinct and orthogonal to Charging Protocol, Power Type, Phases.</td></tr><tr><td>SupplyPhases</td><td>AC phases connected</td></tr><tr><td>SupplyPhases(MaxLimit)</td><td>AC phases Max</td></tr><tr><td>PhaseRotation</td><td>AC wiring phase rotation</td></tr><tr><td>ChargeProtocol</td><td>Charging Control Protocol applicable to the Connector</td></tr><tr><td>AvailabilityState</td><td>Indicates if the Connector is available or not (replaces the Status values reported by the StatusNotification)</td></tr></table>
+
+# 3.2.15. ConnectorHolsterRelease
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A mechanism present in a connector holster to prevent the connector from being removed inappropriately: typically unlocks connector after authorization.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Unlocked for removal/return</td></tr><tr><td>Problem</td><td></td></tr><tr><td>State</td><td></td></tr></table>
+
+# 3.2.16. ConnectorHolsterSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A mechanism to report when a tethered cable connector has been removed from its normal stowage position. May be used for detection of connectors left un-holstered, and possible penalty billing.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Un-Holstered</td></tr><tr><td>Problem</td><td></td></tr></table>
+
+# 3.2.17. ConnectorPlugRetentionLock
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Locking mechanism to retain an inserted plug, both to prevent on-load disconnection, and to prevent theft of charging cables</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Retention mechanism enabled</td></tr><tr><td>Active</td><td>Locked</td></tr><tr><td>Problem</td><td>Locking Failed</td></tr><tr><td>Tripped</td><td>Stall protection fuse blown, etc.</td></tr><tr><td>Tries</td><td>(Re)tries taken on last attempt</td></tr><tr><td>Tries(SetLimit)</td><td>Configured auto retry count</td></tr><tr><td>Tries(MaxLimit)</td><td>Maximum auto retry count</td></tr></table>
+
+# 3.2.18. ConnectorProtectionRelease
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">External protective mechanism (e.g. an external shutter or a connector holster lock mechanism) to prevent contact with conductors that may become "live" under other failure modes</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Protection in effect (locked except when in use)</td></tr><tr><td>Active</td><td>Unlocked</td></tr><tr><td>Problem</td><td>Lock/Unlock mechanism fault</td></tr><tr><td>Tripped</td><td>protective mechanism triggered (fuse)</td></tr></table>
+
+# 3.2.19. Controller
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">An embedded logic controller</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>Running</td></tr><tr><td>Problem</td><td>Controller fault</td></tr><tr><td>Interval[Heartbeat]</td><td>Heartbeat interval</td></tr><tr><td>Manufacturer</td><td>Controller manufacturer name</td></tr><tr><td>Model</td><td>Controller model number</td></tr><tr><td>ECVariant</td><td>Engineering Change variant</td></tr><tr><td>SerialNumber</td><td>Controller hardware serial number</td></tr><tr><td>VersionNumber</td><td>Hardware version number</td></tr><tr><td>VersionDate</td><td>Hardware version date</td></tr><tr><td>FirmwareVersion</td><td>Firmware version number (as reported in BootNotification)</td></tr><tr><td>MaxMsgElements</td><td>Array of implementation-defined limits to the number of elements of specific type that the Charging Station can accept in one message.</td></tr><tr><td>SelftestActive(Set)</td><td>Start self-test</td></tr><tr><td>SelftestActive</td><td>Self-test running</td></tr></table>
+
+# 3.2.20. ControlMetering
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Energy, Power, Electricity meter, used to measure energy, current, voltages etc.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Power</td><td>Measured power</td></tr><tr><td>ACCurrent</td><td>Measured AC current [per phase]</td></tr><tr><td>DCCurrent</td><td>Measured DC current</td></tr><tr><td>DCVoltage</td><td>Measured DC voltage</td></tr></table>
+
+# 3.2.21. CPPWMController
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Control Pilot PWM Controller: provides and senses the IEC 61851-1 / SAE J1772 low voltage DC and PWM signalling between an EVSE and EV over a control pilot line.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Connected</td></tr><tr><td>Problem</td><td>CP PWM controller fault</td></tr><tr><td>DCVoltage</td><td>Control Pilot wire DC Voltage (0-12V)</td></tr><tr><td>State</td><td>IEC 61851-1 states ("A" to "E")</td></tr><tr><td>Percentage</td><td>1kHz Duty Cycle</td></tr><tr><td>SelftestActive(Set)</td><td>Start self-test</td></tr><tr><td>SelftestActive</td><td>Self-test running</td></tr></table>
+
+# 3.2.22. DataLink
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Provides a communications link from a Charging Station to a CSMS. It may use fixed infrastructure, mobile telephony data services, WiFi, or other connectivity channels.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Data link enabled</td></tr><tr><td>Active</td><td>Connected</td></tr><tr><td>Fallback</td><td>Using Backup SIM/Network Preference</td></tr><tr><td>Complete</td><td>Link connection terminated</td></tr><tr><td>Problem</td><td>Communications module or link connection fault</td></tr><tr><td>IMSI</td><td>International Mobile Subscriber Identity number of mobile data SIM card</td></tr><tr><td>ICCID</td><td>Integrated Circuit Card Identifier of mobile data SIM card.</td></tr><tr><td>NetworkAddress</td><td>Current network address</td></tr><tr><td>SignalStrength</td><td>Data signal strength/quality</td></tr></table>
+
+# 3.2.23. Display
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Provides information and feedback to the user.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Display configured to show information</td></tr><tr><td>Problem</td><td>Display fault</td></tr><tr><td>Color</td><td>Display color (monochrome/backlighting)</td></tr><tr><td>Count[HeightInChars]</td><td>Display height (characters)</td></tr><tr><td>Count[WidthInChars]</td><td>Display width (characters)</td></tr><tr><td>DataText[Visible]</td><td>Current Display Contents</td></tr><tr><td>State</td><td>Alphanumeric code indicating current message purpose</td></tr></table>
+
+# 3.2.24. ElectricalFeed
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Represents an incoming electrical connection to a Charging Station, that may be a grid/distribution network connection, of a connection to local power generation and/or storage. Each electrical feed can record the electrical and other characteristics of that feed, including power rating, fusing, upstream metering, etc. When a Charging Station has more than one electrical feed, it must represent which feed supplies each EVSE, and which feed supplies the house load of the Charging Station itself. Simple Charging Stations with only a single electrical feed may omit all electrical feed information, in which case it is inferred that all power is supplied from a single feed, and what would otherwise be ElectricalFeed data (Variables) may be reported as being associated with the ChargingStation component.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Connected</td></tr><tr><td>Problem</td><td></td></tr><tr><td>PowerType</td><td></td></tr><tr><td>Power</td><td></td></tr><tr><td>Energy</td><td></td></tr><tr><td>DCVoltage</td><td></td></tr><tr><td>SupplyPhases</td><td></td></tr><tr><td>PhaseRotation</td><td></td></tr><tr><td>ACVoltage</td><td></td></tr></table>
+
+# 3.2.25. ELVSupply
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Represents the low voltage power supply (typically 12V DC and often other ELV voltages) that provides operating power for controllers, relays, and other electrical components.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>EnergyImportRegister</td><td>Standby/house energy meter register reading</td></tr><tr><td>Power</td><td>instantaneous standby power consumption</td></tr><tr><td>Power(MaxLimit)</td><td>Design maximum standby power consumption</td></tr><tr><td>Fallback</td><td>Running on backup energy;</td></tr><tr><td>Fallback(MaxLimit): =1</td><td>has backup</td></tr><tr><td>StateOfCharge</td><td>backup battery SOC</td></tr><tr><td>Time</td><td>(estimated) operating time on backup energy</td></tr></table>
+
+# 3.2.26. EmergencyStopSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">An "Emergency Stop" button that should be pressed by the user or other nearby persons if serious faulty behavior is observed (e.g. smoke/flames from EV or Charging Station).</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Emergency Stop action armed</td></tr><tr><td>Active</td><td>Pressed/Latched</td></tr><tr><td>Tripped</td><td>Needs manual reset</td></tr></table>
+
+# 3.2.27. EnvironmentalLighting
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Provides reporting/control of general illumination lighting in use at Charging Station.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Environmental Lighting operational</td></tr><tr><td>Enabled(Set)=0</td><td>Disable Environmental lighting</td></tr><tr><td>Active</td><td>On</td></tr><tr><td>Problem</td><td>Environmental lighting fault</td></tr><tr><td>Percent</td><td>Lighting Level (% of maximum)</td></tr><tr><td>Percent(Set)=x%</td><td>Lighting Level (% of maximum)</td></tr><tr><td>Power</td><td>Lighting Wattage</td></tr><tr><td>Color</td><td>Displayed color/intensity</td></tr></table>
+
+# 3.2.28. EVRetentionLock
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A locking mechanism on the EV side as a safety measure to prevent it being disconnected while high currents are flowing.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Retention locking detection in effect</td></tr><tr><td>Active</td><td>Locked to EV</td></tr><tr><td>Complete</td><td>Has unlocked</td></tr><tr><td>Problem</td><td>Lock Problem (e.g. failed to lock/unlock)</td></tr></table>
+
+# 3.2.29. EVSE
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">The entire chain of components responsible for transporting energy from the incoming supply to the electric vehicle (or vice versa)</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Ready for use (not commanded Out of Service)</td></tr><tr><td>Problem</td><td>some problem/fault exists</td></tr><tr><td>Tripped</td><td>A problem requiring intervention has occurred</td></tr><tr><td>Overload</td><td>Excessive current/power consumption</td></tr><tr><td>SupplyPhases</td><td>AC phases connected</td></tr><tr><td>PhaseRotation</td><td>AC wiring phase rotation</td></tr><tr><td>AllowReset</td><td>When true: EVSE can be reset individually</td></tr><tr><td>ACVoltage</td><td>Measured total AC voltage [per phase]</td></tr><tr><td>ACCurrent</td><td>Measured total AC current [per phase]</td></tr><tr><td>DCVoltage</td><td>Measured total DC voltage [per phase]</td></tr><tr><td>DCCurrent</td><td>Measured total DC current [per phase]</td></tr><tr><td>Power</td><td>Measured Power</td></tr><tr><td>VoltageImbalance</td><td>voltage imbalance in three phase supply</td></tr><tr><td>CurrentImbalance</td><td>current imbalance in three phase supply</td></tr><tr><td>ChargeProtocol</td><td>Charging Control Protocol applicable to the EVSE</td></tr><tr><td>ChargingTime</td><td>Total time duration that EV is taking energy from an EVSE. Short pauses in charging (e.g. battery pre-, post-conditioning) are included</td></tr><tr><td>PostChargingTime</td><td>Total time since EV has taken energy from EVSE</td></tr><tr><td>Count[ChargingProfiles]</td><td>Charging Profiles present</td></tr><tr><td>Count[ChargingProfiles](MaxLimit)</td><td>Maximum Charging Profiles supported</td></tr><tr><td>ISO15118Evseld</td><td>The name of the EVSE in the string format as required by ISO 15118 and IEC 63119-2. Example: "DE*ICE*E*1234567890*1"</td></tr></table>
+
+# 3.2.30. ExternalTemperatureSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Reports ambient air temperature</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>Temperature above MaxSet or MinSet</td></tr><tr><td>Problem</td><td>Temperature sensor fault</td></tr><tr><td>Temperature</td><td>Ambient temperature</td></tr></table>
+
+# 3.2.31. FiscalMetering
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Provides energy transfer readings that are the basis for billing.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Problem</td><td>Metering Fault (e.g. read error)</td></tr><tr><td>EnergyImport</td><td>Energy transferred to EV during session</td></tr><tr><td>EnergyImportRegister</td><td>Cumulative import reading</td></tr><tr><td>EnergyExport</td><td>Energy transferred from EV during session</td></tr><tr><td>EnergyExportRegister</td><td>Cumulative export reading</td></tr><tr><td>Manufacturer[Meter]</td><td>Meter manufacturer name</td></tr><tr><td>Manufacturer[CT]</td><td>Current transformer manufacturer name</td></tr><tr><td>Model[Meter]</td><td>Meter model number</td></tr><tr><td>Model[CT]</td><td>CT model number</td></tr><tr><td>ECVariant</td><td>Meter engineering change variant</td></tr><tr><td>SerialNumber[Meter]</td><td>Meter serial number</td></tr><tr><td>SerialNumber[CT]</td><td>CT serial number(s)</td></tr><tr><td>Certificate</td><td></td></tr><tr><td>OptionsSet [MeterValueAlignedData]</td><td>Set of measurands to read and report at clock-aligned time intervals while charging.</td></tr><tr><td>OptionsSet[TxnStoppedAlignedData]</td><td>Set of measurands to be read at clock-aligned time intervals while charging and reported in TransactionStopped</td></tr></table>
+
+# 3.2.32. FloodSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A sensor reporting whether the Charging Station is experiencing water ingress/pooling.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Water presence/level sensing in effect</td></tr><tr><td>Active</td><td>Flooding</td></tr><tr><td>Tripped</td><td>Water level safety sensor tripped</td></tr><tr><td>Height</td><td>Absolute water height above reference (ground) level.</td></tr><tr><td>Percent</td><td>Height as percentage between reference minimum (0%) and maximum allowable (100%). Values below 0% and above 100% are possible.</td></tr></table>
+
+# 3.2.33. GroundIsolationProtection
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">An Isolation Tester as part of their own self-test mechanisms, to confirm the isolation of floating circuitry when no Evs are connected</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Electrical isolation testing enabled</td></tr><tr><td>Active</td><td>Leakage</td></tr><tr><td>Complete</td><td>Isolation test completed</td></tr><tr><td>Problem</td><td>Isolation fault</td></tr><tr><td>Impedance</td><td>Isolation resistance/impedance</td></tr></table>
+
+# 3.2.34. Heater
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Heater to ensure reliable operation in cold environments</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Heater hardware operation enabled</td></tr><tr><td>Active</td><td>Heating</td></tr><tr><td>Problem</td><td>Heater fault</td></tr><tr><td>Tripped</td><td>Heater equipment permanent fault</td></tr><tr><td>Power</td><td>Instantaneous heater power level</td></tr><tr><td>Power(MaxLimit)</td><td>Maximum heater power</td></tr><tr><td>Power(MaxSet)</td><td>Configured heater power</td></tr><tr><td>Temperature(MinSet)</td><td>Cut-in temperature</td></tr><tr><td>Temperature(MaxSet)</td><td>Cut-out temperature</td></tr></table>
+
+# 3.2.35. HumiditySensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Reports relative air humidity</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Problem</td><td>Humidity sensor fault</td></tr><tr><td>Humidity</td><td>RH(%)</td></tr></table>
+
+# 3.2.36. LightSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Reports ambient light levels.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Problem</td><td>Lighting sensor fault</td></tr><tr><td>Light</td><td>The ambient light level</td></tr></table>
+
+# 3.2.37. LiquidCoolingSystem
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A liquid based cooling system, typically used to cool the connector cables of very high power Charging Stations.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Cooling system enabled to run</td></tr><tr><td>Active</td><td>Liquid circulating</td></tr><tr><td>Problem</td><td></td></tr><tr><td>Temperature</td><td></td></tr></table>
+
+# 3.2.38. LocalAvailabilitySensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Accepts local signal inputs controlling whether new Charging Sessions can start and/or whether ongoing sessions should continue. Typically connected to a site/building power supply, to automatically report unavailability when closed.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Local Availability input sensing in operation</td></tr><tr><td>Active</td><td>Out of Service</td></tr><tr><td>Problem</td><td>Local Availability sensing circuit error</td></tr></table>
+
+# 3.2.39. LocalController
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">The entire Local Controller as a logical entity</td></tr><tr><td>Common Variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Available for use (not commanded Out of Service)</td></tr><tr><td>Problem</td><td>Some problem/fault exists</td></tr><tr><td>Identity</td><td>Local Controller identity</td></tr><tr><td>Tripped</td><td>A problem requiring local/manual intervention has occurred.</td></tr><tr><td>Manufacturer</td><td>Local Controller manufacturer name</td></tr><tr><td>Model</td><td>Local Controller manufacturer model</td></tr><tr><td>ECVariant</td><td>Engineering Change Variant</td></tr><tr><td>SerialNumber</td><td>Local Controller serial number</td></tr><tr><td>ChargingStation</td><td>List of Charging Stations Identities connected to this LocalController. (not to be confused with the ChargingStation Component)</td></tr></table>
+
+# 3.2.40. LocalEnergyStorage (updated in v1.3)
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Local energy storage device</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>EnergyCapacity</td><td>Maximum storage capacity</td></tr><tr><td>Identity</td><td>Local Energy Storage identity</td></tr></table>
+
+# 3.2.41. OverCurrentProtection
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Protects equipment by disconnecting the electrical supply when the current drawn (on any phase) exceeds the rated value to a substantial degree.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>Tripped. Trip when over MaxSet/MaxLimit.</td></tr><tr><td>Operated</td><td>Breaker opened and auto-reclosed</td></tr><tr><td>ACCurrent</td><td>Measured total AC current [per phase]</td></tr></table>
+
+# 3.2.42. OverCurrentProtectionRecloser
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Recloser mechanism of an OverCurrentProtection to perform re-arm retries after a trip, or may be set for remotely controlled re-arming on command.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Auto reclosing enabled</td></tr><tr><td>Active</td><td>Reclosing</td></tr><tr><td>Active(Set)</td><td>Initiate manual reclose</td></tr><tr><td>Complete</td><td>Reclose cycle completed</td></tr><tr><td>Problem</td><td>Recloser Fault</td></tr><tr><td>Mode</td><td>Reclose Mode (None, Auto, Commanded)</td></tr><tr><td>Tries</td><td>(Re)tries taken on last attempt</td></tr><tr><td>Tries(SetLimit)</td><td>Configured auto retry count</td></tr><tr><td>Tries(MaxLimit)</td><td>Maximum auto retry count</td></tr></table>
+
+# 3.2.43. PowerContactor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Switches on and off the power to the EV after all authorization and safety requirements have been met. May have secondary contacts to report closure state.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>Closed</td></tr><tr><td>Tripped</td><td>Mirror contact protection tripped</td></tr><tr><td>Problem</td><td>Close/Open failed</td></tr></table>
+
+# 3.2.44. RCD
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A Residual Current Device (US: ground fault breaker) protects human life and/or downstream equipment by quickly detecting abnormal current flows (usually indicative in earth faults) in the Charging Station, cable, or EV during charging.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Tripped</td><td>Breaker opened (manual reset required)</td></tr><tr><td>Operated</td><td>Breaker opened and auto-reclosed</td></tr></table>
+
+# 3.2.45. RCDRecloser
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A motorized recloser mechanism of an RCD that may be configured to perform re-arm retries after a trip, or may be set for remotely controlled re-arming on command.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Auto reclosing enabled</td></tr><tr><td>Active</td><td>Reclosing in progress</td></tr><tr><td>Active(Set)</td><td>Initiate manual reclose</td></tr><tr><td>Complete</td><td>Reclose cycle completed</td></tr><tr><td>Problem</td><td>Recloser Fault</td></tr><tr><td>Tries</td><td>(Re)tries taken on last attempt</td></tr><tr><td>Tries(SetLimit)</td><td>Configured auto (re)try count</td></tr><tr><td>Tries(MaxLimit)</td><td>Maximum auto (re)try count</td></tr></table>
+
+# 3.2.46. RealTimeClock
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Represents realtime clock hardware that can maintain accurate date & time information in a Charging Station, even in the case of simultaneous CSMS uncontactability and power outages or resets.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>RTC running OK</td></tr><tr><td>DCVoltage</td><td>Battery voltage</td></tr><tr><td>Fallback</td><td>Battery failing</td></tr><tr><td>Fallback(MaxLimit)</td><td>RTC has backup-power. MaxLimit = 1</td></tr><tr><td>Problem</td><td>RTC fault</td></tr></table>
+
+# 3.2.47. ShockSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Measures impact forces/accelerations experienced, indicative of possible damage.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Shock sensing enabled</td></tr><tr><td>Active</td><td>Shock</td></tr><tr><td>Force</td><td>detected force (vector)</td></tr></table>
+
+# 3.2.48. SpacesCountSignage
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Electronic signage allowing a charging controller for a large charging facility to advertise counts of available spaces to passing traffic.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Spaces count signage enabled</td></tr><tr><td>Active</td><td>Not Blank</td></tr><tr><td>Count</td><td></td></tr></table>
+
+# 3.2.49. Switch
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A general purpose electromechanical input device, with optional remote defaulting/resetting of values. Each input should use a Variable instance key indicating the nature of the input.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td></td></tr><tr><td>Active</td><td>Non-Default</td></tr><tr><td>State</td><td></td></tr></table>
+
+# 3.2.50. TemperatureSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Temperature sensor at a point inside the Charging Station; multiple sensing points for a single sensing controller. Multiple sensing points for a single sensing controller may be reported using distinct Variable instance keys.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Active</td><td>High temperature (over MaxSet)</td></tr><tr><td>Problem</td><td>Internal temperature sensor fault</td></tr><tr><td>Temperature</td><td>Enclosure temperature</td></tr></table>
+
+# 3.2.51. TiltSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Measures Tilt angle from normal reference position (normally 90 degree vertical).</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Tilt sensing enabled</td></tr><tr><td>Active</td><td>Tilted</td></tr><tr><td>Angle</td><td>Measured tilt (vector) from vertical</td></tr></table>
+
+# 3.2.52. TokenReader
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">An authorization token reader (e.g. RFID)</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Token reader enabled</td></tr><tr><td>Enabled(Set)=0</td><td>Token reader disabled: allow charging without token authentication/authorization</td></tr><tr><td>Operated</td><td>token data read event</td></tr><tr><td>Problem</td><td>token reader fault</td></tr><tr><td>Token</td><td>String read by TokenReader</td></tr><tr><td>TokenType</td><td>Type of Token. Value is one of IdTokenEnumstringType (See Appendix 7).</td></tr></table>
+
+# 3.2.53.UpstreamProtectionTrigger
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Circuitry designed to trigger the disconnection of power to the structure by an upstream protection device after a severe problem has been detected</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>Upstream protection enabled</td></tr><tr><td>Active(Set)</td><td>Force triggering of upstream protection</td></tr><tr><td>Tripped</td><td>Upstream protection triggered</td></tr><tr><td>Problem</td><td>Upstream protection fault</td></tr></table>
+
+# 3.2.54. Ullnput
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">A logical input mechanism (e.g. set of buttons) that is part of a UI whose use may be communicated to the CSMS (in near real time). May support momentary inputs ("Operated") or modal state ("Active"). Multiple input sources should use explicit Variable instance keys (where the input function is key name).</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>UI input enabled</td></tr><tr><td>Operated</td><td></td></tr><tr><td>Active</td><td></td></tr></table>
+
+# 3.2.55. VehicleIdSensor
+
+<table><tr><td colspan="2">Description</td></tr><tr><td colspan="2">Reports an identifier associated with a vehicle occupying a charging bay. The identifier may be a vehicle registration number via ANPR hardware, a VIN, or other local identifier of the vehicle based on medium range/active RFID, or any other relevant technology and result.</td></tr><tr><td>Typically used variables</td><td>Description</td></tr><tr><td>Enabled</td><td>VehicleIdSensor enabled</td></tr><tr><td>Active</td><td>Processing</td></tr></table>
+
+# 3.3. Summary List of Standardized Components
+
+Following is a list that sums up all above-mentioned standardized component names.
+
+<table><tr><td>Component</td><td>Description</td></tr><tr><td>AlignedDataCtrlr</td><td>Logical Component responsible for configuration relating to the reporting of clock-aligned meter data.</td></tr><tr><td>AuthCacheCtrlr</td><td>Logical Component responsible for configuration relating to the use of a local cache for authorization for Charging Station use.</td></tr><tr><td>AuthCtrlr</td><td>Logical Component responsible for configuration relating to the use of authorization for Charging Station use.</td></tr><tr><td>CHAdeMOCtrlr</td><td>A CHAdeMO Controller component communicates with an EV using the wired CANbus protocol to exchange information and control charging using the CHAdeMO protocol</td></tr><tr><td>ClockCtrlr</td><td>Provides a means to configure management of time tracking by Charging Station.</td></tr><tr><td>CustomizationCtrlr</td><td>Responsible for configuration relating to custom vendor-specific implementations, like the DataTransfer message and CustomData extensions or CustomTriggers.</td></tr><tr><td>DeviceDataCtrlr</td><td>Logical Component responsible for configuration relating to the exchange and storage of Charging Station Device Model data.</td></tr><tr><td>DisplayMessageCtrlr</td><td>Logical Component responsible for configuration relating to the display of messages to Charging Station users.</td></tr><tr><td>ISO15118Ctrlr</td><td>Communicates with an EV to exchange information and control charging using the ISO 15118 protocol.</td></tr><tr><td>LocalAuthListCtrlr</td><td>Logical Component responsible for configuration relating to the use of Local Authorization Lists for Charging Station use.</td></tr><tr><td>MonitoringCtrlr</td><td>Logical Component responsible for configuration relating to the exchange of monitoring event data.</td></tr><tr><td>OCPPCommCtrlr</td><td>Logical Component responsible for configuration relating to information exchange between Charging Station and CSMS.</td></tr><tr><td>ReservationCtrlr</td><td>Logical Component responsible for configuration relating to reservations.</td></tr><tr><td>SampledDataCtrlr</td><td>Logical Component responsible for configuration relating to the reporting of sampled meter data.</td></tr><tr><td>SecurityCtrlr</td><td>Logical Component responsible for configuration relating to security of communications between Charging Station and CSMS.</td></tr><tr><td>SmartChargingCrlr</td><td>Logical Component responsible for configuration relating to smart charging.</td></tr><tr><td>TariffCostCtrlr</td><td>Logical Component responsible for configuration relating to tariff and cost display.</td></tr><tr><td>TxCtrlr</td><td>Logical Component responsible for configuration relating to transaction characteristics and behaviour.</td></tr><tr><td>V2XChargingCtrlr</td><td>Responsible for configuration relating to V2X charging/discharging. This component exists on the EVSE tier hierarchy.</td></tr><tr><td>DCDERCtrlr</td><td>Responsible for configuration relating to DER capabilities of the DC inverter of the EVSE in the Charging Station. The component is located at the EVSE level, since it represents the DER capabilities, also referred to as nameplate information, of the EVSE.</td></tr><tr><td>ACDERCtrlr</td><td>Responsible for configuration relating to DER capabilities that the EVSE of the Charging Station can emulate by using ISO 15118-20 ChargeLoop messages to control the inverter in the EV. The component is located at the EVSE level, since it represents the DER capabilities of the EVSE.</td></tr><tr><td>BatterySwapCtrlr</td><td>Responsible for configuration relating to Battery swapping.</td></tr><tr><td>WebPaymentsCtrlr</td><td>Responsible for configuration of a dynamic QR code for ad hoc payments.</td></tr><tr><td>AccessBarrier</td><td>Allows physical access of vehicles to a charging site to be controlled.</td></tr><tr><td>AcDcConverter</td><td>Provides a variable DC current source to force energy directly into an EV battery stack, under tight control of the EV's battery management system.</td></tr><tr><td>AcPhaseSelector</td><td>Allows a specific AC phase to be selected (typically at EVSE tier) for single phase vehicle charging in order to lower overall (e.g. site) phase imbalance.</td></tr><tr><td>Actuator</td><td>A general purpose electro-mechanical output system, with optional completion tracking sensing. Each output should use a Variable instance key indicating the nature of the output.</td></tr><tr><td>AirCoolingSystem</td><td>Fans (or equivalent devices) used to provide cooling.</td></tr><tr><td>AreaVentilation</td><td>Fans (or equivalent devices) used to ensure that EVs that require ventilation during charging</td></tr><tr><td>BayOccupancySe nor</td><td>Sensor (optical, ground loop, ultrasonic, etc.) to detect whether the associated parking/charging bay is physically vacant, or is occupied by a vehicle or other obstruction</td></tr><tr><td>BeaconLighting</td><td>Beacon Lighting to help EV drivers to locate nearby charging places, and/or to determine charging availability state, usually by color variation.</td></tr><tr><td>CableBreakawayS enor</td><td>A sensor that detects when a charging cable (captive or removable) has been forcibly pulled from the Charging Station.</td></tr><tr><td>CaseAccessSens or</td><td>Reports when an access door-panel is open</td></tr><tr><td>ChargingStation</td><td>The entire Charging Station as a logical entity</td></tr><tr><td>ChargingStatusIn dicator</td><td>The Charging Status Indicator, provides visible feedback to the user about the connection and charging status of an EVSE/Connector. This is commonly in the form of multi-colored lighting.</td></tr><tr><td>ConnectedEV</td><td>ConnectedEV is a component that represents a connected vehicle for which data is received via an ISO 15118 or CHAdeMO interface. The generic information that is received, is represented as variables of ConnectedEV. Any protocol-specific information is represented in variables of the ISO15118Ctrl or CHAdeMOCtrl component.</td></tr><tr><td>Connector</td><td>A means to connect an EV to a Charging Station with either a socket, an attached cable & inline connector, or any wireless power transfer device.</td></tr><tr><td>ConnectorHolster Release</td><td>A mechanism present in a connector holster to prevent the connector from being removed inappropriately: typically unlocks connector after authorization.</td></tr><tr><td>ConnectorHolster Sensor</td><td>A mechanism to report when a tethered cable connector has been removed from its normal stowage position. May be used for detection of connectors left un-holstered, and possible penalty billing.</td></tr><tr><td>ConnectorPlugRe tentionLock</td><td>Locking mechanism to retain an inserted plug, both to prevent on-load disconnection, and to prevent theft of charging cables</td></tr><tr><td>ConnectorProtect ionRelease</td><td>External protective mechanism (e.g. an external shutter or a connector holster lock mechanism) to prevent contact with conductors that may become 'live' under other failure modes</td></tr><tr><td>Controller</td><td>An embedded logic controller</td></tr><tr><td>ControlMetering</td><td>Energy, Power, Electricity meter, used to measure energy, current, voltages etc.</td></tr><tr><td>CPPWMControlle r</td><td>Control Pilot PWM Controller: provides and senses the IEC 61851-1 / SAE J1772 low voltage DC and PWM signalling between an EVSE and EV over a control pilot line.</td></tr><tr><td>DataLink</td><td>Provides a communications link from a Charging Station to a CSMS. It may use fixed infrastructure, mobile telephony data services, WiFi, or other connectivity channels.</td></tr><tr><td>Display</td><td>Provides information and feedback to the user.</td></tr><tr><td>DistributionPanel</td><td>Defines the Distribution Panel, with it's fuses and connections to both Charging Stations and other Distribution Panel's.</td></tr><tr><td>ElectricalFeed</td><td>Represents an incoming electrical connection to a Charging Station, that may be a grid/distribution network connection, of a connection to local power generation and/or storage. Each electrical feed can record the electrical and other characteristics of that feed, including power rating, fusing, upstream metering, etc. When a Charging Station has more than one electrical feed, it must represent which feed supplies each EVSE, and which feed supplies the house load of the Charging Station itself. Simple Charging Stations with only a single electrical feed may omit all electrical feed information, in which case it is inferred that all power is supplied from a single feed, and what would otherwise be ElectricalFeed data (Variables) may be reported as being associated with the ChargingStation component.</td></tr><tr><td>ELVSupply</td><td>Represents the low voltage power supply (typically 12V DC and often other ELV voltages) that provides operating power for controllers, relays, and other electrical components.</td></tr><tr><td>EmergencyStopSensor</td><td>An 'Emergency Stop' button that should be pressed by the user or other nearby persons if serious faulty behavior is observed (e.g. smoke/flames from EV or Charging Station).</td></tr><tr><td>EnvironmentalLignting</td><td>Provides reporting/control of general illumination lighting in use at Charging Station.</td></tr><tr><td>EVRetentionLock</td><td>A locking mechanism on the EV side as a safety measure to prevent it being disconnected while high currents are flowing.</td></tr><tr><td>EVSE</td><td>The entire chain of components responsible for transporting energy from the incoming supply to the electric vehicle (or vice versa)</td></tr><tr><td>ExternalTemperatureSensor</td><td>Reports ambient air temperature</td></tr><tr><td>FiscalMetering</td><td>Provides energy transfer readings that are the basis for billing.</td></tr><tr><td>FloodSensor</td><td>A sensor reporting whether the Charging Station is experiencing water ingress/pooling.</td></tr><tr><td>GroundIsolationProtection</td><td>An Isolation Tester as part of their own self-test mechanisms, to confirm the isolation of floating circuitry when no Evs are connected</td></tr><tr><td>Heater</td><td>Heater to ensure reliable operation in cold environments</td></tr><tr><td>HumiditySensor</td><td>Reports relative air humidity</td></tr><tr><td>LightSensor</td><td>Reports ambient light levels.</td></tr><tr><td>LiquidCoolingSystem</td><td>A liquid based cooling system, typically used to cool the connector cables of very high power Charging Stations.</td></tr><tr><td>LocalAvailabilitySensor</td><td>Accepts local signal inputs controlling whether new Charging Sessions can start and/or whether ongoing sessions should continue. Typically connected to a site/building power supply, to automatically report unavailability when closed.</td></tr><tr><td>LocalController</td><td>The entire Local Controller as a logical entity</td></tr><tr><td>LocalEnergyStorage</td><td>Energy storage</td></tr><tr><td>OverCurrentProtection</td><td>Protects equipment by disconnecting the electrical supply when the current drawn (on any phase) exceeds the rated value to a substantial degree.</td></tr><tr><td>OverCurrentProtectionRecloser</td><td>Recloser mechanism of an OverCurrentProtection to perform re-arm retries after a trip, or may be set for remotely controlled re-arming on command.</td></tr><tr><td>PowerContactor</td><td>Switches on and off the power to the EV after all authorization and safety requirements have been met. May have secondary contacts to report closure state.</td></tr><tr><td>RCD</td><td>A Residual Current Device (US: ground fault breaker) protects human life and/or downstream equipment by quickly detecting abnormal current flows (usually indicative in earth faults) in the Charging Station, cable, or EV during charging.</td></tr><tr><td>RCDrecloser</td><td>A motorized recloser mechanism of an RCD that may be configured to perform re-arm retries after a trip, or may be set for remotely controlled re-arming on command.</td></tr><tr><td>RealTimeClock</td><td>Represents realtime clock hardware that can maintain accurate date & time information in a Charging Station, even in the case of simultaneous CSMS uncontactability and power outages or resets.</td></tr><tr><td>ShockSensor</td><td>Measures impact forces/accelerations experienced, indicative of possible damage.</td></tr><tr><td>SpacesCountSignage</td><td>Electronic signage allowing a charging controller for a large charging facility to advertise counts of available spaces to passing traffic.</td></tr><tr><td>Switch</td><td>A general purpose electromechanical input device, with optional remote defaulting/resetting of values. Each input should use a Variable instance key indicating the nature of the input.</td></tr><tr><td>TemperatureSensor</td><td>Temperature sensor at a point inside the Charging Station, multiple sensing points for a single sensing controller. Multiple sensing points for a single sensing controller may be reported using distinct Variable instance keys.</td></tr><tr><td>TiltSensor</td><td>Measures Tilt angle from normal reference position (normally 90 degree vertical).</td></tr><tr><td>TokenReader</td><td>An authorization token reader (e.g. RFID)</td></tr><tr><td>UpstreamProtecti onTrigger</td><td>Circuitry designed to trigger the disconnection of power to the structure by an upstream protection device after a severe problem has been detected</td></tr><tr><td>UInput</td><td>A logical input mechanism (e.g. set of buttons) that is part of a UI whose use may be communicated to the CSMS (in near real time). May support momentary inputs ('Operated') or modal state ('Active'). Multiple input sources should use explicit Variable instance keys (where the input function is key name).</td></tr><tr><td>VehicleIdSensor</td><td>Reports an identifier associated with a vehicle occupying a charging bay. The identifier may be a vehicle registration number via ANPR hardware, a VIN, or other local identifier of the vehicle based on medium range/active RFID, or any other relevant technology and result.</td></tr></table>
+
+# Chapter 4. Standardized Variables
+
+This is a non-exhaustive list of Standardized Variables that SHALL be used when the Charging Station and CSMS want to exchange information about a Variable. See also Part 1, paragraph 4.5.
+
+Variables that are specific to a Controller Component are not included in this list, but are part of section 3.1 Controller Components.
+
+<table><tr><td>Name</td><td>DataType</td><td>Unit</td><td>Description</td></tr><tr><td>ACCurrent</td><td>decimal</td><td>A</td><td>RMS AC Current (in amperes). For 3-phase circuits, each phase (and optional neutral) is represented by a Variable instance equal to a value of the PhaseEnumType (e.g. L1,N). Unkeyed values reported for a Component declared to be multi-phase are assumed to be an average of all per-phase readings and written values are common per-phase settings. Example(s): ChargingStation: Total AC current consumption (all EVSE's, ancillaries), EVSE: Total current consumed by EVSE: includes losses (AC@DC) and EVSE specific ancillaries (e.g. fans), ElectricalFeed: Inflow AC current on feed</td></tr><tr><td>ACPhaseSwitchingSupported</td><td>boolean</td><td></td><td>If defined and true, this EVSE supports the selection of which phase to use for 1 phase AC charging.</td></tr><tr><td>ACVoltage</td><td>decimal</td><td>V</td><td>RMS AC Voltage (in volts). For 3-phase circuits, each phase (and optional neutral) is represented by a Variable instance equal to a value of the PhaseEnumType (e.g. L1,N). Unkeyed values reported for a Component declared to be multi-phase are assumed to be an average of all per-phase readings and written values are common per-phase settings. Example(s): ElectricalFeed: Input Voltage</td></tr><tr><td>Active</td><td>boolean</td><td></td><td>Component is in its non-resting / active state: e.g: On, Engaged, Locked. Some Components may have secondary functions that have corresponding Active Variables with an explicit Variable instance., Note: Monitoring of changes in the Active state of any Component can be specified by setting Delta monitoring on the boolean value with a delta values of 1. Setting/clearing an Active Variable activates/stops the associated functionality, where remotely controllable. Only components that are Available and Enabled can be in the Active state.</td></tr><tr><td>ActiveMonitoringBase</td><td>OptionList</td><td></td><td>Shows the currently used MonitoringBase.</td></tr><tr><td>ActiveMonitoringLevel</td><td>integer</td><td></td><td>Shows the currently use MonitoringLevel.</td></tr><tr><td>ActiveNetworkProfile</td><td>boolean</td><td></td><td>Indicates the configuration profile the station uses to connect to the network.</td></tr><tr><td>ActiveTransactionId</td><td>string</td><td></td><td>Active transaction on charging station or EVSE.</td></tr><tr><td>AdditionallyInfoItemsPerMessage</td><td>integer</td><td></td><td>Maximum number of additionalInfo items that can be sent in one message.</td></tr><tr><td>AdditionalRootCertificateCheck</td><td>boolean</td><td></td><td>When set to true, only one certificate (plus a temporarily fallback certificate) of certificateType CSMSRootCertificate is allowed to be installed at a time.</td></tr><tr><td>AllowEnergyTransferResumption</td><td>boolean</td><td></td><td>This variable defines whether energy transfer is allowed to be resumed when the transaction is resumed after a reset or power outage.</td></tr><tr><td>AllowNewSessionsPendingFirmwareUpdate</td><td>boolean</td><td></td><td>Indicates whether new sessions can be started on EVSEs, while Charging Station is waiting for all EVSEs to become Available in order to start a pending firmware update.</td></tr><tr><td>AllowReset</td><td>boolean</td><td></td><td>Component can be reset. Can be used to announce that an EVSE can be reset individually.</td></tr><tr><td>AllowSecurityProfileDowngrade</td><td>boolean</td><td></td><td>If this variable is implemented and set to true, then the Charging Station allows downgrading the security profile from 3 to 2.</td></tr><tr><td>Angle</td><td>decimal</td><td>Deg</td><td>Angle(s) relative to normal/design idle position. Multiple Variable instance values may be used to indicate angular position in multiple axes (e.g. Left-Right, Forward-Back).</td></tr><tr><td>Attempts</td><td>integer</td><td></td><td>Number of attempts (INCLUDING the original attempt) in the last successful or attempted, cycle of operation. Applies typically to self-monitoring motorized electro-mechanical equipment, etc. (Null): Unknown, 0: Not Attempted/Not allowed, 1: Single attempt/No retries [allowed], 2-N: [up to] N tries [allowed]</td></tr><tr><td>AuthorizationRemoteStart</td><td>boolean</td><td></td><td>Whether a remote request to start a transaction in the form of RequestStartTransactionRequest message should be authorized beforehand like a local action to start a transaction.</td></tr><tr><td>AvailabilityState</td><td>OptionList</td><td></td><td>A value of ConnectorStatusEnumType (See part 2): replicates ConnectorStatus values reported in StatusNotification messages.</td></tr><tr><td>Available</td><td>boolean</td><td></td><td>The Component exists and is locally configured/wired for use, but might not be (remotely) Enabled.</td></tr><tr><td>BasicAuthPassword</td><td>string</td><td></td><td>The basic authentication password is used for HTTP Basic Authentication.</td></tr><tr><td>BytesPerMessage</td><td>integer</td><td></td><td>Message Size (in bytes) - puts constraint on GetReportRequest, GetMonitoringReportRequest or GetVariableRequest message size.</td></tr><tr><td>CentralContractValidationAllowed</td><td>boolean</td><td></td><td>If this variable exists and has the value true, then Charging Station can provide a contract certificate that it cannot validate, to the CSMS for validation as part of the AuthorizationRequest.</td></tr><tr><td>CertSigningRepeatTimes</td><td>integer</td><td></td><td>This variable can be used to configure the amount of times the Charging Station SHALL double the previous back-off time, starting with the number of seconds configured at CertSigningWaitMinimum, every time the back-off time expires without having received the CertificateSignedRequest containing the from the CSR generated signed certificate.</td></tr><tr><td>CertSigningWaitMinimum</td><td>integer</td><td></td><td>This configuration variable defines how long the Charging Station has to wait before generating another CSR, in the case the CSMS accepts the SignCertificateRequest, but never returns the signed certificate.</td></tr><tr><td>Certificate</td><td>string</td><td></td><td>Digital Certificate (in Base64 encoding)</td></tr><tr><td>CertificateEntries</td><td>integer</td><td></td><td>Amount of Certificates currently installed on the Charging Station.</td></tr><tr><td>CertificateStatusSource</td><td>string</td><td></td><td>When present, this variable tells CSMS whether Charging Station uses OCSP or CRL to check for revoked certificates.</td></tr><tr><td>ChargeProtocol</td><td>string</td><td></td><td>The Charging Control Protocol applicable to a Connector. CHAdeMO: CHAdeMO protocol, ISO15118: ISO15118 V2G protocol (wired or wireless) as used with CCS, CPPWM: IEC61851-1 / SAE J1772 protocol (ELV DC & PWM signalling via Control Pilot wire), Uncontrolled: No charging power management applies (e.g. Schuko socket), Undetermined: Yet to be determined (e.g. before plugged in), Unknown: Not determinable, NOTE: ChargeProtocol is distinct from and orthogonal to connectorType.</td></tr><tr><td>ChargingCompleteBulk</td><td>boolean</td><td></td><td>Charging up to StateOfChargeBulk has completed.</td></tr><tr><td>ChargingCompleteFull</td><td>boolean</td><td></td><td>Charging up to StateOfCharge.maxSet has completed.</td></tr><tr><td>ChargingProfilePersistence</td><td>boolean</td><td></td><td>If an instance of this variable is true, then charging profiles with the chargingProfilePurpose mentioned in the variableInstance are persistent, i.e. they are stored persistently and will still exist after a reboot.</td></tr><tr><td>ChargingState</td><td>OptionList</td><td></td><td>This variable reports the current transaction charging state for an EVSE.</td></tr><tr><td>ChargingTime</td><td>decimal</td><td>s</td><td>Time from earliest to latest substantive energy transfer</td></tr><tr><td>Color</td><td>string</td><td></td><td>Standard 24 bit hexadecimal RGB values. Reg Green Blue color intensity, expressed as standard 24 bit hexadecimal RGB values: 3 00-FF (0-255), in order RRGGBB). E.g. 000000: Black, FF0000: Red, 00FF00: Green, 0000FF: Blue, FFFF00: Yellow, FFFFFF: White, 008000: Medium intensity green.</td></tr><tr><td>CommunicationParent</td><td>string</td><td></td><td>Points to a communication parent component (data flow source), to allow rendering the communication hierarchy in a UI.</td></tr><tr><td>Complete</td><td>boolean</td><td></td><td>Component's operation cycle has completed. Used only in event notifications, where it is always true.</td></tr><tr><td>ConditionsSupported</td><td>boolean</td><td></td><td>If set to true the Charging Station supports tariffs with conditions.</td></tr><tr><td>ConfigurationValueSize</td><td>integer</td><td></td><td>This Configuration Variable can be used to limit the following fields: SetVariableData_attributeValue and VariableCharacteristics.valuesList.</td></tr><tr><td>ConnectedTime</td><td>decimal</td><td>s</td><td>Time since logical connection established</td></tr><tr><td>ConnectorType</td><td>OptionList</td><td></td><td>A value of ConnectorStringEnumType (See Appendix 7). Specific type of connector, including sub-variant information. Note: Distinct and orthogonal to Charging Protocol, Power Type, Phases.</td></tr><tr><td>ContractCertificateInstallationEnabled</td><td>boolean</td><td></td><td>If this variable is true, then ISO 15118 contract certificate installation/update as described by use case M01 - Certificate installation EV</td></tr><tr><td>ContractValidationOffline</td><td>boolean</td><td></td><td>If this variable is true, then Charging Station will try to validate a contract certificate when it is offline.</td></tr><tr><td>Count</td><td>integer</td><td></td><td>General purpose integer count variable for Component state reporting</td></tr><tr><td>CountryName</td><td>string</td><td></td><td>The countryName of the SECC in the ISO 3166-1 format.</td></tr><tr><td>Currency</td><td>string</td><td></td><td>Currency in a ISO 4217 formatted currency code.</td></tr><tr><td>CurrentImbalance</td><td>decimal</td><td>Percent</td><td>Percentage current imbalance in an AC three phase supply.</td></tr><tr><td>CustomImplementationEnabled</td><td>boolean</td><td></td><td>This standard configuration variable is used to enable/disable the custom implementation named in the variableInstance.</td></tr><tr><td>CustomTriggers</td><td>MemberList</td><td></td><td>This variable defines the names of custom triggers that Charging Station supports in a customTrigger field of TriggerMessageRequest.</td></tr><tr><td>DCCurrent</td><td>decimal</td><td>A</td><td>DC Current (in amperes). May be an instantaneous measurement, or a period average, depending on context/equipment.</td></tr><tr><td>DCInputPhaseControl</td><td>boolean</td><td></td><td>When DCInputPhaseControl is true, then the values of numberPhases and PhaseToUse in a ChargingSchedulePeriodType will select the input phases from the grid to be used by the DC EVSE.</td></tr><tr><td>DCVoltage</td><td>decimal</td><td>V</td><td>DC Voltage (volts). May be an instantaneous measurement, or a period average, depending on context/equipment.</td></tr><tr><td>DataText</td><td>string</td><td></td><td>Text associated with a Component, e.g. a Display.</td></tr><tr><td>DateTime</td><td>dateTime</td><td></td><td>Point in time value, in [RFC3339] datetime format. Time zone optional.</td></tr><tr><td>DepartureTime</td><td>dateTime</td><td></td><td>Time in [RFC3339] datetime format, when an EV intends to leave the charging station.</td></tr><tr><td>DisablePostActivate</td><td>boolean</td><td></td><td>When set to true this variable disables the behavior to request authorization for an</td></tr><tr><td>DisableRemoteAuthorization</td><td>boolean</td><td></td><td>When set to true this instructs the Charging Station to not issue any AuthorizationRequests, but only use Authorization Cache and Local Authorization List to determine validity of idTokens.</td></tr><tr><td>DischargePower</td><td>decimal</td><td></td><td>The variableCharacteristic maxLimit holds the maximum rated discharge power that this EVSE can provide. The variableCharacteristic maxSet holds the maximum configured discharge power that this EVSE can provide. The Actual value of the instantaneous (real) discharge power is recommended to be supported, but not required. Discharge power is represented by a positive value.</td></tr><tr><td>DisplayMessages</td><td>integer</td><td></td><td>Maximum number of different messages that can configured in this Charging Station simultaneous, via SetDisplayMessageRequest.</td></tr><tr><td>ECVariant</td><td>string</td><td></td><td>Production series variants reflecting internal design changes or sub-component substitutions not affecting external functionality.</td></tr><tr><td>EVConnectionTimeOut</td><td>integer</td><td>s</td><td>Interval from between 'starting' of a transaction until incipient transaction is automatically canceled, due to failure of EV driver to (correctly) insert the charging cable connector(s) into the appropriate socket(s).</td></tr><tr><td>ElectricalParent</td><td>string</td><td></td><td>Points to a electrical parent component (energy flow source), to allow rendering the electrical hierarchy in a UI.</td></tr><tr><td>Enabled</td><td>boolean</td><td></td><td>The Component is Enabled for operation. For Available components that cannot be selectively (remotely) enabled / disabled, this value is always true. Note: Available cannot be false of Enabled is true, so during inventory reporting, Enabled=1 also logically states Available=true</td></tr><tr><td>Energy</td><td>decimal</td><td>Wh</td><td>Energy quantity (in Wh) for reporting/configuring values related to stored energy (i.e. not transferred energy).</td></tr><tr><td>EnergyCapacity</td><td>decimal</td><td>Wh</td><td>Energy capacity in Wh of an energy storage device.</td></tr><tr><td>EnergyExport</td><td>decimal</td><td>Wh</td><td>Total energy transferred: e.g. from EV during (ongoing or terminated) charging session (in wH by default)</td></tr><tr><td>EnergyExportRegister</td><td>decimal</td><td>Wh</td><td>Cumulative export kWh register value, such as from a (certified) fiscal energy meter.</td></tr><tr><td>Energylimport</td><td>decimal</td><td>Wh</td><td>Total energy transferred.</td></tr><tr><td>EnergyImportRegister</td><td>decimal</td><td>Wh</td><td>Cumulative export kWh register value, such as from a (certified) fiscal energy meter.</td></tr><tr><td>Entries</td><td>integer</td><td></td><td>General purpose variable for reporting/managing numbers of entries in repetitive data structures. maxLimit characteristic reports maximum possible entries.</td></tr><tr><td>ExternalConfigChangeDate</td><td>DateTime</td><td></td><td>Date/time when the configuration was changed externally, i.e. outside of CSMS, for example by a local service action.</td></tr><tr><td>ExternalConstraintsProfileDisallowed</td><td>boolean</td><td></td><td>Indicates whether a Charging Station allows an external system to submit a ChargingStationExternalConstraints charging profile.</td></tr><tr><td>ExternalControlSignalsEnabled</td><td>boolean</td><td></td><td>Indicates whether a Charging Station is able to respond to external control signals that influence charging. If the variable is true, but CSMS has set [configkey-external-constraints-profile-disallowed] = true, then external control signals are only allowed during a charging profile with a chargingProfilePeriod = ExternalLimits or ExternalSetpoint.</td></tr><tr><td>Fallback</td><td>boolean</td><td></td><td>Component is operating in a fallback, or backup mode. In inventory reports, a Value of 1 for the maxLimit characteristic indicates that the component can enter a fallback state (i.e. a fallback mode is present).</td></tr><tr><td>FanSpeed</td><td>decimal</td><td>RPM</td><td>Fan Speed (in RPM). A value of 0 represents stopped/stalled. An empty value indicates that fan speed cannot be read.</td></tr><tr><td>FieldLength</td><td>integer</td><td></td><td>This variable is used to report the length of <field> in <message> when it is larger</td></tr><tr><td>FileTransferProtocols</td><td>MemberList</td><td></td><td>List of supported file transfer protocols.</td></tr><tr><td>FirmwareVersion</td><td>string</td><td></td><td>Version number of firmware.</td></tr><tr><td>Force</td><td>decimal</td><td>N</td><td>Reports (impact) force/ acceleration values (estimates) in one or more directions, in units of Newtons or "g". Multiple force readings in different (orthogonal) dimensions may be reported using Variable instance values, such as Down, Right, Forward.</td></tr><tr><td>Formats</td><td>MemberList</td><td></td><td>List of message formats supported by this Charging Station. Possible values: ASCII, HTML, URI, UTF-8.</td></tr><tr><td>Frequency</td><td>decimal</td><td>Hz</td><td>Frequency of AC power, signal, or component operation.</td></tr><tr><td>FrequencySchedule</td><td>string</td><td></td><td>A JSON-formatted string with an array of {time, freq} pairs, in which time is</td></tr><tr><td>FuseRating</td><td>decimal</td><td>A</td><td>Current rating of a fuse/breaker. Variable instances keyed by phase identifier (L1/L2/L3/N).</td></tr><tr><td>HandleFailedTariff</td><td>OptionList</td><td></td><td>This configuration determines how to act when a driver-specific tariff is received, which cannot be processed.</td></tr><tr><td>HeartbeatInterval</td><td>integer</td><td>s</td><td>Interval of inactivity (no OCPP exchanges) with CSMS after which the Charging Station should send HeartbeatRequest.</td></tr><tr><td>Height</td><td>decimal</td><td>m</td><td>Height above(+)/below(-) reference level (ground level unless context demands otherwise).</td></tr><tr><td>Humidity</td><td>decimal</td><td>RH</td><td>The relative humidity in %.</td></tr><tr><td>Hysteresis</td><td>decimal</td><td>Percent</td><td>Specifies the width of a 'dead band' (as a percentage of the threshold) around the central value of a threshold setting (e.g. MinSet, MaxSet, monitor thresholds) to avoid repeated triggering when the measured quantity lies close to the threshold and is subject to small variations.</td></tr><tr><td>ICCID</td><td>string</td><td></td><td>ICCID (Integrated Circuit Card IDentifier) of mobile data SIM card.</td></tr><tr><td>IMSI</td><td>string</td><td></td><td>IMSI (International Mobile Subscriber Identity) number of mobile data SIM card</td></tr><tr><td>ISO15118Evseld</td><td>string</td><td></td><td>EVSE ID in string format as used in ISO 15118 and IEC 63119-2</td></tr><tr><td>IdToken</td><td>string</td><td></td><td>The IdToken used to authorize a charging transaction.</td></tr><tr><td>Identity</td><td>string</td><td></td><td>The Charging Station identity.</td></tr><tr><td>Impedance</td><td>decimal</td><td>Ohm</td><td>Impedance: Primary value is real (resistive only) impedance. Where a complex impedance is to be reported, the imaginary part (reactance) must be represented with a separate Variable instance value of 'reactance'. Reactance values are expressed at the (nominal) relevant operating frequency of the Component (e.g. 50/60Hz for mains electricity feed).</td></tr><tr><td>Interval</td><td>integer</td><td>s</td><td>Minimum Interval (in seconds) between (attempted) operations.</td></tr><tr><td>ItemsPerMessage</td><td>integer</td><td></td><td>Maximum number of ComponentVariable entries that can be sent in one GetReportRequest or GetMonitoringReportRequest message.</td></tr><tr><td>Label</td><td>string</td><td></td><td>Label for a component. Specifies a non-unique label to be used in a hierarchy UI rendering, in place of the unique component name and instance</td></tr><tr><td>Language</td><td>OptionList</td><td></td><td>Default language code, per RFC 5646, of this Charging Station.</td></tr><tr><td>Length</td><td>decimal</td><td>m</td><td>General Purpose linear distance measure.</td></tr><tr><td>LifeTime</td><td>integer</td><td>s</td><td>Indicates how long it takes until a token expires in the authorization cache since it is last used.</td></tr><tr><td>Light</td><td>decimal</td><td>lx</td><td>(Ambient) light level. The value is in Lux.</td></tr><tr><td>LimitChangeSignificance</td><td>decimal</td><td></td><td>If at the Charging Station side a change in the limit in a ChargingProfile is lower than this percentage, the Charging Station MAY skip sending a NotifyChargingLimitRequest or a TransactionEventRequest message to the CSMS.</td></tr><tr><td>LocalAuthorizationOffline</td><td>boolean</td><td></td><td>Whether the Charging Station, when Offline, will start a transaction for locally-authorized identifiers.</td></tr><tr><td>LocalFrequencyUpdateThreshold</td><td>integer</td><td>mHz</td><td>The amount of change in net frequency in mHz is needed to trigger a recalciulation of the setpoint.</td></tr><tr><td>LocalLoadBalancing</td><td>decimal</td><td></td><td>Variable with instances to control local load-balancing.</td></tr><tr><td>LocalPreAuthorize</td><td>boolean</td><td></td><td>Whether the Charging Station, when online, will start a transaction for locally-authorized identifiers without waiting for or requesting an AuthorizationResponse from the CSMS.</td></tr><tr><td>LogicalParent</td><td>string</td><td></td><td>Points to a logical parent component, to allow rendering a comprehensive overview of the Charging Station components in a UI.</td></tr><tr><td>Manufacturer</td><td>string</td><td></td><td>Component Manufacturer name</td></tr><tr><td>MasterPassGroupId</td><td>string</td><td></td><td>IdTokens that have this id as groupId belong to the Master Pass Group.</td></tr><tr><td>MaxCertificateChainSize</td><td>integer</td><td></td><td>This configuration variable can be used to limit the size of the 'certificateChain' field from the CertificateSignedRequest PDU.</td></tr><tr><td>MaxElements</td><td>integer</td><td></td><td>For TariffCostCtrl: Specifies the maximum number of prices elements that the Charging Station supports in each energy, chargingTime,_ IdleTime and fixedFee of a TariffType.</td></tr><tr><td>MaxEnergyOnInvalidId</td><td>integer</td><td>Wh</td><td>Maximum amount of energy in Wh delivered when an identifier is deauthorized by the CSMS after start of a transaction.</td></tr><tr><td>MaxExternalConstraintsId</td><td>integer</td><td></td><td>Defines the highest value that a charging profile id of a ChargingStationExternalConstraints profile in the Charging Station can have.</td></tr><tr><td>MaxPeriodicEventStreams</td><td>integer</td><td></td><td>The maximum number of open periodic event streams that Charging Station supports.</td></tr><tr><td>MaxPriceElements</td><td>integer</td><td></td><td>For ISO15118Ctrl: The maximum number of priceRuleStacks and priceLevelScheduleEntries that Charging Station is able to accept in a ChargingScheduleType.</td></tr><tr><td>MaxSoc</td><td>integer</td><td></td><td>The maximum state of charge that a battery will be charged to.</td></tr><tr><td>Measurands</td><td>MemberLi st</td><td></td><td>Measurand(s) to be included in MeterValuesRequest or TransactionEventRequest</td></tr><tr><td>Message</td><td>string</td><td></td><td>Specific stored message for display.</td></tr><tr><td>MessageAttemptInterval</td><td>integer</td><td>s</td><td>How long the Charging Station should wait before resubmitting a TransactionEventRequest message that the CSMS failed to process.</td></tr><tr><td>MessageAttempts</td><td>integer</td><td></td><td>How often the Charging Station should try to submit a TransactionEventRequest message when the CSMS fails to process it.</td></tr><tr><td>MessageTimeout</td><td>integer</td><td>s</td><td>The purpose of the message timeout is to be able to consider a request message as not sent and continue with other tasks when the message did not arrive due to communication errors or software failure.</td></tr><tr><td>MinimumStatusDuration</td><td>integer</td><td>s</td><td>Minimum duration that a Charging Station or EVSE status is stable before StatusNotificationRequest is sent to the CSMS.</td></tr><tr><td>Mode</td><td>string</td><td></td><td>Operating mode string from among valid options (communicated by OptionList, etc. during capability/configuration discovery).</td></tr><tr><td>Model</td><td>string</td><td></td><td>Manufacturer's Model code/number of Component, including suffixes etc. to identify functional, regional or linguistic variation, but NOT engineering change level internal variation not affecting external behaviour, etc.</td></tr><tr><td>NetworkAddress</td><td>string</td><td></td><td>Current network address of a Component.</td></tr><tr><td>NetworkConfigurationPriority</td><td>SequenceList</td><td></td><td>A comma separated ordered list of the priority of the possible Network Connection Profiles. The list of possible available profile slots for the network configuration profiles SHALL be reported, via the valuesList characteristic of this Variable.</td></tr><tr><td>NetworkProfileConnectionAttempts</td><td>integer</td><td></td><td>Specifies the number of connection attempts the Charging Station executes before switching to a different profile.</td></tr><tr><td>NextTimeOffsetTransitionDateTime</td><td>DateTime</td><td></td><td>Date time of the next time offset transition. On this date time, the clock displayed to the EV driver will be given the new offset as configured via TimeOffsetNextTransition.</td></tr><tr><td>NonEvseSpecific</td><td>boolean</td><td></td><td>For ReservationCtrl: If this configuration variable is present and set to true: Charging Station supports reservation where EVSE id is not specified.</td></tr><tr><td>NotificationMaxDelay</td><td>integer</td><td>s</td><td>For ISO15118Ctrl: The SECC (EVSE) uses the NotificationMaxDelay element in the EVSEStatus to indicate the time in seconds until it expects the EVCC (EV) to react on the action request indicated in EVSENotification.</td></tr><tr><td>NotifyChargingLimitWithSchedules</td><td>boolean</td><td></td><td>Indicates if the Charging Station should include the externally set charging limit/schedule in the message when it sends a NotifyChargingLimitRequest message.</td></tr><tr><td>NtpServerUri</td><td>string</td><td></td><td>This contains the address of the NTP server.</td></tr><tr><td>NtpSource</td><td>OptionList</td><td></td><td>Use the NTP server provided via DHCP, or use the manually configured NTP server.</td></tr><tr><td>OfflineQueuingSeverity</td><td>integer</td><td></td><td>When set and the Charging Station is offline, the Charging Station shall queue any NotifyEventRequest messages triggered by a monitor with a severity number equal to or lower than the severity configured here.</td></tr><tr><td>OfflineTariffFallbackMessage</td><td>string</td><td></td><td>Message (and/or tariff information) to be shown to an EV Driver when Charging Station is offline.</td></tr><tr><td>OfflineThreshold</td><td>integer</td><td>s</td><td>When the offline period of a Charging Station exceeds the OfflineThreshold it is recommended to send a StatusNotificationRequest for all its Connectors when the Charging Station is back online.</td></tr><tr><td>OfflineTxForUnknownIdEnabled</td><td>boolean</td><td></td><td>If this key exists and is true, the Charging Station supports Unknown Offline Authorization.</td></tr><tr><td>Operated</td><td>boolean</td><td></td><td>The Component operated in an instantaneous, transient, or immediately self-resetting pattern. Used only in event notifications, where it is always true.</td></tr><tr><td>OperatingTimes</td><td>string</td><td></td><td>Recurring operating times in iCalendar RRULE format.</td></tr><tr><td>OrganizationName</td><td>string</td><td></td><td>The organizationName of the CSO operating the charging station.</td></tr><tr><td>Overload</td><td>boolean</td><td></td><td>Component is in Overload state.</td></tr><tr><td>Percent</td><td>decimal</td><td>Percent</td><td>Generic dimensionless value reporting/setting value.</td></tr><tr><td>PeriodsPerSchedule</td><td>integer</td><td></td><td>Maximum number of periods that may be defined per ChargingSchedule.</td></tr><tr><td>PhaseRotation</td><td>string</td><td></td><td>This variable describes the phase rotation of a Component relative to its parent Component, using a</td></tr><tr><td>Phases3to1</td><td>boolean</td><td></td><td>If defined and true, this Charging Station supports switching from 3 to 1 phase during a transaction.</td></tr><tr><td>PhysicalParent</td><td>string</td><td></td><td>Points to a physical parent component (container), to allow rendering an overview of the Charging Station component locations in a UI.</td></tr><tr><td>PnCEnabled</td><td>boolean</td><td></td><td>If this variable is true, then ISO 15118 plug and charge as described by use case C07 - Authorization using Contract Certificates is enabled.</td></tr><tr><td>Policy</td><td>OptionList</td><td></td><td>Cache Entry Replacement Policy: least recently used, least frequently used, first in first out, other custom mechanism.</td></tr><tr><td>PostChargingTime</td><td>decimal</td><td>s</td><td>Elapsed time in seconds since last substantive energy transfer</td></tr><tr><td>Power</td><td>decimal</td><td>W,kW</td><td>Instantaneous (real) Power (measured/calculated, including power factor for AC). Where a component (e.g. AC to DC Power Converter) has multiple power measurements, the default (unkeyed) instance is "input" power.</td></tr><tr><td>Present</td><td>boolean</td><td></td><td>Component exists, but might not be locally configured/wired for use, nor (remotely) Enabled.</td></tr><tr><td>Problem</td><td>boolean</td><td></td><td>Component itself has a 'Problem' condition that impacts in any significant way on its normal operation. By definition, 'Problem' state includes (logical OR)'Fault' state. 'Problem' specifically INCLUDES inability to operate that is propagated (up/down/sideways) from any other associated/connected/containing/contained Component.</td></tr><tr><td>ProfileStackLevel</td><td>integer</td><td></td><td>Maximum acceptable value for stackLevel/ in a ChargingProfile.</td></tr><tr><td>Protecting</td><td>boolean</td><td></td><td>Applies to 'sensor' type Components that have an associated protection capability, whereby they can disconnect power (e.g. using the main PowerContactor) if the sensed quantity is outside preset/configured limits. If Protecting is true, the Component is actively preventing/interrupting charging.</td></tr><tr><td>ProtocolAgreed</td><td>string</td><td></td><td>For ConnectedEV: 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.</td></tr><tr><td>ProtocolSupported</td><td>string</td><td></td><td>For ISO15118Ctrl: A string with the following comma-separated items:<uri>,<major>,<minor>. <uri> is in the format as used in the SupportedAppProtocolReq message from ISO 15118-2 and ISO 15118-20. This variable has at most 20 instances, one for each supported protocol version.</td></tr><tr><td>ProtocolSupportedByEV</td><td>string</td><td></td><td>For ConnectedEV: 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.</td></tr><tr><td>PublicKey</td><td>string</td><td></td><td>Configuration variable that can be used to retrieve the public key for a meter connected to a specific EVSE.</td></tr><tr><td>PublicKeyWithSignedMeterValue</td><td>boolean</td><td></td><td>This Configuration Variable can be used to configure whether a public key needs to be sent with a signed meter value.</td></tr><tr><td>QueueAllMessages</td><td>boolean</td><td></td><td>When this variable is set to true, the Charging Station will queue all message until they are delivered to the CSMS.</td></tr><tr><td>RateUnit</td><td>string</td><td></td><td>A list of supported quantities (A, W) for use in a ChargingSchedule.</td></tr><tr><td>RegisterValuesWithoutPhases</td><td>boolean</td><td></td><td>If this variable reports a value of true, then meter values of measurand Energy. Active. Import. Register will only report the total energy over all phases without reporting the individual phase values.</td></tr><tr><td>RemainingTimeBulk</td><td>integer</td><td>s</td><td>Number of seconds remaining to charge to bulk state of charge, given by StateOfChargeBulk.</td></tr><tr><td>RemainingTimeFull</td><td>integer</td><td>s</td><td>Number of seconds remaining to charge to 100% state of charge.</td></tr><tr><td>ReportingValueSize</td><td>integer</td><td></td><td>This Configuration Variable can be used to limit the following fields: GetVariableResult.value, VariableAttribute.value and EventData(actualValue.</td></tr><tr><td>RequestMeteringReceipt</td><td>boolean</td><td></td><td>For ISO15118Ctrl: If this variable is true, then Charging Station shall request a metering receipt</td></tr><tr><td>ResetRetries</td><td>integer</td><td></td><td>Number of times to retry a reset of the Charging Station when a reset was unsuccessful.</td></tr><tr><td>ResumptionTimeout</td><td>integer</td><td>s</td><td>This variable defines the maximum number of seconds that a transaction may be interrupted by a power outage and still be resumed afterwards.</td></tr><tr><td>SampledMeasurands</td><td>MemberList</td><td></td><td>The set of measurands to be sampled by the DataCollector component.</td></tr><tr><td>SamplingInterval</td><td>decimal</td><td>s</td><td>The sampling interval in seconds.</td></tr><tr><td>Seccdld</td><td>string</td><td></td><td>The name of the SECC in the string format as required by ISO 15118.</td></tr><tr><td>SecurityProfile</td><td>integer</td><td></td><td>This configuration variable is used to report the security profile used by the Charging Station.</td></tr><tr><td>SendDuringIdle</td><td>boolean</td><td></td><td>For AlignedDataCtrl: If set to true, the Charging Station SHALL only send clock aligned meter values when there is no transaction ongoing.</td></tr><tr><td>SerialNumber</td><td>string</td><td></td><td>Serial number of Component.</td></tr><tr><td>ServiceRenegotiationSupport</td><td>boolean</td><td></td><td>For ISO15118Ctrl: If set to 'True' the SECC (EVSE) is capable of ServiceRenegotiation.</td></tr><tr><td>SetpointPriority</td><td>OptionList</td><td></td><td>Defines which setpoint shall be used when a ChargingStationExternalConstraints profile</td></tr><tr><td>SignReadings</td><td>boolean</td><td></td><td>If set to true, the Charging Station SHALL include signed meter values in the TransactionEventRequest(Ended).</td></tr><tr><td>SignStartedReadings</td><td>boolean</td><td></td><td>If set to true, the Charging Station SHALL include signed meter values for context = Transaction.Begin in the metervalues field in the TransactionEventRequest(Started or Updated).</td></tr><tr><td>SignUpdatedReadings</td><td>boolean</td><td></td><td>If set to true, the Charging Station SHALL include signed meter values in the metervalues field in the TransactionEventRequest(Updated).</td></tr><tr><td>SignalStrength</td><td>decimal</td><td>dBm</td><td>(Radio/Wired/Optical) data signal strength, in ASU (typically 0-31 or 99 for unknown). Or dbmw (typically -140 to -50).</td></tr><tr><td>SlotStatus</td><td>OptionList</td><td></td><td>This variable represents the status of the door of the battery slot.</td></tr><tr><td>SoC</td><td>integer</td><td>Percent</td><td>SoC of the component BatteryCartridge which refers to the battery that is inserted at the EVSE.</td></tr><tr><td>SoH</td><td>integer</td><td>Percent</td><td>SoH of the component BatteryCartridge which refers to the battery that is inserted at the EVSE.</td></tr><tr><td>State</td><td>string</td><td></td><td>A state code or name identifier string, to allow the internal state of components to be reported and/or controlled</td></tr><tr><td>StateOfCharge</td><td>decimal</td><td>Percent</td><td>Energy Storage Device (e.g. battery) state of charge, expressed as a percentage of nominal design 0-100% operating range. The value of StateOfCharge.maxSet represents the maximum state of charge for a full battery and is usually at or near 100%.</td></tr><tr><td>StateOfChargeBulk</td><td>decimal</td><td>Percent</td><td>Energy Storage Device (e.g. battery) state of charge up to which fast charging is possible. Above this percentage charging speed will drop significantly.</td></tr><tr><td>StopTxOnEVSideDisconnect</td><td>boolean</td><td></td><td>When set to true, the Charging Station SHALL deauthorize the transaction when the cable is unplugged from the EV.</td></tr><tr><td>StopTxOnInvalidId</td><td>boolean</td><td></td><td>Whether the Charging Station will deauthorize an ongoing transaction when it receives a non-Accepted authorization status in TransactionEventResponse for this transaction.</td></tr><tr><td>Storage</td><td>integer</td><td>B</td><td>In bytes. Amount of storage occupied. Storage(maxLimit) specifies absolute limit Storage(MaxSet) restricts usage to specified Max, if supported.</td></tr><tr><td>SupplyPhases</td><td>integer</td><td></td><td>Number of alternating current phases connected/available. 1 or 3 for AC, 0 means DC (no alternating phases). Null value indicates that the number of phases (e.g. in use) is unknown.</td></tr><tr><td>SupportedAdditionalPurposes</td><td>MemberLi st</td><td></td><td>This configuration variable lists the additional charging profile purposes, that have been introduced in OCPP 2.1, that are supported by the Charging Station.</td></tr><tr><td>SupportedEnergyTransferModes</td><td>MemberLi st</td><td></td><td>Lists the energy transfer services that are supported by the Charging Station.</td></tr><tr><td>SupportedFormats</td><td>MemberLi st</td><td></td><td>For DisplayMessageCtrl: List of message formats supported by this Charging Station.</td></tr><tr><td>SupportedIdTokenTypes</td><td>MemberLi st</td><td></td><td>The subset of the list of supported IdTokenTypes as defined in Appendix 7.</td></tr><tr><td>SupportedLimits</td><td>MemberLi st</td><td></td><td>This variable defines which transaction limits in TransactionLimitType are supported by the Charging Station.</td></tr><tr><td>SupportedOperationModes</td><td>MemberLi st</td><td></td><td>Lists the V2X operation modes that are supported by the Charging Station.</td></tr><tr><td>SupportedPriorities</td><td>MemberLi st</td><td></td><td>For DisplayMessageCtrl: List of the priorities supported by this Charging Station.</td></tr><tr><td>SupportedProviders</td><td>string</td><td></td><td>A comma-separated list of all providers (eMSPs) that are supported on this Charging Station. The providers are listed using country and provider ID from the EMAIL, as defined in ISO 15118-20.</td></tr><tr><td>SupportedStates</td><td>MemberLi st</td><td></td><td>For DisplayMessageCtrl: List of the states during which to display a message supported by this Charging Station.</td></tr><tr><td>SupportsDynamicProfiles</td><td>boolean</td><td></td><td>When this variable has value True, then the Charging Station supports charging profiles of type Dynamic.</td></tr><tr><td>SupportsEvseSleep</td><td>boolean</td><td></td><td>When reported as true the Charging Station supports the evseSleep flag in a ChargingSchedulePeriod, which requests the EVSE electronics to go to sleep during operationMode = 'Idle'.</td></tr><tr><td>SupportsExpiryDateTime</td><td>boolean</td><td></td><td>For LocalAuthListCtrl: 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.</td></tr><tr><td>SupportsLimitAtSoC</td><td>boolean</td><td></td><td>When this variable has value True, then the Charging Station supports the field limitAtSoC in ChargingSchedule, which will cap the limit or setpoint in the ChargingSchedulePeriodType by the value of limitAtSoC-limit.</td></tr><tr><td>SupportsMaxOfflineDuration</td><td>boolean</td><td></td><td>When this variable has value True, then the Charging Station supports the fields maxOfflineDuration and invalidAfterOfflineDuration in ChargingProfile.</td></tr><tr><td>SupportsRandomizedDelay</td><td>boolean</td><td></td><td>When this variable has value True, then the Charging Station supports the field randomizedDelay in ChargingSchedule, which will delay the start of each charging schedule period by a random number between 0 and randomizedDelay.</td></tr><tr><td>SupportsUseLocalTime</td><td>boolean</td><td></td><td>When this variable has value True, then the Charging Station supports the field useLocalTime in ChargingSchedule.</td></tr><tr><td>SUSpending</td><td>boolean</td><td></td><td>If Suspending is true, the Component can is currently suspending charging.</td></tr><tr><td>Suspension</td><td>boolean</td><td></td><td>Applies to 'sensor' type Components that have a charging suspension capability, typically for safety or equipment protection reasons. If Suspension is true, the component can suspend charging when the sensed quantity is outside preset/configured limits.</td></tr><tr><td>TargetSoc</td><td>integer</td><td>Percent</td><td>For BatterySwapCtrl: The state of charge that a battery must have in order to be eligible for swapping.</td></tr><tr><td>TariffFailbackMessage</td><td>string</td><td></td><td>Message (and/or tariff information) to be shown to an EV Driver when there is no driver specific tariff information available.</td></tr><tr><td>Temperature</td><td>decimal</td><td>Celsius, Fahrenheit</td><td>Temperature(s) of component (in Celsius, by default). Components may have multiple indexed temperature sensors.</td></tr><tr><td>Time</td><td>dateTime</td><td></td><td>Point in time value, in ISO 8601 datetime format. Time zone optional.</td></tr><tr><td>TimeAdjustmentReportingThresholdId</td><td>integer</td><td>s</td><td>When the clock time is adjusted forwards or backwards for more than TimeAdjustmentReportingThreshold number of seconds, a SecurityEventNotification('SettingSystemTime') is sent by the charging station.</td></tr><tr><td>TimeOffset</td><td>string</td><td></td><td>A Time Offset with respect to Coordinated Universal Time (aka UTC or Greenwich Mean Time) in the form of an [RFC3339] time (zone) offset suffix, including the mandatory "+" or "-" prefix.</td></tr><tr><td>TimeSource</td><td>SequenceL ist</td><td></td><td>Via this variable, the Charging Station provides the CSMS with the option to configure a clock source.</td></tr><tr><td>TimeZone</td><td>string</td><td></td><td>Configured current local time zone in the format: 'Europe/Oslo', 'Asia/Singapore' etc.</td></tr><tr><td>Timeout</td><td>decimal</td><td>s</td><td>Generic timeout value for Component operation (in seconds).</td></tr><tr><td>Timeout</td><td>integer</td><td>s</td><td>For BatterySwapCtrl: Timeout in seconds in which a set of batteries must be inserted or removed after successful authorization.</td></tr><tr><td>Token</td><td>string</td><td></td><td>String of bytes representing an ID token.</td></tr><tr><td>TokenType</td><td>OptionList</td><td></td><td>Type of Token. Value is one of IdTokenEnumStringType (See Appendix 7).</td></tr><tr><td>TotalCostFallbackMessage</td><td>string</td><td></td><td>Message to be shown to an EV Driver when the Charging Station cannot retrieve the cost for a transaction at the end of the transaction.</td></tr><tr><td>Tries</td><td>integer</td><td></td><td>Number of attempts done by a Component.</td></tr><tr><td>Tripped</td><td>boolean</td><td></td><td>Single-shot device requires explicit intervention to re-prime/activate to normal.</td></tr><tr><td>TxBeforeAcceptedEnabled</td><td>boolean</td><td></td><td>With this configuration variable the Charging Station can be configured to allow charging before having received a BootNotificationResponse with status: Accepted.</td></tr><tr><td>TxEndInterval</td><td>integer</td><td>s</td><td>Interval between sampling of metering (or other) data, intended to be transmitted in the TransactionEventRequest(Ended) message.</td></tr><tr><td>TxEndedMeasurands</td><td>MemberLi st</td><td></td><td>Sampled measurands to be included in the meterValues element of TransactionEventRequest(Ended).</td></tr><tr><td>TxStartPoint</td><td>MemberLi st</td><td></td><td>Start points for a transaction.</td></tr><tr><td>TxStartedMeasurands</td><td>MemberLi st</td><td></td><td>Sampled measurands to be included in the meterValues element of TransactionEventRequest(Started).</td></tr><tr><td>TxStopPoint</td><td>MemberLi st</td><td></td><td>Stop points of a transaction.</td></tr><tr><td>TxUpdatedInterval</td><td>integer</td><td>s</td><td>Interval between sampling of metering (or other) data, intended to be transmitted in the TransactionEventRequest(Updated) message.</td></tr><tr><td>TxUpdatedMeasurands</td><td>MemberLi st</td><td></td><td>Sampled measurands to be included in the meterValues element of TransactionEventRequest(Updated).</td></tr><tr><td>UnlockOnEVSideDisconnect</td><td>boolean</td><td></td><td>When set to true, the Charging Station SHALL unlock the cable on the Charging Station side when the cable is unplugged at the EV.</td></tr><tr><td>UpstreamInterval</td><td>integer</td><td>s</td><td>Interval between sampling of metering (or other) data, intended to be transmitted via TransactionEventRequest(Updated) messages for location = Upstream only.</td></tr><tr><td>UpstreamMeasurands</td><td>MemberLi st</td><td></td><td>Sampled measurands to be included in the meterValues element of every TransactionEventRequest(Updated) for location = Upstream only.</td></tr><tr><td>V2GCertificatesInstallationEnabled</td><td>boolean</td><td></td><td>If this variable is true, then ISO 15118 V2G Charging Station certificate installation as described by use case A02 - Update Charging Station Certificate by request of CSMS</td></tr><tr><td>VehicleCertificate</td><td>string</td><td></td><td>For ConnectedEV: The PEM encoded X.509 leaf/intermediate/root certificate when present in the vehicle certificate chain.</td></tr><tr><td>VehicleId</td><td>string</td><td></td><td>For ConnectedEV: EVCCID from ISO 15118 or CHAdeMO.</td></tr><tr><td>VehicleId</td><td>string</td><td></td><td>ID that EV provides to charging station. Encoded as a hexbinary string. In ISO 15118 the EVCCID is 6 bytes (MAC address), in CHAdeMO the vehicle id can be 24 bytes.</td></tr><tr><td>VersionDate</td><td>dateTime</td><td></td><td>[RFC3339]</td></tr><tr><td>VersionNumber</td><td>string</td><td></td><td>Version number of hardware</td></tr><tr><td>VoltageImbalance</td><td>decimal</td><td>Percent</td><td>Percentage voltage imbalance in three phase supply.</td></tr><tr><td>WorkingMode</td><td>OptionList</td><td></td><td>This variable represents the current working mode of the battery in BatteryCartridge component.</td></tr></table>
+
+# Chapter 5. Reason Codes
+
+The table below provides a list of standardized reason codes that can be used in the optional statusInfo element (of type StatusInfoType) of a response.
+
+For each reason code, some messages that might typically return them are shown. This is not an exhaustive list and only indicative.
+
+StatusInfo is optional. Any implementation should be able to function properly without statusInfo, because every message has the response code values that are essential to perform the function. The reasonCode and additionalInfo in StatusInfoType are meant to provide more insight on what is happening and maybe allow for some automatic recovery.
+
+The grouping of the reasonCodes in the table below is only to make it easier to look-up codes for certain situations. The grouping does not affect the meaning of the reasonCode.
+
+# IMPORTANT
+
+The existence of a reason code in this table does not imply a requirement to use it nor does it imply a requirement to any of the mentioned messages.
+
+(Updated in v2.0)
+
+<table><tr><td>Group</td><td>Reason code</td><td>Description</td><td>Typically used for</td></tr><tr><td>Charging Profiles</td><td></td><td></td><td></td></tr><tr><td></td><td>DuplicateProfile</td><td>A charging profile with same stackLevel - chargingProfilePurpose combination already exists on the Charging Station and has an overlapping validity period.</td><td>SetChargingProfile</td></tr><tr><td></td><td>InvalidProfile</td><td>Provided chargingProfile contains invalid elements.</td><td>SetChargingProfile, RequestStartTransaction</td></tr><tr><td></td><td>InvalidProfileId</td><td>Provided chargingProfile has an id that is within an invalid range.</td><td>SetChargingProfile, RequestStartTransaction</td></tr><tr><td></td><td>InvalidSchedule</td><td>Provided chargingSchedule contains invalid elements.</td><td>SetChargingProfile, RequestStartTransaction</td></tr><tr><td></td><td>InvalidStackLevel</td><td>Provided value for stackLevel is invalid.</td><td>SetChargingProfile</td></tr><tr><td></td><td>NoFreqWattCurve</td><td>A frequency-watt curve is missing in a charging schedule period with operation mode = LocalFrequency.</td><td>SetChargingProfile</td></tr><tr><td></td><td>NoPhaseForDC</td><td>Phase selection for a DC EVSE is not supported</td><td>SetChargingProfile</td></tr><tr><td></td><td>NoSignalWattCurve</td><td>A signal-watt curve is missing in a charging schedule period when an AFRRSignalRequest is received.</td><td>AFRRSignal</td></tr><tr><td></td><td>RateLimitExceeded</td><td>A charging profile of the same purpose is submitted too frequently</td><td>SetChargingProfile</td></tr><tr><td></td><td>UnsupportedKind</td><td>The requested charging profile kind is not supported</td><td>SetChargingProfile</td></tr><tr><td></td><td>UnsupportedPurpose</td><td>The requested charging profile purpose is not supported</td><td>SetChargingProfile</td></tr><tr><td></td><td>UnsupportedRateUnit</td><td>A chargingRateUnit is provided that is not supported.</td><td>SetChargingProfile</td></tr><tr><td>Charging Station</td><td></td><td></td><td></td></tr><tr><td></td><td>CSNotAccepted</td><td>BootNotification of Charging Station has not (yet) been accepted by CSMS.</td><td>RequestStartTransaction, RequestStopTransaction</td></tr><tr><td></td><td>FixedCable</td><td>The connector has its own fixed cable that cannot be unlocked.</td><td>UnlockConnector</td></tr><tr><td></td><td>NoCable</td><td>No cable is connected at this time.</td><td>UnlockConnector</td></tr><tr><td></td><td>UnknownConnectorId</td><td>Connector Id is not known on EVSE</td><td>ChangeAvailability, UnlockConnector</td></tr><tr><td></td><td>UnknownConnectorType</td><td>Connector type is not known on EVSE</td><td>ReserveNow</td></tr><tr><td></td><td>UnknownEvse</td><td>EVSE is not known on Charging Stations</td><td>ChangeAvailability, ReserveNow, RequestStartTransaction</td></tr><tr><td>Swap Station</td><td></td><td></td><td></td></tr><tr><td></td><td>BatterySoHLow</td><td>Battery State of Health is too low</td><td>BatterySwap</td></tr><tr><td></td><td>BatterySoC</td><td>Battery State of Charge has unacceptable value</td><td>BatterySwap</td></tr><tr><td></td><td>BatteryDamaged</td><td>Battery is damaged</td><td>BatterySwap</td></tr><tr><td></td><td>BatteryUnknown</td><td>Battery has unknown serial number</td><td>BatterySwap</td></tr><tr><td></td><td>BatteryType</td><td>Battery type not accepted</td><td>BatterySwap</td></tr><tr><td></td><td>NoBatteryAvailable</td><td>No battery available for swapping</td><td>BatterySwap,RequestBatterySwap</td></tr><tr><td>Miscellaneous</td><td></td><td></td><td></td></tr><tr><td></td><td>DuplicateRequestId</td><td>A requestId is provided, that has already been used for this type of request.</td><td>UpdateFirmware,PublishFirmware and requests for reports.</td></tr><tr><td></td><td>InvalidMessageSeq</td><td>Message should not be sent at this moment in current scenario.</td><td>(generic), SetChargingProfile with ISO15118</td></tr><tr><td></td><td>MissingDevModelInfo</td><td>Information needed for operation is missing from Device Model</td><td>(generic)</td></tr><tr><td></td><td>NoError</td><td>No error has occurred, but some extra information is in additionInfo .</td><td>(generic)</td></tr><tr><td></td><td>NotFound</td><td>No object(s) found that match a provided ID or criteria.</td><td>ClearVariableMonitoring, CustomerInformation, GetChargingProfiles, GetDisplayMessages, GetInstalledCertificates, GetReport</td></tr><tr><td></td><td>Unspecified</td><td>No reason is specified, but some extra information is in additionInfo</td><td>(generic)</td></tr><tr><td></td><td>UnsupportedRequest</td><td>This request is not supported.</td><td>(generic)</td></tr><tr><td>Operations and Permissions</td><td></td><td></td><td></td></tr><tr><td></td><td>FwUpdateInProgress</td><td>Operation is not possible, because a firmware update is in progress.</td><td>Reset</td></tr><tr><td></td><td>NotEnabled</td><td>Feature is not enabled.</td><td>ClearCache</td></tr><tr><td></td><td>ReadOnly</td><td>Targeted variable is read-only and cannot be set.</td><td>SetVariables</td></tr><tr><td></td><td>WriteOnly</td><td>Targeted variable is write-only and cannot be read.</td><td>GetVariables</td></tr><tr><td>Security</td><td></td><td></td><td></td></tr><tr><td></td><td>InvalidCSR</td><td>Provided CSR is invalid</td><td>SignCertificate</td></tr><tr><td></td><td>InvalidCertificate</td><td>Provided certificate is invalid.</td><td>CertificateSigned, InstallCertificate</td></tr><tr><td></td><td>InvalidURL</td><td>Provided URL is invalid.</td><td>UpdateFirmware, PublishFirmware</td></tr><tr><td></td><td>RedirectNotAllowed</td><td>HTTP Redirection is not allowed</td><td>LogStatusNotification</td></tr><tr><td>System Errors</td><td></td><td></td><td></td></tr><tr><td></td><td>InternalError</td><td>Operation cannot be completed due to an internal error.</td><td>(generic)</td></tr><tr><td></td><td>OutOfMemory</td><td>Operation not possible, because system does not have enough memory.</td><td>(generic)</td></tr><tr><td></td><td>OutOfStorage</td><td>Operation not possible, because system does not have enough storage.</td><td>(generic)</td></tr><tr><td>Transactions</td><td></td><td></td><td></td></tr><tr><td></td><td>InvalidldToken</td><td>Provided idToken is not valid.</td><td>RequestStartTransaction</td></tr><tr><td></td><td>TxInProgress</td><td>A transaction is in progress.</td><td>ChangeAvailability, Reset, RequestStartTransaction</td></tr><tr><td></td><td>TxNotFound</td><td>There is no such transaction.</td><td>RequestStopTransaction, SetChargingProfile, GetVehicleCertificate</td></tr><tr><td></td><td>TxStarted</td><td>A transaction had already started (e.g. due to cable being plugged in).</td><td>RequestStartTransaction</td></tr><tr><td>Values and Ranges</td><td></td><td></td><td></td></tr><tr><td></td><td>InvalidValue</td><td>An invalid value has been provided.</td><td>(generic)</td></tr><tr><td></td><td>MissingParam</td><td>A parameter that is required for the request is missing.</td><td>(generic)</td></tr><tr><td></td><td>TooLargeElement</td><td>Provided element is too large to handle.</td><td>CertificateSigned, InstallCertificate</td></tr><tr><td></td><td>TooManyElements</td><td>Too many elements have been provided.</td><td>SetChargingProfile, SetVariables, SendLocalList</td></tr><tr><td></td><td>UnsupportedParam</td><td>A parameter was provided that is not supported.</td><td>(generic)</td></tr><tr><td></td><td>ValueOutOfRange</td><td>Provided value is out of range.</td><td>SetVariables, SetVariableMonitoring</td></tr><tr><td></td><td>ValuePositiveOnly</td><td>Provided value is not greater than zero.</td><td>(generic)</td></tr><tr><td></td><td>ValueTooHigh</td><td>Provided value is too high.</td><td>(generic)</td></tr><tr><td></td><td>ValueTooLow</td><td>Provided value is too low.</td><td>(generic)</td></tr><tr><td></td><td>ValueZeroNotAllowed</td><td>Provided value cannot be zero.</td><td>(generic)</td></tr></table>
+
+# Chapter 6. Standardized additionalInfo types
+
+(Updated in v2.0)
+
+Standardized and recommended names (types) for idToken(additionalInfo that can be used to provide additional information related to an ID token. For interoperability reasons, these types must be used if the data to be transmitted matches the description.
+
+additionalInfo consists of:
+
+- Token.additionalInfo.type: specifies the type of content
+- Token.additionalInfo(additionalIdToken: specifies the value
+
+# 6.1. Generic
+
+AdditionalInfo fields can be used to provide additional information about an RFID card.
+
+<table><tr><td>additionalInfo.type</td><td>Description</td></tr><tr><td>EVCCID</td><td>The EVCCID of EV is added as additionInfo to an idToken for ISO 15118-20 sessions.</td></tr><tr><td>ISO14443SubType</td><td>The subtype of an ISO 14443 RFID card. For example: 'VDE-AR-E-2532-100' (a secure variant of ISO 14443).</td></tr></table>
+
+# 6.2. Ad hoc payment
+
+A number of AdditionalInfo fields are prescribed to be used for ad hoc payment (use case C18). The configuration variable PaymentCtrlPaymentDetails determines which values the payment terminal provides that need to be included in idToken(additionalInfo for an ad hoc authorization.
+
+<table><tr><td>additionalInfo.type</td><td>Description</td></tr><tr><td>PspRef</td><td>Payment Service Provider reference id for payment session. Only use when PspRef is not in idToken.</td></tr><tr><td>SessionRef</td><td>Payment session reference id from terminal (not the same as pspRef)</td></tr><tr><td>MerchantRef</td><td>Merchant (CSO) reference id for payment session</td></tr><tr><td>PaymentBrand</td><td>Brand of ad hoc payment card. See predefined list of values in table below.</td></tr><tr><td>ReadingMethod</td><td>Contactless / Contact / Magstripe</td></tr><tr><td>PaymentRecognition</td><td>Credit/debit card or digital wallet. See predefined list of values in table below.</td></tr><tr><td>CardBin</td><td>Card first 6 digits</td></tr><tr><td>CardLast4Digits</td><td>Card last 4 digits</td></tr><tr><td>CardExpiryDate</td><td>The expiry date of the card. Format: YYYY/MM</td></tr><tr><td>HashedCardNr</td><td>The hashed card number.</td></tr><tr><td>WalletUserId</td><td>User ID for a digital wallet, e.g. Alipay.</td></tr></table>
+
+# 6.2.1. Predefined values for PaymentBrand
+
+<table><tr><td>PaymentBrand</td><td>Description</td></tr><tr><td>AMEX</td><td></td></tr><tr><td>ApplePay</td><td></td></tr><tr><td>Bancontact</td><td></td></tr><tr><td>BankAxept</td><td></td></tr><tr><td>Carnet</td><td></td></tr><tr><td>CartesBancaires</td><td></td></tr><tr><td>Dankort</td><td></td></tr><tr><td>Diners</td><td></td></tr><tr><td>Discover</td><td></td></tr><tr><td>EftposAustralia</td><td></td></tr><tr><td>Elo</td><td></td></tr><tr><td>Girocard</td><td></td></tr><tr><td>GooglePay</td><td></td></tr><tr><td>Hipercard</td><td></td></tr><tr><td>Interac</td><td></td></tr><tr><td>JCB</td><td></td></tr><tr><td>Maestro</td><td></td></tr><tr><td>Mastercard</td><td></td></tr><tr><td>SamsungPay</td><td></td></tr><tr><td>UnionPay</td><td></td></tr><tr><td>VPay</td><td></td></tr><tr><td>Visa</td><td></td></tr></table>
+
+# 6.2.2. Predefined values for PaymentRecognition
+
+<table><tr><td>PaymentRecognition</td><td>Description</td></tr><tr><td>CC</td><td>Credit card</td></tr><tr><td>Debit</td><td>Debit card</td></tr><tr><td>Alipay</td><td></td></tr><tr><td>ApplePay</td><td></td></tr><tr><td>GooglePay</td><td></td></tr><tr><td>GrabPay</td><td></td></tr><tr><td>PayPal</td><td></td></tr><tr><td>SamsungPay</td><td></td></tr><tr><td>WeChatPay</td><td></td></tr></table>
+
+# Chapter 7. Standardized values for enumerations as string
+
+# 7.1. IdTokenEnumStringType
+
+Standardized values for idToken.type.
+
+Before OCPP 2.1 this used to be an enumeration. This has been changed to a predefined set of strings for more flexibility.
+
+(Updated in v2.0)
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>Central</td><td>A centrally, in the CSMS (or other server) generated id (for example used for a remotely started transaction that is activated by SMS). No format defined, might be a UUID.</td></tr><tr><td>DirectPayment</td><td>IdToken from a payment terminal that authorized a payment card. Usually a reference id from payment service provider.</td></tr><tr><td>eMAID</td><td>Electro-mobility account id as defined in ISO 15118</td></tr><tr><td>EVCCID</td><td>EVCCID of EV. For ISO 15118-2 this is the MAC address. For ISO 15118-20 this is an identifier up to 255 characters.</td></tr><tr><td>ISO14443</td><td>ISO 14443 UID of RFID card. It is represented as an array of 4 or 7 bytes in hexadecimal representation.</td></tr><tr><td>ISO15693</td><td>ISO 15693 UID of RFID card. It is represented as an array of 8 bytes in hexadecimal representation.</td></tr><tr><td>KeyCode</td><td>A private key-code to authorize a charging transaction. For example: Pin-code.</td></tr><tr><td>Local</td><td>A locally generated id (e.g. internal id created by the Charging Station). Needs no checking by CSMS. No format defined, might be a UUID</td></tr><tr><td>MacAddress</td><td>MacAddress of the EVCC (Electric Vehicle Communication Controller) that is connected to the EVSE. Used when MAC address is used for authorization (Autocharge).</td></tr><tr><td>NoAuthorization</td><td>Transaction is started and no authorization possible. Charging Station only has a start button or mechanical key etc. IdToken field SHALL be left empty.</td></tr><tr><td>VIN</td><td>Vehicle Identification Number of EV.</td></tr></table>
+
+# 7.2. ChargingLimitSourceEnumstringType
+
+Standardized values for a chargingLimitSource field.
+
+Before OCPP 2.1 this used to be an enumeration. This has been changed to a predefined set of strings for more flexibility.
+
+(Updated in v2.0)
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>EMS</td><td>Indicates that an Energy Management System has sent a charging limit.</td></tr><tr><td>Other</td><td>Indicates that an external source, not being an EMS or system operator, has sent a charging limit.</td></tr><tr><td>SO</td><td>Indicates that a System Operator (DSO or TSO) has sent a charging limit.</td></tr><tr><td>CSO</td><td>Indicates that the CSO has set this charging profile.</td></tr></table>
+
+# 7.3. ConnectorEnumstringType
+
+Standardized values for a connectorType field.
+
+- Fixed cable connections have a name that starts with "c" for captive cabled.
+- Socket connections have a name that starts with "s" for socket.
+- Wireless connections have a name that starts with "w" for wireless.
+- Swappable battery types have a name that starts with "b" for battery.
+
+Before OCPP 2.1 this used to be an enumeration. This has been changed to a predefined set of strings for more flexibility.
+
+(Updated in v2.0)
+
+<table><tr><td>Value</td><td>Description</td></tr><tr><td>cCCS1</td><td>Combined Charging System 1 (captive cabled) a.k.a. Combo 1</td></tr><tr><td>cCCS2</td><td>Combined Charging System 2 (captive cabled) a.k.a. Combo 2</td></tr><tr><td>cChaoJi</td><td>ChaoJi (captive cabled) a.k.a. CHAdeMO 3.0</td></tr><tr><td>cG105</td><td>JARI G105-1993 (captive cabled) a.k.a. CHAdeMO (captive cabled)</td></tr><tr><td>cGBT-DC</td><td>GB/T 20234.3 DC connector (captive cabled)</td></tr><tr><td>cLECCS</td><td>Light Equipment Combined Charging System IS17017 (captive cabled)</td></tr><tr><td>cMCS</td><td>Megawatt Charging System (captive cabled)</td></tr><tr><td>cNACS</td><td>North American Charging Standard J3400 (captive cabled)</td></tr><tr><td>cNACS-CCS1</td><td>Tesla MagicDock with built-in NACS to CCS1 adapter (captive cabled)</td></tr><tr><td>cCCS1-NACS</td><td>Omni Port with build-in CCS1 to NACS adapter (captive cabled)</td></tr><tr><td>cTesla</td><td>Tesla Connector (captive cabled)</td></tr><tr><td>cType1</td><td>IEC62196-2 Type 1 connector (captive cabled) a.k.a. J1772</td></tr><tr><td>cType2</td><td>IEC62196-2 Type 2 connector (captive cabled) a.k.a. Mennekes connector</td></tr><tr><td>cUltraChaoJi</td><td>Ultra-ChaoJi for megawatt charging (captive cabled)</td></tr><tr><td>s309-1P-16A</td><td>16A 1 phase IEC60309 socket</td></tr><tr><td>s309-1P-32A</td><td>32A 1 phase IEC60309 socket</td></tr><tr><td>s309-3P-16A</td><td>16A 3 phase IEC60309 socket</td></tr><tr><td>s309-3P-32A</td><td>32A 3 phase IEC60309 socket</td></tr><tr><td>sBS1361</td><td>UK domestic socket a.k.a. 13Amp</td></tr><tr><td>sCEE-7-7</td><td>CEE 7/7 16A socket. May represent 7/4 and 7/5 a.k.a Schuko</td></tr><tr><td>sType1</td><td>IEC62196-2 Type 1 socket a.k.a. J1772</td></tr><tr><td>sType2</td><td>IEC62196-2 Type 2 socket a.k.a. Mennekes connector</td></tr><tr><td>sType3</td><td>IEC62196-2 Type 3 socket a.k.a. Scame</td></tr><tr><td>wInductive</td><td>Wireless inductively coupled connection (generic)</td></tr><tr><td>wResonant</td><td>Wireless resonant coupled connection (generic)</td></tr><tr><td>Other1PhMax16A</td><td>Other single phase (domestic) sockets not mentioned above, rated at no more than 16A. CEE7/17, AS3112, NEMA 5-15, NEMA 5-20, JISC8303, TIS166, SI 32, CPCS-CCC, SEV1011, etc.</td></tr><tr><td>Other1PhOver16A</td><td>Other single phase sockets not mentioned above (over 16A)</td></tr><tr><td>Other3Ph</td><td>Other 3 phase sockets not mentioned above. NEMA14-30, NEMA14-50.</td></tr><tr><td>Pan</td><td>Pantograph connector</td></tr><tr><td>Undetermined</td><td>Yet to be determined (e.g. before plugged in)</td></tr><tr><td>Unknown</td><td>Unknown/not determinable</td></tr></table>
+
+# 7.4. SigningMethodEnumstringType
+
+Standardized values for the signingMethod in a SignedMeterValueType.
+
+Columns Algorithm, Curve, Key Length and Hash Algorithm are for information only and not part of the standardized value.
+
+(Updated in v2.0)
+
+<table><tr><td>SigningMethod</td><td>Algorithm</td><td>Curve</td><td>Key Length</td><td>Hash Algorithm</td></tr><tr><td>ECDSA-secp192k1-SHA256</td><td>ECDSA</td><td>secp192k1</td><td>192 bits</td><td>SHA-256</td></tr><tr><td>ECDSA-secp256k1-SHA256</td><td>ECDSA</td><td>secp256k1</td><td>256 bits</td><td>SHA-256</td></tr><tr><td>ECDSA-secp192r1-SHA256</td><td>ECDSA</td><td>secp192r1</td><td>192 bits</td><td>SHA-256</td></tr><tr><td>ECDSA-secp256r1-SHA256</td><td>ECDSA</td><td>secp256r1</td><td>256 bits</td><td>SHA-256</td></tr><tr><td>ECDSA-brainpool256r1-SHA256</td><td>ECDSA</td><td>brainpool256r1</td><td>256 bits</td><td>SHA-256</td></tr><tr><td>ECDSA-secp384r1-SHA256</td><td>ECDSA</td><td>secp384r1</td><td>384 bits</td><td>SHA-256</td></tr><tr><td>ECDSA-brainpool384r1-SHA256</td><td>ECDSA</td><td>brainpool384r1</td><td>384 bits</td><td>SHA-256</td></tr></table>
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:AFRRSignalRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "timestamp": {
+ "description": "Time when signal becomes active.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "signal": {
+ "description": "Value of signal in _v2xSignalWattCurve_. \r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["timestamp", "signal"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:AFRRSignalResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericStatusEnumType": {
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:AdjustPeriodicEventStreamRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "PeriodicEventStreamParamsType": {
+ "javaType": "PeriodicEventStreamParams",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "interval": {
+ "description": "Time in seconds after which stream data is sent.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "values": {
+ "description": "Number of items to be sent together in stream.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "params": {
+ "$ref": "#/definitions/PeriodicEventStreamParamsType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "params"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:AdjustPeriodicEventStreamResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericStatusEnumType": {
+ "description": "Status of operation.\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:AuthorizeRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalIdToken": {
+ "description": "*(2.1)* This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "_additionalInfo_ can be used to send extra information to CSMS in addition to the regular authorization with _IdToken_. _AdditionalInfo_ contains one or more custom _types_, which need to be agreed upon by all parties involved. When the _type_ is not supported, the CSMS/Charging Station MAY ignore the _additionalInfo_.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "*(2.1)* IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "*(2.1)* Enumeration of possible idToken types. Values defined in Appendix as IdTokenEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "OCSPRequestDataType": {
+ "description": "Information about a certificate for an OCSP check.\r\n",
+ "javaType": "OCSPRequestData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "The hash of the issuer\u2019s distinguished\r\nname (DN), that must be calculated over the DER\r\nencoding of the issuer\u2019s name field in the certificate\r\nbeing checked.\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "The hash of the DER encoded public key:\r\nthe value (excluding tag and length) of the subject\r\npublic key field in the issuer\u2019s certificate.\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The string representation of the\r\nhexadecimal value of the serial number without the\r\nprefix \"0x\" and without leading zeroes.\r\n",
+ "type": "string",
+ "maxLength": 40
+ },
+ "responderURL": {
+ "description": "This contains the responder URL (Case insensitive). \r\n\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "hashAlgorithm",
+ "issuerNameHash",
+ "issuerKeyHash",
+ "serialNumber",
+ "responderURL"
+ ]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "certificate": {
+ "description": "*(2.1)* 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. +\r\nOnly needed in case of central contract validation when Charging Station cannot validate the contract certificate.\r\n\r\n",
+ "type": "string",
+ "maxLength": 10000
+ },
+ "iso15118CertificateHashData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/OCSPRequestDataType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idToken"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:AuthorizeResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "AuthorizationStatusEnumType": {
+ "description": "Current status of the ID Token.\r\n",
+ "javaType": "AuthorizationStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Blocked",
+ "ConcurrentTx",
+ "Expired",
+ "Invalid",
+ "NoCredit",
+ "NotAllowedTypeEVSE",
+ "NotAtThisLocation",
+ "NotAtThisTime",
+ "Unknown"
+ ]
+ },
+ "AuthorizeCertificateStatusEnumType": {
+ "description": "Certificate status information. \r\n- if all certificates are valid: return 'Accepted'.\r\n- if one of the certificates was revoked, return 'CertificateRevoked'.\r\n",
+ "javaType": "AuthorizeCertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "SignatureError",
+ "CertificateExpired",
+ "CertificateRevoked",
+ "NoCertificateAvailable",
+ "CertChainError",
+ "ContractCancelled"
+ ]
+ },
+ "DayOfWeekEnumType": {
+ "javaType": "DayOfWeekEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"]
+ },
+ "EnergyTransferModeEnumType": {
+ "javaType": "EnergyTransferModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "AC_single_phase",
+ "AC_two_phase",
+ "AC_three_phase",
+ "DC",
+ "AC_BPT",
+ "AC_BPT_DER",
+ "AC_DER",
+ "DC_BPT",
+ "DC_ACDP",
+ "DC_ACDP_BPT",
+ "WPT"
+ ]
+ },
+ "EvseKindEnumType": {
+ "description": "Type of EVSE (AC, DC) this tariff applies to.\r\n",
+ "javaType": "EvseKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["AC", "DC"]
+ },
+ "MessageFormatEnumType": {
+ "description": "Format of the message.\r\n",
+ "javaType": "MessageFormatEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ASCII", "HTML", "URI", "UTF8", "QRCODE"]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalIdToken": {
+ "description": "*(2.1)* This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "_additionalInfo_ can be used to send extra information to CSMS in addition to the regular authorization with _IdToken_. _AdditionalInfo_ contains one or more custom _types_, which need to be agreed upon by all parties involved. When the _type_ is not supported, the CSMS/Charging Station MAY ignore the _additionalInfo_.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "IdTokenInfoType": {
+ "description": "Contains status information about an identifier.\r\nIt is advised to not stop charging for a token that expires during charging, as ExpiryDate is only used for caching purposes. If ExpiryDate is not given, the status has no end date.\r\n",
+ "javaType": "IdTokenInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/AuthorizationStatusEnumType"
+ },
+ "cacheExpiryDateTime": {
+ "description": "Date and Time after which the token must be considered invalid.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingPriority": {
+ "description": "Priority from a business point of view. Default priority is 0, The range is from -9 to 9. Higher values indicate a higher priority. The chargingPriority in <<transactioneventresponse,TransactionEventResponse>> overrules this one. \r\n",
+ "type": "integer"
+ },
+ "groupIdToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "language1": {
+ "description": "Preferred user interface language of identifier user. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "language2": {
+ "description": "Second preferred user interface language of identifier user. Don\u2019t use when language1 is omitted, has to be different from language1. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "evseId": {
+ "description": "Only used when the IdToken is only valid for one or more specific EVSEs, not for the entire Charging Station.\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "minItems": 1
+ },
+ "personalMessage": {
+ "$ref": "#/definitions/MessageContentType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "*(2.1)* IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "*(2.1)* Enumeration of possible idToken types. Values defined in Appendix as IdTokenEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "MessageContentType": {
+ "description": "Contains message details, for a message to be displayed on a Charging Station.\r\n\r\n",
+ "javaType": "MessageContent",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "format": {
+ "$ref": "#/definitions/MessageFormatEnumType"
+ },
+ "language": {
+ "description": "Message language identifier. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "content": {
+ "description": "*(2.1)* Required. Message contents. +\r\nMaximum length supported by Charging Station is given in OCPPCommCtrlr.FieldLength[\"MessageContentType.content\"].\r\n Maximum length defaults to 1024.\r\n\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["format", "content"]
+ },
+ "PriceType": {
+ "description": "Price with and without tax. At least one of _exclTax_, _inclTax_ must be present.\r\n",
+ "javaType": "Price",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "exclTax": {
+ "description": "Price/cost excluding tax. Can be absent if _inclTax_ is present.\r\n",
+ "type": "number"
+ },
+ "inclTax": {
+ "description": "Price/cost including tax. Can be absent if _exclTax_ is present.\r\n",
+ "type": "number"
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "TariffConditionsFixedType": {
+ "description": "These conditions describe if a FixedPrice applies at start of the transaction.\r\n\r\nWhen more than one restriction is set, they are to be treated as a logical AND. All need to be valid before this price is active.\r\n\r\nNOTE: _startTimeOfDay_ and _endTimeOfDay_ are in local time, because it is the time in the tariff as it is shown to the EV driver at the Charging Station.\r\nA Charging Station will convert this to the internal time zone that it uses (which is recommended to be UTC, see section Generic chapter 3.1) when performing cost calculation.\r\n\r\n",
+ "javaType": "TariffConditionsFixed",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startTimeOfDay": {
+ "description": "Start time of day in local time. +\r\nFormat as per RFC 3339: time-hour \":\" time-minute +\r\nMust be in 24h format with leading zeros. Hour/Minute separator: \":\"\r\nRegex: ([0-1][0-9]\\|2[0-3]):[0-5][0-9]\r\n",
+ "type": "string"
+ },
+ "endTimeOfDay": {
+ "description": "End time of day in local time. Same syntax as _startTimeOfDay_. +\r\n If end time < start time then the period wraps around to the next day. +\r\n To stop at end of the day use: 00:00.\r\n",
+ "type": "string"
+ },
+ "dayOfWeek": {
+ "description": "Day(s) of the week this is tariff applies.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/DayOfWeekEnumType"
+ },
+ "minItems": 1,
+ "maxItems": 7
+ },
+ "validFromDate": {
+ "description": "Start date in local time, for example: 2015-12-24.\r\nValid from this day (inclusive). +\r\nFormat as per RFC 3339: full-date + \r\n\r\nRegex: ([12][0-9]{3})-(0[1-9]\\|1[0-2])-(0[1-9]\\|[12][0-9]\\|3[01])\r\n",
+ "type": "string"
+ },
+ "validToDate": {
+ "description": "End date in local time, for example: 2015-12-27.\r\n Valid until this day (exclusive). Same syntax as _validFromDate_.\r\n",
+ "type": "string"
+ },
+ "evseKind": {
+ "$ref": "#/definitions/EvseKindEnumType"
+ },
+ "paymentBrand": {
+ "description": "For which payment brand this (adhoc) tariff applies. Can be used to add a surcharge for certain payment brands.\r\n Based on value of _additionalIdToken_ from _idToken.additionalInfo.type_ = \"PaymentBrand\".\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "paymentRecognition": {
+ "description": "Type of adhoc payment, e.g. CC, Debit.\r\n Based on value of _additionalIdToken_ from _idToken.additionalInfo.type_ = \"PaymentRecognition\".\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "TariffConditionsType": {
+ "description": "These conditions describe if and when a TariffEnergyType or TariffTimeType applies during a transaction.\r\n\r\nWhen more than one restriction is set, they are to be treated as a logical AND. All need to be valid before this price is active.\r\n\r\nFor reverse energy flow (discharging) negative values of energy, power and current are used.\r\n\r\nNOTE: _minXXX_ (where XXX = Kwh/A/Kw) must be read as \"closest to zero\", and _maxXXX_ as \"furthest from zero\". For example, a *charging* power range from 10 kW to 50 kWh is given by _minPower_ = 10000 and _maxPower_ = 50000, and a *discharging* power range from -10 kW to -50 kW is given by _minPower_ = -10 and _maxPower_ = -50.\r\n\r\nNOTE: _startTimeOfDay_ and _endTimeOfDay_ are in local time, because it is the time in the tariff as it is shown to the EV driver at the Charging Station.\r\nA Charging Station will convert this to the internal time zone that it uses (which is recommended to be UTC, see section Generic chapter 3.1) when performing cost calculation.\r\n\r\n",
+ "javaType": "TariffConditions",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startTimeOfDay": {
+ "description": "Start time of day in local time. +\r\nFormat as per RFC 3339: time-hour \":\" time-minute +\r\nMust be in 24h format with leading zeros. Hour/Minute separator: \":\"\r\nRegex: ([0-1][0-9]\\|2[0-3]):[0-5][0-9]\r\n",
+ "type": "string"
+ },
+ "endTimeOfDay": {
+ "description": "End time of day in local time. Same syntax as _startTimeOfDay_. +\r\n If end time < start time then the period wraps around to the next day. +\r\n To stop at end of the day use: 00:00.\r\n",
+ "type": "string"
+ },
+ "dayOfWeek": {
+ "description": "Day(s) of the week this is tariff applies.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/DayOfWeekEnumType"
+ },
+ "minItems": 1,
+ "maxItems": 7
+ },
+ "validFromDate": {
+ "description": "Start date in local time, for example: 2015-12-24.\r\nValid from this day (inclusive). +\r\nFormat as per RFC 3339: full-date + \r\n\r\nRegex: ([12][0-9]{3})-(0[1-9]\\|1[0-2])-(0[1-9]\\|[12][0-9]\\|3[01])\r\n",
+ "type": "string"
+ },
+ "validToDate": {
+ "description": "End date in local time, for example: 2015-12-27.\r\n Valid until this day (exclusive). Same syntax as _validFromDate_.\r\n",
+ "type": "string"
+ },
+ "evseKind": {
+ "$ref": "#/definitions/EvseKindEnumType"
+ },
+ "minEnergy": {
+ "description": "Minimum consumed energy in Wh, for example 20000 Wh.\r\n Valid from this amount of energy (inclusive) being used.\r\n",
+ "type": "number"
+ },
+ "maxEnergy": {
+ "description": "Maximum consumed energy in Wh, for example 50000 Wh.\r\n Valid until this amount of energy (exclusive) being used.\r\n",
+ "type": "number"
+ },
+ "minCurrent": {
+ "description": "Sum of the minimum current (in Amperes) over all phases, for example 5 A.\r\n When the EV is charging with more than, or equal to, the defined amount of current, this price is/becomes active. If the charging current is or becomes lower, this price is not or no longer valid and becomes inactive. +\r\n This is NOT about the minimum current over the entire transaction.\r\n",
+ "type": "number"
+ },
+ "maxCurrent": {
+ "description": "Sum of the maximum current (in Amperes) over all phases, for example 20 A.\r\n When the EV is charging with less than the defined amount of current, this price becomes/is active. If the charging current is or becomes higher, this price is not or no longer valid and becomes inactive.\r\n This is NOT about the maximum current over the entire transaction.\r\n",
+ "type": "number"
+ },
+ "minPower": {
+ "description": "Minimum power in W, for example 5000 W.\r\n When the EV is charging with more than, or equal to, the defined amount of power, this price is/becomes active.\r\n If the charging power is or becomes lower, this price is not or no longer valid and becomes inactive.\r\n This is NOT about the minimum power over the entire transaction.\r\n",
+ "type": "number"
+ },
+ "maxPower": {
+ "description": "Maximum power in W, for example 20000 W.\r\n When the EV is charging with less than the defined amount of power, this price becomes/is active.\r\n If the charging power is or becomes higher, this price is not or no longer valid and becomes inactive.\r\n This is NOT about the maximum power over the entire transaction.\r\n",
+ "type": "number"
+ },
+ "minTime": {
+ "description": "Minimum duration in seconds the transaction (charging & idle) MUST last (inclusive).\r\n When the duration of a transaction is longer than the defined value, this price is or becomes active.\r\n Before that moment, this price is not yet active.\r\n",
+ "type": "integer"
+ },
+ "maxTime": {
+ "description": "Maximum duration in seconds the transaction (charging & idle) MUST last (exclusive).\r\n When the duration of a transaction is shorter than the defined value, this price is or becomes active.\r\n After that moment, this price is no longer active.\r\n",
+ "type": "integer"
+ },
+ "minChargingTime": {
+ "description": "Minimum duration in seconds the charging MUST last (inclusive).\r\n When the duration of a charging is longer than the defined value, this price is or becomes active.\r\n Before that moment, this price is not yet active.\r\n",
+ "type": "integer"
+ },
+ "maxChargingTime": {
+ "description": "Maximum duration in seconds the charging MUST last (exclusive).\r\n When the duration of a charging is shorter than the defined value, this price is or becomes active.\r\n After that moment, this price is no longer active.\r\n",
+ "type": "integer"
+ },
+ "minIdleTime": {
+ "description": "Minimum duration in seconds the idle period (i.e. not charging) MUST last (inclusive).\r\n When the duration of the idle time is longer than the defined value, this price is or becomes active.\r\n Before that moment, this price is not yet active.\r\n",
+ "type": "integer"
+ },
+ "maxIdleTime": {
+ "description": "Maximum duration in seconds the idle period (i.e. not charging) MUST last (exclusive).\r\n When the duration of idle time is shorter than the defined value, this price is or becomes active.\r\n After that moment, this price is no longer active.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "TariffEnergyPriceType": {
+ "description": "Tariff with optional conditions for an energy price.\r\n",
+ "javaType": "TariffEnergyPrice",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priceKwh": {
+ "description": "Price per kWh (excl. tax) for this element.\r\n",
+ "type": "number"
+ },
+ "conditions": {
+ "$ref": "#/definitions/TariffConditionsType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priceKwh"]
+ },
+ "TariffEnergyType": {
+ "description": "Price elements and tax for energy\r\n",
+ "javaType": "TariffEnergy",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "prices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TariffEnergyPriceType"
+ },
+ "minItems": 1
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["prices"]
+ },
+ "TariffFixedPriceType": {
+ "description": "Tariff with optional conditions for a fixed price.\r\n",
+ "javaType": "TariffFixedPrice",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "conditions": {
+ "$ref": "#/definitions/TariffConditionsFixedType"
+ },
+ "priceFixed": {
+ "description": "Fixed price for this element e.g. a start fee.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priceFixed"]
+ },
+ "TariffFixedType": {
+ "javaType": "TariffFixed",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "prices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TariffFixedPriceType"
+ },
+ "minItems": 1
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["prices"]
+ },
+ "TariffTimePriceType": {
+ "description": "Tariff with optional conditions for a time duration price.\r\n",
+ "javaType": "TariffTimePrice",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priceMinute": {
+ "description": "Price per minute (excl. tax) for this element.\r\n",
+ "type": "number"
+ },
+ "conditions": {
+ "$ref": "#/definitions/TariffConditionsType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priceMinute"]
+ },
+ "TariffTimeType": {
+ "description": "Price elements and tax for time\r\n\r\n",
+ "javaType": "TariffTime",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "prices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TariffTimePriceType"
+ },
+ "minItems": 1
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["prices"]
+ },
+ "TariffType": {
+ "description": "A tariff is described by fields with prices for:\r\nenergy,\r\ncharging time,\r\nidle time,\r\nfixed fee,\r\nreservation time,\r\nreservation fixed fee. +\r\nEach of these fields may have (optional) conditions that specify when a price is applicable. +\r\nThe _description_ contains a human-readable explanation of the tariff to be shown to the user. +\r\nThe other fields are parameters that define the tariff. These are used by the charging station to calculate the price.\r\n",
+ "javaType": "Tariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "tariffId": {
+ "description": "Unique id of tariff\r\n",
+ "type": "string",
+ "maxLength": 60
+ },
+ "description": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MessageContentType"
+ },
+ "minItems": 1,
+ "maxItems": 10
+ },
+ "currency": {
+ "description": "Currency code according to ISO 4217\r\n",
+ "type": "string",
+ "maxLength": 3
+ },
+ "energy": {
+ "$ref": "#/definitions/TariffEnergyType"
+ },
+ "validFrom": {
+ "description": "Time when this tariff becomes active. When absent, it is immediately active.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingTime": {
+ "$ref": "#/definitions/TariffTimeType"
+ },
+ "idleTime": {
+ "$ref": "#/definitions/TariffTimeType"
+ },
+ "fixedFee": {
+ "$ref": "#/definitions/TariffFixedType"
+ },
+ "reservationTime": {
+ "$ref": "#/definitions/TariffTimeType"
+ },
+ "reservationFixed": {
+ "$ref": "#/definitions/TariffFixedType"
+ },
+ "minCost": {
+ "$ref": "#/definitions/PriceType"
+ },
+ "maxCost": {
+ "$ref": "#/definitions/PriceType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["tariffId", "currency"]
+ },
+ "TaxRateType": {
+ "description": "Tax percentage\r\n",
+ "javaType": "TaxRate",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "description": "Type of this tax, e.g. \"Federal \", \"State\", for information on receipt.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "tax": {
+ "description": "Tax percentage\r\n",
+ "type": "number"
+ },
+ "stack": {
+ "description": "Stack level for this type of tax. Default value, when absent, is 0. +\r\n_stack_ = 0: tax on net price; +\r\n_stack_ = 1: tax added on top of _stack_ 0; +\r\n_stack_ = 2: tax added on top of _stack_ 1, etc. \r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["type", "tax"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "idTokenInfo": {
+ "$ref": "#/definitions/IdTokenInfoType"
+ },
+ "certificateStatus": {
+ "$ref": "#/definitions/AuthorizeCertificateStatusEnumType"
+ },
+ "allowedEnergyTransfer": {
+ "description": "*(2.1)* List of allowed energy transfer modes the EV can choose from. If omitted this defaults to charging only.\r\n\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/EnergyTransferModeEnumType"
+ },
+ "minItems": 1
+ },
+ "tariff": {
+ "$ref": "#/definitions/TariffType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idTokenInfo"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:BatterySwapRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "BatterySwapEventEnumType": {
+ "description": "Battery in/out\r\n",
+ "javaType": "BatterySwapEventEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["BatteryIn", "BatteryOut", "BatteryOutTimeout"]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalIdToken": {
+ "description": "*(2.1)* This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "_additionalInfo_ can be used to send extra information to CSMS in addition to the regular authorization with _IdToken_. _AdditionalInfo_ contains one or more custom _types_, which need to be agreed upon by all parties involved. When the _type_ is not supported, the CSMS/Charging Station MAY ignore the _additionalInfo_.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "BatteryDataType": {
+ "javaType": "BatteryData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evseId": {
+ "description": "Slot number where battery is inserted or removed.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "serialNumber": {
+ "description": "Serial number of battery.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "soC": {
+ "description": "State of charge\r\n",
+ "type": "number",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "soH": {
+ "description": "State of health\r\n\r\n",
+ "type": "number",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "productionDate": {
+ "description": "Production date of battery.\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "vendorInfo": {
+ "description": "Vendor-specific info from battery in undefined format.\r\n",
+ "type": "string",
+ "maxLength": 500
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["evseId", "serialNumber", "soC", "soH"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "*(2.1)* IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "*(2.1)* Enumeration of possible idToken types. Values defined in Appendix as IdTokenEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "batteryData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/BatteryDataType"
+ },
+ "minItems": 1
+ },
+ "eventType": {
+ "$ref": "#/definitions/BatterySwapEventEnumType"
+ },
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "requestId": {
+ "description": "RequestId to correlate BatteryIn/Out events and optional RequestBatterySwapRequest.\r\n\r\n\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["eventType", "requestId", "idToken", "batteryData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:BatterySwapResponse",
+ "description": "This is an empty response that just acknowledges receipt of the request. (The request cannot be rejected).\r\n",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:BootNotificationRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "BootReasonEnumType": {
+ "description": "This contains the reason for sending this message to the CSMS.\r\n",
+ "javaType": "BootReasonEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ApplicationReset",
+ "FirmwareUpdate",
+ "LocalReset",
+ "PowerUp",
+ "RemoteReset",
+ "ScheduledReset",
+ "Triggered",
+ "Unknown",
+ "Watchdog"
+ ]
+ },
+ "ChargingStationType": {
+ "description": "The physical system where an Electrical Vehicle (EV) can be charged.\r\n",
+ "javaType": "ChargingStation",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "serialNumber": {
+ "description": "Vendor-specific device identifier.\r\n",
+ "type": "string",
+ "maxLength": 25
+ },
+ "model": {
+ "description": "Defines the model of the device.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "modem": {
+ "$ref": "#/definitions/ModemType"
+ },
+ "vendorName": {
+ "description": "Identifies the vendor (not necessarily in a unique manner).\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "firmwareVersion": {
+ "description": "This contains the firmware version of the Charging Station.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["model", "vendorName"]
+ },
+ "ModemType": {
+ "description": "Defines parameters required for initiating and maintaining wireless communication with other devices.\r\n",
+ "javaType": "Modem",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "iccid": {
+ "description": "This contains the ICCID of the modem\u2019s SIM card.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "imsi": {
+ "description": "This contains the IMSI of the modem\u2019s SIM card.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "chargingStation": {
+ "$ref": "#/definitions/ChargingStationType"
+ },
+ "reason": {
+ "$ref": "#/definitions/BootReasonEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reason", "chargingStation"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:BootNotificationResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "RegistrationStatusEnumType": {
+ "description": "This contains whether the Charging Station has been registered\r\nwithin the CSMS.\r\n",
+ "javaType": "RegistrationStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Pending", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "currentTime": {
+ "description": "This contains the CSMS\u2019s current time.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "interval": {
+ "description": "When <<cmn_registrationstatusenumtype,Status>> is Accepted, this contains the heartbeat interval in seconds. If the CSMS returns something other than Accepted, the value of the interval field indicates the minimum wait time before sending a next BootNotification request.\r\n",
+ "type": "integer"
+ },
+ "status": {
+ "$ref": "#/definitions/RegistrationStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["currentTime", "interval", "status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:CancelReservationRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reservationId": {
+ "description": "Id of the reservation to cancel.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reservationId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:CancelReservationResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CancelReservationStatusEnumType": {
+ "description": "This indicates the success or failure of the canceling of a reservation by CSMS.\r\n",
+ "javaType": "CancelReservationStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/CancelReservationStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:CertificateSignedRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CertificateSigningUseEnumType": {
+ "description": "Indicates the type of the signed certificate that is returned. When omitted the certificate is used for both the 15118 connection (if implemented) and the Charging Station to CSMS connection. This field is required when a typeOfCertificate was included in the <<signcertificaterequest,SignCertificateRequest>> that requested this certificate to be signed AND both the 15118 connection and the Charging Station connection are implemented.\r\n\r\n",
+ "javaType": "CertificateSigningUseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ChargingStationCertificate", "V2GCertificate", "V2G20Certificate"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateChain": {
+ "description": "The signed PEM encoded X.509 certificate. This SHALL also contain the necessary sub CA certificates, when applicable. The order of the bundle follows the certificate chain, starting from the leaf certificate.\r\n\r\nThe Configuration Variable <<configkey-max-certificate-chain-size,MaxCertificateChainSize>> can be used to limit the maximum size of this field.\r\n",
+ "type": "string",
+ "maxLength": 10000
+ },
+ "certificateType": {
+ "$ref": "#/definitions/CertificateSigningUseEnumType"
+ },
+ "requestId": {
+ "description": "*(2.1)* RequestId to correlate this message with the SignCertificateRequest.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["certificateChain"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:CertificateSignedResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CertificateSignedStatusEnumType": {
+ "description": "Returns whether certificate signing has been accepted, otherwise rejected.\r\n",
+ "javaType": "CertificateSignedStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/CertificateSignedStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ChangeAvailabilityRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "OperationalStatusEnumType": {
+ "description": "This contains the type of availability change that the Charging Station should perform.\r\n\r\n",
+ "javaType": "OperationalStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Inoperative", "Operative"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "operationalStatus": {
+ "$ref": "#/definitions/OperationalStatusEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["operationalStatus"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ChangeAvailabilityResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChangeAvailabilityStatusEnumType": {
+ "description": "This indicates whether the Charging Station is able to perform the availability change.\r\n",
+ "javaType": "ChangeAvailabilityStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Scheduled"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/ChangeAvailabilityStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ChangeTransactionTariffRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DayOfWeekEnumType": {
+ "javaType": "DayOfWeekEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"]
+ },
+ "EvseKindEnumType": {
+ "description": "Type of EVSE (AC, DC) this tariff applies to.\r\n",
+ "javaType": "EvseKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["AC", "DC"]
+ },
+ "MessageFormatEnumType": {
+ "description": "Format of the message.\r\n",
+ "javaType": "MessageFormatEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ASCII", "HTML", "URI", "UTF8", "QRCODE"]
+ },
+ "MessageContentType": {
+ "description": "Contains message details, for a message to be displayed on a Charging Station.\r\n\r\n",
+ "javaType": "MessageContent",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "format": {
+ "$ref": "#/definitions/MessageFormatEnumType"
+ },
+ "language": {
+ "description": "Message language identifier. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "content": {
+ "description": "*(2.1)* Required. Message contents. +\r\nMaximum length supported by Charging Station is given in OCPPCommCtrlr.FieldLength[\"MessageContentType.content\"].\r\n Maximum length defaults to 1024.\r\n\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["format", "content"]
+ },
+ "PriceType": {
+ "description": "Price with and without tax. At least one of _exclTax_, _inclTax_ must be present.\r\n",
+ "javaType": "Price",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "exclTax": {
+ "description": "Price/cost excluding tax. Can be absent if _inclTax_ is present.\r\n",
+ "type": "number"
+ },
+ "inclTax": {
+ "description": "Price/cost including tax. Can be absent if _exclTax_ is present.\r\n",
+ "type": "number"
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "TariffConditionsFixedType": {
+ "description": "These conditions describe if a FixedPrice applies at start of the transaction.\r\n\r\nWhen more than one restriction is set, they are to be treated as a logical AND. All need to be valid before this price is active.\r\n\r\nNOTE: _startTimeOfDay_ and _endTimeOfDay_ are in local time, because it is the time in the tariff as it is shown to the EV driver at the Charging Station.\r\nA Charging Station will convert this to the internal time zone that it uses (which is recommended to be UTC, see section Generic chapter 3.1) when performing cost calculation.\r\n\r\n",
+ "javaType": "TariffConditionsFixed",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startTimeOfDay": {
+ "description": "Start time of day in local time. +\r\nFormat as per RFC 3339: time-hour \":\" time-minute +\r\nMust be in 24h format with leading zeros. Hour/Minute separator: \":\"\r\nRegex: ([0-1][0-9]\\|2[0-3]):[0-5][0-9]\r\n",
+ "type": "string"
+ },
+ "endTimeOfDay": {
+ "description": "End time of day in local time. Same syntax as _startTimeOfDay_. +\r\n If end time < start time then the period wraps around to the next day. +\r\n To stop at end of the day use: 00:00.\r\n",
+ "type": "string"
+ },
+ "dayOfWeek": {
+ "description": "Day(s) of the week this is tariff applies.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/DayOfWeekEnumType"
+ },
+ "minItems": 1,
+ "maxItems": 7
+ },
+ "validFromDate": {
+ "description": "Start date in local time, for example: 2015-12-24.\r\nValid from this day (inclusive). +\r\nFormat as per RFC 3339: full-date + \r\n\r\nRegex: ([12][0-9]{3})-(0[1-9]\\|1[0-2])-(0[1-9]\\|[12][0-9]\\|3[01])\r\n",
+ "type": "string"
+ },
+ "validToDate": {
+ "description": "End date in local time, for example: 2015-12-27.\r\n Valid until this day (exclusive). Same syntax as _validFromDate_.\r\n",
+ "type": "string"
+ },
+ "evseKind": {
+ "$ref": "#/definitions/EvseKindEnumType"
+ },
+ "paymentBrand": {
+ "description": "For which payment brand this (adhoc) tariff applies. Can be used to add a surcharge for certain payment brands.\r\n Based on value of _additionalIdToken_ from _idToken.additionalInfo.type_ = \"PaymentBrand\".\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "paymentRecognition": {
+ "description": "Type of adhoc payment, e.g. CC, Debit.\r\n Based on value of _additionalIdToken_ from _idToken.additionalInfo.type_ = \"PaymentRecognition\".\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "TariffConditionsType": {
+ "description": "These conditions describe if and when a TariffEnergyType or TariffTimeType applies during a transaction.\r\n\r\nWhen more than one restriction is set, they are to be treated as a logical AND. All need to be valid before this price is active.\r\n\r\nFor reverse energy flow (discharging) negative values of energy, power and current are used.\r\n\r\nNOTE: _minXXX_ (where XXX = Kwh/A/Kw) must be read as \"closest to zero\", and _maxXXX_ as \"furthest from zero\". For example, a *charging* power range from 10 kW to 50 kWh is given by _minPower_ = 10000 and _maxPower_ = 50000, and a *discharging* power range from -10 kW to -50 kW is given by _minPower_ = -10 and _maxPower_ = -50.\r\n\r\nNOTE: _startTimeOfDay_ and _endTimeOfDay_ are in local time, because it is the time in the tariff as it is shown to the EV driver at the Charging Station.\r\nA Charging Station will convert this to the internal time zone that it uses (which is recommended to be UTC, see section Generic chapter 3.1) when performing cost calculation.\r\n\r\n",
+ "javaType": "TariffConditions",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startTimeOfDay": {
+ "description": "Start time of day in local time. +\r\nFormat as per RFC 3339: time-hour \":\" time-minute +\r\nMust be in 24h format with leading zeros. Hour/Minute separator: \":\"\r\nRegex: ([0-1][0-9]\\|2[0-3]):[0-5][0-9]\r\n",
+ "type": "string"
+ },
+ "endTimeOfDay": {
+ "description": "End time of day in local time. Same syntax as _startTimeOfDay_. +\r\n If end time < start time then the period wraps around to the next day. +\r\n To stop at end of the day use: 00:00.\r\n",
+ "type": "string"
+ },
+ "dayOfWeek": {
+ "description": "Day(s) of the week this is tariff applies.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/DayOfWeekEnumType"
+ },
+ "minItems": 1,
+ "maxItems": 7
+ },
+ "validFromDate": {
+ "description": "Start date in local time, for example: 2015-12-24.\r\nValid from this day (inclusive). +\r\nFormat as per RFC 3339: full-date + \r\n\r\nRegex: ([12][0-9]{3})-(0[1-9]\\|1[0-2])-(0[1-9]\\|[12][0-9]\\|3[01])\r\n",
+ "type": "string"
+ },
+ "validToDate": {
+ "description": "End date in local time, for example: 2015-12-27.\r\n Valid until this day (exclusive). Same syntax as _validFromDate_.\r\n",
+ "type": "string"
+ },
+ "evseKind": {
+ "$ref": "#/definitions/EvseKindEnumType"
+ },
+ "minEnergy": {
+ "description": "Minimum consumed energy in Wh, for example 20000 Wh.\r\n Valid from this amount of energy (inclusive) being used.\r\n",
+ "type": "number"
+ },
+ "maxEnergy": {
+ "description": "Maximum consumed energy in Wh, for example 50000 Wh.\r\n Valid until this amount of energy (exclusive) being used.\r\n",
+ "type": "number"
+ },
+ "minCurrent": {
+ "description": "Sum of the minimum current (in Amperes) over all phases, for example 5 A.\r\n When the EV is charging with more than, or equal to, the defined amount of current, this price is/becomes active. If the charging current is or becomes lower, this price is not or no longer valid and becomes inactive. +\r\n This is NOT about the minimum current over the entire transaction.\r\n",
+ "type": "number"
+ },
+ "maxCurrent": {
+ "description": "Sum of the maximum current (in Amperes) over all phases, for example 20 A.\r\n When the EV is charging with less than the defined amount of current, this price becomes/is active. If the charging current is or becomes higher, this price is not or no longer valid and becomes inactive.\r\n This is NOT about the maximum current over the entire transaction.\r\n",
+ "type": "number"
+ },
+ "minPower": {
+ "description": "Minimum power in W, for example 5000 W.\r\n When the EV is charging with more than, or equal to, the defined amount of power, this price is/becomes active.\r\n If the charging power is or becomes lower, this price is not or no longer valid and becomes inactive.\r\n This is NOT about the minimum power over the entire transaction.\r\n",
+ "type": "number"
+ },
+ "maxPower": {
+ "description": "Maximum power in W, for example 20000 W.\r\n When the EV is charging with less than the defined amount of power, this price becomes/is active.\r\n If the charging power is or becomes higher, this price is not or no longer valid and becomes inactive.\r\n This is NOT about the maximum power over the entire transaction.\r\n",
+ "type": "number"
+ },
+ "minTime": {
+ "description": "Minimum duration in seconds the transaction (charging & idle) MUST last (inclusive).\r\n When the duration of a transaction is longer than the defined value, this price is or becomes active.\r\n Before that moment, this price is not yet active.\r\n",
+ "type": "integer"
+ },
+ "maxTime": {
+ "description": "Maximum duration in seconds the transaction (charging & idle) MUST last (exclusive).\r\n When the duration of a transaction is shorter than the defined value, this price is or becomes active.\r\n After that moment, this price is no longer active.\r\n",
+ "type": "integer"
+ },
+ "minChargingTime": {
+ "description": "Minimum duration in seconds the charging MUST last (inclusive).\r\n When the duration of a charging is longer than the defined value, this price is or becomes active.\r\n Before that moment, this price is not yet active.\r\n",
+ "type": "integer"
+ },
+ "maxChargingTime": {
+ "description": "Maximum duration in seconds the charging MUST last (exclusive).\r\n When the duration of a charging is shorter than the defined value, this price is or becomes active.\r\n After that moment, this price is no longer active.\r\n",
+ "type": "integer"
+ },
+ "minIdleTime": {
+ "description": "Minimum duration in seconds the idle period (i.e. not charging) MUST last (inclusive).\r\n When the duration of the idle time is longer than the defined value, this price is or becomes active.\r\n Before that moment, this price is not yet active.\r\n",
+ "type": "integer"
+ },
+ "maxIdleTime": {
+ "description": "Maximum duration in seconds the idle period (i.e. not charging) MUST last (exclusive).\r\n When the duration of idle time is shorter than the defined value, this price is or becomes active.\r\n After that moment, this price is no longer active.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "TariffEnergyPriceType": {
+ "description": "Tariff with optional conditions for an energy price.\r\n",
+ "javaType": "TariffEnergyPrice",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priceKwh": {
+ "description": "Price per kWh (excl. tax) for this element.\r\n",
+ "type": "number"
+ },
+ "conditions": {
+ "$ref": "#/definitions/TariffConditionsType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priceKwh"]
+ },
+ "TariffEnergyType": {
+ "description": "Price elements and tax for energy\r\n",
+ "javaType": "TariffEnergy",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "prices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TariffEnergyPriceType"
+ },
+ "minItems": 1
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["prices"]
+ },
+ "TariffFixedPriceType": {
+ "description": "Tariff with optional conditions for a fixed price.\r\n",
+ "javaType": "TariffFixedPrice",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "conditions": {
+ "$ref": "#/definitions/TariffConditionsFixedType"
+ },
+ "priceFixed": {
+ "description": "Fixed price for this element e.g. a start fee.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priceFixed"]
+ },
+ "TariffFixedType": {
+ "javaType": "TariffFixed",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "prices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TariffFixedPriceType"
+ },
+ "minItems": 1
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["prices"]
+ },
+ "TariffTimePriceType": {
+ "description": "Tariff with optional conditions for a time duration price.\r\n",
+ "javaType": "TariffTimePrice",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priceMinute": {
+ "description": "Price per minute (excl. tax) for this element.\r\n",
+ "type": "number"
+ },
+ "conditions": {
+ "$ref": "#/definitions/TariffConditionsType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priceMinute"]
+ },
+ "TariffTimeType": {
+ "description": "Price elements and tax for time\r\n\r\n",
+ "javaType": "TariffTime",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "prices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TariffTimePriceType"
+ },
+ "minItems": 1
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["prices"]
+ },
+ "TariffType": {
+ "description": "A tariff is described by fields with prices for:\r\nenergy,\r\ncharging time,\r\nidle time,\r\nfixed fee,\r\nreservation time,\r\nreservation fixed fee. +\r\nEach of these fields may have (optional) conditions that specify when a price is applicable. +\r\nThe _description_ contains a human-readable explanation of the tariff to be shown to the user. +\r\nThe other fields are parameters that define the tariff. These are used by the charging station to calculate the price.\r\n",
+ "javaType": "Tariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "tariffId": {
+ "description": "Unique id of tariff\r\n",
+ "type": "string",
+ "maxLength": 60
+ },
+ "description": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MessageContentType"
+ },
+ "minItems": 1,
+ "maxItems": 10
+ },
+ "currency": {
+ "description": "Currency code according to ISO 4217\r\n",
+ "type": "string",
+ "maxLength": 3
+ },
+ "energy": {
+ "$ref": "#/definitions/TariffEnergyType"
+ },
+ "validFrom": {
+ "description": "Time when this tariff becomes active. When absent, it is immediately active.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingTime": {
+ "$ref": "#/definitions/TariffTimeType"
+ },
+ "idleTime": {
+ "$ref": "#/definitions/TariffTimeType"
+ },
+ "fixedFee": {
+ "$ref": "#/definitions/TariffFixedType"
+ },
+ "reservationTime": {
+ "$ref": "#/definitions/TariffTimeType"
+ },
+ "reservationFixed": {
+ "$ref": "#/definitions/TariffFixedType"
+ },
+ "minCost": {
+ "$ref": "#/definitions/PriceType"
+ },
+ "maxCost": {
+ "$ref": "#/definitions/PriceType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["tariffId", "currency"]
+ },
+ "TaxRateType": {
+ "description": "Tax percentage\r\n",
+ "javaType": "TaxRate",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "description": "Type of this tax, e.g. \"Federal \", \"State\", for information on receipt.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "tax": {
+ "description": "Tax percentage\r\n",
+ "type": "number"
+ },
+ "stack": {
+ "description": "Stack level for this type of tax. Default value, when absent, is 0. +\r\n_stack_ = 0: tax on net price; +\r\n_stack_ = 1: tax added on top of _stack_ 0; +\r\n_stack_ = 2: tax added on top of _stack_ 1, etc. \r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["type", "tax"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "tariff": {
+ "$ref": "#/definitions/TariffType"
+ },
+ "transactionId": {
+ "description": "Transaction id for new tariff.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["transactionId", "tariff"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ChangeTransactionTariffResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "TariffChangeStatusEnumType": {
+ "description": "Status of the operation\r\n",
+ "javaType": "TariffChangeStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Rejected",
+ "TooManyElements",
+ "ConditionNotSupported",
+ "TxNotFound",
+ "NoCurrencyChange"
+ ]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/TariffChangeStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearCacheRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearCacheResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ClearCacheStatusEnumType": {
+ "description": "Accepted if the Charging Station has executed the request, otherwise rejected.\r\n",
+ "javaType": "ClearCacheStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/ClearCacheStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearChargingProfileRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingProfilePurposeEnumType": {
+ "description": "Specifies to purpose of the charging profiles that will be cleared, if they meet the other criteria in the request.\r\n",
+ "javaType": "ChargingProfilePurposeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ChargingStationExternalConstraints",
+ "ChargingStationMaxProfile",
+ "TxDefaultProfile",
+ "TxProfile",
+ "PriorityCharging",
+ "LocalGeneration"
+ ]
+ },
+ "ClearChargingProfileType": {
+ "description": "A ClearChargingProfileType is a filter for charging profiles to be cleared by ClearChargingProfileRequest.\r\n\r\n",
+ "javaType": "ClearChargingProfile",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evseId": {
+ "description": "Specifies the id of the EVSE for which to clear charging profiles. An evseId of zero (0) specifies the charging profile for the overall Charging Station. Absence of this parameter means the clearing applies to all charging profiles that match the other criteria in the request.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "chargingProfilePurpose": {
+ "$ref": "#/definitions/ChargingProfilePurposeEnumType"
+ },
+ "stackLevel": {
+ "description": "Specifies the stackLevel for which charging profiles will be cleared, if they meet the other criteria in the request.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "chargingProfileId": {
+ "description": "The Id of the charging profile to clear.\r\n",
+ "type": "integer"
+ },
+ "chargingProfileCriteria": {
+ "$ref": "#/definitions/ClearChargingProfileType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearChargingProfileResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ClearChargingProfileStatusEnumType": {
+ "description": "Indicates if the Charging Station was able to execute the request.\r\n",
+ "javaType": "ClearChargingProfileStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Unknown"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/ClearChargingProfileStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearDERControlRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DERControlEnumType": {
+ "description": "Name of control settings to clear. Not used when _controlId_ is provided.\r\n\r\n",
+ "javaType": "DERControlEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "EnterService",
+ "FreqDroop",
+ "FreqWatt",
+ "FixedPFAbsorb",
+ "FixedPFInject",
+ "FixedVar",
+ "Gradients",
+ "HFMustTrip",
+ "HFMayTrip",
+ "HVMustTrip",
+ "HVMomCess",
+ "HVMayTrip",
+ "LimitMaxDischarge",
+ "LFMustTrip",
+ "LVMustTrip",
+ "LVMomCess",
+ "LVMayTrip",
+ "PowerMonitoringMustTrip",
+ "VoltVar",
+ "VoltWatt",
+ "WattPF",
+ "WattVar"
+ ]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "isDefault": {
+ "description": "True: clearing default DER controls. False: clearing scheduled controls.\r\n\r\n",
+ "type": "boolean"
+ },
+ "controlType": {
+ "$ref": "#/definitions/DERControlEnumType"
+ },
+ "controlId": {
+ "description": "Id of control setting to clear. When omitted all settings for _controlType_ are cleared.\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["isDefault"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearDERControlResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DERControlStatusEnumType": {
+ "description": "Result of operation.\r\n\r\n",
+ "javaType": "DERControlStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotSupported", "NotFound"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/DERControlStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearDisplayMessageRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Id of the message that SHALL be removed from the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearDisplayMessageResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ClearMessageStatusEnumType": {
+ "description": "Returns whether the Charging Station has been able to remove the message.\r\n",
+ "javaType": "ClearMessageStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Unknown", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/ClearMessageStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearTariffsRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "tariffIds": {
+ "description": "List of tariff Ids to clear. When absent clears all tariffs at _evseId_.\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "string",
+ "maxLength": 60
+ },
+ "minItems": 1
+ },
+ "evseId": {
+ "description": "When present only clear tariffs matching _tariffIds_ at EVSE _evseId_.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearTariffsResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "TariffClearStatusEnumType": {
+ "javaType": "TariffClearStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NoTariff"]
+ },
+ "ClearTariffsResultType": {
+ "javaType": "ClearTariffsResult",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "tariffId": {
+ "description": "Id of tariff for which _status_ is reported. If no tariffs were found, then this field is absent, and _status_ will be `NoTariff`.\r\n",
+ "type": "string",
+ "maxLength": 60
+ },
+ "status": {
+ "$ref": "#/definitions/TariffClearStatusEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "clearTariffsResult": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ClearTariffsResultType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["clearTariffsResult"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearVariableMonitoringRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "List of the monitors to be cleared, identified by there Id.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearVariableMonitoringResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ClearMonitoringStatusEnumType": {
+ "description": "Result of the clear request for this monitor, identified by its Id.\r\n\r\n",
+ "javaType": "ClearMonitoringStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotFound"]
+ },
+ "ClearMonitoringResultType": {
+ "javaType": "ClearMonitoringResult",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/ClearMonitoringStatusEnumType"
+ },
+ "id": {
+ "description": "Id of the monitor of which a clear was requested.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status", "id"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "clearMonitoringResult": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ClearMonitoringResultType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["clearMonitoringResult"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearedChargingLimitRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "chargingLimitSource": {
+ "description": "Source of the charging limit. Allowed values defined in Appendix as ChargingLimitSourceEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "evseId": {
+ "description": "EVSE Identifier.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["chargingLimitSource"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClearedChargingLimitResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClosePeriodicEventStreamRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Id of stream to close.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ClosePeriodicEventStreamResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:CostUpdatedRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "totalCost": {
+ "description": "Current total cost, based on the information known by the CSMS, of the transaction including taxes. In the currency configured with the configuration Variable: [<<configkey-currency, Currency>>]\r\n\r\n",
+ "type": "number"
+ },
+ "transactionId": {
+ "description": "Transaction Id of the transaction the current cost are asked for.\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["totalCost", "transactionId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:CostUpdatedResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:CustomerInformationRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalIdToken": {
+ "description": "*(2.1)* This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "_additionalInfo_ can be used to send extra information to CSMS in addition to the regular authorization with _IdToken_. _AdditionalInfo_ contains one or more custom _types_, which need to be agreed upon by all parties involved. When the _type_ is not supported, the CSMS/Charging Station MAY ignore the _additionalInfo_.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "CertificateHashDataType": {
+ "javaType": "CertificateHashData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "The hash of the issuer\u2019s distinguished\r\nname (DN), that must be calculated over the DER\r\nencoding of the issuer\u2019s name field in the certificate\r\nbeing checked.\r\n\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "The hash of the DER encoded public key:\r\nthe value (excluding tag and length) of the subject\r\npublic key field in the issuer\u2019s certificate.\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The string representation of the\r\nhexadecimal value of the serial number without the\r\nprefix \"0x\" and without leading zeroes.\r\n",
+ "type": "string",
+ "maxLength": 40
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["hashAlgorithm", "issuerNameHash", "issuerKeyHash", "serialNumber"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "*(2.1)* IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "*(2.1)* Enumeration of possible idToken types. Values defined in Appendix as IdTokenEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customerCertificate": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ },
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "requestId": {
+ "description": "The Id of the request.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "report": {
+ "description": "Flag indicating whether the Charging Station should return NotifyCustomerInformationRequest messages containing information about the customer referred to.\r\n",
+ "type": "boolean"
+ },
+ "clear": {
+ "description": "Flag indicating whether the Charging Station should clear all information about the customer referred to.\r\n",
+ "type": "boolean"
+ },
+ "customerIdentifier": {
+ "description": "A (e.g. vendor specific) identifier of the customer this request refers to. This field contains a custom identifier other than IdToken and Certificate.\r\nOne of the possible identifiers (customerIdentifier, customerIdToken or customerCertificate) should be in the request message.\r\n",
+ "type": "string",
+ "maxLength": 64
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId", "report", "clear"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:CustomerInformationResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomerInformationStatusEnumType": {
+ "description": "Indicates whether the request was accepted.\r\n",
+ "javaType": "CustomerInformationStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Invalid"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/CustomerInformationStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:DataTransferRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "messageId": {
+ "description": "May be used to indicate a specific message or implementation.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "data": {
+ "description": "Data without specified length or format. This needs to be decided by both parties (Open to implementation).\r\n"
+ },
+ "vendorId": {
+ "description": "This identifies the Vendor specific implementation\r\n\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["vendorId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:DataTransferResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DataTransferStatusEnumType": {
+ "description": "This indicates the success or failure of the data transfer.\r\n",
+ "javaType": "DataTransferStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "UnknownMessageId", "UnknownVendorId"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/DataTransferStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "data": {
+ "description": "Data without specified length or format, in response to request.\r\n"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:DeleteCertificateRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "CertificateHashDataType": {
+ "javaType": "CertificateHashData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "The hash of the issuer\u2019s distinguished\r\nname (DN), that must be calculated over the DER\r\nencoding of the issuer\u2019s name field in the certificate\r\nbeing checked.\r\n\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "The hash of the DER encoded public key:\r\nthe value (excluding tag and length) of the subject\r\npublic key field in the issuer\u2019s certificate.\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The string representation of the\r\nhexadecimal value of the serial number without the\r\nprefix \"0x\" and without leading zeroes.\r\n",
+ "type": "string",
+ "maxLength": 40
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["hashAlgorithm", "issuerNameHash", "issuerKeyHash", "serialNumber"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateHashData": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["certificateHashData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:DeleteCertificateResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DeleteCertificateStatusEnumType": {
+ "description": "Charging Station indicates if it can process the request.\r\n",
+ "javaType": "DeleteCertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Failed", "NotFound"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/DeleteCertificateStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:FirmwareStatusNotificationRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "FirmwareStatusEnumType": {
+ "description": "This contains the progress status of the firmware installation.\r\n",
+ "javaType": "FirmwareStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Downloaded",
+ "DownloadFailed",
+ "Downloading",
+ "DownloadScheduled",
+ "DownloadPaused",
+ "Idle",
+ "InstallationFailed",
+ "Installing",
+ "Installed",
+ "InstallRebooting",
+ "InstallScheduled",
+ "InstallVerificationFailed",
+ "InvalidSignature",
+ "SignatureVerified"
+ ]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/FirmwareStatusEnumType"
+ },
+ "requestId": {
+ "description": "The request id that was provided in the\r\nUpdateFirmwareRequest that started this firmware update.\r\nThis field is mandatory, unless the message was triggered by a TriggerMessageRequest AND there is no firmware update ongoing.\r\n",
+ "type": "integer"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:FirmwareStatusNotificationResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:Get15118EVCertificateRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CertificateActionEnumType": {
+ "description": "Defines whether certificate needs to be installed or updated.\r\n",
+ "javaType": "CertificateActionEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Install", "Update"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "iso15118SchemaVersion": {
+ "description": "Schema version currently used for the 15118 session between EV and Charging Station. Needed for parsing of the EXI stream by the CSMS.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "action": {
+ "$ref": "#/definitions/CertificateActionEnumType"
+ },
+ "exiRequest": {
+ "description": "*(2.1)* Raw CertificateInstallationReq request from EV, Base64 encoded. +\r\nExtended to support ISO 15118-20 certificates. The minimum supported length is 11000. If a longer _exiRequest_ is supported, then the supported length must be communicated in variable OCPPCommCtrlr.FieldLength[ \"Get15118EVCertificateRequest.exiRequest\" ].\r\n",
+ "type": "string",
+ "maxLength": 11000
+ },
+ "maximumContractCertificateChains": {
+ "description": "*(2.1)* Absent during ISO 15118-2 session. Required during ISO 15118-20 session. +\r\nMaximum number of contracts that EV wants to install.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "prioritizedEMAIDs": {
+ "description": "*(2.1)* Absent during ISO 15118-2 session. Optional during ISO 15118-20 session. List of EMAIDs for which contract certificates must be requested first, in case there are more certificates than allowed by _maximumContractCertificateChains_.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "string",
+ "maxLength": 255
+ },
+ "minItems": 1,
+ "maxItems": 8
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["iso15118SchemaVersion", "action", "exiRequest"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:Get15118EVCertificateResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "Iso15118EVCertificateStatusEnumType": {
+ "description": "Indicates whether the message was processed properly.\r\n",
+ "javaType": "Iso15118EVCertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Failed"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/Iso15118EVCertificateStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "exiResponse": {
+ "description": "*(2/1)* Raw CertificateInstallationRes response for the EV, Base64 encoded. +\r\nExtended to support ISO 15118-20 certificates. The minimum supported length is 17000. If a longer _exiResponse_ is supported, then the supported length must be communicated in variable OCPPCommCtrlr.FieldLength[ \"Get15118EVCertificateResponse.exiResponse\" ].\r\n\r\n",
+ "type": "string",
+ "maxLength": 17000
+ },
+ "remainingContracts": {
+ "description": "*(2.1)* Number of contracts that can be retrieved with additional requests.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status", "exiResponse"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetBaseReportRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ReportBaseEnumType": {
+ "description": "This field specifies the report base.\r\n",
+ "javaType": "ReportBaseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ConfigurationInventory", "FullInventory", "SummaryInventory"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "requestId": {
+ "description": "The Id of the request.\r\n",
+ "type": "integer"
+ },
+ "reportBase": {
+ "$ref": "#/definitions/ReportBaseEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId", "reportBase"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetBaseReportResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericDeviceModelStatusEnumType": {
+ "description": "This indicates whether the Charging Station is able to accept this request.\r\n",
+ "javaType": "GenericDeviceModelStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotSupported", "EmptyResultSet"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericDeviceModelStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetCertificateChainStatusRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CertificateStatusSourceEnumType": {
+ "description": "Source of status: OCSP, CRL\r\n",
+ "javaType": "CertificateStatusSourceEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CRL", "OCSP"]
+ },
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "CertificateHashDataType": {
+ "javaType": "CertificateHashData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "The hash of the issuer\u2019s distinguished\r\nname (DN), that must be calculated over the DER\r\nencoding of the issuer\u2019s name field in the certificate\r\nbeing checked.\r\n\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "The hash of the DER encoded public key:\r\nthe value (excluding tag and length) of the subject\r\npublic key field in the issuer\u2019s certificate.\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The string representation of the\r\nhexadecimal value of the serial number without the\r\nprefix \"0x\" and without leading zeroes.\r\n",
+ "type": "string",
+ "maxLength": 40
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["hashAlgorithm", "issuerNameHash", "issuerKeyHash", "serialNumber"]
+ },
+ "CertificateStatusRequestInfoType": {
+ "description": "Data necessary to request the revocation status of a certificate.\r\n",
+ "javaType": "CertificateStatusRequestInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateHashData": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ },
+ "source": {
+ "$ref": "#/definitions/CertificateStatusSourceEnumType"
+ },
+ "urls": {
+ "description": "URL(s) of _source_.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "string",
+ "maxLength": 2000
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["source", "urls", "certificateHashData"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateStatusRequests": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CertificateStatusRequestInfoType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["certificateStatusRequests"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetCertificateChainStatusResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CertificateStatusEnumType": {
+ "description": "Status of certificate: good, revoked or unknown.\r\n",
+ "javaType": "CertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Good", "Revoked", "Unknown", "Failed"]
+ },
+ "CertificateStatusSourceEnumType": {
+ "description": "Source of status: OCSP, CRL\r\n",
+ "javaType": "CertificateStatusSourceEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CRL", "OCSP"]
+ },
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "CertificateHashDataType": {
+ "javaType": "CertificateHashData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "The hash of the issuer\u2019s distinguished\r\nname (DN), that must be calculated over the DER\r\nencoding of the issuer\u2019s name field in the certificate\r\nbeing checked.\r\n\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "The hash of the DER encoded public key:\r\nthe value (excluding tag and length) of the subject\r\npublic key field in the issuer\u2019s certificate.\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The string representation of the\r\nhexadecimal value of the serial number without the\r\nprefix \"0x\" and without leading zeroes.\r\n",
+ "type": "string",
+ "maxLength": 40
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["hashAlgorithm", "issuerNameHash", "issuerKeyHash", "serialNumber"]
+ },
+ "CertificateStatusType": {
+ "description": "Revocation status of certificate\r\n",
+ "javaType": "CertificateStatus",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateHashData": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ },
+ "source": {
+ "$ref": "#/definitions/CertificateStatusSourceEnumType"
+ },
+ "status": {
+ "$ref": "#/definitions/CertificateStatusEnumType"
+ },
+ "nextUpdate": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["source", "status", "nextUpdate", "certificateHashData"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateStatus": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CertificateStatusType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["certificateStatus"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetCertificateStatusRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "OCSPRequestDataType": {
+ "description": "Information about a certificate for an OCSP check.\r\n",
+ "javaType": "OCSPRequestData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "The hash of the issuer\u2019s distinguished\r\nname (DN), that must be calculated over the DER\r\nencoding of the issuer\u2019s name field in the certificate\r\nbeing checked.\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "The hash of the DER encoded public key:\r\nthe value (excluding tag and length) of the subject\r\npublic key field in the issuer\u2019s certificate.\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The string representation of the\r\nhexadecimal value of the serial number without the\r\nprefix \"0x\" and without leading zeroes.\r\n",
+ "type": "string",
+ "maxLength": 40
+ },
+ "responderURL": {
+ "description": "This contains the responder URL (Case insensitive). \r\n\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "hashAlgorithm",
+ "issuerNameHash",
+ "issuerKeyHash",
+ "serialNumber",
+ "responderURL"
+ ]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "ocspRequestData": {
+ "$ref": "#/definitions/OCSPRequestDataType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["ocspRequestData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetCertificateStatusResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GetCertificateStatusEnumType": {
+ "description": "This indicates whether the charging station was able to retrieve the OCSP certificate status.\r\n",
+ "javaType": "GetCertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Failed"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GetCertificateStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "ocspResult": {
+ "description": "*(2.1)* OCSPResponse class as defined in <<ref-ocpp_security_24, IETF RFC 6960>>. DER encoded (as defined in <<ref-ocpp_security_24, IETF RFC 6960>>), and then base64 encoded. MAY only be omitted when status is not Accepted. +\r\nThe minimum supported length is 18000. If a longer _ocspResult_ is supported, then the supported length must be communicated in variable OCPPCommCtrlr.FieldLength[ \"GetCertificateStatusResponse.ocspResult\" ].\r\n\r\n",
+ "type": "string",
+ "maxLength": 18000
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetChargingProfilesRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingProfilePurposeEnumType": {
+ "description": "Defines the purpose of the schedule transferred by this profile\r\n",
+ "javaType": "ChargingProfilePurposeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ChargingStationExternalConstraints",
+ "ChargingStationMaxProfile",
+ "TxDefaultProfile",
+ "TxProfile",
+ "PriorityCharging",
+ "LocalGeneration"
+ ]
+ },
+ "ChargingProfileCriterionType": {
+ "description": "A ChargingProfileCriterionType is a filter for charging profiles to be selected by a GetChargingProfilesRequest.\r\n\r\n",
+ "javaType": "ChargingProfileCriterion",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "chargingProfilePurpose": {
+ "$ref": "#/definitions/ChargingProfilePurposeEnumType"
+ },
+ "stackLevel": {
+ "description": "Value determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "chargingProfileId": {
+ "description": "List of all the chargingProfileIds requested. Any ChargingProfile that matches one of these profiles will be reported. If omitted, the Charging Station SHALL not filter on chargingProfileId. This field SHALL NOT contain more ids than set in <<configkey-charging-profile-entries,ChargingProfileEntries.maxLimit>>\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer"
+ },
+ "minItems": 1
+ },
+ "chargingLimitSource": {
+ "description": "For which charging limit sources, charging profiles SHALL be reported. If omitted, the Charging Station SHALL not filter on chargingLimitSource. Values defined in Appendix as ChargingLimitSourceEnumStringType.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "string",
+ "maxLength": 20
+ },
+ "minItems": 1,
+ "maxItems": 4
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "requestId": {
+ "description": "Reference identification that is to be used by the Charging Station in the <<reportchargingprofilesrequest, ReportChargingProfilesRequest>> when provided.\r\n",
+ "type": "integer"
+ },
+ "evseId": {
+ "description": "For which EVSE installed charging profiles SHALL be reported. If 0, only charging profiles installed on the Charging Station itself (the grid connection) SHALL be reported. If omitted, all installed charging profiles SHALL be reported. +\r\nReported charging profiles SHALL match the criteria in field _chargingProfile_.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "chargingProfile": {
+ "$ref": "#/definitions/ChargingProfileCriterionType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId", "chargingProfile"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetChargingProfilesResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GetChargingProfileStatusEnumType": {
+ "description": "This indicates whether the Charging Station is able to process this request and will send <<reportchargingprofilesrequest, ReportChargingProfilesRequest>> messages.\r\n",
+ "javaType": "GetChargingProfileStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "NoProfiles"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GetChargingProfileStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetCompositeScheduleRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingRateUnitEnumType": {
+ "description": "Can be used to force a power or current profile.\r\n\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "Length of the requested schedule in seconds.\r\n\r\n",
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "evseId": {
+ "description": "The ID of the EVSE for which the schedule is requested. When evseid=0, the Charging Station will calculate the expected consumption for the grid connection.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "evseId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetCompositeScheduleResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingRateUnitEnumType": {
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "GenericStatusEnumType": {
+ "description": "The Charging Station will indicate if it was\r\nable to process the request\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "OperationModeEnumType": {
+ "description": "*(2.1)* Charging operation mode to use during this time interval. When absent defaults to `ChargingOnly`.\r\n",
+ "javaType": "OperationModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Idle",
+ "ChargingOnly",
+ "CentralSetpoint",
+ "ExternalSetpoint",
+ "ExternalLimits",
+ "CentralFrequency",
+ "LocalFrequency",
+ "LocalLoadBalancing"
+ ]
+ },
+ "ChargingSchedulePeriodType": {
+ "description": "Charging schedule period structure defines a time period in a charging schedule. It is used in: CompositeScheduleType and in ChargingScheduleType. When used in a NotifyEVChargingScheduleRequest only _startPeriod_, _limit_, _limit_L2_, _limit_L3_ are relevant.\r\n",
+ "javaType": "ChargingSchedulePeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startPeriod": {
+ "description": "Start of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.\r\n",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Optional only when not required by the _operationMode_, as in CentralSetpoint, ExternalSetpoint, ExternalLimits, LocalFrequency, LocalLoadBalancing. +\r\nCharging rate limit during the schedule period, in the applicable _chargingRateUnit_. \r\nThis SHOULD be a non-negative value; a negative value is only supported for backwards compatibility with older systems that use a negative value to specify a discharging limit.\r\nWhen using _chargingRateUnit_ = `W`, this field represents the sum of the power of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "limit_L2": {
+ "description": "*(2.1)* Charging rate limit on phase L2 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "limit_L3": {
+ "description": "*(2.1)* Charging rate limit on phase L3 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "numberPhases": {
+ "description": "The number of phases that can be used for charging. +\r\nFor a DC EVSE this field should be omitted. +\r\nFor an AC EVSE a default value of _numberPhases_ = 3 will be assumed if the field is absent.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "phaseToUse": {
+ "description": "Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true. It\u2019s not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "dischargeLimit": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ that the EV is allowed to discharge with. Note, these are negative values in order to be consistent with _setpoint_, which can be positive and negative. +\r\nFor AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L2": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L2 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L3": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L3 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "setpoint": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow as close as possible. Use negative values for discharging. +\r\nWhen a limit and/or _dischargeLimit_ are given the overshoot when following _setpoint_ must remain within these values.\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpoint_L2": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L2 as close as possible.\r\n",
+ "type": "number"
+ },
+ "setpoint_L3": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L3 as close as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow as closely as possible. Positive values for inductive, negative for capacitive reactive power or current. +\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpointReactive_L2": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L2 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive_L3": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L3 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "preconditioningRequest": {
+ "description": "*(2.1)* If true, the EV should attempt to keep the BMS preconditioned for this time interval.\r\n",
+ "type": "boolean"
+ },
+ "evseSleep": {
+ "description": "*(2.1)* If true, the EVSE must turn off power electronics/modules associated with this transaction. Default value when absent is false.\r\n",
+ "type": "boolean"
+ },
+ "v2xBaseline": {
+ "description": "*(2.1)* Power value that, when present, is used as a baseline on top of which values from _v2xFreqWattCurve_ and _v2xSignalWattCurve_ are added.\r\n\r\n",
+ "type": "number"
+ },
+ "operationMode": {
+ "$ref": "#/definitions/OperationModeEnumType"
+ },
+ "v2xFreqWattCurve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/V2XFreqWattPointType"
+ },
+ "minItems": 1,
+ "maxItems": 20
+ },
+ "v2xSignalWattCurve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/V2XSignalWattPointType"
+ },
+ "minItems": 1,
+ "maxItems": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startPeriod"]
+ },
+ "CompositeScheduleType": {
+ "javaType": "CompositeSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evseId": {
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "duration": {
+ "type": "integer"
+ },
+ "scheduleStart": {
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingSchedulePeriodType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "evseId",
+ "duration",
+ "scheduleStart",
+ "chargingRateUnit",
+ "chargingSchedulePeriod"
+ ]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "V2XFreqWattPointType": {
+ "description": "*(2.1)* A point of a frequency-watt curve.\r\n",
+ "javaType": "V2XFreqWattPoint",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "frequency": {
+ "description": "Net frequency in Hz.\r\n",
+ "type": "number"
+ },
+ "power": {
+ "description": "Power in W to charge (positive) or discharge (negative) at specified frequency.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["frequency", "power"]
+ },
+ "V2XSignalWattPointType": {
+ "description": "*(2.1)* A point of a signal-watt curve.\r\n",
+ "javaType": "V2XSignalWattPoint",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "signal": {
+ "description": "Signal value from an AFRRSignalRequest.\r\n",
+ "type": "integer"
+ },
+ "power": {
+ "description": "Power in W to charge (positive) or discharge (negative) at specified frequency.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["signal", "power"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "schedule": {
+ "$ref": "#/definitions/CompositeScheduleType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetDERControlRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DERControlEnumType": {
+ "description": "Type of control settings to retrieve. Not used when _controlId_ is provided.\r\n\r\n",
+ "javaType": "DERControlEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "EnterService",
+ "FreqDroop",
+ "FreqWatt",
+ "FixedPFAbsorb",
+ "FixedPFInject",
+ "FixedVar",
+ "Gradients",
+ "HFMustTrip",
+ "HFMayTrip",
+ "HVMustTrip",
+ "HVMomCess",
+ "HVMayTrip",
+ "LimitMaxDischarge",
+ "LFMustTrip",
+ "LVMustTrip",
+ "LVMomCess",
+ "LVMayTrip",
+ "PowerMonitoringMustTrip",
+ "VoltVar",
+ "VoltWatt",
+ "WattPF",
+ "WattVar"
+ ]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "requestId": {
+ "description": "RequestId to be used in ReportDERControlRequest.\r\n",
+ "type": "integer"
+ },
+ "isDefault": {
+ "description": "True: get a default DER control. False: get a scheduled control.\r\n\r\n",
+ "type": "boolean"
+ },
+ "controlType": {
+ "$ref": "#/definitions/DERControlEnumType"
+ },
+ "controlId": {
+ "description": "Id of setting to get. When omitted all settings for _controlType_ are retrieved.\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetDERControlResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DERControlStatusEnumType": {
+ "description": "Result of operation.\r\n\r\n",
+ "javaType": "DERControlStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotSupported", "NotFound"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/DERControlStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetDisplayMessagesRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "MessagePriorityEnumType": {
+ "description": "If provided the Charging Station shall return Display Messages with the given priority only.\r\n",
+ "javaType": "MessagePriorityEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["AlwaysFront", "InFront", "NormalCycle"]
+ },
+ "MessageStateEnumType": {
+ "description": "If provided the Charging Station shall return Display Messages with the given state only. \r\n",
+ "javaType": "MessageStateEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Charging", "Faulted", "Idle", "Unavailable", "Suspended", "Discharging"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "If provided the Charging Station shall return Display Messages of the given ids. This field SHALL NOT contain more ids than set in <<configkey-number-of-display-messages,NumberOfDisplayMessages.maxLimit>>\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "minItems": 1
+ },
+ "requestId": {
+ "description": "The Id of this request.\r\n",
+ "type": "integer"
+ },
+ "priority": {
+ "$ref": "#/definitions/MessagePriorityEnumType"
+ },
+ "state": {
+ "$ref": "#/definitions/MessageStateEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetDisplayMessagesResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GetDisplayMessagesStatusEnumType": {
+ "description": "Indicates if the Charging Station has Display Messages that match the request criteria in the <<getdisplaymessagesrequest,GetDisplayMessagesRequest>>\r\n",
+ "javaType": "GetDisplayMessagesStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Unknown"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GetDisplayMessagesStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetInstalledCertificateIdsRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GetCertificateIdUseEnumType": {
+ "javaType": "GetCertificateIdUseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "V2GRootCertificate",
+ "MORootCertificate",
+ "CSMSRootCertificate",
+ "V2GCertificateChain",
+ "ManufacturerRootCertificate",
+ "OEMRootCertificate"
+ ]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateType": {
+ "description": "Indicates the type of certificates requested. When omitted, all certificate types are requested.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/GetCertificateIdUseEnumType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetInstalledCertificateIdsResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GetCertificateIdUseEnumType": {
+ "description": "Indicates the type of the requested certificate(s).\r\n",
+ "javaType": "GetCertificateIdUseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "V2GRootCertificate",
+ "MORootCertificate",
+ "CSMSRootCertificate",
+ "V2GCertificateChain",
+ "ManufacturerRootCertificate",
+ "OEMRootCertificate"
+ ]
+ },
+ "GetInstalledCertificateStatusEnumType": {
+ "description": "Charging Station indicates if it can process the request.\r\n",
+ "javaType": "GetInstalledCertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "NotFound"]
+ },
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "CertificateHashDataChainType": {
+ "javaType": "CertificateHashDataChain",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateHashData": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ },
+ "certificateType": {
+ "$ref": "#/definitions/GetCertificateIdUseEnumType"
+ },
+ "childCertificateHashData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["certificateType", "certificateHashData"]
+ },
+ "CertificateHashDataType": {
+ "javaType": "CertificateHashData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "The hash of the issuer\u2019s distinguished\r\nname (DN), that must be calculated over the DER\r\nencoding of the issuer\u2019s name field in the certificate\r\nbeing checked.\r\n\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "The hash of the DER encoded public key:\r\nthe value (excluding tag and length) of the subject\r\npublic key field in the issuer\u2019s certificate.\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The string representation of the\r\nhexadecimal value of the serial number without the\r\nprefix \"0x\" and without leading zeroes.\r\n",
+ "type": "string",
+ "maxLength": 40
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["hashAlgorithm", "issuerNameHash", "issuerKeyHash", "serialNumber"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GetInstalledCertificateStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "certificateHashDataChain": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CertificateHashDataChainType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetLocalListVersionRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetLocalListVersionResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "versionNumber": {
+ "description": "This contains the current version number of the local authorization list in the Charging Station.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["versionNumber"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetLogRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "LogEnumType": {
+ "description": "This contains the type of log file that the Charging Station\r\nshould send.\r\n",
+ "javaType": "LogEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["DiagnosticsLog", "SecurityLog", "DataCollectorLog"]
+ },
+ "LogParametersType": {
+ "description": "Generic class for the configuration of logging entries.\r\n",
+ "javaType": "LogParameters",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "remoteLocation": {
+ "description": "The URL of the location at the remote system where the log should be stored.\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "oldestTimestamp": {
+ "description": "This contains the date and time of the oldest logging information to include in the diagnostics.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "latestTimestamp": {
+ "description": "This contains the date and time of the latest logging information to include in the diagnostics.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["remoteLocation"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "log": {
+ "$ref": "#/definitions/LogParametersType"
+ },
+ "logType": {
+ "$ref": "#/definitions/LogEnumType"
+ },
+ "requestId": {
+ "description": "The Id of this request\r\n",
+ "type": "integer"
+ },
+ "retries": {
+ "description": "This specifies how many times the Charging Station must retry to upload the log before giving up. If this field is not present, it is left to Charging Station to decide how many times it wants to retry. If the value is 0, it means: no retries.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "retryInterval": {
+ "description": "The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charging Station to decide how long to wait between attempts.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["logType", "requestId", "log"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetLogResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "LogStatusEnumType": {
+ "description": "This field indicates whether the Charging Station was able to accept the request.\r\n",
+ "javaType": "LogStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "AcceptedCanceled"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/LogStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "filename": {
+ "description": "This contains the name of the log file that will be uploaded. This field is not present when no logging information is available.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetMonitoringReportRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "MonitoringCriterionEnumType": {
+ "javaType": "MonitoringCriterionEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ThresholdMonitoring", "DeltaMonitoring", "PeriodicMonitoring"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "ComponentVariableType": {
+ "description": "Class to report components, variables and variable attributes and characteristics.\r\n",
+ "javaType": "ComponentVariable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["component"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "componentVariable": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ComponentVariableType"
+ },
+ "minItems": 1
+ },
+ "requestId": {
+ "description": "The Id of the request.\r\n",
+ "type": "integer"
+ },
+ "monitoringCriteria": {
+ "description": "This field contains criteria for components for which a monitoring report is requested\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MonitoringCriterionEnumType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetMonitoringReportResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericDeviceModelStatusEnumType": {
+ "description": "This field indicates whether the Charging Station was able to accept the request.\r\n",
+ "javaType": "GenericDeviceModelStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotSupported", "EmptyResultSet"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericDeviceModelStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetPeriodicEventStreamRequest",
+ "description": "This message is empty. It has no fields.\r\n",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetPeriodicEventStreamResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ConstantStreamDataType": {
+ "javaType": "ConstantStreamData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Uniquely identifies the stream\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "params": {
+ "$ref": "#/definitions/PeriodicEventStreamParamsType"
+ },
+ "variableMonitoringId": {
+ "description": "Id of monitor used to report his event. It can be a preconfigured or hardwired monitor.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "variableMonitoringId", "params"]
+ },
+ "PeriodicEventStreamParamsType": {
+ "javaType": "PeriodicEventStreamParams",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "interval": {
+ "description": "Time in seconds after which stream data is sent.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "values": {
+ "description": "Number of items to be sent together in stream.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "constantStreamData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ConstantStreamDataType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetReportRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ComponentCriterionEnumType": {
+ "javaType": "ComponentCriterionEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Active", "Available", "Enabled", "Problem"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "ComponentVariableType": {
+ "description": "Class to report components, variables and variable attributes and characteristics.\r\n",
+ "javaType": "ComponentVariable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["component"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "componentVariable": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ComponentVariableType"
+ },
+ "minItems": 1
+ },
+ "requestId": {
+ "description": "The Id of the request.\r\n",
+ "type": "integer"
+ },
+ "componentCriteria": {
+ "description": "This field contains criteria for components for which a report is requested\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ComponentCriterionEnumType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetReportResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericDeviceModelStatusEnumType": {
+ "description": "This field indicates whether the Charging Station was able to accept the request.\r\n",
+ "javaType": "GenericDeviceModelStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotSupported", "EmptyResultSet"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericDeviceModelStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetTariffsRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evseId": {
+ "description": "EVSE id to get tariff from. When _evseId_ = 0, this gets tariffs from all EVSEs.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["evseId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetTariffsResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "TariffGetStatusEnumType": {
+ "description": "Status of operation\r\n",
+ "javaType": "TariffGetStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NoTariff"]
+ },
+ "TariffKindEnumType": {
+ "description": "Kind of tariff (driver/default)\r\n",
+ "javaType": "TariffKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["DefaultTariff", "DriverTariff"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "TariffAssignmentType": {
+ "description": "Shows assignment of tariffs to EVSE or IdToken.\r\n",
+ "javaType": "TariffAssignment",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "tariffId": {
+ "description": "Tariff id.\r\n",
+ "type": "string",
+ "maxLength": 60
+ },
+ "tariffKind": {
+ "$ref": "#/definitions/TariffKindEnumType"
+ },
+ "validFrom": {
+ "description": "Date/time when this tariff become active.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "evseIds": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "minItems": 1
+ },
+ "idTokens": {
+ "description": "IdTokens related to tariff\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "string",
+ "maxLength": 255
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["tariffId", "tariffKind"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/TariffGetStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "tariffAssignments": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TariffAssignmentType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetTransactionStatusRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "transactionId": {
+ "description": "The Id of the transaction for which the status is requested.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetTransactionStatusResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "ongoingIndicator": {
+ "description": "Whether the transaction is still ongoing.\r\n",
+ "type": "boolean"
+ },
+ "messagesInQueue": {
+ "description": "Whether there are still message to be delivered.\r\n",
+ "type": "boolean"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["messagesInQueue"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetVariablesRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "AttributeEnumType": {
+ "description": "Attribute type for which value is requested. When absent, default Actual is assumed.\r\n",
+ "javaType": "AttributeEnum",
+ "type": "string",
+ "default": "Actual",
+ "additionalProperties": false,
+ "enum": ["Actual", "Target", "MinSet", "MaxSet"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "GetVariableDataType": {
+ "description": "Class to hold parameters for GetVariables request.\r\n",
+ "javaType": "GetVariableData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "attributeType": {
+ "$ref": "#/definitions/AttributeEnumType"
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["component", "variable"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "getVariableData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/GetVariableDataType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["getVariableData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:GetVariablesResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "AttributeEnumType": {
+ "javaType": "AttributeEnum",
+ "type": "string",
+ "default": "Actual",
+ "additionalProperties": false,
+ "enum": ["Actual", "Target", "MinSet", "MaxSet"]
+ },
+ "GetVariableStatusEnumType": {
+ "javaType": "GetVariableStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Rejected",
+ "UnknownComponent",
+ "UnknownVariable",
+ "NotSupportedAttributeType"
+ ]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "GetVariableResultType": {
+ "description": "Class to hold results of GetVariables request.\r\n",
+ "javaType": "GetVariableResult",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "attributeStatus": {
+ "$ref": "#/definitions/GetVariableStatusEnumType"
+ },
+ "attributeStatusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "attributeType": {
+ "$ref": "#/definitions/AttributeEnumType"
+ },
+ "attributeValue": {
+ "description": "Value of requested attribute type of component-variable. This field can only be empty when the given status is NOT accepted.\r\n\r\nThe Configuration Variable <<configkey-reporting-value-size,ReportingValueSize>> can be used to limit GetVariableResult.attributeValue, VariableAttribute.value and EventData.actualValue. The max size of these values will always remain equal. \r\n\r\n",
+ "type": "string",
+ "maxLength": 2500
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["attributeStatus", "component", "variable"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "getVariableResult": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/GetVariableResultType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["getVariableResult"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:HeartbeatRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:HeartbeatResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "currentTime": {
+ "description": "Contains the current time of the CSMS.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["currentTime"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:InstallCertificateRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "InstallCertificateUseEnumType": {
+ "description": "Indicates the certificate type that is sent.\r\n",
+ "javaType": "InstallCertificateUseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "V2GRootCertificate",
+ "MORootCertificate",
+ "ManufacturerRootCertificate",
+ "CSMSRootCertificate",
+ "OEMRootCertificate"
+ ]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "certificateType": {
+ "$ref": "#/definitions/InstallCertificateUseEnumType"
+ },
+ "certificate": {
+ "description": "A PEM encoded X.509 certificate.\r\n",
+ "type": "string",
+ "maxLength": 10000
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["certificateType", "certificate"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:InstallCertificateResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "InstallCertificateStatusEnumType": {
+ "description": "Charging Station indicates if installation was successful.\r\n",
+ "javaType": "InstallCertificateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Failed"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/InstallCertificateStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:LogStatusNotificationRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "UploadLogStatusEnumType": {
+ "description": "This contains the status of the log upload.\r\n",
+ "javaType": "UploadLogStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "BadMessage",
+ "Idle",
+ "NotSupportedOperation",
+ "PermissionDenied",
+ "Uploaded",
+ "UploadFailure",
+ "Uploading",
+ "AcceptedCanceled"
+ ]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/UploadLogStatusEnumType"
+ },
+ "requestId": {
+ "description": "The request id that was provided in GetLogRequest that started this log upload. This field is mandatory,\r\nunless the message was triggered by a TriggerMessageRequest AND there is no log upload ongoing.\r\n",
+ "type": "integer"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:LogStatusNotificationResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:MeterValuesRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "LocationEnumType": {
+ "description": "Indicates where the measured value has been sampled. Default = \"Outlet\"\r\n\r\n",
+ "javaType": "LocationEnum",
+ "type": "string",
+ "default": "Outlet",
+ "additionalProperties": false,
+ "enum": ["Body", "Cable", "EV", "Inlet", "Outlet", "Upstream"]
+ },
+ "MeasurandEnumType": {
+ "description": "Type of measurement. Default = \"Energy.Active.Import.Register\"\r\n",
+ "javaType": "MeasurandEnum",
+ "type": "string",
+ "default": "Energy.Active.Import.Register",
+ "additionalProperties": false,
+ "enum": [
+ "Current.Export",
+ "Current.Export.Offered",
+ "Current.Export.Minimum",
+ "Current.Import",
+ "Current.Import.Offered",
+ "Current.Import.Minimum",
+ "Current.Offered",
+ "Display.PresentSOC",
+ "Display.MinimumSOC",
+ "Display.TargetSOC",
+ "Display.MaximumSOC",
+ "Display.RemainingTimeToMinimumSOC",
+ "Display.RemainingTimeToTargetSOC",
+ "Display.RemainingTimeToMaximumSOC",
+ "Display.ChargingComplete",
+ "Display.BatteryEnergyCapacity",
+ "Display.InletHot",
+ "Energy.Active.Export.Interval",
+ "Energy.Active.Export.Register",
+ "Energy.Active.Import.Interval",
+ "Energy.Active.Import.Register",
+ "Energy.Active.Import.CableLoss",
+ "Energy.Active.Import.LocalGeneration.Register",
+ "Energy.Active.Net",
+ "Energy.Active.Setpoint.Interval",
+ "Energy.Apparent.Export",
+ "Energy.Apparent.Import",
+ "Energy.Apparent.Net",
+ "Energy.Reactive.Export.Interval",
+ "Energy.Reactive.Export.Register",
+ "Energy.Reactive.Import.Interval",
+ "Energy.Reactive.Import.Register",
+ "Energy.Reactive.Net",
+ "EnergyRequest.Target",
+ "EnergyRequest.Minimum",
+ "EnergyRequest.Maximum",
+ "EnergyRequest.Minimum.V2X",
+ "EnergyRequest.Maximum.V2X",
+ "EnergyRequest.Bulk",
+ "Frequency",
+ "Power.Active.Export",
+ "Power.Active.Import",
+ "Power.Active.Setpoint",
+ "Power.Active.Residual",
+ "Power.Export.Minimum",
+ "Power.Export.Offered",
+ "Power.Factor",
+ "Power.Import.Offered",
+ "Power.Import.Minimum",
+ "Power.Offered",
+ "Power.Reactive.Export",
+ "Power.Reactive.Import",
+ "SoC",
+ "Voltage",
+ "Voltage.Minimum",
+ "Voltage.Maximum"
+ ]
+ },
+ "PhaseEnumType": {
+ "description": "Indicates how the measured value is to be interpreted. For instance between L1 and neutral (L1-N) Please note that not all values of phase are applicable to all Measurands. When phase is absent, the measured value is interpreted as an overall value.\r\n",
+ "javaType": "PhaseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["L1", "L2", "L3", "N", "L1-N", "L2-N", "L3-N", "L1-L2", "L2-L3", "L3-L1"]
+ },
+ "ReadingContextEnumType": {
+ "description": "Type of detail value: start, end or sample. Default = \"Sample.Periodic\"\r\n",
+ "javaType": "ReadingContextEnum",
+ "type": "string",
+ "default": "Sample.Periodic",
+ "additionalProperties": false,
+ "enum": [
+ "Interruption.Begin",
+ "Interruption.End",
+ "Other",
+ "Sample.Clock",
+ "Sample.Periodic",
+ "Transaction.Begin",
+ "Transaction.End",
+ "Trigger"
+ ]
+ },
+ "MeterValueType": {
+ "description": "Collection of one or more sampled values in MeterValuesRequest and TransactionEvent. All sampled values in a MeterValue are sampled at the same point in time.\r\n",
+ "javaType": "MeterValue",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "sampledValue": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SampledValueType"
+ },
+ "minItems": 1
+ },
+ "timestamp": {
+ "description": "Timestamp for measured value(s).\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["timestamp", "sampledValue"]
+ },
+ "SampledValueType": {
+ "description": "Single sampled value in MeterValues. Each value can be accompanied by optional fields.\r\n\r\nTo save on mobile data usage, default values of all of the optional fields are such that. The value without any additional fields will be interpreted, as a register reading of active import energy in Wh (Watt-hour) units.\r\n",
+ "javaType": "SampledValue",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "value": {
+ "description": "Indicates the measured value.\r\n\r\n",
+ "type": "number"
+ },
+ "measurand": {
+ "$ref": "#/definitions/MeasurandEnumType"
+ },
+ "context": {
+ "$ref": "#/definitions/ReadingContextEnumType"
+ },
+ "phase": {
+ "$ref": "#/definitions/PhaseEnumType"
+ },
+ "location": {
+ "$ref": "#/definitions/LocationEnumType"
+ },
+ "signedMeterValue": {
+ "$ref": "#/definitions/SignedMeterValueType"
+ },
+ "unitOfMeasure": {
+ "$ref": "#/definitions/UnitOfMeasureType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["value"]
+ },
+ "SignedMeterValueType": {
+ "description": "Represent a signed version of the meter value.\r\n",
+ "javaType": "SignedMeterValue",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "signedMeterData": {
+ "description": "Base64 encoded, contains the signed data from the meter in the format specified in _encodingMethod_, which might contain more then just the meter value. It can contain information like timestamps, reference to a customer etc.\r\n",
+ "type": "string",
+ "maxLength": 32768
+ },
+ "signingMethod": {
+ "description": "*(2.1)* Method used to create the digital signature. Optional, if already included in _signedMeterData_. Standard values for this are defined in Appendix as SigningMethodEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "encodingMethod": {
+ "description": "Format used by the energy meter to encode the meter data. For example: OCMF or EDL.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "publicKey": {
+ "description": "*(2.1)* Base64 encoded, sending depends on configuration variable _PublicKeyWithSignedMeterValue_.\r\n",
+ "type": "string",
+ "maxLength": 2500
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["signedMeterData", "encodingMethod"]
+ },
+ "UnitOfMeasureType": {
+ "description": "Represents a UnitOfMeasure with a multiplier\r\n",
+ "javaType": "UnitOfMeasure",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "unit": {
+ "description": "Unit of the value. Default = \"Wh\" if the (default) measurand is an \"Energy\" type.\r\nThis field SHALL use a value from the list Standardized Units of Measurements in Part 2 Appendices. \r\nIf an applicable unit is available in that list, otherwise a \"custom\" unit might be used.\r\n",
+ "type": "string",
+ "default": "Wh",
+ "maxLength": 20
+ },
+ "multiplier": {
+ "description": "Multiplier, this value represents the exponent to base 10. I.e. multiplier 3 means 10 raised to the 3rd power. Default is 0. +\r\nThe _multiplier_ only multiplies the value of the measurand. It does not specify a conversion between units, for example, kW and W.\r\n",
+ "type": "integer",
+ "default": 0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evseId": {
+ "description": "This contains a number (>0) designating an EVSE of the Charging Station. \u20180\u2019 (zero) is used to designate the main power meter.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "meterValue": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MeterValueType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["evseId", "meterValue"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:MeterValuesResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyAllowedEnergyTransferRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "EnergyTransferModeEnumType": {
+ "javaType": "EnergyTransferModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "AC_single_phase",
+ "AC_two_phase",
+ "AC_three_phase",
+ "DC",
+ "AC_BPT",
+ "AC_BPT_DER",
+ "AC_DER",
+ "DC_BPT",
+ "DC_ACDP",
+ "DC_ACDP_BPT",
+ "WPT"
+ ]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "transactionId": {
+ "description": "The transaction for which the allowed energy transfer is allowed.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "allowedEnergyTransfer": {
+ "description": "Modes of energy transfer that are accepted by CSMS.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/EnergyTransferModeEnumType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["transactionId", "allowedEnergyTransfer"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyAllowedEnergyTransferResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "NotifyAllowedEnergyTransferStatusEnumType": {
+ "javaType": "NotifyAllowedEnergyTransferStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/NotifyAllowedEnergyTransferStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyChargingLimitRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingRateUnitEnumType": {
+ "description": "The unit of measure in which limits and setpoints are expressed.\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "CostKindEnumType": {
+ "description": "The kind of cost referred to in the message element amount\r\n",
+ "javaType": "CostKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CarbonDioxideEmission", "RelativePricePercentage", "RenewableGenerationPercentage"]
+ },
+ "OperationModeEnumType": {
+ "description": "*(2.1)* Charging operation mode to use during this time interval. When absent defaults to `ChargingOnly`.\r\n",
+ "javaType": "OperationModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Idle",
+ "ChargingOnly",
+ "CentralSetpoint",
+ "ExternalSetpoint",
+ "ExternalLimits",
+ "CentralFrequency",
+ "LocalFrequency",
+ "LocalLoadBalancing"
+ ]
+ },
+ "AbsolutePriceScheduleType": {
+ "description": "The AbsolutePriceScheduleType is modeled after the same type that is defined in ISO 15118-20, such that if it is supplied by an EMSP as a signed EXI message, the conversion from EXI to JSON (in OCPP) and back to EXI (for ISO 15118-20) does not change the digest and therefore does not invalidate the signature.\r\n\r\nimage::images/AbsolutePriceSchedule-Simple.png[]\r\n\r\n",
+ "javaType": "AbsolutePriceSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "timeAnchor": {
+ "description": "Starting point of price schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleID": {
+ "description": "Unique ID of price schedule\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "priceScheduleDescription": {
+ "description": "Description of the price schedule.\r\n",
+ "type": "string",
+ "maxLength": 160
+ },
+ "currency": {
+ "description": "Currency according to ISO 4217.\r\n",
+ "type": "string",
+ "maxLength": 3
+ },
+ "language": {
+ "description": "String that indicates what language is used for the human readable strings in the price schedule. Based on ISO 639.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "priceAlgorithm": {
+ "description": "A string in URN notation which shall uniquely identify an algorithm that defines how to compute an energy fee sum for a specific power profile based on the EnergyFee information from the PriceRule elements.\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "minimumCost": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "maximumCost": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "priceRuleStacks": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceRuleStackType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "taxRules": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 10
+ },
+ "overstayRuleList": {
+ "$ref": "#/definitions/OverstayRuleListType"
+ },
+ "additionalSelectedServices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalSelectedServicesType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "timeAnchor",
+ "priceScheduleID",
+ "currency",
+ "language",
+ "priceAlgorithm",
+ "priceRuleStacks"
+ ]
+ },
+ "AdditionalSelectedServicesType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "AdditionalSelectedServices",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "serviceFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "serviceName": {
+ "description": "Human readable string to identify this service.\r\n",
+ "type": "string",
+ "maxLength": 80
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["serviceName", "serviceFee"]
+ },
+ "ChargingLimitType": {
+ "javaType": "ChargingLimit",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "chargingLimitSource": {
+ "description": "Represents the source of the charging limit. Values defined in appendix as ChargingLimitSourceEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "isLocalGeneration": {
+ "description": "*(2.1)* True when the reported limit concerns local generation that is providing extra capacity, instead of a limitation.\r\n",
+ "type": "boolean"
+ },
+ "isGridCritical": {
+ "description": "Indicates whether the charging limit is critical for the grid.\r\n",
+ "type": "boolean"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["chargingLimitSource"]
+ },
+ "ChargingSchedulePeriodType": {
+ "description": "Charging schedule period structure defines a time period in a charging schedule. It is used in: CompositeScheduleType and in ChargingScheduleType. When used in a NotifyEVChargingScheduleRequest only _startPeriod_, _limit_, _limit_L2_, _limit_L3_ are relevant.\r\n",
+ "javaType": "ChargingSchedulePeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startPeriod": {
+ "description": "Start of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.\r\n",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Optional only when not required by the _operationMode_, as in CentralSetpoint, ExternalSetpoint, ExternalLimits, LocalFrequency, LocalLoadBalancing. +\r\nCharging rate limit during the schedule period, in the applicable _chargingRateUnit_. \r\nThis SHOULD be a non-negative value; a negative value is only supported for backwards compatibility with older systems that use a negative value to specify a discharging limit.\r\nWhen using _chargingRateUnit_ = `W`, this field represents the sum of the power of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "limit_L2": {
+ "description": "*(2.1)* Charging rate limit on phase L2 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "limit_L3": {
+ "description": "*(2.1)* Charging rate limit on phase L3 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "numberPhases": {
+ "description": "The number of phases that can be used for charging. +\r\nFor a DC EVSE this field should be omitted. +\r\nFor an AC EVSE a default value of _numberPhases_ = 3 will be assumed if the field is absent.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "phaseToUse": {
+ "description": "Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true. It\u2019s not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "dischargeLimit": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ that the EV is allowed to discharge with. Note, these are negative values in order to be consistent with _setpoint_, which can be positive and negative. +\r\nFor AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L2": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L2 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L3": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L3 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "setpoint": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow as close as possible. Use negative values for discharging. +\r\nWhen a limit and/or _dischargeLimit_ are given the overshoot when following _setpoint_ must remain within these values.\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpoint_L2": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L2 as close as possible.\r\n",
+ "type": "number"
+ },
+ "setpoint_L3": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L3 as close as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow as closely as possible. Positive values for inductive, negative for capacitive reactive power or current. +\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpointReactive_L2": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L2 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive_L3": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L3 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "preconditioningRequest": {
+ "description": "*(2.1)* If true, the EV should attempt to keep the BMS preconditioned for this time interval.\r\n",
+ "type": "boolean"
+ },
+ "evseSleep": {
+ "description": "*(2.1)* If true, the EVSE must turn off power electronics/modules associated with this transaction. Default value when absent is false.\r\n",
+ "type": "boolean"
+ },
+ "v2xBaseline": {
+ "description": "*(2.1)* Power value that, when present, is used as a baseline on top of which values from _v2xFreqWattCurve_ and _v2xSignalWattCurve_ are added.\r\n\r\n",
+ "type": "number"
+ },
+ "operationMode": {
+ "$ref": "#/definitions/OperationModeEnumType"
+ },
+ "v2xFreqWattCurve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/V2XFreqWattPointType"
+ },
+ "minItems": 1,
+ "maxItems": 20
+ },
+ "v2xSignalWattCurve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/V2XSignalWattPointType"
+ },
+ "minItems": 1,
+ "maxItems": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startPeriod"]
+ },
+ "ChargingScheduleType": {
+ "description": "Charging schedule structure defines a list of charging periods, as used in: NotifyEVChargingScheduleRequest and ChargingProfileType. When used in a NotifyEVChargingScheduleRequest only _duration_ and _chargingSchedulePeriod_ are relevant and _chargingRateUnit_ must be 'W'. +\r\nAn ISO 15118-20 session may provide either an _absolutePriceSchedule_ or a _priceLevelSchedule_. An ISO 15118-2 session can only provide a_salesTariff_ element. The field _digestValue_ is used when price schedule or sales tariff are signed.\r\n\r\nimage::images/ChargingSchedule-Simple.png[]\r\n\r\n\r\n",
+ "javaType": "ChargingSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "integer"
+ },
+ "limitAtSoC": {
+ "$ref": "#/definitions/LimitAtSoCType"
+ },
+ "startSchedule": {
+ "description": "Starting point of an absolute schedule or recurring schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction in case startSchedule is absent.\r\n",
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "minChargingRate": {
+ "description": "Minimum charging rate supported by the EV. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates. \r\n",
+ "type": "number"
+ },
+ "powerTolerance": {
+ "description": "*(2.1)* Power tolerance when following EVPowerProfile.\r\n\r\n",
+ "type": "number"
+ },
+ "signatureId": {
+ "description": "*(2.1)* Id of this element for referencing in a signature.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "digestValue": {
+ "description": "*(2.1)* Base64 encoded hash (SHA256 for ISO 15118-2, SHA512 for ISO 15118-20) of the EXI price schedule element. Used in signature.\r\n",
+ "type": "string",
+ "maxLength": 88
+ },
+ "useLocalTime": {
+ "description": "*(2.1)* Defaults to false. When true, disregard time zone offset in dateTime fields of _ChargingScheduleType_ and use unqualified local time at Charging Station instead.\r\n This allows the same `Absolute` or `Recurring` charging profile to be used in both summer and winter time.\r\n\r\n",
+ "type": "boolean"
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingSchedulePeriodType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "randomizedDelay": {
+ "description": "*(2.1)* Defaults to 0. When _randomizedDelay_ not equals zero, then the start of each <<cmn_chargingscheduleperiodtype,ChargingSchedulePeriodType>> is delayed by a randomly chosen number of seconds between 0 and _randomizedDelay_. Only allowed for TxProfile and TxDefaultProfile.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariff": {
+ "$ref": "#/definitions/SalesTariffType"
+ },
+ "absolutePriceSchedule": {
+ "$ref": "#/definitions/AbsolutePriceScheduleType"
+ },
+ "priceLevelSchedule": {
+ "$ref": "#/definitions/PriceLevelScheduleType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "chargingRateUnit", "chargingSchedulePeriod"]
+ },
+ "ConsumptionCostType": {
+ "javaType": "ConsumptionCost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startValue": {
+ "description": "The lowest level of consumption that defines the starting point of this consumption block. The block interval extends to the start of the next interval.\r\n",
+ "type": "number"
+ },
+ "cost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startValue", "cost"]
+ },
+ "CostType": {
+ "javaType": "Cost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "costKind": {
+ "$ref": "#/definitions/CostKindEnumType"
+ },
+ "amount": {
+ "description": "The estimated or actual cost per kWh\r\n",
+ "type": "integer"
+ },
+ "amountMultiplier": {
+ "description": "Values: -3..3, The amountMultiplier defines the exponent to base 10 (dec). The final value is determined by: amount * 10 ^ amountMultiplier\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["costKind", "amount"]
+ },
+ "LimitAtSoCType": {
+ "javaType": "LimitAtSoC",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "soc": {
+ "description": "The SoC value beyond which the charging rate limit should be applied.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "limit": {
+ "description": "Charging rate limit beyond the SoC value.\r\nThe unit is defined by _chargingSchedule.chargingRateUnit_.\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["soc", "limit"]
+ },
+ "OverstayRuleListType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "OverstayRuleList",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "overstayPowerThreshold": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "overstayRule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/OverstayRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "overstayTimeThreshold": {
+ "description": "Time till overstay is applied in seconds.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["overstayRule"]
+ },
+ "OverstayRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "OverstayRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "overstayFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "overstayRuleDescription": {
+ "description": "Human readable string to identify the overstay rule.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "startTime": {
+ "description": "Time in seconds after trigger of the parent Overstay Rules for this particular fee to apply.\r\n",
+ "type": "integer"
+ },
+ "overstayFeePeriod": {
+ "description": "Time till overstay will be reapplied\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startTime", "overstayFeePeriod", "overstayFee"]
+ },
+ "PriceLevelScheduleEntryType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n",
+ "javaType": "PriceLevelScheduleEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "The amount of seconds that define the duration of this given PriceLevelScheduleEntry.\r\n",
+ "type": "integer"
+ },
+ "priceLevel": {
+ "description": "Defines the price level of this PriceLevelScheduleEntry (referring to NumberOfPriceLevels). Small values for the PriceLevel represent a cheaper PriceLevelScheduleEntry. Large values for the PriceLevel represent a more expensive PriceLevelScheduleEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "priceLevel"]
+ },
+ "PriceLevelScheduleType": {
+ "description": "The PriceLevelScheduleType is modeled after the same type that is defined in ISO 15118-20, such that if it is supplied by an EMSP as a signed EXI message, the conversion from EXI to JSON (in OCPP) and back to EXI (for ISO 15118-20) does not change the digest and therefore does not invalidate the signature.\r\n",
+ "javaType": "PriceLevelSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priceLevelScheduleEntries": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceLevelScheduleEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 100
+ },
+ "timeAnchor": {
+ "description": "Starting point of this price schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleId": {
+ "description": "Unique ID of this price schedule.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "priceScheduleDescription": {
+ "description": "Description of the price schedule.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numberOfPriceLevels": {
+ "description": "Defines the overall number of distinct price level elements used across all PriceLevelSchedules.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "timeAnchor",
+ "priceScheduleId",
+ "numberOfPriceLevels",
+ "priceLevelScheduleEntries"
+ ]
+ },
+ "PriceRuleStackType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n",
+ "javaType": "PriceRuleStack",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "Duration of the stack of price rules. he amount of seconds that define the duration of the given PriceRule(s).\r\n",
+ "type": "integer"
+ },
+ "priceRule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 8
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "priceRule"]
+ },
+ "PriceRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "PriceRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "parkingFeePeriod": {
+ "description": "The duration of the parking fee period (in seconds).\r\nWhen the time enters into a ParkingFeePeriod, the ParkingFee will apply to the session. .\r\n",
+ "type": "integer"
+ },
+ "carbonDioxideEmission": {
+ "description": "Number of grams of CO2 per kWh.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "renewableGenerationPercentage": {
+ "description": "Percentage of the power that is created by renewable resources.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "energyFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "parkingFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "powerRangeStart": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["energyFee", "powerRangeStart"]
+ },
+ "RationalNumberType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "RationalNumber",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "exponent": {
+ "description": "The exponent to base 10 (dec)\r\n",
+ "type": "integer"
+ },
+ "value": {
+ "description": "Value which shall be multiplied.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["exponent", "value"]
+ },
+ "RelativeTimeIntervalType": {
+ "javaType": "RelativeTimeInterval",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "start": {
+ "description": "Start of the interval, in seconds from NOW.\r\n",
+ "type": "integer"
+ },
+ "duration": {
+ "description": "Duration of the interval, in seconds.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["start"]
+ },
+ "SalesTariffEntryType": {
+ "javaType": "SalesTariffEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "relativeTimeInterval": {
+ "$ref": "#/definitions/RelativeTimeIntervalType"
+ },
+ "ePriceLevel": {
+ "description": "Defines the price level of this SalesTariffEntry (referring to NumEPriceLevels). Small values for the EPriceLevel represent a cheaper TariffEntry. Large values for the EPriceLevel represent a more expensive TariffEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "consumptionCost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ConsumptionCostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["relativeTimeInterval"]
+ },
+ "SalesTariffType": {
+ "description": "A SalesTariff provided by a Mobility Operator (EMSP) .\r\nNOTE: This dataType is based on dataTypes from <<ref-ISOIEC15118-2,ISO 15118-2>>.\r\n",
+ "javaType": "SalesTariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "SalesTariff identifier used to identify one sales tariff. An SAID remains a unique identifier for one schedule throughout a charging session.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariffDescription": {
+ "description": "A human readable title/short description of the sales tariff e.g. for HMI display purposes.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numEPriceLevels": {
+ "description": "Defines the overall number of distinct price levels used across all provided SalesTariff elements.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariffEntry": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SalesTariffEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "salesTariffEntry"]
+ },
+ "TaxRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "TaxRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "taxRuleID": {
+ "description": "Id for the tax rule.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "taxRuleName": {
+ "description": "Human readable string to identify the tax rule.\r\n",
+ "type": "string",
+ "maxLength": 100
+ },
+ "taxIncludedInPrice": {
+ "description": "Indicates whether the tax is included in any price or not.\r\n",
+ "type": "boolean"
+ },
+ "appliesToEnergyFee": {
+ "description": "Indicates whether this tax applies to Energy Fees.\r\n",
+ "type": "boolean"
+ },
+ "appliesToParkingFee": {
+ "description": "Indicates whether this tax applies to Parking Fees.\r\n\r\n",
+ "type": "boolean"
+ },
+ "appliesToOverstayFee": {
+ "description": "Indicates whether this tax applies to Overstay Fees.\r\n\r\n",
+ "type": "boolean"
+ },
+ "appliesToMinimumMaximumCost": {
+ "description": "Indicates whether this tax applies to Minimum/Maximum Cost.\r\n\r\n",
+ "type": "boolean"
+ },
+ "taxRate": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "taxRuleID",
+ "appliesToEnergyFee",
+ "appliesToParkingFee",
+ "appliesToOverstayFee",
+ "appliesToMinimumMaximumCost",
+ "taxRate"
+ ]
+ },
+ "V2XFreqWattPointType": {
+ "description": "*(2.1)* A point of a frequency-watt curve.\r\n",
+ "javaType": "V2XFreqWattPoint",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "frequency": {
+ "description": "Net frequency in Hz.\r\n",
+ "type": "number"
+ },
+ "power": {
+ "description": "Power in W to charge (positive) or discharge (negative) at specified frequency.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["frequency", "power"]
+ },
+ "V2XSignalWattPointType": {
+ "description": "*(2.1)* A point of a signal-watt curve.\r\n",
+ "javaType": "V2XSignalWattPoint",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "signal": {
+ "description": "Signal value from an AFRRSignalRequest.\r\n",
+ "type": "integer"
+ },
+ "power": {
+ "description": "Power in W to charge (positive) or discharge (negative) at specified frequency.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["signal", "power"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "chargingSchedule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingScheduleType"
+ },
+ "minItems": 1
+ },
+ "evseId": {
+ "description": "The EVSE to which the charging limit is set. If absent or when zero, it applies to the entire Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "chargingLimit": {
+ "$ref": "#/definitions/ChargingLimitType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["chargingLimit"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyChargingLimitResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyCustomerInformationRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "data": {
+ "description": "(Part of) the requested data. No format specified in which the data is returned. Should be human readable.\r\n",
+ "type": "string",
+ "maxLength": 512
+ },
+ "tbc": {
+ "description": "\u201cto be continued\u201d indicator. Indicates whether another part of the monitoringData follows in an upcoming notifyMonitoringReportRequest message. Default value when omitted is false.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "seqNo": {
+ "description": "Sequence number of this message. First message starts at 0.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "generatedAt": {
+ "description": " Timestamp of the moment this message was generated at the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "requestId": {
+ "description": "The Id of the request.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["data", "seqNo", "generatedAt", "requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyCustomerInformationResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyDERAlarmRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DERControlEnumType": {
+ "description": "Name of DER control, e.g. LFMustTrip\r\n",
+ "javaType": "DERControlEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "EnterService",
+ "FreqDroop",
+ "FreqWatt",
+ "FixedPFAbsorb",
+ "FixedPFInject",
+ "FixedVar",
+ "Gradients",
+ "HFMustTrip",
+ "HFMayTrip",
+ "HVMustTrip",
+ "HVMomCess",
+ "HVMayTrip",
+ "LimitMaxDischarge",
+ "LFMustTrip",
+ "LVMustTrip",
+ "LVMomCess",
+ "LVMayTrip",
+ "PowerMonitoringMustTrip",
+ "VoltVar",
+ "VoltWatt",
+ "WattPF",
+ "WattVar"
+ ]
+ },
+ "GridEventFaultEnumType": {
+ "description": "Type of grid event that caused this\r\n\r\n",
+ "javaType": "GridEventFaultEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "CurrentImbalance",
+ "LocalEmergency",
+ "LowInputPower",
+ "OverCurrent",
+ "OverFrequency",
+ "OverVoltage",
+ "PhaseRotation",
+ "RemoteEmergency",
+ "UnderFrequency",
+ "UnderVoltage",
+ "VoltageImbalance"
+ ]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "controlType": {
+ "$ref": "#/definitions/DERControlEnumType"
+ },
+ "gridEventFault": {
+ "$ref": "#/definitions/GridEventFaultEnumType"
+ },
+ "alarmEnded": {
+ "description": "True when error condition has ended.\r\nAbsent or false when alarm has started.\r\n\r\n",
+ "type": "boolean"
+ },
+ "timestamp": {
+ "description": "Time of start or end of alarm.\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "extraInfo": {
+ "description": "Optional info provided by EV.\r\n\r\n",
+ "type": "string",
+ "maxLength": 200
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["controlType", "timestamp"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyDERAlarmResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyDERStartStopRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "controlId": {
+ "description": "Id of the started or stopped DER control.\r\nCorresponds to the _controlId_ of the SetDERControlRequest.\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "started": {
+ "description": "True if DER control has started. False if it has ended.\r\n\r\n",
+ "type": "boolean"
+ },
+ "timestamp": {
+ "description": "Time of start or end of event.\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "supersededIds": {
+ "description": "List of controlIds that are superseded as a result of this control starting.\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "string",
+ "maxLength": 36
+ },
+ "minItems": 1,
+ "maxItems": 24
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["controlId", "started", "timestamp"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyDERStartStopResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyDisplayMessagesRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "MessageFormatEnumType": {
+ "description": "Format of the message.\r\n",
+ "javaType": "MessageFormatEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ASCII", "HTML", "URI", "UTF8", "QRCODE"]
+ },
+ "MessagePriorityEnumType": {
+ "description": "With what priority should this message be shown\r\n",
+ "javaType": "MessagePriorityEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["AlwaysFront", "InFront", "NormalCycle"]
+ },
+ "MessageStateEnumType": {
+ "description": "During what state should this message be shown. When omitted this message should be shown in any state of the Charging Station.\r\n",
+ "javaType": "MessageStateEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Charging", "Faulted", "Idle", "Unavailable", "Suspended", "Discharging"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "MessageContentType": {
+ "description": "Contains message details, for a message to be displayed on a Charging Station.\r\n\r\n",
+ "javaType": "MessageContent",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "format": {
+ "$ref": "#/definitions/MessageFormatEnumType"
+ },
+ "language": {
+ "description": "Message language identifier. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "content": {
+ "description": "*(2.1)* Required. Message contents. +\r\nMaximum length supported by Charging Station is given in OCPPCommCtrlr.FieldLength[\"MessageContentType.content\"].\r\n Maximum length defaults to 1024.\r\n\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["format", "content"]
+ },
+ "MessageInfoType": {
+ "description": "Contains message details, for a message to be displayed on a Charging Station.\r\n",
+ "javaType": "MessageInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "display": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "id": {
+ "description": "Unique id within an exchange context. It is defined within the OCPP context as a positive Integer value (greater or equal to zero).\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "priority": {
+ "$ref": "#/definitions/MessagePriorityEnumType"
+ },
+ "state": {
+ "$ref": "#/definitions/MessageStateEnumType"
+ },
+ "startDateTime": {
+ "description": "From what date-time should this message be shown. If omitted: directly.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "endDateTime": {
+ "description": "Until what date-time should this message be shown, after this date/time this message SHALL be removed.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "transactionId": {
+ "description": "During which transaction shall this message be shown.\r\nMessage SHALL be removed by the Charging Station after transaction has\r\nended.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "message": {
+ "$ref": "#/definitions/MessageContentType"
+ },
+ "messageExtra": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MessageContentType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "priority", "message"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "messageInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MessageInfoType"
+ },
+ "minItems": 1
+ },
+ "requestId": {
+ "description": "The id of the <<getdisplaymessagesrequest,GetDisplayMessagesRequest>> that requested this message.\r\n",
+ "type": "integer"
+ },
+ "tbc": {
+ "description": "\"to be continued\" indicator. Indicates whether another part of the report follows in an upcoming NotifyDisplayMessagesRequest message. Default value when omitted is false.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyDisplayMessagesResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyEVChargingNeedsRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ControlModeEnumType": {
+ "description": "*(2.1)* Indicates whether EV wants to operate in Dynamic or Scheduled mode. When absent, Scheduled mode is assumed for backwards compatibility. +\r\n*ISO 15118-20:* +\r\nServiceSelectionReq(SelectedEnergyTransferService)\r\n",
+ "javaType": "ControlModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ScheduledControl", "DynamicControl"]
+ },
+ "DERControlEnumType": {
+ "javaType": "DERControlEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "EnterService",
+ "FreqDroop",
+ "FreqWatt",
+ "FixedPFAbsorb",
+ "FixedPFInject",
+ "FixedVar",
+ "Gradients",
+ "HFMustTrip",
+ "HFMayTrip",
+ "HVMustTrip",
+ "HVMomCess",
+ "HVMayTrip",
+ "LimitMaxDischarge",
+ "LFMustTrip",
+ "LVMustTrip",
+ "LVMomCess",
+ "LVMayTrip",
+ "PowerMonitoringMustTrip",
+ "VoltVar",
+ "VoltWatt",
+ "WattPF",
+ "WattVar"
+ ]
+ },
+ "EnergyTransferModeEnumType": {
+ "description": "Mode of energy transfer requested by the EV.\r\n",
+ "javaType": "EnergyTransferModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "AC_single_phase",
+ "AC_two_phase",
+ "AC_three_phase",
+ "DC",
+ "AC_BPT",
+ "AC_BPT_DER",
+ "AC_DER",
+ "DC_BPT",
+ "DC_ACDP",
+ "DC_ACDP_BPT",
+ "WPT"
+ ]
+ },
+ "IslandingDetectionEnumType": {
+ "javaType": "IslandingDetectionEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "NoAntiIslandingSupport",
+ "RoCoF",
+ "UVP_OVP",
+ "UFP_OFP",
+ "VoltageVectorShift",
+ "ZeroCrossingDetection",
+ "OtherPassive",
+ "ImpedanceMeasurement",
+ "ImpedanceAtFrequency",
+ "SlipModeFrequencyShift",
+ "SandiaFrequencyShift",
+ "SandiaVoltageShift",
+ "FrequencyJump",
+ "RCLQFactor",
+ "OtherActive"
+ ]
+ },
+ "MobilityNeedsModeEnumType": {
+ "description": "*(2.1)* Value of EVCC indicates that EV determines min/target SOC and departure time. +\r\nA value of EVCC_SECC indicates that charging station or CSMS may also update min/target SOC and departure time. +\r\n*ISO 15118-20:* +\r\nServiceSelectionReq(SelectedEnergyTransferService)\r\n",
+ "javaType": "MobilityNeedsModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["EVCC", "EVCC_SECC"]
+ },
+ "ACChargingParametersType": {
+ "description": "EV AC charging parameters for ISO 15118-2\r\n\r\n",
+ "javaType": "ACChargingParameters",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "energyAmount": {
+ "description": "Amount of energy requested (in Wh). This includes energy required for preconditioning.\r\nRelates to: +\r\n*ISO 15118-2*: AC_EVChargeParameterType: EAmount +\r\n*ISO 15118-20*: Dynamic/Scheduled_SEReqControlModeType: EVTargetEnergyRequest\r\n\r\n",
+ "type": "number"
+ },
+ "evMinCurrent": {
+ "description": "Minimum current (amps) supported by the electric vehicle (per phase).\r\nRelates to: +\r\n*ISO 15118-2*: AC_EVChargeParameterType: EVMinCurrent\r\n\r\n",
+ "type": "number"
+ },
+ "evMaxCurrent": {
+ "description": "Maximum current (amps) supported by the electric vehicle (per phase). Includes cable capacity.\r\nRelates to: +\r\n*ISO 15118-2*: AC_EVChargeParameterType: EVMaxCurrent\r\n\r\n",
+ "type": "number"
+ },
+ "evMaxVoltage": {
+ "description": "Maximum voltage supported by the electric vehicle.\r\nRelates to: +\r\n*ISO 15118-2*: AC_EVChargeParameterType: EVMaxVoltage\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["energyAmount", "evMinCurrent", "evMaxCurrent", "evMaxVoltage"]
+ },
+ "ChargingNeedsType": {
+ "javaType": "ChargingNeeds",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "acChargingParameters": {
+ "$ref": "#/definitions/ACChargingParametersType"
+ },
+ "derChargingParameters": {
+ "$ref": "#/definitions/DERChargingParametersType"
+ },
+ "evEnergyOffer": {
+ "$ref": "#/definitions/EVEnergyOfferType"
+ },
+ "requestedEnergyTransfer": {
+ "$ref": "#/definitions/EnergyTransferModeEnumType"
+ },
+ "dcChargingParameters": {
+ "$ref": "#/definitions/DCChargingParametersType"
+ },
+ "v2xChargingParameters": {
+ "$ref": "#/definitions/V2XChargingParametersType"
+ },
+ "availableEnergyTransfer": {
+ "description": "*(2.1)* Modes of energy transfer that are marked as available by EV.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/EnergyTransferModeEnumType"
+ },
+ "minItems": 1
+ },
+ "controlMode": {
+ "$ref": "#/definitions/ControlModeEnumType"
+ },
+ "mobilityNeedsMode": {
+ "$ref": "#/definitions/MobilityNeedsModeEnumType"
+ },
+ "departureTime": {
+ "description": "Estimated departure time of the EV. +\r\n*ISO 15118-2:* AC/DC_EVChargeParameterType: DepartureTime +\r\n*ISO 15118-20:* Dynamic/Scheduled_SEReqControlModeType: DepartureTIme\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestedEnergyTransfer"]
+ },
+ "DCChargingParametersType": {
+ "description": "EV DC charging parameters for ISO 15118-2\r\n",
+ "javaType": "DCChargingParameters",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evMaxCurrent": {
+ "description": "Maximum current (in A) supported by the electric vehicle. Includes cable capacity.\r\nRelates to: +\r\n*ISO 15118-2*: DC_EVChargeParameterType:EVMaximumCurrentLimit\r\n",
+ "type": "number"
+ },
+ "evMaxVoltage": {
+ "description": "Maximum voltage supported by the electric vehicle.\r\nRelates to: +\r\n*ISO 15118-2*: DC_EVChargeParameterType: EVMaximumVoltageLimit\r\n\r\n",
+ "type": "number"
+ },
+ "evMaxPower": {
+ "description": "Maximum power (in W) supported by the electric vehicle. Required for DC charging.\r\nRelates to: +\r\n*ISO 15118-2*: DC_EVChargeParameterType: EVMaximumPowerLimit\r\n\r\n",
+ "type": "number"
+ },
+ "evEnergyCapacity": {
+ "description": "Capacity of the electric vehicle battery (in Wh).\r\nRelates to: +\r\n*ISO 15118-2*: DC_EVChargeParameterType: EVEnergyCapacity\r\n\r\n",
+ "type": "number"
+ },
+ "energyAmount": {
+ "description": "Amount of energy requested (in Wh). This inludes energy required for preconditioning.\r\nRelates to: +\r\n*ISO 15118-2*: DC_EVChargeParameterType: EVEnergyRequest\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "stateOfCharge": {
+ "description": "Energy available in the battery (in percent of the battery capacity)\r\nRelates to: +\r\n*ISO 15118-2*: DC_EVChargeParameterType: DC_EVStatus: EVRESSSOC\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "fullSoC": {
+ "description": "Percentage of SoC at which the EV considers the battery fully charged. (possible values: 0 - 100)\r\nRelates to: +\r\n*ISO 15118-2*: DC_EVChargeParameterType: FullSOC\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "bulkSoC": {
+ "description": "Percentage of SoC at which the EV considers a fast charging process to end. (possible values: 0 - 100)\r\nRelates to: +\r\n*ISO 15118-2*: DC_EVChargeParameterType: BulkSOC\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["evMaxCurrent", "evMaxVoltage"]
+ },
+ "DERChargingParametersType": {
+ "description": "*(2.1)* DERChargingParametersType is used in ChargingNeedsType during an ISO 15118-20 session for AC_BPT_DER to report the inverter settings related to DER control that were agreed between EVSE and EV.\r\n\r\nFields starting with \"ev\" contain values from the EV.\r\nOther fields contain a value that is supported by both EV and EVSE.\r\n\r\nDERChargingParametersType type is only relevant in case of an ISO 15118-20 AC_BPT_DER/AC_DER charging session.\r\n\r\nNOTE: All these fields have values greater or equal to zero (i.e. are non-negative)\r\n\r\n",
+ "javaType": "DERChargingParameters",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evSupportedDERControl": {
+ "description": "DER control functions supported by EV. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType:DERControlFunctions (bitmap)\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/DERControlEnumType"
+ },
+ "minItems": 1
+ },
+ "evOverExcitedMaxDischargePower": {
+ "description": "Rated maximum injected active power by EV, at specified over-excited power factor (overExcitedPowerFactor). +\r\nIt can also be defined as the rated maximum discharge power at the rated minimum injected reactive power value. This means that if the EV is providing reactive power support, and it is requested to discharge at max power (e.g. to satisfy an EMS request), the EV may override the request and discharge up to overExcitedMaximumDischargePower to meet the minimum reactive power requirements. +\r\nCorresponds to the WOvPF attribute in IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVOverExcitedMaximumDischargePower\r\n",
+ "type": "number"
+ },
+ "evOverExcitedPowerFactor": {
+ "description": "EV power factor when injecting (over excited) the minimum reactive power. +\r\nCorresponds to the OvPF attribute in IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVOverExcitedPowerFactor\r\n",
+ "type": "number"
+ },
+ "evUnderExcitedMaxDischargePower": {
+ "description": "Rated maximum injected active power by EV supported at specified under-excited power factor (EVUnderExcitedPowerFactor). +\r\nIt can also be defined as the rated maximum dischargePower at the rated minimum absorbed reactive power value.\r\nThis means that if the EV is providing reactive power support, and it is requested to discharge at max power (e.g. to satisfy an EMS request), the EV may override the request and discharge up to underExcitedMaximumDischargePower to meet the minimum reactive power requirements. +\r\nThis corresponds to the WUnPF attribute in the IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVUnderExcitedMaximumDischargePower\r\n",
+ "type": "number"
+ },
+ "evUnderExcitedPowerFactor": {
+ "description": "EV power factor when injecting (under excited) the minimum reactive power. +\r\nCorresponds to the OvPF attribute in IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVUnderExcitedPowerFactor\r\n",
+ "type": "number"
+ },
+ "maxApparentPower": {
+ "description": "Rated maximum total apparent power, defined by min(EV, EVSE) in va.\r\nCorresponds to the VAMaxRtg in IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumApparentPower\r\n",
+ "type": "number"
+ },
+ "maxChargeApparentPower": {
+ "description": "Rated maximum absorbed apparent power, defined by min(EV, EVSE) in va. +\r\n This field represents the sum of all phases, unless values are provided for L2 and L3,\r\n in which case this field represents phase L1. +\r\n Corresponds to the ChaVAMaxRtg in IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumChargeApparentPower\r\n",
+ "type": "number"
+ },
+ "maxChargeApparentPower_L2": {
+ "description": "Rated maximum absorbed apparent power on phase L2, defined by min(EV, EVSE) in va.\r\nCorresponds to the ChaVAMaxRtg in IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumChargeApparentPower_L2\r\n",
+ "type": "number"
+ },
+ "maxChargeApparentPower_L3": {
+ "description": "Rated maximum absorbed apparent power on phase L3, defined by min(EV, EVSE) in va.\r\nCorresponds to the ChaVAMaxRtg in IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumChargeApparentPower_L3\r\n",
+ "type": "number"
+ },
+ "maxDischargeApparentPower": {
+ "description": "Rated maximum injected apparent power, defined by min(EV, EVSE) in va. +\r\n This field represents the sum of all phases, unless values are provided for L2 and L3,\r\n in which case this field represents phase L1. +\r\n Corresponds to the DisVAMaxRtg in IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumDischargeApparentPower\r\n",
+ "type": "number"
+ },
+ "maxDischargeApparentPower_L2": {
+ "description": "Rated maximum injected apparent power on phase L2, defined by min(EV, EVSE) in va. +\r\n Corresponds to the DisVAMaxRtg in IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumDischargeApparentPower_L2\r\n",
+ "type": "number"
+ },
+ "maxDischargeApparentPower_L3": {
+ "description": "Rated maximum injected apparent power on phase L3, defined by min(EV, EVSE) in va. +\r\n Corresponds to the DisVAMaxRtg in IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumDischargeApparentPower_L3\r\n",
+ "type": "number"
+ },
+ "maxChargeReactivePower": {
+ "description": "Rated maximum absorbed reactive power, defined by min(EV, EVSE), in vars. +\r\n This field represents the sum of all phases, unless values are provided for L2 and L3,\r\n in which case this field represents phase L1. +\r\nCorresponds to the AvarMax attribute in the IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumChargeReactivePower\r\n",
+ "type": "number"
+ },
+ "maxChargeReactivePower_L2": {
+ "description": "Rated maximum absorbed reactive power, defined by min(EV, EVSE), in vars on phase L2. +\r\nCorresponds to the AvarMax attribute in the IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumChargeReactivePower_L2\r\n",
+ "type": "number"
+ },
+ "maxChargeReactivePower_L3": {
+ "description": "Rated maximum absorbed reactive power, defined by min(EV, EVSE), in vars on phase L3. +\r\nCorresponds to the AvarMax attribute in the IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumChargeReactivePower_L3\r\n",
+ "type": "number"
+ },
+ "minChargeReactivePower": {
+ "description": "Rated minimum absorbed reactive power, defined by max(EV, EVSE), in vars. +\r\n This field represents the sum of all phases, unless values are provided for L2 and L3,\r\n in which case this field represents phase L1. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMinimumChargeReactivePower\r\n",
+ "type": "number"
+ },
+ "minChargeReactivePower_L2": {
+ "description": "Rated minimum absorbed reactive power, defined by max(EV, EVSE), in vars on phase L2. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMinimumChargeReactivePower_L2\r\n",
+ "type": "number"
+ },
+ "minChargeReactivePower_L3": {
+ "description": "Rated minimum absorbed reactive power, defined by max(EV, EVSE), in vars on phase L3. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMinimumChargeReactivePower_L3\r\n",
+ "type": "number"
+ },
+ "maxDischargeReactivePower": {
+ "description": "Rated maximum injected reactive power, defined by min(EV, EVSE), in vars. +\r\n This field represents the sum of all phases, unless values are provided for L2 and L3,\r\n in which case this field represents phase L1. +\r\nCorresponds to the IvarMax attribute in the IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumDischargeReactivePower\r\n",
+ "type": "number"
+ },
+ "maxDischargeReactivePower_L2": {
+ "description": "Rated maximum injected reactive power, defined by min(EV, EVSE), in vars on phase L2. +\r\nCorresponds to the IvarMax attribute in the IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumDischargeReactivePower_L2\r\n",
+ "type": "number"
+ },
+ "maxDischargeReactivePower_L3": {
+ "description": "Rated maximum injected reactive power, defined by min(EV, EVSE), in vars on phase L3. +\r\nCorresponds to the IvarMax attribute in the IEC 61850. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumDischargeReactivePower_L3\r\n",
+ "type": "number"
+ },
+ "minDischargeReactivePower": {
+ "description": "Rated minimum injected reactive power, defined by max(EV, EVSE), in vars. +\r\n This field represents the sum of all phases, unless values are provided for L2 and L3,\r\n in which case this field represents phase L1. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMinimumDischargeReactivePower\r\n",
+ "type": "number"
+ },
+ "minDischargeReactivePower_L2": {
+ "description": "Rated minimum injected reactive power, defined by max(EV, EVSE), in var on phase L2. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMinimumDischargeReactivePower_L2\r\n",
+ "type": "number"
+ },
+ "minDischargeReactivePower_L3": {
+ "description": "Rated minimum injected reactive power, defined by max(EV, EVSE), in var on phase L3. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMinimumDischargeReactivePower_L3\r\n",
+ "type": "number"
+ },
+ "nominalVoltage": {
+ "description": "Line voltage supported by EVSE and EV.\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVNominalVoltage\r\n",
+ "type": "number"
+ },
+ "nominalVoltageOffset": {
+ "description": "The nominal AC voltage (rms) offset between the Charging Station's electrical connection point and the utility\u2019s point of common coupling. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVNominalVoltageOffset\r\n",
+ "type": "number"
+ },
+ "maxNominalVoltage": {
+ "description": "Maximum AC rms voltage, as defined by min(EV, EVSE) to operate with. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumNominalVoltage\r\n",
+ "type": "number"
+ },
+ "minNominalVoltage": {
+ "description": "Minimum AC rms voltage, as defined by max(EV, EVSE) to operate with. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMinimumNominalVoltage\r\n",
+ "type": "number"
+ },
+ "evInverterManufacturer": {
+ "description": "Manufacturer of the EV inverter. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVInverterManufacturer\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "evInverterModel": {
+ "description": "Model name of the EV inverter. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVInverterModel\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "evInverterSerialNumber": {
+ "description": "Serial number of the EV inverter. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVInverterSerialNumber\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "evInverterSwVersion": {
+ "description": "Software version of EV inverter. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVInverterSwVersion\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "evInverterHwVersion": {
+ "description": "Hardware version of EV inverter. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVInverterHwVersion\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "evIslandingDetectionMethod": {
+ "description": "Type of islanding detection method. Only mandatory when islanding detection is required at the site, as set in the ISO 15118 Service Details configuration. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVIslandingDetectionMethod\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/IslandingDetectionEnumType"
+ },
+ "minItems": 1
+ },
+ "evIslandingTripTime": {
+ "description": "Time after which EV will trip if an island has been detected. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVIslandingTripTime\r\n",
+ "type": "number"
+ },
+ "evMaximumLevel1DCInjection": {
+ "description": "Maximum injected DC current allowed at level 1 charging. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumLevel1DCInjection\r\n",
+ "type": "number"
+ },
+ "evDurationLevel1DCInjection": {
+ "description": "Maximum allowed duration of DC injection at level 1 charging. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVDurationLevel1DCInjection\r\n",
+ "type": "number"
+ },
+ "evMaximumLevel2DCInjection": {
+ "description": "Maximum injected DC current allowed at level 2 charging. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVMaximumLevel2DCInjection\r\n",
+ "type": "number"
+ },
+ "evDurationLevel2DCInjection": {
+ "description": "Maximum allowed duration of DC injection at level 2 charging. +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVDurationLevel2DCInjection\r\n",
+ "type": "number"
+ },
+ "evReactiveSusceptance": {
+ "description": "\tMeasure of the susceptibility of the circuit to reactance, in Siemens (S). +\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVReactiveSusceptance\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "evSessionTotalDischargeEnergyAvailable": {
+ "description": "Total energy value, in Wh, that EV is allowed to provide during the entire V2G session. The value is independent of the V2X Cycling area. Once this value reaches the value of 0, the EV may block any attempt to discharge in order to protect the battery health.\r\n *ISO 15118-20*: DER_BPT_AC_CPDReqEnergyTransferModeType: EVSessionTotalDischargeEnergyAvailable\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "EVAbsolutePriceScheduleEntryType": {
+ "description": "*(2.1)* An entry in price schedule over time for which EV is willing to discharge.\r\n",
+ "javaType": "EVAbsolutePriceScheduleEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "The amount of seconds of this entry.\r\n",
+ "type": "integer"
+ },
+ "evPriceRule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/EVPriceRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 8
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "evPriceRule"]
+ },
+ "EVAbsolutePriceScheduleType": {
+ "description": "*(2.1)* Price schedule of EV energy offer.\r\n",
+ "javaType": "EVAbsolutePriceSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "timeAnchor": {
+ "description": "Starting point in time of the EVEnergyOffer.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "currency": {
+ "description": "Currency code according to ISO 4217.\r\n",
+ "type": "string",
+ "maxLength": 3
+ },
+ "evAbsolutePriceScheduleEntries": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/EVAbsolutePriceScheduleEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "priceAlgorithm": {
+ "description": "ISO 15118-20 URN of price algorithm: Power, PeakPower, StackedEnergy.\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["timeAnchor", "currency", "priceAlgorithm", "evAbsolutePriceScheduleEntries"]
+ },
+ "EVEnergyOfferType": {
+ "description": "*(2.1)* A schedule of the energy amount over time that EV is willing to discharge. A negative value indicates the willingness to discharge under specific conditions, a positive value indicates that the EV currently is not able to offer energy to discharge. \r\n",
+ "javaType": "EVEnergyOffer",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evAbsolutePriceSchedule": {
+ "$ref": "#/definitions/EVAbsolutePriceScheduleType"
+ },
+ "evPowerSchedule": {
+ "$ref": "#/definitions/EVPowerScheduleType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["evPowerSchedule"]
+ },
+ "EVPowerScheduleEntryType": {
+ "description": "*(2.1)* An entry in schedule of the energy amount over time that EV is willing to discharge. A negative value indicates the willingness to discharge under specific conditions, a positive value indicates that the EV currently is not able to offer energy to discharge.\r\n",
+ "javaType": "EVPowerScheduleEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "The duration of this entry.\r\n",
+ "type": "integer"
+ },
+ "power": {
+ "description": "Defines maximum amount of power for the duration of this EVPowerScheduleEntry to be discharged from the EV battery through EVSE power outlet. Negative values are used for discharging.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "power"]
+ },
+ "EVPowerScheduleType": {
+ "description": "*(2.1)* Schedule of EV energy offer.\r\n",
+ "javaType": "EVPowerSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evPowerScheduleEntries": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/EVPowerScheduleEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "timeAnchor": {
+ "description": "The time that defines the starting point for the EVEnergyOffer.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["timeAnchor", "evPowerScheduleEntries"]
+ },
+ "EVPriceRuleType": {
+ "description": "*(2.1)* An entry in price schedule over time for which EV is willing to discharge.\r\n",
+ "javaType": "EVPriceRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "energyFee": {
+ "description": "Cost per kWh.\r\n",
+ "type": "number"
+ },
+ "powerRangeStart": {
+ "description": "The EnergyFee applies between this value and the value of the PowerRangeStart of the subsequent EVPriceRule. If the power is below this value, the EnergyFee of the previous EVPriceRule applies. Negative values are used for discharging.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["energyFee", "powerRangeStart"]
+ },
+ "V2XChargingParametersType": {
+ "description": "Charging parameters for ISO 15118-20, also supporting V2X charging/discharging.+\r\nAll values are greater or equal to zero, with the exception of EVMinEnergyRequest, EVMaxEnergyRequest, EVTargetEnergyRequest, EVMinV2XEnergyRequest and EVMaxV2XEnergyRequest.\r\n",
+ "javaType": "V2XChargingParameters",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "minChargePower": {
+ "description": "Minimum charge power in W, defined by max(EV, EVSE).\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\nRelates to:\r\n*ISO 15118-20*: BPT_AC/DC_CPDReqEnergyTransferModeType: EVMinimumChargePower\r\n",
+ "type": "number"
+ },
+ "minChargePower_L2": {
+ "description": "Minimum charge power on phase L2 in W, defined by max(EV, EVSE).\r\nRelates to:\r\n*ISO 15118-20*: BPT_AC/DC_CPDReqEnergyTransferModeType: EVMinimumChargePower_L2\r\n",
+ "type": "number"
+ },
+ "minChargePower_L3": {
+ "description": "Minimum charge power on phase L3 in W, defined by max(EV, EVSE).\r\nRelates to:\r\n*ISO 15118-20*: BPT_AC/DC_CPDReqEnergyTransferModeType: EVMinimumChargePower_L3\r\n",
+ "type": "number"
+ },
+ "maxChargePower": {
+ "description": "Maximum charge (absorbed) power in W, defined by min(EV, EVSE) at unity power factor. +\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\nIt corresponds to the ChaWMax attribute in the IEC 61850.\r\nIt is usually equivalent to the rated apparent power of the EV when discharging (ChaVAMax) in IEC 61850. +\r\n\r\nRelates to: \r\n*ISO 15118-20*: BPT_AC/DC_CPDReqEnergyTransferModeType: EVMaximumChargePower\r\n\r\n",
+ "type": "number"
+ },
+ "maxChargePower_L2": {
+ "description": "Maximum charge power on phase L2 in W, defined by min(EV, EVSE)\r\nRelates to: \r\n*ISO 15118-20*: BPT_AC/DC_CPDReqEnergyTransferModeType: EVMaximumChargePower_L2\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "maxChargePower_L3": {
+ "description": "Maximum charge power on phase L3 in W, defined by min(EV, EVSE)\r\nRelates to: \r\n*ISO 15118-20*: BPT_AC/DC_CPDReqEnergyTransferModeType: EVMaximumChargePower_L3\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "minDischargePower": {
+ "description": "Minimum discharge (injected) power in W, defined by max(EV, EVSE) at unity power factor. Value >= 0. +\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1. +\r\nIt corresponds to the WMax attribute in the IEC 61850.\r\nIt is usually equivalent to the rated apparent power of the EV when discharging (VAMax attribute in the IEC 61850).\r\n\r\nRelates to:\r\n*ISO 15118-20*: BPT_AC/DC_CPDReqEnergyTransferModeType: EVMinimumDischargePower\r\n\r\n",
+ "type": "number"
+ },
+ "minDischargePower_L2": {
+ "description": "Minimum discharge power on phase L2 in W, defined by max(EV, EVSE). Value >= 0.\r\nRelates to:\r\n*ISO 15118-20*: BPT_AC/DC_CPDReqEnergyTransferModeType: EVMinimumDischargePower_L2\r\n\r\n",
+ "type": "number"
+ },
+ "minDischargePower_L3": {
+ "description": "Minimum discharge power on phase L3 in W, defined by max(EV, EVSE). Value >= 0.\r\nRelates to:\r\n*ISO 15118-20*: BPT_AC/DC_CPDReqEnergyTransferModeType: EVMinimumDischargePower_L3\r\n\r\n",
+ "type": "number"
+ },
+ "maxDischargePower": {
+ "description": "Maximum discharge (injected) power in W, defined by min(EV, EVSE) at unity power factor. Value >= 0.\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\nRelates to:\r\n*ISO 15118-20*: BPT_AC/DC_CPDReqEnergyTransferModeType: EVMaximumDischargePower\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "maxDischargePower_L2": {
+ "description": "Maximum discharge power on phase L2 in W, defined by min(EV, EVSE). Value >= 0.\r\nRelates to:\r\n*ISO 15118-20*: BPT_AC/DC_CPDReqEnergyTransferModeType: EVMaximumDischargePowe_L2\r\n\r\n",
+ "type": "number"
+ },
+ "maxDischargePower_L3": {
+ "description": "Maximum discharge power on phase L3 in W, defined by min(EV, EVSE). Value >= 0.\r\nRelates to:\r\n*ISO 15118-20*: BPT_AC/DC_CPDReqEnergyTransferModeType: EVMaximumDischargePower_L3\r\n\r\n",
+ "type": "number"
+ },
+ "minChargeCurrent": {
+ "description": "Minimum charge current in A, defined by max(EV, EVSE)\r\nRelates to: \r\n*ISO 15118-20*: BPT_DC_CPDReqEnergyTransferModeType: EVMinimumChargeCurrent\r\n\r\n",
+ "type": "number"
+ },
+ "maxChargeCurrent": {
+ "description": "Maximum charge current in A, defined by min(EV, EVSE)\r\nRelates to: \r\n*ISO 15118-20*: BPT_DC_CPDReqEnergyTransferModeType: EVMaximumChargeCurrent\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "minDischargeCurrent": {
+ "description": "Minimum discharge current in A, defined by max(EV, EVSE). Value >= 0.\r\nRelates to: \r\n*ISO 15118-20*: BPT_DC_CPDReqEnergyTransferModeType: EVMinimumDischargeCurrent\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "maxDischargeCurrent": {
+ "description": "Maximum discharge current in A, defined by min(EV, EVSE). Value >= 0.\r\nRelates to: \r\n*ISO 15118-20*: BPT_DC_CPDReqEnergyTransferModeType: EVMaximumDischargeCurrent\r\n\r\n",
+ "type": "number"
+ },
+ "minVoltage": {
+ "description": "Minimum voltage in V, defined by max(EV, EVSE)\r\nRelates to:\r\n*ISO 15118-20*: BPT_DC_CPDReqEnergyTransferModeType: EVMinimumVoltage\r\n\r\n",
+ "type": "number"
+ },
+ "maxVoltage": {
+ "description": "Maximum voltage in V, defined by min(EV, EVSE)\r\nRelates to:\r\n*ISO 15118-20*: BPT_DC_CPDReqEnergyTransferModeType: EVMaximumVoltage\r\n\r\n",
+ "type": "number"
+ },
+ "evTargetEnergyRequest": {
+ "description": "Energy to requested state of charge in Wh\r\nRelates to:\r\n*ISO 15118-20*: Dynamic/Scheduled_SEReqControlModeType: EVTargetEnergyRequest\r\n\r\n",
+ "type": "number"
+ },
+ "evMinEnergyRequest": {
+ "description": "Energy to minimum allowed state of charge in Wh\r\nRelates to:\r\n*ISO 15118-20*: Dynamic/Scheduled_SEReqControlModeType: EVMinimumEnergyRequest\r\n\r\n",
+ "type": "number"
+ },
+ "evMaxEnergyRequest": {
+ "description": "Energy to maximum state of charge in Wh\r\nRelates to:\r\n*ISO 15118-20*: Dynamic/Scheduled_SEReqControlModeType: EVMaximumEnergyRequest\r\n\r\n",
+ "type": "number"
+ },
+ "evMinV2XEnergyRequest": {
+ "description": "Energy (in Wh) to minimum state of charge for cycling (V2X) activity. \r\nPositive value means that current state of charge is below V2X range.\r\nRelates to:\r\n*ISO 15118-20*: Dynamic_SEReqControlModeType: EVMinimumV2XEnergyRequest\r\n\r\n",
+ "type": "number"
+ },
+ "evMaxV2XEnergyRequest": {
+ "description": "Energy (in Wh) to maximum state of charge for cycling (V2X) activity.\r\nNegative value indicates that current state of charge is above V2X range.\r\nRelates to:\r\n*ISO 15118-20*: Dynamic_SEReqControlModeType: EVMaximumV2XEnergyRequest\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "targetSoC": {
+ "description": "Target state of charge at departure as percentage.\r\nRelates to:\r\n*ISO 15118-20*: BPT_DC_CPDReqEnergyTransferModeType: TargetSOC\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evseId": {
+ "description": "Defines the EVSE and connector to which the EV is connected. EvseId may not be 0.\r\n",
+ "type": "integer",
+ "minimum": 1.0
+ },
+ "maxScheduleTuples": {
+ "description": "Contains the maximum elements the EV supports for: +\r\n- ISO 15118-2: schedule tuples in SASchedule (both Pmax and Tariff). +\r\n- ISO 15118-20: PowerScheduleEntry, PriceRule and PriceLevelScheduleEntries.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "chargingNeeds": {
+ "$ref": "#/definitions/ChargingNeedsType"
+ },
+ "timestamp": {
+ "description": "*(2.1)* Time when EV charging needs were received. +\r\nField can be added when charging station was offline when charging needs were received.\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["evseId", "chargingNeeds"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyEVChargingNeedsResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "NotifyEVChargingNeedsStatusEnumType": {
+ "description": "Returns whether the CSMS has been able to process the message successfully. It does not imply that the evChargingNeeds can be met with the current charging profile.\r\n",
+ "javaType": "NotifyEVChargingNeedsStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Processing", "NoChargingProfile"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/NotifyEVChargingNeedsStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyEVChargingScheduleRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingRateUnitEnumType": {
+ "description": "The unit of measure in which limits and setpoints are expressed.\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "CostKindEnumType": {
+ "description": "The kind of cost referred to in the message element amount\r\n",
+ "javaType": "CostKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CarbonDioxideEmission", "RelativePricePercentage", "RenewableGenerationPercentage"]
+ },
+ "OperationModeEnumType": {
+ "description": "*(2.1)* Charging operation mode to use during this time interval. When absent defaults to `ChargingOnly`.\r\n",
+ "javaType": "OperationModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Idle",
+ "ChargingOnly",
+ "CentralSetpoint",
+ "ExternalSetpoint",
+ "ExternalLimits",
+ "CentralFrequency",
+ "LocalFrequency",
+ "LocalLoadBalancing"
+ ]
+ },
+ "AbsolutePriceScheduleType": {
+ "description": "The AbsolutePriceScheduleType is modeled after the same type that is defined in ISO 15118-20, such that if it is supplied by an EMSP as a signed EXI message, the conversion from EXI to JSON (in OCPP) and back to EXI (for ISO 15118-20) does not change the digest and therefore does not invalidate the signature.\r\n\r\nimage::images/AbsolutePriceSchedule-Simple.png[]\r\n\r\n",
+ "javaType": "AbsolutePriceSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "timeAnchor": {
+ "description": "Starting point of price schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleID": {
+ "description": "Unique ID of price schedule\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "priceScheduleDescription": {
+ "description": "Description of the price schedule.\r\n",
+ "type": "string",
+ "maxLength": 160
+ },
+ "currency": {
+ "description": "Currency according to ISO 4217.\r\n",
+ "type": "string",
+ "maxLength": 3
+ },
+ "language": {
+ "description": "String that indicates what language is used for the human readable strings in the price schedule. Based on ISO 639.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "priceAlgorithm": {
+ "description": "A string in URN notation which shall uniquely identify an algorithm that defines how to compute an energy fee sum for a specific power profile based on the EnergyFee information from the PriceRule elements.\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "minimumCost": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "maximumCost": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "priceRuleStacks": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceRuleStackType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "taxRules": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 10
+ },
+ "overstayRuleList": {
+ "$ref": "#/definitions/OverstayRuleListType"
+ },
+ "additionalSelectedServices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalSelectedServicesType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "timeAnchor",
+ "priceScheduleID",
+ "currency",
+ "language",
+ "priceAlgorithm",
+ "priceRuleStacks"
+ ]
+ },
+ "AdditionalSelectedServicesType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "AdditionalSelectedServices",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "serviceFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "serviceName": {
+ "description": "Human readable string to identify this service.\r\n",
+ "type": "string",
+ "maxLength": 80
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["serviceName", "serviceFee"]
+ },
+ "ChargingSchedulePeriodType": {
+ "description": "Charging schedule period structure defines a time period in a charging schedule. It is used in: CompositeScheduleType and in ChargingScheduleType. When used in a NotifyEVChargingScheduleRequest only _startPeriod_, _limit_, _limit_L2_, _limit_L3_ are relevant.\r\n",
+ "javaType": "ChargingSchedulePeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startPeriod": {
+ "description": "Start of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.\r\n",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Optional only when not required by the _operationMode_, as in CentralSetpoint, ExternalSetpoint, ExternalLimits, LocalFrequency, LocalLoadBalancing. +\r\nCharging rate limit during the schedule period, in the applicable _chargingRateUnit_. \r\nThis SHOULD be a non-negative value; a negative value is only supported for backwards compatibility with older systems that use a negative value to specify a discharging limit.\r\nWhen using _chargingRateUnit_ = `W`, this field represents the sum of the power of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "limit_L2": {
+ "description": "*(2.1)* Charging rate limit on phase L2 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "limit_L3": {
+ "description": "*(2.1)* Charging rate limit on phase L3 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "numberPhases": {
+ "description": "The number of phases that can be used for charging. +\r\nFor a DC EVSE this field should be omitted. +\r\nFor an AC EVSE a default value of _numberPhases_ = 3 will be assumed if the field is absent.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "phaseToUse": {
+ "description": "Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true. It\u2019s not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "dischargeLimit": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ that the EV is allowed to discharge with. Note, these are negative values in order to be consistent with _setpoint_, which can be positive and negative. +\r\nFor AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L2": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L2 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L3": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L3 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "setpoint": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow as close as possible. Use negative values for discharging. +\r\nWhen a limit and/or _dischargeLimit_ are given the overshoot when following _setpoint_ must remain within these values.\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpoint_L2": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L2 as close as possible.\r\n",
+ "type": "number"
+ },
+ "setpoint_L3": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L3 as close as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow as closely as possible. Positive values for inductive, negative for capacitive reactive power or current. +\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpointReactive_L2": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L2 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive_L3": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L3 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "preconditioningRequest": {
+ "description": "*(2.1)* If true, the EV should attempt to keep the BMS preconditioned for this time interval.\r\n",
+ "type": "boolean"
+ },
+ "evseSleep": {
+ "description": "*(2.1)* If true, the EVSE must turn off power electronics/modules associated with this transaction. Default value when absent is false.\r\n",
+ "type": "boolean"
+ },
+ "v2xBaseline": {
+ "description": "*(2.1)* Power value that, when present, is used as a baseline on top of which values from _v2xFreqWattCurve_ and _v2xSignalWattCurve_ are added.\r\n\r\n",
+ "type": "number"
+ },
+ "operationMode": {
+ "$ref": "#/definitions/OperationModeEnumType"
+ },
+ "v2xFreqWattCurve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/V2XFreqWattPointType"
+ },
+ "minItems": 1,
+ "maxItems": 20
+ },
+ "v2xSignalWattCurve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/V2XSignalWattPointType"
+ },
+ "minItems": 1,
+ "maxItems": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startPeriod"]
+ },
+ "ChargingScheduleType": {
+ "description": "Charging schedule structure defines a list of charging periods, as used in: NotifyEVChargingScheduleRequest and ChargingProfileType. When used in a NotifyEVChargingScheduleRequest only _duration_ and _chargingSchedulePeriod_ are relevant and _chargingRateUnit_ must be 'W'. +\r\nAn ISO 15118-20 session may provide either an _absolutePriceSchedule_ or a _priceLevelSchedule_. An ISO 15118-2 session can only provide a_salesTariff_ element. The field _digestValue_ is used when price schedule or sales tariff are signed.\r\n\r\nimage::images/ChargingSchedule-Simple.png[]\r\n\r\n\r\n",
+ "javaType": "ChargingSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "integer"
+ },
+ "limitAtSoC": {
+ "$ref": "#/definitions/LimitAtSoCType"
+ },
+ "startSchedule": {
+ "description": "Starting point of an absolute schedule or recurring schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction in case startSchedule is absent.\r\n",
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "minChargingRate": {
+ "description": "Minimum charging rate supported by the EV. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates. \r\n",
+ "type": "number"
+ },
+ "powerTolerance": {
+ "description": "*(2.1)* Power tolerance when following EVPowerProfile.\r\n\r\n",
+ "type": "number"
+ },
+ "signatureId": {
+ "description": "*(2.1)* Id of this element for referencing in a signature.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "digestValue": {
+ "description": "*(2.1)* Base64 encoded hash (SHA256 for ISO 15118-2, SHA512 for ISO 15118-20) of the EXI price schedule element. Used in signature.\r\n",
+ "type": "string",
+ "maxLength": 88
+ },
+ "useLocalTime": {
+ "description": "*(2.1)* Defaults to false. When true, disregard time zone offset in dateTime fields of _ChargingScheduleType_ and use unqualified local time at Charging Station instead.\r\n This allows the same `Absolute` or `Recurring` charging profile to be used in both summer and winter time.\r\n\r\n",
+ "type": "boolean"
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingSchedulePeriodType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "randomizedDelay": {
+ "description": "*(2.1)* Defaults to 0. When _randomizedDelay_ not equals zero, then the start of each <<cmn_chargingscheduleperiodtype,ChargingSchedulePeriodType>> is delayed by a randomly chosen number of seconds between 0 and _randomizedDelay_. Only allowed for TxProfile and TxDefaultProfile.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariff": {
+ "$ref": "#/definitions/SalesTariffType"
+ },
+ "absolutePriceSchedule": {
+ "$ref": "#/definitions/AbsolutePriceScheduleType"
+ },
+ "priceLevelSchedule": {
+ "$ref": "#/definitions/PriceLevelScheduleType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "chargingRateUnit", "chargingSchedulePeriod"]
+ },
+ "ConsumptionCostType": {
+ "javaType": "ConsumptionCost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startValue": {
+ "description": "The lowest level of consumption that defines the starting point of this consumption block. The block interval extends to the start of the next interval.\r\n",
+ "type": "number"
+ },
+ "cost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startValue", "cost"]
+ },
+ "CostType": {
+ "javaType": "Cost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "costKind": {
+ "$ref": "#/definitions/CostKindEnumType"
+ },
+ "amount": {
+ "description": "The estimated or actual cost per kWh\r\n",
+ "type": "integer"
+ },
+ "amountMultiplier": {
+ "description": "Values: -3..3, The amountMultiplier defines the exponent to base 10 (dec). The final value is determined by: amount * 10 ^ amountMultiplier\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["costKind", "amount"]
+ },
+ "LimitAtSoCType": {
+ "javaType": "LimitAtSoC",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "soc": {
+ "description": "The SoC value beyond which the charging rate limit should be applied.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "limit": {
+ "description": "Charging rate limit beyond the SoC value.\r\nThe unit is defined by _chargingSchedule.chargingRateUnit_.\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["soc", "limit"]
+ },
+ "OverstayRuleListType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "OverstayRuleList",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "overstayPowerThreshold": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "overstayRule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/OverstayRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "overstayTimeThreshold": {
+ "description": "Time till overstay is applied in seconds.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["overstayRule"]
+ },
+ "OverstayRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "OverstayRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "overstayFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "overstayRuleDescription": {
+ "description": "Human readable string to identify the overstay rule.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "startTime": {
+ "description": "Time in seconds after trigger of the parent Overstay Rules for this particular fee to apply.\r\n",
+ "type": "integer"
+ },
+ "overstayFeePeriod": {
+ "description": "Time till overstay will be reapplied\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startTime", "overstayFeePeriod", "overstayFee"]
+ },
+ "PriceLevelScheduleEntryType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n",
+ "javaType": "PriceLevelScheduleEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "The amount of seconds that define the duration of this given PriceLevelScheduleEntry.\r\n",
+ "type": "integer"
+ },
+ "priceLevel": {
+ "description": "Defines the price level of this PriceLevelScheduleEntry (referring to NumberOfPriceLevels). Small values for the PriceLevel represent a cheaper PriceLevelScheduleEntry. Large values for the PriceLevel represent a more expensive PriceLevelScheduleEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "priceLevel"]
+ },
+ "PriceLevelScheduleType": {
+ "description": "The PriceLevelScheduleType is modeled after the same type that is defined in ISO 15118-20, such that if it is supplied by an EMSP as a signed EXI message, the conversion from EXI to JSON (in OCPP) and back to EXI (for ISO 15118-20) does not change the digest and therefore does not invalidate the signature.\r\n",
+ "javaType": "PriceLevelSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priceLevelScheduleEntries": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceLevelScheduleEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 100
+ },
+ "timeAnchor": {
+ "description": "Starting point of this price schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleId": {
+ "description": "Unique ID of this price schedule.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "priceScheduleDescription": {
+ "description": "Description of the price schedule.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numberOfPriceLevels": {
+ "description": "Defines the overall number of distinct price level elements used across all PriceLevelSchedules.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "timeAnchor",
+ "priceScheduleId",
+ "numberOfPriceLevels",
+ "priceLevelScheduleEntries"
+ ]
+ },
+ "PriceRuleStackType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n",
+ "javaType": "PriceRuleStack",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "Duration of the stack of price rules. he amount of seconds that define the duration of the given PriceRule(s).\r\n",
+ "type": "integer"
+ },
+ "priceRule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 8
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "priceRule"]
+ },
+ "PriceRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "PriceRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "parkingFeePeriod": {
+ "description": "The duration of the parking fee period (in seconds).\r\nWhen the time enters into a ParkingFeePeriod, the ParkingFee will apply to the session. .\r\n",
+ "type": "integer"
+ },
+ "carbonDioxideEmission": {
+ "description": "Number of grams of CO2 per kWh.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "renewableGenerationPercentage": {
+ "description": "Percentage of the power that is created by renewable resources.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "energyFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "parkingFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "powerRangeStart": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["energyFee", "powerRangeStart"]
+ },
+ "RationalNumberType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "RationalNumber",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "exponent": {
+ "description": "The exponent to base 10 (dec)\r\n",
+ "type": "integer"
+ },
+ "value": {
+ "description": "Value which shall be multiplied.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["exponent", "value"]
+ },
+ "RelativeTimeIntervalType": {
+ "javaType": "RelativeTimeInterval",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "start": {
+ "description": "Start of the interval, in seconds from NOW.\r\n",
+ "type": "integer"
+ },
+ "duration": {
+ "description": "Duration of the interval, in seconds.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["start"]
+ },
+ "SalesTariffEntryType": {
+ "javaType": "SalesTariffEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "relativeTimeInterval": {
+ "$ref": "#/definitions/RelativeTimeIntervalType"
+ },
+ "ePriceLevel": {
+ "description": "Defines the price level of this SalesTariffEntry (referring to NumEPriceLevels). Small values for the EPriceLevel represent a cheaper TariffEntry. Large values for the EPriceLevel represent a more expensive TariffEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "consumptionCost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ConsumptionCostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["relativeTimeInterval"]
+ },
+ "SalesTariffType": {
+ "description": "A SalesTariff provided by a Mobility Operator (EMSP) .\r\nNOTE: This dataType is based on dataTypes from <<ref-ISOIEC15118-2,ISO 15118-2>>.\r\n",
+ "javaType": "SalesTariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "SalesTariff identifier used to identify one sales tariff. An SAID remains a unique identifier for one schedule throughout a charging session.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariffDescription": {
+ "description": "A human readable title/short description of the sales tariff e.g. for HMI display purposes.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numEPriceLevels": {
+ "description": "Defines the overall number of distinct price levels used across all provided SalesTariff elements.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariffEntry": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SalesTariffEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "salesTariffEntry"]
+ },
+ "TaxRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "TaxRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "taxRuleID": {
+ "description": "Id for the tax rule.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "taxRuleName": {
+ "description": "Human readable string to identify the tax rule.\r\n",
+ "type": "string",
+ "maxLength": 100
+ },
+ "taxIncludedInPrice": {
+ "description": "Indicates whether the tax is included in any price or not.\r\n",
+ "type": "boolean"
+ },
+ "appliesToEnergyFee": {
+ "description": "Indicates whether this tax applies to Energy Fees.\r\n",
+ "type": "boolean"
+ },
+ "appliesToParkingFee": {
+ "description": "Indicates whether this tax applies to Parking Fees.\r\n\r\n",
+ "type": "boolean"
+ },
+ "appliesToOverstayFee": {
+ "description": "Indicates whether this tax applies to Overstay Fees.\r\n\r\n",
+ "type": "boolean"
+ },
+ "appliesToMinimumMaximumCost": {
+ "description": "Indicates whether this tax applies to Minimum/Maximum Cost.\r\n\r\n",
+ "type": "boolean"
+ },
+ "taxRate": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "taxRuleID",
+ "appliesToEnergyFee",
+ "appliesToParkingFee",
+ "appliesToOverstayFee",
+ "appliesToMinimumMaximumCost",
+ "taxRate"
+ ]
+ },
+ "V2XFreqWattPointType": {
+ "description": "*(2.1)* A point of a frequency-watt curve.\r\n",
+ "javaType": "V2XFreqWattPoint",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "frequency": {
+ "description": "Net frequency in Hz.\r\n",
+ "type": "number"
+ },
+ "power": {
+ "description": "Power in W to charge (positive) or discharge (negative) at specified frequency.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["frequency", "power"]
+ },
+ "V2XSignalWattPointType": {
+ "description": "*(2.1)* A point of a signal-watt curve.\r\n",
+ "javaType": "V2XSignalWattPoint",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "signal": {
+ "description": "Signal value from an AFRRSignalRequest.\r\n",
+ "type": "integer"
+ },
+ "power": {
+ "description": "Power in W to charge (positive) or discharge (negative) at specified frequency.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["signal", "power"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "timeBase": {
+ "description": "Periods contained in the charging profile are relative to this point in time.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingSchedule": {
+ "$ref": "#/definitions/ChargingScheduleType"
+ },
+ "evseId": {
+ "description": "The charging schedule contained in this notification applies to an EVSE. EvseId must be > 0.\r\n",
+ "type": "integer",
+ "minimum": 1.0
+ },
+ "selectedChargingScheduleId": {
+ "description": "*(2.1)* Id of the _chargingSchedule_ that EV selected from the provided ChargingProfile.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "powerToleranceAcceptance": {
+ "description": "*(2.1)* True when power tolerance is accepted by EV.\r\nThis value is taken from EVPowerProfile.PowerToleranceAcceptance in the ISO 15118-20 PowerDeliverReq message..\r\n",
+ "type": "boolean"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["timeBase", "evseId", "chargingSchedule"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyEVChargingScheduleResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericStatusEnumType": {
+ "description": "Returns whether the CSMS has been able to process the message successfully. It does not imply any approval of the charging schedule.\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyEventRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "EventNotificationEnumType": {
+ "description": "Specifies the event notification type of the message.\r\n\r\n",
+ "javaType": "EventNotificationEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["HardWiredNotification", "HardWiredMonitor", "PreconfiguredMonitor", "CustomMonitor"]
+ },
+ "EventTriggerEnumType": {
+ "description": "Type of trigger for this event, e.g. exceeding a threshold value.\r\n\r\n",
+ "javaType": "EventTriggerEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Alerting", "Delta", "Periodic"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "EventDataType": {
+ "description": "Class to report an event notification for a component-variable.\r\n",
+ "javaType": "EventData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "eventId": {
+ "description": "Identifies the event. This field can be referred to as a cause by other events.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "timestamp": {
+ "description": "Timestamp of the moment the report was generated.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "trigger": {
+ "$ref": "#/definitions/EventTriggerEnumType"
+ },
+ "cause": {
+ "description": "Refers to the Id of an event that is considered to be the cause for this event.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "actualValue": {
+ "description": "Actual value (_attributeType_ Actual) of the variable.\r\n\r\nThe Configuration Variable <<configkey-reporting-value-size,ReportingValueSize>> can be used to limit GetVariableResult.attributeValue, VariableAttribute.value and EventData.actualValue. The max size of these values will always remain equal. \r\n\r\n",
+ "type": "string",
+ "maxLength": 2500
+ },
+ "techCode": {
+ "description": "Technical (error) code as reported by component.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "techInfo": {
+ "description": "Technical detail information as reported by component.\r\n",
+ "type": "string",
+ "maxLength": 500
+ },
+ "cleared": {
+ "description": "_Cleared_ is set to true to report the clearing of a monitored situation, i.e. a 'return to normal'. \r\n\r\n",
+ "type": "boolean"
+ },
+ "transactionId": {
+ "description": "If an event notification is linked to a specific transaction, this field can be used to specify its transactionId.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variableMonitoringId": {
+ "description": "Identifies the VariableMonitoring which triggered the event.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "eventNotificationType": {
+ "$ref": "#/definitions/EventNotificationEnumType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "severity": {
+ "description": "*(2.1)* Severity associated with the monitor in _variableMonitoringId_ or with the hardwired notification.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "eventId",
+ "timestamp",
+ "trigger",
+ "actualValue",
+ "eventNotificationType",
+ "component",
+ "variable"
+ ]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "generatedAt": {
+ "description": "Timestamp of the moment this message was generated at the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "tbc": {
+ "description": "\u201cto be continued\u201d indicator. Indicates whether another part of the report follows in an upcoming notifyEventRequest message. Default value when omitted is false. \r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "seqNo": {
+ "description": "Sequence number of this message. First message starts at 0.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "eventData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/EventDataType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["generatedAt", "seqNo", "eventData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyEventResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyMonitoringReportRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "EventNotificationEnumType": {
+ "description": "*(2.1)* Type of monitor.\r\n",
+ "javaType": "EventNotificationEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["HardWiredNotification", "HardWiredMonitor", "PreconfiguredMonitor", "CustomMonitor"]
+ },
+ "MonitorEnumType": {
+ "description": "The type of this monitor, e.g. a threshold, delta or periodic monitor. \r\n",
+ "javaType": "MonitorEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "UpperThreshold",
+ "LowerThreshold",
+ "Delta",
+ "Periodic",
+ "PeriodicClockAligned",
+ "TargetDelta",
+ "TargetDeltaRelative"
+ ]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "MonitoringDataType": {
+ "description": "Class to hold parameters of SetVariableMonitoring request.\r\n",
+ "javaType": "MonitoringData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "variableMonitoring": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/VariableMonitoringType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["component", "variable", "variableMonitoring"]
+ },
+ "VariableMonitoringType": {
+ "description": "A monitoring setting for a variable.\r\n",
+ "javaType": "VariableMonitoring",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Identifies the monitor.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "transaction": {
+ "description": "Monitor only active when a transaction is ongoing on a component relevant to this transaction. \r\n",
+ "type": "boolean"
+ },
+ "value": {
+ "description": "Value for threshold or delta monitoring.\r\nFor Periodic or PeriodicClockAligned this is the interval in seconds.\r\n",
+ "type": "number"
+ },
+ "type": {
+ "$ref": "#/definitions/MonitorEnumType"
+ },
+ "severity": {
+ "description": "The severity that will be assigned to an event that is triggered by this monitor. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.\r\n\r\nThe severity levels have the following meaning: +\r\n*0-Danger* +\r\nIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately. +\r\n*1-Hardware Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required. +\r\n*2-System Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required. +\r\n*3-Critical* +\r\nIndicates a critical error. Action is required. +\r\n*4-Error* +\r\nIndicates a non-urgent error. Action is required. +\r\n*5-Alert* +\r\nIndicates an alert event. Default severity for any type of monitoring event. +\r\n*6-Warning* +\r\nIndicates a warning event. Action may be required. +\r\n*7-Notice* +\r\nIndicates an unusual event. No immediate action is required. +\r\n*8-Informational* +\r\nIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required. +\r\n*9-Debug* +\r\nIndicates information useful to developers for debugging, not useful during operations.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "eventNotificationType": {
+ "$ref": "#/definitions/EventNotificationEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "transaction", "value", "type", "severity", "eventNotificationType"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "monitor": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MonitoringDataType"
+ },
+ "minItems": 1
+ },
+ "requestId": {
+ "description": "The id of the GetMonitoringRequest that requested this report.\r\n\r\n",
+ "type": "integer"
+ },
+ "tbc": {
+ "description": "\u201cto be continued\u201d indicator. Indicates whether another part of the monitoringData follows in an upcoming notifyMonitoringReportRequest message. Default value when omitted is false.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "seqNo": {
+ "description": "Sequence number of this message. First message starts at 0.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "generatedAt": {
+ "description": "Timestamp of the moment this message was generated at the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId", "seqNo", "generatedAt"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyMonitoringReportResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyPeriodicEventStream",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "StreamDataElementType": {
+ "javaType": "StreamDataElement",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "t": {
+ "description": "Offset relative to _basetime_ of this message. _basetime_ + _t_ is timestamp of recorded value.\r\n",
+ "type": "number"
+ },
+ "v": {
+ "type": "string",
+ "maxLength": 2500
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["t", "v"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "data": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/StreamDataElementType"
+ },
+ "minItems": 1
+ },
+ "id": {
+ "description": "Id of stream.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "pending": {
+ "description": "Number of data elements still pending to be sent.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "basetime": {
+ "description": "Base timestamp to add to time offset of values.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "pending", "basetime", "data"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyPriorityChargingRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "transactionId": {
+ "description": "The transaction for which priority charging is requested.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "activated": {
+ "description": "True if priority charging was activated. False if it has stopped using the priority charging profile.\r\n",
+ "type": "boolean"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["transactionId", "activated"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyPriorityChargingResponse",
+ "description": "This response message has an empty body.\r\n",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyReportRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "AttributeEnumType": {
+ "description": "Attribute: Actual, MinSet, MaxSet, etc.\r\nDefaults to Actual if absent.\r\n",
+ "javaType": "AttributeEnum",
+ "type": "string",
+ "default": "Actual",
+ "additionalProperties": false,
+ "enum": ["Actual", "Target", "MinSet", "MaxSet"]
+ },
+ "DataEnumType": {
+ "description": "Data type of this variable.\r\n",
+ "javaType": "DataEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "string",
+ "decimal",
+ "integer",
+ "dateTime",
+ "boolean",
+ "OptionList",
+ "SequenceList",
+ "MemberList"
+ ]
+ },
+ "MutabilityEnumType": {
+ "description": "Defines the mutability of this attribute. Default is ReadWrite when omitted.\r\n",
+ "javaType": "MutabilityEnum",
+ "type": "string",
+ "default": "ReadWrite",
+ "additionalProperties": false,
+ "enum": ["ReadOnly", "WriteOnly", "ReadWrite"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "ReportDataType": {
+ "description": "Class to report components, variables and variable attributes and characteristics.\r\n",
+ "javaType": "ReportData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "variableAttribute": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/VariableAttributeType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ },
+ "variableCharacteristics": {
+ "$ref": "#/definitions/VariableCharacteristicsType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["component", "variable", "variableAttribute"]
+ },
+ "VariableAttributeType": {
+ "description": "Attribute data of a variable.\r\n",
+ "javaType": "VariableAttribute",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "$ref": "#/definitions/AttributeEnumType"
+ },
+ "value": {
+ "description": "Value of the attribute. May only be omitted when mutability is set to 'WriteOnly'.\r\n\r\nThe Configuration Variable <<configkey-reporting-value-size,ReportingValueSize>> can be used to limit GetVariableResult.attributeValue, VariableAttribute.value and EventData.actualValue. The max size of these values will always remain equal. \r\n",
+ "type": "string",
+ "maxLength": 2500
+ },
+ "mutability": {
+ "$ref": "#/definitions/MutabilityEnumType"
+ },
+ "persistent": {
+ "description": "If true, value will be persistent across system reboots or power down. Default when omitted is false.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "constant": {
+ "description": "If true, value that will never be changed by the Charging Station at runtime. Default when omitted is false.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "VariableCharacteristicsType": {
+ "description": "Fixed read-only parameters of a variable.\r\n",
+ "javaType": "VariableCharacteristics",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "unit": {
+ "description": "Unit of the variable. When the transmitted value has a unit, this field SHALL be included.\r\n",
+ "type": "string",
+ "maxLength": 16
+ },
+ "dataType": {
+ "$ref": "#/definitions/DataEnumType"
+ },
+ "minLimit": {
+ "description": "Minimum possible value of this variable.\r\n",
+ "type": "number"
+ },
+ "maxLimit": {
+ "description": "Maximum possible value of this variable. When the datatype of this Variable is String, OptionList, SequenceList or MemberList, this field defines the maximum length of the (CSV) string.\r\n",
+ "type": "number"
+ },
+ "maxElements": {
+ "description": "*(2.1)* Maximum number of elements from _valuesList_ that are supported as _attributeValue_.\r\n",
+ "type": "integer",
+ "minimum": 1.0
+ },
+ "valuesList": {
+ "description": "Mandatory when _dataType_ = OptionList, MemberList or SequenceList. In that case _valuesList_ specifies the allowed values for the type.\r\n\r\nThe length of this field can be limited by DeviceDataCtrlr.ConfigurationValueSize.\r\n\r\n* OptionList: The (Actual) Variable value must be a single value from the reported (CSV) enumeration list.\r\n\r\n* MemberList: The (Actual) Variable value may be an (unordered) (sub-)set of the reported (CSV) valid values list.\r\n\r\n* SequenceList: The (Actual) Variable value may be an ordered (priority, etc) (sub-)set of the reported (CSV) valid values.\r\n\r\nThis is a comma separated list.\r\n\r\nThe Configuration Variable <<configkey-configuration-value-size,ConfigurationValueSize>> can be used to limit SetVariableData.attributeValue and VariableCharacteristics.valuesList. The max size of these values will always remain equal. \r\n\r\n\r\n",
+ "type": "string",
+ "maxLength": 1000
+ },
+ "supportsMonitoring": {
+ "description": "Flag indicating if this variable supports monitoring. \r\n",
+ "type": "boolean"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["dataType", "supportsMonitoring"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "requestId": {
+ "description": "The id of the GetReportRequest or GetBaseReportRequest that requested this report\r\n",
+ "type": "integer"
+ },
+ "generatedAt": {
+ "description": "Timestamp of the moment this message was generated at the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "reportData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ReportDataType"
+ },
+ "minItems": 1
+ },
+ "tbc": {
+ "description": "\u201cto be continued\u201d indicator. Indicates whether another part of the report follows in an upcoming notifyReportRequest message. Default value when omitted is false.\r\n\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "seqNo": {
+ "description": "Sequence number of this message. First message starts at 0.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId", "generatedAt", "seqNo"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyReportResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifySettlementRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "PaymentStatusEnumType": {
+ "description": "The status of the settlement attempt.\r\n\r\n",
+ "javaType": "PaymentStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Settled", "Canceled", "Rejected", "Failed"]
+ },
+ "AddressType": {
+ "description": "*(2.1)* A generic address format.\r\n",
+ "javaType": "Address",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of person/company\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "address1": {
+ "description": "Address line 1\r\n",
+ "type": "string",
+ "maxLength": 100
+ },
+ "address2": {
+ "description": "Address line 2\r\n",
+ "type": "string",
+ "maxLength": 100
+ },
+ "city": {
+ "description": "City\r\n",
+ "type": "string",
+ "maxLength": 100
+ },
+ "postalCode": {
+ "description": "Postal code\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "country": {
+ "description": "Country name\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name", "address1", "city", "country"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "transactionId": {
+ "description": "The _transactionId_ that the settlement belongs to. Can be empty if the payment transaction is canceled prior to the start of the OCPP transaction.\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "pspRef": {
+ "description": "The payment reference received from the payment terminal and is used as the value for _idToken_. \r\n\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "status": {
+ "$ref": "#/definitions/PaymentStatusEnumType"
+ },
+ "statusInfo": {
+ "description": "Additional information from payment terminal/payment process.\r\n\r\n",
+ "type": "string",
+ "maxLength": 500
+ },
+ "settlementAmount": {
+ "description": "The amount that was settled, or attempted to be settled (in case of failure).\r\n\r\n",
+ "type": "number"
+ },
+ "settlementTime": {
+ "description": "The time when the settlement was done.\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "receiptId": {
+ "type": "string",
+ "maxLength": 50
+ },
+ "receiptUrl": {
+ "description": "The receipt URL, to be used if the receipt is generated by the payment terminal or the CS.\r\n\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "vatCompany": {
+ "$ref": "#/definitions/AddressType"
+ },
+ "vatNumber": {
+ "description": "VAT number for a company receipt.\r\n\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["pspRef", "status", "settlementAmount", "settlementTime"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifySettlementResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "receiptUrl": {
+ "description": "The receipt URL if receipt generated by CSMS. The Charging Station can QR encode it and show it to the EV Driver.\r\n\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "receiptId": {
+ "description": "The receipt id if the receipt is generated by CSMS.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyWebPaymentStartedRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evseId": {
+ "description": "EVSE id for which transaction is requested.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "timeout": {
+ "description": "Timeout value in seconds after which no result of web payment process (e.g. QR code scanning) is to be expected anymore.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["evseId", "timeout"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:NotifyWebPaymentStartedResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:OpenPeriodicEventStreamRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ConstantStreamDataType": {
+ "javaType": "ConstantStreamData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Uniquely identifies the stream\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "params": {
+ "$ref": "#/definitions/PeriodicEventStreamParamsType"
+ },
+ "variableMonitoringId": {
+ "description": "Id of monitor used to report his event. It can be a preconfigured or hardwired monitor.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "variableMonitoringId", "params"]
+ },
+ "PeriodicEventStreamParamsType": {
+ "javaType": "PeriodicEventStreamParams",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "interval": {
+ "description": "Time in seconds after which stream data is sent.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "values": {
+ "description": "Number of items to be sent together in stream.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "constantStreamData": {
+ "$ref": "#/definitions/ConstantStreamDataType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["constantStreamData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:OpenPeriodicEventStreamResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericStatusEnumType": {
+ "description": "Result of request.\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:PublishFirmwareRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "location": {
+ "description": "This contains a string containing a URI pointing to a\r\nlocation from which to retrieve the firmware.\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "retries": {
+ "description": "This specifies how many times Charging Station must retry\r\nto download the firmware before giving up. If this field is not\r\npresent, it is left to Charging Station to decide how many times it wants to retry.\r\nIf the value is 0, it means: no retries.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "checksum": {
+ "description": "The MD5 checksum over the entire firmware file as a hexadecimal string of length 32. \r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "requestId": {
+ "description": "The Id of the request.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "retryInterval": {
+ "description": "The interval in seconds\r\nafter which a retry may be\r\nattempted. If this field is not\r\npresent, it is left to Charging\r\nStation to decide how long to wait\r\nbetween attempts.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["location", "checksum", "requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:PublishFirmwareResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericStatusEnumType": {
+ "description": "Indicates whether the request was accepted.\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:PublishFirmwareStatusNotificationRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "PublishFirmwareStatusEnumType": {
+ "description": "This contains the progress status of the publishfirmware\r\ninstallation.\r\n",
+ "javaType": "PublishFirmwareStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Idle",
+ "DownloadScheduled",
+ "Downloading",
+ "Downloaded",
+ "Published",
+ "DownloadFailed",
+ "DownloadPaused",
+ "InvalidChecksum",
+ "ChecksumVerified",
+ "PublishFailed"
+ ]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/PublishFirmwareStatusEnumType"
+ },
+ "location": {
+ "description": "Required if status is Published. Can be multiple URI\u2019s, if the Local Controller supports e.g. HTTP, HTTPS, and FTP.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "string",
+ "maxLength": 2000
+ },
+ "minItems": 1
+ },
+ "requestId": {
+ "description": "The request id that was\r\nprovided in the\r\nPublishFirmwareRequest which\r\ntriggered this action.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:PublishFirmwareStatusNotificationResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:PullDynamicScheduleUpdateRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "chargingProfileId": {
+ "description": "Id of charging profile to update.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["chargingProfileId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:PullDynamicScheduleUpdateResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingProfileStatusEnumType": {
+ "description": "Result of request.\r\n\r\n",
+ "javaType": "ChargingProfileStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "ChargingScheduleUpdateType": {
+ "description": "Updates to a ChargingSchedulePeriodType for dynamic charging profiles.\r\n\r\n",
+ "javaType": "ChargingScheduleUpdate",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "limit": {
+ "description": "Optional only when not required by the _operationMode_, as in CentralSetpoint, ExternalSetpoint, ExternalLimits, LocalFrequency, LocalLoadBalancing. +\r\nCharging rate limit during the schedule period, in the applicable _chargingRateUnit_. \r\nThis SHOULD be a non-negative value; a negative value is only supported for backwards compatibility with older systems that use a negative value to specify a discharging limit.\r\nFor AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "limit_L2": {
+ "description": "*(2.1)* Charging rate limit on phase L2 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "limit_L3": {
+ "description": "*(2.1)* Charging rate limit on phase L3 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "dischargeLimit": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ that the EV is allowed to discharge with. Note, these are negative values in order to be consistent with _setpoint_, which can be positive and negative. +\r\nFor AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L2": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L2 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L3": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L3 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "setpoint": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow as close as possible. Use negative values for discharging. +\r\nWhen a limit and/or _dischargeLimit_ are given the overshoot when following _setpoint_ must remain within these values.\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpoint_L2": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L2 as close as possible.\r\n",
+ "type": "number"
+ },
+ "setpoint_L3": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L3 as close as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow as closely as possible. Positive values for inductive, negative for capacitive reactive power or current. +\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpointReactive_L2": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L2 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive_L3": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L3 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "scheduleUpdate": {
+ "$ref": "#/definitions/ChargingScheduleUpdateType"
+ },
+ "status": {
+ "$ref": "#/definitions/ChargingProfileStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ReportChargingProfilesRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingProfileKindEnumType": {
+ "description": "Indicates the kind of schedule.\r\n",
+ "javaType": "ChargingProfileKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Absolute", "Recurring", "Relative", "Dynamic"]
+ },
+ "ChargingProfilePurposeEnumType": {
+ "description": "Defines the purpose of the schedule transferred by this profile\r\n",
+ "javaType": "ChargingProfilePurposeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ChargingStationExternalConstraints",
+ "ChargingStationMaxProfile",
+ "TxDefaultProfile",
+ "TxProfile",
+ "PriorityCharging",
+ "LocalGeneration"
+ ]
+ },
+ "ChargingRateUnitEnumType": {
+ "description": "The unit of measure in which limits and setpoints are expressed.\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "CostKindEnumType": {
+ "description": "The kind of cost referred to in the message element amount\r\n",
+ "javaType": "CostKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CarbonDioxideEmission", "RelativePricePercentage", "RenewableGenerationPercentage"]
+ },
+ "OperationModeEnumType": {
+ "description": "*(2.1)* Charging operation mode to use during this time interval. When absent defaults to `ChargingOnly`.\r\n",
+ "javaType": "OperationModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Idle",
+ "ChargingOnly",
+ "CentralSetpoint",
+ "ExternalSetpoint",
+ "ExternalLimits",
+ "CentralFrequency",
+ "LocalFrequency",
+ "LocalLoadBalancing"
+ ]
+ },
+ "RecurrencyKindEnumType": {
+ "description": "Indicates the start point of a recurrence.\r\n",
+ "javaType": "RecurrencyKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Daily", "Weekly"]
+ },
+ "AbsolutePriceScheduleType": {
+ "description": "The AbsolutePriceScheduleType is modeled after the same type that is defined in ISO 15118-20, such that if it is supplied by an EMSP as a signed EXI message, the conversion from EXI to JSON (in OCPP) and back to EXI (for ISO 15118-20) does not change the digest and therefore does not invalidate the signature.\r\n\r\nimage::images/AbsolutePriceSchedule-Simple.png[]\r\n\r\n",
+ "javaType": "AbsolutePriceSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "timeAnchor": {
+ "description": "Starting point of price schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleID": {
+ "description": "Unique ID of price schedule\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "priceScheduleDescription": {
+ "description": "Description of the price schedule.\r\n",
+ "type": "string",
+ "maxLength": 160
+ },
+ "currency": {
+ "description": "Currency according to ISO 4217.\r\n",
+ "type": "string",
+ "maxLength": 3
+ },
+ "language": {
+ "description": "String that indicates what language is used for the human readable strings in the price schedule. Based on ISO 639.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "priceAlgorithm": {
+ "description": "A string in URN notation which shall uniquely identify an algorithm that defines how to compute an energy fee sum for a specific power profile based on the EnergyFee information from the PriceRule elements.\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "minimumCost": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "maximumCost": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "priceRuleStacks": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceRuleStackType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "taxRules": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 10
+ },
+ "overstayRuleList": {
+ "$ref": "#/definitions/OverstayRuleListType"
+ },
+ "additionalSelectedServices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalSelectedServicesType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "timeAnchor",
+ "priceScheduleID",
+ "currency",
+ "language",
+ "priceAlgorithm",
+ "priceRuleStacks"
+ ]
+ },
+ "AdditionalSelectedServicesType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "AdditionalSelectedServices",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "serviceFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "serviceName": {
+ "description": "Human readable string to identify this service.\r\n",
+ "type": "string",
+ "maxLength": 80
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["serviceName", "serviceFee"]
+ },
+ "ChargingProfileType": {
+ "description": "A ChargingProfile consists of 1 to 3 ChargingSchedules with a list of ChargingSchedulePeriods, describing the amount of power or current that can be delivered per time interval.\r\n\r\nimage::images/ChargingProfile-Simple.png[]\r\n\r\n",
+ "javaType": "ChargingProfile",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Id of ChargingProfile. Unique within charging station. Id can have a negative value. This is useful to distinguish charging profiles from an external actor (external constraints) from charging profiles received from CSMS.\r\n",
+ "type": "integer"
+ },
+ "stackLevel": {
+ "description": "Value determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "chargingProfilePurpose": {
+ "$ref": "#/definitions/ChargingProfilePurposeEnumType"
+ },
+ "chargingProfileKind": {
+ "$ref": "#/definitions/ChargingProfileKindEnumType"
+ },
+ "recurrencyKind": {
+ "$ref": "#/definitions/RecurrencyKindEnumType"
+ },
+ "validFrom": {
+ "description": "Point in time at which the profile starts to be valid. If absent, the profile is valid as soon as it is received by the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "validTo": {
+ "description": "Point in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "transactionId": {
+ "description": "SHALL only be included if ChargingProfilePurpose is set to TxProfile in a SetChargingProfileRequest. The transactionId is used to match the profile to a specific transaction.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "maxOfflineDuration": {
+ "description": "*(2.1)* Period in seconds that this charging profile remains valid after the Charging Station has gone offline. After this period the charging profile becomes invalid for as long as it is offline and the Charging Station reverts back to a valid profile with a lower stack level. \r\nIf _invalidAfterOfflineDuration_ is true, then this charging profile will become permanently invalid.\r\nA value of 0 means that the charging profile is immediately invalid while offline. When the field is absent, then no timeout applies and the charging profile remains valid when offline.\r\n",
+ "type": "integer"
+ },
+ "chargingSchedule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingScheduleType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "invalidAfterOfflineDuration": {
+ "description": "*(2.1)* When set to true this charging profile will not be valid anymore after being offline for more than _maxOfflineDuration_. +\r\n When absent defaults to false.\r\n",
+ "type": "boolean"
+ },
+ "dynUpdateInterval": {
+ "description": "*(2.1)* Interval in seconds after receipt of last update, when to request a profile update by sending a PullDynamicScheduleUpdateRequest message.\r\n A value of 0 or no value means that no update interval applies. +\r\n Only relevant in a dynamic charging profile.\r\n\r\n",
+ "type": "integer"
+ },
+ "dynUpdateTime": {
+ "description": "*(2.1)* Time at which limits or setpoints in this charging profile were last updated by a PullDynamicScheduleUpdateRequest or UpdateDynamicScheduleRequest or by an external actor. +\r\n Only relevant in a dynamic charging profile.\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleSignature": {
+ "description": "*(2.1)* ISO 15118-20 signature for all price schedules in _chargingSchedules_. +\r\nNote: for 256-bit elliptic curves (like secp256k1) the ECDSA signature is 512 bits (64 bytes) and for 521-bit curves (like secp521r1) the signature is 1042 bits. This equals 131 bytes, which can be encoded as base64 in 176 bytes.\r\n",
+ "type": "string",
+ "maxLength": 256
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "id",
+ "stackLevel",
+ "chargingProfilePurpose",
+ "chargingProfileKind",
+ "chargingSchedule"
+ ]
+ },
+ "ChargingSchedulePeriodType": {
+ "description": "Charging schedule period structure defines a time period in a charging schedule. It is used in: CompositeScheduleType and in ChargingScheduleType. When used in a NotifyEVChargingScheduleRequest only _startPeriod_, _limit_, _limit_L2_, _limit_L3_ are relevant.\r\n",
+ "javaType": "ChargingSchedulePeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startPeriod": {
+ "description": "Start of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.\r\n",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Optional only when not required by the _operationMode_, as in CentralSetpoint, ExternalSetpoint, ExternalLimits, LocalFrequency, LocalLoadBalancing. +\r\nCharging rate limit during the schedule period, in the applicable _chargingRateUnit_. \r\nThis SHOULD be a non-negative value; a negative value is only supported for backwards compatibility with older systems that use a negative value to specify a discharging limit.\r\nWhen using _chargingRateUnit_ = `W`, this field represents the sum of the power of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "limit_L2": {
+ "description": "*(2.1)* Charging rate limit on phase L2 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "limit_L3": {
+ "description": "*(2.1)* Charging rate limit on phase L3 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "numberPhases": {
+ "description": "The number of phases that can be used for charging. +\r\nFor a DC EVSE this field should be omitted. +\r\nFor an AC EVSE a default value of _numberPhases_ = 3 will be assumed if the field is absent.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "phaseToUse": {
+ "description": "Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true. It\u2019s not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "dischargeLimit": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ that the EV is allowed to discharge with. Note, these are negative values in order to be consistent with _setpoint_, which can be positive and negative. +\r\nFor AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L2": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L2 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L3": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L3 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "setpoint": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow as close as possible. Use negative values for discharging. +\r\nWhen a limit and/or _dischargeLimit_ are given the overshoot when following _setpoint_ must remain within these values.\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpoint_L2": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L2 as close as possible.\r\n",
+ "type": "number"
+ },
+ "setpoint_L3": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L3 as close as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow as closely as possible. Positive values for inductive, negative for capacitive reactive power or current. +\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpointReactive_L2": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L2 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive_L3": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L3 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "preconditioningRequest": {
+ "description": "*(2.1)* If true, the EV should attempt to keep the BMS preconditioned for this time interval.\r\n",
+ "type": "boolean"
+ },
+ "evseSleep": {
+ "description": "*(2.1)* If true, the EVSE must turn off power electronics/modules associated with this transaction. Default value when absent is false.\r\n",
+ "type": "boolean"
+ },
+ "v2xBaseline": {
+ "description": "*(2.1)* Power value that, when present, is used as a baseline on top of which values from _v2xFreqWattCurve_ and _v2xSignalWattCurve_ are added.\r\n\r\n",
+ "type": "number"
+ },
+ "operationMode": {
+ "$ref": "#/definitions/OperationModeEnumType"
+ },
+ "v2xFreqWattCurve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/V2XFreqWattPointType"
+ },
+ "minItems": 1,
+ "maxItems": 20
+ },
+ "v2xSignalWattCurve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/V2XSignalWattPointType"
+ },
+ "minItems": 1,
+ "maxItems": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startPeriod"]
+ },
+ "ChargingScheduleType": {
+ "description": "Charging schedule structure defines a list of charging periods, as used in: NotifyEVChargingScheduleRequest and ChargingProfileType. When used in a NotifyEVChargingScheduleRequest only _duration_ and _chargingSchedulePeriod_ are relevant and _chargingRateUnit_ must be 'W'. +\r\nAn ISO 15118-20 session may provide either an _absolutePriceSchedule_ or a _priceLevelSchedule_. An ISO 15118-2 session can only provide a_salesTariff_ element. The field _digestValue_ is used when price schedule or sales tariff are signed.\r\n\r\nimage::images/ChargingSchedule-Simple.png[]\r\n\r\n\r\n",
+ "javaType": "ChargingSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "integer"
+ },
+ "limitAtSoC": {
+ "$ref": "#/definitions/LimitAtSoCType"
+ },
+ "startSchedule": {
+ "description": "Starting point of an absolute schedule or recurring schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction in case startSchedule is absent.\r\n",
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "minChargingRate": {
+ "description": "Minimum charging rate supported by the EV. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates. \r\n",
+ "type": "number"
+ },
+ "powerTolerance": {
+ "description": "*(2.1)* Power tolerance when following EVPowerProfile.\r\n\r\n",
+ "type": "number"
+ },
+ "signatureId": {
+ "description": "*(2.1)* Id of this element for referencing in a signature.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "digestValue": {
+ "description": "*(2.1)* Base64 encoded hash (SHA256 for ISO 15118-2, SHA512 for ISO 15118-20) of the EXI price schedule element. Used in signature.\r\n",
+ "type": "string",
+ "maxLength": 88
+ },
+ "useLocalTime": {
+ "description": "*(2.1)* Defaults to false. When true, disregard time zone offset in dateTime fields of _ChargingScheduleType_ and use unqualified local time at Charging Station instead.\r\n This allows the same `Absolute` or `Recurring` charging profile to be used in both summer and winter time.\r\n\r\n",
+ "type": "boolean"
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingSchedulePeriodType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "randomizedDelay": {
+ "description": "*(2.1)* Defaults to 0. When _randomizedDelay_ not equals zero, then the start of each <<cmn_chargingscheduleperiodtype,ChargingSchedulePeriodType>> is delayed by a randomly chosen number of seconds between 0 and _randomizedDelay_. Only allowed for TxProfile and TxDefaultProfile.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariff": {
+ "$ref": "#/definitions/SalesTariffType"
+ },
+ "absolutePriceSchedule": {
+ "$ref": "#/definitions/AbsolutePriceScheduleType"
+ },
+ "priceLevelSchedule": {
+ "$ref": "#/definitions/PriceLevelScheduleType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "chargingRateUnit", "chargingSchedulePeriod"]
+ },
+ "ConsumptionCostType": {
+ "javaType": "ConsumptionCost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startValue": {
+ "description": "The lowest level of consumption that defines the starting point of this consumption block. The block interval extends to the start of the next interval.\r\n",
+ "type": "number"
+ },
+ "cost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startValue", "cost"]
+ },
+ "CostType": {
+ "javaType": "Cost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "costKind": {
+ "$ref": "#/definitions/CostKindEnumType"
+ },
+ "amount": {
+ "description": "The estimated or actual cost per kWh\r\n",
+ "type": "integer"
+ },
+ "amountMultiplier": {
+ "description": "Values: -3..3, The amountMultiplier defines the exponent to base 10 (dec). The final value is determined by: amount * 10 ^ amountMultiplier\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["costKind", "amount"]
+ },
+ "LimitAtSoCType": {
+ "javaType": "LimitAtSoC",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "soc": {
+ "description": "The SoC value beyond which the charging rate limit should be applied.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "limit": {
+ "description": "Charging rate limit beyond the SoC value.\r\nThe unit is defined by _chargingSchedule.chargingRateUnit_.\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["soc", "limit"]
+ },
+ "OverstayRuleListType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "OverstayRuleList",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "overstayPowerThreshold": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "overstayRule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/OverstayRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "overstayTimeThreshold": {
+ "description": "Time till overstay is applied in seconds.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["overstayRule"]
+ },
+ "OverstayRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "OverstayRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "overstayFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "overstayRuleDescription": {
+ "description": "Human readable string to identify the overstay rule.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "startTime": {
+ "description": "Time in seconds after trigger of the parent Overstay Rules for this particular fee to apply.\r\n",
+ "type": "integer"
+ },
+ "overstayFeePeriod": {
+ "description": "Time till overstay will be reapplied\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startTime", "overstayFeePeriod", "overstayFee"]
+ },
+ "PriceLevelScheduleEntryType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n",
+ "javaType": "PriceLevelScheduleEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "The amount of seconds that define the duration of this given PriceLevelScheduleEntry.\r\n",
+ "type": "integer"
+ },
+ "priceLevel": {
+ "description": "Defines the price level of this PriceLevelScheduleEntry (referring to NumberOfPriceLevels). Small values for the PriceLevel represent a cheaper PriceLevelScheduleEntry. Large values for the PriceLevel represent a more expensive PriceLevelScheduleEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "priceLevel"]
+ },
+ "PriceLevelScheduleType": {
+ "description": "The PriceLevelScheduleType is modeled after the same type that is defined in ISO 15118-20, such that if it is supplied by an EMSP as a signed EXI message, the conversion from EXI to JSON (in OCPP) and back to EXI (for ISO 15118-20) does not change the digest and therefore does not invalidate the signature.\r\n",
+ "javaType": "PriceLevelSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priceLevelScheduleEntries": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceLevelScheduleEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 100
+ },
+ "timeAnchor": {
+ "description": "Starting point of this price schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleId": {
+ "description": "Unique ID of this price schedule.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "priceScheduleDescription": {
+ "description": "Description of the price schedule.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numberOfPriceLevels": {
+ "description": "Defines the overall number of distinct price level elements used across all PriceLevelSchedules.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "timeAnchor",
+ "priceScheduleId",
+ "numberOfPriceLevels",
+ "priceLevelScheduleEntries"
+ ]
+ },
+ "PriceRuleStackType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n",
+ "javaType": "PriceRuleStack",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "Duration of the stack of price rules. he amount of seconds that define the duration of the given PriceRule(s).\r\n",
+ "type": "integer"
+ },
+ "priceRule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 8
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "priceRule"]
+ },
+ "PriceRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "PriceRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "parkingFeePeriod": {
+ "description": "The duration of the parking fee period (in seconds).\r\nWhen the time enters into a ParkingFeePeriod, the ParkingFee will apply to the session. .\r\n",
+ "type": "integer"
+ },
+ "carbonDioxideEmission": {
+ "description": "Number of grams of CO2 per kWh.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "renewableGenerationPercentage": {
+ "description": "Percentage of the power that is created by renewable resources.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "energyFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "parkingFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "powerRangeStart": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["energyFee", "powerRangeStart"]
+ },
+ "RationalNumberType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "RationalNumber",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "exponent": {
+ "description": "The exponent to base 10 (dec)\r\n",
+ "type": "integer"
+ },
+ "value": {
+ "description": "Value which shall be multiplied.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["exponent", "value"]
+ },
+ "RelativeTimeIntervalType": {
+ "javaType": "RelativeTimeInterval",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "start": {
+ "description": "Start of the interval, in seconds from NOW.\r\n",
+ "type": "integer"
+ },
+ "duration": {
+ "description": "Duration of the interval, in seconds.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["start"]
+ },
+ "SalesTariffEntryType": {
+ "javaType": "SalesTariffEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "relativeTimeInterval": {
+ "$ref": "#/definitions/RelativeTimeIntervalType"
+ },
+ "ePriceLevel": {
+ "description": "Defines the price level of this SalesTariffEntry (referring to NumEPriceLevels). Small values for the EPriceLevel represent a cheaper TariffEntry. Large values for the EPriceLevel represent a more expensive TariffEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "consumptionCost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ConsumptionCostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["relativeTimeInterval"]
+ },
+ "SalesTariffType": {
+ "description": "A SalesTariff provided by a Mobility Operator (EMSP) .\r\nNOTE: This dataType is based on dataTypes from <<ref-ISOIEC15118-2,ISO 15118-2>>.\r\n",
+ "javaType": "SalesTariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "SalesTariff identifier used to identify one sales tariff. An SAID remains a unique identifier for one schedule throughout a charging session.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariffDescription": {
+ "description": "A human readable title/short description of the sales tariff e.g. for HMI display purposes.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numEPriceLevels": {
+ "description": "Defines the overall number of distinct price levels used across all provided SalesTariff elements.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariffEntry": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SalesTariffEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "salesTariffEntry"]
+ },
+ "TaxRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "TaxRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "taxRuleID": {
+ "description": "Id for the tax rule.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "taxRuleName": {
+ "description": "Human readable string to identify the tax rule.\r\n",
+ "type": "string",
+ "maxLength": 100
+ },
+ "taxIncludedInPrice": {
+ "description": "Indicates whether the tax is included in any price or not.\r\n",
+ "type": "boolean"
+ },
+ "appliesToEnergyFee": {
+ "description": "Indicates whether this tax applies to Energy Fees.\r\n",
+ "type": "boolean"
+ },
+ "appliesToParkingFee": {
+ "description": "Indicates whether this tax applies to Parking Fees.\r\n\r\n",
+ "type": "boolean"
+ },
+ "appliesToOverstayFee": {
+ "description": "Indicates whether this tax applies to Overstay Fees.\r\n\r\n",
+ "type": "boolean"
+ },
+ "appliesToMinimumMaximumCost": {
+ "description": "Indicates whether this tax applies to Minimum/Maximum Cost.\r\n\r\n",
+ "type": "boolean"
+ },
+ "taxRate": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "taxRuleID",
+ "appliesToEnergyFee",
+ "appliesToParkingFee",
+ "appliesToOverstayFee",
+ "appliesToMinimumMaximumCost",
+ "taxRate"
+ ]
+ },
+ "V2XFreqWattPointType": {
+ "description": "*(2.1)* A point of a frequency-watt curve.\r\n",
+ "javaType": "V2XFreqWattPoint",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "frequency": {
+ "description": "Net frequency in Hz.\r\n",
+ "type": "number"
+ },
+ "power": {
+ "description": "Power in W to charge (positive) or discharge (negative) at specified frequency.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["frequency", "power"]
+ },
+ "V2XSignalWattPointType": {
+ "description": "*(2.1)* A point of a signal-watt curve.\r\n",
+ "javaType": "V2XSignalWattPoint",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "signal": {
+ "description": "Signal value from an AFRRSignalRequest.\r\n",
+ "type": "integer"
+ },
+ "power": {
+ "description": "Power in W to charge (positive) or discharge (negative) at specified frequency.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["signal", "power"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "requestId": {
+ "description": "Id used to match the <<getchargingprofilesrequest, GetChargingProfilesRequest>> message with the resulting ReportChargingProfilesRequest messages. When the CSMS provided a requestId in the <<getchargingprofilesrequest, GetChargingProfilesRequest>>, this field SHALL contain the same value.\r\n",
+ "type": "integer"
+ },
+ "chargingLimitSource": {
+ "description": "Source that has installed this charging profile. Values defined in Appendix as ChargingLimitSourceEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "chargingProfile": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingProfileType"
+ },
+ "minItems": 1
+ },
+ "tbc": {
+ "description": "To Be Continued. Default value when omitted: false. false indicates that there are no further messages as part of this report.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "evseId": {
+ "description": "The evse to which the charging profile applies. If evseId = 0, the message contains an overall limit for the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId", "chargingLimitSource", "evseId", "chargingProfile"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ReportChargingProfilesResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ReportDERControlRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DERControlEnumType": {
+ "description": "Type of DER curve\r\n\r\n",
+ "javaType": "DERControlEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "EnterService",
+ "FreqDroop",
+ "FreqWatt",
+ "FixedPFAbsorb",
+ "FixedPFInject",
+ "FixedVar",
+ "Gradients",
+ "HFMustTrip",
+ "HFMayTrip",
+ "HVMustTrip",
+ "HVMomCess",
+ "HVMayTrip",
+ "LimitMaxDischarge",
+ "LFMustTrip",
+ "LVMustTrip",
+ "LVMomCess",
+ "LVMayTrip",
+ "PowerMonitoringMustTrip",
+ "VoltVar",
+ "VoltWatt",
+ "WattPF",
+ "WattVar"
+ ]
+ },
+ "DERUnitEnumType": {
+ "description": "Unit of the Y-axis of DER curve\r\n",
+ "javaType": "DERUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Not_Applicable",
+ "PctMaxW",
+ "PctMaxVar",
+ "PctWAvail",
+ "PctVarAvail",
+ "PctEffectiveV"
+ ]
+ },
+ "PowerDuringCessationEnumType": {
+ "description": "Parameter is only sent, if the EV has to feed-in power or reactive power during fault-ride through (FRT) as defined by HVMomCess curve and LVMomCess curve.\r\n\r\n\r\n",
+ "javaType": "PowerDuringCessationEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Active", "Reactive"]
+ },
+ "DERCurveGetType": {
+ "javaType": "DERCurveGet",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "curve": {
+ "$ref": "#/definitions/DERCurveType"
+ },
+ "id": {
+ "description": "Id of DER curve\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "curveType": {
+ "$ref": "#/definitions/DERControlEnumType"
+ },
+ "isDefault": {
+ "description": "True if this is a default curve\r\n\r\n",
+ "type": "boolean"
+ },
+ "isSuperseded": {
+ "description": "True if this setting is superseded by a higher priority setting (i.e. lower value of _priority_)\r\n\r\n",
+ "type": "boolean"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "curveType", "isDefault", "isSuperseded", "curve"]
+ },
+ "DERCurvePointsType": {
+ "javaType": "DERCurvePoints",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "x": {
+ "description": "The data value of the X-axis (independent) variable, depending on the curve type.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "y": {
+ "description": "The data value of the Y-axis (dependent) variable, depending on the <<cmn_derunitenumtype>> of the curve. If _y_ is power factor, then a positive value means DER is absorbing reactive power (under-excited), a negative value when DER is injecting reactive power (over-excited).\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["x", "y"]
+ },
+ "DERCurveType": {
+ "javaType": "DERCurve",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "curveData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/DERCurvePointsType"
+ },
+ "minItems": 1,
+ "maxItems": 10
+ },
+ "hysteresis": {
+ "$ref": "#/definitions/HysteresisType"
+ },
+ "priority": {
+ "description": "Priority of curve (0=highest)\r\n\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "reactivePowerParams": {
+ "$ref": "#/definitions/ReactivePowerParamsType"
+ },
+ "voltageParams": {
+ "$ref": "#/definitions/VoltageParamsType"
+ },
+ "yUnit": {
+ "$ref": "#/definitions/DERUnitEnumType"
+ },
+ "responseTime": {
+ "description": "Open loop response time, the time to ramp up to 90% of the new target in response to the change in voltage, in seconds. A value of 0 is used to mean no limit. When not present, the device should follow its default behavior.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "startTime": {
+ "description": "Point in time when this curve will become activated. Only absent when _default_ is true.\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration in seconds that this curve will be active. Only absent when _default_ is true.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority", "yUnit", "curveData"]
+ },
+ "EnterServiceGetType": {
+ "javaType": "EnterServiceGet",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "enterService": {
+ "$ref": "#/definitions/EnterServiceType"
+ },
+ "id": {
+ "description": "Id of setting\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "enterService"]
+ },
+ "EnterServiceType": {
+ "javaType": "EnterService",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priority": {
+ "description": "Priority of setting (0=highest)\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "highVoltage": {
+ "description": "Enter service voltage high\r\n",
+ "type": "number"
+ },
+ "lowVoltage": {
+ "description": "Enter service voltage low\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "highFreq": {
+ "description": "Enter service frequency high\r\n\r\n",
+ "type": "number"
+ },
+ "lowFreq": {
+ "description": "Enter service frequency low\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "delay": {
+ "description": "Enter service delay\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "randomDelay": {
+ "description": "Enter service randomized delay\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "rampRate": {
+ "description": "Enter service ramp rate in seconds\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority", "highVoltage", "lowVoltage", "highFreq", "lowFreq"]
+ },
+ "FixedPFGetType": {
+ "javaType": "FixedPFGet",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "fixedPF": {
+ "$ref": "#/definitions/FixedPFType"
+ },
+ "id": {
+ "description": "Id of setting.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "isDefault": {
+ "description": "True if setting is a default control.\r\n",
+ "type": "boolean"
+ },
+ "isSuperseded": {
+ "description": "True if this setting is superseded by a lower priority setting.\r\n",
+ "type": "boolean"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "isDefault", "isSuperseded", "fixedPF"]
+ },
+ "FixedPFType": {
+ "javaType": "FixedPF",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priority": {
+ "description": "Priority of setting (0=highest)\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "displacement": {
+ "description": "Power factor, cos(phi), as value between 0..1.\r\n",
+ "type": "number"
+ },
+ "excitation": {
+ "description": "True when absorbing reactive power (under-excited), false when injecting reactive power (over-excited).\r\n",
+ "type": "boolean"
+ },
+ "startTime": {
+ "description": "Time when this setting becomes active\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration in seconds that this setting is active.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority", "displacement", "excitation"]
+ },
+ "FixedVarGetType": {
+ "javaType": "FixedVarGet",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "fixedVar": {
+ "$ref": "#/definitions/FixedVarType"
+ },
+ "id": {
+ "description": "Id of setting\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "isDefault": {
+ "description": "True if setting is a default control.\r\n",
+ "type": "boolean"
+ },
+ "isSuperseded": {
+ "description": "True if this setting is superseded by a lower priority setting\r\n\r\n",
+ "type": "boolean"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "isDefault", "isSuperseded", "fixedVar"]
+ },
+ "FixedVarType": {
+ "javaType": "FixedVar",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priority": {
+ "description": "Priority of setting (0=highest)\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "setpoint": {
+ "description": "The value specifies a target var output interpreted as a signed percentage (-100 to 100). \r\n A negative value refers to charging, whereas a positive one refers to discharging.\r\n The value type is determined by the unit field.\r\n",
+ "type": "number"
+ },
+ "unit": {
+ "$ref": "#/definitions/DERUnitEnumType"
+ },
+ "startTime": {
+ "description": "Time when this setting becomes active.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration in seconds that this setting is active.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority", "setpoint", "unit"]
+ },
+ "FreqDroopGetType": {
+ "javaType": "FreqDroopGet",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "freqDroop": {
+ "$ref": "#/definitions/FreqDroopType"
+ },
+ "id": {
+ "description": "Id of setting\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "isDefault": {
+ "description": "True if setting is a default control.\r\n",
+ "type": "boolean"
+ },
+ "isSuperseded": {
+ "description": "True if this setting is superseded by a higher priority setting (i.e. lower value of _priority_)\r\n\r\n",
+ "type": "boolean"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "isDefault", "isSuperseded", "freqDroop"]
+ },
+ "FreqDroopType": {
+ "javaType": "FreqDroop",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priority": {
+ "description": "Priority of setting (0=highest)\r\n\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "overFreq": {
+ "description": "Over-frequency start of droop\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "underFreq": {
+ "description": "Under-frequency start of droop\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "overDroop": {
+ "description": "Over-frequency droop per unit, oFDroop\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "underDroop": {
+ "description": "Under-frequency droop per unit, uFDroop\r\n\r\n",
+ "type": "number"
+ },
+ "responseTime": {
+ "description": "Open loop response time in seconds\r\n\r\n",
+ "type": "number"
+ },
+ "startTime": {
+ "description": "Time when this setting becomes active\r\n\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration in seconds that this setting is active\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority", "overFreq", "underFreq", "overDroop", "underDroop", "responseTime"]
+ },
+ "GradientGetType": {
+ "javaType": "GradientGet",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "gradient": {
+ "$ref": "#/definitions/GradientType"
+ },
+ "id": {
+ "description": "Id of setting\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "gradient"]
+ },
+ "GradientType": {
+ "javaType": "Gradient",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priority": {
+ "description": "Id of setting\r\n\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "gradient": {
+ "description": "Default ramp rate in seconds (0 if not applicable)\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "softGradient": {
+ "description": "Soft-start ramp rate in seconds (0 if not applicable)\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority", "gradient", "softGradient"]
+ },
+ "HysteresisType": {
+ "javaType": "Hysteresis",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hysteresisHigh": {
+ "description": "High value for return to normal operation after a grid event, in absolute value. This value adopts the same unit as defined by yUnit\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "hysteresisLow": {
+ "description": "Low value for return to normal operation after a grid event, in absolute value. This value adopts the same unit as defined by yUnit\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "hysteresisDelay": {
+ "description": "Delay in seconds, once grid parameter within HysteresisLow and HysteresisHigh, for the EV to return to normal operation after a grid event.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "hysteresisGradient": {
+ "description": "Set default rate of change (ramp rate %/s) for the EV to return to normal operation after a grid event\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "LimitMaxDischargeGetType": {
+ "javaType": "LimitMaxDischargeGet",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Id of setting\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "isDefault": {
+ "description": "True if setting is a default control.\r\n",
+ "type": "boolean"
+ },
+ "isSuperseded": {
+ "description": "True if this setting is superseded by a higher priority setting (i.e. lower value of _priority_)\r\n\r\n",
+ "type": "boolean"
+ },
+ "limitMaxDischarge": {
+ "$ref": "#/definitions/LimitMaxDischargeType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "isDefault", "isSuperseded", "limitMaxDischarge"]
+ },
+ "LimitMaxDischargeType": {
+ "javaType": "LimitMaxDischarge",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priority": {
+ "description": "Priority of setting (0=highest)\r\n\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "pctMaxDischargePower": {
+ "description": "Only for PowerMonitoring. +\r\n The value specifies a percentage (0 to 100) of the rated maximum discharge power of EV. \r\n The PowerMonitoring curve becomes active when power exceeds this percentage.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "powerMonitoringMustTrip": {
+ "$ref": "#/definitions/DERCurveType"
+ },
+ "startTime": {
+ "description": "Time when this setting becomes active\r\n\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration in seconds that this setting is active\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority"]
+ },
+ "ReactivePowerParamsType": {
+ "javaType": "ReactivePowerParams",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "vRef": {
+ "description": "Only for VoltVar curve: The nominal ac voltage (rms) adjustment to the voltage curve points for Volt-Var curves (percentage).\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "autonomousVRefEnable": {
+ "description": "Only for VoltVar: Enable/disable autonomous VRef adjustment\r\n\r\n\r\n",
+ "type": "boolean"
+ },
+ "autonomousVRefTimeConstant": {
+ "description": "Only for VoltVar: Adjustment range for VRef time constant\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "VoltageParamsType": {
+ "javaType": "VoltageParams",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hv10MinMeanValue": {
+ "description": "EN 50549-1 chapter 4.9.3.4\r\n Voltage threshold for the 10 min time window mean value monitoring.\r\n The 10 min mean is recalculated up to every 3 s. \r\n If the present voltage is above this threshold for more than the time defined by _hv10MinMeanValue_, the EV must trip.\r\n This value is mandatory if _hv10MinMeanTripDelay_ is set.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "hv10MinMeanTripDelay": {
+ "description": "Time for which the voltage is allowed to stay above the 10 min mean value. \r\n After this time, the EV must trip.\r\n This value is mandatory if OverVoltageMeanValue10min is set.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "powerDuringCessation": {
+ "$ref": "#/definitions/PowerDuringCessationEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "curve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/DERCurveGetType"
+ },
+ "minItems": 1,
+ "maxItems": 24
+ },
+ "enterService": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/EnterServiceGetType"
+ },
+ "minItems": 1,
+ "maxItems": 24
+ },
+ "fixedPFAbsorb": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/FixedPFGetType"
+ },
+ "minItems": 1,
+ "maxItems": 24
+ },
+ "fixedPFInject": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/FixedPFGetType"
+ },
+ "minItems": 1,
+ "maxItems": 24
+ },
+ "fixedVar": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/FixedVarGetType"
+ },
+ "minItems": 1,
+ "maxItems": 24
+ },
+ "freqDroop": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/FreqDroopGetType"
+ },
+ "minItems": 1,
+ "maxItems": 24
+ },
+ "gradient": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/GradientGetType"
+ },
+ "minItems": 1,
+ "maxItems": 24
+ },
+ "limitMaxDischarge": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/LimitMaxDischargeGetType"
+ },
+ "minItems": 1,
+ "maxItems": 24
+ },
+ "requestId": {
+ "description": "RequestId from GetDERControlRequest.\r\n",
+ "type": "integer"
+ },
+ "tbc": {
+ "description": "To Be Continued. Default value when omitted: false. +\r\nFalse indicates that there are no further messages as part of this report.\r\n",
+ "type": "boolean"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ReportDERControlResponse",
+ "description": "This message has no parameters.\r\n\r\n",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:RequestBatterySwapRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalIdToken": {
+ "description": "*(2.1)* This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "_additionalInfo_ can be used to send extra information to CSMS in addition to the regular authorization with _IdToken_. _AdditionalInfo_ contains one or more custom _types_, which need to be agreed upon by all parties involved. When the _type_ is not supported, the CSMS/Charging Station MAY ignore the _additionalInfo_.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "*(2.1)* IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "*(2.1)* Enumeration of possible idToken types. Values defined in Appendix as IdTokenEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "requestId": {
+ "description": "Request id to match with BatterySwapRequest.\r\n\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId", "idToken"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:RequestBatterySwapResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericStatusEnumType": {
+ "description": "Accepted or rejected the request.\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:RequestStartTransactionRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingProfileKindEnumType": {
+ "description": "Indicates the kind of schedule.\r\n",
+ "javaType": "ChargingProfileKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Absolute", "Recurring", "Relative", "Dynamic"]
+ },
+ "ChargingProfilePurposeEnumType": {
+ "description": "Defines the purpose of the schedule transferred by this profile\r\n",
+ "javaType": "ChargingProfilePurposeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ChargingStationExternalConstraints",
+ "ChargingStationMaxProfile",
+ "TxDefaultProfile",
+ "TxProfile",
+ "PriorityCharging",
+ "LocalGeneration"
+ ]
+ },
+ "ChargingRateUnitEnumType": {
+ "description": "The unit of measure in which limits and setpoints are expressed.\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "CostKindEnumType": {
+ "description": "The kind of cost referred to in the message element amount\r\n",
+ "javaType": "CostKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CarbonDioxideEmission", "RelativePricePercentage", "RenewableGenerationPercentage"]
+ },
+ "OperationModeEnumType": {
+ "description": "*(2.1)* Charging operation mode to use during this time interval. When absent defaults to `ChargingOnly`.\r\n",
+ "javaType": "OperationModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Idle",
+ "ChargingOnly",
+ "CentralSetpoint",
+ "ExternalSetpoint",
+ "ExternalLimits",
+ "CentralFrequency",
+ "LocalFrequency",
+ "LocalLoadBalancing"
+ ]
+ },
+ "RecurrencyKindEnumType": {
+ "description": "Indicates the start point of a recurrence.\r\n",
+ "javaType": "RecurrencyKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Daily", "Weekly"]
+ },
+ "AbsolutePriceScheduleType": {
+ "description": "The AbsolutePriceScheduleType is modeled after the same type that is defined in ISO 15118-20, such that if it is supplied by an EMSP as a signed EXI message, the conversion from EXI to JSON (in OCPP) and back to EXI (for ISO 15118-20) does not change the digest and therefore does not invalidate the signature.\r\n\r\nimage::images/AbsolutePriceSchedule-Simple.png[]\r\n\r\n",
+ "javaType": "AbsolutePriceSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "timeAnchor": {
+ "description": "Starting point of price schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleID": {
+ "description": "Unique ID of price schedule\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "priceScheduleDescription": {
+ "description": "Description of the price schedule.\r\n",
+ "type": "string",
+ "maxLength": 160
+ },
+ "currency": {
+ "description": "Currency according to ISO 4217.\r\n",
+ "type": "string",
+ "maxLength": 3
+ },
+ "language": {
+ "description": "String that indicates what language is used for the human readable strings in the price schedule. Based on ISO 639.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "priceAlgorithm": {
+ "description": "A string in URN notation which shall uniquely identify an algorithm that defines how to compute an energy fee sum for a specific power profile based on the EnergyFee information from the PriceRule elements.\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "minimumCost": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "maximumCost": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "priceRuleStacks": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceRuleStackType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "taxRules": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 10
+ },
+ "overstayRuleList": {
+ "$ref": "#/definitions/OverstayRuleListType"
+ },
+ "additionalSelectedServices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalSelectedServicesType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "timeAnchor",
+ "priceScheduleID",
+ "currency",
+ "language",
+ "priceAlgorithm",
+ "priceRuleStacks"
+ ]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalIdToken": {
+ "description": "*(2.1)* This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "_additionalInfo_ can be used to send extra information to CSMS in addition to the regular authorization with _IdToken_. _AdditionalInfo_ contains one or more custom _types_, which need to be agreed upon by all parties involved. When the _type_ is not supported, the CSMS/Charging Station MAY ignore the _additionalInfo_.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "AdditionalSelectedServicesType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "AdditionalSelectedServices",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "serviceFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "serviceName": {
+ "description": "Human readable string to identify this service.\r\n",
+ "type": "string",
+ "maxLength": 80
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["serviceName", "serviceFee"]
+ },
+ "ChargingProfileType": {
+ "description": "A ChargingProfile consists of 1 to 3 ChargingSchedules with a list of ChargingSchedulePeriods, describing the amount of power or current that can be delivered per time interval.\r\n\r\nimage::images/ChargingProfile-Simple.png[]\r\n\r\n",
+ "javaType": "ChargingProfile",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Id of ChargingProfile. Unique within charging station. Id can have a negative value. This is useful to distinguish charging profiles from an external actor (external constraints) from charging profiles received from CSMS.\r\n",
+ "type": "integer"
+ },
+ "stackLevel": {
+ "description": "Value determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "chargingProfilePurpose": {
+ "$ref": "#/definitions/ChargingProfilePurposeEnumType"
+ },
+ "chargingProfileKind": {
+ "$ref": "#/definitions/ChargingProfileKindEnumType"
+ },
+ "recurrencyKind": {
+ "$ref": "#/definitions/RecurrencyKindEnumType"
+ },
+ "validFrom": {
+ "description": "Point in time at which the profile starts to be valid. If absent, the profile is valid as soon as it is received by the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "validTo": {
+ "description": "Point in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "transactionId": {
+ "description": "SHALL only be included if ChargingProfilePurpose is set to TxProfile in a SetChargingProfileRequest. The transactionId is used to match the profile to a specific transaction.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "maxOfflineDuration": {
+ "description": "*(2.1)* Period in seconds that this charging profile remains valid after the Charging Station has gone offline. After this period the charging profile becomes invalid for as long as it is offline and the Charging Station reverts back to a valid profile with a lower stack level. \r\nIf _invalidAfterOfflineDuration_ is true, then this charging profile will become permanently invalid.\r\nA value of 0 means that the charging profile is immediately invalid while offline. When the field is absent, then no timeout applies and the charging profile remains valid when offline.\r\n",
+ "type": "integer"
+ },
+ "chargingSchedule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingScheduleType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "invalidAfterOfflineDuration": {
+ "description": "*(2.1)* When set to true this charging profile will not be valid anymore after being offline for more than _maxOfflineDuration_. +\r\n When absent defaults to false.\r\n",
+ "type": "boolean"
+ },
+ "dynUpdateInterval": {
+ "description": "*(2.1)* Interval in seconds after receipt of last update, when to request a profile update by sending a PullDynamicScheduleUpdateRequest message.\r\n A value of 0 or no value means that no update interval applies. +\r\n Only relevant in a dynamic charging profile.\r\n\r\n",
+ "type": "integer"
+ },
+ "dynUpdateTime": {
+ "description": "*(2.1)* Time at which limits or setpoints in this charging profile were last updated by a PullDynamicScheduleUpdateRequest or UpdateDynamicScheduleRequest or by an external actor. +\r\n Only relevant in a dynamic charging profile.\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleSignature": {
+ "description": "*(2.1)* ISO 15118-20 signature for all price schedules in _chargingSchedules_. +\r\nNote: for 256-bit elliptic curves (like secp256k1) the ECDSA signature is 512 bits (64 bytes) and for 521-bit curves (like secp521r1) the signature is 1042 bits. This equals 131 bytes, which can be encoded as base64 in 176 bytes.\r\n",
+ "type": "string",
+ "maxLength": 256
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "id",
+ "stackLevel",
+ "chargingProfilePurpose",
+ "chargingProfileKind",
+ "chargingSchedule"
+ ]
+ },
+ "ChargingSchedulePeriodType": {
+ "description": "Charging schedule period structure defines a time period in a charging schedule. It is used in: CompositeScheduleType and in ChargingScheduleType. When used in a NotifyEVChargingScheduleRequest only _startPeriod_, _limit_, _limit_L2_, _limit_L3_ are relevant.\r\n",
+ "javaType": "ChargingSchedulePeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startPeriod": {
+ "description": "Start of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.\r\n",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Optional only when not required by the _operationMode_, as in CentralSetpoint, ExternalSetpoint, ExternalLimits, LocalFrequency, LocalLoadBalancing. +\r\nCharging rate limit during the schedule period, in the applicable _chargingRateUnit_. \r\nThis SHOULD be a non-negative value; a negative value is only supported for backwards compatibility with older systems that use a negative value to specify a discharging limit.\r\nWhen using _chargingRateUnit_ = `W`, this field represents the sum of the power of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "limit_L2": {
+ "description": "*(2.1)* Charging rate limit on phase L2 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "limit_L3": {
+ "description": "*(2.1)* Charging rate limit on phase L3 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "numberPhases": {
+ "description": "The number of phases that can be used for charging. +\r\nFor a DC EVSE this field should be omitted. +\r\nFor an AC EVSE a default value of _numberPhases_ = 3 will be assumed if the field is absent.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "phaseToUse": {
+ "description": "Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true. It\u2019s not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "dischargeLimit": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ that the EV is allowed to discharge with. Note, these are negative values in order to be consistent with _setpoint_, which can be positive and negative. +\r\nFor AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L2": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L2 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L3": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L3 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "setpoint": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow as close as possible. Use negative values for discharging. +\r\nWhen a limit and/or _dischargeLimit_ are given the overshoot when following _setpoint_ must remain within these values.\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpoint_L2": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L2 as close as possible.\r\n",
+ "type": "number"
+ },
+ "setpoint_L3": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L3 as close as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow as closely as possible. Positive values for inductive, negative for capacitive reactive power or current. +\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpointReactive_L2": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L2 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive_L3": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L3 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "preconditioningRequest": {
+ "description": "*(2.1)* If true, the EV should attempt to keep the BMS preconditioned for this time interval.\r\n",
+ "type": "boolean"
+ },
+ "evseSleep": {
+ "description": "*(2.1)* If true, the EVSE must turn off power electronics/modules associated with this transaction. Default value when absent is false.\r\n",
+ "type": "boolean"
+ },
+ "v2xBaseline": {
+ "description": "*(2.1)* Power value that, when present, is used as a baseline on top of which values from _v2xFreqWattCurve_ and _v2xSignalWattCurve_ are added.\r\n\r\n",
+ "type": "number"
+ },
+ "operationMode": {
+ "$ref": "#/definitions/OperationModeEnumType"
+ },
+ "v2xFreqWattCurve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/V2XFreqWattPointType"
+ },
+ "minItems": 1,
+ "maxItems": 20
+ },
+ "v2xSignalWattCurve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/V2XSignalWattPointType"
+ },
+ "minItems": 1,
+ "maxItems": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startPeriod"]
+ },
+ "ChargingScheduleType": {
+ "description": "Charging schedule structure defines a list of charging periods, as used in: NotifyEVChargingScheduleRequest and ChargingProfileType. When used in a NotifyEVChargingScheduleRequest only _duration_ and _chargingSchedulePeriod_ are relevant and _chargingRateUnit_ must be 'W'. +\r\nAn ISO 15118-20 session may provide either an _absolutePriceSchedule_ or a _priceLevelSchedule_. An ISO 15118-2 session can only provide a_salesTariff_ element. The field _digestValue_ is used when price schedule or sales tariff are signed.\r\n\r\nimage::images/ChargingSchedule-Simple.png[]\r\n\r\n\r\n",
+ "javaType": "ChargingSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "integer"
+ },
+ "limitAtSoC": {
+ "$ref": "#/definitions/LimitAtSoCType"
+ },
+ "startSchedule": {
+ "description": "Starting point of an absolute schedule or recurring schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction in case startSchedule is absent.\r\n",
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "minChargingRate": {
+ "description": "Minimum charging rate supported by the EV. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates. \r\n",
+ "type": "number"
+ },
+ "powerTolerance": {
+ "description": "*(2.1)* Power tolerance when following EVPowerProfile.\r\n\r\n",
+ "type": "number"
+ },
+ "signatureId": {
+ "description": "*(2.1)* Id of this element for referencing in a signature.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "digestValue": {
+ "description": "*(2.1)* Base64 encoded hash (SHA256 for ISO 15118-2, SHA512 for ISO 15118-20) of the EXI price schedule element. Used in signature.\r\n",
+ "type": "string",
+ "maxLength": 88
+ },
+ "useLocalTime": {
+ "description": "*(2.1)* Defaults to false. When true, disregard time zone offset in dateTime fields of _ChargingScheduleType_ and use unqualified local time at Charging Station instead.\r\n This allows the same `Absolute` or `Recurring` charging profile to be used in both summer and winter time.\r\n\r\n",
+ "type": "boolean"
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingSchedulePeriodType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "randomizedDelay": {
+ "description": "*(2.1)* Defaults to 0. When _randomizedDelay_ not equals zero, then the start of each <<cmn_chargingscheduleperiodtype,ChargingSchedulePeriodType>> is delayed by a randomly chosen number of seconds between 0 and _randomizedDelay_. Only allowed for TxProfile and TxDefaultProfile.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariff": {
+ "$ref": "#/definitions/SalesTariffType"
+ },
+ "absolutePriceSchedule": {
+ "$ref": "#/definitions/AbsolutePriceScheduleType"
+ },
+ "priceLevelSchedule": {
+ "$ref": "#/definitions/PriceLevelScheduleType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "chargingRateUnit", "chargingSchedulePeriod"]
+ },
+ "ConsumptionCostType": {
+ "javaType": "ConsumptionCost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startValue": {
+ "description": "The lowest level of consumption that defines the starting point of this consumption block. The block interval extends to the start of the next interval.\r\n",
+ "type": "number"
+ },
+ "cost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startValue", "cost"]
+ },
+ "CostType": {
+ "javaType": "Cost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "costKind": {
+ "$ref": "#/definitions/CostKindEnumType"
+ },
+ "amount": {
+ "description": "The estimated or actual cost per kWh\r\n",
+ "type": "integer"
+ },
+ "amountMultiplier": {
+ "description": "Values: -3..3, The amountMultiplier defines the exponent to base 10 (dec). The final value is determined by: amount * 10 ^ amountMultiplier\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["costKind", "amount"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "*(2.1)* IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "*(2.1)* Enumeration of possible idToken types. Values defined in Appendix as IdTokenEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "LimitAtSoCType": {
+ "javaType": "LimitAtSoC",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "soc": {
+ "description": "The SoC value beyond which the charging rate limit should be applied.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "limit": {
+ "description": "Charging rate limit beyond the SoC value.\r\nThe unit is defined by _chargingSchedule.chargingRateUnit_.\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["soc", "limit"]
+ },
+ "OverstayRuleListType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "OverstayRuleList",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "overstayPowerThreshold": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "overstayRule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/OverstayRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "overstayTimeThreshold": {
+ "description": "Time till overstay is applied in seconds.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["overstayRule"]
+ },
+ "OverstayRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "OverstayRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "overstayFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "overstayRuleDescription": {
+ "description": "Human readable string to identify the overstay rule.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "startTime": {
+ "description": "Time in seconds after trigger of the parent Overstay Rules for this particular fee to apply.\r\n",
+ "type": "integer"
+ },
+ "overstayFeePeriod": {
+ "description": "Time till overstay will be reapplied\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startTime", "overstayFeePeriod", "overstayFee"]
+ },
+ "PriceLevelScheduleEntryType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n",
+ "javaType": "PriceLevelScheduleEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "The amount of seconds that define the duration of this given PriceLevelScheduleEntry.\r\n",
+ "type": "integer"
+ },
+ "priceLevel": {
+ "description": "Defines the price level of this PriceLevelScheduleEntry (referring to NumberOfPriceLevels). Small values for the PriceLevel represent a cheaper PriceLevelScheduleEntry. Large values for the PriceLevel represent a more expensive PriceLevelScheduleEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "priceLevel"]
+ },
+ "PriceLevelScheduleType": {
+ "description": "The PriceLevelScheduleType is modeled after the same type that is defined in ISO 15118-20, such that if it is supplied by an EMSP as a signed EXI message, the conversion from EXI to JSON (in OCPP) and back to EXI (for ISO 15118-20) does not change the digest and therefore does not invalidate the signature.\r\n",
+ "javaType": "PriceLevelSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priceLevelScheduleEntries": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceLevelScheduleEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 100
+ },
+ "timeAnchor": {
+ "description": "Starting point of this price schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleId": {
+ "description": "Unique ID of this price schedule.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "priceScheduleDescription": {
+ "description": "Description of the price schedule.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numberOfPriceLevels": {
+ "description": "Defines the overall number of distinct price level elements used across all PriceLevelSchedules.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "timeAnchor",
+ "priceScheduleId",
+ "numberOfPriceLevels",
+ "priceLevelScheduleEntries"
+ ]
+ },
+ "PriceRuleStackType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n",
+ "javaType": "PriceRuleStack",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "Duration of the stack of price rules. he amount of seconds that define the duration of the given PriceRule(s).\r\n",
+ "type": "integer"
+ },
+ "priceRule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 8
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "priceRule"]
+ },
+ "PriceRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "PriceRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "parkingFeePeriod": {
+ "description": "The duration of the parking fee period (in seconds).\r\nWhen the time enters into a ParkingFeePeriod, the ParkingFee will apply to the session. .\r\n",
+ "type": "integer"
+ },
+ "carbonDioxideEmission": {
+ "description": "Number of grams of CO2 per kWh.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "renewableGenerationPercentage": {
+ "description": "Percentage of the power that is created by renewable resources.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "energyFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "parkingFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "powerRangeStart": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["energyFee", "powerRangeStart"]
+ },
+ "RationalNumberType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "RationalNumber",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "exponent": {
+ "description": "The exponent to base 10 (dec)\r\n",
+ "type": "integer"
+ },
+ "value": {
+ "description": "Value which shall be multiplied.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["exponent", "value"]
+ },
+ "RelativeTimeIntervalType": {
+ "javaType": "RelativeTimeInterval",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "start": {
+ "description": "Start of the interval, in seconds from NOW.\r\n",
+ "type": "integer"
+ },
+ "duration": {
+ "description": "Duration of the interval, in seconds.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["start"]
+ },
+ "SalesTariffEntryType": {
+ "javaType": "SalesTariffEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "relativeTimeInterval": {
+ "$ref": "#/definitions/RelativeTimeIntervalType"
+ },
+ "ePriceLevel": {
+ "description": "Defines the price level of this SalesTariffEntry (referring to NumEPriceLevels). Small values for the EPriceLevel represent a cheaper TariffEntry. Large values for the EPriceLevel represent a more expensive TariffEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "consumptionCost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ConsumptionCostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["relativeTimeInterval"]
+ },
+ "SalesTariffType": {
+ "description": "A SalesTariff provided by a Mobility Operator (EMSP) .\r\nNOTE: This dataType is based on dataTypes from <<ref-ISOIEC15118-2,ISO 15118-2>>.\r\n",
+ "javaType": "SalesTariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "SalesTariff identifier used to identify one sales tariff. An SAID remains a unique identifier for one schedule throughout a charging session.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariffDescription": {
+ "description": "A human readable title/short description of the sales tariff e.g. for HMI display purposes.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numEPriceLevels": {
+ "description": "Defines the overall number of distinct price levels used across all provided SalesTariff elements.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariffEntry": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SalesTariffEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "salesTariffEntry"]
+ },
+ "TaxRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "TaxRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "taxRuleID": {
+ "description": "Id for the tax rule.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "taxRuleName": {
+ "description": "Human readable string to identify the tax rule.\r\n",
+ "type": "string",
+ "maxLength": 100
+ },
+ "taxIncludedInPrice": {
+ "description": "Indicates whether the tax is included in any price or not.\r\n",
+ "type": "boolean"
+ },
+ "appliesToEnergyFee": {
+ "description": "Indicates whether this tax applies to Energy Fees.\r\n",
+ "type": "boolean"
+ },
+ "appliesToParkingFee": {
+ "description": "Indicates whether this tax applies to Parking Fees.\r\n\r\n",
+ "type": "boolean"
+ },
+ "appliesToOverstayFee": {
+ "description": "Indicates whether this tax applies to Overstay Fees.\r\n\r\n",
+ "type": "boolean"
+ },
+ "appliesToMinimumMaximumCost": {
+ "description": "Indicates whether this tax applies to Minimum/Maximum Cost.\r\n\r\n",
+ "type": "boolean"
+ },
+ "taxRate": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "taxRuleID",
+ "appliesToEnergyFee",
+ "appliesToParkingFee",
+ "appliesToOverstayFee",
+ "appliesToMinimumMaximumCost",
+ "taxRate"
+ ]
+ },
+ "V2XFreqWattPointType": {
+ "description": "*(2.1)* A point of a frequency-watt curve.\r\n",
+ "javaType": "V2XFreqWattPoint",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "frequency": {
+ "description": "Net frequency in Hz.\r\n",
+ "type": "number"
+ },
+ "power": {
+ "description": "Power in W to charge (positive) or discharge (negative) at specified frequency.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["frequency", "power"]
+ },
+ "V2XSignalWattPointType": {
+ "description": "*(2.1)* A point of a signal-watt curve.\r\n",
+ "javaType": "V2XSignalWattPoint",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "signal": {
+ "description": "Signal value from an AFRRSignalRequest.\r\n",
+ "type": "integer"
+ },
+ "power": {
+ "description": "Power in W to charge (positive) or discharge (negative) at specified frequency.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["signal", "power"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evseId": {
+ "description": "Number of the EVSE on which to start the transaction. EvseId SHALL be > 0\r\n",
+ "type": "integer",
+ "minimum": 1.0
+ },
+ "groupIdToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "remoteStartId": {
+ "description": "Id given by the server to this start request. The Charging Station will return this in the <<transactioneventrequest, TransactionEventRequest>>, letting the server know which transaction was started for this request. Use to start a transaction.\r\n",
+ "type": "integer"
+ },
+ "chargingProfile": {
+ "$ref": "#/definitions/ChargingProfileType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["remoteStartId", "idToken"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:RequestStartTransactionResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "RequestStartStopStatusEnumType": {
+ "description": "Status indicating whether the Charging Station accepts the request to start a transaction.\r\n",
+ "javaType": "RequestStartStopStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/RequestStartStopStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "transactionId": {
+ "description": "When the transaction was already started by the Charging Station before the RequestStartTransactionRequest was received, for example: cable plugged in first. This contains the transactionId of the already started transaction.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:RequestStopTransactionRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "transactionId": {
+ "description": "The identifier of the transaction which the Charging Station is requested to stop.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["transactionId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:RequestStopTransactionResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "RequestStartStopStatusEnumType": {
+ "description": "Status indicating whether Charging Station accepts the request to stop a transaction.\r\n",
+ "javaType": "RequestStartStopStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/RequestStartStopStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ReservationStatusUpdateRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ReservationUpdateStatusEnumType": {
+ "description": "The updated reservation status.\r\n",
+ "javaType": "ReservationUpdateStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Expired", "Removed", "NoTransaction"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reservationId": {
+ "description": "The ID of the reservation.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "reservationUpdateStatus": {
+ "$ref": "#/definitions/ReservationUpdateStatusEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reservationId", "reservationUpdateStatus"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ReservationStatusUpdateResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ReserveNowRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalIdToken": {
+ "description": "*(2.1)* This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "_additionalInfo_ can be used to send extra information to CSMS in addition to the regular authorization with _IdToken_. _AdditionalInfo_ contains one or more custom _types_, which need to be agreed upon by all parties involved. When the _type_ is not supported, the CSMS/Charging Station MAY ignore the _additionalInfo_.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "*(2.1)* IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "*(2.1)* Enumeration of possible idToken types. Values defined in Appendix as IdTokenEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Id of reservation.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "expiryDateTime": {
+ "description": "Date and time at which the reservation expires.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "connectorType": {
+ "description": "This field specifies the connector type. Values defined in Appendix as ConnectorEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "evseId": {
+ "description": "This contains ID of the evse to be reserved.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "groupIdToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "expiryDateTime", "idToken"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ReserveNowResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ReserveNowStatusEnumType": {
+ "description": "This indicates the success or failure of the reservation.\r\n",
+ "javaType": "ReserveNowStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Faulted", "Occupied", "Rejected", "Unavailable"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/ReserveNowStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ResetRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ResetEnumType": {
+ "description": "This contains the type of reset that the Charging Station or EVSE should perform.\r\n",
+ "javaType": "ResetEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Immediate", "OnIdle", "ImmediateAndResume"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "$ref": "#/definitions/ResetEnumType"
+ },
+ "evseId": {
+ "description": "This contains the ID of a specific EVSE that needs to be reset, instead of the entire Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["type"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:ResetResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ResetStatusEnumType": {
+ "description": "This indicates whether the Charging Station is able to perform the reset.\r\n",
+ "javaType": "ResetStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Scheduled"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/ResetStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SecurityEventNotificationRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "description": "Type of the security event. This value should be taken from the Security events list.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "timestamp": {
+ "description": "Date and time at which the event occurred.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "techInfo": {
+ "description": "Additional information about the occurred security event.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["type", "timestamp"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SecurityEventNotificationResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SendLocalListRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "AuthorizationStatusEnumType": {
+ "description": "Current status of the ID Token.\r\n",
+ "javaType": "AuthorizationStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Blocked",
+ "ConcurrentTx",
+ "Expired",
+ "Invalid",
+ "NoCredit",
+ "NotAllowedTypeEVSE",
+ "NotAtThisLocation",
+ "NotAtThisTime",
+ "Unknown"
+ ]
+ },
+ "MessageFormatEnumType": {
+ "description": "Format of the message.\r\n",
+ "javaType": "MessageFormatEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ASCII", "HTML", "URI", "UTF8", "QRCODE"]
+ },
+ "UpdateEnumType": {
+ "description": "This contains the type of update (full or differential) of this request.\r\n",
+ "javaType": "UpdateEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Differential", "Full"]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalIdToken": {
+ "description": "*(2.1)* This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "_additionalInfo_ can be used to send extra information to CSMS in addition to the regular authorization with _IdToken_. _AdditionalInfo_ contains one or more custom _types_, which need to be agreed upon by all parties involved. When the _type_ is not supported, the CSMS/Charging Station MAY ignore the _additionalInfo_.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "AuthorizationData": {
+ "description": "Contains the identifier to use for authorization.\r\n",
+ "javaType": "AuthorizationData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "idTokenInfo": {
+ "$ref": "#/definitions/IdTokenInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idToken"]
+ },
+ "IdTokenInfoType": {
+ "description": "Contains status information about an identifier.\r\nIt is advised to not stop charging for a token that expires during charging, as ExpiryDate is only used for caching purposes. If ExpiryDate is not given, the status has no end date.\r\n",
+ "javaType": "IdTokenInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/AuthorizationStatusEnumType"
+ },
+ "cacheExpiryDateTime": {
+ "description": "Date and Time after which the token must be considered invalid.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingPriority": {
+ "description": "Priority from a business point of view. Default priority is 0, The range is from -9 to 9. Higher values indicate a higher priority. The chargingPriority in <<transactioneventresponse,TransactionEventResponse>> overrules this one. \r\n",
+ "type": "integer"
+ },
+ "groupIdToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "language1": {
+ "description": "Preferred user interface language of identifier user. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "language2": {
+ "description": "Second preferred user interface language of identifier user. Don\u2019t use when language1 is omitted, has to be different from language1. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "evseId": {
+ "description": "Only used when the IdToken is only valid for one or more specific EVSEs, not for the entire Charging Station.\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "minItems": 1
+ },
+ "personalMessage": {
+ "$ref": "#/definitions/MessageContentType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "*(2.1)* IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "*(2.1)* Enumeration of possible idToken types. Values defined in Appendix as IdTokenEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "MessageContentType": {
+ "description": "Contains message details, for a message to be displayed on a Charging Station.\r\n\r\n",
+ "javaType": "MessageContent",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "format": {
+ "$ref": "#/definitions/MessageFormatEnumType"
+ },
+ "language": {
+ "description": "Message language identifier. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "content": {
+ "description": "*(2.1)* Required. Message contents. +\r\nMaximum length supported by Charging Station is given in OCPPCommCtrlr.FieldLength[\"MessageContentType.content\"].\r\n Maximum length defaults to 1024.\r\n\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["format", "content"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "localAuthorizationList": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AuthorizationData"
+ },
+ "minItems": 1
+ },
+ "versionNumber": {
+ "description": "In case of a full update this is the version number of the full list. In case of a differential update it is the version number of the list after the update has been applied.\r\n",
+ "type": "integer"
+ },
+ "updateType": {
+ "$ref": "#/definitions/UpdateEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["versionNumber", "updateType"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SendLocalListResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "SendLocalListStatusEnumType": {
+ "description": "This indicates whether the Charging Station has successfully received and applied the update of the Local Authorization List.\r\n",
+ "javaType": "SendLocalListStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Failed", "VersionMismatch"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/SendLocalListStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetChargingProfileRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingProfileKindEnumType": {
+ "description": "Indicates the kind of schedule.\r\n",
+ "javaType": "ChargingProfileKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Absolute", "Recurring", "Relative", "Dynamic"]
+ },
+ "ChargingProfilePurposeEnumType": {
+ "description": "Defines the purpose of the schedule transferred by this profile\r\n",
+ "javaType": "ChargingProfilePurposeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "ChargingStationExternalConstraints",
+ "ChargingStationMaxProfile",
+ "TxDefaultProfile",
+ "TxProfile",
+ "PriorityCharging",
+ "LocalGeneration"
+ ]
+ },
+ "ChargingRateUnitEnumType": {
+ "description": "The unit of measure in which limits and setpoints are expressed.\r\n",
+ "javaType": "ChargingRateUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["W", "A"]
+ },
+ "CostKindEnumType": {
+ "description": "The kind of cost referred to in the message element amount\r\n",
+ "javaType": "CostKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["CarbonDioxideEmission", "RelativePricePercentage", "RenewableGenerationPercentage"]
+ },
+ "OperationModeEnumType": {
+ "description": "*(2.1)* Charging operation mode to use during this time interval. When absent defaults to `ChargingOnly`.\r\n",
+ "javaType": "OperationModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Idle",
+ "ChargingOnly",
+ "CentralSetpoint",
+ "ExternalSetpoint",
+ "ExternalLimits",
+ "CentralFrequency",
+ "LocalFrequency",
+ "LocalLoadBalancing"
+ ]
+ },
+ "RecurrencyKindEnumType": {
+ "description": "Indicates the start point of a recurrence.\r\n",
+ "javaType": "RecurrencyKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Daily", "Weekly"]
+ },
+ "AbsolutePriceScheduleType": {
+ "description": "The AbsolutePriceScheduleType is modeled after the same type that is defined in ISO 15118-20, such that if it is supplied by an EMSP as a signed EXI message, the conversion from EXI to JSON (in OCPP) and back to EXI (for ISO 15118-20) does not change the digest and therefore does not invalidate the signature.\r\n\r\nimage::images/AbsolutePriceSchedule-Simple.png[]\r\n\r\n",
+ "javaType": "AbsolutePriceSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "timeAnchor": {
+ "description": "Starting point of price schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleID": {
+ "description": "Unique ID of price schedule\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "priceScheduleDescription": {
+ "description": "Description of the price schedule.\r\n",
+ "type": "string",
+ "maxLength": 160
+ },
+ "currency": {
+ "description": "Currency according to ISO 4217.\r\n",
+ "type": "string",
+ "maxLength": 3
+ },
+ "language": {
+ "description": "String that indicates what language is used for the human readable strings in the price schedule. Based on ISO 639.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "priceAlgorithm": {
+ "description": "A string in URN notation which shall uniquely identify an algorithm that defines how to compute an energy fee sum for a specific power profile based on the EnergyFee information from the PriceRule elements.\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "minimumCost": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "maximumCost": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "priceRuleStacks": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceRuleStackType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "taxRules": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 10
+ },
+ "overstayRuleList": {
+ "$ref": "#/definitions/OverstayRuleListType"
+ },
+ "additionalSelectedServices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalSelectedServicesType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "timeAnchor",
+ "priceScheduleID",
+ "currency",
+ "language",
+ "priceAlgorithm",
+ "priceRuleStacks"
+ ]
+ },
+ "AdditionalSelectedServicesType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "AdditionalSelectedServices",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "serviceFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "serviceName": {
+ "description": "Human readable string to identify this service.\r\n",
+ "type": "string",
+ "maxLength": 80
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["serviceName", "serviceFee"]
+ },
+ "ChargingProfileType": {
+ "description": "A ChargingProfile consists of 1 to 3 ChargingSchedules with a list of ChargingSchedulePeriods, describing the amount of power or current that can be delivered per time interval.\r\n\r\nimage::images/ChargingProfile-Simple.png[]\r\n\r\n",
+ "javaType": "ChargingProfile",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Id of ChargingProfile. Unique within charging station. Id can have a negative value. This is useful to distinguish charging profiles from an external actor (external constraints) from charging profiles received from CSMS.\r\n",
+ "type": "integer"
+ },
+ "stackLevel": {
+ "description": "Value determining level in hierarchy stack of profiles. Higher values have precedence over lower values. Lowest level is 0.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "chargingProfilePurpose": {
+ "$ref": "#/definitions/ChargingProfilePurposeEnumType"
+ },
+ "chargingProfileKind": {
+ "$ref": "#/definitions/ChargingProfileKindEnumType"
+ },
+ "recurrencyKind": {
+ "$ref": "#/definitions/RecurrencyKindEnumType"
+ },
+ "validFrom": {
+ "description": "Point in time at which the profile starts to be valid. If absent, the profile is valid as soon as it is received by the Charging Station.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "validTo": {
+ "description": "Point in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "transactionId": {
+ "description": "SHALL only be included if ChargingProfilePurpose is set to TxProfile in a SetChargingProfileRequest. The transactionId is used to match the profile to a specific transaction.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "maxOfflineDuration": {
+ "description": "*(2.1)* Period in seconds that this charging profile remains valid after the Charging Station has gone offline. After this period the charging profile becomes invalid for as long as it is offline and the Charging Station reverts back to a valid profile with a lower stack level. \r\nIf _invalidAfterOfflineDuration_ is true, then this charging profile will become permanently invalid.\r\nA value of 0 means that the charging profile is immediately invalid while offline. When the field is absent, then no timeout applies and the charging profile remains valid when offline.\r\n",
+ "type": "integer"
+ },
+ "chargingSchedule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingScheduleType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "invalidAfterOfflineDuration": {
+ "description": "*(2.1)* When set to true this charging profile will not be valid anymore after being offline for more than _maxOfflineDuration_. +\r\n When absent defaults to false.\r\n",
+ "type": "boolean"
+ },
+ "dynUpdateInterval": {
+ "description": "*(2.1)* Interval in seconds after receipt of last update, when to request a profile update by sending a PullDynamicScheduleUpdateRequest message.\r\n A value of 0 or no value means that no update interval applies. +\r\n Only relevant in a dynamic charging profile.\r\n\r\n",
+ "type": "integer"
+ },
+ "dynUpdateTime": {
+ "description": "*(2.1)* Time at which limits or setpoints in this charging profile were last updated by a PullDynamicScheduleUpdateRequest or UpdateDynamicScheduleRequest or by an external actor. +\r\n Only relevant in a dynamic charging profile.\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleSignature": {
+ "description": "*(2.1)* ISO 15118-20 signature for all price schedules in _chargingSchedules_. +\r\nNote: for 256-bit elliptic curves (like secp256k1) the ECDSA signature is 512 bits (64 bytes) and for 521-bit curves (like secp521r1) the signature is 1042 bits. This equals 131 bytes, which can be encoded as base64 in 176 bytes.\r\n",
+ "type": "string",
+ "maxLength": 256
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "id",
+ "stackLevel",
+ "chargingProfilePurpose",
+ "chargingProfileKind",
+ "chargingSchedule"
+ ]
+ },
+ "ChargingSchedulePeriodType": {
+ "description": "Charging schedule period structure defines a time period in a charging schedule. It is used in: CompositeScheduleType and in ChargingScheduleType. When used in a NotifyEVChargingScheduleRequest only _startPeriod_, _limit_, _limit_L2_, _limit_L3_ are relevant.\r\n",
+ "javaType": "ChargingSchedulePeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startPeriod": {
+ "description": "Start of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.\r\n",
+ "type": "integer"
+ },
+ "limit": {
+ "description": "Optional only when not required by the _operationMode_, as in CentralSetpoint, ExternalSetpoint, ExternalLimits, LocalFrequency, LocalLoadBalancing. +\r\nCharging rate limit during the schedule period, in the applicable _chargingRateUnit_. \r\nThis SHOULD be a non-negative value; a negative value is only supported for backwards compatibility with older systems that use a negative value to specify a discharging limit.\r\nWhen using _chargingRateUnit_ = `W`, this field represents the sum of the power of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "limit_L2": {
+ "description": "*(2.1)* Charging rate limit on phase L2 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "limit_L3": {
+ "description": "*(2.1)* Charging rate limit on phase L3 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "numberPhases": {
+ "description": "The number of phases that can be used for charging. +\r\nFor a DC EVSE this field should be omitted. +\r\nFor an AC EVSE a default value of _numberPhases_ = 3 will be assumed if the field is absent.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "phaseToUse": {
+ "description": "Values: 1..3, Used if numberPhases=1 and if the EVSE is capable of switching the phase connected to the EV, i.e. ACPhaseSwitchingSupported is defined and true. It\u2019s not allowed unless both conditions above are true. If both conditions are true, and phaseToUse is omitted, the Charging Station / EVSE will make the selection on its own.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "dischargeLimit": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ that the EV is allowed to discharge with. Note, these are negative values in order to be consistent with _setpoint_, which can be positive and negative. +\r\nFor AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L2": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L2 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L3": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L3 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "setpoint": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow as close as possible. Use negative values for discharging. +\r\nWhen a limit and/or _dischargeLimit_ are given the overshoot when following _setpoint_ must remain within these values.\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpoint_L2": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L2 as close as possible.\r\n",
+ "type": "number"
+ },
+ "setpoint_L3": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L3 as close as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow as closely as possible. Positive values for inductive, negative for capacitive reactive power or current. +\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpointReactive_L2": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L2 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive_L3": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L3 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "preconditioningRequest": {
+ "description": "*(2.1)* If true, the EV should attempt to keep the BMS preconditioned for this time interval.\r\n",
+ "type": "boolean"
+ },
+ "evseSleep": {
+ "description": "*(2.1)* If true, the EVSE must turn off power electronics/modules associated with this transaction. Default value when absent is false.\r\n",
+ "type": "boolean"
+ },
+ "v2xBaseline": {
+ "description": "*(2.1)* Power value that, when present, is used as a baseline on top of which values from _v2xFreqWattCurve_ and _v2xSignalWattCurve_ are added.\r\n\r\n",
+ "type": "number"
+ },
+ "operationMode": {
+ "$ref": "#/definitions/OperationModeEnumType"
+ },
+ "v2xFreqWattCurve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/V2XFreqWattPointType"
+ },
+ "minItems": 1,
+ "maxItems": 20
+ },
+ "v2xSignalWattCurve": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/V2XSignalWattPointType"
+ },
+ "minItems": 1,
+ "maxItems": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startPeriod"]
+ },
+ "ChargingScheduleType": {
+ "description": "Charging schedule structure defines a list of charging periods, as used in: NotifyEVChargingScheduleRequest and ChargingProfileType. When used in a NotifyEVChargingScheduleRequest only _duration_ and _chargingSchedulePeriod_ are relevant and _chargingRateUnit_ must be 'W'. +\r\nAn ISO 15118-20 session may provide either an _absolutePriceSchedule_ or a _priceLevelSchedule_. An ISO 15118-2 session can only provide a_salesTariff_ element. The field _digestValue_ is used when price schedule or sales tariff are signed.\r\n\r\nimage::images/ChargingSchedule-Simple.png[]\r\n\r\n\r\n",
+ "javaType": "ChargingSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "integer"
+ },
+ "limitAtSoC": {
+ "$ref": "#/definitions/LimitAtSoCType"
+ },
+ "startSchedule": {
+ "description": "Starting point of an absolute schedule or recurring schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely or until end of the transaction in case startSchedule is absent.\r\n",
+ "type": "integer"
+ },
+ "chargingRateUnit": {
+ "$ref": "#/definitions/ChargingRateUnitEnumType"
+ },
+ "minChargingRate": {
+ "description": "Minimum charging rate supported by the EV. The unit of measure is defined by the chargingRateUnit. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation for in the case a charging process is inefficient at lower charging rates. \r\n",
+ "type": "number"
+ },
+ "powerTolerance": {
+ "description": "*(2.1)* Power tolerance when following EVPowerProfile.\r\n\r\n",
+ "type": "number"
+ },
+ "signatureId": {
+ "description": "*(2.1)* Id of this element for referencing in a signature.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "digestValue": {
+ "description": "*(2.1)* Base64 encoded hash (SHA256 for ISO 15118-2, SHA512 for ISO 15118-20) of the EXI price schedule element. Used in signature.\r\n",
+ "type": "string",
+ "maxLength": 88
+ },
+ "useLocalTime": {
+ "description": "*(2.1)* Defaults to false. When true, disregard time zone offset in dateTime fields of _ChargingScheduleType_ and use unqualified local time at Charging Station instead.\r\n This allows the same `Absolute` or `Recurring` charging profile to be used in both summer and winter time.\r\n\r\n",
+ "type": "boolean"
+ },
+ "chargingSchedulePeriod": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingSchedulePeriodType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "randomizedDelay": {
+ "description": "*(2.1)* Defaults to 0. When _randomizedDelay_ not equals zero, then the start of each <<cmn_chargingscheduleperiodtype,ChargingSchedulePeriodType>> is delayed by a randomly chosen number of seconds between 0 and _randomizedDelay_. Only allowed for TxProfile and TxDefaultProfile.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariff": {
+ "$ref": "#/definitions/SalesTariffType"
+ },
+ "absolutePriceSchedule": {
+ "$ref": "#/definitions/AbsolutePriceScheduleType"
+ },
+ "priceLevelSchedule": {
+ "$ref": "#/definitions/PriceLevelScheduleType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "chargingRateUnit", "chargingSchedulePeriod"]
+ },
+ "ConsumptionCostType": {
+ "javaType": "ConsumptionCost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startValue": {
+ "description": "The lowest level of consumption that defines the starting point of this consumption block. The block interval extends to the start of the next interval.\r\n",
+ "type": "number"
+ },
+ "cost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startValue", "cost"]
+ },
+ "CostType": {
+ "javaType": "Cost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "costKind": {
+ "$ref": "#/definitions/CostKindEnumType"
+ },
+ "amount": {
+ "description": "The estimated or actual cost per kWh\r\n",
+ "type": "integer"
+ },
+ "amountMultiplier": {
+ "description": "Values: -3..3, The amountMultiplier defines the exponent to base 10 (dec). The final value is determined by: amount * 10 ^ amountMultiplier\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["costKind", "amount"]
+ },
+ "LimitAtSoCType": {
+ "javaType": "LimitAtSoC",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "soc": {
+ "description": "The SoC value beyond which the charging rate limit should be applied.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "limit": {
+ "description": "Charging rate limit beyond the SoC value.\r\nThe unit is defined by _chargingSchedule.chargingRateUnit_.\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["soc", "limit"]
+ },
+ "OverstayRuleListType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "OverstayRuleList",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "overstayPowerThreshold": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "overstayRule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/OverstayRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "overstayTimeThreshold": {
+ "description": "Time till overstay is applied in seconds.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["overstayRule"]
+ },
+ "OverstayRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "OverstayRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "overstayFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "overstayRuleDescription": {
+ "description": "Human readable string to identify the overstay rule.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "startTime": {
+ "description": "Time in seconds after trigger of the parent Overstay Rules for this particular fee to apply.\r\n",
+ "type": "integer"
+ },
+ "overstayFeePeriod": {
+ "description": "Time till overstay will be reapplied\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startTime", "overstayFeePeriod", "overstayFee"]
+ },
+ "PriceLevelScheduleEntryType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n",
+ "javaType": "PriceLevelScheduleEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "The amount of seconds that define the duration of this given PriceLevelScheduleEntry.\r\n",
+ "type": "integer"
+ },
+ "priceLevel": {
+ "description": "Defines the price level of this PriceLevelScheduleEntry (referring to NumberOfPriceLevels). Small values for the PriceLevel represent a cheaper PriceLevelScheduleEntry. Large values for the PriceLevel represent a more expensive PriceLevelScheduleEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "priceLevel"]
+ },
+ "PriceLevelScheduleType": {
+ "description": "The PriceLevelScheduleType is modeled after the same type that is defined in ISO 15118-20, such that if it is supplied by an EMSP as a signed EXI message, the conversion from EXI to JSON (in OCPP) and back to EXI (for ISO 15118-20) does not change the digest and therefore does not invalidate the signature.\r\n",
+ "javaType": "PriceLevelSchedule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priceLevelScheduleEntries": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceLevelScheduleEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 100
+ },
+ "timeAnchor": {
+ "description": "Starting point of this price schedule.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "priceScheduleId": {
+ "description": "Unique ID of this price schedule.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "priceScheduleDescription": {
+ "description": "Description of the price schedule.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numberOfPriceLevels": {
+ "description": "Defines the overall number of distinct price level elements used across all PriceLevelSchedules.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "timeAnchor",
+ "priceScheduleId",
+ "numberOfPriceLevels",
+ "priceLevelScheduleEntries"
+ ]
+ },
+ "PriceRuleStackType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n",
+ "javaType": "PriceRuleStack",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "duration": {
+ "description": "Duration of the stack of price rules. he amount of seconds that define the duration of the given PriceRule(s).\r\n",
+ "type": "integer"
+ },
+ "priceRule": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/PriceRuleType"
+ },
+ "minItems": 1,
+ "maxItems": 8
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["duration", "priceRule"]
+ },
+ "PriceRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "PriceRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "parkingFeePeriod": {
+ "description": "The duration of the parking fee period (in seconds).\r\nWhen the time enters into a ParkingFeePeriod, the ParkingFee will apply to the session. .\r\n",
+ "type": "integer"
+ },
+ "carbonDioxideEmission": {
+ "description": "Number of grams of CO2 per kWh.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "renewableGenerationPercentage": {
+ "description": "Percentage of the power that is created by renewable resources.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "energyFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "parkingFee": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "powerRangeStart": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["energyFee", "powerRangeStart"]
+ },
+ "RationalNumberType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "RationalNumber",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "exponent": {
+ "description": "The exponent to base 10 (dec)\r\n",
+ "type": "integer"
+ },
+ "value": {
+ "description": "Value which shall be multiplied.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["exponent", "value"]
+ },
+ "RelativeTimeIntervalType": {
+ "javaType": "RelativeTimeInterval",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "start": {
+ "description": "Start of the interval, in seconds from NOW.\r\n",
+ "type": "integer"
+ },
+ "duration": {
+ "description": "Duration of the interval, in seconds.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["start"]
+ },
+ "SalesTariffEntryType": {
+ "javaType": "SalesTariffEntry",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "relativeTimeInterval": {
+ "$ref": "#/definitions/RelativeTimeIntervalType"
+ },
+ "ePriceLevel": {
+ "description": "Defines the price level of this SalesTariffEntry (referring to NumEPriceLevels). Small values for the EPriceLevel represent a cheaper TariffEntry. Large values for the EPriceLevel represent a more expensive TariffEntry.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "consumptionCost": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ConsumptionCostType"
+ },
+ "minItems": 1,
+ "maxItems": 3
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["relativeTimeInterval"]
+ },
+ "SalesTariffType": {
+ "description": "A SalesTariff provided by a Mobility Operator (EMSP) .\r\nNOTE: This dataType is based on dataTypes from <<ref-ISOIEC15118-2,ISO 15118-2>>.\r\n",
+ "javaType": "SalesTariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "SalesTariff identifier used to identify one sales tariff. An SAID remains a unique identifier for one schedule throughout a charging session.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariffDescription": {
+ "description": "A human readable title/short description of the sales tariff e.g. for HMI display purposes.\r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "numEPriceLevels": {
+ "description": "Defines the overall number of distinct price levels used across all provided SalesTariff elements.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "salesTariffEntry": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SalesTariffEntryType"
+ },
+ "minItems": 1,
+ "maxItems": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "salesTariffEntry"]
+ },
+ "TaxRuleType": {
+ "description": "Part of ISO 15118-20 price schedule.\r\n\r\n",
+ "javaType": "TaxRule",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "taxRuleID": {
+ "description": "Id for the tax rule.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "taxRuleName": {
+ "description": "Human readable string to identify the tax rule.\r\n",
+ "type": "string",
+ "maxLength": 100
+ },
+ "taxIncludedInPrice": {
+ "description": "Indicates whether the tax is included in any price or not.\r\n",
+ "type": "boolean"
+ },
+ "appliesToEnergyFee": {
+ "description": "Indicates whether this tax applies to Energy Fees.\r\n",
+ "type": "boolean"
+ },
+ "appliesToParkingFee": {
+ "description": "Indicates whether this tax applies to Parking Fees.\r\n\r\n",
+ "type": "boolean"
+ },
+ "appliesToOverstayFee": {
+ "description": "Indicates whether this tax applies to Overstay Fees.\r\n\r\n",
+ "type": "boolean"
+ },
+ "appliesToMinimumMaximumCost": {
+ "description": "Indicates whether this tax applies to Minimum/Maximum Cost.\r\n\r\n",
+ "type": "boolean"
+ },
+ "taxRate": {
+ "$ref": "#/definitions/RationalNumberType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "taxRuleID",
+ "appliesToEnergyFee",
+ "appliesToParkingFee",
+ "appliesToOverstayFee",
+ "appliesToMinimumMaximumCost",
+ "taxRate"
+ ]
+ },
+ "V2XFreqWattPointType": {
+ "description": "*(2.1)* A point of a frequency-watt curve.\r\n",
+ "javaType": "V2XFreqWattPoint",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "frequency": {
+ "description": "Net frequency in Hz.\r\n",
+ "type": "number"
+ },
+ "power": {
+ "description": "Power in W to charge (positive) or discharge (negative) at specified frequency.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["frequency", "power"]
+ },
+ "V2XSignalWattPointType": {
+ "description": "*(2.1)* A point of a signal-watt curve.\r\n",
+ "javaType": "V2XSignalWattPoint",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "signal": {
+ "description": "Signal value from an AFRRSignalRequest.\r\n",
+ "type": "integer"
+ },
+ "power": {
+ "description": "Power in W to charge (positive) or discharge (negative) at specified frequency.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["signal", "power"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evseId": {
+ "description": "For TxDefaultProfile an evseId=0 applies the profile to each individual evse. For ChargingStationMaxProfile and ChargingStationExternalConstraints an evseId=0 contains an overal limit for the whole Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "chargingProfile": {
+ "$ref": "#/definitions/ChargingProfileType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["evseId", "chargingProfile"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetChargingProfileResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingProfileStatusEnumType": {
+ "description": "Returns whether the Charging Station has been able to process the message successfully. This does not guarantee the schedule will be followed to the letter. There might be other constraints the Charging Station may need to take into account.\r\n",
+ "javaType": "ChargingProfileStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/ChargingProfileStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetDERControlRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DERControlEnumType": {
+ "description": "Type of control. Determines which setting field below is used.\r\n\r\n",
+ "javaType": "DERControlEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "EnterService",
+ "FreqDroop",
+ "FreqWatt",
+ "FixedPFAbsorb",
+ "FixedPFInject",
+ "FixedVar",
+ "Gradients",
+ "HFMustTrip",
+ "HFMayTrip",
+ "HVMustTrip",
+ "HVMomCess",
+ "HVMayTrip",
+ "LimitMaxDischarge",
+ "LFMustTrip",
+ "LVMustTrip",
+ "LVMomCess",
+ "LVMayTrip",
+ "PowerMonitoringMustTrip",
+ "VoltVar",
+ "VoltWatt",
+ "WattPF",
+ "WattVar"
+ ]
+ },
+ "DERUnitEnumType": {
+ "description": "Unit of the setpoint.\r\n",
+ "javaType": "DERUnitEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Not_Applicable",
+ "PctMaxW",
+ "PctMaxVar",
+ "PctWAvail",
+ "PctVarAvail",
+ "PctEffectiveV"
+ ]
+ },
+ "PowerDuringCessationEnumType": {
+ "description": "Parameter is only sent, if the EV has to feed-in power or reactive power during fault-ride through (FRT) as defined by HVMomCess curve and LVMomCess curve.\r\n\r\n\r\n",
+ "javaType": "PowerDuringCessationEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Active", "Reactive"]
+ },
+ "DERCurvePointsType": {
+ "javaType": "DERCurvePoints",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "x": {
+ "description": "The data value of the X-axis (independent) variable, depending on the curve type.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "y": {
+ "description": "The data value of the Y-axis (dependent) variable, depending on the <<cmn_derunitenumtype>> of the curve. If _y_ is power factor, then a positive value means DER is absorbing reactive power (under-excited), a negative value when DER is injecting reactive power (over-excited).\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["x", "y"]
+ },
+ "DERCurveType": {
+ "javaType": "DERCurve",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "curveData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/DERCurvePointsType"
+ },
+ "minItems": 1,
+ "maxItems": 10
+ },
+ "hysteresis": {
+ "$ref": "#/definitions/HysteresisType"
+ },
+ "priority": {
+ "description": "Priority of curve (0=highest)\r\n\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "reactivePowerParams": {
+ "$ref": "#/definitions/ReactivePowerParamsType"
+ },
+ "voltageParams": {
+ "$ref": "#/definitions/VoltageParamsType"
+ },
+ "yUnit": {
+ "$ref": "#/definitions/DERUnitEnumType"
+ },
+ "responseTime": {
+ "description": "Open loop response time, the time to ramp up to 90% of the new target in response to the change in voltage, in seconds. A value of 0 is used to mean no limit. When not present, the device should follow its default behavior.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "startTime": {
+ "description": "Point in time when this curve will become activated. Only absent when _default_ is true.\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration in seconds that this curve will be active. Only absent when _default_ is true.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority", "yUnit", "curveData"]
+ },
+ "EnterServiceType": {
+ "javaType": "EnterService",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priority": {
+ "description": "Priority of setting (0=highest)\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "highVoltage": {
+ "description": "Enter service voltage high\r\n",
+ "type": "number"
+ },
+ "lowVoltage": {
+ "description": "Enter service voltage low\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "highFreq": {
+ "description": "Enter service frequency high\r\n\r\n",
+ "type": "number"
+ },
+ "lowFreq": {
+ "description": "Enter service frequency low\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "delay": {
+ "description": "Enter service delay\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "randomDelay": {
+ "description": "Enter service randomized delay\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "rampRate": {
+ "description": "Enter service ramp rate in seconds\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority", "highVoltage", "lowVoltage", "highFreq", "lowFreq"]
+ },
+ "FixedPFType": {
+ "javaType": "FixedPF",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priority": {
+ "description": "Priority of setting (0=highest)\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "displacement": {
+ "description": "Power factor, cos(phi), as value between 0..1.\r\n",
+ "type": "number"
+ },
+ "excitation": {
+ "description": "True when absorbing reactive power (under-excited), false when injecting reactive power (over-excited).\r\n",
+ "type": "boolean"
+ },
+ "startTime": {
+ "description": "Time when this setting becomes active\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration in seconds that this setting is active.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority", "displacement", "excitation"]
+ },
+ "FixedVarType": {
+ "javaType": "FixedVar",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priority": {
+ "description": "Priority of setting (0=highest)\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "setpoint": {
+ "description": "The value specifies a target var output interpreted as a signed percentage (-100 to 100). \r\n A negative value refers to charging, whereas a positive one refers to discharging.\r\n The value type is determined by the unit field.\r\n",
+ "type": "number"
+ },
+ "unit": {
+ "$ref": "#/definitions/DERUnitEnumType"
+ },
+ "startTime": {
+ "description": "Time when this setting becomes active.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration in seconds that this setting is active.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority", "setpoint", "unit"]
+ },
+ "FreqDroopType": {
+ "javaType": "FreqDroop",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priority": {
+ "description": "Priority of setting (0=highest)\r\n\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "overFreq": {
+ "description": "Over-frequency start of droop\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "underFreq": {
+ "description": "Under-frequency start of droop\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "overDroop": {
+ "description": "Over-frequency droop per unit, oFDroop\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "underDroop": {
+ "description": "Under-frequency droop per unit, uFDroop\r\n\r\n",
+ "type": "number"
+ },
+ "responseTime": {
+ "description": "Open loop response time in seconds\r\n\r\n",
+ "type": "number"
+ },
+ "startTime": {
+ "description": "Time when this setting becomes active\r\n\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration in seconds that this setting is active\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority", "overFreq", "underFreq", "overDroop", "underDroop", "responseTime"]
+ },
+ "GradientType": {
+ "javaType": "Gradient",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priority": {
+ "description": "Id of setting\r\n\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "gradient": {
+ "description": "Default ramp rate in seconds (0 if not applicable)\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "softGradient": {
+ "description": "Soft-start ramp rate in seconds (0 if not applicable)\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority", "gradient", "softGradient"]
+ },
+ "HysteresisType": {
+ "javaType": "Hysteresis",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hysteresisHigh": {
+ "description": "High value for return to normal operation after a grid event, in absolute value. This value adopts the same unit as defined by yUnit\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "hysteresisLow": {
+ "description": "Low value for return to normal operation after a grid event, in absolute value. This value adopts the same unit as defined by yUnit\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "hysteresisDelay": {
+ "description": "Delay in seconds, once grid parameter within HysteresisLow and HysteresisHigh, for the EV to return to normal operation after a grid event.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "hysteresisGradient": {
+ "description": "Set default rate of change (ramp rate %/s) for the EV to return to normal operation after a grid event\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "LimitMaxDischargeType": {
+ "javaType": "LimitMaxDischarge",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priority": {
+ "description": "Priority of setting (0=highest)\r\n\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "pctMaxDischargePower": {
+ "description": "Only for PowerMonitoring. +\r\n The value specifies a percentage (0 to 100) of the rated maximum discharge power of EV. \r\n The PowerMonitoring curve becomes active when power exceeds this percentage.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "powerMonitoringMustTrip": {
+ "$ref": "#/definitions/DERCurveType"
+ },
+ "startTime": {
+ "description": "Time when this setting becomes active\r\n\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "duration": {
+ "description": "Duration in seconds that this setting is active\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priority"]
+ },
+ "ReactivePowerParamsType": {
+ "javaType": "ReactivePowerParams",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "vRef": {
+ "description": "Only for VoltVar curve: The nominal ac voltage (rms) adjustment to the voltage curve points for Volt-Var curves (percentage).\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "autonomousVRefEnable": {
+ "description": "Only for VoltVar: Enable/disable autonomous VRef adjustment\r\n\r\n\r\n",
+ "type": "boolean"
+ },
+ "autonomousVRefTimeConstant": {
+ "description": "Only for VoltVar: Adjustment range for VRef time constant\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "VoltageParamsType": {
+ "javaType": "VoltageParams",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hv10MinMeanValue": {
+ "description": "EN 50549-1 chapter 4.9.3.4\r\n Voltage threshold for the 10 min time window mean value monitoring.\r\n The 10 min mean is recalculated up to every 3 s. \r\n If the present voltage is above this threshold for more than the time defined by _hv10MinMeanValue_, the EV must trip.\r\n This value is mandatory if _hv10MinMeanTripDelay_ is set.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "hv10MinMeanTripDelay": {
+ "description": "Time for which the voltage is allowed to stay above the 10 min mean value. \r\n After this time, the EV must trip.\r\n This value is mandatory if OverVoltageMeanValue10min is set.\r\n\r\n\r\n",
+ "type": "number"
+ },
+ "powerDuringCessation": {
+ "$ref": "#/definitions/PowerDuringCessationEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "isDefault": {
+ "description": "True if this is a default DER control\r\n\r\n",
+ "type": "boolean"
+ },
+ "controlId": {
+ "description": "Unique id of this control, e.g. UUID\r\n\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "controlType": {
+ "$ref": "#/definitions/DERControlEnumType"
+ },
+ "curve": {
+ "$ref": "#/definitions/DERCurveType"
+ },
+ "enterService": {
+ "$ref": "#/definitions/EnterServiceType"
+ },
+ "fixedPFAbsorb": {
+ "$ref": "#/definitions/FixedPFType"
+ },
+ "fixedPFInject": {
+ "$ref": "#/definitions/FixedPFType"
+ },
+ "fixedVar": {
+ "$ref": "#/definitions/FixedVarType"
+ },
+ "freqDroop": {
+ "$ref": "#/definitions/FreqDroopType"
+ },
+ "gradient": {
+ "$ref": "#/definitions/GradientType"
+ },
+ "limitMaxDischarge": {
+ "$ref": "#/definitions/LimitMaxDischargeType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["isDefault", "controlId", "controlType"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetDERControlResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DERControlStatusEnumType": {
+ "description": "Result of operation.\r\n\r\n",
+ "javaType": "DERControlStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotSupported", "NotFound"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/DERControlStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "supersededIds": {
+ "description": "List of controlIds that are superseded as a result of setting this control.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "string",
+ "maxLength": 36
+ },
+ "minItems": 1,
+ "maxItems": 24
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetDefaultTariffRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DayOfWeekEnumType": {
+ "javaType": "DayOfWeekEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"]
+ },
+ "EvseKindEnumType": {
+ "description": "Type of EVSE (AC, DC) this tariff applies to.\r\n",
+ "javaType": "EvseKindEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["AC", "DC"]
+ },
+ "MessageFormatEnumType": {
+ "description": "Format of the message.\r\n",
+ "javaType": "MessageFormatEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ASCII", "HTML", "URI", "UTF8", "QRCODE"]
+ },
+ "MessageContentType": {
+ "description": "Contains message details, for a message to be displayed on a Charging Station.\r\n\r\n",
+ "javaType": "MessageContent",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "format": {
+ "$ref": "#/definitions/MessageFormatEnumType"
+ },
+ "language": {
+ "description": "Message language identifier. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "content": {
+ "description": "*(2.1)* Required. Message contents. +\r\nMaximum length supported by Charging Station is given in OCPPCommCtrlr.FieldLength[\"MessageContentType.content\"].\r\n Maximum length defaults to 1024.\r\n\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["format", "content"]
+ },
+ "PriceType": {
+ "description": "Price with and without tax. At least one of _exclTax_, _inclTax_ must be present.\r\n",
+ "javaType": "Price",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "exclTax": {
+ "description": "Price/cost excluding tax. Can be absent if _inclTax_ is present.\r\n",
+ "type": "number"
+ },
+ "inclTax": {
+ "description": "Price/cost including tax. Can be absent if _exclTax_ is present.\r\n",
+ "type": "number"
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "TariffConditionsFixedType": {
+ "description": "These conditions describe if a FixedPrice applies at start of the transaction.\r\n\r\nWhen more than one restriction is set, they are to be treated as a logical AND. All need to be valid before this price is active.\r\n\r\nNOTE: _startTimeOfDay_ and _endTimeOfDay_ are in local time, because it is the time in the tariff as it is shown to the EV driver at the Charging Station.\r\nA Charging Station will convert this to the internal time zone that it uses (which is recommended to be UTC, see section Generic chapter 3.1) when performing cost calculation.\r\n\r\n",
+ "javaType": "TariffConditionsFixed",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startTimeOfDay": {
+ "description": "Start time of day in local time. +\r\nFormat as per RFC 3339: time-hour \":\" time-minute +\r\nMust be in 24h format with leading zeros. Hour/Minute separator: \":\"\r\nRegex: ([0-1][0-9]\\|2[0-3]):[0-5][0-9]\r\n",
+ "type": "string"
+ },
+ "endTimeOfDay": {
+ "description": "End time of day in local time. Same syntax as _startTimeOfDay_. +\r\n If end time < start time then the period wraps around to the next day. +\r\n To stop at end of the day use: 00:00.\r\n",
+ "type": "string"
+ },
+ "dayOfWeek": {
+ "description": "Day(s) of the week this is tariff applies.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/DayOfWeekEnumType"
+ },
+ "minItems": 1,
+ "maxItems": 7
+ },
+ "validFromDate": {
+ "description": "Start date in local time, for example: 2015-12-24.\r\nValid from this day (inclusive). +\r\nFormat as per RFC 3339: full-date + \r\n\r\nRegex: ([12][0-9]{3})-(0[1-9]\\|1[0-2])-(0[1-9]\\|[12][0-9]\\|3[01])\r\n",
+ "type": "string"
+ },
+ "validToDate": {
+ "description": "End date in local time, for example: 2015-12-27.\r\n Valid until this day (exclusive). Same syntax as _validFromDate_.\r\n",
+ "type": "string"
+ },
+ "evseKind": {
+ "$ref": "#/definitions/EvseKindEnumType"
+ },
+ "paymentBrand": {
+ "description": "For which payment brand this (adhoc) tariff applies. Can be used to add a surcharge for certain payment brands.\r\n Based on value of _additionalIdToken_ from _idToken.additionalInfo.type_ = \"PaymentBrand\".\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "paymentRecognition": {
+ "description": "Type of adhoc payment, e.g. CC, Debit.\r\n Based on value of _additionalIdToken_ from _idToken.additionalInfo.type_ = \"PaymentRecognition\".\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "TariffConditionsType": {
+ "description": "These conditions describe if and when a TariffEnergyType or TariffTimeType applies during a transaction.\r\n\r\nWhen more than one restriction is set, they are to be treated as a logical AND. All need to be valid before this price is active.\r\n\r\nFor reverse energy flow (discharging) negative values of energy, power and current are used.\r\n\r\nNOTE: _minXXX_ (where XXX = Kwh/A/Kw) must be read as \"closest to zero\", and _maxXXX_ as \"furthest from zero\". For example, a *charging* power range from 10 kW to 50 kWh is given by _minPower_ = 10000 and _maxPower_ = 50000, and a *discharging* power range from -10 kW to -50 kW is given by _minPower_ = -10 and _maxPower_ = -50.\r\n\r\nNOTE: _startTimeOfDay_ and _endTimeOfDay_ are in local time, because it is the time in the tariff as it is shown to the EV driver at the Charging Station.\r\nA Charging Station will convert this to the internal time zone that it uses (which is recommended to be UTC, see section Generic chapter 3.1) when performing cost calculation.\r\n\r\n",
+ "javaType": "TariffConditions",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "startTimeOfDay": {
+ "description": "Start time of day in local time. +\r\nFormat as per RFC 3339: time-hour \":\" time-minute +\r\nMust be in 24h format with leading zeros. Hour/Minute separator: \":\"\r\nRegex: ([0-1][0-9]\\|2[0-3]):[0-5][0-9]\r\n",
+ "type": "string"
+ },
+ "endTimeOfDay": {
+ "description": "End time of day in local time. Same syntax as _startTimeOfDay_. +\r\n If end time < start time then the period wraps around to the next day. +\r\n To stop at end of the day use: 00:00.\r\n",
+ "type": "string"
+ },
+ "dayOfWeek": {
+ "description": "Day(s) of the week this is tariff applies.\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/DayOfWeekEnumType"
+ },
+ "minItems": 1,
+ "maxItems": 7
+ },
+ "validFromDate": {
+ "description": "Start date in local time, for example: 2015-12-24.\r\nValid from this day (inclusive). +\r\nFormat as per RFC 3339: full-date + \r\n\r\nRegex: ([12][0-9]{3})-(0[1-9]\\|1[0-2])-(0[1-9]\\|[12][0-9]\\|3[01])\r\n",
+ "type": "string"
+ },
+ "validToDate": {
+ "description": "End date in local time, for example: 2015-12-27.\r\n Valid until this day (exclusive). Same syntax as _validFromDate_.\r\n",
+ "type": "string"
+ },
+ "evseKind": {
+ "$ref": "#/definitions/EvseKindEnumType"
+ },
+ "minEnergy": {
+ "description": "Minimum consumed energy in Wh, for example 20000 Wh.\r\n Valid from this amount of energy (inclusive) being used.\r\n",
+ "type": "number"
+ },
+ "maxEnergy": {
+ "description": "Maximum consumed energy in Wh, for example 50000 Wh.\r\n Valid until this amount of energy (exclusive) being used.\r\n",
+ "type": "number"
+ },
+ "minCurrent": {
+ "description": "Sum of the minimum current (in Amperes) over all phases, for example 5 A.\r\n When the EV is charging with more than, or equal to, the defined amount of current, this price is/becomes active. If the charging current is or becomes lower, this price is not or no longer valid and becomes inactive. +\r\n This is NOT about the minimum current over the entire transaction.\r\n",
+ "type": "number"
+ },
+ "maxCurrent": {
+ "description": "Sum of the maximum current (in Amperes) over all phases, for example 20 A.\r\n When the EV is charging with less than the defined amount of current, this price becomes/is active. If the charging current is or becomes higher, this price is not or no longer valid and becomes inactive.\r\n This is NOT about the maximum current over the entire transaction.\r\n",
+ "type": "number"
+ },
+ "minPower": {
+ "description": "Minimum power in W, for example 5000 W.\r\n When the EV is charging with more than, or equal to, the defined amount of power, this price is/becomes active.\r\n If the charging power is or becomes lower, this price is not or no longer valid and becomes inactive.\r\n This is NOT about the minimum power over the entire transaction.\r\n",
+ "type": "number"
+ },
+ "maxPower": {
+ "description": "Maximum power in W, for example 20000 W.\r\n When the EV is charging with less than the defined amount of power, this price becomes/is active.\r\n If the charging power is or becomes higher, this price is not or no longer valid and becomes inactive.\r\n This is NOT about the maximum power over the entire transaction.\r\n",
+ "type": "number"
+ },
+ "minTime": {
+ "description": "Minimum duration in seconds the transaction (charging & idle) MUST last (inclusive).\r\n When the duration of a transaction is longer than the defined value, this price is or becomes active.\r\n Before that moment, this price is not yet active.\r\n",
+ "type": "integer"
+ },
+ "maxTime": {
+ "description": "Maximum duration in seconds the transaction (charging & idle) MUST last (exclusive).\r\n When the duration of a transaction is shorter than the defined value, this price is or becomes active.\r\n After that moment, this price is no longer active.\r\n",
+ "type": "integer"
+ },
+ "minChargingTime": {
+ "description": "Minimum duration in seconds the charging MUST last (inclusive).\r\n When the duration of a charging is longer than the defined value, this price is or becomes active.\r\n Before that moment, this price is not yet active.\r\n",
+ "type": "integer"
+ },
+ "maxChargingTime": {
+ "description": "Maximum duration in seconds the charging MUST last (exclusive).\r\n When the duration of a charging is shorter than the defined value, this price is or becomes active.\r\n After that moment, this price is no longer active.\r\n",
+ "type": "integer"
+ },
+ "minIdleTime": {
+ "description": "Minimum duration in seconds the idle period (i.e. not charging) MUST last (inclusive).\r\n When the duration of the idle time is longer than the defined value, this price is or becomes active.\r\n Before that moment, this price is not yet active.\r\n",
+ "type": "integer"
+ },
+ "maxIdleTime": {
+ "description": "Maximum duration in seconds the idle period (i.e. not charging) MUST last (exclusive).\r\n When the duration of idle time is shorter than the defined value, this price is or becomes active.\r\n After that moment, this price is no longer active.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "TariffEnergyPriceType": {
+ "description": "Tariff with optional conditions for an energy price.\r\n",
+ "javaType": "TariffEnergyPrice",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priceKwh": {
+ "description": "Price per kWh (excl. tax) for this element.\r\n",
+ "type": "number"
+ },
+ "conditions": {
+ "$ref": "#/definitions/TariffConditionsType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priceKwh"]
+ },
+ "TariffEnergyType": {
+ "description": "Price elements and tax for energy\r\n",
+ "javaType": "TariffEnergy",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "prices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TariffEnergyPriceType"
+ },
+ "minItems": 1
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["prices"]
+ },
+ "TariffFixedPriceType": {
+ "description": "Tariff with optional conditions for a fixed price.\r\n",
+ "javaType": "TariffFixedPrice",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "conditions": {
+ "$ref": "#/definitions/TariffConditionsFixedType"
+ },
+ "priceFixed": {
+ "description": "Fixed price for this element e.g. a start fee.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priceFixed"]
+ },
+ "TariffFixedType": {
+ "javaType": "TariffFixed",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "prices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TariffFixedPriceType"
+ },
+ "minItems": 1
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["prices"]
+ },
+ "TariffTimePriceType": {
+ "description": "Tariff with optional conditions for a time duration price.\r\n",
+ "javaType": "TariffTimePrice",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "priceMinute": {
+ "description": "Price per minute (excl. tax) for this element.\r\n",
+ "type": "number"
+ },
+ "conditions": {
+ "$ref": "#/definitions/TariffConditionsType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["priceMinute"]
+ },
+ "TariffTimeType": {
+ "description": "Price elements and tax for time\r\n\r\n",
+ "javaType": "TariffTime",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "prices": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TariffTimePriceType"
+ },
+ "minItems": 1
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["prices"]
+ },
+ "TariffType": {
+ "description": "A tariff is described by fields with prices for:\r\nenergy,\r\ncharging time,\r\nidle time,\r\nfixed fee,\r\nreservation time,\r\nreservation fixed fee. +\r\nEach of these fields may have (optional) conditions that specify when a price is applicable. +\r\nThe _description_ contains a human-readable explanation of the tariff to be shown to the user. +\r\nThe other fields are parameters that define the tariff. These are used by the charging station to calculate the price.\r\n",
+ "javaType": "Tariff",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "tariffId": {
+ "description": "Unique id of tariff\r\n",
+ "type": "string",
+ "maxLength": 60
+ },
+ "description": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MessageContentType"
+ },
+ "minItems": 1,
+ "maxItems": 10
+ },
+ "currency": {
+ "description": "Currency code according to ISO 4217\r\n",
+ "type": "string",
+ "maxLength": 3
+ },
+ "energy": {
+ "$ref": "#/definitions/TariffEnergyType"
+ },
+ "validFrom": {
+ "description": "Time when this tariff becomes active. When absent, it is immediately active.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingTime": {
+ "$ref": "#/definitions/TariffTimeType"
+ },
+ "idleTime": {
+ "$ref": "#/definitions/TariffTimeType"
+ },
+ "fixedFee": {
+ "$ref": "#/definitions/TariffFixedType"
+ },
+ "reservationTime": {
+ "$ref": "#/definitions/TariffTimeType"
+ },
+ "reservationFixed": {
+ "$ref": "#/definitions/TariffFixedType"
+ },
+ "minCost": {
+ "$ref": "#/definitions/PriceType"
+ },
+ "maxCost": {
+ "$ref": "#/definitions/PriceType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["tariffId", "currency"]
+ },
+ "TaxRateType": {
+ "description": "Tax percentage\r\n",
+ "javaType": "TaxRate",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "description": "Type of this tax, e.g. \"Federal \", \"State\", for information on receipt.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "tax": {
+ "description": "Tax percentage\r\n",
+ "type": "number"
+ },
+ "stack": {
+ "description": "Stack level for this type of tax. Default value, when absent, is 0. +\r\n_stack_ = 0: tax on net price; +\r\n_stack_ = 1: tax added on top of _stack_ 0; +\r\n_stack_ = 2: tax added on top of _stack_ 1, etc. \r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["type", "tax"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evseId": {
+ "description": "EVSE that tariff applies to. When _evseId_ = 0, then tarriff applies to all EVSEs.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "tariff": {
+ "$ref": "#/definitions/TariffType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["evseId", "tariff"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetDefaultTariffResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "TariffSetStatusEnumType": {
+ "javaType": "TariffSetStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Rejected",
+ "TooManyElements",
+ "ConditionNotSupported",
+ "DuplicateTariffId"
+ ]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/TariffSetStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetDisplayMessageRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "MessageFormatEnumType": {
+ "description": "Format of the message.\r\n",
+ "javaType": "MessageFormatEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ASCII", "HTML", "URI", "UTF8", "QRCODE"]
+ },
+ "MessagePriorityEnumType": {
+ "description": "With what priority should this message be shown\r\n",
+ "javaType": "MessagePriorityEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["AlwaysFront", "InFront", "NormalCycle"]
+ },
+ "MessageStateEnumType": {
+ "description": "During what state should this message be shown. When omitted this message should be shown in any state of the Charging Station.\r\n",
+ "javaType": "MessageStateEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Charging", "Faulted", "Idle", "Unavailable", "Suspended", "Discharging"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "MessageContentType": {
+ "description": "Contains message details, for a message to be displayed on a Charging Station.\r\n\r\n",
+ "javaType": "MessageContent",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "format": {
+ "$ref": "#/definitions/MessageFormatEnumType"
+ },
+ "language": {
+ "description": "Message language identifier. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "content": {
+ "description": "*(2.1)* Required. Message contents. +\r\nMaximum length supported by Charging Station is given in OCPPCommCtrlr.FieldLength[\"MessageContentType.content\"].\r\n Maximum length defaults to 1024.\r\n\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["format", "content"]
+ },
+ "MessageInfoType": {
+ "description": "Contains message details, for a message to be displayed on a Charging Station.\r\n",
+ "javaType": "MessageInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "display": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "id": {
+ "description": "Unique id within an exchange context. It is defined within the OCPP context as a positive Integer value (greater or equal to zero).\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "priority": {
+ "$ref": "#/definitions/MessagePriorityEnumType"
+ },
+ "state": {
+ "$ref": "#/definitions/MessageStateEnumType"
+ },
+ "startDateTime": {
+ "description": "From what date-time should this message be shown. If omitted: directly.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "endDateTime": {
+ "description": "Until what date-time should this message be shown, after this date/time this message SHALL be removed.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "transactionId": {
+ "description": "During which transaction shall this message be shown.\r\nMessage SHALL be removed by the Charging Station after transaction has\r\nended.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "message": {
+ "$ref": "#/definitions/MessageContentType"
+ },
+ "messageExtra": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MessageContentType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id", "priority", "message"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "$ref": "#/definitions/MessageInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["message"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetDisplayMessageResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "DisplayMessageStatusEnumType": {
+ "description": "This indicates whether the Charging Station is able to display the message.\r\n",
+ "javaType": "DisplayMessageStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "NotSupportedMessageFormat",
+ "Rejected",
+ "NotSupportedPriority",
+ "NotSupportedState",
+ "UnknownTransaction",
+ "LanguageNotSupported"
+ ]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/DisplayMessageStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetMonitoringBaseRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "MonitoringBaseEnumType": {
+ "description": "Specify which monitoring base will be set\r\n",
+ "javaType": "MonitoringBaseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["All", "FactoryDefault", "HardWiredOnly"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "monitoringBase": {
+ "$ref": "#/definitions/MonitoringBaseEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["monitoringBase"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetMonitoringBaseResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericDeviceModelStatusEnumType": {
+ "description": "Indicates whether the Charging Station was able to accept the request.\r\n",
+ "javaType": "GenericDeviceModelStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotSupported", "EmptyResultSet"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericDeviceModelStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetMonitoringLevelRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "severity": {
+ "description": "The Charging Station SHALL only report events with a severity number lower than or equal to this severity.\r\nThe severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.\r\n\r\nThe severity levels have the following meaning: +\r\n*0-Danger* +\r\nIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately. +\r\n*1-Hardware Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required. +\r\n*2-System Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required. +\r\n*3-Critical* +\r\nIndicates a critical error. Action is required. +\r\n*4-Error* +\r\nIndicates a non-urgent error. Action is required. +\r\n*5-Alert* +\r\nIndicates an alert event. Default severity for any type of monitoring event. +\r\n*6-Warning* +\r\nIndicates a warning event. Action may be required. +\r\n*7-Notice* +\r\nIndicates an unusual event. No immediate action is required. +\r\n*8-Informational* +\r\nIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required. +\r\n*9-Debug* +\r\nIndicates information useful to developers for debugging, not useful during operations.\r\n\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["severity"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetMonitoringLevelResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericStatusEnumType": {
+ "description": "Indicates whether the Charging Station was able to accept the request.\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetNetworkProfileRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "APNAuthenticationEnumType": {
+ "description": "Authentication method.\r\n",
+ "javaType": "APNAuthenticationEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["PAP", "CHAP", "NONE", "AUTO"]
+ },
+ "OCPPInterfaceEnumType": {
+ "description": "Applicable Network Interface. Charging Station is allowed to use a different network interface to connect if the given one does not work.\r\n",
+ "javaType": "OCPPInterfaceEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Wired0",
+ "Wired1",
+ "Wired2",
+ "Wired3",
+ "Wireless0",
+ "Wireless1",
+ "Wireless2",
+ "Wireless3",
+ "Any"
+ ]
+ },
+ "OCPPTransportEnumType": {
+ "description": "Defines the transport protocol (e.g. SOAP or JSON). Note: SOAP is not supported in OCPP 2.x, but is supported by earlier versions of OCPP.\r\n",
+ "javaType": "OCPPTransportEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SOAP", "JSON"]
+ },
+ "OCPPVersionEnumType": {
+ "description": "*(2.1)* This field is ignored, since the OCPP version to use is determined during the websocket handshake. The field is only kept for backwards compatibility with the OCPP 2.0.1 JSON schema.\r\n",
+ "javaType": "OCPPVersionEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["OCPP12", "OCPP15", "OCPP16", "OCPP20", "OCPP201", "OCPP21"]
+ },
+ "VPNEnumType": {
+ "description": "Type of VPN\r\n",
+ "javaType": "VPNEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["IKEv2", "IPSec", "L2TP", "PPTP"]
+ },
+ "APNType": {
+ "description": "Collection of configuration data needed to make a data-connection over a cellular network.\r\n\r\nNOTE: When asking a GSM modem to dial in, it is possible to specify which mobile operator should be used. This can be done with the mobile country code (MCC) in combination with a mobile network code (MNC). Example: If your preferred network is Vodafone Netherlands, the MCC=204 and the MNC=04 which means the key PreferredNetwork = 20404 Some modems allows to specify a preferred network, which means, if this network is not available, a different network is used. If you specify UseOnlyPreferredNetwork and this network is not available, the modem will not dial in.\r\n",
+ "javaType": "APN",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "apn": {
+ "description": "The Access Point Name as an URL.\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "apnUserName": {
+ "description": "APN username.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "apnPassword": {
+ "description": "*(2.1)* APN Password.\r\n",
+ "type": "string",
+ "maxLength": 64
+ },
+ "simPin": {
+ "description": "SIM card pin code.\r\n",
+ "type": "integer"
+ },
+ "preferredNetwork": {
+ "description": "Preferred network, written as MCC and MNC concatenated. See note.\r\n",
+ "type": "string",
+ "maxLength": 6
+ },
+ "useOnlyPreferredNetwork": {
+ "description": "Default: false. Use only the preferred Network, do\r\nnot dial in when not available. See Note.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "apnAuthentication": {
+ "$ref": "#/definitions/APNAuthenticationEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["apn", "apnAuthentication"]
+ },
+ "NetworkConnectionProfileType": {
+ "description": "The NetworkConnectionProfile defines the functional and technical parameters of a communication link.\r\n",
+ "javaType": "NetworkConnectionProfile",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "apn": {
+ "$ref": "#/definitions/APNType"
+ },
+ "ocppVersion": {
+ "$ref": "#/definitions/OCPPVersionEnumType"
+ },
+ "ocppInterface": {
+ "$ref": "#/definitions/OCPPInterfaceEnumType"
+ },
+ "ocppTransport": {
+ "$ref": "#/definitions/OCPPTransportEnumType"
+ },
+ "messageTimeout": {
+ "description": "Duration in seconds before a message send by the Charging Station via this network connection times-out.\r\nThe best setting depends on the underlying network and response times of the CSMS.\r\nIf you are looking for a some guideline: use 30 seconds as a starting point.\r\n",
+ "type": "integer"
+ },
+ "ocppCsmsUrl": {
+ "description": "URL of the CSMS(s) that this Charging Station communicates with, without the Charging Station identity part. +\r\nThe SecurityCtrlr.Identity field is appended to _ocppCsmsUrl_ to provide the full websocket URL.\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "securityProfile": {
+ "description": "This field specifies the security profile used when connecting to the CSMS with this NetworkConnectionProfile.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "identity": {
+ "description": "*(2.1)* Charging Station identity to be used as the basic authentication username.\r\n",
+ "type": "string",
+ "maxLength": 48
+ },
+ "basicAuthPassword": {
+ "description": "*(2.1)* BasicAuthPassword to use for security profile 1 or 2.\r\n",
+ "type": "string",
+ "maxLength": 64
+ },
+ "vpn": {
+ "$ref": "#/definitions/VPNType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": [
+ "ocppInterface",
+ "ocppTransport",
+ "messageTimeout",
+ "ocppCsmsUrl",
+ "securityProfile"
+ ]
+ },
+ "VPNType": {
+ "description": "VPN Configuration settings\r\n",
+ "javaType": "VPN",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "server": {
+ "description": "VPN Server Address\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "user": {
+ "description": "VPN User\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "group": {
+ "description": "VPN group.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "password": {
+ "description": "*(2.1)* VPN Password.\r\n",
+ "type": "string",
+ "maxLength": 64
+ },
+ "key": {
+ "description": "VPN shared secret.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "$ref": "#/definitions/VPNEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["server", "user", "password", "key", "type"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "configurationSlot": {
+ "description": "Slot in which the configuration should be stored.\r\n",
+ "type": "integer"
+ },
+ "connectionData": {
+ "$ref": "#/definitions/NetworkConnectionProfileType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["configurationSlot", "connectionData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetNetworkProfileResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "SetNetworkProfileStatusEnumType": {
+ "description": "Result of operation.\r\n",
+ "javaType": "SetNetworkProfileStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "Failed"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/SetNetworkProfileStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetVariableMonitoringRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "MonitorEnumType": {
+ "description": "The type of this monitor, e.g. a threshold, delta or periodic monitor. \r\n\r\n",
+ "javaType": "MonitorEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "UpperThreshold",
+ "LowerThreshold",
+ "Delta",
+ "Periodic",
+ "PeriodicClockAligned",
+ "TargetDelta",
+ "TargetDeltaRelative"
+ ]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "PeriodicEventStreamParamsType": {
+ "javaType": "PeriodicEventStreamParams",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "interval": {
+ "description": "Time in seconds after which stream data is sent.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "values": {
+ "description": "Number of items to be sent together in stream.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "SetMonitoringDataType": {
+ "description": "Class to hold parameters of SetVariableMonitoring request.\r\n",
+ "javaType": "SetMonitoringData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "An id SHALL only be given to replace an existing monitor. The Charging Station handles the generation of id's for new monitors.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "periodicEventStream": {
+ "$ref": "#/definitions/PeriodicEventStreamParamsType"
+ },
+ "transaction": {
+ "description": "Monitor only active when a transaction is ongoing on a component relevant to this transaction. Default = false.\r\n\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "value": {
+ "description": "Value for threshold or delta monitoring.\r\nFor Periodic or PeriodicClockAligned this is the interval in seconds.\r\n\r\n",
+ "type": "number"
+ },
+ "type": {
+ "$ref": "#/definitions/MonitorEnumType"
+ },
+ "severity": {
+ "description": "The severity that will be assigned to an event that is triggered by this monitor. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.\r\n\r\nThe severity levels have the following meaning: +\r\n*0-Danger* +\r\nIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately. +\r\n*1-Hardware Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required. +\r\n*2-System Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required. +\r\n*3-Critical* +\r\nIndicates a critical error. Action is required. +\r\n*4-Error* +\r\nIndicates a non-urgent error. Action is required. +\r\n*5-Alert* +\r\nIndicates an alert event. Default severity for any type of monitoring event. +\r\n*6-Warning* +\r\nIndicates a warning event. Action may be required. +\r\n*7-Notice* +\r\nIndicates an unusual event. No immediate action is required. +\r\n*8-Informational* +\r\nIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required. +\r\n*9-Debug* +\r\nIndicates information useful to developers for debugging, not useful during operations.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["value", "type", "severity", "component", "variable"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "setMonitoringData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SetMonitoringDataType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["setMonitoringData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetVariableMonitoringResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "MonitorEnumType": {
+ "description": "The type of this monitor, e.g. a threshold, delta or periodic monitor. \r\n\r\n",
+ "javaType": "MonitorEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "UpperThreshold",
+ "LowerThreshold",
+ "Delta",
+ "Periodic",
+ "PeriodicClockAligned",
+ "TargetDelta",
+ "TargetDeltaRelative"
+ ]
+ },
+ "SetMonitoringStatusEnumType": {
+ "description": "Status is OK if a value could be returned. Otherwise this will indicate the reason why a value could not be returned.\r\n",
+ "javaType": "SetMonitoringStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "UnknownComponent",
+ "UnknownVariable",
+ "UnsupportedMonitorType",
+ "Rejected",
+ "Duplicate"
+ ]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "SetMonitoringResultType": {
+ "description": "Class to hold result of SetVariableMonitoring request.\r\n",
+ "javaType": "SetMonitoringResult",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Id given to the VariableMonitor by the Charging Station. The Id is only returned when status is accepted. Installed VariableMonitors should have unique id's but the id's of removed Installed monitors should have unique id's but the id's of removed monitors MAY be reused.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "status": {
+ "$ref": "#/definitions/SetMonitoringStatusEnumType"
+ },
+ "type": {
+ "$ref": "#/definitions/MonitorEnumType"
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "severity": {
+ "description": "The severity that will be assigned to an event that is triggered by this monitor. The severity range is 0-9, with 0 as the highest and 9 as the lowest severity level.\r\n\r\nThe severity levels have the following meaning: +\r\n*0-Danger* +\r\nIndicates lives are potentially in danger. Urgent attention is needed and action should be taken immediately. +\r\n*1-Hardware Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to Hardware issues. Action is required. +\r\n*2-System Failure* +\r\nIndicates that the Charging Station is unable to continue regular operations due to software or minor hardware issues. Action is required. +\r\n*3-Critical* +\r\nIndicates a critical error. Action is required. +\r\n*4-Error* +\r\nIndicates a non-urgent error. Action is required. +\r\n*5-Alert* +\r\nIndicates an alert event. Default severity for any type of monitoring event. +\r\n*6-Warning* +\r\nIndicates a warning event. Action may be required. +\r\n*7-Notice* +\r\nIndicates an unusual event. No immediate action is required. +\r\n*8-Informational* +\r\nIndicates a regular operational event. May be used for reporting, measuring throughput, etc. No action is required. +\r\n*9-Debug* +\r\nIndicates information useful to developers for debugging, not useful during operations.\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status", "type", "severity", "component", "variable"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "setMonitoringResult": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SetMonitoringResultType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["setMonitoringResult"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetVariablesRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "AttributeEnumType": {
+ "description": "Type of attribute: Actual, Target, MinSet, MaxSet. Default is Actual when omitted.\r\n",
+ "javaType": "AttributeEnum",
+ "type": "string",
+ "default": "Actual",
+ "additionalProperties": false,
+ "enum": ["Actual", "Target", "MinSet", "MaxSet"]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "SetVariableDataType": {
+ "javaType": "SetVariableData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "attributeType": {
+ "$ref": "#/definitions/AttributeEnumType"
+ },
+ "attributeValue": {
+ "description": "Value to be assigned to attribute of variable.\r\nThis value is allowed to be an empty string (\"\").\r\n\r\nThe Configuration Variable <<configkey-configuration-value-size,ConfigurationValueSize>> can be used to limit SetVariableData.attributeValue and VariableCharacteristics.valuesList. The max size of these values will always remain equal. \r\n",
+ "type": "string",
+ "maxLength": 2500
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["attributeValue", "component", "variable"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "setVariableData": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SetVariableDataType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["setVariableData"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SetVariablesResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "AttributeEnumType": {
+ "description": "Type of attribute: Actual, Target, MinSet, MaxSet. Default is Actual when omitted.\r\n",
+ "javaType": "AttributeEnum",
+ "type": "string",
+ "default": "Actual",
+ "additionalProperties": false,
+ "enum": ["Actual", "Target", "MinSet", "MaxSet"]
+ },
+ "SetVariableStatusEnumType": {
+ "description": "Result status of setting the variable.\r\n",
+ "javaType": "SetVariableStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Rejected",
+ "UnknownComponent",
+ "UnknownVariable",
+ "NotSupportedAttributeType",
+ "RebootRequired"
+ ]
+ },
+ "ComponentType": {
+ "description": "A physical or logical component\r\n",
+ "javaType": "Component",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "name": {
+ "description": "Name of the component. Name should be taken from the list of standardized component names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the component exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "SetVariableResultType": {
+ "javaType": "SetVariableResult",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "attributeType": {
+ "$ref": "#/definitions/AttributeEnumType"
+ },
+ "attributeStatus": {
+ "$ref": "#/definitions/SetVariableStatusEnumType"
+ },
+ "attributeStatusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "component": {
+ "$ref": "#/definitions/ComponentType"
+ },
+ "variable": {
+ "$ref": "#/definitions/VariableType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["attributeStatus", "component", "variable"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "VariableType": {
+ "description": "Reference key to a component-variable.\r\n",
+ "javaType": "Variable",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of the variable. Name should be taken from the list of standardized variable names whenever possible. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "instance": {
+ "description": "Name of instance in case the variable exists as multiple instances. Case Insensitive. strongly advised to use Camel Case.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "setVariableResult": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SetVariableResultType"
+ },
+ "minItems": 1
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["setVariableResult"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SignCertificateRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CertificateSigningUseEnumType": {
+ "description": "Indicates the type of certificate that is to be signed. When omitted the certificate is to be used for both the 15118 connection (if implemented) and the Charging Station to CSMS connection.\r\n\r\n",
+ "javaType": "CertificateSigningUseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ChargingStationCertificate", "V2GCertificate", "V2G20Certificate"]
+ },
+ "HashAlgorithmEnumType": {
+ "description": "Used algorithms for the hashes provided.\r\n",
+ "javaType": "HashAlgorithmEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["SHA256", "SHA384", "SHA512"]
+ },
+ "CertificateHashDataType": {
+ "javaType": "CertificateHashData",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "hashAlgorithm": {
+ "$ref": "#/definitions/HashAlgorithmEnumType"
+ },
+ "issuerNameHash": {
+ "description": "The hash of the issuer\u2019s distinguished\r\nname (DN), that must be calculated over the DER\r\nencoding of the issuer\u2019s name field in the certificate\r\nbeing checked.\r\n\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "issuerKeyHash": {
+ "description": "The hash of the DER encoded public key:\r\nthe value (excluding tag and length) of the subject\r\npublic key field in the issuer\u2019s certificate.\r\n",
+ "type": "string",
+ "maxLength": 128
+ },
+ "serialNumber": {
+ "description": "The string representation of the\r\nhexadecimal value of the serial number without the\r\nprefix \"0x\" and without leading zeroes.\r\n",
+ "type": "string",
+ "maxLength": 40
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["hashAlgorithm", "issuerNameHash", "issuerKeyHash", "serialNumber"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "csr": {
+ "description": "The Charging Station SHALL send the public key in form of a Certificate Signing Request (CSR) as described in RFC 2986 [22] and then PEM encoded, using the <<signcertificaterequest,SignCertificateRequest>> message.\r\n",
+ "type": "string",
+ "maxLength": 5500
+ },
+ "certificateType": {
+ "$ref": "#/definitions/CertificateSigningUseEnumType"
+ },
+ "hashRootCertificate": {
+ "$ref": "#/definitions/CertificateHashDataType"
+ },
+ "requestId": {
+ "description": "*(2.1)* RequestId to match this message with the CertificateSignedRequest.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["csr"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:SignCertificateResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericStatusEnumType": {
+ "description": "Specifies whether the CSMS can process the request.\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:StatusNotificationRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ConnectorStatusEnumType": {
+ "description": "This contains the current status of the Connector.\r\n",
+ "javaType": "ConnectorStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Available", "Occupied", "Reserved", "Unavailable", "Faulted"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "timestamp": {
+ "description": "The time for which the status is reported.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "connectorStatus": {
+ "$ref": "#/definitions/ConnectorStatusEnumType"
+ },
+ "evseId": {
+ "description": "The id of the EVSE to which the connector belongs for which the the status is reported.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "The id of the connector within the EVSE for which the status is reported.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["timestamp", "connectorStatus", "evseId", "connectorId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:StatusNotificationResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:TransactionEventRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingStateEnumType": {
+ "description": "Current charging state, is required when state\r\nhas changed. Omitted when there is no communication between EVSE and EV, because no cable is plugged in.\r\n",
+ "javaType": "ChargingStateEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["EVConnected", "Charging", "SuspendedEV", "SuspendedEVSE", "Idle"]
+ },
+ "CostDimensionEnumType": {
+ "description": "Type of cost dimension: energy, power, time, etc.\r\n\r\n",
+ "javaType": "CostDimensionEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Energy",
+ "MaxCurrent",
+ "MinCurrent",
+ "MaxPower",
+ "MinPower",
+ "IdleTIme",
+ "ChargingTime"
+ ]
+ },
+ "LocationEnumType": {
+ "description": "Indicates where the measured value has been sampled. Default = \"Outlet\"\r\n\r\n",
+ "javaType": "LocationEnum",
+ "type": "string",
+ "default": "Outlet",
+ "additionalProperties": false,
+ "enum": ["Body", "Cable", "EV", "Inlet", "Outlet", "Upstream"]
+ },
+ "MeasurandEnumType": {
+ "description": "Type of measurement. Default = \"Energy.Active.Import.Register\"\r\n",
+ "javaType": "MeasurandEnum",
+ "type": "string",
+ "default": "Energy.Active.Import.Register",
+ "additionalProperties": false,
+ "enum": [
+ "Current.Export",
+ "Current.Export.Offered",
+ "Current.Export.Minimum",
+ "Current.Import",
+ "Current.Import.Offered",
+ "Current.Import.Minimum",
+ "Current.Offered",
+ "Display.PresentSOC",
+ "Display.MinimumSOC",
+ "Display.TargetSOC",
+ "Display.MaximumSOC",
+ "Display.RemainingTimeToMinimumSOC",
+ "Display.RemainingTimeToTargetSOC",
+ "Display.RemainingTimeToMaximumSOC",
+ "Display.ChargingComplete",
+ "Display.BatteryEnergyCapacity",
+ "Display.InletHot",
+ "Energy.Active.Export.Interval",
+ "Energy.Active.Export.Register",
+ "Energy.Active.Import.Interval",
+ "Energy.Active.Import.Register",
+ "Energy.Active.Import.CableLoss",
+ "Energy.Active.Import.LocalGeneration.Register",
+ "Energy.Active.Net",
+ "Energy.Active.Setpoint.Interval",
+ "Energy.Apparent.Export",
+ "Energy.Apparent.Import",
+ "Energy.Apparent.Net",
+ "Energy.Reactive.Export.Interval",
+ "Energy.Reactive.Export.Register",
+ "Energy.Reactive.Import.Interval",
+ "Energy.Reactive.Import.Register",
+ "Energy.Reactive.Net",
+ "EnergyRequest.Target",
+ "EnergyRequest.Minimum",
+ "EnergyRequest.Maximum",
+ "EnergyRequest.Minimum.V2X",
+ "EnergyRequest.Maximum.V2X",
+ "EnergyRequest.Bulk",
+ "Frequency",
+ "Power.Active.Export",
+ "Power.Active.Import",
+ "Power.Active.Setpoint",
+ "Power.Active.Residual",
+ "Power.Export.Minimum",
+ "Power.Export.Offered",
+ "Power.Factor",
+ "Power.Import.Offered",
+ "Power.Import.Minimum",
+ "Power.Offered",
+ "Power.Reactive.Export",
+ "Power.Reactive.Import",
+ "SoC",
+ "Voltage",
+ "Voltage.Minimum",
+ "Voltage.Maximum"
+ ]
+ },
+ "OperationModeEnumType": {
+ "description": "*(2.1)* The _operationMode_ that is currently in effect for the transaction.\r\n",
+ "javaType": "OperationModeEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Idle",
+ "ChargingOnly",
+ "CentralSetpoint",
+ "ExternalSetpoint",
+ "ExternalLimits",
+ "CentralFrequency",
+ "LocalFrequency",
+ "LocalLoadBalancing"
+ ]
+ },
+ "PhaseEnumType": {
+ "description": "Indicates how the measured value is to be interpreted. For instance between L1 and neutral (L1-N) Please note that not all values of phase are applicable to all Measurands. When phase is absent, the measured value is interpreted as an overall value.\r\n",
+ "javaType": "PhaseEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["L1", "L2", "L3", "N", "L1-N", "L2-N", "L3-N", "L1-L2", "L2-L3", "L3-L1"]
+ },
+ "PreconditioningStatusEnumType": {
+ "description": "*(2.1)* The current preconditioning status of the BMS in the EV. Default value is Unknown.\r\n",
+ "javaType": "PreconditioningStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Unknown", "Ready", "NotReady", "Preconditioning"]
+ },
+ "ReadingContextEnumType": {
+ "description": "Type of detail value: start, end or sample. Default = \"Sample.Periodic\"\r\n",
+ "javaType": "ReadingContextEnum",
+ "type": "string",
+ "default": "Sample.Periodic",
+ "additionalProperties": false,
+ "enum": [
+ "Interruption.Begin",
+ "Interruption.End",
+ "Other",
+ "Sample.Clock",
+ "Sample.Periodic",
+ "Transaction.Begin",
+ "Transaction.End",
+ "Trigger"
+ ]
+ },
+ "ReasonEnumType": {
+ "description": "The _stoppedReason_ is the reason/event that 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. +\r\nMAY only be omitted when _stoppedReason_ is \"Local\"\r\n\r\n\r\n",
+ "javaType": "ReasonEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "DeAuthorized",
+ "EmergencyStop",
+ "EnergyLimitReached",
+ "EVDisconnected",
+ "GroundFault",
+ "ImmediateReset",
+ "MasterPass",
+ "Local",
+ "LocalOutOfCredit",
+ "Other",
+ "OvercurrentFault",
+ "PowerLoss",
+ "PowerQuality",
+ "Reboot",
+ "Remote",
+ "SOCLimitReached",
+ "StoppedByEV",
+ "TimeLimitReached",
+ "Timeout",
+ "ReqEnergyTransferRejected"
+ ]
+ },
+ "TariffCostEnumType": {
+ "description": "Type of cost: normal or the minimum or maximum cost.\r\n",
+ "javaType": "TariffCostEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["NormalCost", "MinCost", "MaxCost"]
+ },
+ "TransactionEventEnumType": {
+ "description": "This contains the type of this event.\r\nThe first TransactionEvent of a transaction SHALL contain: \"Started\" The last TransactionEvent of a transaction SHALL contain: \"Ended\" All others SHALL contain: \"Updated\"\r\n",
+ "javaType": "TransactionEventEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Ended", "Started", "Updated"]
+ },
+ "TriggerReasonEnumType": {
+ "description": "Reason the Charging Station sends this message to the CSMS\r\n",
+ "javaType": "TriggerReasonEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "AbnormalCondition",
+ "Authorized",
+ "CablePluggedIn",
+ "ChargingRateChanged",
+ "ChargingStateChanged",
+ "CostLimitReached",
+ "Deauthorized",
+ "EnergyLimitReached",
+ "EVCommunicationLost",
+ "EVConnectTimeout",
+ "EVDeparted",
+ "EVDetected",
+ "LimitSet",
+ "MeterValueClock",
+ "MeterValuePeriodic",
+ "OperationModeChanged",
+ "RemoteStart",
+ "RemoteStop",
+ "ResetCommand",
+ "RunningCost",
+ "SignedDataReceived",
+ "SoCLimitReached",
+ "StopAuthorized",
+ "TariffChanged",
+ "TariffNotAccepted",
+ "TimeLimitReached",
+ "Trigger",
+ "TxResumed",
+ "UnlockCommand"
+ ]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalIdToken": {
+ "description": "*(2.1)* This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "_additionalInfo_ can be used to send extra information to CSMS in addition to the regular authorization with _IdToken_. _AdditionalInfo_ contains one or more custom _types_, which need to be agreed upon by all parties involved. When the _type_ is not supported, the CSMS/Charging Station MAY ignore the _additionalInfo_.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "ChargingPeriodType": {
+ "description": "A ChargingPeriodType consists of a start time, and a list of possible values that influence this period, for example: amount of energy charged this period, maximum current during this period etc.\r\n\r\n",
+ "javaType": "ChargingPeriod",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "dimensions": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/CostDimensionType"
+ },
+ "minItems": 1
+ },
+ "tariffId": {
+ "description": "Unique identifier of the Tariff that was used to calculate cost. If not provided, then cost was calculated by some other means.\r\n\r\n",
+ "type": "string",
+ "maxLength": 60
+ },
+ "startPeriod": {
+ "description": "Start timestamp of charging period. A period ends when the next period starts. The last period ends when the session ends.\r\n\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["startPeriod"]
+ },
+ "CostDetailsType": {
+ "description": "CostDetailsType contains the cost as calculated by Charging Station based on provided TariffType.\r\n\r\nNOTE: Reservation is not shown as a _chargingPeriod_, because it took place outside of the transaction.\r\n\r\n",
+ "javaType": "CostDetails",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "chargingPeriods": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/ChargingPeriodType"
+ },
+ "minItems": 1
+ },
+ "totalCost": {
+ "$ref": "#/definitions/TotalCostType"
+ },
+ "totalUsage": {
+ "$ref": "#/definitions/TotalUsageType"
+ },
+ "failureToCalculate": {
+ "description": "If set to true, then Charging Station has failed to calculate the cost.\r\n\r\n",
+ "type": "boolean"
+ },
+ "failureReason": {
+ "description": "Optional human-readable reason text in case of failure to calculate.\r\n\r\n",
+ "type": "string",
+ "maxLength": 500
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["totalCost", "totalUsage"]
+ },
+ "CostDimensionType": {
+ "description": "Volume consumed of cost dimension.\r\n",
+ "javaType": "CostDimension",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "$ref": "#/definitions/CostDimensionEnumType"
+ },
+ "volume": {
+ "description": "Volume of the dimension consumed, measured according to the dimension type.\r\n\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["type", "volume"]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "*(2.1)* IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "*(2.1)* Enumeration of possible idToken types. Values defined in Appendix as IdTokenEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "MeterValueType": {
+ "description": "Collection of one or more sampled values in MeterValuesRequest and TransactionEvent. All sampled values in a MeterValue are sampled at the same point in time.\r\n",
+ "javaType": "MeterValue",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "sampledValue": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/SampledValueType"
+ },
+ "minItems": 1
+ },
+ "timestamp": {
+ "description": "Timestamp for measured value(s).\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["timestamp", "sampledValue"]
+ },
+ "PriceType": {
+ "description": "Price with and without tax. At least one of _exclTax_, _inclTax_ must be present.\r\n",
+ "javaType": "Price",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "exclTax": {
+ "description": "Price/cost excluding tax. Can be absent if _inclTax_ is present.\r\n",
+ "type": "number"
+ },
+ "inclTax": {
+ "description": "Price/cost including tax. Can be absent if _exclTax_ is present.\r\n",
+ "type": "number"
+ },
+ "taxRates": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/TaxRateType"
+ },
+ "minItems": 1,
+ "maxItems": 5
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "SampledValueType": {
+ "description": "Single sampled value in MeterValues. Each value can be accompanied by optional fields.\r\n\r\nTo save on mobile data usage, default values of all of the optional fields are such that. The value without any additional fields will be interpreted, as a register reading of active import energy in Wh (Watt-hour) units.\r\n",
+ "javaType": "SampledValue",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "value": {
+ "description": "Indicates the measured value.\r\n\r\n",
+ "type": "number"
+ },
+ "measurand": {
+ "$ref": "#/definitions/MeasurandEnumType"
+ },
+ "context": {
+ "$ref": "#/definitions/ReadingContextEnumType"
+ },
+ "phase": {
+ "$ref": "#/definitions/PhaseEnumType"
+ },
+ "location": {
+ "$ref": "#/definitions/LocationEnumType"
+ },
+ "signedMeterValue": {
+ "$ref": "#/definitions/SignedMeterValueType"
+ },
+ "unitOfMeasure": {
+ "$ref": "#/definitions/UnitOfMeasureType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["value"]
+ },
+ "SignedMeterValueType": {
+ "description": "Represent a signed version of the meter value.\r\n",
+ "javaType": "SignedMeterValue",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "signedMeterData": {
+ "description": "Base64 encoded, contains the signed data from the meter in the format specified in _encodingMethod_, which might contain more then just the meter value. It can contain information like timestamps, reference to a customer etc.\r\n",
+ "type": "string",
+ "maxLength": 32768
+ },
+ "signingMethod": {
+ "description": "*(2.1)* Method used to create the digital signature. Optional, if already included in _signedMeterData_. Standard values for this are defined in Appendix as SigningMethodEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "encodingMethod": {
+ "description": "Format used by the energy meter to encode the meter data. For example: OCMF or EDL.\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "publicKey": {
+ "description": "*(2.1)* Base64 encoded, sending depends on configuration variable _PublicKeyWithSignedMeterValue_.\r\n",
+ "type": "string",
+ "maxLength": 2500
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["signedMeterData", "encodingMethod"]
+ },
+ "TaxRateType": {
+ "description": "Tax percentage\r\n",
+ "javaType": "TaxRate",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "description": "Type of this tax, e.g. \"Federal \", \"State\", for information on receipt.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "tax": {
+ "description": "Tax percentage\r\n",
+ "type": "number"
+ },
+ "stack": {
+ "description": "Stack level for this type of tax. Default value, when absent, is 0. +\r\n_stack_ = 0: tax on net price; +\r\n_stack_ = 1: tax added on top of _stack_ 0; +\r\n_stack_ = 2: tax added on top of _stack_ 1, etc. \r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["type", "tax"]
+ },
+ "TotalCostType": {
+ "description": "This contains the cost calculated during a transaction. It is used both for running cost and final cost of the transaction.\r\n",
+ "javaType": "TotalCost",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "currency": {
+ "description": "Currency of the costs in ISO 4217 Code.\r\n\r\n",
+ "type": "string",
+ "maxLength": 3
+ },
+ "typeOfCost": {
+ "$ref": "#/definitions/TariffCostEnumType"
+ },
+ "fixed": {
+ "$ref": "#/definitions/PriceType"
+ },
+ "energy": {
+ "$ref": "#/definitions/PriceType"
+ },
+ "chargingTime": {
+ "$ref": "#/definitions/PriceType"
+ },
+ "idleTime": {
+ "$ref": "#/definitions/PriceType"
+ },
+ "reservationTime": {
+ "$ref": "#/definitions/PriceType"
+ },
+ "reservationFixed": {
+ "$ref": "#/definitions/PriceType"
+ },
+ "total": {
+ "$ref": "#/definitions/TotalPriceType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["currency", "typeOfCost", "total"]
+ },
+ "TotalPriceType": {
+ "description": "Total cost with and without tax. Contains the total of energy, charging time, idle time, fixed and reservation costs including and/or excluding tax.\r\n",
+ "javaType": "TotalPrice",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "exclTax": {
+ "description": "Price/cost excluding tax. Can be absent if _inclTax_ is present.\r\n",
+ "type": "number"
+ },
+ "inclTax": {
+ "description": "Price/cost including tax. Can be absent if _exclTax_ is present.\r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "TotalUsageType": {
+ "description": "This contains the calculated usage of energy, charging time and idle time during a transaction.\r\n",
+ "javaType": "TotalUsage",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "energy": {
+ "type": "number"
+ },
+ "chargingTime": {
+ "description": "Total duration of the charging session (including the duration of charging and not charging), in seconds.\r\n\r\n\r\n",
+ "type": "integer"
+ },
+ "idleTime": {
+ "description": "Total duration of the charging session where the EV was not charging (no energy was transferred between EVSE and EV), in seconds.\r\n\r\n\r\n",
+ "type": "integer"
+ },
+ "reservationTime": {
+ "description": "Total time of reservation in seconds.\r\n",
+ "type": "integer"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["energy", "chargingTime", "idleTime"]
+ },
+ "TransactionLimitType": {
+ "description": "Cost, energy, time or SoC limit for a transaction.\r\n",
+ "javaType": "TransactionLimit",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "maxCost": {
+ "description": "Maximum allowed cost of transaction in currency of tariff.\r\n",
+ "type": "number"
+ },
+ "maxEnergy": {
+ "description": "Maximum allowed energy in Wh to charge in transaction.\r\n",
+ "type": "number"
+ },
+ "maxTime": {
+ "description": "Maximum duration of transaction in seconds from start to end.\r\n",
+ "type": "integer"
+ },
+ "maxSoC": {
+ "description": "Maximum State of Charge of EV in percentage.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "TransactionType": {
+ "javaType": "Transaction",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "transactionId": {
+ "description": "This contains the Id of the transaction.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "chargingState": {
+ "$ref": "#/definitions/ChargingStateEnumType"
+ },
+ "timeSpentCharging": {
+ "description": "Contains the total time that energy flowed from EVSE to EV during the transaction (in seconds). Note that timeSpentCharging is smaller or equal to the duration of the transaction.\r\n",
+ "type": "integer"
+ },
+ "stoppedReason": {
+ "$ref": "#/definitions/ReasonEnumType"
+ },
+ "remoteStartId": {
+ "description": "The ID given to remote start request (<<requeststarttransactionrequest, RequestStartTransactionRequest>>. This enables to CSMS to match the started transaction to the given start request.\r\n",
+ "type": "integer"
+ },
+ "operationMode": {
+ "$ref": "#/definitions/OperationModeEnumType"
+ },
+ "tariffId": {
+ "description": "*(2.1)* Id of tariff in use for transaction\r\n",
+ "type": "string",
+ "maxLength": 60
+ },
+ "transactionLimit": {
+ "$ref": "#/definitions/TransactionLimitType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["transactionId"]
+ },
+ "UnitOfMeasureType": {
+ "description": "Represents a UnitOfMeasure with a multiplier\r\n",
+ "javaType": "UnitOfMeasure",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "unit": {
+ "description": "Unit of the value. Default = \"Wh\" if the (default) measurand is an \"Energy\" type.\r\nThis field SHALL use a value from the list Standardized Units of Measurements in Part 2 Appendices. \r\nIf an applicable unit is available in that list, otherwise a \"custom\" unit might be used.\r\n",
+ "type": "string",
+ "default": "Wh",
+ "maxLength": 20
+ },
+ "multiplier": {
+ "description": "Multiplier, this value represents the exponent to base 10. I.e. multiplier 3 means 10 raised to the 3rd power. Default is 0. +\r\nThe _multiplier_ only multiplies the value of the measurand. It does not specify a conversion between units, for example, kW and W.\r\n",
+ "type": "integer",
+ "default": 0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "costDetails": {
+ "$ref": "#/definitions/CostDetailsType"
+ },
+ "eventType": {
+ "$ref": "#/definitions/TransactionEventEnumType"
+ },
+ "meterValue": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MeterValueType"
+ },
+ "minItems": 1
+ },
+ "timestamp": {
+ "description": "The date and time at which this transaction event occurred.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "triggerReason": {
+ "$ref": "#/definitions/TriggerReasonEnumType"
+ },
+ "seqNo": {
+ "description": "Incremental sequence number, helps with determining if all messages of a transaction have been received.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "offline": {
+ "description": "Indication that this transaction event happened when the Charging Station was offline. Default = false, meaning: the event occurred when the Charging Station was online.\r\n",
+ "type": "boolean",
+ "default": false
+ },
+ "numberOfPhasesUsed": {
+ "description": "If the Charging Station is able to report the number of phases used, then it SHALL provide it.\r\nWhen omitted the CSMS may be able to determine the number of phases used as follows: +\r\n1: The numberPhases in the currently used ChargingSchedule. +\r\n2: The number of phases provided via device management.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 3.0
+ },
+ "cableMaxCurrent": {
+ "description": "The maximum current of the connected cable in Ampere (A).\r\n",
+ "type": "integer"
+ },
+ "reservationId": {
+ "description": "This contains the Id of the reservation that terminates as a result of this transaction.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "preconditioningStatus": {
+ "$ref": "#/definitions/PreconditioningStatusEnumType"
+ },
+ "evseSleep": {
+ "description": "*(2.1)* True when EVSE electronics are in sleep mode for this transaction. Default value (when absent) is false.\r\n\r\n",
+ "type": "boolean"
+ },
+ "transactionInfo": {
+ "$ref": "#/definitions/TransactionType"
+ },
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "idToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["eventType", "timestamp", "triggerReason", "seqNo", "transactionInfo"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:TransactionEventResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "AuthorizationStatusEnumType": {
+ "description": "Current status of the ID Token.\r\n",
+ "javaType": "AuthorizationStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Blocked",
+ "ConcurrentTx",
+ "Expired",
+ "Invalid",
+ "NoCredit",
+ "NotAllowedTypeEVSE",
+ "NotAtThisLocation",
+ "NotAtThisTime",
+ "Unknown"
+ ]
+ },
+ "MessageFormatEnumType": {
+ "description": "Format of the message.\r\n",
+ "javaType": "MessageFormatEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["ASCII", "HTML", "URI", "UTF8", "QRCODE"]
+ },
+ "AdditionalInfoType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "AdditionalInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalIdToken": {
+ "description": "*(2.1)* This field specifies the additional IdToken.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "_additionalInfo_ can be used to send extra information to CSMS in addition to the regular authorization with _IdToken_. _AdditionalInfo_ contains one or more custom _types_, which need to be agreed upon by all parties involved. When the _type_ is not supported, the CSMS/Charging Station MAY ignore the _additionalInfo_.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["additionalIdToken", "type"]
+ },
+ "IdTokenInfoType": {
+ "description": "Contains status information about an identifier.\r\nIt is advised to not stop charging for a token that expires during charging, as ExpiryDate is only used for caching purposes. If ExpiryDate is not given, the status has no end date.\r\n",
+ "javaType": "IdTokenInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/AuthorizationStatusEnumType"
+ },
+ "cacheExpiryDateTime": {
+ "description": "Date and Time after which the token must be considered invalid.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "chargingPriority": {
+ "description": "Priority from a business point of view. Default priority is 0, The range is from -9 to 9. Higher values indicate a higher priority. The chargingPriority in <<transactioneventresponse,TransactionEventResponse>> overrules this one. \r\n",
+ "type": "integer"
+ },
+ "groupIdToken": {
+ "$ref": "#/definitions/IdTokenType"
+ },
+ "language1": {
+ "description": "Preferred user interface language of identifier user. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "language2": {
+ "description": "Second preferred user interface language of identifier user. Don\u2019t use when language1 is omitted, has to be different from language1. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "evseId": {
+ "description": "Only used when the IdToken is only valid for one or more specific EVSEs, not for the entire Charging Station.\r\n\r\n",
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "minItems": 1
+ },
+ "personalMessage": {
+ "$ref": "#/definitions/MessageContentType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+ },
+ "IdTokenType": {
+ "description": "Contains a case insensitive identifier to use for the authorization and the type of authorization to support multiple forms of identifiers.\r\n",
+ "javaType": "IdToken",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "additionalInfo": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/AdditionalInfoType"
+ },
+ "minItems": 1
+ },
+ "idToken": {
+ "description": "*(2.1)* IdToken is case insensitive. Might hold the hidden id of an RFID tag, but can for example also contain a UUID.\r\n",
+ "type": "string",
+ "maxLength": 255
+ },
+ "type": {
+ "description": "*(2.1)* Enumeration of possible idToken types. Values defined in Appendix as IdTokenEnumStringType.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["idToken", "type"]
+ },
+ "MessageContentType": {
+ "description": "Contains message details, for a message to be displayed on a Charging Station.\r\n\r\n",
+ "javaType": "MessageContent",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "format": {
+ "$ref": "#/definitions/MessageFormatEnumType"
+ },
+ "language": {
+ "description": "Message language identifier. Contains a language code as defined in <<ref-RFC5646,[RFC5646]>>.\r\n",
+ "type": "string",
+ "maxLength": 8
+ },
+ "content": {
+ "description": "*(2.1)* Required. Message contents. +\r\nMaximum length supported by Charging Station is given in OCPPCommCtrlr.FieldLength[\"MessageContentType.content\"].\r\n Maximum length defaults to 1024.\r\n\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["format", "content"]
+ },
+ "TransactionLimitType": {
+ "description": "Cost, energy, time or SoC limit for a transaction.\r\n",
+ "javaType": "TransactionLimit",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "maxCost": {
+ "description": "Maximum allowed cost of transaction in currency of tariff.\r\n",
+ "type": "number"
+ },
+ "maxEnergy": {
+ "description": "Maximum allowed energy in Wh to charge in transaction.\r\n",
+ "type": "number"
+ },
+ "maxTime": {
+ "description": "Maximum duration of transaction in seconds from start to end.\r\n",
+ "type": "integer"
+ },
+ "maxSoC": {
+ "description": "Maximum State of Charge of EV in percentage.\r\n",
+ "type": "integer",
+ "minimum": 0.0,
+ "maximum": 100.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "totalCost": {
+ "description": "When _eventType_ of TransactionEventRequest is Updated, then this value contains the running cost. When _eventType_ of TransactionEventRequest is Ended, then this contains the final total cost of this transaction, including taxes, in the currency configured with the Configuration Variable: Currency. Absence of this value does not imply that the transaction was free. To indicate a free transaction, the CSMS SHALL send a value of 0.00.\r\n",
+ "type": "number"
+ },
+ "chargingPriority": {
+ "description": "Priority from a business point of view. Default priority is 0, The range is from -9 to 9. Higher values indicate a higher priority. The chargingPriority in <<transactioneventresponse,TransactionEventResponse>> is temporarily, so it may not be set in the <<cmn_idtokeninfotype,IdTokenInfoType>> afterwards. Also the chargingPriority in <<transactioneventresponse,TransactionEventResponse>> has a higher priority than the one in <<cmn_idtokeninfotype,IdTokenInfoType>>. \r\n",
+ "type": "integer"
+ },
+ "idTokenInfo": {
+ "$ref": "#/definitions/IdTokenInfoType"
+ },
+ "transactionLimit": {
+ "$ref": "#/definitions/TransactionLimitType"
+ },
+ "updatedPersonalMessage": {
+ "$ref": "#/definitions/MessageContentType"
+ },
+ "updatedPersonalMessageExtra": {
+ "type": "array",
+ "additionalItems": false,
+ "items": {
+ "$ref": "#/definitions/MessageContentType"
+ },
+ "minItems": 1,
+ "maxItems": 4
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:TriggerMessageRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "MessageTriggerEnumType": {
+ "description": "Type of message to be triggered.\r\n",
+ "javaType": "MessageTriggerEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "BootNotification",
+ "LogStatusNotification",
+ "FirmwareStatusNotification",
+ "Heartbeat",
+ "MeterValues",
+ "SignChargingStationCertificate",
+ "SignV2GCertificate",
+ "SignV2G20Certificate",
+ "StatusNotification",
+ "TransactionEvent",
+ "SignCombinedCertificate",
+ "PublishFirmwareStatusNotification",
+ "CustomTrigger"
+ ]
+ },
+ "EVSEType": {
+ "description": "Electric Vehicle Supply Equipment\r\n",
+ "javaType": "EVSE",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "EVSE Identifier. This contains a number (> 0) designating an EVSE of the Charging Station.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "An id to designate a specific connector (on an EVSE) by connector index number.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["id"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evse": {
+ "$ref": "#/definitions/EVSEType"
+ },
+ "requestedMessage": {
+ "$ref": "#/definitions/MessageTriggerEnumType"
+ },
+ "customTrigger": {
+ "description": "*(2.1)* When _requestedMessage_ = `CustomTrigger` this will trigger sending the corresponding message in field _customTrigger_, if supported by Charging Station.\r\n\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestedMessage"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:TriggerMessageResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "TriggerMessageStatusEnumType": {
+ "description": "Indicates whether the Charging Station will send the requested notification or not.\r\n",
+ "javaType": "TriggerMessageStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NotImplemented"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/TriggerMessageStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:UnlockConnectorRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "evseId": {
+ "description": "This contains the identifier of the EVSE for which a connector needs to be unlocked.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "connectorId": {
+ "description": "This contains the identifier of the connector that needs to be unlocked.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["evseId", "connectorId"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:UnlockConnectorResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "UnlockStatusEnumType": {
+ "description": "This indicates whether the Charging Station has unlocked the connector.\r\n",
+ "javaType": "UnlockStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Unlocked", "UnlockFailed", "OngoingAuthorizedTransaction", "UnknownConnector"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/UnlockStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:UnpublishFirmwareRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "checksum": {
+ "description": "The MD5 checksum over the entire firmware file as a hexadecimal string of length 32. \r\n",
+ "type": "string",
+ "maxLength": 32
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["checksum"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:UnpublishFirmwareResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "UnpublishFirmwareStatusEnumType": {
+ "description": "Indicates whether the Local Controller succeeded in unpublishing the firmware.\r\n",
+ "javaType": "UnpublishFirmwareStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["DownloadOngoing", "NoFirmware", "Unpublished"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/UnpublishFirmwareStatusEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:UpdateDynamicScheduleRequest",
+ "description": "Id of dynamic charging profile to update.\r\n",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingScheduleUpdateType": {
+ "description": "Updates to a ChargingSchedulePeriodType for dynamic charging profiles.\r\n\r\n",
+ "javaType": "ChargingScheduleUpdate",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "limit": {
+ "description": "Optional only when not required by the _operationMode_, as in CentralSetpoint, ExternalSetpoint, ExternalLimits, LocalFrequency, LocalLoadBalancing. +\r\nCharging rate limit during the schedule period, in the applicable _chargingRateUnit_. \r\nThis SHOULD be a non-negative value; a negative value is only supported for backwards compatibility with older systems that use a negative value to specify a discharging limit.\r\nFor AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "limit_L2": {
+ "description": "*(2.1)* Charging rate limit on phase L2 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "limit_L3": {
+ "description": "*(2.1)* Charging rate limit on phase L3 in the applicable _chargingRateUnit_. \r\n",
+ "type": "number"
+ },
+ "dischargeLimit": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ that the EV is allowed to discharge with. Note, these are negative values in order to be consistent with _setpoint_, which can be positive and negative. +\r\nFor AC this field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L2": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L2 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "dischargeLimit_L3": {
+ "description": "*(2.1)* Limit in _chargingRateUnit_ on phase L3 that the EV is allowed to discharge with. \r\n",
+ "type": "number",
+ "maximum": 0.0
+ },
+ "setpoint": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow as close as possible. Use negative values for discharging. +\r\nWhen a limit and/or _dischargeLimit_ are given the overshoot when following _setpoint_ must remain within these values.\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpoint_L2": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L2 as close as possible.\r\n",
+ "type": "number"
+ },
+ "setpoint_L3": {
+ "description": "*(2.1)* Setpoint in _chargingRateUnit_ that the EV should follow on phase L3 as close as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow as closely as possible. Positive values for inductive, negative for capacitive reactive power or current. +\r\nThis field represents the sum of all phases, unless values are provided for L2 and L3, in which case this field represents phase L1.\r\n",
+ "type": "number"
+ },
+ "setpointReactive_L2": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L2 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "setpointReactive_L3": {
+ "description": "*(2.1)* Setpoint for reactive power (or current) in _chargingRateUnit_ that the EV should follow on phase L3 as closely as possible. \r\n",
+ "type": "number"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ }
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "chargingProfileId": {
+ "description": "Id of charging profile to update.\r\n",
+ "type": "integer"
+ },
+ "scheduleUpdate": {
+ "$ref": "#/definitions/ChargingScheduleUpdateType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["chargingProfileId", "scheduleUpdate"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:UpdateDynamicScheduleResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "ChargingProfileStatusEnumType": {
+ "description": "Returns whether message was processed successfully.\r\n",
+ "javaType": "ChargingProfileStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/ChargingProfileStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:UpdateFirmwareRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "FirmwareType": {
+ "description": "Represents a copy of the firmware that can be loaded/updated on the Charging Station.\r\n",
+ "javaType": "Firmware",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "location": {
+ "description": "URI defining the origin of the firmware.\r\n",
+ "type": "string",
+ "maxLength": 2000
+ },
+ "retrieveDateTime": {
+ "description": "Date and time at which the firmware shall be retrieved.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "installDateTime": {
+ "description": "Date and time at which the firmware shall be installed.\r\n",
+ "type": "string",
+ "format": "date-time"
+ },
+ "signingCertificate": {
+ "description": "Certificate with which the firmware was signed.\r\nPEM encoded X.509 certificate.\r\n",
+ "type": "string",
+ "maxLength": 5500
+ },
+ "signature": {
+ "description": "Base64 encoded firmware signature.\r\n",
+ "type": "string",
+ "maxLength": 800
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["location", "retrieveDateTime"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "retries": {
+ "description": "This specifies how many times Charging Station must retry to download the firmware before giving up. If this field is not present, it is left to Charging Station to decide how many times it wants to retry.\r\nIf the value is 0, it means: no retries.\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "retryInterval": {
+ "description": "The interval in seconds after which a retry may be attempted. If this field is not present, it is left to Charging Station to decide how long to wait between attempts.\r\n",
+ "type": "integer"
+ },
+ "requestId": {
+ "description": "The Id of this request\r\n",
+ "type": "integer"
+ },
+ "firmware": {
+ "$ref": "#/definitions/FirmwareType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["requestId", "firmware"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:UpdateFirmwareResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "UpdateFirmwareStatusEnumType": {
+ "description": "This field indicates whether the Charging Station was able to accept the request.\r\n\r\n",
+ "javaType": "UpdateFirmwareStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": [
+ "Accepted",
+ "Rejected",
+ "AcceptedCanceled",
+ "InvalidCertificate",
+ "RevokedCertificate"
+ ]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/UpdateFirmwareStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:UsePriorityChargingRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "transactionId": {
+ "description": "The transaction for which priority charging is requested.\r\n",
+ "type": "string",
+ "maxLength": 36
+ },
+ "activate": {
+ "description": "True to request priority charging.\r\nFalse to request stopping priority charging.\r\n",
+ "type": "boolean"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["transactionId", "activate"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:UsePriorityChargingResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "PriorityChargingStatusEnumType": {
+ "description": "Result of the request.\r\n",
+ "javaType": "PriorityChargingStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected", "NoProfile"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "status": {
+ "$ref": "#/definitions/PriorityChargingStatusEnumType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["status"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:VatNumberValidationRequest",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "vatNumber": {
+ "description": "VAT number to check.\r\n\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "evseId": {
+ "description": "EVSE id for which check is done\r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["vatNumber"]
+}
--- /dev/null
+{
+ "$schema": "http://json-schema.org/draft-06/schema#",
+ "$id": "urn:OCPP:Cp:2:2025:1:VatNumberValidationResponse",
+ "comment": "OCPP 2.1 Edition 1 (c) OCA, Creative Commons Attribution-NoDerivatives 4.0 International Public License",
+ "definitions": {
+ "GenericStatusEnumType": {
+ "description": "Result of operation.\r\n",
+ "javaType": "GenericStatusEnum",
+ "type": "string",
+ "additionalProperties": false,
+ "enum": ["Accepted", "Rejected"]
+ },
+ "AddressType": {
+ "description": "*(2.1)* A generic address format.\r\n",
+ "javaType": "Address",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Name of person/company\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "address1": {
+ "description": "Address line 1\r\n",
+ "type": "string",
+ "maxLength": 100
+ },
+ "address2": {
+ "description": "Address line 2\r\n",
+ "type": "string",
+ "maxLength": 100
+ },
+ "city": {
+ "description": "City\r\n",
+ "type": "string",
+ "maxLength": 100
+ },
+ "postalCode": {
+ "description": "Postal code\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "country": {
+ "description": "Country name\r\n",
+ "type": "string",
+ "maxLength": 50
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["name", "address1", "city", "country"]
+ },
+ "StatusInfoType": {
+ "description": "Element providing more information about the status.\r\n",
+ "javaType": "StatusInfo",
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "reasonCode": {
+ "description": "A predefined code for the reason why the status is returned in this response. The string is case-insensitive.\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "additionalInfo": {
+ "description": "Additional text to provide detailed information.\r\n",
+ "type": "string",
+ "maxLength": 1024
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["reasonCode"]
+ },
+ "CustomDataType": {
+ "description": "This class does not get 'AdditionalProperties = false' in the schema generation, so it can be extended with arbitrary JSON properties to allow adding custom data.",
+ "javaType": "CustomData",
+ "type": "object",
+ "properties": {
+ "vendorId": {
+ "type": "string",
+ "maxLength": 255
+ }
+ },
+ "required": ["vendorId"]
+ }
+ },
+ "type": "object",
+ "additionalProperties": false,
+ "properties": {
+ "company": {
+ "$ref": "#/definitions/AddressType"
+ },
+ "statusInfo": {
+ "$ref": "#/definitions/StatusInfoType"
+ },
+ "vatNumber": {
+ "description": "VAT number that was requested.\r\n\r\n",
+ "type": "string",
+ "maxLength": 20
+ },
+ "evseId": {
+ "description": "EVSE id for which check was requested. \r\n\r\n",
+ "type": "integer",
+ "minimum": 0.0
+ },
+ "status": {
+ "$ref": "#/definitions/GenericStatusEnumType"
+ },
+ "customData": {
+ "$ref": "#/definitions/CustomDataType"
+ }
+ },
+ "required": ["vatNumber", "status"]
+}
--- /dev/null
+# OCPP 2.1 (all files)
+
+This zip contains the latest version of the OCPP 2.1 Edition 1 specification parts 0, 1, 2 specification, 2 appendices, 3 and 4 for those parts of OCPP 2.1.
+
+| File | Date |
+| --------------------------------------------- | ---------- |
+| OCPP-2.1_edition1_part0_introduction | 2025-01-23 |
+| OCPP-2.1_edition1_part1_architecture_topology | 2025-01-23 |
+| OCPP-2.1_edition1_part2_specification | 2025-01-23 |
+| OCPP-2.1_part2_appendices_v20 | 2025-01-23 |
+| OCPP-2.1_part3_JSON_schemas | 2025-01-23 |
+| OCPP-2.1_edition1_part4_ocpp-j-specification | 2025-01-23 |
+| OCPP-2.1_edition1_errata_2025-09 | 2025-09-30 |
+| Appendices_CSV_v2.0 | 2025-01-23 |
+
+### Additional information
+
+The errata do not affect any schemas of OCPP messages. The 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 were 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 2.1 part 2 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.
+
+On 2025-09-30 the following documents were updated in the set:
+
+- OCPP-2.1_edition1_errata_2025-09 replaced OCPP-2.1_edition1_errata_2025-06 - this errata document contains all errata for all parts of OCPP 2.1 until 2025-09
+
+On 2025-07-08 the following documents were updated in the set:
+
+- OCPP-2.1_edition1_errata_2025-06 was added to the documentation set - this errata document contains all errata for all parts of OCPP 2.1 until 2025-06
--- /dev/null
+# OCPP
+
+# Signed Meter Values in OCPP
+
+v1.0, 2025-02-10
+
+# Table of Contents
+
+1. Introduction 2
+
+2. Concepts. 4
+
+2.1. Configuration flexibility & use-cases 4
+2.2. Correctness of measurement. 4
+2.3. Transactions & CDRs 6
+2.4. Notes in this document. 7
+
+3. OCPP 1.6 Implementation 8
+
+3.1. Messages 8
+3.2. Data types 9
+3.3. Configuration settings 12
+
+4. OCPP 2.x Implementation 17
+
+4.1. Messages. 17
+4.2. Data Types. 18
+4.3. Configuration Variables.. 20
+
+5. Appendix 24
+
+5.1. Configuration Key/Variable Settings Matrix 24
+5.2. OCPP 1.6 Example Message (Informative) 25
+5.3. Example publicKey Value Composition (Informative) 25
+
+# OCA Application Note
+
+Relevant for OCPP version: 1.6, 2.0.1 and 2.1.
+
+Copyright © 2025 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
+
+<table><tr><td>Version</td><td>Date</td><td>Author</td><td>Description</td></tr><tr><td>1.0</td><td>2025-02-10</td><td>Scott Thomson (Shell)
+Robert Schlabbach (Ubitricity)
+Patrick Rademakers (Shell)</td><td>First edition</td></tr></table>
+
+# 1. Introduction
+
+This document outlines the standardized method for sharing signed meter values between a Charging Station (CS) and a Charging Station Management System (CSMS). The purpose of which is to provide consumers a way of validating the validity of chargeable measurand(s) (Wh, Time, etc), in compliance with applicable laws or regulations in different jurisdictions. Those include German Mess- & Eichrecht laws.
+
+Full compliance with these laws can include requirements that are out of scope for this whitepaper, which include:
+
+- Unambiguously identifying a customer
+- Handling of ad-hoc payments
+- Handling of signed meter data between Charging Station Management System and Mobility Service Provider
+- How the Charge Station Operator (CSO/CPO) or Mobility Operator must provide the details (including transaction IDs, public keys etc) to customers
+- How the customer may verify the correctness of the measured/billable values
+
+For more information on the out-of-scope elements, refer to guidance on local laws for the jurisdiction of interest. This whitepaper is limited to the transport of signed meter values between the Charging Station and the Charging Station Management System.
+
+The measurements exchanged via OCPP can become part of Charge Detail Records (CDRs) that are exchanged via OCPI or a similar protocol, but the CDR exchange itself via those protocols is out of scope for this document.
+
+Terminology & acronyms
+
+<table><tr><td>Term</td><td>Meaning</td></tr><tr><td>CDR</td><td>Charge Detail Record</td></tr><tr><td>CSMS</td><td>Charging Station Management System</td></tr><tr><td>CS</td><td>Charging Station (which may container a number of EVSEs)</td></tr><tr><td>CSO</td><td>Charging Station Operators</td></tr><tr><td>EDL</td><td>Energie Dienst Leistung (Energy Service)</td></tr><tr><td>EVSE</td><td>Electric Vehicle Supply Equipment, the equipment needed to charge one vehicle</td></tr><tr><td>M&E</td><td>Mess- & Eichrecht</td></tr><tr><td>MSP</td><td>Mobility Service Provider (sometimes also referred to as EMSP)</td></tr><tr><td>OCA</td><td>Open Charge Alliance</td></tr><tr><td>OCMF</td><td>Open Charge Metering Format</td></tr><tr><td>OCPI</td><td>Open Charge Point Interface</td></tr><tr><td>OCPP</td><td>Open Charge Point Protocol</td></tr><tr><td>PTB</td><td>Physikalisch-Technische Bundesanstalt (Physical-Technical Federal Institute)</td></tr><tr><td>SAFE</td><td>Software Alliance For E-mobility</td></tr></table>
+
+# References
+
+A list of references relevant for this paper:
+
+- [BNetzA], Bundesnetzagentur database (German) with data for all commissioned charging stations - including Public Keys, Bundesnetzagentur, https://www.bundesnetzagentur.de/DE/Fachthemen/ElektrizitaetundGas/E-Mobilitaet/start.html
+- [EICH_A7], https://www.gesetze-im-internet.de/messev/anlage_7.html
+- [GCIR], German Charging Infrastructure Regulations (Source: Netherlands Enterprise Agency), Maarten Venselaar, Harm-Jan Idema, Thomas Endriβ, https://www.rvo.nl/sites/default/files/2019/04/German%20charging%20infrastructure%20regulations%20report%20march%202019_0.pdf
+ [OCMF], https://github.com/SAFE-eV/OCMF-Open-Charge-Metering-Format/blob/master/OCMF-en.md
+- [OCPP16], OCPP 1.6 edition 2, Open Charge Alliance, https://openchargealliance.org/protocols/open-charge-point-protocol/
+- [OCPP201], OCPP 2.0.1 edition 3, Open Charge Alliance, https://openchargealliance.org/protocols/open-charge-point-protocol/
+- [OCPP21], OCPP 2.1 edition 1, Open Charge Alliance, https://openchargealliance.org/protocols/open-charge-point-protocol/
+ [S.A.F.E.], https://safe-ev.org/en/
+
+# 2. Concepts
+
+To ensure compliance with the applicable laws & regulations surrounding validated metering of transactions including metered consumption, the following must be achieved:
+
+a. Ensure trustworthy measurements.
+b. Ensure those measurements are communicated throughout the ecosystem in a tamper-proof way,
+c. Provide customers with a method to verify measurements that are the underpinning for their invoices.
+
+For a), see section 2.2 for informative description, and for b), see the rest of this document. Item c) is out of scope for this whitepaper.
+
+Section 2.1 provides an overview of how a Charging Station operator may wish to configure signed meter values for different use cases.
+
+# 2.1. Configuration flexibility & use-cases
+
+To provide flexibility of use-cases, the configuration of the Charging Station may be changed based on configuration keys (OCPP 1.6) or variables (OCPP 2.0.1/2.1). In sections 3 and 4 the specific requirements for each version of OCPP are described. Appendix 5.1 provides a matrix of how the configurations operate.
+
+For example, by setting only SampledDataSignReadings to true, this will enable signed start and end meter values to be placed within the StopTransaction.req (OCPP 1.6) or TransactionEventRequest(Ended) (OCPP 2.0.1/2.1). Setting SampledDataSignStartedReadings to true, in addition, would result in a signed start meter value being sent to the Central System within either a MeterValues.req (OCPP 1.6) or TransactionEventRequest(Started) (OCPP 2.0.1/2.1). To be compliant with Eichrecht, at minimum signed start and stop value must be shared with the Central System – this could be done via just the StopTransaction.req/TransactionEventRequest(Ended) message, which would require only setting SampledDataSignedReadings to true.
+
+The variables are split between Read-Writeable (for switching the signed meter values on and off globally) and Read-Writeable or Read-Only, depending on the capabilities of the Charging Station. For example, if a charging station is unable, based on hardware capability, to sign intermediate values, then SampledDataSignUpdatedReadings or AlignedDataSignUpdatedReadings may be set to false and be read-only variables.
+
+# 2.2. Correctness of measurement
+
+To ensure the correct measurement, the meter must be certified and calibrated. If the certification/calibration can expire, then the CSO must have a process to re-certify/calibrate the meter in a maintenance cycle. It is up to the CSO to ensure this is done at the right time. If not, if the certification/calibration expires, conformance to the applicable laws would be lost. This means that from that point onward, the rules for having a non-certified solution apply. Depending on what category the charging solution falls under (see [EICH_A7] for possibilities within Germany) the certification validity period can vary from 4 to 16 years.
+
+Not only is a calibrated meter needed, as a charging station, communication is required internally to get the values from the meter and send them to the CSMS. However, different meters communicate in a unique way
+
+and have their own way of signing data to protect against tampering. So, it is important to understand what protocol the meter speaks, because it will affect the data sent in our OCPP metering messages. It should be noted that it is possible to be Eichrecht compliant without sharing the meter values with the CSMS – they can be stored locally and provided on a display based on a customer prompt. This is out of the scope of this whitepaper or OCPP.
+
+# 2.2.1. Meter information
+
+The meter (or more technically for Eichrecht, a "Messkapsel" or measuring capsule, which could be a system including a meter and a separate signing module) itself must be a certified, and finally the entire charging station including the meter must be certified for compliance with local laws, as needed. The public key linked to the private key that certified the meter value must then be made available to the charging station to share with the CSMS, as needed. There are different potential coding methods for the meter values that are to be shared with the Central System. The most common two at time of writing are OCMF or EDL, however these are not prescribed by the whitepaper.
+
+# 2.2.2. OCMF: Open Charge Metering Format
+
+The most common type of encoding method supported by different manufacturers in Germany is OCMF (Open Charge Metering Format). The aim of OCMF is to describe an independent and generally usable data format for recording meter readings from charging stations that are relevant under the German calibration law. The full OCMF definition can be found via [OCMF].
+
+Note that the OCMF document talks about OCPP 1.5, not OCPP 1.6 or 2.0.1/2.1, but the elements of 1.5 it is referring to, still exist in later versions, and are still applicable.
+
+# 2.2.3. EDL
+
+EDL stands for Energie Dienst Leistung, or Energy Service, an encoding method that is common in the German market and supported by assorted brands, used to encode the meter values.
+
+# 2.2.4. Other meter formats
+
+There are several other meter formats available and possible now and in the future. How to handle these different formats is outlined in sections 3.2.1 (OCPP 1.6J) and 4.2.2 (OCPP 2.x).
+
+# 2.2.5. Meter Public Key Verification
+
+To enable a user/customer or Charge Point Operator to validate that the public key is correct, the Bundesnetzagentur (Federal Network Agency) requires that all commissioned charging stations are published on their databases. This includes the public keys for a given EVSE. See references for link.
+
+# 2.2.6. Public key
+
+The public key is specific to the meter that does the signing of the measurements. It should only change when the meter is physically replaced or modified, since the public key is reported on the body of the meter (for M&E in Germany, this must be visible to the customer via a window in the charging station or as part of the digital display, however that $2^{\text{nd}}$ option then requires the screen and its software to be part of the certification process).
+
+During installation/configuration of the charging station this key must initially be configured in the charging station. The public key can be transmitted with the signed meter values. Alternatively, the CSMS can retrieve the public key from a configuration key/variable to reduce transferred data usage.
+
+Charging stations typically have one meter for each EVSE, so a charging station with multiple EVSEs will also have to provide multiple public keys for retrieval. See MeterPublicKey[ConnectorID] (3.3.1 or 4.3.2) for more information on this.
+
+# 2.3. Transactions & CDRs
+
+# 2.3.1. Transaction flow
+
+To start a charging session six requirements will have to be satisfied (OCPP 1.6 described):
+
+1. The driver must be allowed to charge; done locally via RFID, via an Authorization request to the CSMS, using cached Authorization results, the local list pushed by the CSMS, or a proprietary integration to a payment terminal. Alternatively, the authorization can be done remotely via a RemoteStartTransaction.req by the CSMS.
+2. The cable must be properly plugged in, to both the car and the charging station. Should this be applied to a wireless charging session then this step would mean the wireless connection is operational.
+3. The charging station must configure the energy meter by sending at least a user identification or a session identification. (internally to CS)
+4. The time of the energy meter must be verified. (internally to CS)
+5. Maybe a charging tariff must be configured. (internally to CS)
+6. Where supported, the official eMI3 EVSE Id must be configured as additional metadata within the energy meter, so that the EV driver can easily verify the public key against a public key database (see 2.1.4). (internally to CS)
+
+When these requirements are met, the charging station takes the initial measurement from the certified meter and sends a StartTransaction.req to the CSMS. This marks the beginning of the charging session. During the charging session the charging station, if so configured, may send intermediate meterValue updates to the CSMS. Depending on the use cases and settings of the configuration keys outlined in this whitepaper, these intermediate values may be signed or unsigned type.
+
+When one of the two start requirements is revoked, e.g., by unplugging, swiping the RFID card again, pushing a stop button, or via a RemoteStopTransaction.req, the charging station will stop energy transfer, get the last meter value, and report this in the StopTransaction.req message that signals the end of the transaction to the CSMS.
+
+# NOTE
+
+StopTransaction.req can only be sent after reading the last certified meter value. In most cases this will not cause any noticeable delay, but it has been reported that some meters in exceptional situations can cause a delay of up to 30 seconds. At the time of writing, it is not known which meter(s) specifically have this delay.
+
+# 2.3.2. Transaction duration
+
+The OCPP transaction duration is the time between the message timestamp of the StartTransaction.req (TransactionEventRequest(Started) for OCPP 2.x) and the message timestamp of the StopTransaction.req (TransactionEventRequest(Ended) for OCPP 2.x). Be aware that the cost calculation typically must be done on timestamps in the signed meter data between the first and last signed value.
+
+The timestamp of the StopTransaction.req (TransactionEventRequest(Ended) for OCPP 2.x) message will be the time that the charge was stopped. The timestamp of the sampledValue item with a signed meter value will be the time that the MID meter is requested to create the signed meter value.
+
+# 2.3.3. Charge Detail Record
+
+German Eichrecht laws require CDRs to include signed meter values for the start and the end of the transaction. Signed intermediate meter values are optional depending on if the charging session has a change in tariff during the transaction, then it is mandatory. The CSMS combines all the charging session information into a CDR.
+
+# 2.3.4. Direct/Ad-hoc Payments
+
+This whitepaper outlines how to manage the transport of messages from typical RFID activated transactions. For full compliance with Eichrecht and direct payment methods, it may be required to inject the tariff information into the signed data. A method for doing this within OCPP 1.6 & OCPP 2.x is under consideration.
+
+# 2.4. Notes in this document
+
+Notes are used to provide additional information to help in understanding or using this document. These are informative only, and some notes will be intended primarily for operators (CSO - Charging Station Operators), and some notes will be intended primarily for implementors (Charging Station Manufacturers).
+
+# 3. OCPP 1.6 Implementation
+
+This section covers how to extend OCPP 1.6 to support signed meter data in a standardized way. Subsection 3.2 explains a new datatype borrowed from OCPP 2.x called SignedMeterValueType. This contains the details of the payload of a signed meter value according to this whitepaper. Subsection 3.3 contains additional configuration settings (see 2.1 for more detail).
+
+# 3.1. Messages
+
+# 3.1.1. StartTransaction.req
+
+As explained in section 2.3.1 (Transaction flow), a transaction start is communicated to the central system via a StartTransaction.req. This message has an integer field called meterStart to pass the initial meterValue but only as unsigned data (and as an integer Wh value), without the option to include signed data as well. The sending of a signed meter value is the topic of the next section.
+
+# 3.1.2. MeterValues.req – for delivering a signed meter value at the start of the transaction
+
+The use of this message at the start of a transaction is optional for this whitepaper. Its intent is to enable a signed meter value to be sent to the CSMS at the start of the transaction, immediately following the StartTransaction.req message. See the keys in 3.3.4 for sampled data.
+
+# 3.1.3. MeterValues.req – for delivering intermediate signed meter values
+
+Some use cases may require additional MeterValues.req to receive updated intermediate values based on the settings of the keys:
+
+- MeterValuesSampledData
+- MeterValuesSampledDataMaxLength
+- MeterValueSampledInterval
+ ClockAlignedDataInterval
+- MeterValuesAlignedData
+- MeterValuesAlignedDataMaxLength
+
+Typically, these are unsigned, but with the new configuration key SampledDataSignUpdatedReadings (3.3.6) or AlignedDataSignUpdatedReadings (3.3.8) these can be set to be of a signed type.
+
+# NOTE
+
+It may take some time for the metering device to sign a value, therefore, higher frequency intervals may not be possible. It is recommended that an implementation of the approach described in this whitepaper, documents the highest possible frequency of signed meter values.
+
+# 3.1.4. StopTransaction.req
+
+By setting SampledDataSignReadings (3.3.3) or AlignedDataSignReadings (3.3.6), the charging station SHALL
+
+send signed values with the CSMS within the StopTransaction.req message.
+
+If the signed meter data to populate the sampledValue field of the transactionData in the StopTransaction.req are in separate data containers, (e.g., start and stop signed meter values are in separate OCMF containers), then:
+
+- The signed data for the start meter value SHALL go in a sampledValue (of SampledValue type) with context Transaction.Begin.
+- The signed data for the stop meter value SHALL go in a sampledValue (of SampledValue type) with context Transaction.End
+- And both placed in the StopTransaction.req transactionData field.
+
+If the signed meter data are in a single data container (e.g., both start and stop signed meter values are in one OCMF container), then:
+
+- The signed data for the meter values SHALL go in a sampledValue (of SampledValueType) with context Transaction.End
+- And placed in the StopTransaction.req transactionData field.
+
+# NOTE
+
+This is to minimize data duplication in case the meter sends the signed meter values in one data container to the Charging Station.
+
+# 3.2. Data types
+
+This section explains the additional data types used for implementation in OCPP 1.6.
+
+# 3.2.1. SignedMeterValueType - Reused from OCPP 2.x
+
+For compatibility, the data structure that is already specified in OCPP 2.x: SignedmeterValueType SHALL be used to format the signed meter data. This is used in StopTransaction.req as the form taken by the value within sampledValue of the transactionData field. It is also used in the sampledValue of the meterValue field in a MeterValues.req. Figure 1 below is an extract from the OCPP 2.x specification, and Table 1 outlines the requirements per this whitepaper.
+
+Figure 1. OCPP2.0.1 Edition 3 Part 2 - Specification, chapter 2.46, page 413
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>signedMeterData</td><td>string[0..2500]</td><td>1..1</td><td>Required. Base64 encoded, contains the signed data which might contain more than just the meter value. It can contain information like timestamps, reference to a customer etc.</td></tr><tr><td>signingMethod</td><td>string[0..50]</td><td>1..1</td><td>Required. Method used to create the digital signature.</td></tr><tr><td>encodingMethod</td><td>string[0..50]</td><td>1..1</td><td>Required. Method used to encode the meter values before applying the digital signature algorithm.</td></tr><tr><td>publicKey</td><td>string[0..2500]</td><td>1..1</td><td>Required. Base64 encoded, sending depends on configuration variable PublicKeyWithSignedMeterValue.</td></tr></table>
+
+Table 1. Requirements for SignedMeterValueType
+
+<table><tr><td>Field Name</td><td>Requirements</td></tr><tr><td>signedMeterData</td><td>SHALL be populated based on the requirements in Figure 1.</td></tr><tr><td>signingMethod</td><td>May already be included in the signedMeterData block (depending on the encoding format of the signed meter data). If it is already included in the signedMeterData, then this SHALL be an empty string. If not included in signedMeterData, then this field SHALL be populated. See Table 13 for value definitions.</td></tr><tr><td>encodingMethod</td><td>SHALL be populated based on the format of the meter (e.g., OCMF, EDL, etc).</td></tr><tr><td>publicKey</td><td>SHALL be included based on the configuration of the PublicKeyWithSignedMeterValue (3.3.2) setting. If the public key is not sent with a message, it SHALL be sent as an empty string. If it is sent, it SHALL contain a Base64 encoded string with the content as specified in 3.2.2.</td></tr></table>
+
+# 3.2.2. publicKey field content specification (for both OCPP 1.6 and OCPP 2.x)
+
+The Base64 encoded content of the publicKey field shall be a colon-separated string:
+
+<marker>：<encoding>：<content-type>：<printed-public-key>
+
+# Where:
+
+- <marker> identifies the content format specified in this document. It is oca.
+- <encoding> specifies the encoding of the <printed-public-key>, see Table 2.
+- <content-type> specifies the type of content after decoding <printed-public-key>. See Table 3.
+- <printed-public-key> contains the public key as printed on the certified meter.
+
+# NOTE
+
+The public key representation as printed on the certified meter was chosen for easiest matching of the public key visible to the customer to the one transmitted with the signed meter values.
+
+Since there is no standardized format for printing the public key on a certified meter, the additional information above is needed to be able process the public key for signature validation.
+
+Table 2. publicKey encoding values
+
+<table><tr><td>Encoding value</td><td>Content of <printed-public-key></td></tr><tr><td>base16</td><td>A case-insensitive string containing a hexadecimal representation of the content. Non-hexadecimal character strings (i.e. other than 0-9a-fA-F) and a hexadecimal prefix (0x) SHALL be ignored.</td></tr><tr><td>base64</td><td>A Base64 encoded string.</td></tr></table>
+
+Table 3. publicKey content-type values
+
+<table><tr><td>content-type value</td><td>Decoded content of <printed-public-key></td></tr><tr><td>asn1</td><td>A binary ASN.1 structure containing the signature algorithm, its parameters and the actual public key.</td></tr></table>
+
+# NOTE
+
+The above tables are intended to be extended with additional values as needed. It is strongly encouraged for vendors needing any additional value to contact the OpenChargeAlliance for inclusion, so that additional values can be specified in a uniform way.
+
+# NOTE
+
+See 5.3 for an example of how to put together the publicKey value.
+
+# 3.3. Configuration settings
+
+The configuration keys described in this section are based on the naming convention of OCPP 2.x, to provide consistency across versions.
+
+# 3.3.1. MeterPublicKey[ConnectorID]
+
+Table 4. Configuration Key MeterPublicKey[ConnectorID]
+
+<table><tr><td>Variable name</td><td>MeterPublicKey[ConnectorID]</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RO</td></tr><tr><td>Type</td><td>string</td></tr><tr><td>Description</td><td>Configuration key that can be used to retrieve the public key for a meter connected to a specific connector/EVSE. The value of this configuration key SHALL be as specified in 3.2.2.Examples: It is expected that each EVSE will have its own meter, therefore, each configuration of charging station will be slightly different. For a charging station with a single physical connector, this would always be MeterPublicKey1. For a charging station with a dual physical connector, that functions as a single EVSE (can only charge one vehicle at a time), MeterPublicKey1 and MeterPublicKey2 would return the same value. For a charging station that has two EVSEs with one connector on each, the configuration keys MeterPublicKey1 and MeterPublicKey2 would return different values.</td></tr></table>
+
+# NOTE
+
+The value of a configuration key in OCPP 1.6 is limited in length to 500 bytes. Consequently, this cannot be used for public keys longer than that.
+
+# 3.3.2. PublicKeyWithSignedMeterValue
+
+The purpose of using this configuration key is to define when a charging station needs to include the public key in a signed meter value. It is re-used from OCPP 2.x and defined in Table 5.
+
+Table 5. Configuration Key PublicKeyWithSignedMeterValue
+
+<table><tr><td>Key name</td><td>PublicKeyWithSignedMeterValue</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>Enum String</td></tr><tr><td>Description</td><td>The value may be set to the following values:
+• Never: i.e., would not be sent automatically with signed meter values. CSMS already knows the value or requests it from configuration variable "MeterPublicKey".
+• OncePerTransaction
+• EveryMeterValue: public key in every meterValue, including the ones in the transactionData field in the StopTransaction.req</td></tr></table>
+
+# NOTE
+
+If this configuration is set to Never then in case of a meter swap, public keys associated with historical transactions (made before the meter change) will no longer be available by a GetConfiguration.req. This could be a compliance issue.
+
+# 3.3.3. SampledDataSignReadings
+
+Configuration Key SampledDataSignReadings
+
+<table><tr><td>Key name</td><td>SampledDataSignReadings</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>Boolean</td></tr><tr><td>Description</td><td>If set to true, the Charging Station SHALL include signed meter values in the StopTransaction.req to the CSMS for those measurands configured in StopTxnSampledData, which can be signed by the certified meter, and optionally in additional messages, as configured by the configuration settings SampledDataSignStartedReadings (see 3.3.5) and SampledDataSignUpdatedReadings (see 3.3.6).</td></tr></table>
+
+# NOTE
+
+The description of SampledDataSignReadings is extended from the OCPP 2.x specification. It now globally enables or disables the transmission of signed sampled meter values. Which messages will contain signed sampled meter values, in addition to StopTransaction.req, is controlled by the additional configuration keys SampledDataSignStartedReadings and SampledDataSignUpdatedReadings, specified in this document.
+
+# 3.3.4. StartTxnSampledData
+
+With this new configuration key, when set to any measurands, the Charging Station SHALL send a
+
+MeterValues.req right after the StartTransaction.req, with SampledValues for the configured measurands with the context "Transaction.Begin". If it is not implemented or the value is an empty list, this extra MeterValues.req will not be sent (standard OCPP 1.6 behaviour).
+
+Table 6. Configuration Key StartTxnSampledData
+
+<table><tr><td>Key name</td><td>StartTxnSampledData</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Optional</td></tr><tr><td>Accessibility</td><td>RW or RO</td></tr><tr><td>Type</td><td>CSL of Measurands</td></tr><tr><td>Description</td><td>If the CSL is not empty, the Charging Station SHALL send a MeterValues.req with SampledValues having the context "Transaction.Begin" to the CSMS for the measurands contained in the CSL, right after the StartTransaction.req.</td></tr></table>
+
+# 3.3.5. SampledDataSignStartedReadings
+
+With this new configuration key, when set to true, the start meter values (according to 3.3.4) sent from the Charging Station to the Central System SHALL be signed, with format "signedData" and the value field formatted according to 3.2.1. If set to false, start meter values SHALL be of an unsigned format.
+
+Table 7. Configuration Key SampledDataSignStartedReadings
+
+<table><tr><td>Key name</td><td>SampledDataSignStartedReadings</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Optional</td></tr><tr><td>Accessibility</td><td>RW or RO</td></tr><tr><td>Type</td><td>Boolean</td></tr><tr><td>Description</td><td>If set to true, the Charging Station SHALL include signed meter values in the meterValue field of the MeterValues.req sent to the CSMS at the start of the transaction for those measurands configured in StartTxnSampledData which can be signed by the certified meter.
+This setting only has an effect if SampledDataSignReadings is set to true and StartTxnSampledData is implemented and contains any signable measurands.</td></tr></table>
+
+# 3.3.6. SampledDataSignUpdatedReadings
+
+With this new configuration key, when set to true, subsequent intermediate meter values (those not according to 3.3.5) sent from the Charging Station to the Central System SHALL be signed. If this key is set to false,
+
+intermediate values SHALL be according to the settings of the configuration variables outlined in 3.1.3 and of an unsigned format.
+
+Table 8. Configuration Key SampledDataSignUpdatedReadings
+
+<table><tr><td>Key name</td><td>SampledDataSignUpdatedReadings</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RW or RO</td></tr><tr><td>Type</td><td>Boolean</td></tr><tr><td>Description</td><td>If set to true, the Charging Station SHALL include signed meter values in the meterValue field in the MeterValues.req to the CSMS for those measurands configured in MeterValuesSampledData which can be signed by the certified meter.This setting only has an effect if SampledDataSignReadings is set to true.</td></tr></table>
+
+# 3.3.7.AlignedDataSignReadings
+
+Table 9. Configuration Key AlignedDataSignReadings
+
+<table><tr><td>Key name</td><td>AlignedDataSignReadings</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>Boolean</td></tr><tr><td>Description</td><td>If set to true, the Charging Station SHALL include signed meter values in the StopTransaction.req to the CSMS for those measurands configured in StopTxnAlignedData which can be signed by the certified meter, and optionally in other messages, as per the AlignedDataSignUpdatedReadings configuration key (see 3.3.7).</td></tr></table>
+
+# NOTE
+
+AlignedDataSignReadings globally enables or disables the transmission of signed aligned meter values. Which messages will contain signed sampled meter values, in addition to StopTransaction.req, is controlled by the additional configuration key AlignedDataSignUpdatedReadings, specified in this document.
+
+# 3.3.8.AlignedDataSignUpdatedReadings
+
+With this new configuration key, when set, clock-aligned intermediate meter values sent from the Charging Station to the Central System SHALL be signed. If this key is not set, intermediate values SHALL be according to the settings of the configuration variables outlined in 3.1.3 and of an unsigned format.
+
+Table 10. Configuration Key AssociatedDataSignUpdatedReadings
+
+<table><tr><td>Key name</td><td>AlignedDataSignUpdatedReadings</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RW or RO</td></tr><tr><td>Type</td><td>Boolean</td></tr><tr><td>Description</td><td>If set to true, the Charging Station SHALL include signed meter values in the meterValue field in the MeterValues.req messages to the CSMS for those measurands configured in MeterValuesAlignedData which can be signed by the certified meter. This variable only has an effect if AlignedDataSignReadings (3.3.7) is set to true.</td></tr></table>
+
+# 4. OCPP 2.x Implementation
+
+OCPP 2.0.1/2.1 were developed with native support for signed meter value functionality (and is the source of much being used for the 1.6 section of this whitepaper). To enable the use cases outlined in section 2.1, configuration variables (see section 4.3) are specified to standardize them.
+
+# 4.1. Messages
+
+# 4.1.1. TransactionEventRequest (eventType = Started and eventType = Updated)
+
+These messages are used to notify about the start of a transaction (eventType = Started) or provide an update to an ongoing transaction (eventType = Updated). Within OCPP 2.x both start and updated natively can provide signed meter values to the CSMS, depending on the settings of the Charging Station. The configuration variables in section 4.3 are used to control when signed meter values are to be provided to the CSMS, including transaction-related start and intermediate meter values.
+
+Depending on the configured TxStartPoint and the time taken for the certified meter (or Messkapsel) to provide the signed meter data to the charging station, the location of the first signed meter value can be sent either in TransactionEventRequest (eventType = Started) or TransactionEventRequest (eventType = Updated, triggerReason = DataSigned).
+
+To deliver intermediate meter values, the TransactionEventRequest (eventType = Updated) message is used. The use of these messages is optional, based on the settings of these configuration variables (found in OCPP 2.x specification):
+
+- SampledDataTxUpdatedMeasurands
+- SampledDataTxUpdatedInterval
+- AlignedDataTxUpdatedMeasurands
+- AlignedDataTxUpdatedInterval
+
+To sign these intermediate values, the following variables may be set to true (AlignedDataSignReadings or SampledDataSignReadings are required in addition to enable the signed meter value function):
+
+- AlignedDataSignUpdatedReadings (4.3.4)
+- SampledDataSignUpdatedReadings (4.3.7)
+
+# 4.1.2. TransactionEventRequest (eventType = Ended)
+
+This message is used to notify about the completion of a transaction. When providing signed meter values (i.e., configuration variables AlignedDataSignReadings or SampledDataSignReadings are set to true) it is mandatory that within this message at least two signed meter values are present – one for the start meter value and one for the stop meter value.
+
+If the signed meter data to populate the signedMeterData field of the signed meter value of the TransactionRequestEvent (eventType = Ended) are in separate data containers (e.g., start and stop signed meter
+
+values are in separate OCMF containers), then:
+
+- The signed data for the start meter value SHALL go in a sampledValue (of SampledValueType) with context Transaction.Begin.
+- The signed data for the stop meter value SHALL go in a sampledValue (of SampledValueType) with context Transaction.End
+- And both placed in the TransactionEventRequest(Ended) meterValue field.
+
+If the signed meter data is in a single data container (e.g., both start and stop signed meter values are in one OCMF container), then:
+
+- The signed data for the meter values SHALL go in a sampledValue (of SampledValueType) with context Transaction.End
+- And placed in the TransactionEventRequest(Ended) meterValue field.
+
+# NOTE
+
+Due to the complexity of meter configurations, CSMS should be configured to flexibly handle receiving the Start and Stop meter values in the TransactionEventRequest (eventType = Ended) in the combinations outlined above.
+
+# 4.2. Data Types
+
+# 4.2.1. SignedMeterValueType
+
+This data type is to be used to complete the signedMeterValue field of the sampledValue field of the meterValue field within a TransactionEventRequest message. Figure 2 below is an extract from the OCPP 2.x specification, and Table 12 outlines the requirements per this whitepaper.
+
+Figure 2. OCPP2.0.1 Edition 3 Part 2 - Specification, chapter 2.46, page 413
+
+<table><tr><td>Field Name</td><td>Field Type</td><td>Card.</td><td>Description</td></tr><tr><td>signedMeterData</td><td>string[0..2500]</td><td>1..1</td><td>Required. Base64 encoded, contains the signed data which might contain more then just the meter value. It can contain information like timestamps, reference to a customer etc.</td></tr><tr><td>signingMethod</td><td>string[0..50]</td><td>1..1</td><td>Required. Method used to create the digital signature.</td></tr><tr><td>encodingMethod</td><td>string[0..50]</td><td>1..1</td><td>Required. Method used to encode the meter values before applying the digital signature algorithm.</td></tr><tr><td>publicKey</td><td>string[0..2500]</td><td>1..1</td><td>Required. Base64 encoded, sending depends on configuration variable PublicKeyWithSignedMeterValue.</td></tr></table>
+
+Table 11. Requirements for SignedMeterValueType
+
+<table><tr><td>Field name</td><td>Formatting Requirements</td></tr><tr><td>signedMeterData</td><td>SHALL be populated based on the requirements in Figure 2.</td></tr><tr><td>signingMethod</td><td>May already be included in the signedMeterData block (depending on the encoding format of the signed meter data). If it is already included in the signedMeterData, then this SHALL be an empty string. If not included in signedMeterData, then this field SHALL be populated. See Table 13 for value definitions.</td></tr><tr><td>encodingMethod</td><td>SHALL be populated based on the format of the meter (e.g., OCMF, EDL, etc.).</td></tr><tr><td>publicKey</td><td>SHALL be included based on the configuration of the PublicKeyWithSignedMeterValue (4.3.1) setting. If the public key is not sent with a message, it SHALL be sent as an empty string. If it is sent, it SHALL contain a Base64 encoded string with the content as specified in 3.2.2.</td></tr></table>
+
+Table 12. signingMethod values
+
+<table><tr><td>signingMethod value</td><td>Algorithm</td><td>Curve</td><td>Key Length</td><td>Hash Algorithm</td></tr><tr><td>ECDSA-secp192k1-SHA256</td><td>ECDSA</td><td>secp192k1</td><td>192 bits</td><td>SHA-256</td></tr><tr><td>ECDSA-secp256k1-SHA256</td><td>ECDSA</td><td>secp256k1</td><td>256 bits</td><td>SHA-256</td></tr><tr><td>ECDSA-secp192r1-SHA256</td><td>ECDSA</td><td>secp192r1</td><td>192 bits</td><td>SHA-256</td></tr><tr><td>ECDSA-secp256r1-SHA256</td><td>ECDSA</td><td>secp256r1</td><td>256 bits</td><td>SHA-256</td></tr><tr><td>ECDSA-brainpool256r1-SHA256</td><td>ECDSA</td><td>brainpool256r1</td><td>256 bits</td><td>SHA-256</td></tr><tr><td>ECDSA-secp384r1-SHA256</td><td>ECDSA</td><td>secp384r1</td><td>384 bits</td><td>SHA-256</td></tr><tr><td>ECDSA-brainpool384r1-SHA256</td><td>ECDSA</td><td>brainpool384r1</td><td>384 bits</td><td>SHA-256</td></tr></table>
+
+# 4.3. Configuration Variables
+
+# 4.3.1. PublicKeyWithSignedMeterValue
+
+Table 13. Configuration Variable PublicKeyWithSignedMeterValue
+
+<table><tr><td>Variable name</td><td>PublicKeyWithSignedMeterValue</td></tr><tr><td>Component</td><td>OCPPCommCtrlr</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>Enum (OptionList)</td></tr><tr><td>Description</td><td>The value may be set to the following values:
+• Never: i.e., would not be sent automatically with signed meter values. CSMS already knows the value or requests it from configuration variable "PublicKey".
+• OncePerTransaction
+• EveryMeterValue: public key in every meterValue of each TransactionEventRequest</td></tr></table>
+
+# NOTE
+
+If this variable is set to Never then in case of a meter swap, public keys associated with historical transactions (made before the meter change) will no longer be available by a GetVariablesRequest. This could be a compliance issue.
+
+# 4.3.2. PublicKey
+
+Table 14. Configuration Variable PublicKey
+
+<table><tr><td>Variable name</td><td>PublicKey</td></tr><tr><td>Component</td><td>FiscalMetering</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RO</td></tr><tr><td>Type</td><td>String</td></tr><tr><td>Description</td><td>Configuration variable that can be used to retrieve the public key for a meter connected to a specific EVSE. The value of this configuration variable SHALL be as specified in 3.2.2.</td></tr></table>
+
+# NOTE
+
+The FiscalMetering component will typically be at the EVSE-tier level. There may be one at the Charging Station tier level for the overall input of the Charging Station.
+
+# 4.3.3.AlignedDataSignReadings
+
+Table 15. Configuration Variable Associated DataSignReadings
+
+<table><tr><td>Variable name</td><td>SignReadings</td></tr><tr><td>Component</td><td>AlignedDataCtrlr</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>Boolean</td></tr><tr><td>Description</td><td>If set to true, the Charging Station SHALL include signed meter values in the TransactionRequest (eventType = Ended) to the CSMS for those measurands configured in
+AlignedDataTxEndesaMeasurands which can be signed by the certified meter, and optionally in other messages controlled by
+AlignedDataSignUpdatedReadings (see 4.3.4).</td></tr></table>
+
+# NOTE
+
+AlignedDataSignReadings globally enables or disables the transmission of signed aligned meter values. Which messages will contain signed sampled meter values, in addition to TransactionEventRequest (eventType = Ended), is controlled by the additional configuration variable AlignedDataSignUpdatedReadings, specified in this document.
+
+# 4.3.4.AlignedDataSignUpdatedReadings
+
+Table 16. Configuration Variable AlignedDataSignUpdatedReadings
+
+<table><tr><td>Variable name</td><td>SignUpdatedReadings</td></tr><tr><td>Component</td><td>AlignedDataCtrlr</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RW or RO</td></tr><tr><td>Type</td><td>Boolean</td></tr><tr><td>Description</td><td>If set to true, the Charging Station SHALL include signed meter values in the TransactionRequest (eventType = Updated) messages to the CSMS for those measurands configured in AlignedDataTxUpdatedMeasurands which can be signed by the certified meter. This variable only has an effect if AlignedDataSignReadings (4.3.3) is set to true.</td></tr></table>
+
+# 4.3.5. SampledDataSignReadings
+
+Table 17. Configuration Variable SampledDataSignReadings
+
+<table><tr><td>Variable name</td><td>SignReadings</td></tr><tr><td>Component</td><td>SampledDataCtrlr</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RW</td></tr><tr><td>Type</td><td>Boolean</td></tr><tr><td>Description</td><td>If set to true, the Charging Station SHALL include signed meter values in the TransactionRequest (eventType = Ended) message to the CSMS for those measurands configured in SampledDataTxEndedMeasurands which can be signed by the certified meter and optionally in other messages, as per SampledDataSignStartedReadings (see 4.3.6) and SampledDataSignUpdatedReadings (see 4.3.7).</td></tr></table>
+
+# NOTE
+
+SampledDataSignReadings globally enables or disables the transmission of signed sampled meter values. Which messages will contain signed sampled meter values, in addition to TransactionRequest (eventType = Started), is controlled by the configuration variables SampledDataSignStartedReadings and SampledDataSignUpdatedReadings, specified in this document.
+
+# 4.3.6. SampledDataSignStartedReadings
+
+Table 18. Configuration Variable SampledDataSignStartedReadings
+
+<table><tr><td>Variable name</td><td>SignStartedReadings</td></tr><tr><td>Component</td><td>SampledDataCtrlr</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RW or RO</td></tr><tr><td>Type</td><td>Boolean</td></tr><tr><td>Description</td><td>If set to true, the Charging Station SHALL include signed meter values in the TransactionRequest (eventType = Started or Updated) to the CSMS for those measurands configured in SampledDataTxStartedMeasurands which can be signed by the certified meter. This setting only has an effect if SampledDataSignReadings is set to true.</td></tr></table>
+
+# 4.3.7. SampledDataSignUpdatedReadings
+
+Table 19. Configuration Variable SampledDataSignUpdatedReadings
+
+<table><tr><td>Variable name</td><td>SignUpdatedReadings</td></tr><tr><td>Component</td><td>SampledDataCtrlr</td></tr><tr><td>Required/optional (for this whitepaper)</td><td>Required</td></tr><tr><td>Accessibility</td><td>RW or RO</td></tr><tr><td>Type</td><td>Boolean</td></tr><tr><td>Description</td><td>If set to true, the Charging Station SHALL include signed meter values in the TransactionRequest (eventType = Updated) messages to the CSMS for those measurands configured in SampledDataTxUpdatedMeasurands which can be signed by the certified meter. This setting only has an effect if SampledDataSignReadings is set to true.</td></tr></table>
+
+# 5. Appendix
+
+# 5.1. Configuration Key/Variable Settings Matrix
+
+Table 21 describes how the variables, when set and in what combination, affect which meter values should be signed. The upper section of the table lists the variables, and the middle section defines the output. The bottom section provides more detail on the messages involved.
+
+Table 20. Configuration Settings Matrix
+
+<table><tr><td>Configuration settings</td><td colspan="7"></td></tr><tr><td>SampledDataSignReedings</td><td></td><td>FALSE</td><td>TRUE</td><td>TRUE</td><td>TRUE</td><td>TRUE</td><td>TRUE</td></tr><tr><td>AlignedDataSignReadings</td><td></td><td>FALSE</td><td>TRUE</td><td>TRUE</td><td>TRUE</td><td>TRUE</td><td>TRUE</td></tr><tr><td></td><td colspan="7"></td></tr><tr><td>SampledDataSignStartedReadings</td><td></td><td>N/A</td><td>FALSE</td><td>TRUE</td><td>TRUE</td><td>TRUE</td><td>TRUE</td></tr><tr><td></td><td colspan="7"></td></tr><tr><td>SampledDataSignUpdatedReadings</td><td></td><td>N/A</td><td>FALSE</td><td>FALSE</td><td>TRUE</td><td>FALSE</td><td>TRUE</td></tr><tr><td>AlignedDataSignUpdatedReadings</td><td></td><td>N/A</td><td>FALSE</td><td>FALSE</td><td>FALSE</td><td>TRUE</td><td>TRUE</td></tr><tr><td>Which meter values are signed</td><td colspan="7"></td></tr><tr><td>Meter Value Context</td><td>Message</td><td>None</td><td>End Only</td><td>Start & End</td><td>Periodic Intermedi ate</td><td>Aligned Intermedi ate</td><td>Both Intermedi ate</td></tr><tr><td>Transaction.Begin</td><td>2.x: TxEvent (Started) OR 1st(Updated)1.6: MeterValuesReq</td><td>-</td><td>-</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr><tr><td>Sample.Periodic</td><td>2.x: TxEvent(Updated)1.6: MeterValuesReq</td><td>-</td><td>-</td><td>-</td><td>Y</td><td>-</td><td>Y</td></tr><tr><td>Sample.Clock</td><td>2.x: TxEvent(Updated)1.6: MeterValuesReq</td><td>-</td><td>-</td><td>-</td><td>-</td><td>Y</td><td>Y</td></tr><tr><td>Transaction.Begin & Transaction.End</td><td>2.x: TxEvent (Ended)1.6: StopTransactionReq</td><td>-</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td><td>Y</td></tr></table>
+
+# 5.2. OCPP 1.6 Example Message (Informative)
+
+An example of a StopTransaction.req with the signed meter data for both the start and end of a transaction within one OCMF container in one sampled value with context Transaction.End. The public key is also shared.
+
+[2, "729491009", "StopTransaction", \{"meterStop": 108814, "timestamp": "2023-05-19T13:55:48Z", "idTag": "HRWWBX8", "reason": "Local", "transactionData": \{\{"timestamp": "2023-05-19T13:55:48Z", "sampledValue": \{\{"format": "SignedData", "value":
+
+"\{\}"signedMeterData\":"T0NNRnx7IkZWliA6IClXLjAiLCJHSSlgOiAiRFpHLUdTSDAxLjFLMkwilLCJHUylgOiAiMURarZwMjgyMjUxNzkiLCJHVlglOiAiMjMwliwiUEciIDogllQ5Nilsk1WliA6ICJEWkciLCJNTSLgOiAiR1NIMDEuMuSyTCIslkTIa6IClxRFpHMDAyODlyNTE3OSIslk1GliA6IClYmZAiLCJJUylgOiB0cnVILCJJVCIGOiAiQ0VOVFJBTF8xliwiSUQiIDogIkhSV1dCWDiLCJDVCIGOiAiRVZTRUIEliwiQ0kiIDogljyQlozmTc4QTAICLCJSRCIGOiBbeyJUTSLgOiAiMjAyMy0wnNS0xOVQxNTo1MjoZOSwwMDArMDlwMCBJliwiVFgilDoglkIIcLCJSVlgOiAiMC4wMDAiLCJSSSLgOiAiMDEtMDA6OTguMDguMDAuRkyiLCJSVlgOiAiia1doliwiUIQilDoglkRIWUUYiIDoglilsINULiA6ICJHIn0seyJUTSLgOiAiMjAyMy0wnNS0xOVQxNTo1MzO1OCwwMDArMDlwMCBJliwiVFgilDoglkUlcSJVlgOiAiMC42MzYiLCJSSSLgOiAiMDEtMDA6OTguMDguMDAuRkYiLCJSVlgOiAiia1doliwiUIQilDoglkRIWUUYiIDoglilsINULiA6ICJHIn1dLCJVliA6IFt7IIRNliA6IClcyMDIZLTA1LTE5VDE1OjUoyM5LDAwMCswMjAwIEklCJUWCIGOiAiQiIsllWliA6IClXMDguMTc4liwiUkkilDogljAxLTAwOjLDjA4LjAwLkZGliwiUIUilDogImtXlIJU3ICJEQylsIKVGliA6IClLCJTVCIGOiAiRyJ9LHsiVE0iIDogIqwMjMtMDUtMTIUMTU6NTM6NTgsMDAwKzAyMDAgSSIsllRYliA6ICJFliwiUIYiIDogljewOC44MTQiLCJSSSLgOiAiMDEtMDA6OUMmuMDguMDAuRkYiLCJSVlgOiAiia1doliwiUIQilDoglkRIWlRUYiIDoglilsINULiA6ICJHIn0seyJUTSLgOiAiMjAyMy0wnNS0xOVQxNTo1MjoZOSwwMDArMDlwMCBJliwiVFgilDoglkIIcLCJSVlgOiAiMC4wMDIyiWiUkkilIDogljAxLTAwOjhDLjA3LjAwLkZGliwiUIUilDoglk9obSlSIlJIUIA6ICJEQylsIKVGliA6IClLCJTVCIGOiAiRyJ9LHsiVE0iIDogIqwMjMtMDUtMTIUMTU6NTM6NTgsMDAwKzAyMDAgSSIsllRYliA6ICJFliwiUIYiIDogljxc5lpiWiUkkilDogljAxLTAwOjAwLjA4LjA2LkZGliwiUIUilDogInMiLCJSVCIGOiAiREMiLCJFrlgOiAiiwiUQIDoglkfcifV19fHsiU0EiIDogIkvDRFNBLXNIY3AyNTZrMS1TSEEyNTYlCCJTRCLGoiAiMzAONTAYMjEweMQwMOYZMTIDN0FEMDHBRDRGNTA3Q0FGRUYxNjZGRku1Rku1NTc3OEi4Njg2NzYyNqRxRy2RERDMDgoRTMyQTcwMjlwNjM1QTg5MzZGRTZDNjFBQUNFQ0JGQURFOTY2MzYyQkQxNLIwOEFFRjEwOTM5ODk2NDBGQUJBREMzNDEOMku1Mij9\","encodingMethod\":"OCMF\"
+
+```java
+"MzA1NjMwMTAwNjA3MkE4NjQ4Q0UzRDAyMDEwNjA1Mkl4MTA0MDAwQTAzNDlWMDA0MEE4O
+DUyN0UyM0VEODcxMTE3NDkxQkQ0MzVEQTA0ODA0MUFBRjICMzcxRjZBNUMQzAOERDRDU5OUQ5NjIDMOE
+wRUNCRjc3MzcwRjlzMjA4RTdDQTAzQkQzNTMwNONCNDJGNTkwNEE5Qzc1Qkl3RDgxxQxQzA1MzQ2N0Y1NTg=\}
+"}", "location": "Outlet", "context": "Transaction.End", "measurand": "Energy.Active.Importantly:tRegister", "unit": "Wh}")]}, "transactionId": 1745412560}
+
+# 5.3. Example publicKey Value Composition (Informative)
+
+1. Public key printed on the certified meter (ASN.1 structure containing key algorithm and parameters as well as the actual key):
+3056301006072a8648ce3d020106052b8104000a03420004460a02ba2766d9c44f023ecc0e4e58644a87add1aadd 6317e5fe4dccdb29b163a01d8a6297c84bc530f86431e92f8d46ab37830247c05cbd92fac252929e7f61
+2. Prefix with metadata:
+
+oca:base16:asn1:3056301006072a8648ce3d020106052b8104000a03420004460a02ba2766d9c44f023ecc0e4e58 644a87add1aadd6317e5fe4dcbd29b163a01d8a6297c84bc530f86431e92f8d46ab37830247c05cbd92fac252929 e7f61
+
+3. Base64 encode to the string to put in the publicKey field:
+
+b2NhOmJhc2UxnNjphc24xOjMwNTYzMDEewMDYwNzJhODY0OGNIM2QwMjAxMDYwNTJiODEewNDAwMGEwMzQy
+MDAwNDQ2MGEewMmJhMjc2NmQ5YzQ0ZjAyM2VjYZBINGU1ODY0NGE4N2FkZDFhYWRkNjMxN2U1ZmU0ZGNjZG
+lyOWlNxNjNhMDFkOGE2Mjk3Yzg0YmM1MzBmODY0MzFIOTJmOGQ0NmFiMzc4MzAyNDdjMDVjYmQ5MmZhYzl1M
+jkyOWU3ZjYx
+```
'SECC',
'Secc',
'Overcurrent',
+ 'ocsp',
'OCSP',
'EMAID',
'emaid',
'IDTOKEN',
'idtoken',
+ 'issuerkeyhash',
+ 'issuernamehash',
],
},
},
--- /dev/null
+// Copyright Jerome Benoit. 2021-2025. All Rights Reserved.
+
+import { createHash, X509Certificate } from 'node:crypto'
+import { mkdir, readdir, readFile, rm, stat, writeFile } from 'node:fs/promises'
+import { join, resolve, sep } from 'node:path'
+
+import type { ChargingStation } from '../../ChargingStation.js'
+
+import {
+ type CertificateHashDataChainType,
+ type CertificateHashDataType,
+ CertificateSigningUseEnumType,
+ DeleteCertificateStatusEnumType,
+ GetCertificateIdUseEnumType,
+ HashAlgorithmEnumType,
+ InstallCertificateUseEnumType,
+} from '../../../types/ocpp/2.0/Common.js'
+
+/**
+ * Interface for ChargingStation with certificate manager
+ */
+export interface ChargingStationWithCertificateManager extends ChargingStation {
+ certificateManager: OCPP20CertificateManagerInterface
+}
+
+/**
+ * Result type for certificate deletion operations
+ */
+export interface DeleteCertificateResult {
+ status: DeleteCertificateStatusEnumType
+}
+
+/**
+ * Result type for getting installed certificates
+ */
+export interface GetInstalledCertificatesResult {
+ certificateHashDataChain: CertificateHashDataChainType[]
+}
+
+/**
+ * Interface for OCPP 2.0 Certificate Manager operations
+ * Used for type-safe access to certificate management functionality
+ */
+export interface OCPP20CertificateManagerInterface {
+ deleteCertificate(
+ stationHashId: string,
+ hashData: CertificateHashDataType
+ ): DeleteCertificateResult | Promise<DeleteCertificateResult>
+ getInstalledCertificates(
+ stationHashId: string,
+ filterTypes?: InstallCertificateUseEnumType[]
+ ): GetInstalledCertificatesResult | Promise<GetInstalledCertificatesResult>
+ storeCertificate(
+ stationHashId: string,
+ certType: CertificateSigningUseEnumType | InstallCertificateUseEnumType,
+ pemData: string
+ ): Promise<StoreCertificateResult> | StoreCertificateResult
+ validateCertificateFormat(pemData: unknown): boolean
+}
+
+/**
+ * Result type for certificate storage operations
+ */
+export interface StoreCertificateResult {
+ error?: string
+ filePath?: string
+ success: boolean
+}
+
+/**
+ * OCPP 2.0 Certificate Manager
+ *
+ * Provides certificate management operations for OCPP 2.0 charging stations:
+ * - Store/delete certificates
+ * - Compute certificate hashes
+ * - Validate certificate format
+ * - Manage certificate storage paths
+ */
+export class OCPP20CertificateManager {
+ private static readonly BASE_CERT_PATH = 'dist/assets/configurations'
+ private static readonly CERT_FOLDER = 'certs'
+ private static readonly PEM_BEGIN_MARKER = '-----BEGIN CERTIFICATE-----'
+ private static readonly PEM_END_MARKER = '-----END CERTIFICATE-----'
+
+ /**
+ * Computes hash data for a PEM certificate per RFC 6960 Section 4.1.1 CertID semantics
+ *
+ * Per RFC 6960, the CertID identifies a certificate by:
+ * - issuerNameHash: Hash of the issuer's DN (from the subject certificate)
+ * - issuerKeyHash: Hash of the issuer's public key (from the issuer certificate)
+ * - serialNumber: The certificate's serial number
+ * @param pemData - PEM-encoded certificate data
+ * @param hashAlgorithm - Hash algorithm to use (default: SHA256)
+ * @param issuerCertPem - Optional PEM-encoded issuer certificate for issuerKeyHash computation.
+ * If not provided, attempts to detect self-signed certificates (issuer = subject)
+ * and uses the subject certificate's public key. For non-self-signed certificates
+ * without an issuer cert, uses the subject's public key as fallback.
+ * @returns Certificate hash data including issuerNameHash, issuerKeyHash, serialNumber
+ * @throws {Error} If PEM format is invalid or certificate cannot be parsed
+ */
+ public computeCertificateHash (
+ pemData: string,
+ hashAlgorithm: HashAlgorithmEnumType = HashAlgorithmEnumType.SHA256,
+ issuerCertPem?: string
+ ): CertificateHashDataType {
+ if (!this.validateCertificateFormat(pemData)) {
+ throw new Error('Invalid PEM certificate format')
+ }
+
+ const algorithmName = this.getHashAlgorithmName(hashAlgorithm)
+
+ try {
+ const firstCertPem = this.extractFirstCertificate(pemData)
+ const x509 = new X509Certificate(firstCertPem)
+
+ // RFC 6960 4.1.1: issuerNameHash is the hash of the issuer's DN from the subject certificate
+ // Node.js X509Certificate.issuer provides the string representation of the issuer DN
+ const issuerNameHash = createHash(algorithmName).update(x509.issuer).digest('hex')
+
+ // RFC 6960 4.1.1: issuerKeyHash is the hash of the issuer certificate's public key
+ // Determine which public key to use for issuerKeyHash
+ let issuerPublicKeyDer: Buffer
+
+ if (issuerCertPem != null && this.validateCertificateFormat(issuerCertPem)) {
+ // Use provided issuer certificate's public key
+ const issuerCert = new X509Certificate(this.extractFirstCertificate(issuerCertPem))
+ issuerPublicKeyDer = issuerCert.publicKey.export({
+ format: 'der',
+ type: 'spki',
+ }) as Buffer
+ } else if (this.isSelfSignedCertificate(x509)) {
+ // Self-signed certificate: issuer = subject, use the certificate's own public key
+ issuerPublicKeyDer = x509.publicKey.export({
+ format: 'der',
+ type: 'spki',
+ }) as Buffer
+ } else {
+ // Non-self-signed without issuer cert: use subject's public key as fallback
+ // This is technically incorrect per RFC 6960 but maintains backward compatibility
+ issuerPublicKeyDer = x509.publicKey.export({
+ format: 'der',
+ type: 'spki',
+ }) as Buffer
+ }
+
+ const issuerKeyHash = createHash(algorithmName).update(issuerPublicKeyDer).digest('hex')
+
+ const serialNumber = x509.serialNumber
+
+ return {
+ hashAlgorithm,
+ issuerKeyHash,
+ issuerNameHash,
+ serialNumber,
+ }
+ } catch {
+ // Fallback for PEM data that cannot be parsed by X509Certificate
+ // Compute hashes from the raw certificate content
+ return this.computeFallbackCertificateHash(pemData, hashAlgorithm, algorithmName)
+ }
+ }
+
+ /**
+ * Deletes a certificate by its hash data
+ * @param stationHashId - Charging station unique identifier
+ * @param hashData - Certificate hash data identifying the certificate to delete
+ * @returns Delete operation result with status
+ */
+ public async deleteCertificate (
+ stationHashId: string,
+ hashData: CertificateHashDataType
+ ): Promise<DeleteCertificateResult> {
+ try {
+ const basePath = this.getStationCertificatesBasePath(stationHashId)
+
+ if (!(await this.pathExists(basePath))) {
+ return { status: DeleteCertificateStatusEnumType.NotFound }
+ }
+
+ const certTypeEntries = await readdir(basePath, { withFileTypes: true })
+ const certTypes = certTypeEntries
+ .filter(dirent => dirent.isDirectory())
+ .map(dirent => dirent.name)
+
+ for (const certType of certTypes) {
+ const certTypeDir = join(basePath, certType)
+ const allFiles = await readdir(certTypeDir)
+ const files = allFiles.filter(f => f.endsWith('.pem'))
+
+ for (const file of files) {
+ const filePath = join(certTypeDir, file)
+ this.validateCertificatePath(filePath, OCPP20CertificateManager.BASE_CERT_PATH)
+ try {
+ const pemData = await readFile(filePath, 'utf8')
+ const certHash = this.computeCertificateHash(pemData, hashData.hashAlgorithm)
+
+ if (
+ certHash.serialNumber === hashData.serialNumber &&
+ certHash.issuerNameHash === hashData.issuerNameHash &&
+ certHash.issuerKeyHash === hashData.issuerKeyHash
+ ) {
+ await rm(filePath)
+ return { status: DeleteCertificateStatusEnumType.Accepted }
+ }
+ } catch {
+ // Skip unreadable or unparsable certificate file
+ }
+ }
+ }
+
+ return { status: DeleteCertificateStatusEnumType.NotFound }
+ } catch {
+ // Certificate directory access or validation failed
+ return { status: DeleteCertificateStatusEnumType.Failed }
+ }
+ }
+
+ /**
+ * Gets the filesystem path for a certificate
+ * @param stationHashId - Charging station unique identifier
+ * @param certType - Certificate type (e.g., CSMSRootCertificate, ChargingStationCertificate)
+ * @param serialNumber - Certificate serial number
+ * @returns Full path where the certificate should be stored
+ */
+ public getCertificatePath (
+ stationHashId: string,
+ certType: CertificateSigningUseEnumType | InstallCertificateUseEnumType,
+ serialNumber: string
+ ): string {
+ const basePath = this.getStationCertificatesBasePath(stationHashId)
+ const sanitizedSerial = this.sanitizeSerial(serialNumber)
+ return join(basePath, certType, `${sanitizedSerial}.pem`)
+ }
+
+ /**
+ * Gets installed certificates for a charging station
+ * @param stationHashId - Charging station unique identifier
+ * @param filterTypes - Optional array of certificate types to filter
+ * @returns List of installed certificate hash data chains
+ */
+ public async getInstalledCertificates (
+ stationHashId: string,
+ filterTypes?: InstallCertificateUseEnumType[]
+ ): Promise<GetInstalledCertificatesResult> {
+ const certificateHashDataChain: CertificateHashDataChainType[] = []
+
+ try {
+ const basePath = this.getStationCertificatesBasePath(stationHashId)
+
+ if (!(await this.pathExists(basePath))) {
+ return { certificateHashDataChain }
+ }
+
+ const certTypeEntries = await readdir(basePath, { withFileTypes: true })
+ const certTypes = certTypeEntries
+ .filter(dirent => dirent.isDirectory())
+ .map(dirent => dirent.name)
+
+ for (const certType of certTypes) {
+ if (filterTypes != null && filterTypes.length > 0) {
+ if (!filterTypes.includes(certType as InstallCertificateUseEnumType)) {
+ continue
+ }
+ }
+
+ const certTypeDir = join(basePath, certType)
+ const allFiles = await readdir(certTypeDir)
+ const files = allFiles.filter(f => f.endsWith('.pem'))
+
+ for (const file of files) {
+ const filePath = join(certTypeDir, file)
+ this.validateCertificatePath(filePath, OCPP20CertificateManager.BASE_CERT_PATH)
+ try {
+ const pemData = await readFile(filePath, 'utf8')
+ const hashData = this.computeCertificateHash(pemData)
+
+ certificateHashDataChain.push({
+ certificateHashData: hashData,
+ certificateType: this.mapInstallTypeToGetType(
+ certType as InstallCertificateUseEnumType
+ ),
+ })
+ } catch {
+ // Skip unreadable or unparsable certificate file
+ continue
+ }
+ }
+ }
+ } catch {
+ // Ignore directory listing errors - return empty result
+ }
+ return { certificateHashDataChain }
+ }
+
+ /**
+ * Stores a PEM certificate to the filesystem
+ * @param stationHashId - Charging station unique identifier
+ * @param certType - Certificate type for storage (InstallCertificateUseEnumType for root certificates
+ * or CertificateSigningUseEnumType for signed leaf certificates)
+ * @param pemData - PEM-encoded certificate data
+ * @returns Storage result with success status and file path or error
+ */
+ public async storeCertificate (
+ stationHashId: string,
+ certType: CertificateSigningUseEnumType | InstallCertificateUseEnumType,
+ pemData: string
+ ): Promise<StoreCertificateResult> {
+ if (!this.validateCertificateFormat(pemData)) {
+ return {
+ error: 'Invalid PEM format: Certificate must have valid BEGIN and END markers',
+ success: false,
+ }
+ }
+
+ try {
+ const firstCertPem = this.extractFirstCertificate(pemData)
+ let serialNumber: string
+
+ try {
+ const hashData = this.computeCertificateHash(firstCertPem)
+ serialNumber = hashData.serialNumber
+ } catch {
+ // X509 parsing failed, generate fallback serial from content hash
+ serialNumber = this.generateFallbackSerialNumber(firstCertPem)
+ }
+
+ const filePath = this.getCertificatePath(stationHashId, certType, serialNumber)
+
+ this.validateCertificatePath(filePath, OCPP20CertificateManager.BASE_CERT_PATH)
+
+ const dirPath = resolve(filePath, '..')
+ if (!(await this.pathExists(dirPath))) {
+ await mkdir(dirPath, { recursive: true })
+ }
+
+ await writeFile(filePath, pemData, 'utf8')
+
+ return {
+ filePath,
+ success: true,
+ }
+ } catch (error) {
+ return {
+ error: `Failed to store certificate: ${(error as Error).message}`,
+ success: false,
+ }
+ }
+ }
+
+ /**
+ * Validates PEM certificate format
+ * @param pemData - PEM data to validate
+ * @returns true if valid PEM certificate format, false otherwise
+ */
+ public validateCertificateFormat (pemData: unknown): boolean {
+ if (pemData == null || typeof pemData !== 'string') {
+ return false
+ }
+
+ if (pemData.trim().length === 0) {
+ return false
+ }
+
+ const trimmed = pemData.trim()
+
+ return (
+ trimmed.includes(OCPP20CertificateManager.PEM_BEGIN_MARKER) &&
+ trimmed.includes(OCPP20CertificateManager.PEM_END_MARKER)
+ )
+ }
+
+ /**
+ * Computes fallback hash data when X509Certificate parsing fails.
+ * Uses the raw PEM content to derive hash values.
+ * @param pemData - PEM-encoded certificate data
+ * @param hashAlgorithm - Hash algorithm enum type for the response
+ * @param algorithmName - Node.js crypto hash algorithm name
+ * @returns Certificate hash data derived from raw PEM content
+ */
+ private computeFallbackCertificateHash (
+ pemData: string,
+ hashAlgorithm: HashAlgorithmEnumType,
+ algorithmName: string
+ ): CertificateHashDataType {
+ // Extract the base64 content between PEM markers
+ const base64Content = pemData
+ .replace(/-----BEGIN CERTIFICATE-----/, '')
+ .replace(/-----END CERTIFICATE-----/, '')
+ .replace(/\s/g, '')
+
+ // Compute hashes from the certificate content
+ const contentBuffer = Buffer.from(base64Content, 'base64')
+ const issuerNameHash = createHash(algorithmName)
+ .update(contentBuffer.subarray(0, Math.min(64, contentBuffer.length)))
+ .digest('hex')
+ const issuerKeyHash = createHash(algorithmName).update(contentBuffer).digest('hex')
+
+ // Generate a serial number from the content hash
+ const serialNumber = createHash('sha256')
+ .update(pemData)
+ .digest('hex')
+ .substring(0, 16)
+ .toUpperCase()
+
+ return {
+ hashAlgorithm,
+ issuerKeyHash,
+ issuerNameHash,
+ serialNumber,
+ }
+ }
+
+ private extractFirstCertificate (pemData: string): string {
+ const beginIndex = pemData.indexOf(OCPP20CertificateManager.PEM_BEGIN_MARKER)
+ const endIndex = pemData.indexOf(OCPP20CertificateManager.PEM_END_MARKER)
+
+ if (beginIndex === -1 || endIndex === -1) {
+ return pemData
+ }
+
+ return pemData.substring(beginIndex, endIndex + OCPP20CertificateManager.PEM_END_MARKER.length)
+ }
+
+ private generateFallbackSerialNumber (pemData: string): string {
+ return createHash('sha256').update(pemData).digest('hex').substring(0, 16).toUpperCase()
+ }
+
+ private getHashAlgorithmName (hashAlgorithm: HashAlgorithmEnumType): string {
+ switch (hashAlgorithm) {
+ case HashAlgorithmEnumType.SHA256:
+ return 'sha256'
+ case HashAlgorithmEnumType.SHA384:
+ return 'sha384'
+ case HashAlgorithmEnumType.SHA512:
+ return 'sha512'
+ default:
+ return 'sha256'
+ }
+ }
+
+ /**
+ * Builds and validates the base certificates directory path for a station.
+ * @param stationHashId - Charging station unique identifier
+ * @returns Validated base path for certificate storage
+ * @throws {Error} If path validation fails (path traversal attempt)
+ */
+ private getStationCertificatesBasePath (stationHashId: string): string {
+ const sanitizedHashId = this.sanitizePath(stationHashId)
+ const basePath = join(
+ OCPP20CertificateManager.BASE_CERT_PATH,
+ sanitizedHashId,
+ OCPP20CertificateManager.CERT_FOLDER
+ )
+ this.validateCertificatePath(basePath, OCPP20CertificateManager.BASE_CERT_PATH)
+ return basePath
+ }
+
+ private isSelfSignedCertificate (x509: X509Certificate): boolean {
+ return x509.issuer === x509.subject
+ }
+
+ private mapInstallTypeToGetType (
+ installType: InstallCertificateUseEnumType
+ ): GetCertificateIdUseEnumType {
+ switch (installType) {
+ case InstallCertificateUseEnumType.CSMSRootCertificate:
+ return GetCertificateIdUseEnumType.CSMSRootCertificate
+ case InstallCertificateUseEnumType.ManufacturerRootCertificate:
+ return GetCertificateIdUseEnumType.ManufacturerRootCertificate
+ case InstallCertificateUseEnumType.MORootCertificate:
+ return GetCertificateIdUseEnumType.MORootCertificate
+ case InstallCertificateUseEnumType.V2GRootCertificate:
+ return GetCertificateIdUseEnumType.V2GRootCertificate
+ default:
+ return GetCertificateIdUseEnumType.CSMSRootCertificate
+ }
+ }
+
+ private async pathExists (path: string): Promise<boolean> {
+ try {
+ await stat(path)
+ return true
+ } catch {
+ // Path does not exist or is inaccessible
+ return false
+ }
+ }
+
+ private sanitizePath (input: string): string {
+ return input
+ .replace(/\.\./g, '_')
+ .replace(/[/\\]/g, '_')
+ .replace(/[<>:"|?*]/g, '_')
+ }
+
+ private sanitizeSerial (serial: string): string {
+ return serial.replace(/:/g, '-').replace(/[/\\<>"|?*]/g, '_')
+ }
+
+ private validateCertificatePath (certificateFileName: string, baseDir: string): string {
+ const baseResolved = resolve(baseDir)
+ const fileResolved = resolve(baseDir, certificateFileName)
+
+ // Check if resolved path is within the base directory
+ if (!fileResolved.startsWith(baseResolved + sep) && fileResolved !== baseResolved) {
+ throw new Error(
+ `Path traversal attempt detected: certificate path '${certificateFileName}' resolves outside base directory`
+ )
+ }
+
+ return fileResolved
+ }
+}
+
+/**
+ * Type guard to check if a charging station has a certificate manager
+ * @param chargingStation - The charging station to check
+ * @returns true if the charging station has a certificate manager
+ */
+export function hasCertificateManager (
+ chargingStation: ChargingStation
+): chargingStation is ChargingStationWithCertificateManager {
+ return (
+ 'certificateManager' in chargingStation &&
+ chargingStation.certificateManager != null &&
+ typeof (chargingStation as ChargingStationWithCertificateManager).certificateManager
+ .validateCertificateFormat === 'function'
+ )
+}
+// Partial Copyright Jerome Benoit. 2021-2025. All Rights Reserved.
+
import type { ValidateFunction } from 'ajv'
import { secondsToMilliseconds } from 'date-fns'
import type {
OCPP20ChargingProfileType,
OCPP20ChargingScheduleType,
- OCPP20TransactionContext,
+ OCPP20IdTokenType,
} from '../../../types/ocpp/2.0/Transaction.js'
import { OCPPError } from '../../../exception/index.js'
import {
AttributeEnumType,
+ CertificateSigningUseEnumType,
ConnectorEnumType,
ConnectorStatusEnum,
DataEnumType,
+ DeleteCertificateStatusEnumType,
ErrorType,
FirmwareStatus,
GenericDeviceModelStatusEnumType,
GenericStatus,
+ GetCertificateIdUseEnumType,
+ GetInstalledCertificateStatusEnumType,
GetVariableStatusEnumType,
type IncomingRequestHandler,
+ InstallCertificateStatusEnumType,
+ InstallCertificateUseEnumType,
type JsonType,
+ type OCPP20CertificateSignedRequest,
+ type OCPP20CertificateSignedResponse,
type OCPP20ClearCacheResponse,
OCPP20ComponentName,
OCPP20ConnectorStatusEnumType,
+ type OCPP20DeleteCertificateRequest,
+ type OCPP20DeleteCertificateResponse,
OCPP20DeviceInfoVariableName,
type OCPP20GetBaseReportRequest,
type OCPP20GetBaseReportResponse,
+ type OCPP20GetInstalledCertificateIdsRequest,
+ type OCPP20GetInstalledCertificateIdsResponse,
type OCPP20GetVariablesRequest,
type OCPP20GetVariablesResponse,
OCPP20IncomingRequestCommand,
+ type OCPP20InstallCertificateRequest,
+ type OCPP20InstallCertificateResponse,
type OCPP20NotifyReportRequest,
type OCPP20NotifyReportResponse,
OCPP20RequestCommand,
type OCPP20ResetResponse,
type OCPP20SetVariablesRequest,
type OCPP20SetVariablesResponse,
- OCPP20TransactionEventEnumType,
OCPPVersion,
ReasonCodeEnumType,
ReportBaseEnumType,
generateUUID,
isAsyncFunction,
logger,
- validateIdentifierString,
+ validateUUID,
} from '../../../utils/index.js'
import { getConfigurationKey } from '../../ConfigurationKeyUtils.js'
-import { hasReservationExpired, resetConnectorStatus } from '../../Helpers.js'
+import { getIdTagsFile, hasReservationExpired, resetConnectorStatus } from '../../Helpers.js'
import { OCPPAuthServiceFactory } from '../auth/services/OCPPAuthServiceFactory.js'
import { OCPPIncomingRequestService } from '../OCPPIncomingRequestService.js'
+import { restoreConnectorStatus, sendAndSetConnectorStatus } from '../OCPPServiceUtils.js'
import {
- OCPPServiceUtils,
- restoreConnectorStatus,
- sendAndSetConnectorStatus,
-} from '../OCPPServiceUtils.js'
+ type GetInstalledCertificatesResult,
+ hasCertificateManager,
+ type StoreCertificateResult,
+} from './OCPP20CertificateManager.js'
import { OCPP20Constants } from './OCPP20Constants.js'
import { OCPP20ServiceUtils } from './OCPP20ServiceUtils.js'
import { OCPP20VariableManager } from './OCPP20VariableManager.js'
super(OCPPVersion.VERSION_201)
this.reportDataCache = new Map<number, ReportDataType[]>()
this.incomingRequestHandlers = new Map<OCPP20IncomingRequestCommand, IncomingRequestHandler>([
+ [
+ OCPP20IncomingRequestCommand.CERTIFICATE_SIGNED,
+ this.handleRequestCertificateSigned.bind(this) as unknown as IncomingRequestHandler,
+ ],
[
OCPP20IncomingRequestCommand.CLEAR_CACHE,
this.handleRequestClearCache.bind(this) as unknown as IncomingRequestHandler,
],
+ [
+ OCPP20IncomingRequestCommand.DELETE_CERTIFICATE,
+ this.handleRequestDeleteCertificate.bind(this) as unknown as IncomingRequestHandler,
+ ],
[
OCPP20IncomingRequestCommand.GET_BASE_REPORT,
this.handleRequestGetBaseReport.bind(this) as unknown as IncomingRequestHandler,
],
+
+ [
+ OCPP20IncomingRequestCommand.GET_INSTALLED_CERTIFICATE_IDS,
+ this.handleRequestGetInstalledCertificateIds.bind(
+ this
+ ) as unknown as IncomingRequestHandler,
+ ],
[
OCPP20IncomingRequestCommand.GET_VARIABLES,
this.handleRequestGetVariables.bind(this) as unknown as IncomingRequestHandler,
],
+ [
+ OCPP20IncomingRequestCommand.INSTALL_CERTIFICATE,
+ this.handleRequestInstallCertificate.bind(this) as unknown as IncomingRequestHandler,
+ ],
[
OCPP20IncomingRequestCommand.REQUEST_START_TRANSACTION,
this.handleRequestStartTransaction.bind(this) as unknown as IncomingRequestHandler,
return reportData
}
- /**
- * Get the TxUpdatedInterval value from the variable manager.
- * This is used to determine the interval at which TransactionEvent(Updated) messages are sent.
- * @param chargingStation - The charging station instance
- * @returns The TxUpdatedInterval in milliseconds
- */
private getTxUpdatedInterval (chargingStation: ChargingStation): number {
const variableManager = OCPP20VariableManager.getInstance()
const results = variableManager.getVariables(chargingStation, [
}
/**
- * Handles OCPP 2.0 Reset request from central system with enhanced EVSE-specific support
- * Initiates station or EVSE reset based on request parameters and transaction states
+ * Handles OCPP 2.0 CertificateSigned request from central system
+ * Receives signed certificate chain from CSMS and stores it in the charging station
+ * Triggers websocket reconnect for ChargingStationCertificate type to use the new certificate
* @param chargingStation - The charging station instance processing the request
- * @param commandPayload - Reset request payload with type and optional EVSE ID
- * @returns Promise resolving to ResetResponse indicating operation status
+ * @param commandPayload - CertificateSigned request payload with certificate chain and type
+ * @returns Promise resolving to CertificateSignedResponse indicating operation status
*/
+ private async handleRequestCertificateSigned (
+ chargingStation: ChargingStation,
+ commandPayload: OCPP20CertificateSignedRequest
+ ): Promise<OCPP20CertificateSignedResponse> {
+ const { certificateChain, certificateType } = commandPayload
+
+ if (!hasCertificateManager(chargingStation)) {
+ logger.error(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestCertificateSigned: Certificate manager not available`
+ )
+ return {
+ status: GenericStatus.Rejected,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InternalError,
+ },
+ }
+ }
+
+ // Validate certificate chain format
+ if (!chargingStation.certificateManager.validateCertificateFormat(certificateChain)) {
+ logger.warn(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestCertificateSigned: Invalid PEM format for certificate chain`
+ )
+ return {
+ status: GenericStatus.Rejected,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InvalidCertificate,
+ },
+ }
+ }
+
+ // Store certificate chain
+ try {
+ const result = chargingStation.certificateManager.storeCertificate(
+ chargingStation.stationInfo?.hashId ?? '',
+ certificateType ?? CertificateSigningUseEnumType.ChargingStationCertificate,
+ certificateChain
+ )
+
+ // Handle both Promise and synchronous returns, and both boolean and object results
+ const storeResult = result instanceof Promise ? await result : result
+
+ // Handle both boolean (test mock) and object (real implementation) results
+ const success = typeof storeResult === 'boolean' ? storeResult : storeResult.success
+
+ if (!success) {
+ logger.warn(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestCertificateSigned: Certificate chain storage rejected`
+ )
+ return {
+ status: GenericStatus.Rejected,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InvalidCertificate,
+ },
+ }
+ }
+
+ // For ChargingStationCertificate, trigger websocket reconnect to use the new certificate
+ const effectiveCertificateType =
+ certificateType ?? CertificateSigningUseEnumType.ChargingStationCertificate
+ if (effectiveCertificateType === CertificateSigningUseEnumType.ChargingStationCertificate) {
+ logger.info(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestCertificateSigned: Triggering websocket reconnect to use new ChargingStationCertificate`
+ )
+ chargingStation.closeWSConnection()
+ }
+
+ logger.info(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestCertificateSigned: Certificate chain stored successfully`
+ )
+ return {
+ status: GenericStatus.Accepted,
+ }
+ } catch (error) {
+ logger.error(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestCertificateSigned: Certificate chain storage failed`,
+ error
+ )
+ return {
+ status: GenericStatus.Rejected,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.OutOfStorage,
+ },
+ }
+ }
+ }
+
+ /**
+ * Handles OCPP 2.0 DeleteCertificate request from central system
+ * Deletes a certificate matching the provided hash data from the charging station
+ * @param chargingStation - The charging station instance processing the request
+ * @param commandPayload - DeleteCertificate request payload with certificate hash data
+ * @returns Promise resolving to DeleteCertificateResponse with status
+ */
+ private async handleRequestDeleteCertificate (
+ chargingStation: ChargingStation,
+ commandPayload: OCPP20DeleteCertificateRequest
+ ): Promise<OCPP20DeleteCertificateResponse> {
+ const { certificateHashData } = commandPayload
+
+ if (!hasCertificateManager(chargingStation)) {
+ logger.error(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestDeleteCertificate: Certificate manager not available`
+ )
+ return {
+ status: DeleteCertificateStatusEnumType.Failed,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InternalError,
+ },
+ }
+ }
+
+ try {
+ const result = chargingStation.certificateManager.deleteCertificate(
+ chargingStation.stationInfo?.hashId ?? '',
+ certificateHashData
+ )
+
+ // Handle both Promise and synchronous returns
+ const deleteResult = result instanceof Promise ? await result : result
+
+ // Check the status field for the result
+ if (deleteResult.status === DeleteCertificateStatusEnumType.NotFound) {
+ logger.info(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestDeleteCertificate: Certificate not found`
+ )
+ return {
+ status: DeleteCertificateStatusEnumType.NotFound,
+ }
+ }
+
+ if (deleteResult.status === DeleteCertificateStatusEnumType.Accepted) {
+ logger.info(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestDeleteCertificate: Certificate deleted successfully`
+ )
+ return {
+ status: DeleteCertificateStatusEnumType.Accepted,
+ }
+ }
+
+ // Failed status
+ return {
+ status: DeleteCertificateStatusEnumType.Failed,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InternalError,
+ },
+ }
+ } catch (error) {
+ logger.error(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestDeleteCertificate: Certificate deletion failed`,
+ error
+ )
+ return {
+ status: DeleteCertificateStatusEnumType.Failed,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InternalError,
+ },
+ }
+ }
+ }
private handleRequestGetBaseReport (
chargingStation: ChargingStation,
}
}
+ /**
+ * Handles OCPP 2.0 GetInstalledCertificateIds request from central system
+ * Returns list of installed certificates matching the optional filter types
+ * @param chargingStation - The charging station instance processing the request
+ * @param commandPayload - GetInstalledCertificateIds request payload with optional certificate type filter
+ * @returns Promise resolving to GetInstalledCertificateIdsResponse with status and certificate chain data
+ */
+ private async handleRequestGetInstalledCertificateIds (
+ chargingStation: ChargingStation,
+ commandPayload: OCPP20GetInstalledCertificateIdsRequest
+ ): Promise<OCPP20GetInstalledCertificateIdsResponse> {
+ const { certificateType } = commandPayload
+
+ if (!hasCertificateManager(chargingStation)) {
+ logger.error(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestGetInstalledCertificateIds: Certificate manager not available`
+ )
+ return {
+ status: GetInstalledCertificateStatusEnumType.NotFound,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InternalError,
+ },
+ }
+ }
+
+ try {
+ const filterTypes = certificateType?.map(ct => {
+ if (ct === GetCertificateIdUseEnumType.V2GCertificateChain) {
+ return InstallCertificateUseEnumType.V2GRootCertificate
+ }
+ return ct as unknown as InstallCertificateUseEnumType
+ })
+
+ const methodResult = chargingStation.certificateManager.getInstalledCertificates(
+ chargingStation.stationInfo?.hashId ?? '',
+ filterTypes
+ )
+ const result: GetInstalledCertificatesResult =
+ methodResult instanceof Promise ? await methodResult : methodResult
+
+ logger.info(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestGetInstalledCertificateIds: Retrieved ${String(result.certificateHashDataChain.length)} certificates`
+ )
+
+ return {
+ certificateHashDataChain:
+ result.certificateHashDataChain.length > 0 ? result.certificateHashDataChain : undefined,
+ status:
+ result.certificateHashDataChain.length > 0
+ ? GetInstalledCertificateStatusEnumType.Accepted
+ : GetInstalledCertificateStatusEnumType.NotFound,
+ }
+ } catch (error) {
+ logger.error(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestGetInstalledCertificateIds: Failed to retrieve certificates`,
+ error
+ )
+ return {
+ status: GetInstalledCertificateStatusEnumType.NotFound,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InternalError,
+ },
+ }
+ }
+ }
+
+ private async handleRequestInstallCertificate (
+ chargingStation: ChargingStation,
+ commandPayload: OCPP20InstallCertificateRequest
+ ): Promise<OCPP20InstallCertificateResponse> {
+ const { certificate, certificateType } = commandPayload
+
+ if (!hasCertificateManager(chargingStation)) {
+ logger.error(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestInstallCertificate: Certificate manager not available`
+ )
+ return {
+ status: InstallCertificateStatusEnumType.Failed,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InternalError,
+ },
+ }
+ }
+
+ if (!chargingStation.certificateManager.validateCertificateFormat(certificate)) {
+ logger.warn(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestInstallCertificate: Invalid PEM format for certificate type ${certificateType}`
+ )
+ return {
+ status: InstallCertificateStatusEnumType.Rejected,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InvalidCertificate,
+ },
+ }
+ }
+
+ try {
+ const methodResult = chargingStation.certificateManager.storeCertificate(
+ chargingStation.stationInfo?.hashId ?? '',
+ certificateType,
+ certificate
+ )
+ const storeResult: StoreCertificateResult =
+ methodResult instanceof Promise ? await methodResult : methodResult
+
+ if (!storeResult.success) {
+ logger.warn(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestInstallCertificate: Certificate storage rejected for type ${certificateType}`
+ )
+ return {
+ status: InstallCertificateStatusEnumType.Rejected,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InvalidCertificate,
+ },
+ }
+ }
+
+ logger.info(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestInstallCertificate: Certificate installed successfully for type ${certificateType}`
+ )
+ return {
+ status: InstallCertificateStatusEnumType.Accepted,
+ }
+ } catch (error) {
+ logger.error(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestInstallCertificate: Certificate storage failed for type ${certificateType}`,
+ error
+ )
+ return {
+ status: InstallCertificateStatusEnumType.Failed,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.OutOfStorage,
+ },
+ }
+ }
+ }
+
private async handleRequestReset (
chargingStation: ChargingStation,
commandPayload: OCPP20ResetRequest
}
}
- // Authorize idToken - OCPP 2.0 always uses unified auth system
+ // Authorize idToken
let isAuthorized = false
try {
- // Use unified auth system - pass idToken.idToken as string
- isAuthorized = await OCPPServiceUtils.isIdTagAuthorizedUnified(
- chargingStation,
- connectorId,
- idToken.idToken
- )
+ isAuthorized = this.isIdTokenAuthorized(chargingStation, idToken)
} catch (error) {
logger.error(
`${chargingStation.logPrefix()} ${moduleName}.handleRequestStartTransaction: Authorization error for ${idToken.idToken}:`,
if (groupIdToken != null) {
let isGroupAuthorized = false
try {
- // Use unified auth system for group token
- isGroupAuthorized = await OCPPServiceUtils.isIdTagAuthorizedUnified(
- chargingStation,
- connectorId,
- groupIdToken.idToken
- )
+ isGroupAuthorized = this.isIdTokenAuthorized(chargingStation, groupIdToken)
} catch (error) {
logger.error(
`${chargingStation.logPrefix()} ${moduleName}.handleRequestStartTransaction: Group authorization error for ${groupIdToken.idToken}:`,
// Validate charging profile if provided
if (chargingProfile != null) {
+ // OCPP 2.0.1 §2.10: RequestStartTransaction requires chargingProfilePurpose = TxProfile
+ if (
+ chargingProfile.chargingProfilePurpose !== OCPP20ChargingProfilePurposeEnumType.TxProfile
+ ) {
+ logger.warn(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestStartTransaction: ChargingProfile must have purpose TxProfile for RequestStartTransaction, got ${chargingProfile.chargingProfilePurpose}`
+ )
+ return {
+ status: RequestStartStopStatusEnumType.Rejected,
+ transactionId: generateUUID(),
+ }
+ }
+
+ // OCPP 2.0.1 §2.10: transactionId MUST NOT be set in RequestStartTransaction
+ if (chargingProfile.transactionId != null) {
+ logger.warn(
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestStartTransaction: ChargingProfile transactionId must not be set for RequestStartTransaction`
+ )
+ return {
+ status: RequestStartStopStatusEnumType.Rejected,
+ transactionId: generateUUID(),
+ }
+ }
let isValidProfile = false
try {
- isValidProfile = this.validateChargingProfile(
- chargingStation,
- chargingProfile,
- evseId,
- 'RequestStartTransaction'
- )
+ isValidProfile = this.validateChargingProfile(chargingStation, chargingProfile, evseId)
} catch (error) {
logger.error(
`${chargingStation.logPrefix()} ${moduleName}.handleRequestStartTransaction: Charging profile validation error:`,
transactionId: generateUUID(),
}
}
-
if (!isValidProfile) {
logger.warn(
`${chargingStation.logPrefix()} ${moduleName}.handleRequestStartTransaction: Invalid charging profile`
)
connectorStatus.transactionStarted = true
connectorStatus.transactionId = transactionId
- // Reset sequence number for new transaction (OCPP 2.0.1 compliance)
- OCPP20ServiceUtils.resetTransactionSequenceNumber(chargingStation, connectorId)
connectorStatus.transactionIdTag = idToken.idToken
connectorStatus.transactionStart = new Date()
connectorStatus.transactionEnergyActiveImportRegisterValue = 0
)
}
- // Send TransactionEvent Started notification to CSMS with context-aware trigger reason selection
- // FR: F01.FR.17 - remoteStartId SHALL be included in TransactionEventRequest
- // FR: F02.FR.05 - idToken SHALL be included in TransactionEventRequest
- const context: OCPP20TransactionContext = {
- command: 'RequestStartTransaction',
- source: 'remote_command',
- }
-
- await OCPP20ServiceUtils.sendTransactionEvent(
- chargingStation,
- OCPP20TransactionEventEnumType.Started,
- context,
- connectorId,
- transactionId,
- {
- idToken,
- remoteStartId,
- }
- )
-
- // Start TxUpdatedInterval timer for periodic TransactionEvent(Updated) messages
- const txUpdatedInterval = this.getTxUpdatedInterval(chargingStation)
- chargingStation.startTxUpdatedInterval(connectorId, txUpdatedInterval)
-
logger.info(
`${chargingStation.logPrefix()} ${moduleName}.handleRequestStartTransaction: Remote start transaction ACCEPTED on #${connectorId.toString()} for idToken '${idToken.idToken}'`
)
`${chargingStation.logPrefix()} ${moduleName}.handleRequestStopTransaction: Remote stop transaction request received for transaction ID ${transactionId as string}`
)
- if (!validateIdentifierString(transactionId, 36)) {
+ if (!validateUUID(transactionId)) {
logger.warn(
- `${chargingStation.logPrefix()} ${moduleName}.handleRequestStopTransaction: Invalid transaction ID format (must be non-empty string ≤36 characters): ${transactionId as string}`
+ `${chargingStation.logPrefix()} ${moduleName}.handleRequestStopTransaction: Invalid transaction ID format (expected UUID): ${transactionId as string}`
)
return {
status: RequestStartStopStatusEnumType.Rejected,
}
}
+ private isIdTokenAuthorized (
+ chargingStation: ChargingStation,
+ idToken: OCPP20IdTokenType
+ ): boolean {
+ /**
+ * OCPP 2.0 Authorization Logic Implementation
+ *
+ * OCPP 2.0 handles authorization differently from 1.6:
+ * 1. Check if authorization is required (LocalAuthorizeOffline, AuthorizeRemoteStart variables)
+ * 2. Local authorization list validation if enabled
+ * 3. For OCPP 2.0, there's no explicit AuthorizeRequest - authorization is validated
+ * through configuration variables and local auth lists
+ * 4. Remote validation through TransactionEvent if needed
+ */
+
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.isIdTokenAuthorized: Validating idToken ${idToken.idToken} of type ${idToken.type}`
+ )
+
+ try {
+ // Check if local authorization is disabled and remote authorization is also disabled
+ const localAuthListEnabled = chargingStation.getLocalAuthListEnabled()
+ const remoteAuthorizationEnabled = chargingStation.stationInfo?.remoteAuthorization ?? true
+
+ if (!localAuthListEnabled && !remoteAuthorizationEnabled) {
+ logger.warn(
+ `${chargingStation.logPrefix()} ${moduleName}.isIdTokenAuthorized: Both local and remote authorization are disabled. Allowing access but this may indicate misconfiguration.`
+ )
+ return true
+ }
+
+ // 1. Check local authorization list first (if enabled)
+ if (localAuthListEnabled) {
+ const isLocalAuthorized = this.isIdTokenLocalAuthorized(chargingStation, idToken.idToken)
+ if (isLocalAuthorized) {
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.isIdTokenAuthorized: IdToken ${idToken.idToken} authorized via local auth list`
+ )
+ return true
+ }
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.isIdTokenAuthorized: IdToken ${idToken.idToken} not found in local auth list`
+ )
+ }
+
+ // 2. For OCPP 2.0, if we can't authorize locally and remote auth is enabled,
+ // we should validate through TransactionEvent mechanism or return false
+ // In OCPP 2.0, there's no explicit remote authorize - it's handled during transaction events
+ if (remoteAuthorizationEnabled) {
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.isIdTokenAuthorized: Remote authorization enabled but no explicit remote auth mechanism in OCPP 2.0 - deferring to transaction event validation`
+ )
+ // In OCPP 2.0, remote authorization happens during TransactionEvent processing
+ // For now, we'll allow the transaction to proceed and let the CSMS validate during TransactionEvent
+ return true
+ }
+
+ // 3. If we reach here, authorization failed
+ logger.warn(
+ `${chargingStation.logPrefix()} ${moduleName}.isIdTokenAuthorized: IdToken ${idToken.idToken} authorization failed - not found in local list and remote auth not configured`
+ )
+ return false
+ } catch (error) {
+ logger.error(
+ `${chargingStation.logPrefix()} ${moduleName}.isIdTokenAuthorized: Error during authorization validation for ${idToken.idToken}:`,
+ error
+ )
+ // Fail securely - deny access on authorization errors
+ return false
+ }
+ }
+
+ /**
+ * Check if idToken is authorized in local authorization list
+ * @param chargingStation - The charging station instance
+ * @param idTokenString - The ID token string to validate
+ * @returns true if authorized locally, false otherwise
+ */
+ private isIdTokenLocalAuthorized (
+ chargingStation: ChargingStation,
+ idTokenString: string
+ ): boolean {
+ try {
+ return (
+ chargingStation.hasIdTags() &&
+ chargingStation.idTagsCache
+ // eslint-disable-next-line @typescript-eslint/no-non-null-assertion
+ .getIdTags(getIdTagsFile(chargingStation.stationInfo!)!)
+ ?.includes(idTokenString) === true
+ )
+ } catch (error) {
+ logger.error(
+ `${chargingStation.logPrefix()} ${moduleName}.isIdTokenLocalAuthorized: Error checking local authorization for ${idTokenString}:`,
+ error
+ )
+ return false
+ }
+ }
+
/**
* Reset connector status on start transaction error
* @param chargingStation - The charging station instance
private validateChargingProfile (
chargingStation: ChargingStation,
chargingProfile: OCPP20ChargingProfileType,
- evseId: number,
- context: 'RequestStartTransaction' | 'SetChargingProfile' = 'SetChargingProfile'
+ evseId: number
): boolean {
logger.debug(
`${chargingStation.logPrefix()} ${moduleName}.validateChargingProfile: Validating charging profile ${chargingProfile.id.toString()} for EVSE ${evseId.toString()}`
)
+ // Validate stack level range (OCPP 2.0 spec: 0-9)
if (chargingProfile.stackLevel < 0 || chargingProfile.stackLevel > 9) {
logger.warn(
`${chargingStation.logPrefix()} ${moduleName}.validateChargingProfile: Invalid stack level ${chargingProfile.stackLevel.toString()}, must be 0-9`
return false
}
+ // Validate charging profile ID is positive
if (chargingProfile.id <= 0) {
logger.warn(
`${chargingStation.logPrefix()} ${moduleName}.validateChargingProfile: Invalid charging profile ID ${chargingProfile.id.toString()}, must be positive`
return false
}
+ // Validate EVSE compatibility
if (!chargingStation.hasEvses && evseId > 0) {
logger.warn(
`${chargingStation.logPrefix()} ${moduleName}.validateChargingProfile: EVSE ${evseId.toString()} not supported by this charging station`
return false
}
+ // Validate charging schedules array is not empty
if (chargingProfile.chargingSchedule.length === 0) {
logger.warn(
`${chargingStation.logPrefix()} ${moduleName}.validateChargingProfile: Charging profile must contain at least one charging schedule`
return false
}
+ // Time constraints validation
const now = new Date()
if (chargingProfile.validFrom && chargingProfile.validTo) {
if (chargingProfile.validFrom >= chargingProfile.validTo) {
return false
}
+ // Validate recurrency kind compatibility with profile kind
if (
chargingProfile.recurrencyKind &&
chargingProfile.chargingProfileKind !== OCPP20ChargingProfileKindEnumType.Recurring
return false
}
+ // Validate each charging schedule
for (const [scheduleIndex, schedule] of chargingProfile.chargingSchedule.entries()) {
if (
!this.validateChargingSchedule(
}
}
- if (!this.validateChargingProfilePurpose(chargingStation, chargingProfile, evseId, context)) {
+ // Profile purpose specific validations
+ if (!this.validateChargingProfilePurpose(chargingStation, chargingProfile, evseId)) {
return false
}
/**
* Validates charging profile purpose-specific business rules
- * Per OCPP 2.0.1 Part 2 §2.10:
- * - RequestStartTransaction MUST use chargingProfilePurpose=TxProfile
- * - RequestStartTransaction chargingProfile.transactionId MUST NOT be present
* @param chargingStation - The charging station instance
* @param chargingProfile - The charging profile to validate
* @param evseId - EVSE identifier
- * @param context - Request context ('RequestStartTransaction' or 'SetChargingProfile')
* @returns True if purpose validation passes, false otherwise
*/
private validateChargingProfilePurpose (
chargingStation: ChargingStation,
chargingProfile: OCPP20ChargingProfileType,
- evseId: number,
- context: 'RequestStartTransaction' | 'SetChargingProfile' = 'SetChargingProfile'
+ evseId: number
): boolean {
logger.debug(
- `${chargingStation.logPrefix()} ${moduleName}.validateChargingProfilePurpose: Validating purpose-specific rules for profile ${chargingProfile.id.toString()} with purpose ${chargingProfile.chargingProfilePurpose} in context ${context}`
+ `${chargingStation.logPrefix()} ${moduleName}.validateChargingProfilePurpose: Validating purpose-specific rules for profile ${chargingProfile.id.toString()} with purpose ${chargingProfile.chargingProfilePurpose}`
)
- // RequestStartTransaction context validation per OCPP 2.0.1 §2.10
- if (context === 'RequestStartTransaction') {
- // Requirement 1: ChargingProfile.chargingProfilePurpose SHALL be TxProfile
- if (
- chargingProfile.chargingProfilePurpose !== OCPP20ChargingProfilePurposeEnumType.TxProfile
- ) {
- logger.warn(
- `${chargingStation.logPrefix()} ${moduleName}.validateChargingProfilePurpose: RequestStartTransaction (OCPP 2.0.1 §2.10) requires chargingProfilePurpose to be TxProfile, got ${chargingProfile.chargingProfilePurpose}`
- )
- return false
- }
-
- // Requirement 2: ChargingProfile.transactionId SHALL NOT be present at RequestStartTransaction time
- if (chargingProfile.transactionId != null) {
- logger.warn(
- `${chargingStation.logPrefix()} ${moduleName}.validateChargingProfilePurpose: RequestStartTransaction (OCPP 2.0.1 §2.10) does not allow chargingProfile.transactionId (not yet known at start time)`
- )
- return false
- }
- }
-
switch (chargingProfile.chargingProfilePurpose) {
case OCPP20ChargingProfilePurposeEnumType.ChargingStationExternalConstraints:
// ChargingStationExternalConstraints must apply to EVSE 0 (entire station)
return false
}
- // TxProfile in SetChargingProfile context should have a transactionId
- if (context === 'SetChargingProfile' && !chargingProfile.transactionId) {
+ // TxProfile should have a transactionId when used with active transaction
+ if (!chargingProfile.transactionId) {
logger.debug(
- `${chargingStation.logPrefix()} ${moduleName}.validateChargingProfilePurpose: TxProfile without transactionId in SetChargingProfile context - may be for future use`
+ `${chargingStation.logPrefix()} ${moduleName}.validateChargingProfilePurpose: TxProfile without transactionId - may be for future use`
)
}
break
import type { ValidateFunction } from 'ajv'
+import { generateKeyPairSync } from 'node:crypto'
+
import type { ChargingStation } from '../../../charging-station/index.js'
import type { OCPPResponseService } from '../OCPPResponseService.js'
import { OCPPError } from '../../../exception/index.js'
import {
+ type CertificateActionEnumType,
+ type CertificateSigningUseEnumType,
ErrorType,
type JsonObject,
type JsonType,
+ type OCPP20Get15118EVCertificateRequest,
+ type OCPP20Get15118EVCertificateResponse,
+ type OCPP20GetCertificateStatusRequest,
+ type OCPP20GetCertificateStatusResponse,
OCPP20RequestCommand,
+ type OCPP20SignCertificateRequest,
+ type OCPP20SignCertificateResponse,
OCPPVersion,
+ type OCSPRequestDataType,
type RequestParams,
} from '../../../types/index.js'
import { generateUUID, logger } from '../../../utils/index.js'
this.buildRequestPayload = this.buildRequestPayload.bind(this)
}
+ /**
+ * Request an ISO 15118 EV certificate from the CSMS.
+ *
+ * Forwards an EXI-encoded certificate request from the EV to the CSMS.
+ * The EXI payload is passed through unmodified (base64 string) without
+ * any decoding or validation - the CSMS is responsible for processing it.
+ *
+ * This is used during ISO 15118 Plug & Charge flows when the EV requests
+ * certificate installation or update from the Mobility Operator (MO).
+ * @param chargingStation - The charging station forwarding the request
+ * @param iso15118SchemaVersion - Schema version identifier (e.g., 'urn:iso:15118:2:2013:MsgDef')
+ * @param action - The certificate action type (Install or Update)
+ * @param exiRequest - Base64-encoded EXI request from the EV (passed through unchanged)
+ * @returns Promise resolving to the CSMS response with EXI-encoded certificate data
+ */
+ public async requestGet15118EVCertificate (
+ chargingStation: ChargingStation,
+ iso15118SchemaVersion: string,
+ action: CertificateActionEnumType,
+ exiRequest: string
+ ): Promise<OCPP20Get15118EVCertificateResponse> {
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.requestGet15118EVCertificate: Requesting ISO 15118 EV certificate`
+ )
+
+ const requestPayload: OCPP20Get15118EVCertificateRequest = {
+ action,
+ exiRequest,
+ iso15118SchemaVersion,
+ }
+
+ const messageId = generateUUID()
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.requestGet15118EVCertificate: Sending Get15118EVCertificate request with message ID '${messageId}'`
+ )
+
+ const response = (await this.sendMessage(
+ chargingStation,
+ messageId,
+ requestPayload,
+ OCPP20RequestCommand.GET_15118_EV_CERTIFICATE
+ )) as OCPP20Get15118EVCertificateResponse
+
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.requestGet15118EVCertificate: Received response with status '${response.status}'`
+ )
+
+ return response
+ }
+
+ /**
+ * Request OCSP certificate status from the CSMS.
+ *
+ * Sends an OCSP (Online Certificate Status Protocol) request to the CSMS
+ * to check the revocation status of a certificate. The CSMS will return
+ * the OCSP response data which can be used to verify certificate validity.
+ *
+ * This is used to validate certificates during ISO 15118 communication
+ * before accepting them for charging authorization.
+ *
+ * Note: This is a stub implementation for simulator testing. No real OCSP
+ * network calls are made - the CSMS provides the response.
+ * @param chargingStation - The charging station requesting the status
+ * @param ocspRequestData - OCSP request data including certificate hash and responder URL
+ * @returns Promise resolving to the CSMS response with OCSP result
+ */
+ public async requestGetCertificateStatus (
+ chargingStation: ChargingStation,
+ ocspRequestData: OCSPRequestDataType
+ ): Promise<OCPP20GetCertificateStatusResponse> {
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.requestGetCertificateStatus: Requesting certificate status`
+ )
+
+ const requestPayload: OCPP20GetCertificateStatusRequest = {
+ ocspRequestData,
+ }
+
+ const messageId = generateUUID()
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.requestGetCertificateStatus: Sending GetCertificateStatus request with message ID '${messageId}'`
+ )
+
+ const response = (await this.sendMessage(
+ chargingStation,
+ messageId,
+ requestPayload,
+ OCPP20RequestCommand.GET_CERTIFICATE_STATUS
+ )) as OCPP20GetCertificateStatusResponse
+
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.requestGetCertificateStatus: Received response with status '${response.status}'`
+ )
+
+ return response
+ }
+
/**
* Handles OCPP 2.0.1 request processing with enhanced validation and comprehensive error handling
*
throw new OCPPError(ErrorType.NOT_SUPPORTED, errorMsg, commandName, commandParams)
}
+ /**
+ * Request certificate signing from the CSMS.
+ *
+ * Generates a Certificate Signing Request (CSR) using the charging station's
+ * certificate manager and sends it to the CSMS for signing. Supports both
+ * ChargingStationCertificate and V2GCertificate types.
+ *
+ * IMPORTANT: This implementation generates a MOCK CSR for simulator testing purposes.
+ * It is NOT a cryptographically valid PKCS#10 CSR and MUST NOT be used in production.
+ * The generated CSR structure is simplified (JSON-based) for OCPP message testing only.
+ * Real CSMS expecting valid PKCS#10 CSR will reject this format.
+ * @param chargingStation - The charging station requesting the certificate
+ * @param certificateType - Optional certificate type (ChargingStationCertificate or V2GCertificate)
+ * @returns Promise resolving to the CSMS response with Accepted or Rejected status
+ * @throws {OCPPError} When certificate manager is unavailable or CSR generation fails
+ */
+ public async requestSignCertificate (
+ chargingStation: ChargingStation,
+ certificateType?: CertificateSigningUseEnumType
+ ): Promise<OCPP20SignCertificateResponse> {
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.requestSignCertificate: Requesting certificate signing`
+ )
+
+ let csr: string
+ try {
+ const { publicKey } = generateKeyPairSync('rsa', {
+ modulusLength: 2048,
+ privateKeyEncoding: { format: 'pem', type: 'pkcs8' },
+ publicKeyEncoding: { format: 'pem', type: 'spki' },
+ })
+
+ const configKey = chargingStation.ocppConfiguration?.configurationKey?.find(
+ key => key.key === 'SecurityCtrlr.OrganizationName'
+ )
+ const orgName = configKey?.value ?? 'Unknown'
+ const stationId = chargingStation.stationInfo?.chargingStationId ?? 'Unknown'
+ const subject = `CN=${stationId},O=${orgName}`
+
+ // Generate simplified mock CSR for simulator testing
+ // WARNING: This is NOT a cryptographically valid PKCS#10 CSR
+ // Structure: JSON with subject, publicKey, timestamp (NOT ASN.1 DER)
+ const mockCsrData = {
+ algorithm: 'RSA-SHA256',
+ keySize: 2048,
+ publicKey: publicKey.replace(/-----BEGIN PUBLIC KEY-----|-----END PUBLIC KEY-----|\n/g, ''),
+ subject,
+ timestamp: new Date().toISOString(),
+ }
+
+ const csrBase64 = Buffer.from(JSON.stringify(mockCsrData)).toString('base64')
+ csr = `-----BEGIN CERTIFICATE REQUEST-----\n${csrBase64}\n-----END CERTIFICATE REQUEST-----`
+ } catch (error) {
+ const errorMsg = `Failed to generate CSR: ${error instanceof Error ? error.message : 'Unknown error'}`
+ logger.error(
+ `${chargingStation.logPrefix()} ${moduleName}.requestSignCertificate: ${errorMsg}`
+ )
+ throw new OCPPError(ErrorType.INTERNAL_ERROR, errorMsg, OCPP20RequestCommand.SIGN_CERTIFICATE)
+ }
+
+ // Build request payload
+ const requestPayload: OCPP20SignCertificateRequest = {
+ csr,
+ }
+
+ // Add certificate type if specified
+ if (certificateType != null) {
+ requestPayload.certificateType = certificateType
+ }
+
+ const messageId = generateUUID()
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.requestSignCertificate: Sending SignCertificate request with message ID '${messageId}'`
+ )
+
+ const response = (await this.sendMessage(
+ chargingStation,
+ messageId,
+ requestPayload,
+ OCPP20RequestCommand.SIGN_CERTIFICATE
+ )) as OCPP20SignCertificateResponse
+
+ logger.debug(
+ `${chargingStation.logPrefix()} ${moduleName}.requestSignCertificate: Received response with status '${response.status}'`
+ )
+
+ return response
+ }
+
// eslint-disable-next-line @typescript-eslint/no-unnecessary-type-parameters
private buildRequestPayload<Request extends JsonType>(
chargingStation: ChargingStation,
for (const entry of candidates) {
if (context.source === 'remote_command' && context.command != null) {
if (
- (context.command === 'RequestStartTransaction' &&
+ (context.command === OCPP20IncomingRequestCommand.REQUEST_START_TRANSACTION &&
entry.triggerReason === OCPP20TriggerReasonEnumType.RemoteStart) ||
- (context.command === 'RequestStopTransaction' &&
+ (context.command === OCPP20IncomingRequestCommand.REQUEST_STOP_TRANSACTION &&
entry.triggerReason === OCPP20TriggerReasonEnumType.RemoteStop) ||
- (context.command === 'Reset' &&
+ (context.command === OCPP20IncomingRequestCommand.RESET &&
entry.triggerReason === OCPP20TriggerReasonEnumType.ResetCommand) ||
- (context.command === 'TriggerMessage' &&
+ (context.command === OCPP20IncomingRequestCommand.TRIGGER_MESSAGE &&
entry.triggerReason === OCPP20TriggerReasonEnumType.Trigger) ||
- (context.command === 'UnlockConnector' &&
+ (context.command === OCPP20IncomingRequestCommand.UNLOCK_CONNECTOR &&
entry.triggerReason === OCPP20TriggerReasonEnumType.UnlockCommand)
) {
return entry.triggerReason
} from './ocpp/1.6/Transaction.js'
export {
BootReasonEnumType,
+ CertificateActionEnumType,
+ type CertificateHashDataChainType,
+ type CertificateHashDataType,
+ CertificateSigningUseEnumType,
type CustomDataType,
DataEnumType,
+ DeleteCertificateStatusEnumType,
GenericDeviceModelStatusEnumType,
+ GetCertificateIdUseEnumType,
+ GetCertificateStatusEnumType,
+ GetInstalledCertificateStatusEnumType,
+ HashAlgorithmEnumType,
+ InstallCertificateStatusEnumType,
+ InstallCertificateUseEnumType,
+ Iso15118EVCertificateStatusEnumType,
OCPP20ComponentName,
OCPP20UnitEnumType,
+ type OCSPRequestDataType,
ReasonCodeEnumType,
ReportBaseEnumType,
ResetEnumType,
} from './ocpp/2.0/MeterValues.js'
export {
type OCPP20BootNotificationRequest,
+ type OCPP20CertificateSignedRequest,
type OCPP20ClearCacheRequest,
+ type OCPP20DeleteCertificateRequest,
+ type OCPP20Get15118EVCertificateRequest,
type OCPP20GetBaseReportRequest,
+ type OCPP20GetCertificateStatusRequest,
+ type OCPP20GetInstalledCertificateIdsRequest,
type OCPP20GetVariablesRequest,
type OCPP20HeartbeatRequest,
OCPP20IncomingRequestCommand,
+ type OCPP20InstallCertificateRequest,
type OCPP20NotifyReportRequest,
OCPP20RequestCommand,
type OCPP20RequestStartTransactionRequest,
type OCPP20RequestStopTransactionRequest,
type OCPP20ResetRequest,
type OCPP20SetVariablesRequest,
+ type OCPP20SignCertificateRequest,
type OCPP20StatusNotificationRequest,
} from './ocpp/2.0/Requests.js'
export type {
OCPP20BootNotificationResponse,
+ OCPP20CertificateSignedResponse,
OCPP20ClearCacheResponse,
+ OCPP20DeleteCertificateResponse,
+ OCPP20Get15118EVCertificateResponse,
OCPP20GetBaseReportResponse,
+ OCPP20GetCertificateStatusResponse,
+ OCPP20GetInstalledCertificateIdsResponse,
OCPP20GetVariablesResponse,
OCPP20HeartbeatResponse,
+ OCPP20InstallCertificateResponse,
OCPP20NotifyReportResponse,
OCPP20RequestStartTransactionResponse,
OCPP20RequestStopTransactionResponse,
OCPP20ResetResponse,
OCPP20SetVariablesResponse,
+ OCPP20SignCertificateResponse,
OCPP20StatusNotificationResponse,
} from './ocpp/2.0/Responses.js'
export {
V2GRootCertificate = 'V2GRootCertificate',
}
+export enum Iso15118EVCertificateStatusEnumType {
+ Accepted = 'Accepted',
+ Failed = 'Failed',
+}
+
export enum OCPP20ComponentName {
// Physical and Logical Components
AccessBarrier = 'AccessBarrier',
export interface CertificateHashDataChainType extends JsonObject {
certificateHashData: CertificateHashDataType
certificateType: GetCertificateIdUseEnumType
- childCertificateHashData?: CertificateHashDataType
+ childCertificateHashData?: CertificateHashDataType[]
}
export interface CertificateHashDataType extends JsonObject {
import type { UUIDv4 } from '../../UUID.js'
import type {
BootReasonEnumType,
+ CertificateActionEnumType,
+ CertificateHashDataType,
+ CertificateSigningUseEnumType,
ChargingStationType,
CustomDataType,
+ GetCertificateIdUseEnumType,
InstallCertificateUseEnumType,
+ OCSPRequestDataType,
ReportBaseEnumType,
ResetEnumType,
} from './Common.js'
} from './Variables.js'
export const enum OCPP20IncomingRequestCommand {
+ CERTIFICATE_SIGNED = 'CertificateSigned',
CLEAR_CACHE = 'ClearCache',
+ DELETE_CERTIFICATE = 'DeleteCertificate',
GET_BASE_REPORT = 'GetBaseReport',
+ GET_INSTALLED_CERTIFICATE_IDS = 'GetInstalledCertificateIds',
GET_VARIABLES = 'GetVariables',
+ INSTALL_CERTIFICATE = 'InstallCertificate',
REQUEST_START_TRANSACTION = 'RequestStartTransaction',
REQUEST_STOP_TRANSACTION = 'RequestStopTransaction',
RESET = 'Reset',
SET_VARIABLES = 'SetVariables',
+ TRIGGER_MESSAGE = 'TriggerMessage',
+ UNLOCK_CONNECTOR = 'UnlockConnector',
}
export const enum OCPP20RequestCommand {
BOOT_NOTIFICATION = 'BootNotification',
+ GET_15118_EV_CERTIFICATE = 'Get15118EVCertificate',
+ GET_CERTIFICATE_STATUS = 'GetCertificateStatus',
HEARTBEAT = 'Heartbeat',
NOTIFY_REPORT = 'NotifyReport',
+ SIGN_CERTIFICATE = 'SignCertificate',
STATUS_NOTIFICATION = 'StatusNotification',
TRANSACTION_EVENT = 'TransactionEvent',
}
reason: BootReasonEnumType
}
+export interface OCPP20CertificateSignedRequest extends JsonObject {
+ certificateChain: string
+ certificateType?: CertificateSigningUseEnumType
+ customData?: CustomDataType
+}
+
export type OCPP20ClearCacheRequest = EmptyObject
+export interface OCPP20DeleteCertificateRequest extends JsonObject {
+ certificateHashData: CertificateHashDataType
+ customData?: CustomDataType
+}
+
+export interface OCPP20Get15118EVCertificateRequest extends JsonObject {
+ action: CertificateActionEnumType
+ customData?: CustomDataType
+ exiRequest: string
+ iso15118SchemaVersion: string
+}
+
export interface OCPP20GetBaseReportRequest extends JsonObject {
customData?: CustomDataType
reportBase: ReportBaseEnumType
requestId: number
}
+export interface OCPP20GetCertificateStatusRequest extends JsonObject {
+ customData?: CustomDataType
+ ocspRequestData: OCSPRequestDataType
+}
+
+export interface OCPP20GetInstalledCertificateIdsRequest extends JsonObject {
+ certificateType?: GetCertificateIdUseEnumType[]
+ customData?: CustomDataType
+}
+
export interface OCPP20GetVariablesRequest extends JsonObject {
customData?: CustomDataType
getVariableData: OCPP20GetVariableDataType[]
setVariableData: OCPP20SetVariableDataType[]
}
+export interface OCPP20SignCertificateRequest extends JsonObject {
+ certificateType?: CertificateSigningUseEnumType
+ csr: string
+ customData?: CustomDataType
+}
+
export interface OCPP20StatusNotificationRequest extends JsonObject {
connectorId: number
connectorStatus: OCPP20ConnectorStatusEnumType
import type { UUIDv4 } from '../../UUID.js'
import type { RegistrationStatusEnumType } from '../Common.js'
import type {
+ CertificateHashDataChainType,
+ CertificateSignedStatusEnumType,
CustomDataType,
+ DeleteCertificateStatusEnumType,
GenericDeviceModelStatusEnumType,
GenericStatusEnumType,
+ GetCertificateStatusEnumType,
+ GetInstalledCertificateStatusEnumType,
InstallCertificateStatusEnumType,
+ Iso15118EVCertificateStatusEnumType,
ResetStatusEnumType,
StatusInfoType,
} from './Common.js'
statusInfo?: StatusInfoType
}
+export interface OCPP20CertificateSignedResponse extends JsonObject {
+ customData?: CustomDataType
+ status: CertificateSignedStatusEnumType
+ statusInfo?: StatusInfoType
+}
+
export interface OCPP20ClearCacheResponse extends JsonObject {
customData?: CustomDataType
status: GenericStatusEnumType
statusInfo?: StatusInfoType
}
+export interface OCPP20DeleteCertificateResponse extends JsonObject {
+ customData?: CustomDataType
+ status: DeleteCertificateStatusEnumType
+ statusInfo?: StatusInfoType
+}
+
+export interface OCPP20Get15118EVCertificateResponse extends JsonObject {
+ customData?: CustomDataType
+ exiResponse: string
+ status: Iso15118EVCertificateStatusEnumType
+ statusInfo?: StatusInfoType
+}
+
export interface OCPP20GetBaseReportResponse extends JsonObject {
customData?: CustomDataType
status: GenericDeviceModelStatusEnumType
statusInfo?: StatusInfoType
}
+export interface OCPP20GetCertificateStatusResponse extends JsonObject {
+ customData?: CustomDataType
+ ocspResult?: string
+ status: GetCertificateStatusEnumType
+ statusInfo?: StatusInfoType
+}
+
+export interface OCPP20GetInstalledCertificateIdsResponse extends JsonObject {
+ certificateHashDataChain?: CertificateHashDataChainType[]
+ customData?: CustomDataType
+ status: GetInstalledCertificateStatusEnumType
+ statusInfo?: StatusInfoType
+}
+
export interface OCPP20GetVariablesResponse extends JsonObject {
customData?: CustomDataType
getVariableResult: OCPP20GetVariableResultType[]
setVariableResult: OCPP20SetVariableResultType[]
}
+export interface OCPP20SignCertificateResponse extends JsonObject {
+ customData?: CustomDataType
+ status: GenericStatusEnumType
+ statusInfo?: StatusInfoType
+}
+
export type OCPP20StatusNotificationResponse = EmptyObject
}
/** Specific command that triggered the event (for remote_command source) */
- command?:
- | 'RequestStartTransaction'
- | 'RequestStopTransaction'
- | 'Reset'
- | 'TriggerMessage'
- | 'UnlockConnector'
+ command?: OCPP20IncomingRequestCommand
hasRemoteStartId?: boolean
getNumberOfEvses: (): number => evses.size,
getWebSocketPingInterval: () => websocketPingInterval,
hasEvses: useEvses,
+ hasIdTags: (): boolean => false,
idTagsCache: IdTagsCache.getInstance(),
inAcceptedState: (): boolean => {
return (
--- /dev/null
+/* eslint-disable @typescript-eslint/no-explicit-any */
+
+import { expect } from '@std/expect'
+import { describe, it, mock } from 'node:test'
+
+import { OCPP20CertificateManager } from '../../../../src/charging-station/ocpp/2.0/OCPP20CertificateManager.js'
+import {
+ type CertificateHashDataType,
+ HashAlgorithmEnumType,
+ InstallCertificateUseEnumType,
+} from '../../../../src/types/index.js'
+
+// eslint-disable-next-line @typescript-eslint/no-unused-vars -- kept for future mocking
+const _mockFs = {
+ existsSync: mock.fn(() => true),
+ mkdirSync: mock.fn(() => undefined),
+ readdirSync: mock.fn(() => []),
+ readFileSync: mock.fn(() => ''),
+ rmSync: mock.fn(() => undefined),
+ writeFileSync: mock.fn(() => undefined),
+}
+
+const TEST_STATION_HASH_ID = 'test-station-hash-12345'
+const TEST_CERT_TYPE = InstallCertificateUseEnumType.CSMSRootCertificate
+
+const VALID_PEM_CERTIFICATE = `-----BEGIN CERTIFICATE-----
+MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiUMA0GCSqGSIb3Qq8teleNzMHjvLuHvVsY
+a5uYmO6K8pzuYmOvfLNNMC5leGFtcGxlLmNvbTAeFw0xNzAxMTIyMTI3NDBaFw0y
+NzAxMTAyMTI3NDBaMC4xLDAqBgNVBAMTI2V4YW1wbGUuY29tIFNlbGYgU2lnbmVk
+IENlcnRpZmljYXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqGxm
+mO6K8pzuYmOvfLNNMC5leGFtcGxlLmNvbTAeFw0xNzAxMTIyMTI3NDBaFw0yNzAx
+MTAyMTI3NDBaMC4xLDAqBgNVBAMTI2V4YW1wbGUuY29tIFNlbGYgU2lnbmVkIENl
+cnRpZmljYXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqGxmmO6K
+8pzuYmOvfLNNMBQLq2K8pzuY0BAQEFAAOCAQ8AMIIBCgKCAQEAqGxmmO6K8pzuYq
+-----END CERTIFICATE-----`
+
+const INVALID_PEM_NO_MARKERS = `
+MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiUMA0GCSqGSIb3Qq8teleNzMHjvLuHvVsY
+a5uYmO6K8pzuYmOvfLNNMC5leGFtcGxlLmNvbTAeFw0xNzAxMTIyMTI3NDBaFw0y
+`
+
+const INVALID_PEM_WRONG_MARKERS = `-----BEGIN PRIVATE KEY-----
+MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiUMA0GCSqGSIb3Qq8teleNzMHjvLuHvVsY
+-----END PRIVATE KEY-----`
+
+const EMPTY_PEM_CERTIFICATE = ''
+
+// eslint-disable-next-line @typescript-eslint/no-unused-vars -- kept for future assertions
+const _EXPECTED_HASH_DATA: CertificateHashDataType = {
+ hashAlgorithm: HashAlgorithmEnumType.SHA256,
+ issuerKeyHash: expect.stringMatching(/^[a-fA-F0-9]+$/),
+ issuerNameHash: expect.stringMatching(/^[a-fA-F0-9]+$/),
+ serialNumber: expect.any(String),
+}
+
+await describe('OCPP20CertificateManager', async () => {
+ await describe('storeCertificate', async () => {
+ await it('Should store a valid PEM certificate to the correct path', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const result = await manager.storeCertificate(
+ TEST_STATION_HASH_ID,
+ TEST_CERT_TYPE,
+ VALID_PEM_CERTIFICATE
+ )
+
+ expect(result).toBeDefined()
+ expect(result.success).toBe(true)
+ expect(result.filePath).toContain(TEST_STATION_HASH_ID)
+ expect(result.filePath).toContain('certs')
+ expect(result.filePath).toMatch(/\.pem$/)
+ })
+
+ await it('Should reject invalid PEM certificate without BEGIN/END markers', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const result = await manager.storeCertificate(
+ TEST_STATION_HASH_ID,
+ TEST_CERT_TYPE,
+ INVALID_PEM_NO_MARKERS
+ )
+
+ expect(result).toBeDefined()
+ expect(result.success).toBe(false)
+ expect(result.error).toContain('Invalid PEM format')
+ })
+
+ await it('Should reject empty certificate data', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const result = await manager.storeCertificate(
+ TEST_STATION_HASH_ID,
+ TEST_CERT_TYPE,
+ EMPTY_PEM_CERTIFICATE
+ )
+
+ expect(result).toBeDefined()
+ expect(result.success).toBe(false)
+ expect(result.error).toBeDefined()
+ })
+
+ await it('Should create certificate directory structure if not exists', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const result = await manager.storeCertificate(
+ TEST_STATION_HASH_ID,
+ InstallCertificateUseEnumType.V2GRootCertificate,
+ VALID_PEM_CERTIFICATE
+ )
+
+ expect(result).toBeDefined()
+ expect(result.success).toBe(true)
+ expect(result.filePath).toContain('V2GRootCertificate')
+ })
+ })
+
+ await describe('deleteCertificate', async () => {
+ await it('Should delete certificate by hash data', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const hashData: CertificateHashDataType = {
+ hashAlgorithm: HashAlgorithmEnumType.SHA256,
+ issuerKeyHash: 'abc123def456',
+ issuerNameHash: 'xyz789abc012',
+ serialNumber: 'SN-12345',
+ }
+
+ const result = await manager.deleteCertificate(TEST_STATION_HASH_ID, hashData)
+
+ expect(result).toBeDefined()
+ expect(result.status).toBeDefined()
+ expect(['Accepted', 'NotFound', 'Failed']).toContain(result.status)
+ })
+
+ await it('Should return NotFound for non-existent certificate', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const hashData: CertificateHashDataType = {
+ hashAlgorithm: HashAlgorithmEnumType.SHA256,
+ issuerKeyHash: 'non-existent-hash',
+ issuerNameHash: 'non-existent-hash',
+ serialNumber: 'NON-EXISTENT-SN',
+ }
+
+ const result = await manager.deleteCertificate(TEST_STATION_HASH_ID, hashData)
+
+ expect(result).toBeDefined()
+ expect(result.status).toBe('NotFound')
+ })
+
+ await it('Should handle filesystem errors gracefully', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const hashData: CertificateHashDataType = {
+ hashAlgorithm: HashAlgorithmEnumType.SHA256,
+ issuerKeyHash: 'valid-hash',
+ issuerNameHash: 'valid-hash',
+ serialNumber: 'VALID-SN',
+ }
+
+ const result = await manager.deleteCertificate('invalid-station-id', hashData)
+
+ expect(result).toBeDefined()
+ expect(['NotFound', 'Failed']).toContain(result.status)
+ })
+ })
+
+ await describe('getInstalledCertificates', async () => {
+ await it('Should return list of installed certificates for station', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const result = await manager.getInstalledCertificates(TEST_STATION_HASH_ID)
+
+ expect(result).toBeDefined()
+ expect(Array.isArray(result.certificateHashDataChain)).toBe(true)
+ })
+
+ await it('Should filter certificates by type when filter provided', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const filterTypes = [InstallCertificateUseEnumType.CSMSRootCertificate]
+ const result = await manager.getInstalledCertificates(TEST_STATION_HASH_ID, filterTypes)
+
+ expect(result).toBeDefined()
+ expect(Array.isArray(result.certificateHashDataChain)).toBe(true)
+ })
+
+ await it('Should return empty list when no certificates installed', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const result = await manager.getInstalledCertificates('empty-station-hash-id')
+
+ expect(result).toBeDefined()
+ expect(result.certificateHashDataChain).toHaveLength(0)
+ })
+
+ await it('Should support multiple certificate type filters', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const filterTypes = [
+ InstallCertificateUseEnumType.CSMSRootCertificate,
+ InstallCertificateUseEnumType.V2GRootCertificate,
+ InstallCertificateUseEnumType.ManufacturerRootCertificate,
+ ]
+ const result = await manager.getInstalledCertificates(TEST_STATION_HASH_ID, filterTypes)
+
+ expect(result).toBeDefined()
+ expect(Array.isArray(result.certificateHashDataChain)).toBe(true)
+ })
+ })
+
+ await describe('computeCertificateHash', async () => {
+ await it('Should compute hash data for valid PEM certificate', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const hashData = manager.computeCertificateHash(VALID_PEM_CERTIFICATE)
+
+ expect(hashData).toBeDefined()
+ expect(hashData.hashAlgorithm).toBe(HashAlgorithmEnumType.SHA256)
+ expect(hashData.issuerNameHash).toBeDefined()
+ expect(typeof hashData.issuerNameHash).toBe('string')
+ expect(hashData.issuerKeyHash).toBeDefined()
+ expect(typeof hashData.issuerKeyHash).toBe('string')
+ expect(hashData.serialNumber).toBeDefined()
+ expect(typeof hashData.serialNumber).toBe('string')
+ })
+
+ await it('Should return hex-encoded hash values', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const hashData = manager.computeCertificateHash(VALID_PEM_CERTIFICATE)
+
+ const hexPattern = /^[a-fA-F0-9]+$/
+ expect(hashData.issuerNameHash).toMatch(hexPattern)
+ expect(hashData.issuerKeyHash).toMatch(hexPattern)
+ })
+
+ await it('Should throw error for invalid PEM certificate', () => {
+ const manager = new OCPP20CertificateManager()
+
+ expect(() => {
+ manager.computeCertificateHash(INVALID_PEM_NO_MARKERS)
+ }).toThrow()
+ })
+
+ await it('Should throw error for empty certificate', () => {
+ const manager = new OCPP20CertificateManager()
+
+ expect(() => {
+ manager.computeCertificateHash(EMPTY_PEM_CERTIFICATE)
+ }).toThrow()
+ })
+
+ await it('Should support SHA384 hash algorithm', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const hashData = manager.computeCertificateHash(
+ VALID_PEM_CERTIFICATE,
+ HashAlgorithmEnumType.SHA384
+ )
+
+ expect(hashData).toBeDefined()
+ expect(hashData.hashAlgorithm).toBe(HashAlgorithmEnumType.SHA384)
+ })
+
+ await it('Should support SHA512 hash algorithm', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const hashData = manager.computeCertificateHash(
+ VALID_PEM_CERTIFICATE,
+ HashAlgorithmEnumType.SHA512
+ )
+
+ expect(hashData).toBeDefined()
+ expect(hashData.hashAlgorithm).toBe(HashAlgorithmEnumType.SHA512)
+ })
+ })
+
+ await describe('validateCertificateFormat', async () => {
+ await it('Should return true for valid PEM certificate', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const isValid = manager.validateCertificateFormat(VALID_PEM_CERTIFICATE)
+
+ expect(isValid).toBe(true)
+ })
+
+ await it('Should return false for certificate without BEGIN marker', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const isValid = manager.validateCertificateFormat(INVALID_PEM_NO_MARKERS)
+
+ expect(isValid).toBe(false)
+ })
+
+ await it('Should return false for certificate with wrong markers', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const isValid = manager.validateCertificateFormat(INVALID_PEM_WRONG_MARKERS)
+
+ expect(isValid).toBe(false)
+ })
+
+ await it('Should return false for empty string', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const isValid = manager.validateCertificateFormat(EMPTY_PEM_CERTIFICATE)
+
+ expect(isValid).toBe(false)
+ })
+
+ await it('Should return false for null/undefined input', () => {
+ const manager = new OCPP20CertificateManager()
+
+ expect(manager.validateCertificateFormat(null as any)).toBe(false)
+ expect(manager.validateCertificateFormat(undefined as any)).toBe(false)
+ })
+
+ await it('Should return true for certificate with extra whitespace', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const pemWithWhitespace = `
+
+ -----BEGIN CERTIFICATE-----
+ MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiUMA0GCSqGSIb3Qq8teleNzMHjvLuHvVsY
+ -----END CERTIFICATE-----
+
+ `
+
+ const isValid = manager.validateCertificateFormat(pemWithWhitespace)
+
+ expect(isValid).toBe(true)
+ })
+ })
+
+ await describe('getCertificatePath', async () => {
+ await it('Should return correct file path for certificate', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const path = manager.getCertificatePath(TEST_STATION_HASH_ID, TEST_CERT_TYPE, 'SERIAL-12345')
+
+ expect(path).toBeDefined()
+ expect(path).toContain(TEST_STATION_HASH_ID)
+ expect(path).toContain('certs')
+ expect(path).toContain('CSMSRootCertificate')
+ expect(path).toContain('SERIAL-12345')
+ expect(path).toMatch(/\.pem$/)
+ })
+
+ await it('Should handle special characters in serial number', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const path = manager.getCertificatePath(
+ TEST_STATION_HASH_ID,
+ TEST_CERT_TYPE,
+ 'SERIAL:ABC/123'
+ )
+
+ expect(path).toBeDefined()
+ const filename = path.split('/').pop()
+ expect(filename).not.toContain(':')
+ expect(filename).not.toContain('/')
+ })
+
+ await it('Should return different paths for different certificate types', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const csmsPath = manager.getCertificatePath(
+ TEST_STATION_HASH_ID,
+ InstallCertificateUseEnumType.CSMSRootCertificate,
+ 'SERIAL-001'
+ )
+
+ const v2gPath = manager.getCertificatePath(
+ TEST_STATION_HASH_ID,
+ InstallCertificateUseEnumType.V2GRootCertificate,
+ 'SERIAL-001'
+ )
+
+ expect(csmsPath).not.toBe(v2gPath)
+ expect(csmsPath).toContain('CSMSRootCertificate')
+ expect(v2gPath).toContain('V2GRootCertificate')
+ })
+
+ await it('Should return path following project convention', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const path = manager.getCertificatePath(TEST_STATION_HASH_ID, TEST_CERT_TYPE, 'SERIAL-12345')
+
+ expect(path).toMatch(/configurations/)
+ expect(path).toMatch(/certs/)
+ expect(path).toMatch(/\.pem$/)
+ })
+ })
+
+ await describe('Edge cases and error handling', async () => {
+ await it('Should handle concurrent certificate operations', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const results = await Promise.all([
+ manager.storeCertificate(
+ TEST_STATION_HASH_ID,
+ InstallCertificateUseEnumType.CSMSRootCertificate,
+ VALID_PEM_CERTIFICATE
+ ),
+ manager.storeCertificate(
+ TEST_STATION_HASH_ID,
+ InstallCertificateUseEnumType.V2GRootCertificate,
+ VALID_PEM_CERTIFICATE
+ ),
+ manager.getInstalledCertificates(TEST_STATION_HASH_ID),
+ ])
+
+ expect(results).toHaveLength(3)
+ results.forEach(result => {
+ expect(result).toBeDefined()
+ })
+ })
+
+ await it('Should handle very long certificate chains', async () => {
+ const manager = new OCPP20CertificateManager()
+
+ const longChain = Array(5).fill(VALID_PEM_CERTIFICATE).join('\n')
+
+ const result = await manager.storeCertificate(TEST_STATION_HASH_ID, TEST_CERT_TYPE, longChain)
+
+ expect(result).toBeDefined()
+ })
+
+ await it('Should sanitize station hash ID for filesystem safety', () => {
+ const manager = new OCPP20CertificateManager()
+
+ const maliciousHashId = '../../../etc/passwd'
+
+ const path = manager.getCertificatePath(maliciousHashId, TEST_CERT_TYPE, 'SERIAL-001')
+
+ expect(path).not.toContain('..')
+ })
+ })
+})
--- /dev/null
+/* eslint-disable @typescript-eslint/no-unsafe-member-access */
+/* eslint-disable @typescript-eslint/no-unsafe-assignment */
+/* eslint-disable @typescript-eslint/no-unsafe-call */
+/* eslint-disable @typescript-eslint/no-explicit-any */
+
+import { expect } from '@std/expect'
+import { describe, it, mock } from 'node:test'
+
+import { OCPP20IncomingRequestService } from '../../../../src/charging-station/ocpp/2.0/OCPP20IncomingRequestService.js'
+import {
+ CertificateSigningUseEnumType,
+ GenericStatus,
+ type OCPP20CertificateSignedRequest,
+ type OCPP20CertificateSignedResponse,
+ OCPPVersion,
+} from '../../../../src/types/index.js'
+import { Constants } from '../../../../src/utils/index.js'
+import { createChargingStation } from '../../../ChargingStationFactory.js'
+import { TEST_CHARGING_STATION_BASE_NAME } from './OCPP20TestConstants.js'
+
+const VALID_PEM_CERTIFICATE = `-----BEGIN CERTIFICATE-----
+MIIBkTCB+wIJAKHBfpvPA0GXMA0GCSqGSIb3DQEBCwUAMBExDzANBgNVBAMMBnRl
+c3RDQTAeFw0yNDAxMDEwMDAwMDBaFw0yOTAxMDEwMDAwMDBaMBExDzANBgNVBAMM
+BnRlc3RDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC5p8U8zTk8TT5H5s8mjxJz
+p+eDAh+xW1+eTprjqD4vfQSXCv8hC3TlPpZwHk8C5dJmEp8Dqv3lAO5bVkzzqbhR
+AgMBAAGjUzBRMB0GA1UdDgQWBBRc8RqFu0nnqJdw3f9nFVXm9BxeUDAfBgNVHSME
+GDAWgBRc8RqFu0nnqJdw3f9nFVXm9BxeUDAPBgNVHRMBAf8EBTADAQH/MA0GCSqG
+SIb3DQEBCwUAA0EAYw7K5EKcJGj8TH7NpP3L3hRPZF8qU5QfT0zQBqBm4U5JtDnS
+nFUewM7PNhYJsWjJRpLdAL1kC6x8bW1kQ5FVUQ==
+-----END CERTIFICATE-----`
+
+const VALID_CERTIFICATE_CHAIN = `-----BEGIN CERTIFICATE-----
+MIIBkTCB+wIJAKHBfpvPA0GXMA0GCSqGSIb3DQEBCwUAMBExDzANBgNVBAMMBnRl
+c3RDQTAeFw0yNDAxMDEwMDAwMDBaFw0yOTAxMDEwMDAwMDBaMBExDzANBgNVBAMM
+BnRlc3RDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC5p8U8zTk8TT5H5s8mjxJz
+p+eDAh+xW1+eTprjqD4vfQSXCv8hC3TlPpZwHk8C5dJmEp8Dqv3lAO5bVkzzqbhR
+AgMBAAGjUzBRMB0GA1UdDgQWBBRc8RqFu0nnqJdw3f9nFVXm9BxeUDAfBgNVHSME
+GDAWgBRc8RqFu0nnqJdw3f9nFVXm9BxeUDAPBgNVHRMBAf8EBTADAQH/MA0GCSqG
+SIb3DQEBCwUAA0EAYw7K5EKcJGj8TH7NpP3L3hRPZF8qU5QfT0zQBqBm4U5JtDnS
+nFUewM7PNhYJsWjJRpLdAL1kC6x8bW1kQ5FVUQ==
+-----END CERTIFICATE-----
+-----BEGIN CERTIFICATE-----
+MIIBkTCB+wIJAKHBfpvPA0GYMA0GCSqGSIb3DQEBCwUAMBExDzANBgNVBAMMBnRl
+c3RDQTAeFw0yNDAxMDEwMDAwMDBaFw0yOTAxMDEwMDAwMDBaMBExDzANBgNVBAMM
+BnRlc3RDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC5p8U8zTk8TT5H5s8mjxJz
+p+eDAh+xW1+eTprjqD4vfQSXCv8hC3TlPpZwHk8C5dJmEp8Dqv3lAO5bVkzzqbhR
+AgMBAAGjUzBRMB0GA1UdDgQWBBRc8RqFu0nnqJdw3f9nFVXm9BxeUDAfBgNVHSME
+GDAWgBRc8RqFu0nnqJdw3f9nFVXm9BxeUDAPBgNVHRMBAf8EBTADAQH/MA0GCSqG
+SIb3DQEBCwUAA0EAYw7K5EKcJGj8TH7NpP3L3hRPZF8qU5QfT0zQBqBm4U5JtDnS
+nFUewM7PNhYJsWjJRpLdAL1kC6x8bW1kQ5FVUQ==
+-----END CERTIFICATE-----`
+
+const INVALID_PEM_CERTIFICATE_MISSING_MARKERS = `MIIBkTCB+wIJAKHBfpvPA0GXMA0GCSqGSIb3DQEBCwUAMBExDzANBgNVBAMMBn
+Rlc3RDQTAeFw0yNDAxMDEwMDAwMDBaFw0yOTAxMDEwMDAwMDBaMBExDzANBgNVBA
+MMBnRlc3RDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC5p8U8zTk8TT5H5s8mjx`
+
+const createMockCertificateManager = (
+ options: {
+ storeCertificateError?: Error
+ storeCertificateResult?: boolean
+ } = {}
+) => ({
+ deleteCertificate: mock.fn(),
+ getInstalledCertificates: mock.fn(() => []),
+ storeCertificate: mock.fn(() => {
+ if (options.storeCertificateError) {
+ throw options.storeCertificateError
+ }
+ return options.storeCertificateResult ?? true
+ }),
+ validateCertificateFormat: mock.fn((cert: string) => {
+ return (
+ cert.includes('-----BEGIN CERTIFICATE-----') && cert.includes('-----END CERTIFICATE-----')
+ )
+ }),
+})
+
+await describe('I04 - CertificateSigned', async () => {
+ const mockChargingStation = createChargingStation({
+ baseName: TEST_CHARGING_STATION_BASE_NAME,
+ connectorsCount: 3,
+ evseConfiguration: { evsesCount: 3 },
+ heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
+ stationInfo: {
+ ocppStrictCompliance: false,
+ ocppVersion: OCPPVersion.VERSION_201,
+ },
+ websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
+ })
+
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager()
+ // Mock closeWSConnection for reconnect tests
+ ;(mockChargingStation as any).closeWSConnection = mock.fn()
+
+ const incomingRequestService = new OCPP20IncomingRequestService()
+
+ await describe('Valid Certificate Chain Installation', async () => {
+ await it('Should accept valid certificate chain', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ storeCertificateResult: true,
+ })
+
+ const request: OCPP20CertificateSignedRequest = {
+ certificateChain: VALID_CERTIFICATE_CHAIN,
+ certificateType: CertificateSigningUseEnumType.ChargingStationCertificate,
+ }
+
+ const response: OCPP20CertificateSignedResponse = await (
+ incomingRequestService as any
+ ).handleRequestCertificateSigned(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(typeof response).toBe('object')
+ expect(response.status).toBeDefined()
+ expect(typeof response.status).toBe('string')
+ expect(response.status).toBe(GenericStatus.Accepted)
+ })
+
+ await it('Should accept single certificate (no chain)', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ storeCertificateResult: true,
+ })
+
+ const request: OCPP20CertificateSignedRequest = {
+ certificateChain: VALID_PEM_CERTIFICATE,
+ certificateType: CertificateSigningUseEnumType.V2GCertificate,
+ }
+
+ const response: OCPP20CertificateSignedResponse = await (
+ incomingRequestService as any
+ ).handleRequestCertificateSigned(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GenericStatus.Accepted)
+ expect(response.statusInfo).toBeUndefined()
+ })
+ })
+
+ await describe('Invalid Certificate Handling', async () => {
+ await it('Should reject certificate with invalid PEM format', async () => {
+ const request: OCPP20CertificateSignedRequest = {
+ certificateChain: INVALID_PEM_CERTIFICATE_MISSING_MARKERS,
+ certificateType: CertificateSigningUseEnumType.ChargingStationCertificate,
+ }
+
+ const response: OCPP20CertificateSignedResponse = await (
+ incomingRequestService as any
+ ).handleRequestCertificateSigned(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GenericStatus.Rejected)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBeDefined()
+ expect(typeof response.statusInfo?.reasonCode).toBe('string')
+ })
+ })
+
+ await describe('ChargingStationCertificate Reconnect Logic', async () => {
+ await it('Should trigger websocket reconnect for ChargingStationCertificate type', async () => {
+ const mockCertManager = createMockCertificateManager({
+ storeCertificateResult: true,
+ })
+ ;(mockChargingStation as any).certificateManager = mockCertManager
+ const mockCloseWSConnection = mock.fn()
+ ;(mockChargingStation as any).closeWSConnection = mockCloseWSConnection
+
+ const request: OCPP20CertificateSignedRequest = {
+ certificateChain: VALID_PEM_CERTIFICATE,
+ certificateType: CertificateSigningUseEnumType.ChargingStationCertificate,
+ }
+
+ const response: OCPP20CertificateSignedResponse = await (
+ incomingRequestService as any
+ ).handleRequestCertificateSigned(mockChargingStation, request)
+
+ expect(response.status).toBe(GenericStatus.Accepted)
+ // Verify closeWSConnection was called to trigger reconnect
+ expect(mockCloseWSConnection.mock.calls.length).toBeGreaterThan(0)
+ })
+ })
+
+ await describe('V2GCertificate Storage', async () => {
+ await it('Should store V2GCertificate separately without reconnect', async () => {
+ const mockCertManager = createMockCertificateManager({
+ storeCertificateResult: true,
+ })
+ ;(mockChargingStation as any).certificateManager = mockCertManager
+ const mockCloseWSConnection = mock.fn()
+ ;(mockChargingStation as any).closeWSConnection = mockCloseWSConnection
+
+ const request: OCPP20CertificateSignedRequest = {
+ certificateChain: VALID_PEM_CERTIFICATE,
+ certificateType: CertificateSigningUseEnumType.V2GCertificate,
+ }
+
+ const response: OCPP20CertificateSignedResponse = await (
+ incomingRequestService as any
+ ).handleRequestCertificateSigned(mockChargingStation, request)
+
+ expect(response.status).toBe(GenericStatus.Accepted)
+ // Verify storeCertificate was called
+ expect(mockCertManager.storeCertificate.mock.calls.length).toBeGreaterThan(0)
+ // Verify closeWSConnection was NOT called for V2GCertificate
+ expect(mockCloseWSConnection.mock.calls.length).toBe(0)
+ })
+ })
+
+ await describe('Certificate Manager Missing', async () => {
+ await it('Should return Rejected status with InternalError when certificate manager is missing', async () => {
+ // Create a separate mock charging station without certificateManager
+ const stationWithoutCertManager = createChargingStation({
+ baseName: TEST_CHARGING_STATION_BASE_NAME,
+ connectorsCount: 1,
+ evseConfiguration: { evsesCount: 1 },
+ heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
+ stationInfo: {
+ ocppStrictCompliance: false,
+ ocppVersion: OCPPVersion.VERSION_201,
+ },
+ websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
+ })
+
+ // Ensure certificateManager is null/undefined
+ delete (stationWithoutCertManager as any).certificateManager
+
+ const request: OCPP20CertificateSignedRequest = {
+ certificateChain: VALID_PEM_CERTIFICATE,
+ certificateType: CertificateSigningUseEnumType.ChargingStationCertificate,
+ }
+
+ const response: OCPP20CertificateSignedResponse = await (
+ incomingRequestService as any
+ ).handleRequestCertificateSigned(stationWithoutCertManager, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GenericStatus.Rejected)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBe('InternalError')
+ })
+ })
+
+ await describe('Storage Failure Handling', async () => {
+ await it('Should return Rejected status when storage fails', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ storeCertificateResult: false,
+ })
+
+ const request: OCPP20CertificateSignedRequest = {
+ certificateChain: VALID_PEM_CERTIFICATE,
+ certificateType: CertificateSigningUseEnumType.ChargingStationCertificate,
+ }
+
+ const response: OCPP20CertificateSignedResponse = await (
+ incomingRequestService as any
+ ).handleRequestCertificateSigned(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GenericStatus.Rejected)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBeDefined()
+ })
+
+ await it('Should return Rejected status when storage throws error', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ storeCertificateError: new Error('Storage full'),
+ })
+
+ const request: OCPP20CertificateSignedRequest = {
+ certificateChain: VALID_PEM_CERTIFICATE,
+ certificateType: CertificateSigningUseEnumType.V2GCertificate,
+ }
+
+ const response: OCPP20CertificateSignedResponse = await (
+ incomingRequestService as any
+ ).handleRequestCertificateSigned(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GenericStatus.Rejected)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBeDefined()
+ })
+ })
+
+ await describe('Response Structure Validation', async () => {
+ await it('Should return response matching CertificateSignedResponse schema', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ storeCertificateResult: true,
+ })
+
+ const request: OCPP20CertificateSignedRequest = {
+ certificateChain: VALID_PEM_CERTIFICATE,
+ certificateType: CertificateSigningUseEnumType.ChargingStationCertificate,
+ }
+
+ const response: OCPP20CertificateSignedResponse = await (
+ incomingRequestService as any
+ ).handleRequestCertificateSigned(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(typeof response).toBe('object')
+
+ // status is required
+ expect(response.status).toBeDefined()
+ expect([GenericStatus.Accepted, GenericStatus.Rejected]).toContain(response.status)
+
+ // statusInfo is optional but if present must have reasonCode
+ if (response.statusInfo != null) {
+ expect(response.statusInfo.reasonCode).toBeDefined()
+ expect(typeof response.statusInfo.reasonCode).toBe('string')
+ if (response.statusInfo.additionalInfo != null) {
+ expect(typeof response.statusInfo.additionalInfo).toBe('string')
+ }
+ }
+
+ // customData is optional but if present must have vendorId
+ if (response.customData != null) {
+ expect(response.customData.vendorId).toBeDefined()
+ expect(typeof response.customData.vendorId).toBe('string')
+ }
+ })
+
+ await it('Should include statusInfo with reasonCode for rejection', async () => {
+ const request: OCPP20CertificateSignedRequest = {
+ certificateChain: INVALID_PEM_CERTIFICATE_MISSING_MARKERS,
+ certificateType: CertificateSigningUseEnumType.ChargingStationCertificate,
+ }
+
+ const response: OCPP20CertificateSignedResponse = await (
+ incomingRequestService as any
+ ).handleRequestCertificateSigned(mockChargingStation, request)
+
+ expect(response.status).toBe(GenericStatus.Rejected)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBeDefined()
+ expect(typeof response.statusInfo?.reasonCode).toBe('string')
+ expect(response.statusInfo?.reasonCode.length).toBeGreaterThan(0)
+ expect(response.statusInfo?.reasonCode.length).toBeLessThanOrEqual(20)
+ })
+ })
+})
--- /dev/null
+/* eslint-disable @typescript-eslint/no-unsafe-member-access */
+/* eslint-disable @typescript-eslint/no-unsafe-assignment */
+/* eslint-disable @typescript-eslint/no-unsafe-call */
+/* eslint-disable @typescript-eslint/no-explicit-any */
+
+import { expect } from '@std/expect'
+import { describe, it, mock } from 'node:test'
+
+import { OCPP20IncomingRequestService } from '../../../../src/charging-station/ocpp/2.0/OCPP20IncomingRequestService.js'
+import {
+ DeleteCertificateStatusEnumType,
+ HashAlgorithmEnumType,
+ type OCPP20DeleteCertificateRequest,
+ type OCPP20DeleteCertificateResponse,
+ OCPPVersion,
+ ReasonCodeEnumType,
+} from '../../../../src/types/index.js'
+import { Constants } from '../../../../src/utils/index.js'
+import { createChargingStation } from '../../../ChargingStationFactory.js'
+import { TEST_CHARGING_STATION_BASE_NAME } from './OCPP20TestConstants.js'
+
+const VALID_CERTIFICATE_HASH_DATA = {
+ hashAlgorithm: HashAlgorithmEnumType.SHA256,
+ issuerKeyHash: 'a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2',
+ issuerNameHash: 'f6e5d4c3b2a1f6e5d4c3b2a1f6e5d4c3b2a1f6e5d4c3b2a1f6e5d4c3b2a1f6e5',
+ serialNumber: '1234567890ABCDEF',
+}
+
+const NONEXISTENT_CERTIFICATE_HASH_DATA = {
+ hashAlgorithm: HashAlgorithmEnumType.SHA256,
+ issuerKeyHash: '0000000000000000000000000000000000000000000000000000000000000000',
+ issuerNameHash: '0000000000000000000000000000000000000000000000000000000000000000',
+ serialNumber: 'NONEXISTENT123456',
+}
+
+const createMockCertificateManager = (
+ options: {
+ deleteCertificateError?: Error
+ deleteCertificateResult?: { status: 'Accepted' | 'Failed' | 'NotFound' }
+ } = {}
+) => ({
+ deleteCertificate: mock.fn(() => {
+ if (options.deleteCertificateError) {
+ throw options.deleteCertificateError
+ }
+ return options.deleteCertificateResult ?? { status: 'Accepted' }
+ }),
+ getInstalledCertificates: mock.fn(() => []),
+ storeCertificate: mock.fn(() => true),
+ validateCertificateFormat: mock.fn(() => true),
+})
+
+await describe('I04 - DeleteCertificate', async () => {
+ const mockChargingStation = createChargingStation({
+ baseName: TEST_CHARGING_STATION_BASE_NAME,
+ connectorsCount: 3,
+ evseConfiguration: { evsesCount: 3 },
+ heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
+ stationInfo: {
+ ocppStrictCompliance: false,
+ ocppVersion: OCPPVersion.VERSION_201,
+ },
+ websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
+ })
+
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager()
+
+ const incomingRequestService = new OCPP20IncomingRequestService()
+
+ await describe('Valid Certificate Deletion', async () => {
+ await it('Should accept deletion of existing certificate', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ deleteCertificateResult: { status: 'Accepted' },
+ })
+
+ const request: OCPP20DeleteCertificateRequest = {
+ certificateHashData: VALID_CERTIFICATE_HASH_DATA,
+ }
+
+ const response: OCPP20DeleteCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestDeleteCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(typeof response).toBe('object')
+ expect(response.status).toBeDefined()
+ expect(typeof response.status).toBe('string')
+ expect(response.status).toBe(DeleteCertificateStatusEnumType.Accepted)
+ expect(response.statusInfo).toBeUndefined()
+ })
+
+ await it('Should accept deletion with SHA384 hash algorithm', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ deleteCertificateResult: { status: 'Accepted' },
+ })
+
+ const request: OCPP20DeleteCertificateRequest = {
+ certificateHashData: {
+ ...VALID_CERTIFICATE_HASH_DATA,
+ hashAlgorithm: HashAlgorithmEnumType.SHA384,
+ },
+ }
+
+ const response: OCPP20DeleteCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestDeleteCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(DeleteCertificateStatusEnumType.Accepted)
+ expect(response.statusInfo).toBeUndefined()
+ })
+
+ await it('Should accept deletion with SHA512 hash algorithm', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ deleteCertificateResult: { status: 'Accepted' },
+ })
+
+ const request: OCPP20DeleteCertificateRequest = {
+ certificateHashData: {
+ ...VALID_CERTIFICATE_HASH_DATA,
+ hashAlgorithm: HashAlgorithmEnumType.SHA512,
+ },
+ }
+
+ const response: OCPP20DeleteCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestDeleteCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(DeleteCertificateStatusEnumType.Accepted)
+ expect(response.statusInfo).toBeUndefined()
+ })
+ })
+
+ await describe('Certificate Not Found', async () => {
+ await it('Should return NotFound for non-existent certificate', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ deleteCertificateResult: { status: 'NotFound' },
+ })
+
+ const request: OCPP20DeleteCertificateRequest = {
+ certificateHashData: NONEXISTENT_CERTIFICATE_HASH_DATA,
+ }
+
+ const response: OCPP20DeleteCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestDeleteCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(DeleteCertificateStatusEnumType.NotFound)
+ })
+ })
+
+ await describe('Deletion Failure Handling', async () => {
+ await it('Should return Failed status when deletion throws error', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ deleteCertificateError: new Error('Deletion failed'),
+ })
+
+ const request: OCPP20DeleteCertificateRequest = {
+ certificateHashData: VALID_CERTIFICATE_HASH_DATA,
+ }
+
+ const response: OCPP20DeleteCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestDeleteCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(DeleteCertificateStatusEnumType.Failed)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBeDefined()
+ })
+
+ await it('Should return Failed with InternalError when certificateManager is missing', async () => {
+ const stationWithoutCertManager = createChargingStation({
+ baseName: TEST_CHARGING_STATION_BASE_NAME,
+ connectorsCount: 3,
+ evseConfiguration: { evsesCount: 3 },
+ heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
+ stationInfo: {
+ ocppStrictCompliance: false,
+ ocppVersion: OCPPVersion.VERSION_201,
+ },
+ websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
+ })
+
+ ;(stationWithoutCertManager as any).certificateManager = undefined
+
+ const request: OCPP20DeleteCertificateRequest = {
+ certificateHashData: VALID_CERTIFICATE_HASH_DATA,
+ }
+
+ const response: OCPP20DeleteCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestDeleteCertificate(stationWithoutCertManager, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(DeleteCertificateStatusEnumType.Failed)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBe(ReasonCodeEnumType.InternalError)
+ })
+ })
+
+ await describe('Response Structure Validation', async () => {
+ await it('Should return response matching DeleteCertificateResponse schema', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ deleteCertificateResult: { status: 'Accepted' },
+ })
+
+ const request: OCPP20DeleteCertificateRequest = {
+ certificateHashData: VALID_CERTIFICATE_HASH_DATA,
+ }
+
+ const response: OCPP20DeleteCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestDeleteCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(typeof response).toBe('object')
+
+ expect(response.status).toBeDefined()
+ expect([
+ DeleteCertificateStatusEnumType.Accepted,
+ DeleteCertificateStatusEnumType.NotFound,
+ DeleteCertificateStatusEnumType.Failed,
+ ]).toContain(response.status)
+
+ if (response.statusInfo != null) {
+ expect(response.statusInfo.reasonCode).toBeDefined()
+ expect(typeof response.statusInfo.reasonCode).toBe('string')
+ if (response.statusInfo.additionalInfo != null) {
+ expect(typeof response.statusInfo.additionalInfo).toBe('string')
+ }
+ }
+
+ if (response.customData != null) {
+ expect(response.customData.vendorId).toBeDefined()
+ expect(typeof response.customData.vendorId).toBe('string')
+ }
+ })
+
+ await it('Should include statusInfo with reasonCode for failure', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ deleteCertificateError: new Error('Deletion failed'),
+ })
+
+ const request: OCPP20DeleteCertificateRequest = {
+ certificateHashData: VALID_CERTIFICATE_HASH_DATA,
+ }
+
+ const response: OCPP20DeleteCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestDeleteCertificate(mockChargingStation, request)
+
+ expect(response.status).toBe(DeleteCertificateStatusEnumType.Failed)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBeDefined()
+ expect(typeof response.statusInfo?.reasonCode).toBe('string')
+ expect(response.statusInfo?.reasonCode.length).toBeGreaterThan(0)
+ expect(response.statusInfo?.reasonCode.length).toBeLessThanOrEqual(20)
+ })
+ })
+})
--- /dev/null
+/* eslint-disable @typescript-eslint/no-unsafe-member-access */
+/* eslint-disable @typescript-eslint/no-unsafe-assignment */
+/* eslint-disable @typescript-eslint/no-unsafe-call */
+/* eslint-disable @typescript-eslint/no-explicit-any */
+
+import { expect } from '@std/expect'
+import { describe, it, mock } from 'node:test'
+
+import { OCPP20IncomingRequestService } from '../../../../src/charging-station/ocpp/2.0/OCPP20IncomingRequestService.js'
+import {
+ type CertificateHashDataChainType,
+ type CertificateHashDataType,
+ GetCertificateIdUseEnumType,
+ GetInstalledCertificateStatusEnumType,
+ HashAlgorithmEnumType,
+ type OCPP20GetInstalledCertificateIdsRequest,
+ type OCPP20GetInstalledCertificateIdsResponse,
+ OCPPVersion,
+} from '../../../../src/types/index.js'
+import { Constants } from '../../../../src/utils/index.js'
+import { createChargingStation } from '../../../ChargingStationFactory.js'
+import { TEST_CHARGING_STATION_BASE_NAME } from './OCPP20TestConstants.js'
+
+const createMockCertificateHashData = (serialNumber = '123456789'): CertificateHashDataType => ({
+ hashAlgorithm: HashAlgorithmEnumType.SHA256,
+ issuerKeyHash: 'abc123def456',
+ issuerNameHash: 'xyz789uvw012',
+ serialNumber,
+})
+
+const createMockCertificateHashDataChain = (
+ certificateType: GetCertificateIdUseEnumType,
+ serialNumber = '123456789'
+): CertificateHashDataChainType => ({
+ certificateHashData: createMockCertificateHashData(serialNumber),
+ certificateType,
+})
+
+const createMockCertificateManager = (
+ options: {
+ getInstalledCertificatesError?: Error
+ getInstalledCertificatesResult?: CertificateHashDataChainType[]
+ } = {}
+) => ({
+ deleteCertificate: mock.fn(),
+ getInstalledCertificates: mock.fn(() => {
+ if (options.getInstalledCertificatesError) {
+ throw options.getInstalledCertificatesError
+ }
+ return {
+ certificateHashDataChain: options.getInstalledCertificatesResult ?? [],
+ }
+ }),
+ storeCertificate: mock.fn(() => true),
+ validateCertificateFormat: mock.fn(() => true),
+})
+
+await describe('I04 - GetInstalledCertificateIds', async () => {
+ const mockChargingStation = createChargingStation({
+ baseName: TEST_CHARGING_STATION_BASE_NAME,
+ connectorsCount: 3,
+ evseConfiguration: { evsesCount: 3 },
+ heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
+ stationInfo: {
+ ocppStrictCompliance: false,
+ ocppVersion: OCPPVersion.VERSION_201,
+ },
+ websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
+ })
+
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager()
+
+ const incomingRequestService = new OCPP20IncomingRequestService()
+
+ await describe('Request All Certificate Types', async () => {
+ await it('Should return all certificates when no filter is provided', async () => {
+ const mockCerts: CertificateHashDataChainType[] = [
+ createMockCertificateHashDataChain(GetCertificateIdUseEnumType.V2GRootCertificate, '111'),
+ createMockCertificateHashDataChain(GetCertificateIdUseEnumType.MORootCertificate, '222'),
+ createMockCertificateHashDataChain(GetCertificateIdUseEnumType.CSMSRootCertificate, '333'),
+ ]
+
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ getInstalledCertificatesResult: mockCerts,
+ })
+
+ const request: OCPP20GetInstalledCertificateIdsRequest = {}
+
+ const response: OCPP20GetInstalledCertificateIdsResponse = await (
+ incomingRequestService as any
+ ).handleRequestGetInstalledCertificateIds(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GetInstalledCertificateStatusEnumType.Accepted)
+ expect(response.certificateHashDataChain).toBeDefined()
+ expect(Array.isArray(response.certificateHashDataChain)).toBe(true)
+ expect(response.certificateHashDataChain?.length).toBe(3)
+ })
+ })
+
+ await describe('Request Filtered Certificate Types', async () => {
+ await it('Should return only V2GRootCertificate when filtered', async () => {
+ const v2gCert = createMockCertificateHashDataChain(
+ GetCertificateIdUseEnumType.V2GRootCertificate,
+ '111'
+ )
+
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ getInstalledCertificatesResult: [v2gCert],
+ })
+
+ const request: OCPP20GetInstalledCertificateIdsRequest = {
+ certificateType: [GetCertificateIdUseEnumType.V2GRootCertificate],
+ }
+
+ const response: OCPP20GetInstalledCertificateIdsResponse = await (
+ incomingRequestService as any
+ ).handleRequestGetInstalledCertificateIds(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GetInstalledCertificateStatusEnumType.Accepted)
+ expect(response.certificateHashDataChain).toBeDefined()
+ expect(response.certificateHashDataChain?.length).toBe(1)
+ expect(response.certificateHashDataChain?.[0].certificateType).toBe(
+ GetCertificateIdUseEnumType.V2GRootCertificate
+ )
+ })
+
+ await it('Should return multiple types when multiple filters provided', async () => {
+ const mockCerts: CertificateHashDataChainType[] = [
+ createMockCertificateHashDataChain(GetCertificateIdUseEnumType.V2GRootCertificate, '111'),
+ createMockCertificateHashDataChain(GetCertificateIdUseEnumType.CSMSRootCertificate, '222'),
+ ]
+
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ getInstalledCertificatesResult: mockCerts,
+ })
+
+ const request: OCPP20GetInstalledCertificateIdsRequest = {
+ certificateType: [
+ GetCertificateIdUseEnumType.V2GRootCertificate,
+ GetCertificateIdUseEnumType.CSMSRootCertificate,
+ ],
+ }
+
+ const response: OCPP20GetInstalledCertificateIdsResponse = await (
+ incomingRequestService as any
+ ).handleRequestGetInstalledCertificateIds(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GetInstalledCertificateStatusEnumType.Accepted)
+ expect(response.certificateHashDataChain?.length).toBe(2)
+ })
+ })
+
+ await describe('No Certificates Found', async () => {
+ await it('Should return Accepted with empty array when no certificates found', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ getInstalledCertificatesResult: [],
+ })
+
+ const request: OCPP20GetInstalledCertificateIdsRequest = {}
+
+ const response: OCPP20GetInstalledCertificateIdsResponse = await (
+ incomingRequestService as any
+ ).handleRequestGetInstalledCertificateIds(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ // Per OCPP 2.0.1 spec: NotFound is returned when no certificates match the request
+ expect(response.status).toBe(GetInstalledCertificateStatusEnumType.NotFound)
+ // Per OCPP spec: certificateHashDataChain is omitted when empty, not an empty array
+ expect(response.certificateHashDataChain).toBeUndefined()
+ })
+
+ await it('Should return NotFound when filtered type has no certificates', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ getInstalledCertificatesResult: [],
+ })
+
+ const request: OCPP20GetInstalledCertificateIdsRequest = {
+ certificateType: [GetCertificateIdUseEnumType.ManufacturerRootCertificate],
+ }
+
+ const response: OCPP20GetInstalledCertificateIdsResponse = await (
+ incomingRequestService as any
+ ).handleRequestGetInstalledCertificateIds(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GetInstalledCertificateStatusEnumType.NotFound)
+ })
+ })
+
+ await describe('Response Structure Validation', async () => {
+ await it('Should return response with required status field', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ getInstalledCertificatesResult: [],
+ })
+
+ const request: OCPP20GetInstalledCertificateIdsRequest = {}
+
+ const response: OCPP20GetInstalledCertificateIdsResponse = await (
+ incomingRequestService as any
+ ).handleRequestGetInstalledCertificateIds(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(typeof response).toBe('object')
+ expect(response.status).toBeDefined()
+ expect([
+ GetInstalledCertificateStatusEnumType.Accepted,
+ GetInstalledCertificateStatusEnumType.NotFound,
+ ]).toContain(response.status)
+ })
+
+ await it('Should return valid CertificateHashDataChain structure', async () => {
+ const mockCert = createMockCertificateHashDataChain(
+ GetCertificateIdUseEnumType.V2GRootCertificate,
+ '123456'
+ )
+
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ getInstalledCertificatesResult: [mockCert],
+ })
+
+ const request: OCPP20GetInstalledCertificateIdsRequest = {}
+
+ const response: OCPP20GetInstalledCertificateIdsResponse = await (
+ incomingRequestService as any
+ ).handleRequestGetInstalledCertificateIds(mockChargingStation, request)
+
+ expect(response.status).toBe(GetInstalledCertificateStatusEnumType.Accepted)
+ expect(response.certificateHashDataChain).toBeDefined()
+ expect(response.certificateHashDataChain?.length).toBe(1)
+
+ const chain = response.certificateHashDataChain?.[0]
+ expect(chain?.certificateType).toBeDefined()
+ expect(chain?.certificateHashData).toBeDefined()
+ expect(chain?.certificateHashData.hashAlgorithm).toBeDefined()
+ expect(chain?.certificateHashData.issuerNameHash).toBeDefined()
+ expect(chain?.certificateHashData.issuerKeyHash).toBeDefined()
+ expect(chain?.certificateHashData.serialNumber).toBeDefined()
+ })
+ })
+
+ await describe('Certificate Manager Missing', async () => {
+ await it('Should return NotFound when certificate manager is not available', async () => {
+ const stationWithoutCertManager = createChargingStation({
+ baseName: TEST_CHARGING_STATION_BASE_NAME,
+ connectorsCount: 3,
+ evseConfiguration: { evsesCount: 3 },
+ heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
+ stationInfo: {
+ ocppStrictCompliance: false,
+ ocppVersion: OCPPVersion.VERSION_201,
+ },
+ websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
+ })
+
+ // Explicitly set to null/undefined
+ ;(stationWithoutCertManager as any).certificateManager = null
+
+ const request: OCPP20GetInstalledCertificateIdsRequest = {}
+
+ const response: OCPP20GetInstalledCertificateIdsResponse = await (
+ incomingRequestService as any
+ ).handleRequestGetInstalledCertificateIds(stationWithoutCertManager, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GetInstalledCertificateStatusEnumType.NotFound)
+ expect(response.statusInfo).toBeDefined()
+ })
+ })
+})
--- /dev/null
+/* eslint-disable @typescript-eslint/no-unsafe-member-access */
+/* eslint-disable @typescript-eslint/no-unsafe-assignment */
+/* eslint-disable @typescript-eslint/no-unsafe-call */
+/* eslint-disable @typescript-eslint/no-explicit-any */
+
+import { expect } from '@std/expect'
+import { describe, it, mock } from 'node:test'
+
+import { OCPP20IncomingRequestService } from '../../../../src/charging-station/ocpp/2.0/OCPP20IncomingRequestService.js'
+import {
+ InstallCertificateStatusEnumType,
+ InstallCertificateUseEnumType,
+ type OCPP20InstallCertificateRequest,
+ type OCPP20InstallCertificateResponse,
+ OCPPVersion,
+} from '../../../../src/types/index.js'
+import { Constants } from '../../../../src/utils/index.js'
+import { createChargingStation } from '../../../ChargingStationFactory.js'
+import { TEST_CHARGING_STATION_BASE_NAME } from './OCPP20TestConstants.js'
+
+const VALID_PEM_CERTIFICATE = `-----BEGIN CERTIFICATE-----
+MIIBkTCB+wIJAKHBfpvPA0GXMA0GCSqGSIb3DQEBCwUAMBExDzANBgNVBAMMBnRl
+c3RDQTAeFw0yNDAxMDEwMDAwMDBaFw0yOTAxMDEwMDAwMDBaMBExDzANBgNVBAMM
+BnRlc3RDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC5p8U8zTk8TT5H5s8mjxJz
+p+eDAh+xW1+eTprjqD4vfQSXCv8hC3TlPpZwHk8C5dJmEp8Dqv3lAO5bVkzzqbhR
+AgMBAAGjUzBRMB0GA1UdDgQWBBRc8RqFu0nnqJdw3f9nFVXm9BxeUDAfBgNVHSME
+GDAWgBRc8RqFu0nnqJdw3f9nFVXm9BxeUDAPBgNVHRMBAf8EBTADAQH/MA0GCSqG
+SIb3DQEBCwUAA0EAYw7K5EKcJGj8TH7NpP3L3hRPZF8qU5QfT0zQBqBm4U5JtDnS
+nFUewM7PNhYJsWjJRpLdAL1kC6x8bW1kQ5FVUQ==
+-----END CERTIFICATE-----`
+
+const INVALID_PEM_CERTIFICATE_MISSING_MARKERS = `MIIBkTCB+wIJAKHBfpvPA0GXMA0GCSqGSIb3DQEBCwUAMBExDzANBgNVBAMMBn
+Rlc3RDQTAeFw0yNDAxMDEwMDAwMDBaFw0yOTAxMDEwMDAwMDBaMBExDzANBgNVBA
+MMBnRlc3RDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC5p8U8zTk8TT5H5s8mjx`
+
+const EXPIRED_PEM_CERTIFICATE = `-----BEGIN CERTIFICATE-----
+MIIBkTCB+wIJAKHBfpvPA0GXMA0GCSqGSIb3DQEBCwUAMBExDzANBgNVBAMMBnRl
+c3RDQTAeFw0yMDAxMDEwMDAwMDBaFw0yMTAxMDEwMDAwMDBaMBExDzANBgNVBAMM
+BnRlc3RDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC5p8U8zTk8TT5H5s8mjxJz
+p+eDAh+xW1+eTprjqD4vfQSXCv8hC3TlPpZwHk8C5dJmEp8Dqv3lAO5bVkzzqbhR
+AgMBAAGjUzBRMB0GA1UdDgQWBBRc8RqFu0nnqJdw3f9nFVXm9BxeUDAfBgNVHSME
+GDAWgBRc8RqFu0nnqJdw3f9nFVXm9BxeUDAPBgNVHRMBAf8EBTADAQH/MA0GCSqG
+SIb3DQEBCwUAA0EAexpired==
+-----END CERTIFICATE-----`
+
+const createMockCertificateManager = (
+ options: {
+ storeCertificateError?: Error
+ storeCertificateResult?: boolean
+ } = {}
+) => ({
+ deleteCertificate: mock.fn(),
+ getInstalledCertificates: mock.fn(() => []),
+ storeCertificate: mock.fn(() => {
+ if (options.storeCertificateError) {
+ throw options.storeCertificateError
+ }
+ return { success: options.storeCertificateResult ?? true }
+ }),
+ validateCertificateFormat: mock.fn((cert: string) => {
+ return (
+ cert.includes('-----BEGIN CERTIFICATE-----') && cert.includes('-----END CERTIFICATE-----')
+ )
+ }),
+})
+
+await describe('I03 - InstallCertificate', async () => {
+ const mockChargingStation = createChargingStation({
+ baseName: TEST_CHARGING_STATION_BASE_NAME,
+ connectorsCount: 3,
+ evseConfiguration: { evsesCount: 3 },
+ heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
+ stationInfo: {
+ ocppStrictCompliance: false,
+ ocppVersion: OCPPVersion.VERSION_201,
+ },
+ websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
+ })
+
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager()
+
+ const incomingRequestService = new OCPP20IncomingRequestService()
+
+ await describe('Valid Certificate Installation', async () => {
+ await it('Should accept valid V2GRootCertificate', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ storeCertificateResult: true,
+ })
+
+ const request: OCPP20InstallCertificateRequest = {
+ certificate: VALID_PEM_CERTIFICATE,
+ certificateType: InstallCertificateUseEnumType.V2GRootCertificate,
+ }
+
+ const response: OCPP20InstallCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestInstallCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(typeof response).toBe('object')
+ expect(response.status).toBeDefined()
+ expect(typeof response.status).toBe('string')
+ expect(response.status).toBe(InstallCertificateStatusEnumType.Accepted)
+ expect(response.statusInfo).toBeUndefined()
+ })
+
+ await it('Should accept valid MORootCertificate', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ storeCertificateResult: true,
+ })
+
+ const request: OCPP20InstallCertificateRequest = {
+ certificate: VALID_PEM_CERTIFICATE,
+ certificateType: InstallCertificateUseEnumType.MORootCertificate,
+ }
+
+ const response: OCPP20InstallCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestInstallCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(InstallCertificateStatusEnumType.Accepted)
+ expect(response.statusInfo).toBeUndefined()
+ })
+
+ await it('Should accept valid CSMSRootCertificate', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ storeCertificateResult: true,
+ })
+
+ const request: OCPP20InstallCertificateRequest = {
+ certificate: VALID_PEM_CERTIFICATE,
+ certificateType: InstallCertificateUseEnumType.CSMSRootCertificate,
+ }
+
+ const response: OCPP20InstallCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestInstallCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(InstallCertificateStatusEnumType.Accepted)
+ expect(response.statusInfo).toBeUndefined()
+ })
+
+ await it('Should accept valid ManufacturerRootCertificate', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ storeCertificateResult: true,
+ })
+
+ const request: OCPP20InstallCertificateRequest = {
+ certificate: VALID_PEM_CERTIFICATE,
+ certificateType: InstallCertificateUseEnumType.ManufacturerRootCertificate,
+ }
+
+ const response: OCPP20InstallCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestInstallCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(InstallCertificateStatusEnumType.Accepted)
+ expect(response.statusInfo).toBeUndefined()
+ })
+ })
+
+ await describe('Invalid Certificate Handling', async () => {
+ await it('Should reject certificate with invalid PEM format', async () => {
+ const request: OCPP20InstallCertificateRequest = {
+ certificate: INVALID_PEM_CERTIFICATE_MISSING_MARKERS,
+ certificateType: InstallCertificateUseEnumType.V2GRootCertificate,
+ }
+
+ const response: OCPP20InstallCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestInstallCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(InstallCertificateStatusEnumType.Rejected)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBeDefined()
+ expect(typeof response.statusInfo?.reasonCode).toBe('string')
+ })
+
+ await it('Should reject expired certificate when validation is enabled', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ storeCertificateResult: false,
+ })
+ ;(mockChargingStation as any).stationInfo.validateCertificateExpiry = true
+
+ const request: OCPP20InstallCertificateRequest = {
+ certificate: EXPIRED_PEM_CERTIFICATE,
+ certificateType: InstallCertificateUseEnumType.CSMSRootCertificate,
+ }
+
+ const response: OCPP20InstallCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestInstallCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(InstallCertificateStatusEnumType.Rejected)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBeDefined()
+
+ delete (mockChargingStation as any).stationInfo.validateCertificateExpiry
+ })
+ })
+
+ await describe('Storage Failure Handling', async () => {
+ await it('Should return Failed status when storage is full', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ storeCertificateError: new Error('Storage full'),
+ })
+
+ const request: OCPP20InstallCertificateRequest = {
+ certificate: VALID_PEM_CERTIFICATE,
+ certificateType: InstallCertificateUseEnumType.MORootCertificate,
+ }
+
+ const response: OCPP20InstallCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestInstallCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(InstallCertificateStatusEnumType.Failed)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBeDefined()
+ })
+ })
+
+ await describe('Response Structure Validation', async () => {
+ await it('Should return response matching InstallCertificateResponse schema', async () => {
+ ;(mockChargingStation as any).certificateManager = createMockCertificateManager({
+ storeCertificateResult: true,
+ })
+
+ const request: OCPP20InstallCertificateRequest = {
+ certificate: VALID_PEM_CERTIFICATE,
+ certificateType: InstallCertificateUseEnumType.V2GRootCertificate,
+ }
+
+ const response: OCPP20InstallCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestInstallCertificate(mockChargingStation, request)
+
+ expect(response).toBeDefined()
+ expect(typeof response).toBe('object')
+
+ expect(response.status).toBeDefined()
+ expect([
+ InstallCertificateStatusEnumType.Accepted,
+ InstallCertificateStatusEnumType.Rejected,
+ InstallCertificateStatusEnumType.Failed,
+ ]).toContain(response.status)
+
+ if (response.statusInfo != null) {
+ expect(response.statusInfo.reasonCode).toBeDefined()
+ expect(typeof response.statusInfo.reasonCode).toBe('string')
+ if (response.statusInfo.additionalInfo != null) {
+ expect(typeof response.statusInfo.additionalInfo).toBe('string')
+ }
+ }
+
+ if (response.customData != null) {
+ expect(response.customData.vendorId).toBeDefined()
+ expect(typeof response.customData.vendorId).toBe('string')
+ }
+ })
+
+ await it('Should include statusInfo with reasonCode for rejection', async () => {
+ const request: OCPP20InstallCertificateRequest = {
+ certificate: INVALID_PEM_CERTIFICATE_MISSING_MARKERS,
+ certificateType: InstallCertificateUseEnumType.V2GRootCertificate,
+ }
+
+ const response: OCPP20InstallCertificateResponse = await (
+ incomingRequestService as any
+ ).handleRequestInstallCertificate(mockChargingStation, request)
+
+ expect(response.status).toBe(InstallCertificateStatusEnumType.Rejected)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBeDefined()
+ expect(typeof response.statusInfo?.reasonCode).toBe('string')
+ expect(response.statusInfo?.reasonCode.length).toBeGreaterThan(0)
+ expect(response.statusInfo?.reasonCode.length).toBeLessThanOrEqual(20)
+ })
+ })
+})
import { createChargingStation } from '../../../ChargingStationFactory.js'
import { createMockAuthService } from '../auth/helpers/MockFactories.js'
import { TEST_CHARGING_STATION_BASE_NAME } from './OCPP20TestConstants.js'
-import { resetLimits, resetReportingValueSize } from './OCPP20TestUtils.js'
+import {
+ resetConnectorTransactionState,
+ resetLimits,
+ resetReportingValueSize,
+} from './OCPP20TestUtils.js'
await describe('F01 & F02 - Remote Start Transaction', async () => {
const mockChargingStation = createChargingStation({
beforeEach(() => {
const stationId = mockChargingStation.stationInfo?.chargingStationId ?? 'unknown'
OCPPAuthServiceFactory.setInstanceForTesting(stationId, createMockAuthService())
+ resetConnectorTransactionState(mockChargingStation)
+ resetLimits(mockChargingStation)
+ resetReportingValueSize(mockChargingStation)
})
- // Clean up after tests
afterEach(() => {
OCPPAuthServiceFactory.clearAllInstances()
})
- // Reset limits before each test
- resetLimits(mockChargingStation)
- resetReportingValueSize(mockChargingStation)
-
// FR: F01.FR.03, F01.FR.04, F01.FR.05, F01.FR.13
await it('Should handle RequestStartTransaction with valid evseId and idToken', async () => {
const validRequest: OCPP20RequestStartTransactionRequest = {
expect(typeof response.transactionId).toBe('string')
})
- // FR: F01.FR.17, F02.FR.05
- await it('Should include remoteStartId and idToken in TransactionEvent', async () => {
- let capturedTransactionEvent: any = null
+ // FR: F01.FR.17, F02.FR.05 - Verify remoteStartId and idToken are stored for later TransactionEvent
+ await it('Should store remoteStartId and idToken in connector status for TransactionEvent', async () => {
const spyChargingStation = createChargingStation({
baseName: TEST_CHARGING_STATION_BASE_NAME,
connectorsCount: 3,
evseConfiguration: { evsesCount: 3 },
heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
ocppRequestService: {
- requestHandler: async (_cs: any, _cmd: any, payload: any) => {
- capturedTransactionEvent = payload
- return Promise.resolve({})
- },
+ requestHandler: async () => Promise.resolve({}),
},
stationInfo: {
ocppStrictCompliance: false,
websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
})
+ const stationId = spyChargingStation.stationInfo?.chargingStationId ?? 'unknown'
+ OCPPAuthServiceFactory.setInstanceForTesting(stationId, createMockAuthService())
+
const requestWithRemoteStartId: OCPP20RequestStartTransactionRequest = {
evseId: 1,
idToken: {
expect(response.status).toBe(RequestStartStopStatusEnumType.Accepted)
expect(response.transactionId).toBeDefined()
- expect(capturedTransactionEvent).toBeDefined()
- expect(capturedTransactionEvent.transactionInfo).toBeDefined()
- expect(capturedTransactionEvent.transactionInfo.remoteStartId).toBe(42)
+ const connectorStatus = spyChargingStation.getConnectorStatus(1)
+ expect(connectorStatus).toBeDefined()
+ expect(connectorStatus?.remoteStartId).toBe(42)
+ expect(connectorStatus?.transactionIdTag).toBe('REMOTE_TOKEN_456')
+ expect(connectorStatus?.transactionStarted).toBe(true)
+ expect(connectorStatus?.transactionId).toBe(response.transactionId)
- expect(capturedTransactionEvent.idToken).toBeDefined()
- expect(capturedTransactionEvent.idToken.idToken).toBe('REMOTE_TOKEN_456')
- expect(capturedTransactionEvent.idToken.type).toBe(OCPP20IdTokenEnumType.ISO15693)
+ OCPPAuthServiceFactory.clearAllInstances()
})
// FR: F01.FR.19
--- /dev/null
+/* eslint-disable @typescript-eslint/no-unsafe-member-access */
+/* eslint-disable @typescript-eslint/no-unsafe-assignment */
+/* eslint-disable @typescript-eslint/no-unsafe-call */
+/* eslint-disable @typescript-eslint/no-explicit-any */
+/* cspell:ignore Bvbn NQIF CBCYX */
+
+import { expect } from '@std/expect'
+import { describe, it, mock } from 'node:test'
+
+import { OCPP20RequestService } from '../../../../src/charging-station/ocpp/2.0/OCPP20RequestService.js'
+import { OCPP20ResponseService } from '../../../../src/charging-station/ocpp/2.0/OCPP20ResponseService.js'
+import {
+ CertificateActionEnumType,
+ GetCertificateStatusEnumType,
+ HashAlgorithmEnumType,
+ Iso15118EVCertificateStatusEnumType,
+ type OCPP20Get15118EVCertificateRequest,
+ type OCPP20Get15118EVCertificateResponse,
+ type OCPP20GetCertificateStatusRequest,
+ type OCPP20GetCertificateStatusResponse,
+ OCPP20RequestCommand,
+ OCPPVersion,
+ type OCSPRequestDataType,
+ ReasonCodeEnumType,
+} from '../../../../src/types/index.js'
+import { Constants } from '../../../../src/utils/index.js'
+import { createChargingStation } from '../../../ChargingStationFactory.js'
+import { TEST_CHARGING_STATION_BASE_NAME } from './OCPP20TestConstants.js'
+
+// Sample Base64 EXI request (mock - represents CertificateInstallationReq)
+const MOCK_EXI_REQUEST = 'SGVsbG8gV29ybGQgRVhJIFJlcXVlc3Q='
+const MOCK_EXI_RESPONSE = 'SGVsbG8gV29ybGQgRVhJIFJlc3BvbnNl'
+const MOCK_ISO15118_SCHEMA_VERSION = 'urn:iso:std:iso:15118:-20:AC'
+const MOCK_OCSP_RESULT = 'TW9jayBPQ1NQIFJlc3VsdCBCYXNlNjQ='
+
+// Helper to create mock request service with mocked sendMessage
+const createMockRequestService = <T>(responseOverride?: Partial<T>) => {
+ const mockResponseService = new OCPP20ResponseService()
+ const requestService = new OCPP20RequestService(mockResponseService)
+
+ // Mock sendMessage to return configured response
+ ;(requestService as any).sendMessage = mock.fn(() =>
+ Promise.resolve({
+ ...responseOverride,
+ })
+ )
+
+ return requestService
+}
+
+// Mock OCSP request data for GetCertificateStatus tests
+const createMockOCSPRequestData = (): OCSPRequestDataType => ({
+ hashAlgorithm: HashAlgorithmEnumType.SHA256,
+ issuerKeyHash: 'abc123def456issuerkeyhash',
+ issuerNameHash: 'abc123def456issuernamehash',
+ responderURL: 'http://ocsp.example.com',
+ serialNumber: '1234567890',
+})
+
+await describe('M02 - Get15118EVCertificate Request', async () => {
+ const mockChargingStation = createChargingStation({
+ baseName: TEST_CHARGING_STATION_BASE_NAME,
+ connectorsCount: 3,
+ evseConfiguration: { evsesCount: 3 },
+ heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
+ stationInfo: {
+ ocppStrictCompliance: false,
+ ocppVersion: OCPPVersion.VERSION_201,
+ },
+ websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
+ })
+
+ await describe('EXI Install Action', async () => {
+ await it('Should forward EXI request unmodified for Install action', async () => {
+ const requestService = createMockRequestService<OCPP20Get15118EVCertificateResponse>({
+ exiResponse: MOCK_EXI_RESPONSE,
+ status: Iso15118EVCertificateStatusEnumType.Accepted,
+ })
+
+ await (requestService as any).requestGet15118EVCertificate(
+ mockChargingStation,
+ MOCK_ISO15118_SCHEMA_VERSION,
+ CertificateActionEnumType.Install,
+ MOCK_EXI_REQUEST
+ )
+
+ const sendMessageMock = (requestService as any).sendMessage
+ expect(sendMessageMock.mock.calls.length).toBe(1)
+
+ const sentPayload = sendMessageMock.mock.calls[0]
+ .arguments[2] as OCPP20Get15118EVCertificateRequest
+ expect(sentPayload.exiRequest).toBe(MOCK_EXI_REQUEST)
+ expect(sentPayload.action).toBe(CertificateActionEnumType.Install)
+ })
+ })
+
+ await describe('EXI Update Action', async () => {
+ await it('Should forward EXI request unmodified for Update action', async () => {
+ const requestService = createMockRequestService<OCPP20Get15118EVCertificateResponse>({
+ exiResponse: MOCK_EXI_RESPONSE,
+ status: Iso15118EVCertificateStatusEnumType.Accepted,
+ })
+
+ await (requestService as any).requestGet15118EVCertificate(
+ mockChargingStation,
+ MOCK_ISO15118_SCHEMA_VERSION,
+ CertificateActionEnumType.Update,
+ MOCK_EXI_REQUEST
+ )
+
+ const sendMessageMock = (requestService as any).sendMessage
+ const sentPayload = sendMessageMock.mock.calls[0]
+ .arguments[2] as OCPP20Get15118EVCertificateRequest
+ expect(sentPayload.exiRequest).toBe(MOCK_EXI_REQUEST)
+ expect(sentPayload.action).toBe(CertificateActionEnumType.Update)
+ })
+ })
+
+ await describe('CSMS Response Handling', async () => {
+ await it('Should return Accepted response with exiResponse from CSMS', async () => {
+ const requestService = createMockRequestService<OCPP20Get15118EVCertificateResponse>({
+ exiResponse: MOCK_EXI_RESPONSE,
+ status: Iso15118EVCertificateStatusEnumType.Accepted,
+ })
+
+ const response: OCPP20Get15118EVCertificateResponse = await (
+ requestService as any
+ ).requestGet15118EVCertificate(
+ mockChargingStation,
+ MOCK_ISO15118_SCHEMA_VERSION,
+ CertificateActionEnumType.Install,
+ MOCK_EXI_REQUEST
+ )
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(Iso15118EVCertificateStatusEnumType.Accepted)
+ expect(response.exiResponse).toBe(MOCK_EXI_RESPONSE)
+ })
+
+ await it('Should return Failed response from CSMS', async () => {
+ const requestService = createMockRequestService<OCPP20Get15118EVCertificateResponse>({
+ exiResponse: '',
+ status: Iso15118EVCertificateStatusEnumType.Failed,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InvalidCertificate,
+ },
+ })
+
+ const response: OCPP20Get15118EVCertificateResponse = await (
+ requestService as any
+ ).requestGet15118EVCertificate(
+ mockChargingStation,
+ MOCK_ISO15118_SCHEMA_VERSION,
+ CertificateActionEnumType.Install,
+ MOCK_EXI_REQUEST
+ )
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(Iso15118EVCertificateStatusEnumType.Failed)
+ expect(response.statusInfo?.reasonCode).toBe(ReasonCodeEnumType.InvalidCertificate)
+ })
+ })
+
+ await describe('Schema Version Parameter', async () => {
+ await it('Should pass schema version correctly', async () => {
+ const requestService = createMockRequestService<OCPP20Get15118EVCertificateResponse>({
+ exiResponse: MOCK_EXI_RESPONSE,
+ status: Iso15118EVCertificateStatusEnumType.Accepted,
+ })
+
+ await (requestService as any).requestGet15118EVCertificate(
+ mockChargingStation,
+ MOCK_ISO15118_SCHEMA_VERSION,
+ CertificateActionEnumType.Install,
+ MOCK_EXI_REQUEST
+ )
+
+ const sendMessageMock = (requestService as any).sendMessage
+ const sentPayload = sendMessageMock.mock.calls[0]
+ .arguments[2] as OCPP20Get15118EVCertificateRequest
+ expect(sentPayload.iso15118SchemaVersion).toBe(MOCK_ISO15118_SCHEMA_VERSION)
+ })
+ })
+
+ await describe('Base64 EXI Pass-Through', async () => {
+ await it('Should pass Base64 EXI string unchanged', async () => {
+ const complexBase64EXI =
+ 'VGhpcyBpcyBhIG1vcmUgY29tcGxleCBFWEkgcGF5bG9hZCB3aXRoIHNwZWNpYWwgY2hhcmFjdGVycyArLz0='
+
+ const requestService = createMockRequestService<OCPP20Get15118EVCertificateResponse>({
+ exiResponse: MOCK_EXI_RESPONSE,
+ status: Iso15118EVCertificateStatusEnumType.Accepted,
+ })
+
+ await (requestService as any).requestGet15118EVCertificate(
+ mockChargingStation,
+ MOCK_ISO15118_SCHEMA_VERSION,
+ CertificateActionEnumType.Install,
+ complexBase64EXI
+ )
+
+ const sendMessageMock = (requestService as any).sendMessage
+ const sentPayload = sendMessageMock.mock.calls[0]
+ .arguments[2] as OCPP20Get15118EVCertificateRequest
+ // EXI should be passed through unchanged - no decoding/encoding
+ expect(sentPayload.exiRequest).toBe(complexBase64EXI)
+ })
+ })
+})
+
+await describe('M03 - GetCertificateStatus Request', async () => {
+ const mockChargingStation = createChargingStation({
+ baseName: TEST_CHARGING_STATION_BASE_NAME,
+ connectorsCount: 3,
+ evseConfiguration: { evsesCount: 3 },
+ heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
+ stationInfo: {
+ ocppStrictCompliance: false,
+ ocppVersion: OCPPVersion.VERSION_201,
+ },
+ websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
+ })
+
+ await describe('OCSP Request Data', async () => {
+ await it('Should send OCSP request data correctly', async () => {
+ const requestService = createMockRequestService<OCPP20GetCertificateStatusResponse>({
+ ocspResult: MOCK_OCSP_RESULT,
+ status: GetCertificateStatusEnumType.Accepted,
+ })
+
+ const ocspRequestData = createMockOCSPRequestData()
+
+ await (requestService as any).requestGetCertificateStatus(
+ mockChargingStation,
+ ocspRequestData
+ )
+
+ const sendMessageMock = (requestService as any).sendMessage
+ expect(sendMessageMock.mock.calls.length).toBe(1)
+
+ const sentPayload = sendMessageMock.mock.calls[0]
+ .arguments[2] as OCPP20GetCertificateStatusRequest
+ expect(sentPayload.ocspRequestData).toBeDefined()
+ expect(sentPayload.ocspRequestData.hashAlgorithm).toBe(HashAlgorithmEnumType.SHA256)
+ expect(sentPayload.ocspRequestData.issuerKeyHash).toBe(ocspRequestData.issuerKeyHash)
+ expect(sentPayload.ocspRequestData.issuerNameHash).toBe(ocspRequestData.issuerNameHash)
+ expect(sentPayload.ocspRequestData.serialNumber).toBe(ocspRequestData.serialNumber)
+ expect(sentPayload.ocspRequestData.responderURL).toBe(ocspRequestData.responderURL)
+ })
+ })
+
+ await describe('CSMS Response Handling', async () => {
+ await it('Should return Accepted response with ocspResult from CSMS', async () => {
+ const requestService = createMockRequestService<OCPP20GetCertificateStatusResponse>({
+ ocspResult: MOCK_OCSP_RESULT,
+ status: GetCertificateStatusEnumType.Accepted,
+ })
+
+ const response: OCPP20GetCertificateStatusResponse = await (
+ requestService as any
+ ).requestGetCertificateStatus(mockChargingStation, createMockOCSPRequestData())
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GetCertificateStatusEnumType.Accepted)
+ expect(response.ocspResult).toBe(MOCK_OCSP_RESULT)
+ })
+
+ await it('Should return Failed response from CSMS', async () => {
+ const requestService = createMockRequestService<OCPP20GetCertificateStatusResponse>({
+ status: GetCertificateStatusEnumType.Failed,
+ statusInfo: {
+ reasonCode: ReasonCodeEnumType.InternalError,
+ },
+ })
+
+ const response: OCPP20GetCertificateStatusResponse = await (
+ requestService as any
+ ).requestGetCertificateStatus(mockChargingStation, createMockOCSPRequestData())
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GetCertificateStatusEnumType.Failed)
+ expect(response.statusInfo?.reasonCode).toBe(ReasonCodeEnumType.InternalError)
+ })
+ })
+
+ await describe('Stub OCSP Response', async () => {
+ await it('Should handle stub OCSP response correctly', async () => {
+ // This tests that the simulator doesn't make real network calls
+ // Response is stubbed/mocked at the sendMessage level
+ const stubOcspResult = 'U3R1YiBPQ1NQIFJlc3BvbnNlIERhdGE='
+
+ const requestService = createMockRequestService<OCPP20GetCertificateStatusResponse>({
+ ocspResult: stubOcspResult,
+ status: GetCertificateStatusEnumType.Accepted,
+ })
+
+ const response: OCPP20GetCertificateStatusResponse = await (
+ requestService as any
+ ).requestGetCertificateStatus(mockChargingStation, createMockOCSPRequestData())
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GetCertificateStatusEnumType.Accepted)
+ expect(response.ocspResult).toBe(stubOcspResult)
+
+ // Verify sendMessage was called (no real network call)
+ const sendMessageMock = (requestService as any).sendMessage
+ expect(sendMessageMock.mock.calls.length).toBe(1)
+ })
+ })
+})
+
+await describe('Request Command Names', async () => {
+ const mockChargingStation = createChargingStation({
+ baseName: TEST_CHARGING_STATION_BASE_NAME,
+ connectorsCount: 1,
+ evseConfiguration: { evsesCount: 1 },
+ heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
+ stationInfo: {
+ ocppStrictCompliance: false,
+ ocppVersion: OCPPVersion.VERSION_201,
+ },
+ websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
+ })
+
+ await it('Should send GET_15118_EV_CERTIFICATE command name', async () => {
+ const requestService = createMockRequestService<OCPP20Get15118EVCertificateResponse>({
+ exiResponse: MOCK_EXI_RESPONSE,
+ status: Iso15118EVCertificateStatusEnumType.Accepted,
+ })
+
+ await (requestService as any).requestGet15118EVCertificate(
+ mockChargingStation,
+ MOCK_ISO15118_SCHEMA_VERSION,
+ CertificateActionEnumType.Install,
+ MOCK_EXI_REQUEST
+ )
+
+ const sendMessageMock = (requestService as any).sendMessage
+ const commandName = sendMessageMock.mock.calls[0].arguments[3]
+ expect(commandName).toBe(OCPP20RequestCommand.GET_15118_EV_CERTIFICATE)
+ })
+
+ await it('Should send GET_CERTIFICATE_STATUS command name', async () => {
+ const requestService = createMockRequestService<OCPP20GetCertificateStatusResponse>({
+ ocspResult: MOCK_OCSP_RESULT,
+ status: GetCertificateStatusEnumType.Accepted,
+ })
+
+ await (requestService as any).requestGetCertificateStatus(
+ mockChargingStation,
+ createMockOCSPRequestData()
+ )
+
+ const sendMessageMock = (requestService as any).sendMessage
+ const commandName = sendMessageMock.mock.calls[0].arguments[3]
+ expect(commandName).toBe(OCPP20RequestCommand.GET_CERTIFICATE_STATUS)
+ })
+})
--- /dev/null
+/* eslint-disable @typescript-eslint/no-unsafe-member-access */
+/* eslint-disable @typescript-eslint/no-unsafe-assignment */
+/* eslint-disable @typescript-eslint/no-unsafe-call */
+/* eslint-disable @typescript-eslint/no-explicit-any */
+
+import { expect } from '@std/expect'
+import { describe, it, mock } from 'node:test'
+
+import { OCPP20RequestService } from '../../../../src/charging-station/ocpp/2.0/OCPP20RequestService.js'
+import { OCPP20ResponseService } from '../../../../src/charging-station/ocpp/2.0/OCPP20ResponseService.js'
+import {
+ CertificateSigningUseEnumType,
+ GenericStatus,
+ OCPP20RequestCommand,
+ type OCPP20SignCertificateRequest,
+ type OCPP20SignCertificateResponse,
+ OCPPVersion,
+} from '../../../../src/types/index.js'
+import { Constants } from '../../../../src/utils/index.js'
+import { createChargingStation } from '../../../ChargingStationFactory.js'
+import { TEST_CHARGING_STATION_BASE_NAME } from './OCPP20TestConstants.js'
+
+const MOCK_ORGANIZATION_NAME = 'Test Organization Inc.'
+
+// Helper to create mock request service with mocked sendMessage
+const createMockRequestService = (responseOverride?: Partial<OCPP20SignCertificateResponse>) => {
+ const mockResponseService = new OCPP20ResponseService()
+ const requestService = new OCPP20RequestService(mockResponseService)
+
+ // Mock sendMessage to return configured response
+ ;(requestService as any).sendMessage = mock.fn(() =>
+ Promise.resolve({
+ status: GenericStatus.Accepted,
+ ...responseOverride,
+ })
+ )
+
+ return requestService
+}
+
+await describe('I02 - SignCertificate Request', async () => {
+ const mockChargingStation = createChargingStation({
+ baseName: TEST_CHARGING_STATION_BASE_NAME,
+ connectorsCount: 3,
+ evseConfiguration: { evsesCount: 3 },
+ heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
+ stationInfo: {
+ ocppStrictCompliance: false,
+ ocppVersion: OCPPVersion.VERSION_201,
+ },
+ websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
+ })
+
+ // Set up configuration with OrganizationName
+ mockChargingStation.ocppConfiguration = {
+ configurationKey: [{ key: 'SecurityCtrlr.OrganizationName', value: MOCK_ORGANIZATION_NAME }],
+ }
+
+ await describe('CSR Generation', async () => {
+ await it('Should generate CSR with PKCS#10 PEM format', async () => {
+ const requestService = createMockRequestService()
+
+ const response = await (requestService as any).requestSignCertificate(
+ mockChargingStation,
+ CertificateSigningUseEnumType.ChargingStationCertificate
+ )
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GenericStatus.Accepted)
+
+ const sendMessageMock = (requestService as any).sendMessage
+ expect(sendMessageMock.mock.calls.length).toBeGreaterThan(0)
+
+ const sentPayload = sendMessageMock.mock.calls[0].arguments[2] as OCPP20SignCertificateRequest
+ expect(sentPayload.csr).toBeDefined()
+ expect(sentPayload.csr).toContain('-----BEGIN CERTIFICATE REQUEST-----')
+ expect(sentPayload.csr).toContain('-----END CERTIFICATE REQUEST-----')
+ })
+
+ await it('Should include OrganizationName from SecurityCtrlr config in CSR', async () => {
+ const requestService = createMockRequestService()
+
+ await (requestService as any).requestSignCertificate(
+ mockChargingStation,
+ CertificateSigningUseEnumType.ChargingStationCertificate
+ )
+
+ const sendMessageMock = (requestService as any).sendMessage
+ const sentPayload = sendMessageMock.mock.calls[0].arguments[2] as OCPP20SignCertificateRequest
+ expect(sentPayload.csr).toBeDefined()
+ expect(sentPayload.csr).toContain('-----BEGIN CERTIFICATE REQUEST-----')
+
+ const csrRegex =
+ /-----BEGIN CERTIFICATE REQUEST-----\n(.+?)\n-----END CERTIFICATE REQUEST-----/
+ const csrExecResult = csrRegex.exec(sentPayload.csr)
+ expect(csrExecResult).toBeDefined()
+ const csrData = csrExecResult?.[1]
+ const decodedCsr = Buffer.from(csrData ?? '', 'base64').toString('utf-8')
+ expect(decodedCsr).toContain('O=Test Organization Inc.')
+ })
+ })
+
+ await describe('ChargingStationCertificate Type', async () => {
+ await it('Should send SignCertificateRequest with ChargingStationCertificate type', async () => {
+ const requestService = createMockRequestService()
+
+ await (requestService as any).requestSignCertificate(
+ mockChargingStation,
+ CertificateSigningUseEnumType.ChargingStationCertificate
+ )
+
+ const sendMessageMock = (requestService as any).sendMessage
+ const sentPayload = sendMessageMock.mock.calls[0].arguments[2] as OCPP20SignCertificateRequest
+
+ expect(sentPayload.certificateType).toBe(
+ CertificateSigningUseEnumType.ChargingStationCertificate
+ )
+ })
+ })
+
+ await describe('V2GCertificate Type', async () => {
+ await it('Should send SignCertificateRequest with V2GCertificate type', async () => {
+ const requestService = createMockRequestService()
+
+ await (requestService as any).requestSignCertificate(
+ mockChargingStation,
+ CertificateSigningUseEnumType.V2GCertificate
+ )
+
+ const sendMessageMock = (requestService as any).sendMessage
+ const sentPayload = sendMessageMock.mock.calls[0].arguments[2] as OCPP20SignCertificateRequest
+
+ expect(sentPayload.certificateType).toBe(CertificateSigningUseEnumType.V2GCertificate)
+ })
+ })
+
+ await describe('CSMS Response Handling', async () => {
+ await it('Should return Accepted response from CSMS', async () => {
+ const requestService = createMockRequestService({
+ status: GenericStatus.Accepted,
+ })
+
+ const response: OCPP20SignCertificateResponse = await (
+ requestService as any
+ ).requestSignCertificate(
+ mockChargingStation,
+ CertificateSigningUseEnumType.ChargingStationCertificate
+ )
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GenericStatus.Accepted)
+ })
+
+ await it('Should return Rejected response from CSMS', async () => {
+ const requestService = createMockRequestService({
+ status: GenericStatus.Rejected,
+ statusInfo: {
+ reasonCode: 'InvalidCSR',
+ },
+ })
+
+ const response: OCPP20SignCertificateResponse = await (
+ requestService as any
+ ).requestSignCertificate(
+ mockChargingStation,
+ CertificateSigningUseEnumType.ChargingStationCertificate
+ )
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GenericStatus.Rejected)
+ expect(response.statusInfo).toBeDefined()
+ expect(response.statusInfo?.reasonCode).toBe('InvalidCSR')
+ })
+ })
+
+ await describe('Optional Certificate Type', async () => {
+ await it('Should send SignCertificateRequest without certificateType when omitted', async () => {
+ const requestService = createMockRequestService()
+
+ await (requestService as any).requestSignCertificate(mockChargingStation)
+
+ const sendMessageMock = (requestService as any).sendMessage
+ const sentPayload = sendMessageMock.mock.calls[0].arguments[2] as OCPP20SignCertificateRequest
+
+ expect(sentPayload.csr).toBeDefined()
+ // certificateType should be undefined when not specified
+ expect(sentPayload.certificateType).toBeUndefined()
+ })
+ })
+
+ await describe('Request Payload Validation', async () => {
+ await it('Should build valid OCPP20SignCertificateRequest payload', async () => {
+ const requestService = createMockRequestService()
+
+ await (requestService as any).requestSignCertificate(
+ mockChargingStation,
+ CertificateSigningUseEnumType.ChargingStationCertificate
+ )
+
+ const sendMessageMock = (requestService as any).sendMessage
+ expect(sendMessageMock.mock.calls.length).toBe(1)
+
+ const sentPayload = sendMessageMock.mock.calls[0].arguments[2] as OCPP20SignCertificateRequest
+
+ // Validate payload structure
+ expect(typeof sentPayload).toBe('object')
+ expect(sentPayload.csr).toBeDefined()
+ expect(typeof sentPayload.csr).toBe('string')
+ expect(sentPayload.csr.length).toBeGreaterThan(0)
+ expect(sentPayload.csr.length).toBeLessThanOrEqual(5500) // Max length per schema
+ })
+
+ await it('Should send SIGN_CERTIFICATE command name', async () => {
+ const requestService = createMockRequestService()
+
+ await (requestService as any).requestSignCertificate(
+ mockChargingStation,
+ CertificateSigningUseEnumType.ChargingStationCertificate
+ )
+
+ const sendMessageMock = (requestService as any).sendMessage
+ const commandName = sendMessageMock.mock.calls[0].arguments[3]
+
+ expect(commandName).toBe(OCPP20RequestCommand.SIGN_CERTIFICATE)
+ })
+ })
+
+ await describe('Error Handling', async () => {
+ await it('Should generate CSR without certificate manager dependency', async () => {
+ const stationWithoutCertManager = createChargingStation({
+ baseName: TEST_CHARGING_STATION_BASE_NAME,
+ connectorsCount: 1,
+ evseConfiguration: { evsesCount: 1 },
+ heartbeatInterval: Constants.DEFAULT_HEARTBEAT_INTERVAL,
+ stationInfo: {
+ ocppStrictCompliance: false,
+ ocppVersion: OCPPVersion.VERSION_201,
+ },
+ websocketPingInterval: Constants.DEFAULT_WEBSOCKET_PING_INTERVAL,
+ })
+
+ stationWithoutCertManager.ocppConfiguration = {
+ configurationKey: [
+ { key: 'SecurityCtrlr.OrganizationName', value: MOCK_ORGANIZATION_NAME },
+ ],
+ }
+
+ delete (stationWithoutCertManager as any).certificateManager
+
+ const requestService = createMockRequestService()
+
+ const response = await (requestService as any).requestSignCertificate(
+ stationWithoutCertManager,
+ CertificateSigningUseEnumType.ChargingStationCertificate
+ )
+
+ expect(response).toBeDefined()
+ expect(response.status).toBe(GenericStatus.Accepted)
+
+ const sendMessageMock = (requestService as any).sendMessage
+ const sentPayload = sendMessageMock.mock.calls[0].arguments[2] as OCPP20SignCertificateRequest
+ expect(sentPayload.csr).toBeDefined()
+ expect(sentPayload.csr).toContain('-----BEGIN CERTIFICATE REQUEST-----')
+ })
+ })
+})
import type { ChargingStation } from '../../../../src/charging-station/ChargingStation.js'
import type { ConfigurationKey } from '../../../../src/types/ChargingStationOcppConfiguration.js'
-import { OCPP20RequiredVariableName } from '../../../../src/types/index.js'
+import { ConnectorStatusEnum, OCPP20RequiredVariableName } from '../../../../src/types/index.js'
import { Constants } from '../../../../src/utils/index.js'
+/**
+ * Reset connector transaction state for all connectors in the charging station.
+ * This ensures test isolation by clearing any transaction state from previous tests.
+ * @param chargingStation Charging station instance whose connector state should be reset.
+ */
+export function resetConnectorTransactionState (chargingStation: ChargingStation): void {
+ if (chargingStation.hasEvses) {
+ for (const evseStatus of chargingStation.evses.values()) {
+ for (const connectorStatus of evseStatus.connectors.values()) {
+ connectorStatus.transactionStarted = false
+ connectorStatus.transactionId = undefined
+ connectorStatus.transactionIdTag = undefined
+ connectorStatus.transactionStart = undefined
+ connectorStatus.transactionEnergyActiveImportRegisterValue = 0
+ connectorStatus.remoteStartId = undefined
+ connectorStatus.status = ConnectorStatusEnum.Available
+ connectorStatus.chargingProfiles = []
+ }
+ }
+ } else {
+ for (const [connectorId, connectorStatus] of chargingStation.connectors.entries()) {
+ if (connectorId === 0) continue // Skip connector 0 (charging station itself)
+ connectorStatus.transactionStarted = false
+ connectorStatus.transactionId = undefined
+ connectorStatus.transactionIdTag = undefined
+ connectorStatus.transactionStart = undefined
+ connectorStatus.transactionEnergyActiveImportRegisterValue = 0
+ connectorStatus.remoteStartId = undefined
+ connectorStatus.status = ConnectorStatusEnum.Available
+ connectorStatus.chargingProfiles = []
+ }
+ }
+}
+
/**
* Reset message size and element limits to generous defaults after tests manipulating them.
* Defaults chosen to exceed any test constructed payload sizes.
repositories / e-mobility-charging-stations-simulator.git / commitdiff
